From report at bugs.python.org  Thu Jul  1 00:18:23 2010
From: report at bugs.python.org (Yuv Gre)
Date: Wed, 30 Jun 2010 22:18:23 +0000
Subject: [New-bugs-announce] [issue9136] RuntimeError when profiling Decimal
In-Reply-To: <1277936303.13.0.879921120175.issue9136@psf.upfronthosting.co.za>
Message-ID: <1277936303.13.0.879921120175.issue9136@psf.upfronthosting.co.za>


New submission from Yuv Gre <ubershmekel at gmail.com>:

I'm using Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit (Intel)] on win32. Running the following code:


    import profile
    import math
    import decimal
    
    
    def show_bug():
        x = decimal.Decimal.from_float(math.e)**(-2**31)
    
    profile.run('show_bug()')

And I get this stack trace:

Traceback (most recent call last):
  File "C:/Users/Me/Documents/python/temptest", line 15, in <module>
    profile.run('show_bug()')
  File "C:\Python31\lib\profile.py", line 70, in run
    prof = prof.run(statement)
  File "C:\Python31\lib\profile.py", line 456, in run
    return self.runctx(cmd, dict, dict)
  File "C:\Python31\lib\profile.py", line 462, in runctx
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "C:/Users/Me/Documents/python/temptest", line 8, in show_bug
    x = Decimal.from_float(math.e)**(-2**31)
  File "C:\Python31\lib\decimal.py", line 2212, in __pow__
    context = getcontext()
  File "C:\Python31\lib\decimal.py", line 447, in getcontext
    context = Context()
  File "C:\Python31\lib\decimal.py", line 3777, in __init__
    for name, val in locals().items():
RuntimeError: dictionary changed size during iteration

----------
components: Library (Lib)
messages: 109023
nosy: ubershmekel
priority: normal
severity: normal
status: open
title: RuntimeError when profiling Decimal
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Thu Jul  1 17:12:42 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 01 Jul 2010 15:12:42 +0000
Subject: [New-bugs-announce] [issue9137] x.update(red=5, blue=6,
	other=7) doesn't work, where x is a MutableMapping
In-Reply-To: <1277997162.2.0.246195895629.issue9137@psf.upfronthosting.co.za>
Message-ID: <1277997162.2.0.246195895629.issue9137@psf.upfronthosting.co.za>


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

Simple example, using collections.OrderedDict:

>>> import collections
>>> x = collections.OrderedDict()
>>> x.update(red=5, blue=6, other=7)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/bin/../stow/Python-3.1.1/lib/python3.1/_abcoll.py", line 490, in update
    for key, value in other:
TypeError: 'int' object is not iterable

In MutableMapping.update, the first argument needs to be a positional-only argument.  Otherwise, it's impossible to use "other" as keyword argument to designate a key-value pair.

----------
assignee: stutzbach
messages: 109055
nosy: stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: x.update(red=5, blue=6, other=7) doesn't work, where x is a MutableMapping
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Jul  1 23:48:54 2010
From: report at bugs.python.org (Aahz)
Date: Thu, 01 Jul 2010 21:48:54 +0000
Subject: [New-bugs-announce] [issue9138] Tutorial: classes intro paragraph
	icky
In-Reply-To: <1278020934.41.0.867324522486.issue9138@psf.upfronthosting.co.za>
Message-ID: <1278020934.41.0.867324522486.issue9138@psf.upfronthosting.co.za>


New submission from Aahz <aahz at pythoncraft.com>:

http://docs.python.org/dev/tutorial/classes.html

Chapter 9 of the Tutorial contains this intro paragraph:

    Python's class mechanism adds classes to the language with a minimum
    of new syntax and semantics. It is a mixture of the class mechanisms
    found in C++ and Modula-3. As is true for modules, classes in Python
    do not put an absolute barrier between definition and user, but
    rather rely on the politeness of the user not to "break into the
    definition." The most important features of classes are retained with
    full power, however:  the class inheritance mechanism allows multiple
    base classes, a derived class can override any methods of its base
    class or classes, and a method can call the method of a base class
    with the same name.  Objects can contain an arbitrary amount of data.

A coworker found particularly the third sentence incomprehensible, and
even with ten years of Python under my belt, I can't say that it makes
much more sense to me.  I know what it must be trying to say and
therefore proffer this suggested rewrite:

    Compared with other programming languages, Python's class mechanism
    adds classes with a minimum of new syntax and semantics.  It is a
    mixture of the class mechanisms found in C++ and Modula-3.  Python
    classes provide all the standard features of Object Oriented
    Programming: the class inheritance mechanism allows multiple base
    classes, a derived class can override any methods of its base class
    or classes, and a method can call the method of a base class with the
    same name.  Objects can contain arbitrary amounts and kinds of data.
    As is true for modules, classes partake of the dynamic nature of
    Python; users of a class can modify or break the class definition
    even without changing the source code.

----------
assignee: docs at python
components: Documentation
messages: 109080
nosy: aahz, docs at python
priority: critical
severity: normal
stage: patch review
status: open
title: Tutorial: classes intro paragraph icky
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul  2 04:43:09 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Jul 2010 02:43:09 +0000
Subject: [New-bugs-announce] [issue9139] Add examples for str.format()
In-Reply-To: <1278038589.68.0.873296098752.issue9139@psf.upfronthosting.co.za>
Message-ID: <1278038589.68.0.873296098752.issue9139@psf.upfronthosting.co.za>


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

The attached patch adds a section with examples about str.format() after http://docs.python.org/library/string.html#format-specification-mini-language .
The patch needs some small improvements:
  1) the examples in the previous sections could be removed and/or a link to the new section could be added;
  2) the last example could be improved;
  3) another example using custom formats (e.g. for datetime) should be added;

I'd like to have this in 2.7 (Benjamin said it's OK), please review.

----------
assignee: ezio.melotti
components: Documentation
files: issue9139.diff
keywords: patch
messages: 109087
nosy: benjamin.peterson, eric.smith, ezio.melotti
priority: high
severity: normal
stage: patch review
status: open
title: Add examples for str.format()
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17833/issue9139.diff

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

From report at bugs.python.org  Fri Jul  2 06:53:42 2010
From: report at bugs.python.org (Peter Froehlich)
Date: Fri, 02 Jul 2010 04:53:42 +0000
Subject: [New-bugs-announce] [issue9140] SocketServer.BaseRequestHandler not
	a new-style class?
In-Reply-To: <1278046422.83.0.363442370038.issue9140@psf.upfronthosting.co.za>
Message-ID: <1278046422.83.0.363442370038.issue9140@psf.upfronthosting.co.za>


New submission from Peter Froehlich <peter.hans.froehlich at gmail.com>:

I tried to do this:

class Handler(SimpleHTTPRequestHandler):
  def do_GET(self):
    super(Handler, self).do_GET()
    print self.path

However super fails:

TypeError: super() argument 1 must be type, not classobj

Looking up the chain of base classes, I found that SocketServer.BaseRequestHandler is defined as follows:

class BaseRequestHandler:

No "(object)" there to make it a new-style class. I think that's wrong? BTW, in the 3.1 library it's defined the same way, but I'd assume that all classes are "new-style" in 3.1?

----------
components: Library (Lib)
messages: 109089
nosy: phf
priority: normal
severity: normal
status: open
title: SocketServer.BaseRequestHandler not a new-style class?
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Jul  2 13:30:12 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 02 Jul 2010 11:30:12 +0000
Subject: [New-bugs-announce] [issue9141] Allow objects to decide if they can
	be collected by GC
In-Reply-To: <1278070212.7.0.406390843902.issue9141@psf.upfronthosting.co.za>
Message-ID: <1278070212.7.0.406390843902.issue9141@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

The GC module currently relies only on the presence of a __del__ method to decide if an object can be safely collected at all.  Also, there is a special case for generator objects.

This patch allows any object to call an api during its traversal,
PyObject_GC_Collectable(), to indicate whether it is fit to be collected at this time, overriding any presence of a __del__ method or not.

This mechanism is being put in place in stackless python 2.7 because tasklets cannot always be collected depending on their runtime state, and I thought this might be a useful addition for regular python, especially since there already is such a dynamic special case for generator objects.

----------
components: Interpreter Core
files: gc_collectable.patch
keywords: needs review, patch, patch
messages: 109099
nosy: krisvale
priority: normal
severity: normal
status: open
title: Allow objects to decide if they can be collected by GC
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file17838/gc_collectable.patch

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

From report at bugs.python.org  Fri Jul  2 14:22:48 2010
From: report at bugs.python.org (rajesh)
Date: Fri, 02 Jul 2010 12:22:48 +0000
Subject: [New-bugs-announce] [issue9142] while executing python
In-Reply-To: <1278073368.88.0.141531066285.issue9142@psf.upfronthosting.co.za>
Message-ID: <1278073368.88.0.141531066285.issue9142@psf.upfronthosting.co.za>


New submission from rajesh <rajchasha at gmail.com>:

while executing the python file:
python sercon.py

It Displays the below error.kindly provide me the solution.

Updated the Configparser log
Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/local/lib/python2.3/lib-tk/Tkinter.py", line 1345, in __call__
    return self.func(*args)
  File "/ug6/RAJESH/finacle/TParty/lib/python2.3/site-packages/Pmw/Pmw_1_1/lib/PmwPanedWidget.py", line 307, in _handleConfigure
    self._getNaturalSizes()
  File "/ug6/RAJESH/finacle/TParty/lib/python2.3/site-packages/Pmw/Pmw_1_1/lib/PmwPanedWidget.py", line 338, in _getNaturalSizes
    bw = string.atoi(self.cget('hull_borderwidth'))
  File "/usr/local/lib/python2.3/string.py", line 220, in atoi
    return _int(s, base)
TypeError: int() can't convert non-string with explicit base
Traceback (most recent call last):
  File "sercon.py", line 264, in ?
    prodname,primaryIP,flag1 = displayScreen1(prodname,primaryIP)
  File "sercon.py", line 141, in displayScreen1
    widget = screen1.screen1(root,prodname,prodprimaryIP)
  File "/ug6/RAJESH/finacle/app/base/sercon/tools/screen1.py", line 228, in __init__
    self.panes.configurepane('IPAddresses',size = 0.35)
  File "/ug6/RAJESH/finacle/TParty/lib/python2.3/site-packages/Pmw/Pmw_1_1/lib/PmwPanedWidget.py", line 521, in configurepane
    self._handleConfigure()
  File "/ug6/RAJESH/finacle/TParty/lib/python2.3/site-packages/Pmw/Pmw_1_1/lib/PmwPanedWidget.py", line 307, in _handleConfigure
    self._getNaturalSizes()
  File "/ug6/RAJESH/finacle/TParty/lib/python2.3/site-packages/Pmw/Pmw_1_1/lib/PmwPanedWidget.py", line 338, in _getNaturalSizes
    bw = string.atoi(self.cget('hull_borderwidth'))
  File "/ug6/RAJESH/finacle/TParty/lib/python2.3/string.py", line 220, in atoi
    return _int(s, base)
TypeError: int() can't convert non-string with explicit base

----------
messages: 109103
nosy: rajesh.chandran
priority: normal
severity: normal
status: open
title: while executing python
type: compile error
versions: Python 2.5

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

From report at bugs.python.org  Fri Jul  2 14:51:31 2010
From: report at bugs.python.org (Jan Engelhardt)
Date: Fri, 02 Jul 2010 12:51:31 +0000
Subject: [New-bugs-announce] [issue9143] test_ctypes: fails on sparc64 long
	double
In-Reply-To: <1278075091.72.0.569096323766.issue9143@psf.upfronthosting.co.za>
Message-ID: <1278075091.72.0.569096323766.issue9143@psf.upfronthosting.co.za>


New submission from Jan Engelhardt <jengelh at medozas.de>:

When python is compiled with sparc64 settings (i.e. -m64), test_ctypes fails. I am not sure why this does not show up with -m32.

ares:/usr/src/packages/BUILD/Python-2.6.5> LD_LIBRARY_PATH=/usr/src/packages/BUILD/Python-2.6.5 ./python -E -tt ./Lib/test/regrtest.py -s test_ctypes
test_ctypes
test test_ctypes failed -- Traceback (most recent call last):
  File "/usr/src/packages/BUILD/Python-2.6.5/Lib/ctypes/test/test_callbacks.py", line 81, in test_longdouble
    self.check_type(c_longdouble, 3.14)
  File "/usr/src/packages/BUILD/Python-2.6.5/Lib/ctypes/test/test_callbacks.py", line 30, in check_type
    self.failUnlessEqual(self.got_args, (-3, arg))
AssertionError: (-3, 0.0) != (-3, 3.1400000000000001)

When using "long double x = 3.14", the constant 3.14 is taken as a double, which is then converted to long double. Of course it isn't accurate. There must be something in python that doesn't generate this correctly; it should have been "long double x = 3.14L", since only the constant 3.14L expands to the full longdouble pi.

----------
components: Tests
messages: 109107
nosy: jengelh
priority: normal
severity: normal
status: open
title: test_ctypes: fails on sparc64 long double
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Jul  2 15:43:15 2010
From: report at bugs.python.org (Giuseppe Ottaviano)
Date: Fri, 02 Jul 2010 13:43:15 +0000
Subject: [New-bugs-announce] [issue9144] Import error for multiprocessing in
	2.7rc2 on Windows
In-Reply-To: <1278078195.79.0.768389993052.issue9144@psf.upfronthosting.co.za>
Message-ID: <1278078195.79.0.768389993052.issue9144@psf.upfronthosting.co.za>


New submission from Giuseppe Ottaviano <giuott at gmail.com>:

With a fresh install from python-2.7rc2.amd64.msi (rc1 is also affected) multiprocessing gives the following error:

Python 2.7rc2 (r27rc2:82154, Jun 22 2010, 21:22:29) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import multiprocessing
>>> multiprocessing.Pool()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\lib\multiprocessing\__init__.py", line 227, in Pool
    return Pool(processes, initializer, initargs, maxtasksperchild)
  File "C:\Python27\lib\multiprocessing\pool.py", line 89, in __init__
    self._setup_queues()
  File "C:\Python27\lib\multiprocessing\pool.py", line 181, in _setup_queues
    from .queues import SimpleQueue
  File "C:\Python27\lib\multiprocessing\queues.py", line 22, in <module>
    from multiprocessing.synchronize import Lock, BoundedSemaphore, Semaphore, Condition
  File "C:\Python27\lib\multiprocessing\synchronize.py", line 22, in <module>
    from multiprocessing.forking import assert_spawning, Popen
  File "C:\Python27\lib\multiprocessing\forking.py", line 158, in <module>
    from ._multiprocessing import win32, Connection, PipeConnection
ImportError: No module named _multiprocessing

I noticed that _multiprocessing.lib is not in Lib/multiprocessing/ but in libs/, so I don't know why there is a relative import here.
Changing all the occurrences to
  from _multiprocessing import ...
everything works fine.

----------
components: Library (Lib)
messages: 109109
nosy: ot
priority: normal
severity: normal
status: open
title: Import error for multiprocessing in 2.7rc2 on Windows
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul  2 19:35:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Jul 2010 17:35:19 +0000
Subject: [New-bugs-announce] [issue9145] test_coercion fails in refleak runs
In-Reply-To: <1278092119.96.0.393167431946.issue9145@psf.upfronthosting.co.za>
Message-ID: <1278092119.96.0.393167431946.issue9145@psf.upfronthosting.co.za>


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

$ ./python -m test.regrtest -uall -R 2:3 -v test_coercion
== CPython 2.7rc2+ (trunk, Jul 2 2010, 18:50:24) [GCC 4.3.2]
==   Linux-2.6.27.10-grsec-xxxx-grs-ipv4-64-x86_64-with-debian-lenny-sid little-endian
==   /home/antoine/cpython/debug/build/test_python_19672
test_coercion
test_cmptypes (test.test_coercion.CoercionTest) ... ok
test_infinite_rec_classic_classes (test.test_coercion.CoercionTest) ... ok
test_infix_binops (test.test_coercion.CoercionTest) ... ok
test_prefix_binops (test.test_coercion.CoercionTest) ... ok

----------------------------------------------------------------------
Ran 4 tests in 0.122s

OK
beginning 5 repetitions
12345
test test_coercion crashed -- <type 'exceptions.UnboundLocalError'>: local variable 'res' referenced before assignment
Traceback (most recent call last):
  File "/home/antoine/cpython/debug/Lib/test/regrtest.py", line 873, in runtest_inner
    huntrleaks)
  File "/home/antoine/cpython/debug/Lib/test/regrtest.py", line 1003, in dash_R
    run_the_test()
  File "/home/antoine/cpython/debug/Lib/test/regrtest.py", line 989, in run_the_test
    indirect_test()
  File "/home/antoine/cpython/debug/Lib/test/test_coercion.py", line 339, in test_main
    process_infix_results()
  File "/home/antoine/cpython/debug/Lib/test/test_coercion.py", line 215, in process_infix_results
    if isinstance(res[i][6], tuple):
UnboundLocalError: local variable 'res' referenced before assignment
1 test failed:
    test_coercion
[55121 refs]

----------
components: Library (Lib), Tests
messages: 109118
nosy: ezio.melotti, flox, pitrou
priority: normal
severity: normal
status: open
title: test_coercion fails in refleak runs
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul  2 21:10:10 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 02 Jul 2010 19:10:10 +0000
Subject: [New-bugs-announce] [issue9146] Segfault in hashlib in OpenSSL FIPS
	mode using	non-FIPS-compliant hashes,
	if "ssl" imported before "hashlib"
In-Reply-To: <1278097810.42.0.823869291087.issue9146@psf.upfronthosting.co.za>
Message-ID: <1278097810.42.0.823869291087.issue9146@psf.upfronthosting.co.za>


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

Having run:
  prelink --undo --all
the following works OK:
 OPENSSL_FORCE_FIPS_MODE=1 python -c "import hashlib; m = m = hashlib.md5(); m.update('abc')"

but the following segfaults:
 OPENSSL_FORCE_FIPS_MODE=1 python -c "import ssl; import hashlib; m = m = hashlib.md5(); m.update('abc')"

and the following gives the same segfault, in a simpler way (strictly speaking one shouldn't directly import _ssl, but this most directly reproduces the crash):
 OPENSSL_FORCE_FIPS_MODE=1 python -c "import _ssl; import hashlib; m = m = hashlib.md5(); m.update('abc')"

(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007fffee978736 in EVP_hash (self=0xaed3c0, vp=0x95b6a4, len=3) at /home/david/coding/python-svn/trunk-fips/Modules/_hashopenssl.c:112
#2  0x00007fffee978cb5 in EVP_update (self=0xaed3c0, args=('abc',)) at /home/david/coding/python-svn/trunk-fips/Modules/_hashopenssl.c:247
#3  0x0000000000567faa in PyCFunction_Call (func=<built-in method update of _hashlib.HASH object at remote 0xaed3c0>, arg=('abc',), kw=0x0)
    at Objects/methodobject.c:81
and the segfault is due to EVP_DigestUpdate calling through the ctx->update function pointer, which in this case is NULL.

(gdb) p self->ctx
$2 = {digest = 0x7ffff0c955a0, engine = 0x0, flags = 0, md_data = 0x0, pctx = 0x0, update = 0}

self->ctx->update == NULL and self->ctx->digest == &bad_md, as set up by:

The setup is here: (different run of gdb, so different addresses):

(gdb) bt
#0  EVP_DigestInit_ex (ctx=0x7fffecdc7b80, type=0x7fffefc6fc60, impl=0x0) at
digest.c:249
#1  0x00007fffecbc53ce in init_hashlib () at
/usr/src/debug/Python-2.6.2/Modules/_hashopenssl.c:513

#ifdef OPENSSL_FIPS
                  if (FIPS_mode())
                          {
                          if (!(type->flags & EVP_MD_FLAG_FIPS)
                           && !(ctx->flags & EVP_MD_CTX_FLAG_NON_FIPS_ALLOW))
                                  {
                                  EVPerr(EVP_F_EVP_DIGESTINIT_EX,
EVP_R_DISABLED_FOR_FIPS);
  =>                              ctx->digest = &bad_md;
                                  return 0;
                                  }
                          }
#endif

(seen on x86_64 Linux; Fedora 13, with openssl-1.0.0-1.fc13.x86_64 on SVN trunk, and on other builds)

Clearly, the Python process should not segfault or abort.

I don't think it's clear what the behavior should be here, though - how is the Python standard library to be used in conjunction with OpenSSL's FIPS mode?

>From page 18 of the OpenSSL's FIPS guide: http://ftp.openssl.org/docs/fips/UserGuide.pdf
"By?design,?the?OpenSSL?API?attempts?to?disable?non?FIPS?algorithms,?when?in?FIPS?mode,?at?the?
EVP?level?and?via?most?low?level?function?calls.??Failure?to?check?the?return?code?from?low?level?
functions?could?result?in?unexpected?behavior.??Note?also?that?sufficiently?creative?or?unusual?use?of?
the?API?may?still?allow?the?use?of?non?FIPS?algorithms.??The?non?FIPS?algorithm?disabling?is?
intended?as?a?aid?to?the?developer?in?preventing?the?accidental?use?of?non?FIPS?algorithms?in?FIPS?
mode,?and?not?as?an?absolute?guarantee.?It?is?the?responsibility?of?the?application?developer?to?
ensure?that?no?non?FIPS?algorithms?are?used?when?in?FIPS?mode."

It seems odd that the behavior of "md5" within "hashlib" can vary depending on whether "_ssl" was imported first.  Reducing surprises for the programmer suggests to me that the behavior for these two cases should be harmonized.

It also seems odd that SSL can refuse the usage of MD5 whilst other implementations exist and are available; my understanding of FIPS mode is that it's intended for locked-down environments that wish to ensure that only known-good crypto is used (and e.g. MD5 is known to be be broken for some uses, see: http://www.kb.cert.org/vuls/id/836068)

Possible approaches:
  (A) change hashlib so that it continues to support md5 if ssl/_ssl is imported first, even in FIPS mode
  (B) change hashlib so that in FIPS mode, it fails to support md5 even if ssl/_ssl is not imported first
    (B.1) by not recognizing "md5" as a digest, leading to NameError exceptions and similar (I dislike this approach, as it leads to obscure failures)
    (B.2) by raising a new exception e.g. "ProhibitedInFIPSMode" or somesuch (so that the failure is obvious and searchable)
  (C.*) as per (B.*), but support an explicit override: hashlib.md5(non_fips_allow=True)

Thoughts?

----------
components: Library (Lib)
messages: 109121
nosy: dmalcolm
priority: normal
severity: normal
status: open
title: Segfault in hashlib in OpenSSL FIPS mode using non-FIPS-compliant hashes, if "ssl" imported before "hashlib"
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Sat Jul  3 09:42:42 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 03 Jul 2010 07:42:42 +0000
Subject: [New-bugs-announce] [issue9147] dis.show_code() variant that
	accepts source strings (and	returns rather than prints)
In-Reply-To: <1278142962.3.0.213920811411.issue9147@psf.upfronthosting.co.za>
Message-ID: <1278142962.3.0.213920811411.issue9147@psf.upfronthosting.co.za>


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

Add a new API in the dis module that:

1. Works like show_code() but returns a string rather than printing to stdout
2. Accepts source strings directly, similar to the dis.dis() changes for 3.2

Tentative name: get_code_info()

Inspired by Yanov Aknin's ssc() utility and the issue 6507 updates to dis.dis()

----------
assignee: ncoghlan
components: Library (Lib)
messages: 109161
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: dis.show_code() variant that accepts source strings (and returns rather than prints)
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Sat Jul  3 13:29:35 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 03 Jul 2010 11:29:35 +0000
Subject: [New-bugs-announce] [issue9148] os.execve puts process to
	background on windows
In-Reply-To: <1278156575.44.0.771660264126.issue9148@psf.upfronthosting.co.za>
Message-ID: <1278156575.44.0.771660264126.issue9148@psf.upfronthosting.co.za>


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

os.execve() is said to replace current process with new program. Unfortunately, when you try to call script that contains os.execve() on windows - that script spawns background process and control is immediately returned to the calling program. Does it behave the same on Unix?

Is there any way to replace current process on Windows so that references to calling parent process are not lost and it could wait for execution to complete?

----------
components: Library (Lib)
messages: 109176
nosy: techtonik
priority: normal
severity: normal
status: open
title: os.execve puts process to background on windows
versions: Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Jul  3 14:33:02 2010
From: report at bugs.python.org (David Hood)
Date: Sat, 03 Jul 2010 12:33:02 +0000
Subject: [New-bugs-announce] [issue9149] colorsys.py function rgb_to_hls
In-Reply-To: <1278160382.92.0.847390863693.issue9149@psf.upfronthosting.co.za>
Message-ID: <1278160382.92.0.847390863693.issue9149@psf.upfronthosting.co.za>


New submission from David Hood <thoughtfulbloke at gmail.com>:

colorsys.py function rgb_to_hls will crash on the RGB color (0,2,1) on line 68 with a division by zero error.
68 else: s = (maxc-minc) / (2.0-maxc-minc)

----------
messages: 109181
nosy: David.Hood
priority: normal
severity: normal
status: open
title: colorsys.py function rgb_to_hls
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Sat Jul  3 19:59:05 2010
From: report at bugs.python.org (Ryan Hodin)
Date: Sat, 03 Jul 2010 17:59:05 +0000
Subject: [New-bugs-announce] [issue9150] IDLE should not save trailing
	whitespace after strip	trailing whitespace has been used
In-Reply-To: <1278179945.62.0.903425904075.issue9150@psf.upfronthosting.co.za>
Message-ID: <1278179945.62.0.903425904075.issue9150@psf.upfronthosting.co.za>


New submission from Ryan Hodin <ryan201078 at ymail.com>:

I commonly use IDLE to create very large files. this annoys me a little, but it takes up hard disk space and is unnessesary

----------
components: IDLE
messages: 109186
nosy: rhprogrammer
priority: normal
severity: normal
status: open
title: IDLE should not save trailing whitespace after strip trailing whitespace has been used
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Sat Jul  3 22:52:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 03 Jul 2010 20:52:29 +0000
Subject: [New-bugs-announce] [issue9151] Demo/classes/Dates.py does not work
	in 3.x
Message-ID: <1278190349.61.0.933581518071.issue9151@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee: belopolsky
components: Demos and Tools
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: Demo/classes/Dates.py does not work in 3.x
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Jul  4 05:39:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 04 Jul 2010 03:39:25 +0000
Subject: [New-bugs-announce] [issue9152] Dead code in datetime module
In-Reply-To: <1278214765.19.0.475716851207.issue9152@psf.upfronthosting.co.za>
Message-ID: <1278214765.19.0.475716851207.issue9152@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Apparently introduced by a wholesale elimination of PyString_ in r57374, the else clause in the following snippet from call_tzname is redundant:



        if (!PyUnicode_Check(result)) {
            PyErr_Format(PyExc_TypeError, "tzinfo.tzname() must "
                         "return None or a string, not '%s'",
                         Py_TYPE(result)->tp_name);
            Py_DECREF(result);
            result = NULL;
        }
        else if (!PyUnicode_Check(result)) {
            PyObject *temp = PyUnicode_FromObject(result);
            Py_DECREF(result);
            result = temp;
        }

----------
assignee: belopolsky
components: Extension Modules
keywords: easy
messages: 109203
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Dead code in datetime module
type: resource usage
versions: Python 3.2

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

From report at bugs.python.org  Sun Jul  4 17:31:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 04 Jul 2010 15:31:13 +0000
Subject: [New-bugs-announce] [issue9153] Run tests and demos as part of the
	test suite
In-Reply-To: <1278257473.49.0.485349644123.issue9153@psf.upfronthosting.co.za>
Message-ID: <1278257473.49.0.485349644123.issue9153@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I propose than tests and demos be run during the test suite, as a sanity check to prevent them getting badly out of sync (see ?Signs of neglect thread?? starting at http://mail.python.org/pipermail/python-dev/2010-June/101092.html)

Is this a good idea?

----------
components: Demos and Tools, Tests
messages: 109227
nosy: merwok
priority: low
severity: normal
status: open
title: Run tests and demos as part of the test suite
versions: Python 3.2

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

From report at bugs.python.org  Sun Jul  4 21:03:24 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Jul 2010 19:03:24 +0000
Subject: [New-bugs-announce] [issue9154] Parser module doesn't understand
	function annotations.
In-Reply-To: <1278270204.2.0.0990664909847.issue9154@psf.upfronthosting.co.za>
Message-ID: <1278270204.2.0.0990664909847.issue9154@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Python 3.2a0 (py3k:82529M, Jul  4 2010, 17:35:10) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import parser
[38213 refs]
>>> parser.sequence2st(parser.suite("def f(a:int) -> int: pass").totuple())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
parser.ParserError: VALIDATION FAILURE: report this to the maintainer!
[38264 refs]

----------
assignee: mark.dickinson
components: Extension Modules
messages: 109256
nosy: mark.dickinson
priority: normal
severity: normal
stage: unit test needed
status: open
title: Parser module doesn't understand function annotations.
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Jul  4 21:54:01 2010
From: report at bugs.python.org (Demur Rumed)
Date: Sun, 04 Jul 2010 19:54:01 +0000
Subject: [New-bugs-announce] [issue9155] Reserve COMPARE_OP for
	RichComparisons
In-Reply-To: <1278273241.45.0.419435390146.issue9155@psf.upfronthosting.co.za>
Message-ID: <1278273241.45.0.419435390146.issue9155@psf.upfronthosting.co.za>


New submission from Demur Rumed <junkmute at hotmail.com>:

Currently, COMPARE_OP is burdened by a needless, and unorthogonal, extra layer of indirection. I've modified it to only handle the rich comparison case, moving the other five cases to BINARY_IN, BINARY_NOT_IN, BINARY_IS, BINARY_IS_NOT, and BINARY_EXC_MATCH

To consider is inlining the POP_JUMP_IF_FALSE POP_TOP which always follow BINARY_EXC_MATCH

----------
components: Interpreter Core
files: cmpoppatch.diff
keywords: patch
messages: 109259
nosy: serprex
priority: normal
severity: normal
status: open
title: Reserve COMPARE_OP for RichComparisons
type: performance
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17855/cmpoppatch.diff

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

From report at bugs.python.org  Mon Jul  5 03:21:35 2010
From: report at bugs.python.org (=?utf-8?q?Mathias_Panzenb=C3=B6ck?=)
Date: Mon, 05 Jul 2010 01:21:35 +0000
Subject: [New-bugs-announce] [issue9156] socket._fileobject: read raises
	AttributeError when	closed in another thread
In-Reply-To: <1278292895.39.0.187416203103.issue9156@psf.upfronthosting.co.za>
Message-ID: <1278292895.39.0.187416203103.issue9156@psf.upfronthosting.co.za>


New submission from Mathias Panzenb?ck <grosser.meister.morti at gmx.net>:

When you open a socket._fileobject through sock.makefile('rb') or similar and you read blocking in one thread and close the file object from another thread the reading thread gets an AttributeError. This is because the close method sets the underlying fileobject._sock member to None and the read/readline/... methods call recv on this member without checking if its None. I think the _sock member should not be set to None at all but a flag should be set that this file object is closed.

For the time being I use the "bugfix" I attached and therefore do not call sock.makefile('rb') but FileObject(sock, 'rb'). FileObject is a subtype of socket._fileobject that overrides the close method and closed property.

I don't know if this bug persists in 2.7 or 3.x. I still use Fedora 12 and that comes with Python 2.6.2.

----------
components: Library (Lib)
files: FileObject.py
messages: 109281
nosy: panzi
priority: normal
severity: normal
status: open
title: socket._fileobject: read raises AttributeError when closed in another thread
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file17860/FileObject.py

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

From report at bugs.python.org  Mon Jul  5 03:28:15 2010
From: report at bugs.python.org (Mitar)
Date: Mon, 05 Jul 2010 01:28:15 +0000
Subject: [New-bugs-announce] [issue9157] Allow inspection of used decorators
	on a function
In-Reply-To: <1278293295.3.0.202692223524.issue9157@psf.upfronthosting.co.za>
Message-ID: <1278293295.3.0.202692223524.issue9157@psf.upfronthosting.co.za>


New submission from Mitar <mmitar at gmail.com>:

Sometimes it is useful to be able to check which decorators are already applied to a function, especially when you are constructing them dynamically. I am proposing that for all decorators in Python would be suggested that they maintain a list of used decorators on a function. It is most useful when all decorators do this.

It is the same reasoning why `inspect` module is in Python - to be able to inspect Python structures, to have this possibility. If you do not want it then you do can use Python structures as they were given to you. But you have an option to inspect them.

And I would like the same to see from decorators. It is not really so important that all decorators update this. If they would not then they would be hidden from inspection. But if developer wants to use inspection then he would choose such decorators which use this (or change them in this way). If all default Python's decorators would already be such it would be much easier to use them.

This could be implement by changing `wraps` function to pass over also the (for example) `__DECORATORS__` attribute of a function to a wrapped function and add this new decorator to a list, `__DECORATORS__`.

By default in a list ids of decorators would be maintained, but this could be overridden by `id` attribute of `wraps` function so that decorator can represent itself in some special way, for example as a tuple of its id and some significant parameters.

----------
messages: 109283
nosy: mitar
priority: normal
severity: normal
status: open
title: Allow inspection of used decorators on a function
type: feature request

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

From report at bugs.python.org  Mon Jul  5 03:44:21 2010
From: report at bugs.python.org (Terrence Cole)
Date: Mon, 05 Jul 2010 01:44:21 +0000
Subject: [New-bugs-announce] [issue9158] PyArg_ParseTuple y* documentation
	is incorrect
In-Reply-To: <1278294261.08.0.252772210981.issue9158@psf.upfronthosting.co.za>
Message-ID: <1278294261.08.0.252772210981.issue9158@psf.upfronthosting.co.za>


New submission from Terrence Cole <terrence at zettabytestorage.com>:

The documented C type for y* should be [Py_buffer], not [Py_buffer *], as with the documentation for z* and the convention followed by the other types.

I'm not sure what 'type' this issue should have.  I've set it at 'crash' initially, since that's how the bug manifested for me.

----------
assignee: docs at python
components: Documentation
files: PyArgs_ParseTuple_ystar_doc_fix.patch
keywords: patch
messages: 109285
nosy: docs at python, terrence
priority: normal
severity: normal
status: open
title: PyArg_ParseTuple y* documentation is incorrect
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file17862/PyArgs_ParseTuple_ystar_doc_fix.patch

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

From report at bugs.python.org  Mon Jul  5 04:26:53 2010
From: report at bugs.python.org (kimhyunkang)
Date: Mon, 05 Jul 2010 02:26:53 +0000
Subject: [New-bugs-announce] [issue9159] asyncore.file_wrapper does not
	register its fd to	socket_map
In-Reply-To: <1278296813.27.0.585763714278.issue9159@psf.upfronthosting.co.za>
Message-ID: <1278296813.27.0.585763714278.issue9159@psf.upfronthosting.co.za>


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

In current stable python 2.6, the test code below does nothing, which is inconsistent with other default dispatcher's behavior.

========

import asyncore

class test_reader(asyncore.file_wrapper)
  def writable(self):
    return False

  def handle_read(self):
    print self.recv(4096)

f = open('test.dat', 'r')
reader = test_reader(f.fileno())

asyncore.loop()

----------
components: Library (Lib)
messages: 109287
nosy: kimhyunkang
priority: normal
severity: normal
status: open
title: asyncore.file_wrapper does not register its fd to socket_map
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Jul  5 05:27:59 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 05 Jul 2010 03:27:59 +0000
Subject: [New-bugs-announce] [issue9160] Documentation link of 3.2 not
	working at docs.python.org
In-Reply-To: <1278300479.72.0.619696598543.issue9160@psf.upfronthosting.co.za>
Message-ID: <1278300479.72.0.619696598543.issue9160@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

This link: http://docs.python.org/dev/py3k/

Isn't working. I have always used it to see the latest documentation from 3.2, and it is linked in the left-hand side of the screen on docs.python.org as "Python 3.2 (in development)" under "Docs for other versions" if you're, for example here: http://docs.python.org/py3k/

----------
assignee: docs at python
components: Documentation
messages: 109289
nosy: docs at python, eliben
priority: normal
severity: normal
status: open
title: Documentation link of 3.2 not working at docs.python.org
versions: Python 3.2

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

From report at bugs.python.org  Mon Jul  5 07:36:32 2010
From: report at bugs.python.org (Craig McQueen)
Date: Mon, 05 Jul 2010 05:36:32 +0000
Subject: [New-bugs-announce] [issue9161] add_option in optparse no longer
	accepts unicode string
In-Reply-To: <1278308192.07.0.362660691035.issue9161@psf.upfronthosting.co.za>
Message-ID: <1278308192.07.0.362660691035.issue9161@psf.upfronthosting.co.za>


New submission from Craig McQueen <python at craig.mcqueen.id.au>:

Working in Japan, I find it very helpful to be able to read full Unicode arguments in Python 2.x under Windows 2000/XP. So I am using the following:

http://stackoverflow.com/questions/846850/how-to-read-unicode-characters-from-command-line-arguments-in-python-on-windows/846931#846931

Brilliantly, the optparse module in Python 2.6 has worked fine with Unicode arguments. Sadly, it seems Python 2.7 is preventing this. When I try to run my program with Python 2.7, I get the following:

  ...
  File "c:\python27\lib\optparse.py", line 1018, in add_option
    raise TypeError, "invalid arguments"
TypeError: invalid arguments

It seems that the type check in optparse.py line 1018 has changed from this in 2.6:
    if type(args[0]) in types.StringTypes:

to this in 2.7:
    if type(args[0]) is types.StringType:

This makes it more difficult to support Unicode in 2.7, compared to 2.6. Any chance this could be reverted?

----------
messages: 109300
nosy: cmcqueen1975
priority: normal
severity: normal
status: open
title: add_option in optparse no longer accepts unicode string
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul  5 08:34:47 2010
From: report at bugs.python.org (Michael Fladischer)
Date: Mon, 05 Jul 2010 06:34:47 +0000
Subject: [New-bugs-announce] [issue9162] License for multiprocessing files
In-Reply-To: <1278311687.0.0.315948028382.issue9162@psf.upfronthosting.co.za>
Message-ID: <1278311687.0.0.315948028382.issue9162@psf.upfronthosting.co.za>


New submission from Michael Fladischer <michael at fladi.at>:

The files in Lib/multiprocessing (except __init__.py) are referring to their license by point to a nonexistent file called COPYING.txt.

This possibly needs clarification as if this file is missing or the license is to be found somewhere else.

----------
components: Library (Lib)
messages: 109306
nosy: FladischerMichael
priority: normal
severity: normal
status: open
title: License for multiprocessing files

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

From report at bugs.python.org  Mon Jul  5 09:27:42 2010
From: report at bugs.python.org (Michael Blume)
Date: Mon, 05 Jul 2010 07:27:42 +0000
Subject: [New-bugs-announce] [issue9163] test_gdb fails
In-Reply-To: <1278314862.38.0.121904956787.issue9163@psf.upfronthosting.co.za>
Message-ID: <1278314862.38.0.121904956787.issue9163@psf.upfronthosting.co.za>


New submission from Michael Blume <blume.mike at gmail.com>:

After building Python 2.7 on two separate X68 Ubuntu boxes, test_gdb failed both times.

./configure
make
make test

output follows:


test_gdb
test test_gdb failed -- Traceback (most recent call last):
  File "/home/mike/workspace/Python-2.7/Lib/test/test_gdb.py", line 637, in test_basic_command
    ''')
  File "/home/mike/workspace/Python-2.7/Lib/test/test_gdb.py", line 163, in assertMultilineMatches
    msg='%r did not match %r' % (actual, pattern))
AssertionError: 'Breakpoint 1 at 0x80957d6: file Objects/object.c, line 329.\n[Thread debugging using libthread_db enabled]\n\nBreakpoint 1, PyObject_Print (op=42, fp=0x401cf4e0, flags=1) at Objects/object.c:329\n329\t{\n#3 Frame 0x81e322c, for file /home/mike/workspace/Python-2.7/Lib/test/gdb_sample.py, line 10, in baz (args=(1, 2, 3))\n    print(42)\n#7 (unable to read python frame information)\n#10 Frame 0x81d5544, for file /home/mike/workspace/Python-2.7/Lib/test/gdb_sample.py, line 7, in bar (a=1, b=2, c=3)\n    baz(a, b, c)\n#13 Frame 0x81d53dc, for file /home/mike/workspace/Python-2.7/Lib/test/gdb_sample.py, line 4, in foo (a=1, b=2, c=3)\n    bar(a, b, c)\n' did not match '^.*\n#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 7, in bar \\(a=1, b=2, c=3\\)\n    baz\\(a, b, c\\)\n#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 4, in foo \\(a=1, b=2, c=3\\)\n    bar\\(a, b, c\\)\n#[0-9]+ Frame 0x[0-9a-f]+, for file .*gdb_sample.py, line 12, in <module> \\(\\)\nfoo\\(1, 2, 3\\)\n'

machines have the following packages installed, with the following versions:
gdb 7.1-1ubuntu2
libgdb-dev 7.1-1ubuntu2

----------
components: Tests
messages: 109311
nosy: Michael.Blume
priority: normal
severity: normal
status: open
title: test_gdb fails
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul  5 11:46:59 2010
From: report at bugs.python.org (Jyrki Wahlstedt)
Date: Mon, 05 Jul 2010 09:46:59 +0000
Subject: [New-bugs-announce] [issue9164] 2.7 sysconfig should handle arch
	duplicates
In-Reply-To: <1278323219.73.0.148043211343.issue9164@psf.upfronthosting.co.za>
Message-ID: <1278323219.73.0.148043211343.issue9164@psf.upfronthosting.co.za>


New submission from Jyrki Wahlstedt <jyrki.wahlstedt at wahlstedt.fi>:

Hi,
in building Python 2.7 (using MacPorts)I end up in a situation that the build stops in sysconfig.py due to duplicate arch args on compile line. Compiling stops, because there is no way to find machine value from ('i386', 'i386', 'x86_64', 'x86_64'). The duplicates should be removed so that findall-sort-tuple would give only the unique values.

----------
components: Build
messages: 109314
nosy: jyrkiwahlstedt
priority: normal
severity: normal
status: open
title: 2.7 sysconfig should handle arch duplicates
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul  5 17:16:48 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 05 Jul 2010 15:16:48 +0000
Subject: [New-bugs-announce] [issue9165] Add math.isfinite()
In-Reply-To: <1278343008.96.0.366805630513.issue9165@psf.upfronthosting.co.za>
Message-ID: <1278343008.96.0.366805630513.issue9165@psf.upfronthosting.co.za>


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

It would be equivalent to "not isinf(x) and not isnan(x)".

----------
components: Extension Modules
messages: 109324
nosy: benjamin.peterson
priority: low
severity: normal
status: open
title: Add math.isfinite()
versions: Python 3.2

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

From report at bugs.python.org  Mon Jul  5 17:32:31 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 05 Jul 2010 15:32:31 +0000
Subject: [New-bugs-announce] [issue9166] minor misstatement in What's New in
	2.7
In-Reply-To: <1278343951.02.0.221627534967.issue9166@psf.upfronthosting.co.za>
Message-ID: <1278343951.02.0.221627534967.issue9166@psf.upfronthosting.co.za>


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

"Finally, the Mapping abstract base class now raises a NotImplemented exception..."

should read "returns" instead of "raises"

Here's the relevant code patch:
http://svn.python.org/view/python/trunk/Lib/_abcoll.py?r1=78800&r2=81414&pathrev=81414

----------
assignee: docs at python
components: Documentation
keywords: patch
messages: 109327
nosy: docs at python, stutzbach
priority: normal
severity: normal
stage: patch review
status: open
title: minor misstatement in What's New in 2.7
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul  5 18:07:54 2010
From: report at bugs.python.org (Daniele Varrazzo)
Date: Mon, 05 Jul 2010 16:07:54 +0000
Subject: [New-bugs-announce] [issue9167] argv double encoding on OSX
In-Reply-To: <1278346074.17.0.914375109611.issue9167@psf.upfronthosting.co.za>
Message-ID: <1278346074.17.0.914375109611.issue9167@psf.upfronthosting.co.za>


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

Looks like the wchar_t* array returned by Py_GetArgcArgv() on OSX suffers by double encoding. This can affect sys.argv, sys.executable and C code relying on the above function of course.

On Linux:

$ python3
Python 3.0rc1+ (py3k, Oct 28 2008, 09:22:29) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, sys
>>> snowman = '\u2603'
>>> os.system(sys.executable + " -c 'import sys; [print(a.encode(\"utf8\")) for a in sys.argv]' foo bar " + snowman)
b'-c'
b'foo'
b'bar'
b'\xe2\x98\x83'
0

On OSX (uname -a is Darwin comicbookguy.local 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386)

$ python3
Python 3.1.2 (r312:79147, Jul  5 2010, 11:57:14) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, sys
>>> snowman = '\u2603'
>>> os.system(sys.executable + " -c 'import sys; [print(a.encode(\"utf8\")) for a in sys.argv]' foo bar " + snowman)
b'-c'
b'foo'
b'bar'
b'\xc3\xa2\xc2\x98\xc2\x83'
0

Is this a known limitation of the platform? I don't know much about OSX, just found it testing for regressions in setproctitle <http://code.google.com/p/py-setproctitle/>

Reported correctly working on Windows.

----------
components: Interpreter Core
messages: 109333
nosy: piro
priority: normal
severity: normal
status: open
title: argv double encoding on OSX
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Jul  5 18:20:41 2010
From: report at bugs.python.org (Alberto Trevino)
Date: Mon, 05 Jul 2010 16:20:41 +0000
Subject: [New-bugs-announce] [issue9168] setuid in smtp.py sheds privileges
	before binding port
In-Reply-To: <1278346841.06.0.147409219565.issue9168@psf.upfronthosting.co.za>
Message-ID: <1278346841.06.0.147409219565.issue9168@psf.upfronthosting.co.za>


New submission from Alberto Trevino <alberto at byu.edu>:

The SMTP proxy server in Python (smtpd.py) allows you to shed privileges and run as user nobody. However, if you are trying to use port 25, the server will shed privileges before binding the port, causing a bind failure. By moving the setuid code between the creation of the proxy server and the aysncore loop, we can bind a port below 1024 and run as nobody.

----------
components: Library (Lib)
files: smtpd.py-0.2-setuid-fix.diff
keywords: patch
messages: 109336
nosy: alfmel, barry
priority: normal
severity: normal
status: open
title: setuid in smtp.py sheds privileges before binding port
versions: Python 3.2
Added file: http://bugs.python.org/file17871/smtpd.py-0.2-setuid-fix.diff

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

From report at bugs.python.org  Mon Jul  5 19:07:30 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 05 Jul 2010 17:07:30 +0000
Subject: [New-bugs-announce] [issue9169] Deprecate use of more than 3
	positional arguments in	timedelta constructor
In-Reply-To: <1278349650.72.0.868837064663.issue9169@psf.upfronthosting.co.za>
Message-ID: <1278349650.72.0.868837064663.issue9169@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Prior to r82454, python implementation of timedelta had the following comment:

class timedelta:
     def __new__(cls, days=0, seconds=0, microseconds=0,
                 # XXX The following should only be used as keyword args:	 
                 milliseconds=0, minutes=0, hours=0, weeks=0):


This suggests that these arguments were intended to be keyword only, but at the time there was no language support for that.

In 3.x, the above can be rewritten as

class timedelta:
     def __new__(cls, days=0, seconds=0, microseconds=0, *,
                 milliseconds=0, minutes=0, hours=0, weeks=0):

to require that milliseconds, minutes, etc, be used only positionally.

This would be a backward incompatible change, so it would need to go through a deprecation process, but I think someone writing

HOUR = timedelta(0, 0, 0, 0, 0, 1)

or

WEEK = timedelta(0, 0, 0, 0, 0, 0, 1)

deserves a deprecation warning.

----------
assignee: belopolsky
messages: 109339
nosy: belopolsky, mark.dickinson, pitrou, tim_one
priority: normal
severity: normal
stage: unit test needed
status: open
title: Deprecate use of more than 3 positional arguments in timedelta constructor
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Mon Jul  5 19:42:23 2010
From: report at bugs.python.org (Andrew Miller)
Date: Mon, 05 Jul 2010 17:42:23 +0000
Subject: [New-bugs-announce] [issue9170] zipfile.extractall raises runtime
	error on correct	password
In-Reply-To: <1278351743.73.0.460439084815.issue9170@psf.upfronthosting.co.za>
Message-ID: <1278351743.73.0.460439084815.issue9170@psf.upfronthosting.co.za>


New submission from Andrew Miller <aymill at gmail.com>:

On a WinZip AES-256 encrypted zip, zipfile.extractall raises a RuntimeError for "Bad password for file" when given the correct password. Command line example below:

Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from zipfile import ZipFile
>>> zip = ZipFile("example.zip", "r")
>>> zip.extractall(".", pwd="cat")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/zipfile.py", line 935, in extractall
    self.extract(zipinfo, path, pwd)
  File "/usr/lib/python2.6/zipfile.py", line 923, in extract
    return self._extract_member(member, path, pwd)
  File "/usr/lib/python2.6/zipfile.py", line 963, in _extract_member
    source = self.open(member, pwd=pwd)
  File "/usr/lib/python2.6/zipfile.py", line 898, in open
    raise RuntimeError("Bad password for file", name)
RuntimeError: ('Bad password for file', <zipfile.ZipInfo object at 0xb739e26c>)
>>>

----------
components: Library (Lib)
files: example.zip
messages: 109342
nosy: aymill
priority: normal
severity: normal
status: open
title: zipfile.extractall raises runtime error on correct password
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file17872/example.zip

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

From report at bugs.python.org  Mon Jul  5 19:45:10 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 05 Jul 2010 17:45:10 +0000
Subject: [New-bugs-announce] [issue9171] sysconfig module does not support
	-m option
In-Reply-To: <1278351910.01.0.446224296064.issue9171@psf.upfronthosting.co.za>
Message-ID: <1278351910.01.0.446224296064.issue9171@psf.upfronthosting.co.za>


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

http://docs.python.org/dev/library/sysconfig.html#using-sysconfig-as-a-script

The doc states that sysconfig module con be used with python's -m option but this doesn't work:

giampaolo at ubuntu:~/svn/python-2.7$ python -m sysconfig
giampaolo at ubuntu:~/svn/python-2.7$ 

By taking a look at the code it seems that the module doesn't contain any main() or similar function.

----------
messages: 109343
nosy: giampaolo.rodola, tarek, tarek-ziade
priority: normal
severity: normal
status: open
title: sysconfig module does not support -m option
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Jul  5 20:37:11 2010
From: report at bugs.python.org (Andrew Miller)
Date: Mon, 05 Jul 2010 18:37:11 +0000
Subject: [New-bugs-announce] [issue9172] zipfile.extractall always raises an
	OSError after	successfully unzipping all files
In-Reply-To: <1278355031.26.0.155948134842.issue9172@psf.upfronthosting.co.za>
Message-ID: <1278355031.26.0.155948134842.issue9172@psf.upfronthosting.co.za>


New submission from Andrew Miller <aymill at gmail.com>:

Tried it with a variety of unencrypted zips. Zipped with WinZip 11.1. Looks like it tries to unzip a second time after it completes the first unzip.

Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from zipfile import ZipFile
>>> zip = ZipFile("example_1.zip")
>>> zip.extractall()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/zipfile.py", line 935, in extractall
    self.extract(zipinfo, path, pwd)
  File "/usr/lib/python2.6/zipfile.py", line 923, in extract
    return self._extract_member(member, path, pwd)
  File "/usr/lib/python2.6/zipfile.py", line 960, in _extract_member
    os.mkdir(targetpath)
OSError: [Errno 17] File exists: '/home/andy/projects/codedropvalidator/testdata/example'
>>>

----------
files: example_1.zip
messages: 109346
nosy: aymill
priority: normal
severity: normal
status: open
title: zipfile.extractall always raises an OSError after successfully unzipping all files
type: behavior
Added file: http://bugs.python.org/file17873/example_1.zip

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

From report at bugs.python.org  Tue Jul  6 02:05:00 2010
From: report at bugs.python.org (Paul Smith)
Date: Tue, 06 Jul 2010 00:05:00 +0000
Subject: [New-bugs-announce] [issue9173] logger statement not guarded in
	shutil._make_tarball
In-Reply-To: <1278374700.0.0.888108186461.issue9173@psf.upfronthosting.co.za>
Message-ID: <1278374700.0.0.888108186461.issue9173@psf.upfronthosting.co.za>


New submission from Paul Smith <paulsmith at pobox.com>:

A called to logger.info() in shutil._make_tarball is not guarded against the logger being None, and therefore raises an AttributeError if that is the case.

----------
components: Library (Lib)
files: shutil_logger_py27.patch
keywords: patch
messages: 109364
nosy: paulsmith
priority: normal
severity: normal
status: open
title: logger statement not guarded in shutil._make_tarball
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file17878/shutil_logger_py27.patch

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

From report at bugs.python.org  Tue Jul  6 06:02:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 06 Jul 2010 04:02:17 +0000
Subject: [New-bugs-announce] [issue9174] unittest assertEqual error output
	sub-optimal for single	strings
In-Reply-To: <1278388937.66.0.26708370086.issue9174@psf.upfronthosting.co.za>
Message-ID: <1278388937.66.0.26708370086.issue9174@psf.upfronthosting.co.za>


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

When assertEqual is called on a pair of strings, then in Python3 assertMultiLineEqual is called.  This function calls ndiff to display a nicely formatted multiline comparison of the strings, which would make it very easy to spot the differences...if it worked.  However, ndiff does not add newlines where they do not exist, so the output is not correctly formatted when strings without newlines are compared.

Attached is a unit test and patch.

This fix should be backported to 2.7, since assertMultiLineEqual is used there for unicode strings.

Assigning to Michael Foord for review.  Michael, you can assign it back to me if you'd like me to commit it.

----------
assignee: michael.foord
components: Library (Lib)
files: unittest_assertEquals.patch
keywords: patch
messages: 109365
nosy: michael.foord, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: unittest assertEqual error output sub-optimal for single strings
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17879/unittest_assertEquals.patch

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

From report at bugs.python.org  Tue Jul  6 11:15:36 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 06 Jul 2010 09:15:36 +0000
Subject: [New-bugs-announce] [issue9175] ctypes doesn't build on hp-ux
In-Reply-To: <1278407736.6.0.642117116261.issue9175@psf.upfronthosting.co.za>
Message-ID: <1278407736.6.0.642117116261.issue9175@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

During the build of python2.7 on a HP-UX machine I get this compile error when building the ctypes extension:

cc -Ae +z -Olimit 1500 -g -DNDEBUG -O -Ibuild/temp.hp-ux-B.11.23-9000-800-2.7/libffi/include -Ibuild/temp.hp-ux-B.11.23-9000-800-2.7/libffi -I/home/xsupport/bld/Python-2.7/Modules/_ctypes/libffi/src -I/opt/python2.7/include -I. -IInclude -I./Include -I/home/xsupport/bld/Python-2.7/Include -I/home/xsupport/bld/Python-2.7 -c /home/xsupport/bld/Python-2.7/Modules/_ctypes/_ctypes.c -o build/temp.hp-ux-B.11.23-9000-800-2.7/home/xsupport/bld/Python-2.7/Modules/_ctypes/_ctypes.o
cpp: "build/temp.hp-ux-B.11.23-9000-800-2.7/libffi/include/ffi.h", line 133: error 4044: Constant literal too large.
cpp: "build/temp.hp-ux-B.11.23-9000-800-2.7/libffi/include/ffi.h", line 134: error 4062: "no 64-bit data type supported"

Compiler version:

  B9007AA               C.11.23.12     HP C/aC++ Developer's Bundle 

System info:


HP-UX ah006b02 B.11.23 U 9000/800 2284397887 unlimited-user license

----------
assignee: theller
components: Build, ctypes
messages: 109374
nosy: ronaldoussoren, theller
priority: normal
severity: normal
status: open
title: ctypes doesn't build on hp-ux
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Tue Jul  6 11:51:26 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 06 Jul 2010 09:51:26 +0000
Subject: [New-bugs-announce] [issue9176] module termios doesn't build on
	HP-UX
In-Reply-To: <1278409886.91.0.742762759895.issue9176@psf.upfronthosting.co.za>
Message-ID: <1278409886.91.0.742762759895.issue9176@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

I get the following error when building the termios module on HP-UX:


cc -Ae +z -Olimit 1500 -g -DNDEBUG -O -I/opt/python2.7/include -I. -IInclude -I./Include -I/home/xsupport/bld/Python-2.7/Include -I/home/xsupport/bld/Python-2.7 -c /home/xsupport/bld/Python-2.7/Modules/termios.c -o build/temp.hp-ux-B.11.23-9000-800-2.7/home/xsupport/bld/Python-2.7/Modules/termios.o
cc: "/home/xsupport/bld/Python-2.7/Modules/termios.c", line 75: error 1574: Unknown size for "mode".
cc: "/home/xsupport/bld/Python-2.7/Modules/termios.c", line 96: error 1530: Undefined struct or union.
cc: "/home/xsupport/bld/Python-2.7/Modules/termios.c", line 96: error 1527: Incompatible types in cast: Must cast from scalar to scalar or to void type.
cc: "/home/xsupport/bld/Python-2.7/Modules/termios.c", line 106: error 1530: Undefined struct or union.


(The line numbers are off by 3 due to an experiment that doesn't affect the error message beyond the linenumbers).



Compiler version:

  B9007AA               C.11.23.12     HP C/aC++ Developer's Bundle 

System info:


HP-UX ah006b02 B.11.23 U 9000/800 2284397887 unlimited-user license

----------
components: Build
messages: 109378
nosy: ronaldoussoren
priority: normal
severity: normal
status: open
title: module termios doesn't build on HP-UX
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Tue Jul  6 11:53:00 2010
From: report at bugs.python.org (Cyril)
Date: Tue, 06 Jul 2010 09:53:00 +0000
Subject: [New-bugs-announce] [issue9177] ssl.read/write on closed socket
	raises AttributeError
In-Reply-To: <1278409980.47.0.00506027612669.issue9177@psf.upfronthosting.co.za>
Message-ID: <1278409980.47.0.00506027612669.issue9177@psf.upfronthosting.co.za>


New submission from Cyril <cbay at excellency.fr>:

This:

import socket, ssl

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
ssl_sock = ssl.wrap_socket(s)
ssl_sock.connect(('www.verisign.com', 443))
ssl_sock.close()
ssl_sock.read(1024)

raises:

Traceback (most recent call last):
  File "/tmp/bug.py", line 10, in <module>
    ssl_sock.read(1024)
  File "/path/to/lib/python2.7/ssl.py", line 138, in read
    return self._sslobj.read(len)
AttributeError: 'NoneType' object has no attribute 'read'


I would expect a socket.error instead, which mimics the way regular sockets behave. Indeed, this code:

import socket, ssl

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('www.verisign.com', 80))
s.close()
s.recv(1024)

raises:

Traceback (most recent call last):
  File "/tmp/bug.py", line 6, in <module>
    s.recv(1024)
  File "/path/to/lib/python2.7/socket.py", line 170, in _dummy
    raise error(EBADF, 'Bad file descriptor')
socket.error: [Errno 9] Bad file descriptor


I've tested on the latest trunks on both 2.7 and 3.2. I've also tested on 2.6 and 3.1.

I can write a patch that fixes it if the bug is accepted.

----------
components: Library (Lib)
messages: 109379
nosy: cbay
priority: normal
severity: normal
status: open
title: ssl.read/write on closed socket raises AttributeError
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Jul  6 11:59:13 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 06 Jul 2010 09:59:13 +0000
Subject: [New-bugs-announce] [issue9178] Compile problem on HP-UX 11
In-Reply-To: <1278410353.61.0.423846104588.issue9178@psf.upfronthosting.co.za>
Message-ID: <1278410353.61.0.423846104588.issue9178@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

I get a segmentation fault in the compiler when building python 2.7 on an HP-UX machine.

Compiler version:

  B9007AA               C.11.23.12     HP C/aC++ Developer's Bundle 

System info:


HP-UX ah006b02 B.11.23 U 9000/800 2284397887 unlimited-user license


Last bit of the output of make:


        cc -Ae -c -Olimit 1500 -g -DNDEBUG -O  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o Objects/exceptions.o Objects/exceptions.c
( 0)  0x002012ac   Call_exit + 0x58  [/opt/ansic/lbin/ccom]
( 1)  0x001f3938   catch_signal + 0x1c  [/opt/ansic/lbin/ccom]
( 2)  0x00967fb8   _sigreturn  [/opt/ansic/lbin/ccom]
( 3)  0x008759ec   doc_assign_range_bounds + 0x1430  [/opt/ansic/lbin/ccom]
( 4)  0x008730cc   doc_process_ranges + 0xdc  [/opt/ansic/lbin/ccom]
( 5)  0x0063b2d0   opt_driver + 0x1e20  [/opt/ansic/lbin/ccom]
( 6)  0x00547cc8   process_sllic_graph + 0x1a8  [/opt/ansic/lbin/ccom]
( 7)  0x00545320   pass2_ucode + 0x47c  [/opt/ansic/lbin/ccom]
( 8)  0x005818b0   cg_end + 0x38c  [/opt/ansic/lbin/ccom]
( 9)  0x002875fc   be_end + 0x1c  [/opt/ansic/lbin/ccom]
(10)  0x00271df0   fl_defn + 0x5fc  [/opt/ansic/lbin/ccom]
(11)  0x0025e74c   fl_stmt + 0x25c  [/opt/ansic/lbin/ccom]
(12)  0x001fa2ac   cpx_Process_tree + 0xc18  [/opt/ansic/lbin/ccom]
(13)  0x00213378   Process_tree_received_as_output + 0x474  [/opt/ansic/lbin/ccom]
(14)  0x00212ea0   P_build_non_leaf + 0x8c  [/opt/ansic/lbin/ccom]
(15)  0x00205690   Faster_parser + 0x4bc  [/opt/ansic/lbin/ccom]
(16)  0x00202168   LR_parser + 0x10  [/opt/ansic/lbin/ccom]
(17)  0x002015a0   Do_MW + 0x18  [/opt/ansic/lbin/ccom]
(18)  0x001f4244   main + 0x7a0  [/opt/ansic/lbin/ccom]
(19)  0x0090fa40   _start + 0x98  [/opt/ansic/lbin/ccom]
(20)  0x001f2000   $START$ + 0x178  [/opt/ansic/lbin/ccom]
cc: error 1405: "/opt/ansic/lbin/ccom" terminated abnormally with signal 11.
*** Error exit code 9


I can finish the build by compiling this file and "Modules/_io/_iomodule.o" without the '-O' flag (the latter took some tweaking)

It is unlikely that this is a Python bug, but I'm filing it here anyway just in case anyone else runs into it.


see also: Issue9176, Issue9175

----------
components: Build
messages: 109380
nosy: ronaldoussoren
priority: normal
severity: normal
status: open
title: Compile problem on HP-UX 11
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Tue Jul  6 12:23:34 2010
From: report at bugs.python.org (andrew cooke)
Date: Tue, 06 Jul 2010 10:23:34 +0000
Subject: [New-bugs-announce] [issue9179] Lookback with group references
	incorrect (two issues?)
In-Reply-To: <1278411814.72.0.368411829683.issue9179@psf.upfronthosting.co.za>
Message-ID: <1278411814.72.0.368411829683.issue9179@psf.upfronthosting.co.za>


New submission from andrew cooke <andrew at acooke.org>:

from re import compile

# these work as expected

assert compile('(a)b(?<=b)(c)').match('abc')
assert not compile('(a)b(?<=c)(c)').match('abc')
assert compile('(a)b(?=c)(c)').match('abc')
assert not compile('(a)b(?=b)(c)').match('abc')

# but when you add groups, you get bugs

assert not compile('(?:(a)|(x))b(?<=(?(2)x|c))c').match('abc') # matches!
assert not compile('(?:(a)|(x))b(?<=(?(2)b|x))c').match('abc')
assert compile('(?:(a)|(x))b(?<=(?(2)x|b))c').match('abc') # fails!
assert not compile('(?:(a)|(x))b(?<=(?(1)c|x))c').match('abc') # matches!
assert compile('(?:(a)|(x))b(?<=(?(1)b|x))c').match('abc') # fails!

# but lookahead works as expected

assert compile('(?:(a)|(x))b(?=(?(2)x|c))c').match('abc')
assert not compile('(?:(a)|(x))b(?=(?(2)c|x))c').match('abc')
assert compile('(?:(a)|(x))b(?=(?(2)x|c))c').match('abc')
assert not compile('(?:(a)|(x))b(?=(?(1)b|x))c').match('abc')
assert compile('(?:(a)|(x))b(?=(?(1)c|x))c').match('abc')

# these are similar but, in my opinion, shouldn't even compile
# (group used before defined)

assert not compile('(a)b(?<=(?(2)x|c))(c)').match('abc') # matches!
assert not compile('(a)b(?<=(?(2)b|x))(c)').match('abc')
assert not compile('(a)b(?<=(?(1)c|x))(c)').match('abc') # matches!
assert compile('(a)b(?<=(?(1)b|x))(c)').match('abc') # fails!

assert compile('(a)b(?=(?(2)x|c))(c)').match('abc')
assert not compile('(a)b(?=(?(2)b|x))(c)').match('abc')
assert compile('(a)b(?=(?(1)c|x))(c)').match('abc')

# this is the error we should see above
try:
    compile('(a)\\2(b)')
    assert False, 'expected error'
except:
    pass

----------
components: Library (Lib)
messages: 109382
nosy: acooke
priority: normal
severity: normal
status: open
title: Lookback with group references incorrect (two issues?)
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Jul  6 16:14:53 2010
From: report at bugs.python.org (Peter Wolf)
Date: Tue, 06 Jul 2010 14:14:53 +0000
Subject: [New-bugs-announce] [issue9180] Memory Error
In-Reply-To: <1278425693.24.0.842654269147.issue9180@psf.upfronthosting.co.za>
Message-ID: <1278425693.24.0.842654269147.issue9180@psf.upfronthosting.co.za>


New submission from Peter Wolf <freakcycle at optusnet.com.au>:

I am using Ubuntu 10.04 32 bit  and python 2.6.When I type the following line in a terminal

>python mydatafile.py

I get the following error message on the next line

MemoryError

That is all.


File details : 

It is a 2d list of floating point numbers 86Mb in size.
Here is the start ->

mydata=[[1.51386,1.51399,1.51386,1.51399],
[1.51386,1.51401,1.51401,1.51386],
[1.51391,1.51406,1.51395,1.51401],
[1.51392,1.514,1.51397,1.51395],
[1.51377,1.5142,1.51387,1.51397],

here is the end ->

[1.5631,1.5633,1.5631,1.5631],
[1.5631,1.5632,1.5631,1.5631],
[1.5631,1.5633,1.5631,1.5631],
[1.563,1.5631,1.5631,1.5631]]


I will add that exactly the same type of file but 49MB in size compiled 
with 1GB of ram although there was a lot of disk activity and the CPU seemed to be working very hard.The 86MB file produced the above error.I upgraded to 3.4GB and still the same error.

----------
components: None
messages: 109392
nosy: freakcycle
priority: normal
severity: normal
status: open
title: Memory Error
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Tue Jul  6 17:17:13 2010
From: report at bugs.python.org (Charles Solar)
Date: Tue, 06 Jul 2010 15:17:13 +0000
Subject: [New-bugs-announce] [issue9181] Solaris extension building does not
	work with 64 bit	python
In-Reply-To: <1278429433.49.0.398235894568.issue9181@psf.upfronthosting.co.za>
Message-ID: <1278429433.49.0.398235894568.issue9181@psf.upfronthosting.co.za>


New submission from Charles Solar <charlessolar at gmail.com>:

On solaris, if you build a 64 bit python and use it to build an extension, it will not properly link the module.

Apparently solaris requires the -m64 flag in the linker as well as the compile steps.  Python distutils successfully compiles all the object files using -m64, but it fails to link with -m64 causing the entire build to fail if the extension needs a 64 bit library dependency ( will get 'incompatible library' errors from the linker ).

To reproduce:
build python with CFLAGS="-m64 -O3" LDFLAGS="-m64"
build a C extension that depends on a 64 bit library (python setup.py install)

I assume that it would work if the C extension does not need a specific 64 bit library as the linker will not go and look for the wrong version of file.  So its a very uncommon but annoying bug.

> ld --version
GNU ld (GNU Binutils) 2.20.1.20100303
Copyright 2009 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

----------
assignee: tarek
components: Distutils, Distutils2, Extension Modules
messages: 109396
nosy: redcomet, tarek
priority: normal
severity: normal
status: open
title: Solaris extension building does not work with 64 bit python
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Tue Jul  6 18:24:41 2010
From: report at bugs.python.org (Sergey Konoplev)
Date: Tue, 06 Jul 2010 16:24:41 +0000
Subject: [New-bugs-announce] [issue9182] argparse: optional argument w/
	narg='+' conflicts w/	positional argsument
In-Reply-To: <1278433481.81.0.201692715302.issue9182@psf.upfronthosting.co.za>
Message-ID: <1278433481.81.0.201692715302.issue9182@psf.upfronthosting.co.za>


New submission from Sergey Konoplev <gray.ru at gmail.com>:

Hello,

I am starting to use argparse package and faced the problem where an optional argument w/ nargs='+' conflicts w/ a positional argument. 

Here is the test case:

>>> import argparse
>>> p = argparse.ArgumentParser()
>>> p.add_argument('foo', type=str)
_StoreAction(option_strings=[], dest='foo', nargs=None, const=None, default=None, type=<type 'str'>, choices=None, help=None, metavar=None)
>>> p.add_argument('-b', '--bar', type=int, nargs='+')
_StoreAction(option_strings=['-b', '--bar'], dest='bar', nargs='+', const=None, default=None, type=<type 'int'>, choices=None, help=None, metavar=None)
>>> p.print_help()
usage: [-h] [-b BAR [BAR ...]] foo

positional arguments:
  foo

optional arguments:
  -h, --help            show this help message and exit
  -b BAR [BAR ...], --bar BAR [BAR ...]
>>> p.parse_args('-b 123 456 bla'.split())
usage: [-h] [-b BAR [BAR ...]] foo
: error: argument -b/--bar: invalid int value: 'bla'


It prints this usage string "usage: [-h] [-b BAR [BAR ...]] foo" so it is assumed that I could use this " -b 123 456 bla" but it does not works. 

How could it be and how to solve it? 

Thank you in advance.

----------
components: Library (Lib)
messages: 109402
nosy: gray_hemp
priority: normal
severity: normal
status: open
title: argparse: optional argument w/ narg='+' conflicts w/ positional argsument
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Jul  6 23:55:53 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 06 Jul 2010 21:55:53 +0000
Subject: [New-bugs-announce] [issue9183] Intern UTC timezone
In-Reply-To: <1278453353.29.0.0260229757511.issue9183@psf.upfronthosting.co.za>
Message-ID: <1278453353.29.0.0260229757511.issue9183@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Attached patch makes timezone(timedelta(0)) always return the same instance as timezone.utc.  See issue9051 for pure python implementation.

With this patch, manipulation of aware datetime objects will be as efficient as that of naive datetime objects.  Note that having timezone.utc is not enough to assure that the same tzinfo object is used because aware objects can be produced by datetime.strptime().  With this patch,

>>> datetime.strptime('2010-07-06 21:39:55 +0000', "%Y-%m-%d %H:%M:%S %z").tzinfo is timezone.utc
True

----------
assignee: belopolsky
components: Extension Modules
files: intern-utc.diff
keywords: easy, patch
messages: 109432
nosy: belopolsky, mark.dickinson
priority: normal
severity: normal
stage: commit review
status: open
title: Intern UTC timezone
type: resource usage
versions: Python 3.2
Added file: http://bugs.python.org/file17885/intern-utc.diff

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

From report at bugs.python.org  Tue Jul  6 23:58:09 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Jul 2010 21:58:09 +0000
Subject: [New-bugs-announce] [issue9184] open() doc: default value for
	buffering is -1, not None
In-Reply-To: <1278453489.46.0.972678242141.issue9184@psf.upfronthosting.co.za>
Message-ID: <1278453489.46.0.972678242141.issue9184@psf.upfronthosting.co.za>


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

Examples:
 * open(filename) works
 * open(filename, buffering=-1) works
 * open(filename, buffering=None) fails

In the code:
 * _pyio.open(): default value is -1, type is int, no default value in the docstring
 * _io.open(): default value is not specified (C function), type is int, default value in the docstring is None

In the doc:
 * open() default value is None

The default value should be -1 everywhere. None is rejected by io.open (_io) and _pyio.open.

Attached patch fixes _io.open() docstring Python documentation.

----------
assignee: docs at python
components: Documentation, IO, Interpreter Core
files: open_doc_buffering.patch
keywords: patch
messages: 109434
nosy: docs at python, haypo, pitrou
priority: normal
severity: normal
status: open
title: open() doc: default value for buffering is -1, not None
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17886/open_doc_buffering.patch

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

From report at bugs.python.org  Wed Jul  7 10:56:37 2010
From: report at bugs.python.org (Zsolt Cserna)
Date: Wed, 07 Jul 2010 08:56:37 +0000
Subject: [New-bugs-announce] [issue9185] os.getcwd causes infinite loop on
	solaris
In-Reply-To: <1278492997.35.0.523630408468.issue9185@psf.upfronthosting.co.za>
Message-ID: <1278492997.35.0.523630408468.issue9185@psf.upfronthosting.co.za>


New submission from Zsolt Cserna <zsolt.cserna at morganstanley.com>:

os.getcwd() causes infinite loop on solaris10 when the length of the current directory is greater than 1024 (them limit of the maximum absolute path).

os.getcwd is implemented by a while loop in python, see the function posix_getcwd in posixmodule.c. That while loop loops forever because on solaris it sets errno to ERANGE and res to NULL - even if there will be no positive results from getcwd due to the extra long path.
This infinite while cycle also causes eating up the memory.

I think the solution would be implementing a hard limit for this while loop. It could be either fixed (16k for example), or dymanic: comparing the MAXPATHLEN macro to the size of the allocated buffer and if the size of the buffer is greater than MAXLPATHLEN then raise an OSError exception with the current errno.

That bug was triggered by test_posix unittest.

----------
components: Library (Lib)
messages: 109459
nosy: csernazs
priority: normal
severity: normal
status: open
title: os.getcwd causes infinite loop on solaris
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Jul  7 12:10:32 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 07 Jul 2010 10:10:32 +0000
Subject: [New-bugs-announce] [issue9186] math.log1p(-1.0) produces
	OverflowError; should be ValueError
In-Reply-To: <1278497432.77.0.860958326747.issue9186@psf.upfronthosting.co.za>
Message-ID: <1278497432.77.0.860958326747.issue9186@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

>>> from math import log1p
>>> log1p(-1.0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: math range error

This should be a ValueError instead.

(Thanks Benjamin for noticing this.)

----------
assignee: mark.dickinson
components: Extension Modules
files: log1p_neg1.patch
keywords: patch
messages: 109468
nosy: benjamin.peterson, mark.dickinson
priority: normal
severity: normal
status: open
title: math.log1p(-1.0) produces OverflowError; should be ValueError
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17893/log1p_neg1.patch

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

From report at bugs.python.org  Wed Jul  7 13:06:08 2010
From: report at bugs.python.org (Lloyd Sheng)
Date: Wed, 07 Jul 2010 11:06:08 +0000
Subject: [New-bugs-announce] [issue9187] Can't find file  "vcvars64.bat"
In-Reply-To: <1278500768.36.0.603333056157.issue9187@psf.upfronthosting.co.za>
Message-ID: <1278500768.36.0.603333056157.issue9187@psf.upfronthosting.co.za>


New submission from Lloyd Sheng <senzjx at gmail.com>:

While I install Pymongo,Error shows that:

running install
running bdist_egg
running egg_info
writing pymongo.egg-info\PKG-INFO
writing top-level names to pymongo.egg-info\top_level.txt
writing dependency_links to pymongo.egg-info\dependency_links.txt
reading manifest file 'pymongo.egg-info\SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'pymongo.egg-info\SOURCES.txt'
installing library code to build\bdist.win-amd64\egg
running install_lib
running build_py
running build_ext
building 'pymongo._cbson' extension
Traceback (most recent call last):
  File "setup.py", line 176, in <module>
    "doc": doc})
  File "C:\Python26\lib\distutils\core.py", line 152, in setup
    dist.run_commands()
  File "C:\Python26\lib\distutils\dist.py", line 975, in run_commands
    self.run_command(cmd)
  File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
    cmd_obj.run()
  File "C:\Python26\lib\site-packages\setuptools-0.6c11-py2.6.egg\setuptools\command\install.py", line 76, in run
  File "C:\Python26\lib\site-packages\setuptools-0.6c11-py2.6.egg\setuptools\command\install.py", line 96, in do_egg_install
  File "C:\Python26\lib\distutils\cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
    cmd_obj.run()
  File "C:\Python26\lib\site-packages\setuptools-0.6c11-py2.6.egg\setuptools\command\bdist_egg.py", line 175, in run
  File "C:\Python26\lib\site-packages\setuptools-0.6c11-py2.6.egg\setuptools\command\bdist_egg.py", line 161, in call_command
  File "C:\Python26\lib\distutils\cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
    cmd_obj.run()
  File "C:\Python26\lib\site-packages\setuptools-0.6c11-py2.6.egg\setuptools\command\install_lib.py", line 20, in run
  File "C:\Python26\lib\distutils\command\install_lib.py", line 115, in build
    self.run_command('build_ext')
  File "C:\Python26\lib\distutils\cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
    cmd_obj.run()
  File "setup.py", line 108, in run
    build_ext.run(self)
  File "C:\Python26\lib\distutils\command\build_ext.py", line 340, in run
    self.build_extensions()
  File "C:\Python26\lib\distutils\command\build_ext.py", line 449, in build_extensions
    self.build_extension(ext)
  File "setup.py", line 118, in build_extension
    build_ext.build_extension(self, ext)
  File "C:\Python26\lib\distutils\command\build_ext.py", line 499, in build_extension
    depends=ext.depends)
  File "C:\Python26\lib\distutils\msvc9compiler.py", line 449, in compile
    self.initialize()
  File "C:\Python26\lib\distutils\msvc9compiler.py", line 359, in initialize
    vc_env = query_vcvarsall(VERSION, plat_spec)
  File "C:\Python26\lib\distutils\msvc9compiler.py", line 275, in query_vcvarsall
    raise ValueError(str(list(result.keys())))
ValueError: [u'path']

There error info is same as Issue7511 .
Here is info about my machine:
OS: Windows Server 2008 R2(64bit)

I have installed both VS2010 and VS2008 in my machine.But VS2010 intalled before VS2008.
Also. I can found vcvars64.bat at dir:C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64, but i don't know why Python can't found it.

There is a temporarily way to avoid the error ,we can manual execute vcvars64.bat before intall python module, But I think it's a python bug.

----------
components: Library (Lib)
messages: 109469
nosy: Lloyd.Sheng
priority: normal
severity: normal
status: open
title: Can't find file  "vcvars64.bat"
versions: Python 2.6

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

From report at bugs.python.org  Wed Jul  7 15:17:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Jul 2010 13:17:49 +0000
Subject: [New-bugs-announce] [issue9188] test_gdb fails on narrow unicode
	builds
In-Reply-To: <1278508669.56.0.292835810608.issue9188@psf.upfronthosting.co.za>
Message-ID: <1278508669.56.0.292835810608.issue9188@psf.upfronthosting.co.za>


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

======================================================================
FAIL: test_unicode (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of unicode values
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/27/Lib/test/test_gdb.py", line 247, in test_unicode
    self.assertGdbRepr(u"\U0001D121")
  File "/home/antoine/cpython/27/Lib/test/test_gdb.py", line 178, in assertGdbRepr
    self.assertEquals(gdb_repr, repr(val), gdb_output)
AssertionError: Breakpoint 1 at 0x45cde8: file Objects/object.c, line 330.
[Thread debugging using libthread_db enabled]

Breakpoint 1, PyObject_Print (op=Traceback (most recent call last):
  File "/home/antoine/cpython/27/python-gdb.py", line 1084, in to_string
    return pyop.get_truncated_repr(MAX_OUTPUT_LEN)
  File "/home/antoine/cpython/27/python-gdb.py", line 183, in get_truncated_repr
    self.write_repr(out, set())
  File "/home/antoine/cpython/27/python-gdb.py", line 1054, in write_repr
    proxy2.append(unichr(code))
ValueError: unichr() arg not in range(0x10000) (narrow Python build)
, fp=0x7ffff7535780, flags=1) at Objects/object.c:330
330	    return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=Traceback (most recent call last):
  File "/home/antoine/cpython/27/python-gdb.py", line 1084, in to_string
    return pyop.get_truncated_repr(MAX_OUTPUT_LEN)
  File "/home/antoine/cpython/27/python-gdb.py", line 183, in get_truncated_repr
    self.write_repr(out, set())
  File "/home/antoine/cpython/27/python-gdb.py", line 1054, in write_repr
    proxy2.append(unichr(code))
ValueError: unichr() arg not in range(0x10000) (narrow Python build)
, fp=0x7ffff7535780, flags=1) at Objects/object.c:330
#1  0x0000000000431744 in file_PyObject_Print (op=Traceback (most recent call last):
  File "/home/antoine/cpython/27/python-gdb.py", line 1084, in to_string
    return pyop.get_truncated_repr(MAX_OUTPUT_LEN)
  File "/home/antoine/cpython/27/python-gdb.py", line 183, in get_truncated_repr
    self.write_repr(out, set())
  File "/home/antoine/cpython/27/python-gdb.py", line 1054, in write_repr
    proxy2.append(unichr(code))
ValueError: unichr() arg not in range(0x10000) (narrow Python build)
, f=0x7ffff7fc1280, flags=1) at Objects/fileobject.c:110
#2  0x00000000004369e2 in PyFile_WriteObject (v=Traceback (most recent call last):
  File "/home/antoine/cpython/27/python-gdb.py", line 1084, in to_string
    return pyop.get_truncated_repr(MAX_OUTPUT_LEN)
  File "/home/antoine/cpython/27/python-gdb.py", line 183, in get_truncated_repr
    self.write_repr(out, set())
  File "/home/antoine/cpython/27/python-gdb.py", line 1054, in write_repr
    proxy2.append(unichr(code))
ValueError: unichr() arg not in range(0x10000) (narrow Python build)
, f=<file at remote 0x7ffff7fc1280>, flags=1) at Objects/fileobject.c:2472
#3  0x00000000004c9709 in PyEval_EvalFrameEx (f=Frame 0x9190f0, for file <string>, line 1, in <module> (), 
    throwflag=0) at Python/ceval.c:1769
#4  0x00000000004cfd36 in PyEval_EvalCodeEx (co=0x7ffff7fb8930, globals=
    {'__builtins__': <module at remote 0x7ffff7fd2470>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x7ffff7fd2470>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3252
#5  0x00000000004c5dc4 in PyEval_EvalCode (co=0x7ffff7fb8930, globals=
    {'__builtins__': <module at remote 0x7ffff7fd2470>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x7ffff7fd2470>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:666
#6  0x0000000000500a4c in run_mod (mod=0x903828, filename=0x5a1bbd "<string>", globals=
    {'__builtins__': <module at remote 0x7ffff7fd2470>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x7ffff7fd2470>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=0x7fffffffdbc0, arena=0x8bc5f0) at Python/pythonrun.c:1346
#7  0x00000000005008eb in PyRun_StringFlags (str=0x82a010 "print u'\\U0001d121'\n", start=257, globals=
    {'__builtins__': <module at remote 0x7ffff7fd2470>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=
    {'__builtins__': <module at remote 0x7ffff7fd2470>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=0x7fffffffdbc0) at Python/pythonrun.c:1309
#8  0x00000000004ff3f5 in PyRun_SimpleStringFlags (command=0x82a010 "print u'\\U0001d121'\n", flags=
    0x7fffffffdbc0) at Python/pythonrun.c:962
#9  0x00000000004155a4 in Py_Main (argc=4, argv=0x7fffffffdd48) at Modules/main.c:543
#10 0x0000000000414484 in main (argc=4, argv=0x7fffffffdd48) at ./Modules/python.c:23

----------
components: Library (Lib), Tests
messages: 109473
nosy: dmalcolm, pitrou
priority: normal
severity: normal
status: open
title: test_gdb fails on narrow unicode builds
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Jul  7 17:51:13 2010
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Wed, 07 Jul 2010 15:51:13 +0000
Subject: [New-bugs-announce] [issue9189] Improve CFLAGS handling
In-Reply-To: <1278517873.84.0.191654592449.issue9189@psf.upfronthosting.co.za>
Message-ID: <1278517873.84.0.191654592449.issue9189@psf.upfronthosting.co.za>


New submission from Jeffrey Yasskin <jyasskin at gmail.com>:

Patch at http://codereview.appspot.com/1749042.

The idea here is to let the user set CFLAGS on either configure or make (or both), and have later settings appear later in the $CC command line. I left OPT, BASECFLAGS, and EXTRA_CFLAGS around in case people have written scripts using them, but I think they're superfluous as user-visible knobs after this patch.

I prevented AC_PROG_CC from setting a default $CFLAGS value because the values it would set are already put into $BASECFLAGS when appropriate, and @CFLAGS@ needs to appear after @BASECFLAGS@ to allow the user to override Python's defaults at configure time. We could also accomplish this by removing BASECFLAGS and OPT entirely and instead prepending their contents to $CFLAGS in configure. That's a bigger patch, but if any of you feel strongly about it I can do that instead.

I made the same changes for CPPFLAGS and LDFLAGS but no other user-settable variables. I don't have strong opinions about the exact set we support this for, as long as it includes CFLAGS, but these three seemed like a sensible set.

----------
messages: 109481
nosy: brett.cannon, jyasskin, lemburg, loewis, pitrou
priority: normal
severity: normal
status: open
title: Improve CFLAGS handling
versions: Python 3.2

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

From report at bugs.python.org  Wed Jul  7 18:42:25 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 07 Jul 2010 16:42:25 +0000
Subject: [New-bugs-announce] [issue9190] Undefined behaviour in
	_PyFloat_Pack4
In-Reply-To: <1278520945.21.0.807868550373.issue9190@psf.upfronthosting.co.za>
Message-ID: <1278520945.21.0.807868550373.issue9190@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

_PyFloat_Pack4 does a double-to-float cast, without first checking that the value being converted is within the range of a float.  According to C99 6.3.1.5p2, this results in undefined behaviour.  It should be fixed (probably via comparison with FLT_MAX before casting.)

np_float in the struct module also has this problem.

----------
assignee: mark.dickinson
messages: 109483
nosy: mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: Undefined behaviour in _PyFloat_Pack4
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Jul  7 19:52:46 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 07 Jul 2010 17:52:46 +0000
Subject: [New-bugs-announce] [issue9191] winreg.c:Reg2Py() may leak memory
	(in unusual	circumstances)
In-Reply-To: <1278525166.4.0.0879298798846.issue9191@psf.upfronthosting.co.za>
Message-ID: <1278525166.4.0.0879298798846.issue9191@psf.upfronthosting.co.za>


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

In Reg2Py() in winreg.c, in the REG_MULTI_SZ case, there's the following:

                wchar_t **str = (wchar_t **)malloc(sizeof(wchar_t *)*s);
                if (str == NULL)
                    return PyErr_NoMemory();

However, not all of the return paths after that point call free(str).

The leaking paths are pretty unusual, so I'm setting the priority to low.  The leaking paths occur when PyList_New returns NULL or if the registry entry contains more than INT_MAX characters.

Two other things I noticed and I'm not sure about:

Is INT_MAX really the maximum number of characters for a Python unicode string?

Should this be using PyMem functions instead of malloc/free?

----------
assignee: stutzbach
components: Windows
messages: 109486
nosy: stutzbach
priority: low
severity: normal
stage: needs patch
status: open
title: winreg.c:Reg2Py() may leak memory (in unusual circumstances)
type: resource usage
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Jul  7 20:25:59 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 07 Jul 2010 18:25:59 +0000
Subject: [New-bugs-announce] [issue9192] Add a a way to determine float
	format
In-Reply-To: <1278527159.47.0.497382000521.issue9192@psf.upfronthosting.co.za>
Message-ID: <1278527159.47.0.497382000521.issue9192@psf.upfronthosting.co.za>


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

At the moment, the only way is float.__getformat__() which is unpleasant and unofficial. Perhaps we could add a member to sys.float_info.

----------
components: Interpreter Core
messages: 109488
nosy: benjamin.peterson, mark.dickinson
priority: low
severity: normal
status: open
title: Add a a way to determine float format
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Wed Jul  7 20:33:27 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 07 Jul 2010 18:33:27 +0000
Subject: [New-bugs-announce] [issue9193] Versioned .so files
In-Reply-To: <1278527607.97.0.766712002778.issue9193@psf.upfronthosting.co.za>
Message-ID: <1278527607.97.0.766712002778.issue9193@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

As described in the thread started here:

http://mail.python.org/pipermail/python-dev/2010-June/100998.html

this bug requests that a new configure option called --with-so-abi-tag be added to Python 3.2 to support sharing of .so files for different versions of Python.

----------
assignee: barry
components: Build
keywords: patch
messages: 109489
nosy: barry
priority: normal
severity: normal
status: open
title: Versioned .so files
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Thu Jul  8 05:06:47 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 08 Jul 2010 03:06:47 +0000
Subject: [New-bugs-announce] [issue9194] winreg:fixupMultiSZ should check
	that P < Q in the inner	loop
In-Reply-To: <1278558407.29.0.39315930303.issue9194@psf.upfronthosting.co.za>
Message-ID: <1278558407.29.0.39315930303.issue9194@psf.upfronthosting.co.za>


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

The comment before fixupMultiSZ and countString states:

** Note that fixupMultiSZ and countString have both had changes
** made to support "incorrect strings".  The registry specification
** calls for strings to be terminated with 2 null bytes.  It seems
** some commercial packages install strings which don't conform,
** causing this code to fail - however, "regedit" etc still work
** with these strings (ie only we don't!).

As indicated in the comments, the two functions dutifully check the supplied length parameter and do not trust the data to be in the correct format.

... except for the inner loop in fixupMultiSZ, which reads:

                for(; *P != '\0'; P++)
                        ;

It should be the same as the inner loop of countStrings:

                for (; P < Q && *P != '\0'; P++)
                        ;

----------
messages: 109511
nosy: stutzbach
priority: normal
severity: normal
status: open
title: winreg:fixupMultiSZ should check that P < Q in the inner loop
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Jul  8 08:36:47 2010
From: report at bugs.python.org (Craig McQueen)
Date: Thu, 08 Jul 2010 06:36:47 +0000
Subject: [New-bugs-announce] [issue9195] Link in docs from "String
	Formatting Operations" to	"Template Strings"
In-Reply-To: <1278571007.55.0.304215462236.issue9195@psf.upfronthosting.co.za>
Message-ID: <1278571007.55.0.304215462236.issue9195@psf.upfronthosting.co.za>


New submission from Craig McQueen <python at craig.mcqueen.id.au>:

I stumbled across "Template Strings" of PEP 292 by accident recently. I'd never heard of it before.

I'm familiar with the "string interpolation" aka "String Formatting Operations", and I know to find that in the docs under "Standard Types", i.e.
http://docs.python.org/library/stdtypes.html#string-formatting-operations
http://docs.python.org/py3k/library/stdtypes.html#old-string-formatting-operations

It would be good for that documentation to mention "Template Strings", and include a cross-reference to the docs for it, since it was created as an alternative string formatting. I.e. cross-reference to
http://docs.python.org/library/string.html#template-strings
http://docs.python.org/py3k/library/string.html#template-strings

----------
assignee: docs at python
components: Documentation
messages: 109515
nosy: cmcqueen1975, docs at python
priority: normal
severity: normal
status: open
title: Link in docs from "String Formatting Operations" to "Template Strings"
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jul  8 09:07:10 2010
From: report at bugs.python.org (Craig McQueen)
Date: Thu, 08 Jul 2010 07:07:10 +0000
Subject: [New-bugs-announce] [issue9196] Improve docs for string
	interpolation "%s" re Unicode	strings
In-Reply-To: <1278572830.17.0.148747735024.issue9196@psf.upfronthosting.co.za>
Message-ID: <1278572830.17.0.148747735024.issue9196@psf.upfronthosting.co.za>


New submission from Craig McQueen <python at craig.mcqueen.id.au>:

I have just been trying to figure out how string interpolation works for "%s", when Unicode strings are involved. It seems it's a bit complicated, but the Python documentation doesn't really describe it. It just says %s "converts any Python object using str()".

Here is what I have found (I think), and it could be worth improving the documentation of this somehow.

Example 1:
    "%s" % test_object

>From what I can tell, in this case:
1. test_object.__str__() is called.
2. If test_object.__str__() returns a string object, then that is substituted.
3. If test_object.__str__() returns a Unicode object (for some reason), then test_object.__unicode__() is called, then _that_ is substituted instead. The output string is turned into Unicode. This behaviour is surprising.

[Note that the call to test_object.__str__() is not the same as str(test_object), because the former can return a Unicode object without causing an error, while the latter, if it gets a Unicode object, will then try to encode('ascii') to a string, possibly generating a UnicodeEncodeError exception.]


Example 2:
    u"%s" % test_object

In this case:
1. test_object.__unicode__() is called, if it exists, and the result is substituted. The output string is Unicode.
2. If test_object.__unicode__() doesn't exist, then test_object.__str__() is called instead, converted to Unicode, and substituted. The output string is Unicode.


Example 3:
    "%s %s" % (u'unicode', test_object)

In this case:
1. The first substitution causes the output string to be Unicode.
2. It seems that (1) causes the second substitution to follow the same rules as Example 2. This is a little surprising.

----------
assignee: docs at python
components: Documentation
messages: 109516
nosy: cmcqueen1975, docs at python
priority: normal
severity: normal
status: open
title: Improve docs for string interpolation "%s" re Unicode strings
versions: Python 2.7

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

From report at bugs.python.org  Thu Jul  8 10:50:50 2010
From: report at bugs.python.org (Palluat de Besset)
Date: Thu, 08 Jul 2010 08:50:50 +0000
Subject: [New-bugs-announce] [issue9197] subprocess module causing crash
Message-ID: <1278579050.72.0.400216710661.issue9197@psf.upfronthosting.co.za>


Changes by Palluat de Besset <marc.palluatdebesset at sophos.com>:


----------
assignee: ronaldoussoren
components: Macintosh
nosy: mpalluat, ronaldoussoren
priority: normal
severity: normal
status: open
title: subprocess module causing crash
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Thu Jul  8 10:53:07 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 08 Jul 2010 08:53:07 +0000
Subject: [New-bugs-announce] [issue9198] Should repr() print unicode
	characters outside the BMP?
In-Reply-To: <1278579187.34.0.662391507791.issue9198@psf.upfronthosting.co.za>
Message-ID: <1278579187.34.0.662391507791.issue9198@psf.upfronthosting.co.za>


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

On wide unicode builds, '\U00010000'.isprintable() returns True, and repr() returns the character unmodified.
Is it a good behavior, given that very few fonts have can display this character?

Marc-Andre Lemburg wrote:
> The "printable" property is a Python invention, not a Unicode property,
> so we do have some freedom is deciding what is printable and what
> is not.

The current implementation considers printable """all the characters except those characters defined in the Unicode character database as following categories are considered printable.
  * Cc (Other, Control)
  * Cf (Other, Format)
  * Cs (Other, Surrogate)
  * Co (Other, Private Use)
  * Cn (Other, Not Assigned)
  * Zl Separator, Line ('\u2028', LINE SEPARATOR)
  * Zp Separator, Paragraph ('\u2029', PARAGRAPH SEPARATOR)
  * Zs (Separator, Space) other than ASCII space('\x20').
"""

We could also arbitrarily exclude all the non-BMP chars.

----------
components: Unicode
messages: 109520
nosy: amaury.forgeotdarc, ezio.melotti, lemburg
priority: normal
severity: normal
status: open
title: Should repr() print unicode characters outside the BMP?
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Jul  8 15:38:54 2010
From: report at bugs.python.org (Phillip J. Eby)
Date: Thu, 08 Jul 2010 13:38:54 +0000
Subject: [New-bugs-announce] [issue9199] distutil upload command crashes
	when displaying server	response
In-Reply-To: <1278596334.3.0.531936724428.issue9199@psf.upfronthosting.co.za>
Message-ID: <1278596334.3.0.531936724428.issue9199@psf.upfronthosting.co.za>


New submission from Phillip J. Eby <pje at telecommunity.com>:

When showing a server response (--show-response), the upload command crashes with the following traceback:

Traceback (most recent call last):
  File "setup.py", line 94, in <module>
    scripts = scripts,
  File "/usr/lib/python2.7/distutils/core.py", line 152, in setup
    dist.run_commands()
  File "/usr/lib/python2.7/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/usr/lib/python2.7/distutils/command/upload.py", line 60, in run
    self.upload_file(command, pyversion, filename)
  File "/usr/lib/python2.7/distutils/command/upload.py", line 189, in upload_file
    self.announce('-'*75, result.read(), '-'*75)
TypeError: announce() takes at most 3 arguments (4 given)

This is apparently due to the change made in r70889, which replaced a "print" statement with a call to self.announce(), but did not change the parameters appropriately.  (The announce() method takes a string and a log level, not an arbitrary number of string arguments.)

I don't know what versions of Python this is in besides 2.7; it may exist in a 2.6.x release or 3.x as well, but it is definitely in the 2.7 release.

----------
assignee: tarek
components: Distutils
messages: 109541
nosy: pje, tarek
priority: normal
severity: normal
status: open
title: distutil upload command crashes when displaying server response
versions: Python 2.7

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

From report at bugs.python.org  Thu Jul  8 15:50:03 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 08 Jul 2010 13:50:03 +0000
Subject: [New-bugs-announce] [issue9200] str.isprintable() is always False
	for large code points
In-Reply-To: <1278597003.49.0.847714220976.issue9200@psf.upfronthosting.co.za>
Message-ID: <1278597003.49.0.847714220976.issue9200@psf.upfronthosting.co.za>


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

On narrow unicode builds:
unicodedata.category(chr(0x10000)) == 'Lo'  # correct
Py_UNICODE_ISPRINTABLE(0x10000)    == 1     # correct 
str.isprintable(chr(0x10000))      == False # inconsistent

On narrow unicode builds, large code points are stored with a surrogate pair.  But str.isprintable() simply loops over the Py_UNICODE array, and test the surrogates separately.

There should be a way to walk a unicode string in C, character by character, and the str methods (str.is*, str.to*) should use it.

----------
components: Unicode
messages: 109542
nosy: amaury.forgeotdarc, ezio.melotti, lemburg
priority: normal
severity: normal
status: open
title: str.isprintable() is always False for large code points
versions: Python 3.2

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

From report at bugs.python.org  Thu Jul  8 16:40:15 2010
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 08 Jul 2010 14:40:15 +0000
Subject: [New-bugs-announce] [issue9201] IDLE: raises Exception TclError in
	a special case
In-Reply-To: <1278600015.52.0.587656960584.issue9201@psf.upfronthosting.co.za>
Message-ID: <1278600015.52.0.587656960584.issue9201@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

[forwarded from https://launchpad.net/bugs/597763]

seen with all version, built with Tcl8.5

To reproduce the bug, use the following class:

class x(object):
 TEST = "hello"
 THE_MAXIMUM = 55

 def __init__(self, a, b):
  self.a = 3
  self.b = "test"

and set the cursor behind "test". After that use SHIFT + UP (so from 3 to incl. "test" will be marked) and after that use SHIFT + POS1, which will produce this exception:

>>> Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 1413, in __call__
    return self.func(*args)
  File "/usr/lib/python2.6/idlelib/MultiCall.py", line 151, in handler
    r = l[i](event)
  File "/usr/lib/python2.6/idlelib/EditorWindow.py", line 335, in home_callback
    if self.text.compare(first,">",last):
  File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 2863, in compare
    self._w, 'compare', index1, op, index2))
TclError: expected boolean value but got ""

----------
components: Tkinter
messages: 109544
nosy: doko
priority: normal
severity: normal
status: open
title: IDLE: raises Exception TclError in a special case
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Jul  8 16:52:52 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 08 Jul 2010 14:52:52 +0000
Subject: [New-bugs-announce] [issue9202] Update platform.win32_ver() to
	account for change to #8413
In-Reply-To: <1278600772.14.0.212036343969.issue9202@psf.upfronthosting.co.za>
Message-ID: <1278600772.14.0.212036343969.issue9202@psf.upfronthosting.co.za>


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

The change to #8413 broke the use of sys.getwindowsversion() in platform.platform() calls on Windows, which subsequently breaks all runs of regrtest (e.g. buildbots) since it outputs platform info at the start.

Now that structseq subclasses tuple, every field of sys.getwindowsversion() is returned, rather than only the specific ones inserted into the structseq (for backwards compatibility). Since platform.py needs to maintain backwards compatibility with older versions, the change will need to handle both the new and old way.

----------
assignee: brian.curtin
components: None
messages: 109546
nosy: benjamin.peterson, brian.curtin, lemburg
priority: high
severity: normal
stage: needs patch
status: open
title: Update platform.win32_ver() to account for change to #8413
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Jul  8 19:35:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Jul 2010 17:35:04 +0000
Subject: [New-bugs-announce] [issue9203] Use computed gotos by default
In-Reply-To: <1278610504.41.0.538912852234.issue9203@psf.upfronthosting.co.za>
Message-ID: <1278610504.41.0.538912852234.issue9203@psf.upfronthosting.co.za>


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

Now that the option has probably been extensively tested, it would be nice to enable computed gotos by default on systems that support them.
Perhaps this needs a dedicated test in the configure script.

----------
components: Build, Interpreter Core
messages: 109558
nosy: jyasskin, lemburg, loewis, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Use computed gotos by default
type: performance
versions: Python 3.2

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

From report at bugs.python.org  Thu Jul  8 20:09:56 2010
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 08 Jul 2010 18:09:56 +0000
Subject: [New-bugs-announce] [issue9204] The documentation of PyType_Type in
	py3k mentions	types.TypeType
In-Reply-To: <1278612596.78.0.246474788536.issue9204@psf.upfronthosting.co.za>
Message-ID: <1278612596.78.0.246474788536.issue9204@psf.upfronthosting.co.za>


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

The documentation of PyType_Type (http://docs.python.org/dev/py3k/c-api/type.html#PyType_Type) is this: 
"This is the type object for type objects; it is the same object as type and types.TypeType  in the Python layer."

But in py3k there is no types.TypeType object.

----------
assignee: docs at python
components: Documentation
messages: 109560
nosy: docs at python, durban
priority: normal
severity: normal
status: open
title: The documentation of PyType_Type in py3k mentions types.TypeType
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Jul  8 22:00:51 2010
From: report at bugs.python.org (Greg Brockman)
Date: Thu, 08 Jul 2010 20:00:51 +0000
Subject: [New-bugs-announce] [issue9205] Parent process hanging in
	multiprocessing if children	terminate unexpectedly
In-Reply-To: <1278619251.36.0.833806205056.issue9205@psf.upfronthosting.co.za>
Message-ID: <1278619251.36.0.833806205056.issue9205@psf.upfronthosting.co.za>


New submission from Greg Brockman <gdb at ksplice.com>:

I have recently begun using multiprocessing for a variety of batch
jobs.  It's a great library, and it's been quite useful.  However, I have been bitten several times by situations where a worker process in a Pool will unexpectedly die, leaving multiprocessing hanging in a wait.  A simple example of this is produced by the following:
"""
#!/usr/bin/env python
import multiprocessing, sys
def foo(x):
  sys.exit(1)
multiprocessing.Pool(1).apply(foo, [1])
"""
The child will exit and the parent will hang forever.  A similar occurrence happens if one pushes C-c while a child process is running (this special case is noted in http://bugs.python.org/issue8296) or killed by a signal.

Attached is a patch to handle unexpected terminations of children
processes and prevent the parent process from hanging.  A test case is included.  (Developed and tested on 64-bit Ubuntu.)  Please let me know what you think.  Thanks!

----------
components: Library (Lib)
files: termination.patch
keywords: patch
messages: 109585
nosy: gdb
priority: normal
severity: normal
status: open
title: Parent process hanging in multiprocessing if children terminate unexpectedly
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file17905/termination.patch

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

From report at bugs.python.org  Thu Jul  8 22:01:48 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 08 Jul 2010 20:01:48 +0000
Subject: [New-bugs-announce] [issue9206] os.stat() is broken
In-Reply-To: <1278619308.76.0.418560838526.issue9206@psf.upfronthosting.co.za>
Message-ID: <1278619308.76.0.418560838526.issue9206@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Most likely the same underlying problem as in issue 9202, but can be seen on a non-windows platform.

>>> from os import *
>>> stat('/')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: NULL result without error in PyObject_Call

With attached patch, the error message is clearer:

>>> stat('.')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: In structseq_repr()  member 15 name is NULL

----------
assignee: belopolsky
messages: 109586
nosy: belopolsky
priority: high
severity: normal
stage: unit test needed
status: open
title: os.stat() is broken
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Jul  8 22:05:33 2010
From: report at bugs.python.org (Greg Brockman)
Date: Thu, 08 Jul 2010 20:05:33 +0000
Subject: [New-bugs-announce] [issue9207] multiprocessing occasionally spits
	out exception during	shutdown
In-Reply-To: <1278619533.83.0.0853433126095.issue9207@psf.upfronthosting.co.za>
Message-ID: <1278619533.83.0.0853433126095.issue9207@psf.upfronthosting.co.za>


New submission from Greg Brockman <gdb at ksplice.com>:

On Ubuntu 10.04, using freshly-compiled python-from-trunk (as well as multiprocessing-from-trunk), I get tracebacks from the following about 30% of the time:

"""
import multiprocessing, time           
def foo(x):                            
 time.sleep(3)                         
multiprocessing.Pool(1).apply(foo, [1])
"""

My tracebacks are of the form:
"""
Exception in thread Thread-1 (most likely raised during interpreter shutdown):
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/threading.py", line 530, in __bootstrap_inner
  File "/usr/local/lib/python2.7/threading.py", line 483, in run
  File "/usr/local/lib/python2.7/multiprocessing/pool.py", line 272, in _handle_workers
<type 'exceptions.TypeError'>: 'NoneType' object is not callable
"""

This information was originally posted to http://bugs.python.org/issue4106.

----------
components: Library (Lib)
messages: 109588
nosy: gdb
priority: normal
severity: normal
status: open
title: multiprocessing occasionally spits out exception during shutdown
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri Jul  9 00:16:11 2010
From: report at bugs.python.org (norbidur)
Date: Thu, 08 Jul 2010 22:16:11 +0000
Subject: [New-bugs-announce] [issue9208] SMTPHandler does not handle unicode
	strings
In-Reply-To: <1278627371.74.0.0567748809415.issue9208@psf.upfronthosting.co.za>
Message-ID: <1278627371.74.0.0567748809415.issue9208@psf.upfronthosting.co.za>


New submission from norbidur <norbidur at users.sourceforge.net>:

SMTPHandler fails when receiving unicode strings.

example : 
import logging,logging.handlers
smtpHandler = logging.handlers.SMTPHandler(
    mailhost=("smtp.free.fr",25),
    fromaddr="from at free.fr", toaddrs="to at free.fr",
    subject=u"error message")
LOG = logging.getLogger()
LOG.addHandler(smtpHandler)
LOG.error(u"accentu\u00E9")

-> UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 108 : ordinal not in range(128)

There has been a discuss on this in http://groups.google.com/group/comp.lang.python/browse_thread/thread/759df42f9374d1b6/05ad55c388c746e3?lnk=raot&pli=1

FileHandler does not behave the same way : for this handler's family an encoding can be specified, and if this encoding fails, there is a fallback to UTF-8.

----------
components: Unicode
messages: 109621
nosy: norbidur
priority: normal
severity: normal
status: open
title: SMTPHandler does not handle unicode strings
type: behavior
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Fri Jul  9 03:18:10 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Fri, 09 Jul 2010 01:18:10 +0000
Subject: [New-bugs-announce] [issue9209] pstats module crashes on trailing
	backslash
In-Reply-To: <1278638290.01.0.457027619386.issue9209@psf.upfronthosting.co.za>
Message-ID: <1278638290.01.0.457027619386.issue9209@psf.upfronthosting.co.za>


New submission from Ilya Sandler <ilya.sandler at gmail.com>:

a session attached:

cheetah:~/wrk/svn/psi-poly5/poly/aut/prof> ~/comp/python/trunk/python -m pstats prof.out 
Welcome to the profile statistics browser.
% stats 20 \
Thu Jul  8 17:50:27 2010    prof.out

         197258358 function calls (197187736 primitive calls) in 321.090 CPU seconds

Traceback (most recent call last):
  File "/home/ilya/comp/python/trunk/Lib/runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/home/ilya/comp/python/trunk/Lib/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/home/ilya/comp/python/trunk/Lib/pstats.py", line 681, in <module>
    browser.cmdloop()
  File "/home/ilya/comp/python/trunk/Lib/cmd.py", line 142, in cmdloop
    stop = self.onecmd(line)
  File "/home/ilya/comp/python/trunk/Lib/cmd.py", line 219, in onecmd
    return func(arg)
  File "/home/ilya/comp/python/trunk/Lib/pstats.py", line 657, in do_stats
    return self.generic('print_stats', line)
  File "/home/ilya/comp/python/trunk/Lib/pstats.py", line 578, in generic
    getattr(self.stats, fn)(*processed)
  File "/home/ilya/comp/python/trunk/Lib/pstats.py", line 359, in print_stats
    width, list = self.get_print_list(amount)
  File "/home/ilya/comp/python/trunk/Lib/pstats.py", line 332, in get_print_list
    list, msg = self.eval_print_amount(selection, list, msg)
  File "/home/ilya/comp/python/trunk/Lib/pstats.py", line 306, in eval_print_amount
    if re.search(sel, func_std_string(func)):
  File "/home/ilya/comp/python/trunk/Lib/re.py", line 142, in search
    return _compile(pattern, flags).search(string)
  File "/home/ilya/comp/python/trunk/Lib/re.py", line 245, in _compile
    raise error, v # invalid expression
sre_constants.error: bogus escape (end of line)

----------
components: Library (Lib)
messages: 109656
nosy: isandler
priority: normal
severity: normal
status: open
title: pstats module crashes on trailing backslash
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul  9 11:15:17 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 09 Jul 2010 09:15:17 +0000
Subject: [New-bugs-announce] [issue9210] remove --with-wctype-functions
	configure option
In-Reply-To: <1278666917.19.0.275398438928.issue9210@psf.upfronthosting.co.za>
Message-ID: <1278666917.19.0.275398438928.issue9210@psf.upfronthosting.co.za>


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

Quoting Marc-Andre Lemburg:
"""
The support for the wctype functions should have been remove long ago,
since they cause subtle incompatibilities between Python builds. I should
have probably never added it in the first place... people were worried
about the size of the type record tables at the time, which is why
I thought it would be a good idea to try to optionally use the C lib
functions.

The comment was true before the Python type tables were changed
into a type record database: the switch used to remove the
Python tables required for those functions. With the type records
database, this is no longer the case, since the records are also
being used for properties that are not exposed via wctype functions.
"""

----------
components: Unicode
messages: 109696
nosy: amaury.forgeotdarc, ezio.melotti, lemburg
priority: normal
severity: normal
status: open
title: remove --with-wctype-functions configure option
versions: Python 3.2

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

From report at bugs.python.org  Fri Jul  9 11:21:34 2010
From: report at bugs.python.org (Christian Hager)
Date: Fri, 09 Jul 2010 09:21:34 +0000
Subject: [New-bugs-announce] [issue9211] Cannot close socket after ssl
	handshake failed
In-Reply-To: <1278667294.44.0.586266178697.issue9211@psf.upfronthosting.co.za>
Message-ID: <1278667294.44.0.586266178697.issue9211@psf.upfronthosting.co.za>


New submission from Christian Hager <metakaram at gmail.com>:

When running a SSL socket server in Python 2.5 or 2.6 (didn't try with newer versions), new connections are setup with "ssl.wrap_socket()". Everything works fine if I connect a client with SSL, but if I just telnet to the server it's not possible to close the socket anymore (receiving data works fine through the non-ssl socket though).

I get a SSL exception like this: "SSLError: [Errno 1] _ssl.c:480: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol". After that I am not able to close the socket, but still can send data on the non-ssl-wrapped socket. How would I close this now open non-ssl socket?

Simplified code:

read_sockets,write_sockets,error_sockets = select.select(CONNECTION_LIST,[],[])
for sock in read_sockets:
    if sock == server_socket:
        newsock, addr = server_socket.accept()

        # SSL Setup
        try:
            sslsock = ssl.wrap_socket(newsock, server_side=True, certfile="../cert.pem", keyfile="../cert.pem")
            CONNECTION_LIST.append(sslsock)
        except:
            print "ssl handshake failed"

            try: 
                newsock.send("bye\r\n") # succeeds
                newsock.close()         # doesn't work

----------
components: IO
messages: 109697
nosy: metachris
priority: normal
severity: normal
status: open
title: Cannot close socket after ssl handshake failed
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Fri Jul  9 21:03:37 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 09 Jul 2010 19:03:37 +0000
Subject: [New-bugs-announce] [issue9212] dict_keys purports to implement the
	Set ABC, but is missing the isdisjoint method
In-Reply-To: <1278702217.69.0.69895367614.issue9212@psf.upfronthosting.co.za>
Message-ID: <1278702217.69.0.69895367614.issue9212@psf.upfronthosting.co.za>


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

>>> isinstance({}.keys(), collections.Set)
True
>>> [method for method in set(dir(collections.Set)) - set(dir({}.keys()))
...  if not method.startswith('_')]
['isdisjoint']

(in Python 2.7, use "viewkeys()" instead of "keys")

dict_items has the same problem.

----------
assignee: stutzbach
components: Interpreter Core
messages: 109783
nosy: stutzbach
priority: normal
severity: normal
stage: unit test needed
status: open
title: dict_keys purports to implement the Set ABC, but is missing the isdisjoint method
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Jul  9 21:06:15 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 09 Jul 2010 19:06:15 +0000
Subject: [New-bugs-announce] [issue9213] range purports to implement the
	Sequence ABC, but is missing index and count methods
In-Reply-To: <1278702375.23.0.863463663463.issue9213@psf.upfronthosting.co.za>
Message-ID: <1278702375.23.0.863463663463.issue9213@psf.upfronthosting.co.za>


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

>>> isinstance(range, collections.Sequence)
True
>>> [method for method in set(dir(collections.Sequence)) - set(dir(range(1))) if not method.startswith('_')]
['index', 'count']

----------
assignee: stutzbach
components: Interpreter Core
messages: 109784
nosy: stutzbach
priority: normal
severity: normal
stage: unit test needed
status: open
title: range purports to implement the Sequence ABC, but is missing index and count methods
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Jul  9 21:31:45 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 09 Jul 2010 19:31:45 +0000
Subject: [New-bugs-announce] [issue9214] Most Set methods of KeysView and
	ItemsView do not work	right
In-Reply-To: <1278703905.18.0.125671722438.issue9214@psf.upfronthosting.co.za>
Message-ID: <1278703905.18.0.125671722438.issue9214@psf.upfronthosting.co.za>


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

Attached is a simple Python 3 example script that defines a minimalist MutableMapping that simply wraps a dict, followed by:

x = MySimpleMapping(red=5)
y = x.keys()
z = x.keys() | {'orange'}                                          x['blue'] = 7
print(list(z))
print(list(z))

Output:
['blue', 'red', 'orange']
[]

Expected Output:
['orange', 'red']
['orange', 'red']

The problem is that __or__ ends up returning a new KeysView wrapping a generator instead of returning a set.

To solve the problem, KeysView and ItemsView need to override _from_iterable to return a set instead of a new view.

----------
assignee: stutzbach
components: Library (Lib)
files: keysview_test.py
keywords: easy
messages: 109788
nosy: stutzbach
priority: normal
severity: normal
stage: unit test needed
status: open
title: Most Set methods of KeysView and ItemsView do not work right
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17923/keysview_test.py

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

From report at bugs.python.org  Fri Jul  9 23:01:53 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 09 Jul 2010 21:01:53 +0000
Subject: [New-bugs-announce] [issue9215] test_float crashes with assertion
	failure on Ubuntu	buildbot.
In-Reply-To: <1278709313.21.0.942874068814.issue9215@psf.upfronthosting.co.za>
Message-ID: <1278709313.21.0.942874068814.issue9215@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

The Ubuntu i386 buildbot was crashing in test_float in the 3.1 branch;  it looks as though _Py_dg_dtoa is producing invalid results.

I've made a couple of checkins to try to diagnose the failure (r82752 and r82754);  here's some of the resulting output from http://www.python.org/dev//buildbot/builders/i386%20Ubuntu%203.1/builds/870

test_float
Unexpected failure in format_float_short. Arguments: d = 9999, format_code = 101, mode = 2, precision = 3
digits == :
Unexpected failure in format_float_short. Arguments: d = 0.096000000000000002, format_code = 102, mode = 3, precision = 2
digits == :

':' is the ASCII character after '9', so this is a classic case of the digit '9' being rounded up to the next ASCII digit.  I don't know why this is happening on this particular buildbot and no others that I've noticed.

This machine is one where double rounding *is* typically a problem (according to its configure output), so it should be using the _Py_{set,get}_387controlword functions to control the FPU precision;  perhaps something's going wrong with this step.

----------
assignee: mark.dickinson
messages: 109796
nosy: eric.smith, mark.dickinson
priority: high
severity: normal
status: open
title: test_float crashes with assertion failure on Ubuntu buildbot.
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Sat Jul 10 02:22:15 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Sat, 10 Jul 2010 00:22:15 +0000
Subject: [New-bugs-announce] [issue9216] FIPS support for hashlib
In-Reply-To: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za>
Message-ID: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za>


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

(taking the liberty of adding gregory.p.smith to the "nosy" list; hope that's OK)

This is a higher-level take on issue 9146.

Some versions of OpenSSL have a FIPS mode that can refuse the use of non-certified hashes.

The idea is that FIPS mode should prevent the use of non-certified hashes for security uses.  For example, MD5 shouldn't be used for signatures these days (see e.g. http://www.kb.cert.org/vuls/id/836068).

However, there are legitimate non-security uses of these hashes.  For example, one might use MD5 hashes of objects to places them in bins for later retrieval, purely as a speed optimization (e.g. files in directories on a filesystem).

I'm working on a patch to hashlib which would better support this, but it involves an API expansion, and I wanted to sound things out first.

The API idea is to introduce a new keyword argument, say "usedforsecurity" to hashlib.new() and to the named hashlib constructors, such as hashlib.md5().  This would default to True.  If code is using these hashes in FIPS mode, the developer needs to override this: usedforsecurity=False to mark the callsite as a non-security-sensitive location.  Internally, this would lead to the EVP_MD_CTX being initialized with EVP_MD_CTX_FLAG_NON_FIPS_ALLOW.

This way, if you run unaudited code in an environment that cares about FIPS, the code will raise exceptions if it uses a non-valid hash, but during code audit the callsites can be marked clearly as "usedforsecurity=False", and be used as before.

In non-FIPS environments, the flag would be ignored.

Am I right in thinking that the _hashlib module should be treated as an implementation detail here?  The entry points within _hashlib are likely to double, with a pair of pre-initialized contexts, one with the flag, one without.

Does this sound reasonable?  Thanks.

----------
components: Library (Lib)
messages: 109808
nosy: dmalcolm, gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: FIPS support for hashlib
versions: Python 3.2

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

From report at bugs.python.org  Sat Jul 10 21:27:50 2010
From: report at bugs.python.org (Tiago Antao)
Date: Sat, 10 Jul 2010 19:27:50 +0000
Subject: [New-bugs-announce] [issue9217] 2to3 crashes with some doctests
In-Reply-To: <1278790070.07.0.615684286831.issue9217@psf.upfronthosting.co.za>
Message-ID: <1278790070.07.0.615684286831.issue9217@psf.upfronthosting.co.za>


New submission from Tiago Antao <tiagoantao at gmail.com>:

2to3 -d sometimes crashes.

The problem seems to be in refactor_doctest. The problematic line is:
if self.log.isEnabledFor(logging.DEBUG):
self.log does not exist. The error, as expected:
  File "/usr/lib/python3.1/lib2to3/refactor.py", line 516, in refactor_doctest
    if self.log.isEnabledFor(logging.DEBUG):
AttributeError: 'StdoutRefactoringTool' object has no attribute 'log'

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 109911
nosy: tiagoantao
priority: normal
severity: normal
status: open
title: 2to3 crashes with some doctests
versions: Python 3.1

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

From report at bugs.python.org  Sat Jul 10 21:30:09 2010
From: report at bugs.python.org (Diego Jacobi)
Date: Sat, 10 Jul 2010 19:30:09 +0000
Subject: [New-bugs-announce] [issue9218] pop multiple elements of a list at
	once
In-Reply-To: <1278790209.67.0.359453381678.issue9218@psf.upfronthosting.co.za>
Message-ID: <1278790209.67.0.359453381678.issue9218@psf.upfronthosting.co.za>


New submission from Diego Jacobi <jacobidiego at gmail.com>:

I am currently working with buffer in an USB device and pyusb.
So when i read from a buffer endpoint i get an array.Array() list.
I handle this chunk of data with a thread to send a receive the information that i need. In this thread i load a list with all the information that is read from the USB device, and another layer with pop this information from the threads buffer.

The thing i found is that, to pop a variable chunk of data from this buffer without copying it and deleting the elements, i have to pop one element at the time.

    def get_chunk(self, size):
        for x in range(size):
            yield self.recv_buffer.pop()

I guess that it would be improved if i can just pop a defined number of elements, like this:

pop self.recv_buffer[:size]
or
self.recv_buffer.pop(,-size)

That would be... "pop from the last element minus size to the last element"
in that way there is only one memory transaction.
The new list points to the old memory address and the recv_buffer is advanced to a new address. Data is not moved.

note that i like the idea of using "pop" as the "del" operator for lists

thanks.
Diego

----------
messages: 109912
nosy: jacobidiego
priority: normal
severity: normal
status: open
title: pop multiple elements of a list at once
type: performance
versions: Python 2.6

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

From report at bugs.python.org  Sat Jul 10 21:51:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Jul 2010 19:51:07 +0000
Subject: [New-bugs-announce] [issue9219] Make reindent-rst.py preserve ^L
In-Reply-To: <1278791467.43.0.414939089844.issue9219@psf.upfronthosting.co.za>
Message-ID: <1278791467.43.0.414939089844.issue9219@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Tools/scripts/reindent-rst.py strips trailing whitespace from reST files, including ^L. ISTM that this character is always used explicitly, not by oversight, e.g. by people wanting their editor to paginate files like plain text PEPs. I suggest that the regex at the core of the script be changed to let ^L alone.

This is arguably a bug fix, depending on your definition of ?trailing whitespace?, but I?m not sure at all whether it should be in 2.7.1.

----------
keywords: easy
messages: 109918
nosy: merwok
priority: low
severity: normal
status: open
title: Make reindent-rst.py preserve ^L
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Jul 10 21:52:30 2010
From: report at bugs.python.org (Jim Fulton)
Date: Sat, 10 Jul 2010 19:52:30 +0000
Subject: [New-bugs-announce] [issue9220] Modules no longer usable as context
	managers
In-Reply-To: <1278791550.43.0.759341928181.issue9220@psf.upfronthosting.co.za>
Message-ID: <1278791550.43.0.759341928181.issue9220@psf.upfronthosting.co.za>


New submission from Jim Fulton <jim at zope.com>:

In python 2.7 a module can't be used as a context manager.

For example, given the module, t.py:

    def __enter__(*args):
        print 'enter', args

    def __exit__(*args):
        print 'exit', args

In Python 2.6:

    >>> import t
    >>> with t: pass
    ... 
    enter ()
    exit (None, None, None)

In Python 2.7:

    >>> import t
    >>> with t: pass
    ... 
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    AttributeError: __exit__

----------
components: Interpreter Core
messages: 109920
nosy: j1m
priority: normal
severity: normal
status: open
title: Modules no longer usable as context managers
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Jul 10 22:12:28 2010
From: report at bugs.python.org (Tiago Antao)
Date: Sat, 10 Jul 2010 20:12:28 +0000
Subject: [New-bugs-announce] [issue9221] 2to3 fails to parse a for construct
In-Reply-To: <1278792748.61.0.873837385139.issue9221@psf.upfronthosting.co.za>
Message-ID: <1278792748.61.0.873837385139.issue9221@psf.upfronthosting.co.za>


New submission from Tiago Antao <tiagoantao at gmail.com>:

2to3 crashes with a apparently simple for.
An example is presented (the first line is actually enough)

        >>> for clade in tree.find_clades(branch_length=True, order='level'):
        >>>     if (clade.branch_length < .5 and
        >>>         not clade.is_terminal() and
        >>>         clade is not self.root):
        >>>         tree.collapse(clade)

The stack is shown below. It almost seems a problem with newline conversion at the end?

RefactoringTool: Can't parse docstring in xx2 line 1: ParseError: bad input: type=0, value='', context=('', (2, 0))
RefactoringTool: Can't parse docstring in xx2 line 2: ParseError: bad input: type=5, value='    ', context=('\n', (2, 0))
RefactoringTool: Can't parse docstring in xx2 line 3: ParseError: bad input: type=5, value='        ', context=('\n\n', (3, 0))
RefactoringTool: Can't parse docstring in xx2 line 4: ParseError: bad input: type=5, value='        ', context=('\n\n\n', (4, 0))
RefactoringTool: Can't parse docstring in xx2 line 5: ParseError: bad input: type=5, value='        ', context=('\n\n\n\n', (5, 0))
RefactoringTool: No files need to be modified.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 109929
nosy: tiagoantao
priority: normal
severity: normal
status: open
title: 2to3 fails to parse a for construct
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Sun Jul 11 02:44:12 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 11 Jul 2010 00:44:12 +0000
Subject: [New-bugs-announce] [issue9222] IDLE: Fix open/saveas 'Files of
	type' choices
In-Reply-To: <1278809052.13.0.969100167059.issue9222@psf.upfronthosting.co.za>
Message-ID: <1278809052.13.0.969100167059.issue9222@psf.upfronthosting.co.za>


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

In the open and save-as dialog boxes, the choices for the 'Files of type' field are governed by the filetypes list in Lib\idlelib\IOBinding.py, about line 225 (found by a friend).

    filetypes = [
        ("Python and text files", "*.py *.pyw *.txt", "TEXT"),
        ("All text files", "*", "TEXT"),
        ("All files", "*"),
        ]

I see multiple problems with this:

1. The first line, which for me is the default, mixes Python and text files, while one nearly only wants to only search through Python files. I propose to remove 'and text' and '*.txt'.

2. The second line, which would currently be redundant with the first if it did what it said (but would not be with the first fix), has a bug in the file spec, '*' instead of '*.txt', that makes it redundant with the third line. I propose to fix that bug.

The following is copied from my patched and tested version of the file:

    filetypes = [
        ("Python files", "*.py *.pyw", "TEXT"),
        ("Text files", "*.txt", "TEXT"),
        ("All files", "*"),
        ]

So this is a trivial 2 line patch.

----------
components: IDLE
keywords: easy
messages: 109951
nosy: tjreedy
priority: normal
severity: normal
status: open
title: IDLE: Fix open/saveas 'Files of type' choices
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Jul 11 11:55:18 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 11 Jul 2010 09:55:18 +0000
Subject: [New-bugs-announce] [issue9223] distutils Command docs linking
In-Reply-To: <1278842118.98.0.447580746047.issue9223@psf.upfronthosting.co.za>
Message-ID: <1278842118.98.0.447580746047.issue9223@psf.upfronthosting.co.za>


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

There are a couple of chapters about implementing a command in distutils docs that should be linked together.

http://docs.python.org/distutils/extending.html#extending-distutils should link to http://docs.python.org/distutils/apiref.html#distutils.cmd.Command and the latter to http://docs.python.org/distutils/apiref.html#creating-a-new-distutils-command (or merged).

----------
assignee: tarek
components: Distutils
messages: 109979
nosy: tarek, techtonik
priority: normal
severity: normal
status: open
title: distutils Command docs linking

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

From report at bugs.python.org  Sun Jul 11 15:36:59 2010
From: report at bugs.python.org (ipatrol)
Date: Sun, 11 Jul 2010 13:36:59 +0000
Subject: [New-bugs-announce] [issue9224] Distutls fails with MSVC++ 2008on
	Windows Vista 64bit
In-Reply-To: <1278855419.68.0.64475748771.issue9224@psf.upfronthosting.co.za>
Message-ID: <1278855419.68.0.64475748771.issue9224@psf.upfronthosting.co.za>


New submission from ipatrol <ipatrol6010 at yahoo.com>:

Trying to compile any extension module fails with the following error:

running install
running build
running build_ext
building 'bsdiff' extension
Traceback (most recent call last):
  File "setup.py", line 56, in <module>
    ext_modules = [extension])
  File "C:\hp\bin\Python\lib\distutils\core.py", line 152, in setup
    dist.run_commands()
	[Skipping many levels for brevity]
  File "C:\hp\bin\Python\lib\distutils\msvc9compiler.py", line 469, in compile
    self.initialize()
  File "C:\hp\bin\Python\lib\distutils\msvc9compiler.py", line 379, in initialize
    vc_env = query_vcvarsall(VERSION, plat_spec)
  File "C:\hp\bin\Python\lib\distutils\msvc9compiler.py", line 295, in query_vcvarsall
    raise ValueError(str(list(result.keys())))
ValueError: [u'path']

here, \hp\bin is a vista symlink to Python's directory. This is the second version that had this error, with several modules as well.

It appears to be an issue in msvc9compiler's handling of stdout, will try to patch.

----------
assignee: tarek
components: Distutils, Extension Modules, Windows
messages: 110008
nosy: ipatrol, tarek
priority: normal
severity: normal
status: open
title: Distutls fails with MSVC++ 2008on Windows Vista 64bit
type: compile error
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Sun Jul 11 20:49:41 2010
From: report at bugs.python.org (Demur Rumed)
Date: Sun, 11 Jul 2010 18:49:41 +0000
Subject: [New-bugs-announce] [issue9225] Replace DUP_TOPX with DUP_TOP_TWO
In-Reply-To: <1278874181.81.0.745105188712.issue9225@psf.upfronthosting.co.za>
Message-ID: <1278874181.81.0.745105188712.issue9225@psf.upfronthosting.co.za>


New submission from Demur Rumed <junkmute at hotmail.com>:

DUP_TOPX(3) is never used, nor is ROT_FOUR. This patch removes the opcodes, replacing DUP_TOPX with DUP_TOP_TWO

Oddly, at least with pybench, use of PREDICT(BINARY_SUBSCR) in DUP_TOP_TWO seems to show an always right PREDICT as slower than FAST_DISPATCH

----------
components: Interpreter Core
files: duptoptwo.patch
keywords: patch
messages: 110035
nosy: serprex
priority: normal
severity: normal
status: open
title: Replace DUP_TOPX with DUP_TOP_TWO
type: performance
Added file: http://bugs.python.org/file17949/duptoptwo.patch

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

From report at bugs.python.org  Sun Jul 11 21:56:36 2010
From: report at bugs.python.org (Chris Monsanto)
Date: Sun, 11 Jul 2010 19:56:36 +0000
Subject: [New-bugs-announce] [issue9226] erroneous behavior when creating
	classes inside a closure
In-Reply-To: <1278878196.2.0.124754685152.issue9226@psf.upfronthosting.co.za>
Message-ID: <1278878196.2.0.124754685152.issue9226@psf.upfronthosting.co.za>


New submission from Chris Monsanto <chris at monsan.to>:

I have a function whose closure contains a local variable that shadows a global variable (lets call it x). If I create a class as follows: 

class Test(object): x = x

Test.x will contain the value of the global x, not the local x. This ONLY happens when the names are the same, and it only happens in the class body; i.e., "class Test(object): y = x" and class "Test(object): pass; Test.x = x" work fine.

However, if there is an assignment x = x AND you make other assignments, such as y = x, in the body, the other variables will have the wrong value too.

Test case attached. Problem noticed on Python 2.6.2 on Windows and 2.6.5 on Linux.

----------
files: test.py
messages: 110037
nosy: monsanto
priority: normal
severity: normal
status: open
title: erroneous behavior when creating classes inside a closure
versions: Python 2.6
Added file: http://bugs.python.org/file17950/test.py

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

From report at bugs.python.org  Sun Jul 11 23:31:46 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 11 Jul 2010 21:31:46 +0000
Subject: [New-bugs-announce] [issue9227] can't import Tkinter / use IDLE
	after installing Python	2.7 on Mac OS X
In-Reply-To: <1278883906.89.0.545374403914.issue9227@psf.upfronthosting.co.za>
Message-ID: <1278883906.89.0.545374403914.issue9227@psf.upfronthosting.co.za>


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

After installing Python 2.7 for Mac OS X from the Python.org binary I can't use Tkinter or IDLE.

I installed the following, on Snow Leopard:

* Python 2.7 PPC/i386/x86-64 Max OS X Installer Disk Image 


>>> import Tkinter
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/Tkinter.py", line 39, in <module>
    import _tkinter # If this fails your Python may not be configured for Tk
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so, 2): no suitable image found.  Did find:
	/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so: no matching architecture in universal wrapper

----------
assignee: ronaldoussoren
components: Macintosh
messages: 110051
nosy: michael.foord, ronaldoussoren
priority: normal
severity: normal
status: open
title: can't import Tkinter / use IDLE after installing Python 2.7 on Mac OS X
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul 12 01:51:27 2010
From: report at bugs.python.org (ipatrol)
Date: Sun, 11 Jul 2010 23:51:27 +0000
Subject: [New-bugs-announce] [issue9228] Make changes in the path and
	pathext on installation
In-Reply-To: <1278892287.6.0.671523214632.issue9228@psf.upfronthosting.co.za>
Message-ID: <1278892287.6.0.671523214632.issue9228@psf.upfronthosting.co.za>


New submission from ipatrol <ipatrol6010 at yahoo.com>:

I was fiddling around with easier ways to run python scripts in the Windows shell. I'll represent these as hypothetical AUTOEXEC.BAT entries (I used the UI for this):

;Add python to the search path so "python script.py" works
set path="%path%;C:\Python27"
;Add .py to the executable list so "script.py" works
set pathext="%pathext%;.PY"
;And finally (I couldn't find any other way) "script" works
set .py=python.exe

I think it would be a good idea to do this on installation. Any improvements and actual implementations using the registry would be greatly appreciated (especially since autoexec.bat isn't used anymore).

----------
components: Installation, Windows
messages: 110056
nosy: ipatrol
priority: normal
severity: normal
status: open
title: Make changes in the path and pathext on installation
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul 12 04:46:18 2010
From: report at bugs.python.org (Matt Gattis)
Date: Mon, 12 Jul 2010 02:46:18 +0000
Subject: [New-bugs-announce] [issue9229] memoryview of mmap object not
	working in 2.7
In-Reply-To: <1278902778.58.0.779431592784.issue9229@psf.upfronthosting.co.za>
Message-ID: <1278902778.58.0.779431592784.issue9229@psf.upfronthosting.co.za>


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

This code works in 3.1.2 but not in 2.7:

>>> import mmap
>>> m = mmap.mmap(-1,20)
>>> v = memoryview(m)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot make memory view because object does not have the buffer interface

----------
components: Extension Modules, IO
messages: 110063
nosy: Matt.Gattis
priority: normal
severity: normal
status: open
title: memoryview of mmap object not working in 2.7
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul 12 05:56:30 2010
From: report at bugs.python.org (Ivan Pozdeev)
Date: Mon, 12 Jul 2010 03:56:30 +0000
Subject: [New-bugs-announce] [issue9230] pdb.Pdb.checkline() throws
	AttributeError if called	before starting a debug session
In-Reply-To: <1278906990.65.0.476539166106.issue9230@psf.upfronthosting.co.za>
Message-ID: <1278906990.65.0.476539166106.issue9230@psf.upfronthosting.co.za>


New submission from Ivan Pozdeev <ivan_pozdeev at mail.ru>:

pdb.Pdb.checkline() throws AttributeError at pdb.py:470 if invoked before starting a debugging session because self.curframe doesn't exist at that time.

This breaks IPython's %run magic command (v0.10, Magic.py:1663). The command sets a breakpoint before running the script and scans the file before that to make sure the breakpoint is set on an executable line. 

This is a reasonable thing to do: setting a breakpoint and making sure it is set correctly shouldn't require a running debug session. So i conclude it is pdb, not IPython, that shall be fixed.

The patch attached gives linecache.getline() None as module_globals if self.curframe doesn't exist.

The rationale is: even if the script does use PEP302 import stuff, we can't know or use that before running it. So it's ok if we stay limited with usual paths.

----------
components: Library (Lib)
files: pdb_checkline.patch
keywords: patch
messages: 110065
nosy: __Vano
priority: normal
severity: normal
status: open
title: pdb.Pdb.checkline() throws AttributeError if called before starting a debug session
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file17955/pdb_checkline.patch

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

From report at bugs.python.org  Mon Jul 12 12:27:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Jul 2010 10:27:02 +0000
Subject: [New-bugs-announce] [issue9231] IDLE interactive interpreter crash
In-Reply-To: <1278930422.83.0.430271709302.issue9231@psf.upfronthosting.co.za>
Message-ID: <1278930422.83.0.430271709302.issue9231@psf.upfronthosting.co.za>


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

After a few keystrokes in the interactive interpreter, I got the
following traceback:

Traceback (most recent call last):
  File "Lib/idlelib/idle.py", line 11, in <module>
    idlelib.PyShell.main()
  File "/home/antoine/py3k/__svn__/Lib/idlelib/PyShell.py", line 1420,
in main
    root.mainloop()
  File "/home/antoine/py3k/__svn__/Lib/tkinter/__init__.py", line 1009,
in mainloop
    self.tk.mainloop(n)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xc0 in position 0:
invalid start byte


The keystrokes were ['d', 'i', Ctrl+Space], which briefly displayed the
completion popup before crashing.

----------
components: IDLE
messages: 110077
nosy: pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: IDLE interactive interpreter crash
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Mon Jul 12 16:30:17 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Jul 2010 14:30:17 +0000
Subject: [New-bugs-announce] [issue9232] Allow trailing comma in any
	function argument list.
In-Reply-To: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za>
Message-ID: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Python's current grammar allows a trailing comma after the argument list in:

def f(a, b,):
    pass

but not in

def f(*, a, b,):
    pass

I propose allowing trailing commas in both situations.

See python-dev discussion starting at

http://mail.python.org/pipermail/python-dev/2010-July/101636.html

----------
components: Interpreter Core
messages: 110089
nosy: mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: Allow trailing comma in any function argument list.
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Mon Jul 12 17:47:45 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Mon, 12 Jul 2010 15:47:45 +0000
Subject: [New-bugs-announce] [issue9233] json.load failure when C
	optimizations aren't built
In-Reply-To: <1278949665.57.0.214129757073.issue9233@psf.upfronthosting.co.za>
Message-ID: <1278949665.57.0.214129757073.issue9233@psf.upfronthosting.co.za>


New submission from Fred L. Drake, Jr. <fdrake at acm.org>:

The json decoder doesn't pass tests when the C optimizations in the _json module aren't available.  The actual test failures appear fairly superficial, but aren't the limit of the problems.

Empty objects are converted to empty lists instead of empty dictionaries when _json isn't available; test attached.

Issue 5723 notes that the pure-Python implementation isn't tested; fixing that might have avoided these problems.

Test failures from Python 2.6.5:

======================================================================
ERROR: test_c_encode_basestring_ascii (json.tests.test_encode_basestring_ascii.TestEncodeBaseStringAscii)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/fdrake/src/Python-2.6.5/Lib/json/tests/test_encode_basestring_ascii.py", line 29, in test_c_encode_basestring_ascii
    self._test_encode_basestring_ascii(json.encoder.c_encode_basestring_ascii)
  File "/home/fdrake/src/Python-2.6.5/Lib/json/tests/test_encode_basestring_ascii.py", line 32, in _test_encode_basestring_ascii
    fname = encode_basestring_ascii.__name__
AttributeError: 'NoneType' object has no attribute '__name__'

======================================================================
ERROR: test_c_scanstring (json.tests.test_scanstring.TestScanString)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/fdrake/src/Python-2.6.5/Lib/json/tests/test_scanstring.py", line 13, in test_c_scanstring
    self._test_scanstring(json.decoder.c_scanstring)
  File "/home/fdrake/src/Python-2.6.5/Lib/json/tests/test_scanstring.py", line 17, in _test_scanstring
    scanstring('"z\\ud834\\udd20x"', 1, None, True),
TypeError: 'NoneType' object is not callable

======================================================================
FAIL: test_encode_basestring_ascii (json.tests.test_speedups.TestSpeedups)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/fdrake/src/Python-2.6.5/Lib/json/tests/test_speedups.py", line 13, in test_encode_basestring_ascii
    self.assertEquals(encoder.encode_basestring_ascii.__module__, "_json")
AssertionError: 'json.encoder' != '_json'

======================================================================
FAIL: test_scanstring (json.tests.test_speedups.TestSpeedups)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/fdrake/src/Python-2.6.5/Lib/json/tests/test_speedups.py", line 9, in test_scanstring
    self.assertEquals(decoder.scanstring.__module__, "_json")
AssertionError: 'json.decoder' != '_json'


Test failures from 2.7:

======================================================================
ERROR: test_c_scanstring (json.tests.test_scanstring.TestScanString)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/fdrake/src/Python-2.7/Lib/json/tests/test_scanstring.py", line 13, in test_c_scanstring
    self._test_scanstring(json.decoder.c_scanstring)
  File "/home/fdrake/src/Python-2.7/Lib/json/tests/test_scanstring.py", line 17, in _test_scanstring
    scanstring('"z\\ud834\\udd20x"', 1, None, True),
TypeError: 'NoneType' object is not callable

======================================================================
FAIL: test_encode_basestring_ascii (json.tests.test_speedups.TestSpeedups)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/fdrake/src/Python-2.7/Lib/json/tests/test_speedups.py", line 12, in test_encode_basestring_ascii
    self.assertEquals(encoder.encode_basestring_ascii.__module__, "_json")
AssertionError: 'json.encoder' != '_json'

======================================================================
FAIL: test_scanstring (json.tests.test_speedups.TestSpeedups)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/fdrake/src/Python-2.7/Lib/json/tests/test_speedups.py", line 8, in test_scanstring
    self.assertEquals(decoder.scanstring.__module__, "_json")
AssertionError: 'json.decoder' != '_json'

----------
components: Library (Lib)
files: test-empty-json-object.diff
keywords: patch
messages: 110099
nosy: fdrake
priority: normal
severity: normal
status: open
title: json.load failure when C optimizations aren't built
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file17966/test-empty-json-object.diff

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

From report at bugs.python.org  Mon Jul 12 22:09:07 2010
From: report at bugs.python.org (Adrian Sampson)
Date: Mon, 12 Jul 2010 20:09:07 +0000
Subject: [New-bugs-announce] [issue9234] argparse: aliases for positional
	arguments (subparsers)
In-Reply-To: <1278965347.63.0.908625805717.issue9234@psf.upfronthosting.co.za>
Message-ID: <1278965347.63.0.908625805717.issue9234@psf.upfronthosting.co.za>


New submission from Adrian Sampson <asampson at cs.washington.edu>:

The argparse module supports "subparsers," which allow CLI tools to support invocation of subcommands (much like the svn or hg programs). For these subcommands, it is often useful to allow multiple names for the same command. For instance, in Mercurial, "hg blame" does the same thing as "hg annotate".

You should be able to create subparsers with command aliases, like this:
>>> subparsers.add_parser("annotate", aliases=('ann', 'blame'))

The help message for the program should display the aliases alongisde the command names.

I'm attaching an example script that adds an Action to the library to accomplish this. This isn't a patch, but if this approach seems right to other people, I'll turn it into a patch.

Here's this bug on argparse's old tracker:
http://code.google.com/p/argparse/issues/detail?id=23

----------
components: Library (Lib)
files: aliases.py
messages: 110130
nosy: asampson
priority: normal
severity: normal
status: open
title: argparse: aliases for positional arguments (subparsers)
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file17971/aliases.py

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

From report at bugs.python.org  Mon Jul 12 22:40:35 2010
From: report at bugs.python.org (Yaroslav Halchenko)
Date: Mon, 12 Jul 2010 20:40:35 +0000
Subject: [New-bugs-announce] [issue9235] missing "import sys" in
	Tools/gdb/libpython.py
In-Reply-To: <1278967235.19.0.848515468243.issue9235@psf.upfronthosting.co.za>
Message-ID: <1278967235.19.0.848515468243.issue9235@psf.upfronthosting.co.za>


New submission from Yaroslav Halchenko <yarikoptic at gmail.com>:

as you can see from below, sys. is used, but never imported (besides a docstring)


$> git describe
upstream/0.5.0.dev-875-gf06319e

$> grep -5 'sys' /home/yoh/proj/misc/python/Tools/gdb/libpython.py

"""
During development, I've been manually invoking the code in this way:
(gdb) python

import sys
sys.path.append('/home/david/coding/python-gdb')
import libpython
end

then reloading it after each edit like this:
(gdb) python reload(libpython)
--

    def print_summary(self):
        if self.is_evalframeex():
            pyop = self.get_pyop()
            if pyop:
                sys.stdout.write('#%i %s\n' % (self.get_index(), pyop.get_truncated_repr(MAX_OUTPUT_LEN)))
                sys.stdout.write(pyop.current_line())
            else:
                sys.stdout.write('#%i (unable to read python frame information)\n' % self.get_index())
        else:
            sys.stdout.write('#%i\n' % self.get_index())

class PyList(gdb.Command):
    '''List the current Python source code, if any

    Use
--
            for i, line in enumerate(all_lines[start-1:end]):
                linestr = str(i+start)
                # Highlight current line:
                if i + start == lineno:
                    linestr = '>' + linestr
                sys.stdout.write('%4s    %s' % (linestr, line))


# ...and register the command:
PyList()

----------
components: Demos and Tools
messages: 110134
nosy: Yaroslav.Halchenko
priority: normal
severity: normal
status: open
title: missing "import sys" in Tools/gdb/libpython.py
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul 12 23:07:10 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 12 Jul 2010 21:07:10 +0000
Subject: [New-bugs-announce] [issue9236] Invalid reads in fastsearch.h
In-Reply-To: <1278968830.4.0.450614560792.issue9236@psf.upfronthosting.co.za>
Message-ID: <1278968830.4.0.450614560792.issue9236@psf.upfronthosting.co.za>


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

In test_bytes Valgrind finds two reads with negative array indices.


test_bytes
==7341== Invalid read of size 1
==7341==    at 0x4EDA24: fastsearch (fastsearch.h:143)
==7341==    by 0x4F170E: bytearray_find_internal (find.h:42)
==7341==    by 0x4F17BD: bytearray_rindex (bytearrayobject.c:1267)
==7341==    by 0x49DDA0: PyEval_EvalFrameEx (ceval.c:4322)
==7341==    by 0x49FD2A: PyEval_EvalCodeEx (ceval.c:3252)
==7341==    by 0x49D741: PyEval_EvalFrameEx (ceval.c:4108)
==7341==    by 0x49E155: PyEval_EvalFrameEx (ceval.c:4098)
==7341==    by 0x49FD2A: PyEval_EvalCodeEx (ceval.c:3252)
==7341==    by 0x4FE1BE: function_call (funcobject.c:526)
==7341==    by 0x41AE8C: PyObject_Call (abstract.c:2522)
==7341==    by 0x49B9AB: PyEval_EvalFrameEx (ceval.c:4325)
==7341==    by 0x49FD2A: PyEval_EvalCodeEx (ceval.c:3252)
==7341==  Address 0xcfd37df is 1 bytes before a block of size 6 alloc'd
==7341==    at 0x4C2412C: malloc (vg_replace_malloc.c:195)
==7341==    by 0x4C241A6: realloc (vg_replace_malloc.c:476)
==7341==    by 0x4EF441: PyByteArray_Resize (bytearrayobject.c:259)
==7341==    by 0x4F0F8A: bytearray_iconcat (bytearrayobject.c:340)
==7341==    by 0x4F113E: bytearray_init (bytearrayobject.c:810)
==7341==    by 0x468531: type_call (typeobject.c:723)
==7341==    by 0x41AE8C: PyObject_Call (abstract.c:2522)
==7341==    by 0x499129: PyEval_EvalFrameEx (ceval.c:4230)
==7341==    by 0x49E155: PyEval_EvalFrameEx (ceval.c:4098)
==7341==    by 0x49FD2A: PyEval_EvalCodeEx (ceval.c:3252)
==7341==    by 0x4FE1BE: function_call (funcobject.c:526)
==7341==    by 0x41AE8C: PyObject_Call (abstract.c:2522)
==7341== 
==7341== 
==7341== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y
==7341== starting debugger with cmd: /usr/bin/gdb -nw /proc/7507/fd/1014 7507
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Attaching to program: /proc/7507/fd/1014, process 7507
fastsearch (s=0xcfd37e0 "world", n=0, p=0xa0170b4 "worm", m=4, maxcount=<value optimized out>, mode=2) at Objects/stringlib/fastsearch.h:143
143                     if (!STRINGLIB_BLOOM(mask, s[i-1]))
(gdb) p i
$1 = 0




==7341== 
==7341== Debugger has detached.  Valgrind regains control.  We continue.
==7341== Invalid read of size 1
==7341==    at 0x4ED9B0: fastsearch (fastsearch.h:149)
==7341==    by 0x4F0938: bytearray_rsplit (split.h:311)
==7341==    by 0x49E6C1: PyEval_EvalFrameEx (ceval.c:4012)
==7341==    by 0x49E155: PyEval_EvalFrameEx (ceval.c:4098)
==7341==    by 0x49FD2A: PyEval_EvalCodeEx (ceval.c:3252)
==7341==    by 0x4FE1BE: function_call (funcobject.c:526)
==7341==    by 0x41AE8C: PyObject_Call (abstract.c:2522)
==7341==    by 0x49B9AB: PyEval_EvalFrameEx (ceval.c:4325)
==7341==    by 0x49FD2A: PyEval_EvalCodeEx (ceval.c:3252)
==7341==    by 0x4FE1BE: function_call (funcobject.c:526)
==7341==    by 0x41AE8C: PyObject_Call (abstract.c:2522)
==7341==    by 0x42237E: instancemethod_call (classobject.c:2578)
==7341==  Address 0xf7c508f is 1 bytes before a block of size 12 alloc'd
==7341==    at 0x4C2412C: malloc (vg_replace_malloc.c:195)
==7341==    by 0x4C241A6: realloc (vg_replace_malloc.c:476)
==7341==    by 0x4EF441: PyByteArray_Resize (bytearrayobject.c:259)
==7341==    by 0x4F0F8A: bytearray_iconcat (bytearrayobject.c:340)
==7341==    by 0x4F113E: bytearray_init (bytearrayobject.c:810)
==7341==    by 0x468531: type_call (typeobject.c:723)
==7341==    by 0x41AE8C: PyObject_Call (abstract.c:2522)
==7341==    by 0x499129: PyEval_EvalFrameEx (ceval.c:4230)
==7341==    by 0x49E155: PyEval_EvalFrameEx (ceval.c:4098)
==7341==    by 0x49FD2A: PyEval_EvalCodeEx (ceval.c:3252)
==7341==    by 0x4FE1BE: function_call (funcobject.c:526)
==7341==    by 0x41AE8C: PyObject_Call (abstract.c:2522)
==7341== 
==7341== 
==7341== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y
==7341== starting debugger with cmd: /usr/bin/gdb -nw /proc/7534/fd/1014 7534
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Attaching to program: /proc/7534/fd/1014, process 7534
fastsearch (s=0xf7c5090 "mississippi", n=0, p=0x9eba16c "ss", m=2, maxcount=-1, mode=2) at Objects/stringlib/fastsearch.h:149
149                     if (!STRINGLIB_BLOOM(mask, s[i-1]))
(gdb) p i
$1 = 0

----------
components: Interpreter Core
messages: 110140
nosy: skrah
priority: normal
severity: normal
status: open
title: Invalid reads in fastsearch.h
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jul 13 00:29:24 2010
From: report at bugs.python.org (rocky bernstein)
Date: Mon, 12 Jul 2010 22:29:24 +0000
Subject: [New-bugs-announce] [issue9237] Add sys.call_tracing to on-line sys
	module documentation
In-Reply-To: <1278973764.17.0.0501374635668.issue9237@psf.upfronthosting.co.za>
Message-ID: <1278973764.17.0.0501374635668.issue9237@psf.upfronthosting.co.za>


New submission from rocky bernstein <rocky at gnu.org>:

sys.call_tracing doesn't appear in Python documents and I think it should. For a start, one could use the docstring from sysmodule.c:

 call_tracing(func, args) -> object

 Call func(*args), while tracing is enabled.  The tracing state is saved, and restored afterwards.  This is intended to be called from a
debugger from a checkpoint, to recursively debug some other code.

Thanks.

----------
assignee: docs at python
components: Documentation
messages: 110145
nosy: docs at python, rocky
priority: normal
severity: normal
status: open
title: Add sys.call_tracing  to on-line sys module documentation
type: feature request
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Jul 13 01:33:24 2010
From: report at bugs.python.org (Ryan Kelly)
Date: Mon, 12 Jul 2010 23:33:24 +0000
Subject: [New-bugs-announce] [issue9238] zipfile incorrectly documented as
	not supporting archive	comments
In-Reply-To: <1278977604.77.0.794237265554.issue9238@psf.upfronthosting.co.za>
Message-ID: <1278977604.77.0.794237265554.issue9238@psf.upfronthosting.co.za>


New submission from Ryan Kelly <ryan at rfk.id.au>:

The zipfile module is prominently documented as "This module does not currently handle...ZIP files which have appended comments".  But as far as I can tell, it handles them fine - there's even a "comment" property on the ZipFile object that you can set to modify the comment.

I attach a simple doc patch that removes the apparently out-of-date information.

----------
assignee: docs at python
components: Documentation
files: zipfile_comment_doc.patch
keywords: patch
messages: 110147
nosy: docs at python, rfk
priority: normal
severity: normal
status: open
title: zipfile incorrectly documented as not supporting archive comments
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17973/zipfile_comment_doc.patch

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

From report at bugs.python.org  Tue Jul 13 01:56:46 2010
From: report at bugs.python.org (Ryan Kelly)
Date: Mon, 12 Jul 2010 23:56:46 +0000
Subject: [New-bugs-announce] [issue9239] zipfile: truncating comment can
	corrupt the zipfile
In-Reply-To: <1278979006.42.0.00730549521889.issue9239@psf.upfronthosting.co.za>
Message-ID: <1278979006.42.0.00730549521889.issue9239@psf.upfronthosting.co.za>


New submission from Ryan Kelly <ryan at rfk.id.au>:

If you open a ZipFile in append mode and modify the comment to be shorter than what was originally there, the file will become corrupted.  Truncated data from the original comment is left "dangling" at the end of the zipfile.

A much more trivial bug discovered while writing tests for this: setting the "comment" attribute doesn't mark the zipfile as modified, so the change won't be written out unless you also modify one of the archive files.

The attached patch fixes (and adds tests for) these issues.

----------
components: Library (Lib)
files: zipfile_appendmode_comment.patch
keywords: patch
messages: 110149
nosy: rfk
priority: normal
severity: normal
status: open
title: zipfile: truncating comment can corrupt the zipfile
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file17974/zipfile_appendmode_comment.patch

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

From report at bugs.python.org  Tue Jul 13 02:11:12 2010
From: report at bugs.python.org (Diego Jacobi)
Date: Tue, 13 Jul 2010 00:11:12 +0000
Subject: [New-bugs-announce] [issue9240] different behaviour with for
	loop... interpreted vs	scripted
In-Reply-To: <1278979872.82.0.311259826309.issue9240@psf.upfronthosting.co.za>
Message-ID: <1278979872.82.0.311259826309.issue9240@psf.upfronthosting.co.za>


New submission from Diego Jacobi <jacobidiego at gmail.com>:

Hi.
I am not a python expert and i was trying to reduce this next code:

        data = []
        i = 0
        for j in range(packetlen+1):
            print i, self.channels_in[ channels[i] ]
            data.append( self.channels_in[ channels[i] ].pop() )
            i += 1
            if i >= len(channels):
                i=0

into something like this:

        data = []
        for j in range(packetlen+1), i in channels:
            print j, i
            data.append( self.channels_in[ i ].pop() )

which is much more readable and short.
But i didnt know if this sintax is really supported (also i didnt found examples on internet), so i just tried.

I runned the script and it didnt complains with errors, BUT i found that the behavior is not what i expected.

I expected j to take value of range() and i to take the values of channels until range() gets empty.

well, the actual behavior is that j takes the value of the complete range() as in
j = range(..)

and the for loop iterates as in 
for i in channels:


ALSO i tested this un the python command line and it produces different behaviours:

the same sintax writen as:

for j in range(1,5), i in range(120,500,12):
   print j, i

produces 

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'i' is not defined


Thats all. I guess that if it produces different results, then there is an error happening here.


If there is a pythonic way to do this:
for j in range(packetlen+1), i in channels:

please tell me.

Cheers.
Diego

----------
messages: 110150
nosy: jacobidiego
priority: normal
severity: normal
status: open
title: different behaviour with for loop... interpreted vs scripted
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Jul 13 11:04:36 2010
From: report at bugs.python.org (Gianfranco)
Date: Tue, 13 Jul 2010 09:04:36 +0000
Subject: [New-bugs-announce] [issue9241] SAXParseError on unicode (Japanese)
	file
In-Reply-To: <1279011876.88.0.998505025151.issue9241@psf.upfronthosting.co.za>
Message-ID: <1279011876.88.0.998505025151.issue9241@psf.upfronthosting.co.za>


New submission from Gianfranco <gianzula at tin.it>:

When parsing a UTF-16 little-endian encoded XML file containing some japanese characters, the xml.sax.parse function raises a SAXParseException exception saying "no element found". Problem arises with/on:

Python 2.5.2/Windows XP Pro SP3 32 bit
Python 2.6.4/Windows XP Pro SP3 32 bit
Python 2.5.2/Windows 2008 Server SP2 64 bit

The same file is successfully processed with/on:

Python 2.4.3/CentOS 5.4
Python 2.6.3/CentOS 5.4

I've attached a minimal XML file that contains a single U+FF1A japanese character that triggers the exception. Code for parsing the file follows:

import xml.sax
xml.sax.parse(open("ff1a.xml"), xml.sax.ContentHandler())

Best regards,
Gianfranco

----------
components: XML
files: ff1a.xml
messages: 110163
nosy: gianzula
priority: normal
severity: normal
status: open
title: SAXParseError on unicode (Japanese) file
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file17979/ff1a.xml

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

From report at bugs.python.org  Tue Jul 13 11:24:48 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 13 Jul 2010 09:24:48 +0000
Subject: [New-bugs-announce] [issue9242] unicodeobject.c: use of
	uninitialized values
In-Reply-To: <1279013088.42.0.0403163187541.issue9242@psf.upfronthosting.co.za>
Message-ID: <1279013088.42.0.0403163187541.issue9242@psf.upfronthosting.co.za>


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

Not sure if this is valid or if there is some internal trickery that Valgrind isn't aware of. If it's the latter, perhaps an entry to
Misc/valgrind.supp could be added.


test_bug1175396 (__main__.UTF32Test) ... ==26861== Conditional jump or move depends on uninitialised value(s)
==26861==    at 0x48A2DD: PyUnicodeUCS2_DecodeUTF32Stateful (unicodeobject.c:2282)
==26861==    by 0x50E25C: utf_32_le_decode (_codecsmodule.c:420)
==26861==    by 0x52E727: PyCFunction_Call (methodobject.c:81)
==26861==    by 0x4B4EB7: call_function (ceval.c:4012)
==26861==    by 0x4B1402: PyEval_EvalFrameEx (ceval.c:2665)
==26861==    by 0x4B31DA: PyEval_EvalCodeEx (ceval.c:3252)
==26861==    by 0x4B52C0: fast_function (ceval.c:4108)
==26861==    by 0x4B4FE1: call_function (ceval.c:4033)
==26861==    by 0x4B1402: PyEval_EvalFrameEx (ceval.c:2665)
==26861==    by 0x4B31DA: PyEval_EvalCodeEx (ceval.c:3252)
==26861==    by 0x4B52C0: fast_function (ceval.c:4108)
==26861==    by 0x4B4FE1: call_function (ceval.c:4033)
==26861== 
==26861== 
==26861== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y
==26861== starting debugger with cmd: /usr/bin/gdb -nw /proc/26862/fd/1014 26862
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Attaching to program: /proc/26862/fd/1014, process 26862
0x000000000048a2dd in PyUnicodeUCS2_DecodeUTF32Stateful (s=0x5bd6a54 "\n", size=1, errors=0x5add144 "strict", byteorder=0x7feffb18c, 
    consumed=0x7feffb170) at Objects/unicodeobject.c:2282
2282            if (qq[iorder[2]] != 0 || qq[iorder[3]] != 0)
(gdb) p s
$1 = 0x5bd6a54 "\n"
(gdb) p qq
$2 = (const unsigned char *) 0x5bd6a54 "\n"
(gdb) p iorder[2]
$3 = 2
(gdb) p iorder[3]
$4 = 3
(gdb) p bo
$5 = -1
(gdb) p *byteorder
$6 = -1

----------
messages: 110165
nosy: lemburg, skrah
priority: normal
severity: normal
status: open
title: unicodeobject.c: use of uninitialized values
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jul 13 13:47:49 2010
From: report at bugs.python.org (James Lee)
Date: Tue, 13 Jul 2010 11:47:49 +0000
Subject: [New-bugs-announce] [issue9243] sndhdr erroneously detects files as
	vox
In-Reply-To: <1279021669.64.0.945928628097.issue9243@psf.upfronthosting.co.za>
Message-ID: <1279021669.64.0.945928628097.issue9243@psf.upfronthosting.co.za>


New submission from James Lee <jbit at jbit.net>:

http://svn.python.org/view/python/branches/py3k/Lib/sndhdr.py?r1=56957&r2=56987 seems to have broken sndhdr as it incorrectly detects files as voc (all that time ago and nobody has noticed...):

[jbit at miku]~$ xxd test.wav | head -n 1
0000000: 5249 4646 2478 e001 5741 5645 666d 7420  RIFF$x..WAVEfmt 
[jbit at miku]~$ python3.1
>>> import sndhdr
>>> sndhdr.what("test.wav")
('voc', 0, 1, -1, 8)

I'm a little unsure why it got changed from indexing to startswith() at all, but changes like the following are just totally incorrect.
-    if h[:20] != b'Creative Voice File\032':
+    if h.startswith(b'Creative Voice File\032'):

Attached is a patch against the py3k branch which fixes the issue as well as some other things obviously broken by the same changelist, although it might be a good idea to review the changelist again to make sure there's nothing else obviously broken :)
>>> sndhdr.what("test.wav")
('wav', 48000, 2, -1, 16)

----------
components: Library (Lib)
files: sndhdr-fix.patch
keywords: patch
messages: 110172
nosy: jbit
priority: normal
severity: normal
status: open
title: sndhdr erroneously detects files as vox
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file17981/sndhdr-fix.patch

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

From report at bugs.python.org  Tue Jul 13 13:51:55 2010
From: report at bugs.python.org (Ask Solem)
Date: Tue, 13 Jul 2010 11:51:55 +0000
Subject: [New-bugs-announce] [issue9244] multiprocessing.pool: Pool crashes
	if worker can't encode	result (with patch)
In-Reply-To: <1279021915.02.0.743108448879.issue9244@psf.upfronthosting.co.za>
Message-ID: <1279021915.02.0.743108448879.issue9244@psf.upfronthosting.co.za>


New submission from Ask Solem <askh at opera.com>:

If the target function returns an unpickleable value the worker process crashes. This patch tries to safely handle unpickleable errors, while enabling the user to inspect such errors after the fact.

In addition a new argument has been added to apply_async: error_callback.
This is an optional callback that is called if the job raises an exception. The signature of the callback is `callback(exc)`.

----------
components: Library (Lib)
files: multiprocessing-trunk at 82502-handle_worker_encoding_errors.patch
keywords: patch
messages: 110173
nosy: asksol, jnoller
priority: normal
severity: normal
status: open
title: multiprocessing.pool: Pool crashes if worker can't encode result (with patch)
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file17982/multiprocessing-trunk at 82502-handle_worker_encoding_errors.patch

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

From report at bugs.python.org  Tue Jul 13 13:58:36 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 13 Jul 2010 11:58:36 +0000
Subject: [New-bugs-announce] [issue9245] "from itertools imoprt *" crashes
	2to3
In-Reply-To: <1279022316.28.0.141997544186.issue9245@psf.upfronthosting.co.za>
Message-ID: <1279022316.28.0.141997544186.issue9245@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

a script containing the following line crashes 2to3 with an assertion error.

The line:

  from itertools import *


File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib2to3/fixes/fix_itertools_imports.py", line 24, in transform
    assert child.type == syms.import_as_name
AssertionError

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 110175
nosy: ronaldoussoren
priority: normal
severity: normal
status: open
title: "from itertools imoprt *" crashes 2to3
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Jul 13 14:10:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Jul 2010 12:10:59 +0000
Subject: [New-bugs-announce] [issue9246] os.getcwd() hardcodes max path len
In-Reply-To: <1279023059.26.0.245683093399.issue9246@psf.upfronthosting.co.za>
Message-ID: <1279023059.26.0.245683093399.issue9246@psf.upfronthosting.co.za>


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

In 2.x, os.getcwd() uses a dynamic allocation scheme to accomodate whatever buffer size the current path needs to be represented.

In 3.x, the max path length is hardcoded to 1026 bytes or characters, and an error is raised if the current path length is larger than that. Even on systems where MAX_PATH is 1024 (a common value), it is still valid to create paths larger than that (using e.g. os.mkdir()).

The attached script shows that os.getcwd() works with a 1032-character path in 2.x, but fails in 3.x.

----------
components: Extension Modules
files: bigpath.py
messages: 110177
nosy: haypo, loewis, pitrou, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: os.getcwd() hardcodes max path len
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17983/bigpath.py

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

From report at bugs.python.org  Tue Jul 13 15:38:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Jul 2010 13:38:57 +0000
Subject: [New-bugs-announce] [issue9247] imp.reload() doesn't take import
	lock
In-Reply-To: <1279028337.95.0.00914211475074.issue9247@psf.upfronthosting.co.za>
Message-ID: <1279028337.95.0.00914211475074.issue9247@psf.upfronthosting.co.za>


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

I am not sure this is important or now, but reload() (imp.reload() in 3.x) doesn't take the import lock when reloading:

$ echo 'import imp; print("lock held =", imp.lock_held())' > foo.py
$ ./python -c 'import imp, foo; imp.reload(foo)'
lock held = True
lock held = False

----------
components: Interpreter Core
messages: 110191
nosy: brett.cannon, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: imp.reload() doesn't take import lock
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Jul 13 15:47:03 2010
From: report at bugs.python.org (Ask Solem)
Date: Tue, 13 Jul 2010 13:47:03 +0000
Subject: [New-bugs-announce] [issue9248] multiprocessing.pool: Proposal:
	"waitforslot"
In-Reply-To: <1279028823.93.0.963356654708.issue9248@psf.upfronthosting.co.za>
Message-ID: <1279028823.93.0.963356654708.issue9248@psf.upfronthosting.co.za>


New submission from Ask Solem <askh at opera.com>:

This patch adds the `waitforslot` argument to apply_async. If set to `True`, apply_async will not return until there is a worker available to process the job.

This is implemented by a semaphore that is released by the result handler whenever a new result is ready. The semaphore is also released
when the supervisor (worker_handler) finds a worker process that has been
unexpectedly terminated.

This is already in use by Celery 2.0, which ships with its own modified version of multiprocessing.pool.

I'm not sure about the name ``waitforslot``, I think I may even hate it, but haven't been able to come up with a better name for it yet.

----------
components: Library (Lib)
messages: 110193
nosy: asksol, jnoller
priority: normal
severity: normal
status: open
title: multiprocessing.pool: Proposal: "waitforslot"
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Jul 13 17:00:09 2010
From: report at bugs.python.org (hannes reuter)
Date: Tue, 13 Jul 2010 15:00:09 +0000
Subject: [New-bugs-announce] [issue9249] struct.pack and Long Integer
	datatype should be 4, but is 8 bytes
In-Reply-To: <1279033209.41.0.410142321642.issue9249@psf.upfronthosting.co.za>
Message-ID: <1279033209.41.0.410142321642.issue9249@psf.upfronthosting.co.za>


New submission from hannes reuter <gisxperts at googlemail.com>:

on http://docs.python.org/library/struct.html
in section 7.3.2.2. Format Characters in the table one can find that 
L -> unsigned long -> 	integer-> should have a 4 byte dataspace.
(same applies for l), which seems to be correct -> 32bit/8=4


On a Ubuntu 64 , Python 2.6,  
a) calcsize reports it uses 8 byte
b) by writing data to a file and reading it back in I could confirm that it uses as well 8 bytes of binary data -> ofile2.write(struct.pack('LL',int(x[0]), int(x[1])))

Q: Is that behavior what we see a Docu error ?
Q: Is that behavior what we see general struct problem ? 
add1: in # 2263 e.g. we see problems for L type data in relation to np ?  
add2: IMHO certainly not a padding problem like in #7355


for reproduction:

from struct import *
calcsize('H')
2 -> correct to docu
calcsize('f')
4 -> correct to docu
calcsize('L')
8   -> should be 4
calcsize('l')
8 -> should be 4
calcsize('x')
1 -> correct to docu

So either docu is wrong, or struct has an error.

----------
assignee: theller
components: ctypes
messages: 110201
nosy: hannes.reuter, theller
priority: normal
severity: normal
status: open
title: struct.pack and Long Integer datatype should be 4, but is 8 bytes
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Jul 13 18:36:13 2010
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 13 Jul 2010 16:36:13 +0000
Subject: [New-bugs-announce] [issue9250] sys.modules changes size during
	iteration in regrtest	module
In-Reply-To: <1279038973.54.0.16228117882.issue9250@psf.upfronthosting.co.za>
Message-ID: <1279038973.54.0.16228117882.issue9250@psf.upfronthosting.co.za>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

Python 2.7 - svn revision 82852

Bug description
===============

Test script foo.py
------------------

    #!/usr/bin/env python
    import distutils.core
    import test.regrtest


Exception when running foo.py
-----------------------------

Traceback (most recent call last):
  File "foo.py", line 3, in <module>
    import test.regrtest
  File "/usr/local/lib/python2.7/test/regrtest.py", line 184, in <module>
    for module in sys.modules.itervalues():
RuntimeError: dictionary changed size during iteration


Workaround
==========

Revese the order of the imports in foo.py.


Proposed patch
==============

Root cause: email modules are being imported inside the loop.

The following patch (svn revision 82852) forces the import of the
email modules before the main iteration. These modules have been
lazily imported in email/__init__.py and need to be effectively
imported before updating the __file__ and __path__ attributes.

The patch is also attached to this report.

--- release27-maint/Lib/test/regrtest.py       2010-07-13 18:11:32.000000000 +0200
+++ /usr/local/lib/python2.7/test/regrtest.py   2010-07-13 18:00:52.000000000 +0200
@@ -181,6 +181,12 @@
 # (site.py absolutize them), the __file__ and __path__ will be absolute too.
 # Therefore it is necessary to absolutize manually the __file__ and __path__ of
 # the packages to prevent later imports to fail when the CWD is different.
+
+# Email modules are imported lazily, force their import first.
+if 'email' in sys.modules:
+    [hasattr(sys.modules[name], '__foo__') for name in list(sys.modules)
+                                                if name.startswith('email.')]
+
 for module in sys.modules.itervalues():
     if hasattr(module, '__path__'):
         module.__path__ = [os.path.abspath(path) for path in module.__path__]

----------
components: Tests
files: sys.modules_regrtest.patch
keywords: patch
messages: 110211
nosy: xdegaye
priority: normal
severity: normal
status: open
title: sys.modules changes size during iteration in regrtest module
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file17988/sys.modules_regrtest.patch

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

From report at bugs.python.org  Tue Jul 13 21:05:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Jul 2010 19:05:31 +0000
Subject: [New-bugs-announce] [issue9251] Test for the import lock
In-Reply-To: <1279047931.75.0.287450849516.issue9251@psf.upfronthosting.co.za>
Message-ID: <1279047931.75.0.287450849516.issue9251@psf.upfronthosting.co.za>


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

The import lock is lacking tests that it functions properly.

Coming up with a way of checking it was unexpectedly hard. I finally managed to write a script which quite reliably fails if you patch Python/import.c to not take the import lock. The script relies on garbage collection trickery to release the GIL at arbitrary moments.
It should probably be converted to an unit test.

----------
components: Interpreter Core, Tests
files: mtimport.py
messages: 110219
nosy: brett.cannon, ncoghlan, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Test for the import lock
versions: Python 3.2
Added file: http://bugs.python.org/file17990/mtimport.py

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

From report at bugs.python.org  Tue Jul 13 23:19:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 13 Jul 2010 21:19:13 +0000
Subject: [New-bugs-announce] [issue9252] PyImport_Import calls __import__
	with dummy fromlist
In-Reply-To: <1279055953.69.0.493320308989.issue9252@psf.upfronthosting.co.za>
Message-ID: <1279055953.69.0.493320308989.issue9252@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

I have discovered this issue while working on the unit tests for issue 7989. In the first version of the setUp/tearDown overrides, I made a mistake when restoring sys.modules after the test run.  The fix was to do

sys.modules.__init__(saved_sys_modules)

instead of

sys.modules = saved_sys_modules

Interestingly, _pickle.c and pickle.py behaved differently when sys.modules was restored incorrectly:  pickle.py, using

__import__(name, ..)
mod = sys.modules[name]

picked up the incorrectly restored sys.modules, while _pickle.c, using PyImport_Import, which is effectively

mod = __import__(name, fromlist=["__doc__"], ..)

failed.

>From discussion on python-dev [1], I realize that pickle.py approach is the correct one even though in my case it would probably mask an error in my code.

At the minimum, I think _pickle.c and pickle.py should be changed to do the same thing - probably call importlib.import_module(..).  I don't know whether PyImport_Import should be fixed or deprecated.


[1] "Peculiar import code in pickle.py" <http://mail.python.org/pipermail/python-dev/2010-July/101906.html>.

----------
assignee: brett.cannon
components: Interpreter Core
messages: 110228
nosy: belopolsky, brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: PyImport_Import calls __import__ with dummy fromlist
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Jul 13 23:29:49 2010
From: report at bugs.python.org (Vincent Driessen)
Date: Tue, 13 Jul 2010 21:29:49 +0000
Subject: [New-bugs-announce] [issue9253] optional subparsers
In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za>
Message-ID: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za>


New submission from Vincent Driessen <nvie81 at gmail.com>:

**NOTE**: This is a re-post of http://code.google.com/p/argparse/issues/detail?id=47

What steps will reproduce the problem?
parser = argparse.ArgumentParser()
sub = parser.add_subparsers()
sub.add_parser("info")
parser.add_argument("paths", "+")
parser.parse_args(["foo", "bar"])

What is the expected output? What do you see instead?
Expected behavior is that, failing to match one of the subparser inputs
("info"), the parser checks if the argument matches any of the top-level
arguments, in this case the 'paths' multi-arg. In other words, it should be
possible to make the subparser be optional, such that when the subparser
argument fails to retrieve any valid subparser, the remaining args are
parsed as if no subparser exists. At present, it does not seem possible to
make a subparser be optional at all.
Perhaps this could be exposed to the user as:
parser.add_subparsers(nargs=argparse.OPTIONAL)
or something to that effect. Or, allow a default subparser to be specified.
I.e.,

sub = parser.add_subparsers()
info = sub.add_parser("info")
main = sub.add_parser("main")
sub.default = main

I'm sure the point will come up that the current behavior is correct,
because given a subparser like "info", a user could easily make a mistake
like "myapp ino foo bar" and rather than get a safe error be given
something unexpected. For this reason, I think the default behavior is
usually going to be correct. BUT, it would still be nice if it could be
optional, so that developers could be free to make that call. Sometimes the
potential user errors aren't really an issue, and having to explicitly set
a subparse arg every time can be a nuissance.

----------
components: Library (Lib)
messages: 110231
nosy: nvie
priority: normal
severity: normal
status: open
title: optional subparsers
type: feature request
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Jul 13 23:49:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 13 Jul 2010 21:49:29 +0000
Subject: [New-bugs-announce] [issue9254] __import__ docstring should
	recommend	importlib.import_module()
In-Reply-To: <1279057769.02.0.398615806235.issue9254@psf.upfronthosting.co.za>
Message-ID: <1279057769.02.0.398615806235.issue9254@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

On Tue, Jul 13, 2010 at 4:52 PM, Brett Cannon wrote [1]:
..
> I say this every time I give an import talk and it has been brought up here
> before but obviously not everyone catches it (which is understandable as I
> think when it came up on python-dev it was at the tail end of a discussion),
> so I am just going to repeat myself:
> ??Do not put junk in fromlist if you call __import__ directly! Use
> importlib.import_module! Or if you have a *really* good reason to not use
> it, then use ``__import__(name); module = sys.modules[name]``.

I think one of the reasons the message does not sink in (at least this is the reason in my case) is that a user who discovers that __import__('foo.bar') returns foo instead of bar, looks up help(__import__) to find that

"""
When importing a module from a package, note that __import__('A.B', ...) returns package A when fromlist is empty, but its submodule B when fromlist is not empty.
"""

Passing fromlist=["dummy"] seems like a natural solution after reading this.

The ReST documentation [2] is slightly better as it contain a recommendation that says: "If you simply want to import a module (potentially within a package) by name, you can call __import__() and then look it up in sys.modules." However this still fails to mention the (better IMO) alternative of using importlib.import_module().

I believe the __import__ docstring should start with a recommendation not to use it directly and use importlib.import_module() instead, while the ReST documentation should grow a warning not to use dummy fromlist and the recommendation to use __import__() followed by sys.modules lookup should be changed to a recommendation to use mportlib.import_module().

[1] "Peculiar import code in pickle.py" <http://mail.python.org/pipermail/python-dev/2010-July/101906.html>.
[2] http://docs.python.org/dev/library/functions.html?#__import__

----------
messages: 110234
nosy: belopolsky, brett.cannon
priority: normal
severity: normal
status: open
title: __import__ docstring should recommend importlib.import_module()

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

From report at bugs.python.org  Tue Jul 13 23:53:48 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 13 Jul 2010 21:53:48 +0000
Subject: [New-bugs-announce] [issue9255] document that the 'test' package is
	for core developers	only
In-Reply-To: <1279058028.22.0.187583087672.issue9255@psf.upfronthosting.co.za>
Message-ID: <1279058028.22.0.187583087672.issue9255@psf.upfronthosting.co.za>


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

The documentation for the 'test' package should specify that the things that are documented are really meant for people contributing to Python and not for personal use. This will help lead to people no longer using the package outside of Python itself and eventually getting the module back to being an internal detail.

----------
assignee: brett.cannon
components: Documentation
keywords: easy
messages: 110236
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: document that the 'test' package is for core developers only
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Jul 14 03:34:04 2010
From: report at bugs.python.org (Wim)
Date: Wed, 14 Jul 2010 01:34:04 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue9256=5D_plistlib_should_cre?=
 =?utf-8?q?ate_non-na=C3=AFve_datetime_objects?=
In-Reply-To: <1279071244.17.0.181964010836.issue9256@psf.upfronthosting.co.za>
Message-ID: <1279071244.17.0.181964010836.issue9256@psf.upfronthosting.co.za>


New submission from Wim <wiml at hhhh.org>:

The plistlib module parses <date> elements in the plist into datetime objects. (This is good.) However, it produces na?ve datetimes, even though the <date> elements include an explicit timezone specification ('Z' for UTC, since they're in ISO 8601 format).

Now that issue 5094 has been fixed, this should be a pretty trivial thing to fix??just pass tzinfo=UTC when creating the datetime (since the regex it uses won't even accept a date that doesn't have the 'Z' suffix, this will be correct).

As an aside: RFC 3339 section 4.3 suggests a convention for distinguishing between "timestamps in UTC" and "timestamps which happen to be defined in terms of UTC, but don't really live in any particular timezone". The python datetime module is not currently able to make this distinction AFAIK, but even though the plist date strings don't follow the RFC 3339 convention, they are most accurately described as having an unknown local offset (like POSIX timestamps, they are UTC-referenced but cannot carry local-timezone info).

----------
files: plistdt.py
messages: 110249
nosy: wiml
priority: normal
severity: normal
status: open
title: plistlib should create non-na?ve datetime objects
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file17993/plistdt.py

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

From report at bugs.python.org  Wed Jul 14 05:27:47 2010
From: report at bugs.python.org (Eric Talevich)
Date: Wed, 14 Jul 2010 03:27:47 +0000
Subject: [New-bugs-announce] [issue9257] cElementTree iterparse requires
	events as bytes; ElementTree uses strings
In-Reply-To: <1279078067.06.0.575324977312.issue9257@psf.upfronthosting.co.za>
Message-ID: <1279078067.06.0.575324977312.issue9257@psf.upfronthosting.co.za>


New submission from Eric Talevich <eric.talevich at gmail.com>:

In xml.etree, ElementTree and cElementTree implement different interfaces for the iterparse function/class.

In ElementTree, the argument "events" must be a tuple of strings:

from xml.etree import ElementTree as ET
for result in ET.iterparse('example.xml', events=('start', 'end')):
    print(result)

That works, given a valid XML file 'example.xml'. If the event names are given as bytes instead of strings (b'start', b'end'), there's no crash, but no events are recognized.

In cElementTree, it's the opposite: the events argument must be a tuple of bytes:

from xml.etree import cElementTree as cET
for result in cET.iterparse('example.xml', events=(b'start', b'end')):
    print(result)

Giving a tuple of strings instead of bytes results in:

>>> for result in cET.iterparse('example.xml', events=('start', 'end')):
...     print(result)
TypeError: invalid event tuple


This makes it difficult to use ElementTree as a backup for cElementTree, or at least very awkward.

----------
components: Library (Lib)
messages: 110252
nosy: eric-talevich
priority: normal
severity: normal
status: open
title: cElementTree iterparse requires events as bytes; ElementTree uses strings
versions: Python 3.1

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

From report at bugs.python.org  Wed Jul 14 09:56:29 2010
From: report at bugs.python.org (Retro)
Date: Wed, 14 Jul 2010 07:56:29 +0000
Subject: [New-bugs-announce] [issue9258] Typos in docs for methods kqueue
	and kevent of module	'select'
In-Reply-To: <1279094189.8.0.55376365851.issue9258@psf.upfronthosting.co.za>
Message-ID: <1279094189.8.0.55376365851.issue9258@psf.upfronthosting.co.za>


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

Fix the docs for every selected Python version. They all have the same typos.

The typos appear in the documentation of the 'select' module. These are the methods that need typo fixes:


select.kqueue()
(Only supported on BSD.)

Returns a kernel queue object object ...

[remove one of the words 'object' here because they are unnecessarily repeated]


select.kevent(ident, filter=KQ_FILTER_READ, flags=KQ_EV_ADD, fflags=0, data=0, udata=0)
(Only supported on BSD.)

Returns a kernel event object object; see section Kevent Objects below for the methods supported by kqueue objects.

[again, remove one of the words 'object' here because they are unnecessarily repeated; also, fix the word 'kqueue' to 'kevent']

----------
assignee: docs at python
components: Documentation
messages: 110255
nosy: Retro, docs at python, georg.brandl
priority: normal
severity: normal
status: open
title: Typos in docs for methods kqueue and kevent of module 'select'
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/issue9258>
_______________________________________

From report at bugs.python.org  Wed Jul 14 13:53:18 2010
From: report at bugs.python.org (Ariel Ben-Yehuda)
Date: Wed, 14 Jul 2010 11:53:18 +0000
Subject: [New-bugs-announce] [issue9259] Python 2.7 breaks assigned __exit__s
In-Reply-To: <1279108398.28.0.504653003054.issue9259@psf.upfronthosting.co.za>
Message-ID: <1279108398.28.0.504653003054.issue9259@psf.upfronthosting.co.za>


New submission from Ariel Ben-Yehuda <ariel.bys at gmail.com>:

Hello, I think there is a problem with Python 2.7: I installed it, and tried to compile GObject-Introspection 0.9.2. Here is the result:

...
  GISCAN GLib-2.0.gir
Traceback (most recent call last):
  File "../tools/g-ir-scanner", line 36, in <module>
    from giscanner.scannermain import scanner_main
  File "/sources/gobject-introspection-0.9.2/giscanner/scannermain.py", line 31, in <module>
    from giscanner.dumper import compile_introspection_binary
  File "/sources/gobject-introspection-0.9.2/giscanner/dumper.py", line 26, in <module>
    from .glibtransformer import IntrospectionBinary
  File "/sources/gobject-introspection-0.9.2/giscanner/glibtransformer.py", line 34, in <module>
    from .transformer import Names
  File "/sources/gobject-introspection-0.9.2/giscanner/transformer.py", line 31, in <module>
    from .girparser import GIRParser
  File "/sources/gobject-introspection-0.9.2/giscanner/girparser.py", line 32, in <module>
    from .girwriter import COMPATIBLE_GIR_VERSION
  File "/sources/gobject-introspection-0.9.2/giscanner/girwriter.py", line 30, in <module>
    from .xmlwriter import XMLWriter
  File "/sources/gobject-introspection-0.9.2/giscanner/xmlwriter.py", line 70, in <module>
    with LibtoolImporter:
AttributeError: __exit__

Oops, no GObject-Introspection for me. Investigating the bug, I looked in the recent changes in Python2.7 for something interesting, and found this: 
A new opcode was added to perform the initial setup for with statements, looking up the __enter__()  and __exit__()  methods. (Contributed by Benjamin Peterson.)

Finally, I made 3 test cases to the bug. All 3 produce no input in Python 2.6, but crash pretty nicely in 2.7, the first 2 not finding __exit__ and the last missing __enter__.

I will try to make a patch, however my CPython skills are not so great, so you will probably make a better one.

----------
components: Interpreter Core
files: tests.tar.xz
messages: 110268
nosy: arielbyd
priority: normal
severity: normal
status: open
title: Python 2.7 breaks assigned __exit__s
versions: Python 2.7
Added file: http://bugs.python.org/file17996/tests.tar.xz

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

From report at bugs.python.org  Wed Jul 14 16:44:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Jul 2010 14:44:23 +0000
Subject: [New-bugs-announce] [issue9260] A finer grained import lock
In-Reply-To: <1279118663.3.0.514954672422.issue9260@psf.upfronthosting.co.za>
Message-ID: <1279118663.3.0.514954672422.issue9260@psf.upfronthosting.co.za>


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

This is an implementation of the idea suggested in:
http://mail.python.org/pipermail/python-dev/2003-February/033445.html

The patch creates a dictionary of reentrant locks keyed by module full name. Trying to import a module or package will first get the lock for that module (or, if necessary, create it) and then acquire it. This is done for any module type.

The global import lock is still there, but only used for two things:
- serializing first time creation of module-specific locks
- protection of imports based on import hooks, since we don't know whether third-party import hooks are themselves thread-safe

Semantics of the public C API are unchanged, because it is not clear whether they should be or not (concerns of usefulness vs. compatibility). For example, PyImport_ImportModuleNoBlock() still uses the global import lock but this could be relaxed in a later patch.

----------
components: Interpreter Core
files: implock.patch
keywords: patch
messages: 110287
nosy: brett.cannon, christian.heimes, grahamd, gvanrossum, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: A finer grained import lock
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file17998/implock.patch

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

From report at bugs.python.org  Wed Jul 14 18:20:37 2010
From: report at bugs.python.org (Dan OD)
Date: Wed, 14 Jul 2010 16:20:37 +0000
Subject: [New-bugs-announce] [issue9261] include higher (../../) dirs fails
In-Reply-To: <1279124437.89.0.789068978786.issue9261@psf.upfronthosting.co.za>
Message-ID: <1279124437.89.0.789068978786.issue9261@psf.upfronthosting.co.za>


New submission from Dan OD <djo35 at cam.ac.uk>:

MANIFEST.in example:

recursive-include ../../this *.that

fails to include files with

"warning: no files found matching '*.that' under directory '../../this'"

and also

include ../../this *.that

fails with

"warning: no files found matching '../../this'"

- odd situation I know, but including files in higher directories shouldn't be impossible should it? Thanks, Dan

----------
assignee: tarek
components: Distutils
messages: 110296
nosy: indiedan, tarek
priority: normal
severity: normal
status: open
title: include higher (../../) dirs fails
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Jul 14 19:31:49 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 14 Jul 2010 17:31:49 +0000
Subject: [New-bugs-announce] [issue9262] IDLE: Use ttk.Notebook for tabbed
	windows
In-Reply-To: <1279128709.53.0.879340925848.issue9262@psf.upfronthosting.co.za>
Message-ID: <1279128709.53.0.879340925848.issue9262@psf.upfronthosting.co.za>


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

The addition of tabbed windows to web browsers was a great advance that is now standard. For Windows, it eliminated the crowding of the taskbar. I suspect it made switching easier on all systems.

The addition of the same to IDLE would have similar benefits. I often have a shell and two edit windows open.

This would require, I believe, the use of ttk.Notebook, which requires tcl/tk 8.5+ or the Tile extension. Can this be made a requirement for IDLE in 3.2? Windows has 8.5 now. *nix users can add Tile if they have 8.4. I do not know the situation for Mac.

----------
components: IDLE
messages: 110301
nosy: tjreedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: Use ttk.Notebook for tabbed windows
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Thu Jul 15 01:50:50 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 14 Jul 2010 23:50:50 +0000
Subject: [New-bugs-announce] [issue9263] Try to print repr() when an C-level
	assert fails (in the	garbage collector, beyond?)
In-Reply-To: <1279151450.93.0.973335817084.issue9263@psf.upfronthosting.co.za>
Message-ID: <1279151450.93.0.973335817084.issue9263@psf.upfronthosting.co.za>


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

Modules/gcmodule.c contains various assertions which can fail due to reference counting errors elsewhere in either python, or an extension module.  These can be difficult to track down.

In the hope of maximizing the information from crash reports, the attached patch (against py3k) introduces a new assertion macro to Objects/object.h and Objects.c, which provides a richer debug message.  In particular, it identifies which object has the issue, and can more clearly spell out the problem.

The patch replaces all uses of assert() in Modules/gcmodule.c for which a specific object has an issue (e.g. bogus reference count).

The implementation may play somewhat fast-and-loose with rules about object invariants: you might have an only partially valid object, but the process is about to abort, so it seems acceptable to try to glean extra information on stderr.  (This may turn an abort into a segfault, of course)

Caveats:
- exact name of the API probably could be better
- I don't yet have a specific use for the "callback" idea; I was thinking of trying to display all objects that reference that object.  Might need a void* closure to be useful.  Might be a useless complication.
- Only tested on gcc-4.4.3 so far; the __STRING(expr) and __PRETTY_FUNCTION__ look non-portable.
- no test case; I thought about using ctypes to extract PyObject_IncRef from the implementation, but this is likely to lead to brittle test cases.  Alternatively, is xxmodule to be used for this kind of thing?

Thoughts?

----------
components: Interpreter Core
files: py3k-repr-on-gcmodule-assertions.patch
keywords: patch
messages: 110341
nosy: dmalcolm
priority: normal
severity: normal
stage: patch review
status: open
title: Try to print repr() when an C-level assert fails (in the garbage collector, beyond?)
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file18007/py3k-repr-on-gcmodule-assertions.patch

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

From report at bugs.python.org  Thu Jul 15 06:11:25 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 15 Jul 2010 04:11:25 +0000
Subject: [New-bugs-announce] [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

The documentation of the standard 'trace' module (Doc/library/trace.rst) is sorely lacking. Arguments are not explained, some key methods are not documented at all, and the CoverageResults class isn't documented.

Usage of these appears in the example but leaves the user confused as the only source of documentation for the example is the source code of the module.

I'm attaching a patch that fixes this issue, by providing documentation for the missing parts.

The patch was generated vs. the latest SVN trunk.

----------
assignee: docs at python
components: Documentation
files: tracedoc.3.patch
keywords: patch
messages: 110344
nosy: docs at python, eli.bendersky, tjreedy
priority: normal
severity: normal
status: open
title: trace.py documentation is incomplete
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file18009/tracedoc.3.patch

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

From report at bugs.python.org  Thu Jul 15 07:20:54 2010
From: report at bugs.python.org (Narnie Harshoe)
Date: Thu, 15 Jul 2010 05:20:54 +0000
Subject: [New-bugs-announce] [issue9265] Can choose other shell in
	subprocess module. Includes fix.
In-Reply-To: <1279171254.35.0.713274753233.issue9265@psf.upfronthosting.co.za>
Message-ID: <1279171254.35.0.713274753233.issue9265@psf.upfronthosting.co.za>


New submission from Narnie Harshoe <signuplinux at gmail.com>:

Popen from the subprocess module when called with shell=True and executable=/bin/bash still runs in the /bin/sh shell.

The error has been found and corrected in the subprocess module and is as follows:

change:
        lines 1018-1022 for python v 2.6
        lines 1092-1096 for python v 2.7
        lines 1046-1050 for python v 3.1
        from this:
        
            if shell:
                args = ["/bin/sh", "-c"] + args

            if executable is None:
                executable = args[0]

        to this:
        
            if shell:
            if executable is None:
                args = ["/bin/sh", "-c"] + args
                executable = args[0]
            else:
                args = [executable, "-c"] + args

#            if executable is None:
#                executable = args[0]


Of course the last 2 lines can just be deleted but were left in to better highlight the change.

This change corrects the bug allowing shell=True and executable=/bin/bash to run in a bash shell or any other shell sub'd for /bin/bash.

Hope this will make it into the module.

I've included my temp fix which I have simply called subprocess2 for my purposes for v 2.6.

----------
components: Library (Lib)
files: subprocess2.py
messages: 110346
nosy: narnie
priority: normal
severity: normal
status: open
title: Can choose other shell in subprocess module. Includes fix.
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file18010/subprocess2.py

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

From report at bugs.python.org  Thu Jul 15 14:55:50 2010
From: report at bugs.python.org (Greg Hazel)
Date: Thu, 15 Jul 2010 12:55:50 +0000
Subject: [New-bugs-announce] [issue9266] ctypes "ValueError: NULL pointer
	access" on Win7 x64
In-Reply-To: <1279198550.56.0.12735266712.issue9266@psf.upfronthosting.co.za>
Message-ID: <1279198550.56.0.12735266712.issue9266@psf.upfronthosting.co.za>


New submission from Greg Hazel <ghazel at users.sourceforge.net>:

ctypes on Windows on a 64bit Python installation gets a NULL pointer access where one is not expected.

To reproduce the problem, run make.bat then "python ctypes_test.py"


Failure output looks like this:

Three! 1 2 <__main__.LP_Some object at 0x000000000209C4C8>
<__main__.Some object at 0x000000000209C548>
91
Four! 1 2 3 <__main__.LP_Some object at 0x000000000209C4C8>
Traceback (most recent call last):
  File "_ctypes/callbacks.c", line 291, in 'calling callback function'
  File "ctypes_test.py", line 21, in fourprinter
    print(to.contents)
ValueError: NULL pointer access


Otherwise, successful output looks something like:

Three! 1 2 <ctypes.LP_Some object at 0x2acc9482aed0>
<__main__.Some object at 0x2acc9482ae50>
91
Four! 1 2 3 <ctypes.LP_Some object at 0x2acc9482aed0>
<__main__.Some object at 0x2acc9482ae50>
91



Environments exhibiting this problem:

Python 2.7 (r27:82525, Jul  4 2010, 07:43:08) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.architecture()
('64bit', 'WindowsPE')

Python 3.1.2 (r312:79149, Mar 20 2010, 22:55:39) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.architecture()
('64bit', 'WindowsPE')


Environments NOT exhibiting the problem:

Python 2.4.3 (#1, Sep  3 2009, 15:37:37)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-46)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.architecture()
('64bit', 'ELF')

Also Windows on a 32bit architecture seems unaffected.

----------
assignee: theller
components: ctypes
files: ctypes_test.zip
messages: 110362
nosy: ghazel, theller
priority: normal
severity: normal
status: open
title: ctypes "ValueError: NULL pointer access" on Win7 x64
type: crash
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file18012/ctypes_test.zip

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

From report at bugs.python.org  Thu Jul 15 20:13:01 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 15 Jul 2010 18:13:01 +0000
Subject: [New-bugs-announce] [issue9267] Update pickle opcode documentation
	in pickletools for 3.x
In-Reply-To: <1279217581.88.0.294098163632.issue9267@psf.upfronthosting.co.za>
Message-ID: <1279217581.88.0.294098163632.issue9267@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Pickle opcode documentation in pickletools still refers to old/new style classes and changes made in 2.x series.  Opcodes such as INT, INST, and OBJ that are no longer produced by 3.x pickling code should be described as such and discussion added on how 2.x features that are removed in 3.x are emulated when 2.x pickles are loaded in 3.x.

See also issue5180.

----------
assignee: belopolsky
components: Documentation
keywords: easy
messages: 110384
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: Update pickle opcode documentation in pickletools for 3.x
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Thu Jul 15 21:37:18 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 15 Jul 2010 19:37:18 +0000
Subject: [New-bugs-announce] [issue9268] Add annotation option to
	pickletools.dis
In-Reply-To: <1279222638.31.0.459529413565.issue9268@psf.upfronthosting.co.za>
Message-ID: <1279222638.31.0.459529413565.issue9268@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Example:

>>> dis(pickle.dumps(T, 3), annotate=1)                                                                                                                                         
    0: \x80 PROTO      3 | Protocol version indicator.                                                                                                                          
    2: ]    EMPTY_LIST   | Push an empty list.                                                                                                                                  
    3: q    BINPUT     0 | Store the stack top into the memo.  The stack is not popped.                                                                                         
    5: h    BINGET     0 | Read an object from the memo and push it on the stack.                                                                                               
    7: \x85 TUPLE1       | One-tuple.                                                                                                                                           
    8: q    BINPUT     1 | Store the stack top into the memo.  The stack is not popped.                                                                                         
   10: a    APPEND       | Append an object to a list.                                                                                                                          
   11: 0    POP          | Discard the top stack item, shrinking the stack by one item.                                                                                         
   12: h    BINGET     1 | Read an object from the memo and push it on the stack.                                                                                               
   14: .    STOP         | Stop the unpickling machine.

----------
assignee: belopolsky
files: pickletools-annotate.diff
keywords: easy, patch
messages: 110388
nosy: alexandre.vassalotti, belopolsky, lemburg, mark.dickinson, pitrou
priority: normal
severity: normal
stage: unit test needed
status: open
title: Add annotation option to pickletools.dis
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file18018/pickletools-annotate.diff

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

From report at bugs.python.org  Fri Jul 16 01:01:42 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 15 Jul 2010 23:01:42 +0000
Subject: [New-bugs-announce] [issue9269] Cannot pickle self-referencing sets
In-Reply-To: <1279234902.88.0.629141543515.issue9269@psf.upfronthosting.co.za>
Message-ID: <1279234902.88.0.629141543515.issue9269@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Attached script, cycle.py demonstrates a simplification of the behavior reported by mike bayer in msg77200.

Essentially, the script attempts to pickle a set that contains a class instance that has an attribute referring back to the set:

class C:
    pass
c = C()
cycle = set([c])
c.foo = cycle

An attempt to pickle the *cycle* object triggers an assertion error in 2.7 or in 3.2 with disabled _pickle acceleration and produces a broken cycle in 3.2 or if cPickle is used instead of pickle in 2.7.

$ python3 cycle.py
FAIILURE
..

$ python2 cycle.py
Traceback (most recent call last):
  ..
  File ".../pickle.py", line 244, in memoize
    assert id(obj) not in self.memo
AssertionError

If you run cycle.py with an argument, it uses a dict instead of set to create the cycle and shows that the cycles with dict can be pickled correctly:

$ python3 cycle.py dict
SUCCESS
..

After reporting success or failure, cycle.py, prints a disassembly of the pickle stream which makes it clear what happens:

In case of dict, we see the following:

$ python3 cycle.py dict
SUCCESS
 ..
    2: }    EMPTY_DICT
    3: q    BINPUT     0
 ..
   26: X    BINUNICODE 'foo'
..
   36: h    BINGET     0
   38: s    SETITEM
..
   40: N    NONE
   41: s    SETITEM

An empty dict is created and saved in the memo.  Then a C object is built with foo attribute is set to the dict retrieved from the memo. Finally, the same dict is updated with (C object, None) key-value pair.  The result is the cycle identical to the one we built in python code.

The sets, however, are built differently.  There is no pickle opcode to add items to a set, so all set items must exist by the time set is built.  So here is what we see:  

$ python3 cycle.py
FAIILURE
    2: c    GLOBAL     'builtins set'
   16: q    BINPUT     0
.. instead of empty set the constructor is saved in memo
   42: X    BINUNICODE 'foo'
   52: h    BINGET     0
..
   63: R    REDUCE
.. a set object containing c is constructed 
   66: s    SETITEM  
.. and assigned to c.foo
   72: R    REDUCE
.. another set object is constructed containing c
 
As a result, we have

cycle = {c}
c.foo = {c}

Instead of 

c.foo = cycle

----------
assignee: belopolsky
components: Interpreter Core
files: cycle.py
messages: 110397
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: Cannot pickle self-referencing sets
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file18020/cycle.py

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

From report at bugs.python.org  Fri Jul 16 05:27:58 2010
From: report at bugs.python.org (bugs-python@vendor.thewrittenword.com)
Date: Fri, 16 Jul 2010 03:27:58 +0000
Subject: [New-bugs-announce] [issue9270] distutils.util.getplatform and
	sysconfig.getplatform	differ
In-Reply-To: <1279250878.74.0.870585975763.issue9270@psf.upfronthosting.co.za>
Message-ID: <1279250878.74.0.870585975763.issue9270@psf.upfronthosting.co.za>


New submission from bugs-python at vendor.thewrittenword.com <bugs-python at vendor.thewrittenword.com>:

We had issues building python 2.7 on hppa-hp-hpux machines because sysconfig and distutils had different ideas of the platform name.

./python -c 'import os, sys; from distutils.util import get_platform as plat1; from sysconfig import get_platform as plat2; print plat1();print plat2()'
hp-ux-B.11.11-9000_785
hp-ux-B.11.11-9000-785

Notice that one has an underscore, the other a dash.

Either the code is sysconfig or distutils needs to change slightly so that they match.
e.g.
Index: Lib/sysconfig.py
===================================================================
--- Lib/sysconfig.py.orig       2010-05-19 22:20:14.000000000 +0000
+++ Lib/sysconfig.py    2010-07-16 02:52:39.385322407 +0000
@@ -569,3 +569,3 @@
     machine = machine.replace(' ', '_')
-    machine = machine.replace('/', '-')
+    machine = machine.replace('/', '_')

----------
assignee: tarek
components: Distutils
messages: 110411
nosy: bugs-python at vendor.thewrittenword.com, tarek
priority: normal
severity: normal
status: open
title: distutils.util.getplatform and sysconfig.getplatform differ
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul 16 07:49:07 2010
From: report at bugs.python.org (Jason Gross)
Date: Fri, 16 Jul 2010 05:49:07 +0000
Subject: [New-bugs-announce] [issue9271] Python throws `IOError: [Errno 27]
	File too large' on	long file names
In-Reply-To: <1279259347.56.0.547870211974.issue9271@psf.upfronthosting.co.za>
Message-ID: <1279259347.56.0.547870211974.issue9271@psf.upfronthosting.co.za>


New submission from Jason Gross <jasongross9 at gmail.com>:

On attempting to open files with sufficiently long file names, python throws IOError: [Errno 27] File too large.  This is misleading, and perhaps should be relabeled as 'File name too long.'

I have only tested this on unix with Python 2.5.2.  This error was thrown when I opened /afs/athena.mit.edu/user/j/g/jgross/web_scripts/alphabets/results/turk/armenian_01_A3NOO9K3CY1YU5.cstroke for writing.

----------
components: IO
messages: 110414
nosy: Jason.Gross
priority: normal
severity: normal
status: open
title: Python throws `IOError: [Errno 27] File too large' on long file names
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Fri Jul 16 10:49:51 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 16 Jul 2010 08:49:51 +0000
Subject: [New-bugs-announce] [issue9272] CGIHTTPServer poisons os.environ
In-Reply-To: <1279270191.51.0.568678636745.issue9272@psf.upfronthosting.co.za>
Message-ID: <1279270191.51.0.568678636745.issue9272@psf.upfronthosting.co.za>


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

When CGIHTTPServer prepares to start child CGI program it modifies global os.environ. This implicitly changes parents application state if it also relies on some of CGI environment variables.

----------
messages: 110418
nosy: techtonik
priority: normal
severity: normal
status: open
title: CGIHTTPServer poisons os.environ
versions: Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Jul 16 17:48:45 2010
From: report at bugs.python.org (Tiago Antao)
Date: Fri, 16 Jul 2010 15:48:45 +0000
Subject: [New-bugs-announce] [issue9273] 2to to simultaneously do code AND
	doctests
In-Reply-To: <1279295325.63.0.00955742679892.issue9273@psf.upfronthosting.co.za>
Message-ID: <1279295325.63.0.00955742679892.issue9273@psf.upfronthosting.co.za>


New submission from Tiago Antao <tiagoantao at gmail.com>:

Currently 2to3 has to be called twice in order to do a full code conversion: one for the code and another for the doctests.

Would it be possible to do both things simultaneously (on passing a flag)?

It would be nice if distutils.command.build_py.build_py_2to3 would also have this functionality (ie a single pass for both code and docutils)

Thanks

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 110457
nosy: tiagoantao
priority: normal
severity: normal
status: open
title: 2to to simultaneously do code AND doctests

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

From report at bugs.python.org  Fri Jul 16 19:21:14 2010
From: report at bugs.python.org (Eric Promislow)
Date: Fri, 16 Jul 2010 17:21:14 +0000
Subject: [New-bugs-announce] [issue9274] code.InteractiveInterpreter fails
	to change locals when	invoked in a function
In-Reply-To: <1279300874.85.0.408315798568.issue9274@psf.upfronthosting.co.za>
Message-ID: <1279300874.85.0.408315798568.issue9274@psf.upfronthosting.co.za>


New submission from Eric Promislow <ericp at activestate.com>:

Similar to bug http://bugs.python.org/issue5215 which found
a workaround in pdb.  Here I want to use code.InteractiveInterpreter
to modify code interactively (see Komodo bug
http://bugs.activestate.com/show_bug.cgi?id=87405 )

I can do this at the top-level, but not inside a function.  The
attached file shows the problem:

----------
components: Interpreter Core
files: bug87405a.py
messages: 110464
nosy: ericp
priority: normal
severity: normal
status: open
title: code.InteractiveInterpreter fails to change locals when invoked in a function
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file18029/bug87405a.py

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

From report at bugs.python.org  Fri Jul 16 19:45:54 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Jul 2010 17:45:54 +0000
Subject: [New-bugs-announce] [issue9275] python 2.7 OS X installer no longer
	installs	/usr/local/bin symlinks by default
In-Reply-To: <1279302354.45.0.244219891996.issue9275@psf.upfronthosting.co.za>
Message-ID: <1279302354.45.0.244219891996.issue9275@psf.upfronthosting.co.za>


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

For 2.7, the set of default installed packages for the OS installer was changed for some reason to no longer select the "UNIX command-line tools" package by default so the traditional symlinks in /usr/local/bin are not being created by default.  This is a change in behavior from previous installers and the installer README files were not updated to reflect this change.  Users are confused by this, see for example:
http://stackoverflow.com/questions/3266005/why-arent-the-python-2-7-command-line-tools-located-in-usr-local-bin-on-mac-o/

Suggest reverting the change in behavior so that the symlinks are again installed by default.

----------
assignee: ronaldoussoren
components: Installation, Macintosh
messages: 110465
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: python 2.7 OS X installer no longer installs /usr/local/bin symlinks by default
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul 16 21:25:20 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 16 Jul 2010 19:25:20 +0000
Subject: [New-bugs-announce] [issue9276] pickle should support methods
In-Reply-To: <1279308320.41.0.159043379114.issue9276@psf.upfronthosting.co.za>
Message-ID: <1279308320.41.0.159043379114.issue9276@psf.upfronthosting.co.za>


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

pickle doesn't support methods:


>>> class x:
...     def y(self):
...             pass
... 
>>> import pickle
>>> pickle.dumps(x.y)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/exarkun/Projects/python/branches/py3k/Lib/pickle.py", line 1314, in dumps
    Pickler(f, protocol, fix_imports=fix_imports).dump(obj)
_pickle.PicklingError: Can't pickle <class 'function'>: attribute lookup builtins.function failed

It would be easy to fix this, though.  Here's a link to some code that implements it: http://twistedmatrix.com/trac/browser/trunk/twisted/persisted/styles.py?rev=1

----------
components: Library (Lib)
messages: 110473
nosy: exarkun
priority: normal
severity: normal
status: open
title: pickle should support methods
type: feature request

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

From report at bugs.python.org  Fri Jul 16 22:11:26 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 16 Jul 2010 20:11:26 +0000
Subject: [New-bugs-announce] [issue9277] test_struct failure on ARM
In-Reply-To: <1279311086.16.0.957118455274.issue9277@psf.upfronthosting.co.za>
Message-ID: <1279311086.16.0.957118455274.issue9277@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

test_struct currently fails on the ARM buildbots;  see:

http://www.python.org/dev//buildbot/builders/ARMv4%20Debian%203.x/builds/275/steps/test/logs/stdio


======================================================================
FAIL: test_bool (test.test_struct.StructTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pybot/buildarea-armeabi/3.x.klose-linux-armeabi/build/Lib/test/test_struct.py", line 521, in test_bool
    "ExplodingBool())" % (prefix + '?'))
AssertionError: Expected IOError: struct.pack('>?', ExplodingBool())

----------
components: Extension Modules
keywords: buildbot
messages: 110485
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: test_struct failure on ARM
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Jul 16 23:34:29 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 16 Jul 2010 21:34:29 +0000
Subject: [New-bugs-announce] [issue9278] rename 2to3 to 2to3.py
In-Reply-To: <1279316069.22.0.0186321125783.issue9278@psf.upfronthosting.co.za>
Message-ID: <1279316069.22.0.0186321125783.issue9278@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

C:\>c:\Python26\Tools\scripts\2to3
'c:\Python26\Tools\scripts\2to3' is not recognized as an internal or external command,
operable program or batch file.

All other scripts in Tools\scripts directory have .py extension. Only 2to3 doesn't.

----------
components: 2to3 (2.x to 3.0 conversion tool), Windows
messages: 110503
nosy: srid
priority: normal
severity: normal
status: open
title: rename 2to3 to 2to3.py
type: feature request
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul 16 23:41:27 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 16 Jul 2010 21:41:27 +0000
Subject: [New-bugs-announce] [issue9279] get rid of pdb.doc
In-Reply-To: <1279316487.65.0.399467366411.issue9279@psf.upfronthosting.co.za>
Message-ID: <1279316487.65.0.399467366411.issue9279@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

Put it into pdb.__doc__ instead.

----------
assignee: georg.brandl
components: Library (Lib)
keywords: easy
messages: 110505
nosy: georg.brandl
priority: normal
severity: normal
status: open
title: get rid of pdb.doc
versions: Python 3.2

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

From report at bugs.python.org  Sat Jul 17 06:48:17 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 17 Jul 2010 04:48:17 +0000
Subject: [New-bugs-announce] [issue9280] sharedinstall target doesn't depend
	on sharedmods target
In-Reply-To: <1279342097.68.0.765090641555.issue9280@psf.upfronthosting.co.za>
Message-ID: <1279342097.68.0.765090641555.issue9280@psf.upfronthosting.co.za>


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

altinstall target depends on libinstall target, which depends on build_all target, which depends on sharedmods target.
altinstall target also depends on sharedinstall target.
Both sharedmods and sharedinstall targets call setup.py.
This can cause failure of parallel installation, when setup.py is called twice at the same time.

This problem was reproduced by Gentoo users:
https://bugs.gentoo.org/show_bug.cgi?id=328009

I'm attaching the patch.

----------
components: Build
files: python-Makefile.pre.in.patch
keywords: patch
messages: 110537
nosy: Arfrever
priority: normal
severity: normal
status: open
title: sharedinstall target doesn't depend on sharedmods target
type: compile error
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file18035/python-Makefile.pre.in.patch

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

From report at bugs.python.org  Sat Jul 17 07:00:39 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 17 Jul 2010 05:00:39 +0000
Subject: [New-bugs-announce] [issue9281] Race condition in
	distutils.dir_util.mkpath()
In-Reply-To: <1279342839.57.0.133468665449.issue9281@psf.upfronthosting.co.za>
Message-ID: <1279342839.57.0.133468665449.issue9281@psf.upfronthosting.co.za>


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

distutils.dir_util.mkpath() is used to create a directory and is supposed to not fail when this directory already exists.
There's a chance that another process will create this directory between os.path.isdir() check and call to os.mkdir().
This was reproduced by a Gentoo user during parallel installation of Python:
https://bugs.gentoo.org/show_bug.cgi?id=311437

I'm attaching the patch.

----------
assignee: tarek
components: Distutils
files: distutils-dir_util.patch
keywords: patch
messages: 110538
nosy: Arfrever, tarek
priority: normal
severity: normal
status: open
title: Race condition in distutils.dir_util.mkpath()
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file18036/distutils-dir_util.patch

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

From report at bugs.python.org  Sat Jul 17 10:38:40 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 17 Jul 2010 08:38:40 +0000
Subject: [New-bugs-announce] [issue9282] Bug in --listfuncs option of
	trace.py
In-Reply-To: <1279355920.89.0.901837761289.issue9282@psf.upfronthosting.co.za>
Message-ID: <1279355920.89.0.901837761289.issue9282@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

Running:

py3d -m trace -C . --listfuncs trace_target.py

Where py3d points to a freshly compiled Python 3 trunk interpreter, results in an error: 

functions called:
Traceback (most recent call last):
  File "/home/eliben/python_src/eliben-py3k/Lib/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/home/eliben/python_src/eliben-py3k/Lib/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "/home/eliben/python_src/eliben-py3k/Lib/trace.py", line 816, in <module>
    main()
  File "/home/eliben/python_src/eliben-py3k/Lib/trace.py", line 813, in main
    results.write_results(missing, summary=summary, coverdir=coverdir)
  File "/home/eliben/python_src/eliben-py3k/Lib/trace.py", line 260, in write_results
    for filename, modulename, funcname in sorted(calls.keys()):
NameError: global name 'calls' is not defined


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

With Python 2.x it runs fine. The cause is probably a bug introduced during the porting to Python 3. The relevant piece of code in the write_results() method in trace.py is:

        if self.calledfuncs:
            print()
            print("functions called:")
            for filename, modulename, funcname in sorted(calls.keys()):
                print(("filename: %s, modulename: %s, funcname: %s"
                       % (filename, modulename, funcname)))

The 'calls' variable in the loop isn't defined anywhere. Previously (in 2.6) this same chunk of code looked like this:

        if self.calledfuncs:
            print
            print "functions called:"
            calls = self.calledfuncs.keys()
            calls.sort()
            for filename, modulename, funcname in calls:
                print ("filename: %s, modulename: %s, funcname: %s"
                       % (filename, modulename, funcname))

Which aliases 'calls' to 'self.calledfuncs.keys()'

------

Once this is confirmed as a bug, I will be happy to submit a patch that solves the problem.

----------
components: Library (Lib)
messages: 110543
nosy: eli.bendersky, tjreedy
priority: normal
severity: normal
status: open
title: Bug in --listfuncs option of trace.py
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jul 17 13:07:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Jul 2010 11:07:39 +0000
Subject: [New-bugs-announce] [issue9283] buggy repr for os.environ
In-Reply-To: <1279364859.98.0.0796685002752.issue9283@psf.upfronthosting.co.za>
Message-ID: <1279364859.98.0.0796685002752.issue9283@psf.upfronthosting.co.za>


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

os.environ has the same repr as os.environb, that is, it looks as though it's a mapping of bytes to bytes, while it's a mapping of str to str.

>>> repr(os.environ)[:50]
"environ({b'TMP': b'/tmp/', b'XAUTHORITY': b'/var/r"
>>> repr(os.environb)[:50]
"environ({b'TMP': b'/tmp/', b'XAUTHORITY': b'/var/r"

----------
assignee: haypo
components: Library (Lib)
messages: 110547
nosy: haypo, pitrou
priority: high
severity: normal
status: open
title: buggy repr for os.environ
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat Jul 17 15:16:57 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Sat, 17 Jul 2010 13:16:57 +0000
Subject: [New-bugs-announce] [issue9284] inspect.findsource() cannot find
	source for doctest code
In-Reply-To: <1279372617.05.0.528440876901.issue9284@psf.upfronthosting.co.za>
Message-ID: <1279372617.05.0.528440876901.issue9284@psf.upfronthosting.co.za>


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

The fix for issue4050 broke some of my doctests. Minimal test:

import doctest, inspect
def test():
    '''
    >>> def x(): pass
    >>> inspect.getsource(x)
    'def x(): pass\\n'
    '''
doctest.run_docstring_examples(test, globals())

This works in 2.6, but not in 2.7. Reason is that inspect.getsourcefile() finds the fake filename '<docTest NoName[0]>', which it doesn't understand. In 2.6, inspect.getmodule() is also tried, which first looks at obj.__module__, and the filename can be derived from that. I suggest that inspect.getsourcefile() grows some code to use this trick if the filename seems fake (f[0] + f[-1] == '<>').

----------
components: Library (Lib)
messages: 110551
nosy: ajaksu2, brodie, djc, pitrou, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: inspect.findsource() cannot find source for doctest code
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Jul 17 16:01:14 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 17 Jul 2010 14:01:14 +0000
Subject: [New-bugs-announce] [issue9285] A decorator for cProfile and
	profile modules
In-Reply-To: <1279375274.49.0.102313390752.issue9285@psf.upfronthosting.co.za>
Message-ID: <1279375274.49.0.102313390752.issue9285@psf.upfronthosting.co.za>


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

A patch including tests is in attachment.
Example usage:

>>> from cProfile import profile
>>>
>>> @profile
... def factorial(n):
...     n = abs(int(n))
...     if n < 1: 
...             n = 1
...     x = 1
...     for i in range(1, n+1):
...             x = i * x
...     return x
... 
>>>
>>> factorial(5)
    Thu Jul 15 20:58:21 2010    /tmp/tmpIDejr5

             4 function calls in 0.000 CPU seconds

       Ordered by: internal time, call count

       ncalls  tottime  percall  cumtime  percall filename:lineno(function)
            1    0.000    0.000    0.000    0.000 profiler.py:120(factorial)
            1    0.000    0.000    0.000    0.000 {range}
            1    0.000    0.000    0.000    0.000 {abs}
            1    0.000    0.000    0.000    0.000 {method 'disable' of '_lsprof.Profiler' objects}

120
>>>


Before including doc changes I'd like to hear whether this is actually desirable or not.

----------
assignee: collinwinter
components: Benchmarks, Library (Lib)
files: profile.patch
keywords: needs review, patch, patch
messages: 110555
nosy: collinwinter, giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: A decorator for cProfile and profile modules
versions: Python 3.2
Added file: http://bugs.python.org/file18039/profile.patch

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

From report at bugs.python.org  Sat Jul 17 16:35:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 17 Jul 2010 14:35:59 +0000
Subject: [New-bugs-announce] [issue9286] email.utils.parseaddr returns
	garbage for invalid input
In-Reply-To: <1279377359.55.0.199569408455.issue9286@psf.upfronthosting.co.za>
Message-ID: <1279377359.55.0.199569408455.issue9286@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

This behavior does not seem right to me:

parsing 'merwok'
 expected ('merwok', '')
 got      ('', 'merwok')

parsing 'merwok wok at rusty'
 expected ('', 'wok at rusty')
 got      ('', 'merwokwok at rusty')

(Generated with a small script just doing a loop and prints, not attached because boring.)

Are my expectations wrong? I don?t know if a string like ?merwok? in my first example is a legal address in the relevant RFCs; Mark Sapiro replied in msg110556 that it could be consistent with most MUAs/MTAs.

I don?t know either if the folding done in the second example is okay; I?d like an exception here, or if parseaddr is designed to never fail, empty strings to indicate failure. I?m also okay with ?garbage in, garbage out? as answer.

----------
components: Library (Lib)
messages: 110561
nosy: merwok, r.david.murray
priority: normal
severity: normal
status: open
title: email.utils.parseaddr returns garbage for invalid input
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Jul 17 16:39:03 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 17 Jul 2010 14:39:03 +0000
Subject: [New-bugs-announce] [issue9287] Cosmetic fix in
	OtherFileTests.testOpenDir
In-Reply-To: <1279377543.77.0.675008772529.issue9287@psf.upfronthosting.co.za>
Message-ID: <1279377543.77.0.675008772529.issue9287@psf.upfronthosting.co.za>


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

Hello. In OtherFileTests.testOpenDir(test_file), if we run this test
in Lib/test, __file__ becomes "test_file.py", so os.path.dirname(__file__) becomes "". I think it is better to use os.path.abspath to get valid folder path for test purpose.

# This test seems not to exist in Python2.7.

----------
components: Tests
files: test_file.patch
keywords: easy, patch
messages: 110563
nosy: ocean-city
priority: normal
severity: normal
stage: patch review
status: open
title: Cosmetic fix in OtherFileTests.testOpenDir
versions: Python 2.6
Added file: http://bugs.python.org/file18040/test_file.patch

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

From report at bugs.python.org  Sun Jul 18 00:09:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 17 Jul 2010 22:09:00 +0000
Subject: [New-bugs-announce] [issue9288] Disambiguate :option: and
	:cmdoption:
In-Reply-To: <1279404540.57.0.963765007492.issue9288@psf.upfronthosting.co.za>
Message-ID: <1279404540.57.0.963765007492.issue9288@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I made a doc patch in a followup to http://mail.python.org/pipermail/python-dev/2010-July/102011.html

----------
assignee: docs at python
components: Documentation
files: improve-check.diff
keywords: needs review, patch
messages: 110606
nosy: docs at python, merwok
priority: normal
severity: normal
status: open
title: Disambiguate :option: and :cmdoption:
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file18046/improve-check.diff

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

From report at bugs.python.org  Sun Jul 18 02:48:54 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 18 Jul 2010 00:48:54 +0000
Subject: [New-bugs-announce] [issue9289] Skip test_long_key(test_winreg) on
	win2k + py2.x
In-Reply-To: <1279414134.03.0.595847788627.issue9289@psf.upfronthosting.co.za>
Message-ID: <1279414134.03.0.595847788627.issue9289@psf.upfronthosting.co.za>


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

test_long_key fails on win2k + python2.x.

======================================================================
ERROR: test_long_key (__main__.LocalWinregTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_winreg.py", line 279, in test_long_key
    DeleteKey(HKEY_CURRENT_USER, '\\'.join((test_key_name, name)))
WindowsError: [Error 234] ????????????

# Error says "More data is available"

According to
http://msdn.microsoft.com/en-us/library/ms724872(v=VS.85).aspx
  Value name:
    Windows 2000:  260 ANSI characters or 16,383 Unicode characters.

Windows 2000 cannot handle long value name like *name* in the test,
so I think we should skip the test on Windows 2000.

I confirmed test runs fine on python3.x. Probably because it uses unicode Win32 API.

----------
components: Tests, Windows
files: skip_test_long_key.patch
keywords: patch
messages: 110620
nosy: ocean-city
priority: normal
severity: normal
stage: patch review
status: open
title: Skip test_long_key(test_winreg) on win2k + py2.x
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file18048/skip_test_long_key.patch

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

From report at bugs.python.org  Sun Jul 18 03:51:35 2010
From: report at bugs.python.org (Geraldo Xexeo)
Date: Sun, 18 Jul 2010 01:51:35 +0000
Subject: [New-bugs-announce] [issue9290] IDLE and Command line present
	different behavior for	sys.stdin
In-Reply-To: <1279417895.54.0.811089047738.issue9290@psf.upfronthosting.co.za>
Message-ID: <1279417895.54.0.811089047738.issue9290@psf.upfronthosting.co.za>


New submission from Geraldo Xexeo <gxexeo at gmail.com>:

The fact that in IDLE sys.stdin is a idlelib.rpc.RPCProxy  results in programs having different behavior in IDLE and in Command Line mode.

I noticed that when grading many students exercises in IDLE. Things like:

sys.stdin.readlines()

just don?t exists in IDLE, but are fully operational in Command Line mode.

In Command Line mode, sys.stdin is a file.

This is expected, as the manual (27.1) says that sys.stdin (and stdout and stderrr) are "File objects corresponding to the interpreter?s standard input"

There are also other "quirks".

I fell that is really strange that stdin has different behavior for the same program.

----------
components: IDLE, IO
messages: 110621
nosy: Geraldo.Xexeo
priority: normal
severity: normal
status: open
title: IDLE and Command line present different behavior for sys.stdin
versions: Python 3.1

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

From report at bugs.python.org  Sun Jul 18 13:54:55 2010
From: report at bugs.python.org (Dmitry Jemerov)
Date: Sun, 18 Jul 2010 11:54:55 +0000
Subject: [New-bugs-announce] [issue9291] mimetypes initialization fails on
	Windows because of	non-Latin characters in registry
In-Reply-To: <1279454095.41.0.733053669611.issue9291@psf.upfronthosting.co.za>
Message-ID: <1279454095.41.0.733053669611.issue9291@psf.upfronthosting.co.za>


New submission from Dmitry Jemerov <intelliyole at gmail.com>:

On Windows, mimetypes initialization reads the list of MIME types from the Windows registry. It assumes that all characters are Latin-1 encoded, and fails when it's not the case, with the following exception:

Traceback (most recent call last):
  File "mttest.py", line 3, in <module>
    mimetypes.init()
  File "c:\Python27\lib\mimetypes.py", line 355, in init
    db.read_windows_registry()
  File "c:\Python27\lib\mimetypes.py", line 260, in read_windows_registry
    for ctype in enum_types(mimedb):
  File "c:\Python27\lib\mimetypes.py", line 250, in enum_types
    ctype = ctype.encode(default_encoding) # omit in 3.x!
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe0 in position 0: ordinal not in range(128)

This can be reproduced, for example, on a Russian Windows XP installation which has QuickTime installed (QuickTime creates the non-Latin entries in the registry). The following line causes the exception to happen:

import mimetypes; mimetypes.init()

----------
components: Library (Lib), Windows
messages: 110637
nosy: Dmitry.Jemerov
priority: normal
severity: normal
status: open
title: mimetypes initialization fails on Windows because of non-Latin characters in registry
versions: Python 2.7

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

From report at bugs.python.org  Sun Jul 18 15:44:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Jul 2010 13:44:25 +0000
Subject: [New-bugs-announce] [issue9292] Dead code in Modules/pyexpat.c
In-Reply-To: <1279460665.67.0.339124626695.issue9292@psf.upfronthosting.co.za>
Message-ID: <1279460665.67.0.339124626695.issue9292@psf.upfronthosting.co.za>


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

There's some dead code in xmlparse_ParseFile() in Modules/pyexpat.c: the file pointer "fp" is always NULL, and as such the following code can never get entered into:

        if (fp) {
            bytes_read = fread(buf, sizeof(char), BUF_SIZE, fp);
            if (bytes_read < 0) {
                PyErr_SetFromErrno(PyExc_IOError);
                return NULL;
            }
        }

There might be similar situations in other methods.

----------
components: Extension Modules
messages: 110646
nosy: akuchling, christian.heimes, pitrou
priority: low
severity: normal
stage: needs patch
status: open
title: Dead code in Modules/pyexpat.c
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Jul 18 16:09:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Jul 2010 14:09:31 +0000
Subject: [New-bugs-announce] [issue9293] Unsupported IO operations should
	raise	UnsupportedOperation
In-Reply-To: <1279462171.13.0.608517762148.issue9293@psf.upfronthosting.co.za>
Message-ID: <1279462171.13.0.608517762148.issue9293@psf.upfronthosting.co.za>


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

Some of them currently raise IOError. Fortunately, UnsupportedOperation inherits from IOError, which means compatibility can be preserved.

Contrast:
>>> open("LICENSE").write("bar")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: not writable

With:
>>> open("LICENSE", "rb").write(b"")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
io.UnsupportedOperation: write

Or:
>>> io.StringIO().fileno()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
io.UnsupportedOperation: fileno

Or, unfortunately:

>>> open("LICENSE", "rb", buffering=0).write(b"")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: File not open for writing

----------
components: IO, Library (Lib)
keywords: easy
messages: 110648
nosy: amaury.forgeotdarc, benjamin.peterson, haypo, pitrou
priority: normal
severity: normal
status: open
title: Unsupported IO operations should raise UnsupportedOperation
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Jul 18 16:55:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Jul 2010 14:55:44 +0000
Subject: [New-bugs-announce] [issue9294] Dead code in Objects/object.c
In-Reply-To: <1279464944.67.0.616745975029.issue9294@psf.upfronthosting.co.za>
Message-ID: <1279464944.67.0.616745975029.issue9294@psf.upfronthosting.co.za>


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

internal_print() is called from only one place, with the `nesting` argument wired to 0, therefore the following chunk of code in internal_print() never gets a chance to be executed:

    if (nesting > 10) {
        PyErr_SetString(PyExc_RuntimeError, "print recursion");
        return -1;
    }

----------
components: Interpreter Core
messages: 110651
nosy: pitrou
priority: low
severity: normal
stage: needs patch
status: open
title: Dead code in Objects/object.c
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Jul 18 16:59:36 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 18 Jul 2010 14:59:36 +0000
Subject: [New-bugs-announce] [issue9295]
	test_close_open_print_buffered(test_file) sometimes	crashes
In-Reply-To: <1279465176.3.0.233257918018.issue9295@psf.upfronthosting.co.za>
Message-ID: <1279465176.3.0.233257918018.issue9295@psf.upfronthosting.co.za>


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

I noticed test_close_open_print_buffered(test_file) sometimes crashes on release26-maint branch. This is most problamatic part in my python2.6 test survey on VC6 + Win2K.

Here is stacktrace.

_write_lk(int 6, const void * 0x00b49240, unsigned int 11) line 155 + 3 bytes
_write(int 6, const void * 0x00b49240, unsigned int 11) line 79 + 17 bytes
_flush(_iobuf * 0x102618e8) line 162 + 23 bytes
_fclose_lk(_iobuf * 0x102618e8) line 130 + 9 bytes
fclose(_iobuf * 0x102618e8) line 67 + 9 bytes
close_the_file(PyFileObject * 0x00a9e6b8) line 370 + 7 bytes
file_close(PyFileObject * 0x00a9e6b8) line 570 + 9 bytes
call_function(_object * * * 0x00fdf350, int 11134648) line 3734 + 204 bytes
PyEval_EvalFrameEx(_frame * 0x00b33d50, int 131) line 2414
(snip)

Python crashes when MSVCRT touches internal buffer of file object via flush() in close().

I think this is multi-threading bug related to internal buffer of file object. I'll post more.

----------
components: Interpreter Core
messages: 110652
nosy: ocean-city
priority: normal
severity: normal
stage: needs patch
status: open
title: test_close_open_print_buffered(test_file) sometimes crashes
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Sun Jul 18 17:48:56 2010
From: report at bugs.python.org (Doug Hellmann)
Date: Sun, 18 Jul 2010 15:48:56 +0000
Subject: [New-bugs-announce] [issue9296] json module skipkeys handling
	changed exception types in	2.7
In-Reply-To: <1279468136.69.0.813704540742.issue9296@psf.upfronthosting.co.za>
Message-ID: <1279468136.69.0.813704540742.issue9296@psf.upfronthosting.co.za>


New submission from Doug Hellmann <doug.hellmann at gmail.com>:

Under Python 2.6 the json encoder raised a TypeError when it encountered dictionary keys that were not strings.  Under 2.7, that exception has changed to a ValueError, but the documentation still says it raises TypeError.  I'm not sure which is right, but TypeError seems like the correct exception.

----------
components: Library (Lib)
messages: 110660
nosy: doughellmann
priority: normal
severity: normal
status: open
title: json module skipkeys handling changed exception types in 2.7
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul 19 03:55:16 2010
From: report at bugs.python.org (Murilo da Silva)
Date: Mon, 19 Jul 2010 01:55:16 +0000
Subject: [New-bugs-announce] [issue9297] SMTP with Sqlite3 file attachment
In-Reply-To: <1279504516.14.0.42498978414.issue9297@psf.upfronthosting.co.za>
Message-ID: <1279504516.14.0.42498978414.issue9297@psf.upfronthosting.co.za>


New submission from Murilo da Silva <murilobr at gmail.com>:

I'm sending e-mail using SMTP. This e-mail is sent with an Sqlite3 database attached.
When I send the e-mail in the same domain the attachment arrives OK, but if I send it to a different domain it comes crashed!!
The file is added with some base64 code...I don't have any ideia why!

The code mail.py:

import smtplib
import os
import mimetypes
import base64

from email import encoders
from email.message import Message
from email.mime.base import MIMEBase
from email.mime.nonmultipart import MIMENonMultipart
from email.mime.multipart import MIMEMultipart
from email.mime.application import MIMEApplication
from email.mime.audio import MIMEAudio
from email.mime.image import MIMEImage
from email.mime.message import MIMEMessage
from email.mime.text import MIMEText

class SendMail:
    def __init__(self):
        self.body = []
        self.attachments = []
    
    def add_body(self, _text, _subtype='plain', _charset='us-ascii'):
        part = MIMEText(_text+"\n", _subtype, _charset)
        self.body.append(part)

    def add_attach(self, _file_path, _subtype='octet-stream', _encoder=encoders.encode_base64, **_params):
        path = _file_path
        ctype, encoding = mimetypes.guess_type(path)
        if ctype is None or encoding is not None:
            ctype = 'application/octet-stream'
        maintype, subtype = ctype.split('/', 1)
        if maintype == 'text':
            fp = open(path)
            part = MIMEText(fp.read(), _subtype=subtype)
            fp.close()
        elif maintype == 'image':
            fp = open(path, 'rb')
            part = MIMEImage(fp.read(), _subtype=subtype)
            fp.close()
        elif maintype == 'audio':
            fp = open(path, 'rb')
            part = MIMEAudio(fp.read(), _subtype=subtype)
            fp.close()
        else:
            fp = open(path, 'rb')
            part = MIMEBase(maintype, subtype)
            part.set_payload(fp.read())
            fp.close()
            # Encode the payload using Base64
            encoders.encode_base64(part)
            part.set_payload(part.get_payload().decode())
        
        part.add_header('Content-Disposition', 'attachment', filename = path.split(os.sep)[-1])
        self.attachments.append(part)      

    def send_now(self, mail_from, mail_to, subject, multipart_subtype='mixed', host=None, port=25, auth=False, user="", passw=""):
        msg = MIMEMultipart(multipart_subtype)
        msg['Subject'] = subject
        msg['From'] = mail_from
        if type(mail_to) is list:
            msg['To'] = ", ".join(mail_to)
        else:
            msg['To'] = mail_to

        for b in self.body:
            msg.attach(b)

        for att in self.attachments:
            msg.attach(att)
        
        try:
            mailserver = smtplib.SMTP(host, port)
            #mailserver.set_debuglevel(1)
            mailserver.ehlo() 
            mailserver.starttls() 
            mailserver.ehlo()
            if auth:
                mailserver.login(user, passw) 

            mailserver.sendmail(mail_from, mail_to, msg.as_string())
            
            mailserver.close()
        
            return True
        except Exception as e:
            print(e)
            return False

The database to attach is in the final.

The example:
s = SendMail()
s.add_body("test")
s.add_attach(os.path.abspath("test.db"))
s.send_now("test at domain1.com", "test at domain2.com", "test", host="smtp.domain1.com", port=25, auth=True, user="user", passw="pass")

----------
components: Library (Lib)
files: test.db
messages: 110707
nosy: murilobr
priority: normal
severity: normal
status: open
title: SMTP with Sqlite3 file attachment
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file18056/test.db

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

From report at bugs.python.org  Mon Jul 19 05:04:56 2010
From: report at bugs.python.org (Vance Unruh)
Date: Mon, 19 Jul 2010 03:04:56 +0000
Subject: [New-bugs-announce] [issue9298] binary email attachment issue with
	base64 encoding
In-Reply-To: <1279508696.99.0.665109757672.issue9298@psf.upfronthosting.co.za>
Message-ID: <1279508696.99.0.665109757672.issue9298@psf.upfronthosting.co.za>


New submission from Vance Unruh <vunruh at earthlink.net>:

I'm using Python to email a text version and a PDF version of a report. The standard way of doing things does not work with Vista's Mail program, but works fine with Mail on OSX. So, I don't know if this is a Python or a Vista Mail bug. By standard way, I mean:

    # Add the attached PDF:
    part = MIMEApplication(pdf,"pdf")
    part.add_header('Content-Disposition', 'attachment', filename=pdfFile)
    msg.attach(part)


To fix the problem, I changed C:\Python31\Lib\email\encoders.py to use encodebytes instead of b64encode in order to get mail on Windows Vista to correctly interpret the attachment. This splits the base64 encoding into many lines of some fixed lenth.

I can achieve the same thing adding the attachment by hand with the following code:

    from email.mime.base import MIMEBase
    part = MIMEBase("application","pdf")
    part.add_header('Content-Transfer-Encoding', 'base64') 
    part.set_payload(str(base64.encodebytes(pdf),'ascii'))
    msg.attach(part)

Seems like I shouldn't need to know this much.

I'm new to Python and this is the first bug I have submitted, so if you need additional information, please let me know.

----------
components: Library (Lib)
messages: 110710
nosy: vunruh
priority: normal
severity: normal
status: open
title: binary email attachment issue with base64 encoding
versions: Python 3.1

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

From report at bugs.python.org  Mon Jul 19 10:47:35 2010
From: report at bugs.python.org (Ray.Allen)
Date: Mon, 19 Jul 2010 08:47:35 +0000
Subject: [New-bugs-announce] [issue9299] os.mkdir() and os.makedirs() add a
	keyword argument to	suppress "File exists" exception.
In-Reply-To: <1279529255.89.0.917982060428.issue9299@psf.upfronthosting.co.za>
Message-ID: <1279529255.89.0.917982060428.issue9299@psf.upfronthosting.co.za>


New submission from Ray.Allen <ysj.ray at gmail.com>:

As discussed in python-dev mailing list, something should be add to os.mkdir() and os.makedirs() to simulate the shell's "mkdir -p" function, that is, suppress the OSError exception if the target directory exists. 

Here is a patch against py3k, with code, test and doc. I add an "ensure_exist" keyword argument for both os.mkdir() and os.makedirs(), indicates weather an OSError is raised if the target directory already exists.

Since I've no windows environment, I only tested the patch on Unix. Hope someone could help test it on windows.

----------
components: Library (Lib)
files: mkdir_py3k.diff
keywords: patch
messages: 110719
nosy: ysj.ray
priority: normal
severity: normal
status: open
title: os.mkdir() and os.makedirs() add a keyword argument to suppress "File exists" exception.
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file18059/mkdir_py3k.diff

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

From report at bugs.python.org  Mon Jul 19 10:59:59 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 19 Jul 2010 08:59:59 +0000
Subject: [New-bugs-announce] [issue9300] c/profile Profile class is not
	documented
In-Reply-To: <1279529999.64.0.448186271222.issue9300@psf.upfronthosting.co.za>
Message-ID: <1279529999.64.0.448186271222.issue9300@psf.upfronthosting.co.za>


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

http://docs.python.org/library/profile.html

...while it is, for example, for hotshot module:
http://docs.python.org/library/hotshot.html#hotshot.Profile

Profile class contains some useful methods which are surely worth mentioning, like print_stat() and runcall() above all.

----------
assignee: docs at python
components: Documentation
messages: 110722
nosy: docs at python, giampaolo.rodola
priority: normal
severity: normal
stage: needs patch
status: open
title: c/profile Profile class is not documented
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Jul 19 11:09:48 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Mon, 19 Jul 2010 09:09:48 +0000
Subject: [New-bugs-announce] [issue9301] urllib.quote(None) returns None in
	2.7 (raised TypeError	before)
In-Reply-To: <1279530588.62.0.226192140376.issue9301@psf.upfronthosting.co.za>
Message-ID: <1279530588.62.0.226192140376.issue9301@psf.upfronthosting.co.za>


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

Rejecting invalid input seems better in this case. This was changed in issue1285086. Can we preface the normal fast path with something like:

    if s is None:
        raise TypeError('can only quote strings')

It used to raise:

    Traceback (most recent call last):
      File "/usr/lib64/python2.6/urllib.py", line 1222, in quote
        res = map(safe_map.__getitem__, s)
    TypeError: argument 2 to map() must support iteration

----------
components: Library (Lib)
messages: 110723
nosy: djc, flox, orsenthil
priority: normal
severity: normal
status: open
title: urllib.quote(None) returns None in 2.7 (raised TypeError before)
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul 19 11:43:25 2010
From: report at bugs.python.org (Ray.Allen)
Date: Mon, 19 Jul 2010 09:43:25 +0000
Subject: [New-bugs-announce] [issue9302] Distutils document problem?
In-Reply-To: <1279532605.75.0.42010773345.issue9302@psf.upfronthosting.co.za>
Message-ID: <1279532605.75.0.42010773345.issue9302@psf.upfronthosting.co.za>


New submission from Ray.Allen <ysj.ray at gmail.com>:

The distutils api document for class Extension:

http://docs.python.org/dev/py3k/distutils/apiref.html#distutils.core.Extension

Among the argument, in fact, the type of the arguments "sources", "include_dirs", "library_dirs", "libraries", "runtime_library_dirs" must be list, but all of them are marked as "string". I think this is a problem. 

Here is a patch for this, against py3k.

----------
assignee: docs at python
components: Documentation
files: distutils_apiref.diff
keywords: patch
messages: 110724
nosy: docs at python, ysj.ray
priority: normal
severity: normal
status: open
title: Distutils document problem?
versions: Python 3.2
Added file: http://bugs.python.org/file18061/distutils_apiref.diff

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

From report at bugs.python.org  Mon Jul 19 14:08:06 2010
From: report at bugs.python.org (Michael Schwarz)
Date: Mon, 19 Jul 2010 12:08:06 +0000
Subject: [New-bugs-announce] [issue9303] Migrate sqlite3 module to _v2 API
	to enhance performance
In-Reply-To: <1279541286.68.0.824716490463.issue9303@psf.upfronthosting.co.za>
Message-ID: <1279541286.68.0.824716490463.issue9303@psf.upfronthosting.co.za>


New submission from Michael Schwarz <michi.schwarz at gmail.com>:

The Python sqlite module currently uses some deprecated API [0] of SQLite. These are functions that have a counterpart with _v2 appended to their name.

The SQLite query planner will not use certain optimizations when using the old API. For example, as documented in [1], using a statement with a GLOB or LIKE operator where the pattern is parametrized will only use an appropriate index if sqlite3_prepare_v2() is used instead of sqlite3_prepare().

Following is an example of such a query. When executed, table 'test' is scanned row by row, which requires all data in the table to be loaded from disk.

cursor.execute('create table test(a text)')
cursor.execute('create index test_index on test(a)')
# insert some data here
cursor.execute('select * from test where a glob ?', ['prefix*'])

When the same query is executed in the sqlite3 command line utility, the index 'test_index' is used instead.

sqlite> create table test(a text);
sqlite> create index test_index on test(a);
sqlite> explain query plan select * from test where a glob 'prefix*';
order	from	detail
0	0	TABLE test WITH INDEX test_index

The query in this example is not parametrized as parameters can't be filled in when using the sqlite3 command line utility. This is just to show that the schema and the query allow the index to be used with certain pattern strings.

[0]: http://www.sqlite.org/c3ref/funclist.html
[1]: http://www.sqlite.org/optoverview.html#like_opt

Michael

----------
components: Extension Modules
messages: 110739
nosy: feuermurmel
priority: normal
severity: normal
status: open
title: Migrate sqlite3 module to _v2 API to enhance performance
type: performance
versions: Python 3.1

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

From report at bugs.python.org  Mon Jul 19 17:25:53 2010
From: report at bugs.python.org (Carl Chenet)
Date: Mon, 19 Jul 2010 15:25:53 +0000
Subject: [New-bugs-announce] [issue9304] unreproducible example in the
	memoryview documentation
In-Reply-To: <1279553153.05.0.828630884678.issue9304@psf.upfronthosting.co.za>
Message-ID: <1279553153.05.0.828630884678.issue9304@psf.upfronthosting.co.za>


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

Hi,

In the current documentation at http://docs.python.org/library/stdtypes.html#memoryview, the first example announces : 

>>> v = memoryview('abcefg')
>>> v[1]
'b'
>>> v[-1]
'g'
>>> v[1:4]
<memory at 0x77ab28>
>>> str(v[1:4])
'bce'

Trying to reproduce this example I got : 

$ python
Python 2.7 (r27:82500, Jul 13 2010, 17:48:51) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> v = memoryview('abcefg')
>>> v[1]
'b'
>>> v[-1]
'g'
>>> v[1:4]
<memory at 0xa2a510>
>>> str(v[1:4])
'<memory at 0xa2a5a8>'

The last line of the example in the documentation is not reproducible. Hope it's only a documentation issue.

Bye,
Carl Chenet

----------
assignee: docs at python
components: Documentation
messages: 110766
nosy: chaica_, docs at python
priority: normal
severity: normal
status: open
title: unreproducible example in the memoryview documentation
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul 19 18:21:45 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 19 Jul 2010 16:21:45 +0000
Subject: [New-bugs-announce] [issue9305] Don't use east/west of UTC in
	date/time documentation
In-Reply-To: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za>
Message-ID: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

I am opening this to supersede issue7229.  See discussion following msg107148.

In many places offsets representing the difference between local time and UTC are described as minutes or seconds east or west of UTC.   This is not correct because UTC is not a place and minutes and seconds don't measure distance in this context.  Replacing UTC with the Prime Meridian will not fix that because some regions in the western hemisphere use positive offsets from UTC.  or example, Madrid is at 3? 42' West, but uses Central European Time which is UTC+1.

I believe geographical references in the python documentation are irrelevant.  What users are interested in is how to convert local time to UTC and UTC to local time rather than what is the sign of time.timezone in Madrid.

I suggest the following wording for time.timezone description:

time.timezone: The number of seconds one must add to the local time to arrive at UTC.

Similarly, tzinfo.utcoffset() can be defined as "Returns timedelta one must add to UTC to arrive at local time."

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 110774
nosy: belopolsky, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Don't use east/west of UTC in date/time documentation
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Mon Jul 19 18:35:21 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 19 Jul 2010 16:35:21 +0000
Subject: [New-bugs-announce] [issue9306] distutils: raise informative error
	message when cmd_class	is None
In-Reply-To: <1279557321.49.0.203770679838.issue9306@psf.upfronthosting.co.za>
Message-ID: <1279557321.49.0.203770679838.issue9306@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

Current I see this:

 File "/opt/ActivePython-2.7/lib/python2.7/distutils/dist.py", line 806, in get_command_class
   klass = self.cmdclass.get(command)
AttributeError: 'NoneType' object has no attribute 'get'

more context: https://bugs.launchpad.net/pyreadline/+bug/607329

----------
assignee: tarek
components: Distutils
messages: 110776
nosy: srid, tarek
priority: normal
severity: normal
status: open
title: distutils: raise informative error message when cmd_class is None
type: feature request
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Jul 19 19:50:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 19 Jul 2010 17:50:25 +0000
Subject: [New-bugs-announce] [issue9307] Py_TPFLAGS_LONG_SUBCLASS is not
	documented
In-Reply-To: <1279561825.23.0.120090245801.issue9307@psf.upfronthosting.co.za>
Message-ID: <1279561825.23.0.120090245801.issue9307@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Is there a reason for not documenting Py_TPFLAGS_LONG_SUBCLASS (Py_TPFLAGS_INT_SUBCLASS in 2.x)?

This flag is used in PyLong_Check, but neither this flag or its inheritance properties are explained anywhere in the docs.

See also issue5476.

----------
assignee: docs at python
components: Documentation
messages: 110787
nosy: belopolsky, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Py_TPFLAGS_LONG_SUBCLASS is not documented
type: feature request

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

From report at bugs.python.org  Mon Jul 19 20:57:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 19 Jul 2010 18:57:09 +0000
Subject: [New-bugs-announce] [issue9308] Remove redundant coding cookies
	from 3.x stdlib
In-Reply-To: <1279565829.31.0.797750861129.issue9308@psf.upfronthosting.co.za>
Message-ID: <1279565829.31.0.797750861129.issue9308@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

On Mon, Jul 19, 2010 at 2:45 AM, Guido van Rossum <guido at python.org> wrote:
> Sounds like a good idea to try to remove redundant cookies *and* to
> remove most occasional use of non-ASCII characters outside comments
> (except for unittests specifically trying to test Unicode features).
> Personally I would use \xXX escapes instead of spelling out the
> characters in shlex.py, for example.
>
> Both with or without the coding cookies, many ways of displaying text
> files garble characters outside the ASCII range, so it's better to
> stick to ASCII as much as possible.
>
> --Guido
>
> On Mon, Jul 19, 2010 at 1:21 AM, Alexander Belopolsky
> <alexander.belopolsky at gmail.com> wrote:
>> I was looking at the inspect module and noticed that it's source
>> starts with "# -*- coding: iso-8859-1 -*-". ? I have checked and there
>> are no non-ascii characters in the file. ? There are several other
>> modules that still use the cookie:
>>
>> Lib/ast.py:# -*- coding: utf-8 -*-
>> Lib/getopt.py:# -*- coding: utf-8 -*-
>> Lib/inspect.py:# -*- coding: iso-8859-1 -*-
>> Lib/pydoc.py:# -*- coding: latin-1 -*-
>> Lib/shlex.py:# -*- coding: iso-8859-1 -*-
>> Lib/encodings/punycode.py:# -*- coding: utf-8 -*-
>> Lib/msilib/__init__.py:# -*- coding: utf-8 -*-
>> Lib/sqlite3/__init__.py:#-*- coding: ISO-8859-1 -*-
>> Lib/sqlite3/dbapi2.py:#-*- coding: ISO-8859-1 -*-
>> Lib/test/bad_coding.py:# -*- coding: uft-8 -*-
>> Lib/test/badsyntax_3131.py:# -*- coding: utf-8 -*-
>>
>> I understand that coding: utf-8 is strictly redundant in 3.x. ?There
>> are cases such as Lib/shlex.py where using encoding other than utf-8
>> is justified. ?(See
>> http://svn.python.org/view?view=rev&revision=82560). ?What are the
>> guidelines for other cases? ?Should redundant cookies be removed?
>> Since not all editors respect the ?-*- cookie, I think the answer
>> should be "yes" particularly when the cookie is setting encoding other
>> than utf-8.
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>

----------
assignee: belopolsky
components: Library (Lib)
messages: 110798
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Remove redundant coding cookies from 3.x stdlib

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

From report at bugs.python.org  Mon Jul 19 23:14:41 2010
From: report at bugs.python.org (Alexander Dreyer)
Date: Mon, 19 Jul 2010 21:14:41 +0000
Subject: [New-bugs-announce] [issue9309] Add environment variable
	complementing command line	option -no-user-cfg
In-Reply-To: <1279574081.87.0.528312419657.issue9309@psf.upfronthosting.co.za>
Message-ID: <1279574081.87.0.528312419657.issue9309@psf.upfronthosting.co.za>


New submission from Alexander Dreyer <adreyer at gmx.de>:

At the Sage Days 24 coding sprint the issue came up, that the setup.py install programs of several python-based tools pick the prefix-setting from ~/.pydistutils.cfg. 
http://trac.sagemath.org/sage_trac/ticket/9536

In order to get this right, we suggest to introduce the environment variable DISTUTILS_NO_USER_CFG. It can be used like the --no-user-cfg commandline option supported by distutils.

Best regards

----------
assignee: tarek
components: Distutils
files: dist.py.patch
keywords: patch
messages: 110811
nosy: AlexanderDreyer, tarek
priority: normal
severity: normal
status: open
title: Add environment variable complementing command line option -no-user-cfg
type: feature request
versions: Python 2.5
Added file: http://bugs.python.org/file18069/dist.py.patch

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

From report at bugs.python.org  Tue Jul 20 00:54:43 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 19 Jul 2010 22:54:43 +0000
Subject: [New-bugs-announce] [issue9310] Intermittent failures in
	test_logging
In-Reply-To: <1279580083.41.0.887395400152.issue9310@psf.upfronthosting.co.za>
Message-ID: <1279580083.41.0.887395400152.issue9310@psf.upfronthosting.co.za>


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

Seemingly random failures in test_logging on 2.6/ubuntu-wide. See:


http://www.python.org/dev/buildbot/builders/AMD64 Ubuntu wide 2.6/builds/777 [fail]
http://www.python.org/dev/buildbot/builders/AMD64 Ubuntu wide 2.6/builds/778 [ok]


======================================================================
ERROR: test_config0_ok (test.test_logging.ConfigFileTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/cpython-ucs4-nonascii-???/2.6.pitrou-ubuntu-wide/build/Lib/test/test_logging.py", line 646, in test_config0_ok
    self.apply_config(self.config0)
  File "/home/buildbot/cpython-ucs4-nonascii-???/2.6.pitrou-ubuntu-wide/build/Lib/test/test_logging.py", line 639, in apply_config
    logging.config.fileConfig(fn)
  File "/home/buildbot/cpython-ucs4-nonascii-???/2.6.pitrou-ubuntu-wide/build/Lib/logging/config.py", line 85, in fileConfig
    _install_loggers(cp, handlers, disable_existing_loggers)
  File "/home/buildbot/cpython-ucs4-nonascii-???/2.6.pitrou-ubuntu-wide/build/Lib/logging/config.py", line 217, in _install_loggers
    existing.sort()
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 37: ordinal not in range(128)

----------
components: Tests
keywords: buildbot
messages: 110829
nosy: skrah
priority: normal
severity: normal
status: open
title: Intermittent failures in test_logging
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Jul 20 04:02:37 2010
From: report at bugs.python.org (Garrett Cooper)
Date: Tue, 20 Jul 2010 02:02:37 +0000
Subject: [New-bugs-announce] [issue9311] os.access can return bogus values
	when run as superuser
In-Reply-To: <1279591357.64.0.139129514793.issue9311@psf.upfronthosting.co.za>
Message-ID: <1279591357.64.0.139129514793.issue9311@psf.upfronthosting.co.za>


New submission from Garrett Cooper <yanegomi at gmail.com>:

As seen in the nose bug [1], I stumbled upon an OS quirk with FreeBSD, where apparently (as superuser) due to the wording of the POSIX spec for access(2), it's considered free game to return 0 for the system call (True) for os.[RWX]_OK.

Only python was affected by this on the system I was using (both perl and sh did the right thing in detecting the executable bit(s) on the file).

An example should be provided to do the right thing with the stat module, and developers should be warned against using os.access because (as the patch and test log demonstrate), stat(2) does the right thing when access(2) does not as superuser...

Here's an example of the code I used to detect the executable bit:

import os
import stat

s = os.stat(afile)

executable = (s.st_mode & stat.S_IXUSR | stat.S_IXGRP | stat.S_IXOTH) == 0

[1] http://code.google.com/p/python-nose/issues/detail?id=351
[2] http://www.opengroup.org/onlinepubs/000095399/functions/access.html

----------
components: Library (Lib)
messages: 110850
nosy: yaneurabeya
priority: normal
severity: normal
status: open
title: os.access can return bogus values when run as superuser
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Jul 20 06:19:47 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 20 Jul 2010 04:19:47 +0000
Subject: [New-bugs-announce] [issue9312] Fix usage of :option: markup in
	stdlib ReST docs
In-Reply-To: <1279599587.56.0.337150515932.issue9312@psf.upfronthosting.co.za>
Message-ID: <1279599587.56.0.337150515932.issue9312@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

Due to a discussion on python-dev (Subject: "Markup of command-line options in Python's .rst documentation"), Georg Brandl checked in revision r82961 with a clarification of :option: markup which should only be used for Python interpreter's own flags.

However, several modules in stdlib use :option: for their own command-line options, which creates confusion (these options get linked by Sphinx to unrelated Python options).

I'm attaching a patch that fixes this issue for these files. The affected files are:

Doc/library/idle.rst
Doc/library/timeit.rst
Doc/library/test.rst
Doc/library/doctest.rst
Doc/library/unittest.rst
Doc/library/pydoc.rst
Doc/library/webbrowser.rst
Doc/library/compileall.rst

Note1: :option: was fixed to `` markup (code snippet) as per the recommendation in the updated documentation guide
Note2: I didn't patch trace.rst because it's overgoing a major rehaul (http://bugs.python.org/issue9264)

----------
assignee: docs at python
components: Documentation
messages: 110862
nosy: docs at python, eli.bendersky
priority: normal
severity: normal
status: open
title: Fix usage of :option: markup in stdlib ReST docs
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Jul 20 13:07:22 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 20 Jul 2010 11:07:22 +0000
Subject: [New-bugs-announce] [issue9313] distutils error on MSVC older than 8
In-Reply-To: <1279624042.03.0.724891043691.issue9313@psf.upfronthosting.co.za>
Message-ID: <1279624042.03.0.724891043691.issue9313@psf.upfronthosting.co.za>


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

I got an error while testing py3k on VC6. Here is a patch.

======================================================================
ERROR: test_remove_visual_c_ref (distutils.tests.test_msvc9compiler.msvc9compile
rTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\distutils\tests\test_msvc9compiler.py", line 112,
 in test_remove_visual_c_ref
    from distutils.msvc9compiler import MSVCCompiler
  File "e:\python-dev\py3k\lib\distutils\msvc9compiler.py", line 291, in <module
>
    raise DistutilsPlatformError("VC %0.1f is not supported by this module" % VE
RSION)
distutils.errors.DistutilsPlatformError: VC 6.0 is not supported by this module

----------------------------------------------------------------------
Ran 170 tests in 49.070s

FAILED (errors=1, skipped=4)
Traceback (most recent call last):
  File "test_distutils.py", line 18, in <module>
    test_main()
  File "test_distutils.py", line 13, in test_main
    test.support.run_unittest(distutils.tests.test_suite())
  File "e:\python-dev\py3k\lib\test\support.py", line 1054, in run_unittest
    _run_suite(suite)
  File "e:\python-dev\py3k\lib\test\support.py", line 1037, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\distutils\tests\test_msvc9compiler.py", line 112,
 in test_remove_visual_c_ref
    from distutils.msvc9compiler import MSVCCompiler
  File "e:\python-dev\py3k\lib\distutils\msvc9compiler.py", line 291, in <module
>
    raise DistutilsPlatformError("VC %0.1f is not supported by this module" % VE
RSION)
distutils.errors.DistutilsPlatformError: VC 6.0 is not supported by this module

----------
assignee: tarek
components: Distutils, Tests
files: py3k_distutils_on_old_msvc.patch
keywords: patch
messages: 110886
nosy: ocean-city, tarek
priority: normal
severity: normal
status: open
title: distutils error on MSVC older than 8
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file18088/py3k_distutils_on_old_msvc.patch

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

From report at bugs.python.org  Tue Jul 20 13:28:41 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Tue, 20 Jul 2010 11:28:41 +0000
Subject: [New-bugs-announce] [issue9314] inconsistent result when
	concatenating list with iterators
In-Reply-To: <1279625321.9.0.516167517772.issue9314@psf.upfronthosting.co.za>
Message-ID: <1279625321.9.0.516167517772.issue9314@psf.upfronthosting.co.za>


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

This seems wrong:

>>> a = []
>>> b = iter(['c', 'd'])
>>> a += b
>>> c = []
>>> c + iter(['d', 'e'])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can only concatenate list (not "listiterator") to list

In other words, if iadd can deal with it, why can't add?

----------
components: Interpreter Core
messages: 110887
nosy: djc
priority: normal
severity: normal
status: open
title: inconsistent result when concatenating list with iterators
versions: Python 2.6

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

From report at bugs.python.org  Tue Jul 20 19:44:51 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 20 Jul 2010 17:44:51 +0000
Subject: [New-bugs-announce] [issue9315] The trace module lacks unit tests
In-Reply-To: <1279647891.9.0.117287880523.issue9315@psf.upfronthosting.co.za>
Message-ID: <1279647891.9.0.117287880523.issue9315@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

Brought up in issue 9282: unit tests should be added for the trace module.

Minor naming problem: Lib/test/test_trace.py is currently employed for testing the sys.settrace method.

Suggestion: name the unit tests of the trace module test_trace_module.py

----------
components: Library (Lib)
messages: 110932
nosy: eli.bendersky
priority: normal
severity: normal
status: open
title: The trace module lacks unit tests
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Jul 21 02:42:47 2010
From: report at bugs.python.org (Ryan Kelly)
Date: Wed, 21 Jul 2010 00:42:47 +0000
Subject: [New-bugs-announce] [issue9316] typos in zipimport docstrings
In-Reply-To: <1279672967.55.0.52374479726.issue9316@psf.upfronthosting.co.za>
Message-ID: <1279672967.55.0.52374479726.issue9316@psf.upfronthosting.co.za>


New submission from Ryan Kelly <ryan at rfk.id.au>:

zipimporter methods is_package, get_code and get_source have in the their docstring "Raise ZipImportError is the module couldn't be found".

The attached patch fixes the typo to "if the module couldn't be found".

----------
files: zipimport_docstring_typo.patch
keywords: patch
messages: 110983
nosy: rfk
priority: normal
severity: normal
status: open
title: typos in zipimport docstrings
Added file: http://bugs.python.org/file18095/zipimport_docstring_typo.patch

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

From report at bugs.python.org  Wed Jul 21 03:54:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 21 Jul 2010 01:54:25 +0000
Subject: [New-bugs-announce] [issue9317] Incorrect coverage file from trace
	test_pickle.py
In-Reply-To: <1279677265.36.0.322549269298.issue9317@psf.upfronthosting.co.za>
Message-ID: <1279677265.36.0.322549269298.issue9317@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

I am running the following command

$ python -m trace -C pickle-trace.d -c -m Lib/test/test_pickle.py

and getting attached file, pickle.cover, in the pickle-trace.d directory.  This does not look right.  From the very beginning, module level statements are marked as not executed:


>>>>>> __version__ = "$Revision: 82937 $"       # Code version
       
>>>>>> from types import FunctionType, BuiltinFunctionType
>>>>>> from copyreg import dispatch_table
>>>>>> from copyreg import _extension_registry, _inverted_registry, _extension_cache
>>>>>> import marshal
>>>>>> import sys

The method I was interested in, _instantiate, shows as if it was never executed even though if I add a failing assert, I do see test failure.

I suspect that this may have something to do with the import trickery that test_pickle does to test with and without _pickle.

----------
components: Library (Lib)
files: pickle.cover
messages: 110990
nosy: belopolsky
priority: normal
severity: normal
stage: unit test needed
status: open
title: Incorrect coverage file from trace test_pickle.py
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file18096/pickle.cover

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

From report at bugs.python.org  Wed Jul 21 07:49:07 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 21 Jul 2010 05:49:07 +0000
Subject: [New-bugs-announce] [issue9318] Py3k compilation on old MSVC
In-Reply-To: <1279691347.62.0.710756316078.issue9318@psf.upfronthosting.co.za>
Message-ID: <1279691347.62.0.710756316078.issue9318@psf.upfronthosting.co.za>


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

Hello. Attached patch is needed to compile on MSVC6. I'm appriciated
if this patch is accepted.

----------
components: Build
files: py3k_compile_on_old_compiler.patch
keywords: patch
messages: 111007
nosy: ocean-city
priority: normal
severity: normal
stage: patch review
status: open
title: Py3k compilation on old MSVC
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file18100/py3k_compile_on_old_compiler.patch

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

From report at bugs.python.org  Wed Jul 21 08:29:25 2010
From: report at bugs.python.org (Ron Adam)
Date: Wed, 21 Jul 2010 06:29:25 +0000
Subject: [New-bugs-announce] [issue9319] segfault when searching modules
	with help()
In-Reply-To: <1279693765.46.0.777254335316.issue9319@psf.upfronthosting.co.za>
Message-ID: <1279693765.46.0.777254335316.issue9319@psf.upfronthosting.co.za>


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

help('modules spam') causes segfault.

When pydoc tries goes though the files it does the following in the ModuleScanner class.

(minimal example)

>>> for importer, modname, ispkg in pkgutil.walk_packages():
...     if modname == 'test.badsyntax_pep3120':
...         loader = importer.find_module(modname)
... 
Segmentation fault

Adding:

   if modname=='test.badsyntax_pep3120':
      continue

At the top of the for loop will suppress the segfault in pydoc by skipping that file.


A bit further probing narrowed it down to this...

>>> loader = pkgutil.get_loader('test.badsyntax_pep3120')
Segmentation fault

I'm not familiar with the pkgutil module so I didn't go further.

----------
components: Library (Lib)
messages: 111009
nosy: ron_adam
priority: normal
severity: normal
status: open
title: segfault when searching modules with help()
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Wed Jul 21 09:07:26 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 21 Jul 2010 07:07:26 +0000
Subject: [New-bugs-announce] [issue9320] os.environ is global for threads
In-Reply-To: <1279696046.14.0.777932115359.issue9320@psf.upfronthosting.co.za>
Message-ID: <1279696046.14.0.777932115359.issue9320@psf.upfronthosting.co.za>


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

Seems like os.environ is shared between multiple threads. This should be documented at least in threading chapters.

----------
assignee: docs at python
components: Documentation
messages: 111013
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: os.environ is global for threads
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/issue9320>
_______________________________________

From report at bugs.python.org  Wed Jul 21 10:38:02 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 21 Jul 2010 08:38:02 +0000
Subject: [New-bugs-announce] [issue9321] CGIHTTPServer cleanup htbin
In-Reply-To: <1279701482.44.0.871660375803.issue9321@psf.upfronthosting.co.za>
Message-ID: <1279701482.44.0.871660375803.issue9321@psf.upfronthosting.co.za>


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

CGIHTTPServer looks for CGI files in '/htbin' directory. This never was a standard (in comparison to `cgi-bin`) and can be safely removed at least in Py3k

----------
components: Library (Lib)
messages: 111020
nosy: techtonik
priority: normal
severity: normal
status: open
title: CGIHTTPServer cleanup htbin
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/issue9321>
_______________________________________

From report at bugs.python.org  Wed Jul 21 16:05:30 2010
From: report at bugs.python.org (Dan OD)
Date: Wed, 21 Jul 2010 14:05:30 +0000
Subject: [New-bugs-announce] [issue9322] bdist_rpm ext_modules absolute
	source path fail
In-Reply-To: <1279721130.09.0.919872519995.issue9322@psf.upfronthosting.co.za>
Message-ID: <1279721130.09.0.919872519995.issue9322@psf.upfronthosting.co.za>


New submission from Dan OD <djo35 at cam.ac.uk>:

Setting absolute paths for C source code files in setup.py breaks bdist_rpm

ext_modules=[Extension('foo', [os.path.abspath('src/foo.c')])],

results in bdist_rpm not including src/foo.c in the RPM, however

ext_modules=[Extension('foo', ['src/foo.c'])],

works just fine.

----------
assignee: tarek
components: Distutils
messages: 111058
nosy: indiedan, tarek
priority: normal
severity: normal
status: open
title: bdist_rpm ext_modules absolute source path fail
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Jul 21 16:30:32 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 21 Jul 2010 14:30:32 +0000
Subject: [New-bugs-announce] [issue9323] trace.py bug with the main file
	being traced
In-Reply-To: <1279722632.82.0.584454979643.issue9323@psf.upfronthosting.co.za>
Message-ID: <1279722632.82.0.584454979643.issue9323@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

[This bug was discovered by Alexander Belopolsky, during the work on Issue 9317]

Bug report
**********

The attached traceme.py file demonstrates the following problem:

With python 2.7:
$ python2 -m trace  -c -s traceme.py
lines   cov%   module   (path)
    1   100%   threading   (Lib/threading.py)
    6   100%   traceme   (traceme.py)

The first entry is clearly spurious, but traceme looks right.  With py3k, however, I get

$ python3 -m trace  -c -s traceme.py
lines   cov%   module   (path)
    1   100%   threading   (Lib/threading.py)

No traceme line at all.

Analysis
********

When trace.py actually runs the script, it uses this code in 3.x:

           t.run('exec(%r)' % (script,))

instead of this code in 2.x:

            t.run('execfile(%r)' % (progname,))

`exec` doesn't have the program name to attach to the code object created, and calls it '<string>' by default. However, this file name is ignored by the trace module.

`execfile` doesn't exist in 3.x, so an alternative approach is needed.

Proposed solution
*****************

Instead of t.run as displayed above, use this code:

            with open(progname) as fp:
                code = compile(fp.read(), progname, 'exec')
                t.run(code)

The code object created by `compile` attaches the program name and is executable by t.run (because t.run actually calls `exec` which can run the result of `compile`).

This solution fixes the problem:

$ py3d -m trace -c -s traceme.py 
lines   cov%   module   (path)
    1   100%   threading   (/home/eliben/python_src/eliben-py3k/Lib/threading.py)
    6   100%   traceme   (traceme.py)

I'll attach a patch file that was creates vs. the latest trunk, with this fix.

----------
files: traceme.py
messages: 111066
nosy: eli.bendersky
priority: normal
severity: normal
status: open
title: trace.py bug with the main file being traced
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file18105/traceme.py

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

From report at bugs.python.org  Wed Jul 21 20:50:56 2010
From: report at bugs.python.org (Dave Fugate)
Date: Wed, 21 Jul 2010 18:50:56 +0000
Subject: [New-bugs-announce] [issue9324] signal.signal(bogus_signal,
	handler) segfaults on Windows
In-Reply-To: <1279738256.92.0.653078709511.issue9324@psf.upfronthosting.co.za>
Message-ID: <1279738256.92.0.653078709511.issue9324@psf.upfronthosting.co.za>


New submission from Dave Fugate <dfugate at microsoft.com>:

Using Python 2.7 (r27:82525, Jul 4 2010, 09:01:59; 32-bit Intel) on 64-bit Windows Server 2008 R2, python.exe (interactive sessions and files) crashes when it encounters the following snippet:
>>> import signal
>>> signal.signal(7, lambda a, b: None)

Note that Python doesn't crash if I substitute '7' with a valid Windows signal (e.g., '2').  Also, it seems that at least some invalid signal inputs (e.g., '0') generate the appropriate Python exception.

----------
files: cpy_crash.jpg
messages: 111104
nosy: midnightdf
priority: normal
severity: normal
status: open
title: signal.signal(bogus_signal, handler) segfaults on Windows
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file18109/cpy_crash.jpg

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

From report at bugs.python.org  Wed Jul 21 22:25:02 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 21 Jul 2010 20:25:02 +0000
Subject: [New-bugs-announce] [issue9325] Add an option to pdb/trace/profile
	to run library module	as a script
In-Reply-To: <1279743902.96.0.66207849175.issue9325@psf.upfronthosting.co.za>
Message-ID: <1279743902.96.0.66207849175.issue9325@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

The -m interpreter option allows one to run library module as a script, but if you want to debug, profile or trace the execution of the same, you must supply the path to the module source file on the command line.  The resulting execution may also be different from python -m run especially when the module is located within a package.

I would like to be able to do

$ python -m trace <trace options> --run-module <module name>

and the same with pdb and profile in place of trace.

----------
assignee: belopolsky
components: Library (Lib)
messages: 111111
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: Add an option to pdb/trace/profile to run library module as a script
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Wed Jul 21 22:44:07 2010
From: report at bugs.python.org (Dave Fugate)
Date: Wed, 21 Jul 2010 20:44:07 +0000
Subject: [New-bugs-announce] [issue9326] Error message for incorrect number
	of (function) args is	incorrect
In-Reply-To: <1279745047.45.0.24813200138.issue9326@psf.upfronthosting.co.za>
Message-ID: <1279745047.45.0.24813200138.issue9326@psf.upfronthosting.co.za>


New submission from Dave Fugate <dfugate at microsoft.com>:

The error message below should state something along the lines of "f() takes at least 1 non-keyword argument (0 given)".  Regardless, this is a regression from 2.6 which would have emitted "f() takes at least 1 argument (0 given)" which while not perfect, is a more accurate description of the problem:


D:\rft\vsl\dlr\Languages\IronPython\Tests>27
Python 2.7 (r27:82525, Jul  4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> def f(a, b=2): pass
...
>>> f(b=2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() takes at least 1 argument (1 given)
>>>

----------
messages: 111116
nosy: midnightdf
priority: normal
severity: normal
status: open
title: Error message for incorrect number of (function) args is incorrect
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Jul 22 00:08:36 2010
From: report at bugs.python.org (Patrick Strawderman)
Date: Wed, 21 Jul 2010 22:08:36 +0000
Subject: [New-bugs-announce] [issue9327] doctest DocFileCase setUp/tearDown
	asymmetry
In-Reply-To: <1279750116.68.0.946227736764.issue9327@psf.upfronthosting.co.za>
Message-ID: <1279750116.68.0.946227736764.issue9327@psf.upfronthosting.co.za>


New submission from Patrick Strawderman <patrick at zope.com>:

doctest.DocFileTest inserts the test's path into the globs as "__file__",
but doctest.DocTestCase's tearDown method simply calls globs.clear(),
so that subsequent runs of the test case will not receive the same
initial globals.

This means that doctests referencing __file__ cannot be run repeatedly
without using a custom setUp that restores __file__.

I think most would expect symmetry between setUp and tearDown, and in
fact zope.testrunner operates with this false assumption when run
with the "-N" option to repeat a test N times.

----------
components: Library (Lib)
messages: 111127
nosy: boogenhagn, fdrake
priority: normal
severity: normal
status: open
title: doctest DocFileCase setUp/tearDown asymmetry
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/issue9327>
_______________________________________

From report at bugs.python.org  Thu Jul 22 00:49:15 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 21 Jul 2010 22:49:15 +0000
Subject: [New-bugs-announce] [issue9328] str.__format__.__doc__ backport
	glitch
In-Reply-To: <1279752555.95.0.938195163481.issue9328@psf.upfronthosting.co.za>
Message-ID: <1279752555.95.0.938195163481.issue9328@psf.upfronthosting.co.za>


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

On Python list, 'jmfauth' reports
>>> >>> sys.version
2.7 (r27:82525, Jul  4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)]
>>> >>> ''.format.__doc__
S.format(*args, **kwargs) -> unicode

I do not have 2.7 loaded to verify this, but assuming this is accurate,
'unicode' should be 'string'. I presume this is from mistaken conversion of 3.1 'string' to 2.7 'unicode' when backporting the new string format system.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 111130
nosy: docs at python, tjreedy
priority: normal
severity: normal
stage: needs patch
status: open
title: str.__format__.__doc__ backport glitch
versions: Python 2.7

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

From report at bugs.python.org  Thu Jul 22 18:20:56 2010
From: report at bugs.python.org (Sam Saint-Pettersen)
Date: Thu, 22 Jul 2010 16:20:56 +0000
Subject: [New-bugs-announce] [issue9329] freeze tool cannot handle JSON
	module properly
In-Reply-To: <1279815656.66.0.596140100357.issue9329@psf.upfronthosting.co.za>
Message-ID: <1279815656.66.0.596140100357.issue9329@psf.upfronthosting.co.za>


New submission from Sam Saint-Pettersen <s.stpettersen at gmail.com>:

Freeze tool can generate Makefile and C code for Python programs using the JSON module. The code can be compiled fine, but when a program using the JSON module is run, this is returned:

Traceback (most recent call last): 
2	  File "myProgram.py", line 15, in <module> 
3	    import json 
4	  File "/usr/local/lib/python2.7/json/__init__.py", line 108, in <module> 
5	    from .decoder import JSONDecoder 
6	  File "/usr/local/lib/python2.7/json/decoder.py", line 24, in <module> 
7	    NaN, PosInf, NegInf = _floatconstants() 
8	  File "/usr/local/lib/python2.7/json/decoder.py", line 18, in _floatconstants 
9	    _BYTES = '7FF80000000000007FF0000000000000'.decode('hex') 
10	LookupError: unknown encoding: hex 

Something to do with .decode('hex') apparently.

----------
components: Demos and Tools
messages: 111188
nosy: sam.sp
priority: normal
severity: normal
status: open
title: freeze tool cannot handle JSON module properly
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Jul 22 19:11:20 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 22 Jul 2010 17:11:20 +0000
Subject: [New-bugs-announce] [issue9330] assertIn should check for
	membership support before	testing
In-Reply-To: <1279818680.38.0.509759364598.issue9330@psf.upfronthosting.co.za>
Message-ID: <1279818680.38.0.509759364598.issue9330@psf.upfronthosting.co.za>


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

A recent sysconfig test which should have been skipped on Windows (now fixed) exposed a bug in the assertIn/assertNotIn methods. If the "container" you are testing doesn't support membership testing or iteration, such as None value when a previous call fails, the test is then an error rather than a fail.

Before:
======================================================================
ERROR: test_ldshared_value (test.test_sysconfig.TestSysConfig)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\python-dev\py3k\lib\test\test_sysconfig.py", line 285, in test_ldshar
ed_value
    self.assertIn(ldflags, ldshared)
  File "c:\python-dev\py3k\lib\unittest\case.py", line 797, in assertIn
    if member not in container:
TypeError: argument of type 'NoneType' is not iterable


I believe this should be a fail with AssertionError, rather than an error with TypeError.

======================================================================
FAIL: test_ldshared_value (test.test_sysconfig.TestSysConfig)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\python-dev\py3k\lib\test\test_sysconfig.py", line 285, in test_ldshar
ed_value
    self.assertIn(ldflags, ldshared)
AssertionError: None does not support the `in` operator



The patch adds a check that __contains__, __iter__, or __getitem__ exist on the object and fails the test if none of those are found. It also includes a few test updates.

----------
assignee: michael.foord
components: Library (Lib)
files: membership_check.diff
keywords: needs review, patch, patch
messages: 111193
nosy: brian.curtin, michael.foord
priority: normal
severity: normal
stage: patch review
status: open
title: assertIn should check for membership support before testing
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file18126/membership_check.diff

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

From report at bugs.python.org  Thu Jul 22 19:43:37 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 22 Jul 2010 17:43:37 +0000
Subject: [New-bugs-announce] [issue9331] sys.setprofile is not described as
	CPython implementation	detail
In-Reply-To: <1279820617.97.0.227411152808.issue9331@psf.upfronthosting.co.za>
Message-ID: <1279820617.97.0.227411152808.issue9331@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Unlike sys.settrace, sys.setprofile is not described as CPython implementation detail in Doc/library/sys.rst.

----------
assignee: docs at python
components: Documentation
messages: 111199
nosy: belopolsky, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: sys.setprofile is not described as CPython implementation detail
type: feature request

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

From report at bugs.python.org  Thu Jul 22 20:45:39 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 22 Jul 2010 18:45:39 +0000
Subject: [New-bugs-announce] [issue9332] Document requirements for
	os.symlink usage on Windows
In-Reply-To: <1279824339.14.0.912688887592.issue9332@psf.upfronthosting.co.za>
Message-ID: <1279824339.14.0.912688887592.issue9332@psf.upfronthosting.co.za>


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

#1578269 introduced os.symlink support for Windows 6.0, but it requires the SeCreateSymbolicLinkPrivilege privilege to be enabled for the calling user, which is not always the case. Documentation needs to be added on the specific details here, possibly including a method to request privilege escalation.

----------
assignee: brian.curtin
components: Documentation
messages: 111207
nosy: brian.curtin, jaraco
priority: normal
severity: normal
stage: needs patch
status: open
title: Document requirements for os.symlink usage on Windows
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Jul 22 21:58:24 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 22 Jul 2010 19:58:24 +0000
Subject: [New-bugs-announce] [issue9333] Expose a way to enable os.symlink
	on Windows
In-Reply-To: <1279828704.23.0.310372952456.issue9333@psf.upfronthosting.co.za>
Message-ID: <1279828704.23.0.310372952456.issue9333@psf.upfronthosting.co.za>


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

As it currently stands, the possibility exists that some users might not have the SeCreateSymbolicLinkPrivilege privilege enabled (depending on security settings, corporate policy, etc). There should be some method of enabling that privilege outside of the way we do it in the tests (using ctypes).

Attached is a quick prototype...no docs or tests yet. If you don't have the privilege enabled, "os.enable_symlink()" will attempt to enable it for you (True if successful, False if not).


For the security conscious: "The AdjustTokenPrivileges function cannot add new privileges to the access token. It can only enable or disable the token's existing privileges"

----------
assignee: brian.curtin
components: Extension Modules
files: enable_symlink.diff
keywords: patch
messages: 111213
nosy: brian.curtin, eric.smith, jaraco
priority: normal
severity: normal
status: open
title: Expose a way to enable os.symlink on Windows
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file18132/enable_symlink.diff

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

From report at bugs.python.org  Fri Jul 23 00:15:39 2010
From: report at bugs.python.org (Anders Kaseorg)
Date: Thu, 22 Jul 2010 22:15:39 +0000
Subject: [New-bugs-announce] [issue9334] argparse does not accept options
	taking arguments	beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>


New submission from Anders Kaseorg <andersk at mit.edu>:

Porting the a2x program to argparse from the now-deprecated optparse subtly breaks it when certain options are passed:

$ a2x --asciidoc-opts --safe gitcli.txt
$ ./a2x.argparse --asciidoc-opts --safe gitcli.txt
usage: a2x [-h] [--version] [-a ATTRIBUTE] [--asciidoc-opts ASCIIDOC_OPTS]
           [--copy] [--conf-file CONF_FILE] [-D PATH] [-d DOCTYPE]
           [--epubcheck] [-f FORMAT] [--icons] [--icons-dir PATH] [-k]
           [--lynx] [-L] [-n] [-r PATH] [-s] [--stylesheet STYLESHEET]
           [--safe] [--dblatex-opts DBLATEX_OPTS] [--fop]
           [--fop-opts FOP_OPTS] [--xsltproc-opts XSLTPROC_OPTS] [-v]
a2x: error: argument --asciidoc-opts: expected one argument

Apparently argparse uses a heuristic to try to guess whether an argument looks like an argument or an option, going so far as to check whether it looks like a negative number (!).  It should _never_ guess: the option was specified to take an argument, so the following argument should always be parsed as an argument.

Small test case:

>>> import optparse
>>> parser = optparse.OptionParser(prog='a2x')
>>> parser.add_option('--asciidoc-opts',
...     action='store', dest='asciidoc_opts', default='',
...     metavar='ASCIIDOC_OPTS', help='asciidoc options')
>>> parser.parse_args(['--asciidoc-opts', '--safe'])
(<Values at 0x7f585142ef80: {'asciidoc_opts': '--safe'}>, [])

>>> import argparse
>>> parser = argparse.ArgumentParser(prog='a2x')
>>> parser.add_argument('--asciidoc-opts',
...     action='store', dest='asciidoc_opts', default='',
...     metavar='ASCIIDOC_OPTS', help='asciidoc options')
>>> parser.parse_args(['--asciidoc-opts', '--safe'])
usage: a2x [-h] [--asciidoc-opts ASCIIDOC_OPTS]
a2x: error: argument --asciidoc-opts: expected one argument

----------
components: Library (Lib)
messages: 111221
nosy: andersk
priority: normal
severity: normal
status: open
title: argparse does not accept options taking arguments beginning with dash (regression from optparse)
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul 23 04:38:31 2010
From: report at bugs.python.org (Anthony Long)
Date: Fri, 23 Jul 2010 02:38:31 +0000
Subject: [New-bugs-announce] [issue9335] LC_CTYPE system setting not
	respected by setlocale()
In-Reply-To: <1279852711.38.0.0249345603825.issue9335@psf.upfronthosting.co.za>
Message-ID: <1279852711.38.0.0249345603825.issue9335@psf.upfronthosting.co.za>


New submission from Anthony Long <antlong at gmail.com>:

On mac 10.5, python 2.6.4 (via mac ports) performing

len(string.letters) will produce 117 instead of 52.

from terminal:
along-mb:~ along$ locale
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL=

This appears to be related to:

locale.setlocale(locale.LC_CTYPE) not being respected.

len(string.letters) should produce 52.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 111233
nosy: antlong, ronaldoussoren
priority: normal
severity: normal
status: open
title: LC_CTYPE system setting not respected by setlocale()
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Fri Jul 23 05:27:53 2010
From: report at bugs.python.org (Anthony Long)
Date: Fri, 23 Jul 2010 03:27:53 +0000
Subject: [New-bugs-announce] [issue9336] string.letters should display
	locale based equivalent of	a-Z
In-Reply-To: <1279855673.74.0.0304173911229.issue9336@psf.upfronthosting.co.za>
Message-ID: <1279855673.74.0.0304173911229.issue9336@psf.upfronthosting.co.za>


New submission from Anthony Long <antlong at gmail.com>:

string.letters should display the locale based equivalent of a-Z.

In enUS this would be a-z A-Z, in total a len of 52, whereas in spain it would be a-z (with  ?), and A-Z (?).

Each locale should change the returned letters.

http://en.wikipedia.org/wiki/Keyboard_layout

----------
components: Library (Lib)
messages: 111238
nosy: antlong
priority: normal
severity: normal
status: open
title: string.letters should display locale based equivalent of a-Z
versions: Python 2.5, Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri Jul 23 12:31:00 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 23 Jul 2010 10:31:00 +0000
Subject: [New-bugs-announce] [issue9337] Make float.__str__ behave
	identically to float.__repr__
In-Reply-To: <1279881060.45.0.501412515152.issue9337@psf.upfronthosting.co.za>
Message-ID: <1279881060.45.0.501412515152.issue9337@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Proposal:  make the str of a float (or complex number) identical to the repr of a float (or complex number), in Python 3.2.  This idea came up a couple of times at EuroPython, and generally met with approval.

An open question: what should be done on platforms that don't support the short float repr?  In practice, I don't think this matters too much:  it's difficult to find such platforms.  The simplest thing to do would be to make __str__ identical to __repr__ on all platforms.

This change *will* inevitably break code;  the question is whether this level of breakage is acceptable for 3.1 -> 3.2.

I'll also bring this up on the python-dev mailing list.

----------
assignee: mark.dickinson
components: Interpreter Core
messages: 111268
nosy: eric.smith, mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: Make float.__str__ behave identically to float.__repr__
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Fri Jul 23 12:46:29 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 23 Jul 2010 10:46:29 +0000
Subject: [New-bugs-announce] [issue9338] argparse optionals with nargs='+'
	can't be followed by	positionals
In-Reply-To: <1279881989.28.0.725806934086.issue9338@psf.upfronthosting.co.za>
Message-ID: <1279881989.28.0.725806934086.issue9338@psf.upfronthosting.co.za>


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

[From the old argparse tracker: http://code.google.com/p/argparse/issues/detail?id=20]

You can't follow a nargs='+' optional argument with a positional argument:

>>> import argparse
>>> parser = argparse.ArgumentParser(prog='PROG')
>>> parser.add_argument('--badger', nargs='+')
>>> parser.add_argument('spam')
>>> parser.parse_args('--badger A B C D'.split())
usage: PROG [-h] [--badger BADGER [BADGER ...]] spam
PROG: error: too few arguments

Ideally, this should produce:

>>> parser.parse_args('--badger A B C D'.split())
Namespace(badger=['A', 'B', 'C'], spam='D')

The problem is that the nargs='+' causes the optional to consume all the arguments following it, even though we should know that we need to save one for the final positional argument.

A workaround is to specify '--', e.g.:

>>> parser.parse_args('--badger A B C -- D'.split())
Namespace(badger=['A', 'B', 'C'], spam='D')

The problem arises from the fact that argparse uses regular-expression style matching for positional arguments, but it does that separately from what it does for optional arguments.

One solution might be to build a regular expression of the possible things a parser could match. So given a parser like::

  parser = argparse.ArgumentParser()
  parser.add_argument('-w')
  parser.add_argument('-x', nargs='+')
  parser.add_argument('y')
  parser.add_argument('z', nargs='*')

the regular expression might look something like (where positionals have been replaced by the character A)::

  (-w A)? (-x A+)? A (-w A)? (-x A+)? A* (-w A)? (-x A+)?

Note that the optionals can appear between any positionals, so I have to repeat their regular expressions multiple times. Because of this, I worry about how big the regular expression might grow to be for large parsers. But maybe this is the right way to solve the problem.

----------
messages: 111270
nosy: bethard
priority: normal
severity: normal
stage: needs patch
status: open
title: argparse optionals with nargs='+' can't be followed by positionals
type: feature request

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

From report at bugs.python.org  Fri Jul 23 13:19:29 2010
From: report at bugs.python.org (Brian Brazil)
Date: Fri, 23 Jul 2010 11:19:29 +0000
Subject: [New-bugs-announce] [issue9339] threading is_alive documnetation is
	unclear
In-Reply-To: <1279883969.69.0.278185543155.issue9339@psf.upfronthosting.co.za>
Message-ID: <1279883969.69.0.278185543155.issue9339@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

http://docs.python.org/py3k/library/threading.html

"Roughly, a thread is alive from the moment the start() method returns until its run() method terminates."

Using "Roughly" in relation to threading is a bit unspecific. I've had a look through _bootstrap_inner() and attached a patch to clarify this.

----------
assignee: docs at python
components: Documentation
files: threading-roughly-doc-fix.patch
keywords: patch
messages: 111278
nosy: bbrazil, docs at python
priority: normal
severity: normal
status: open
title: threading is_alive documnetation is unclear
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/file18140/threading-roughly-doc-fix.patch

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

From report at bugs.python.org  Fri Jul 23 14:00:05 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 23 Jul 2010 12:00:05 +0000
Subject: [New-bugs-announce] [issue9340] argparse parse_known_args does not
	work with subparsers
In-Reply-To: <1279886405.92.0.918578525345.issue9340@psf.upfronthosting.co.za>
Message-ID: <1279886405.92.0.918578525345.issue9340@psf.upfronthosting.co.za>


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

[Moved from http://code.google.com/p/argparse/issues/detail?id=45]

If you try to use parse_known_args and you have a subparser, the subparser will still complain if it sees extra arguments:

>>> parser = argparse.ArgumentParser()
>>> subparsers = parser.add_subparsers()
>>> subparsers.add_parser('A')
>>> parser.parse_known_args(['A', '--foo', 'b'])
usage:  A [-h]
 A: error: unrecognized arguments: --foo b

What should be returned is probably:

>>> parser.parse_known_args(['A', '--foo', 'b'])
(Namespace(), ['--foo', 'b'])

The problem is that subparsers don't know whether they're being called by parse_args() or parse_known_args(). I see a few possible fixes:

* Add another argument to Action.__call__ that indicates what method is being called. But that would break any existing subclasses.

* Do some stack inspection using sys._getframe(). But that's not guaranteed to work on other implementations of Python.

* When parse_args is called, set some flag on the subparsers object that causes it to call parse_known_args instead, and restore that flag before parse_known_args returns. This probably introduces potential threading issues, though practically perhaps they'll never turn up.

----------
assignee: bethard
components: Library (Lib)
messages: 111285
nosy: bethard
priority: normal
severity: normal
stage: needs patch
status: open
title: argparse parse_known_args does not work with subparsers
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul 23 14:17:31 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 23 Jul 2010 12:17:31 +0000
Subject: [New-bugs-announce] [issue9341] allow argparse subcommands to be
	grouped
In-Reply-To: <1279887451.34.0.723880615782.issue9341@psf.upfronthosting.co.za>
Message-ID: <1279887451.34.0.723880615782.issue9341@psf.upfronthosting.co.za>


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

[Moved from http://code.google.com/p/argparse/issues/detail?id=53]

It's currently not possible to have subcommands formatted in groups, e.g. instead of:

subcommands:
  {a,b,c,d,e}
    a          a subcommand help
    b          b subcommand help
    c          c subcommand help
    d          d subcommand help
    e          e subcommand help 

you should be able to get something like:

subcommands:
  group1:
    a          a subcommand help
    b          b subcommand help
    c          c subcommand help
  group2:
    d          d subcommand help
    e          e subcommand help

----------
components: Library (Lib)
messages: 111290
nosy: bethard
priority: normal
severity: normal
stage: needs patch
status: open
title: allow argparse subcommands to be grouped
type: feature request

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

From report at bugs.python.org  Fri Jul 23 14:20:09 2010
From: report at bugs.python.org (John Chandler)
Date: Fri, 23 Jul 2010 12:20:09 +0000
Subject: [New-bugs-announce] [issue9342] Tests for monthrange in calendar.py
	module
In-Reply-To: <1279887609.81.0.197947140036.issue9342@psf.upfronthosting.co.za>
Message-ID: <1279887609.81.0.197947140036.issue9342@psf.upfronthosting.co.za>


New submission from John Chandler <therealmetaljoe at gmail.com>:

Hi,

Attaching a patch for the test_calendar.py file.

Adds six tests to provide test coverage of the monthrange function.


John

----------
components: Tests
files: test_calendar.patch
keywords: patch
messages: 111292
nosy: John.Chandler
priority: normal
severity: normal
status: open
title: Tests for monthrange in calendar.py module
versions: Python 3.2
Added file: http://bugs.python.org/file18144/test_calendar.patch

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

From report at bugs.python.org  Fri Jul 23 14:57:27 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 23 Jul 2010 12:57:27 +0000
Subject: [New-bugs-announce] [issue9343] Document that argparse "parents"
	must be fully declared	before children
In-Reply-To: <1279889847.13.0.579699796707.issue9343@psf.upfronthosting.co.za>
Message-ID: <1279889847.13.0.579699796707.issue9343@psf.upfronthosting.co.za>


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

[From http://code.google.com/p/argparse/issues/detail?id=61]

It should be documented clearly that only the arguments present on the parent parser at the time ArgumentParser is called will be included in the parser.

>>> parent = argparse.ArgumentParser(add_help=False)
>>> child = argparse.ArgumentParser(parents=[parent])
>>> parent.add_argument('--foo', action='store_true')
>>> child.parse_args(['--foo'])
usage: [-h]
: error: unrecognized arguments: --foo

----------
assignee: docs at python
components: Documentation
messages: 111306
nosy: bethard, docs at python
priority: normal
severity: normal
status: open
title: Document that argparse "parents" must be fully declared before children
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul 23 15:10:57 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 23 Jul 2010 13:10:57 +0000
Subject: [New-bugs-announce] [issue9344] please add posix.getgrouplist()
In-Reply-To: <1279890657.77.0.804697326433.issue9344@psf.upfronthosting.co.za>
Message-ID: <1279890657.77.0.804697326433.issue9344@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

A number of unix systems expose a getgroupslist function to fetch the groups that a user is a member of. It would be nice if that function were exposed to python.

See issue7900 for more information on why that would be useful.

----------
keywords: easy
messages: 111309
nosy: ronaldoussoren
priority: low
severity: normal
status: open
title: please add posix.getgrouplist()
versions: Python 3.2

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

From report at bugs.python.org  Fri Jul 23 15:14:53 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 23 Jul 2010 13:14:53 +0000
Subject: [New-bugs-announce] [issue9345] argparse wrap tests are sensitive
	to terminal size
In-Reply-To: <1279890893.09.0.0931064949941.issue9345@psf.upfronthosting.co.za>
Message-ID: <1279890893.09.0.0931064949941.issue9345@psf.upfronthosting.co.za>


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

[From http://code.google.com/p/argparse/issues/detail?id=63]

What steps will reproduce the problem?
1. PYTHONPATH=. python test/test_argparse.py
2. do the above in an 80x24 terminal window and it passes
3. do the same in an 80 wide emacs shell buffer and you get lots of failures

To make sure this doesn't continue to be a problem, we probably need to do something like os.environ['COLUMNS'] = 80 and check output like that.

----------
components: Tests
messages: 111311
nosy: bethard
priority: normal
severity: normal
stage: needs patch
status: open
title: argparse wrap tests are sensitive to terminal size
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Jul 23 15:24:00 2010
From: report at bugs.python.org (Brian Brazil)
Date: Fri, 23 Jul 2010 13:24:00 +0000
Subject: [New-bugs-announce] [issue9346] Improve threading tests
In-Reply-To: <1279891440.96.0.298342013248.issue9346@psf.upfronthosting.co.za>
Message-ID: <1279891440.96.0.298342013248.issue9346@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

The attached patch:
Remove unused "self-test" from threading.py that doesn't really test much.

Add better testing for Thread.__repr__.

This brings coverage as measured by regrtest from 40% to 45%.

----------
components: Interpreter Core
files: threading_test_cleanup.patch
keywords: patch
messages: 111313
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Improve threading tests
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file18145/threading_test_cleanup.patch

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

From report at bugs.python.org  Fri Jul 23 15:27:50 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 23 Jul 2010 13:27:50 +0000
Subject: [New-bugs-announce] [issue9347] Calling argparse add_argument with
	a sequence as 'type'	causes spurious error message
In-Reply-To: <1279891670.23.0.306869867423.issue9347@psf.upfronthosting.co.za>
Message-ID: <1279891670.23.0.306869867423.issue9347@psf.upfronthosting.co.za>


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

What steps will reproduce the problem?

parser = argparse.ArgumentParser()
parser.add_argument('--foo', type=(int, float))

What is the expected output?

ValueError: (<type 'int'>, <type 'float'>) is not callable

What do you see instead?

TypeError: not all arguments converted during string formatting

Please provide any additional information below.

This is caused by calling using the % string formatting operator without
proper wrapping of the argument. The fix is basically:

-            raise ValueError('%r is not callable' % type_func)
+            raise ValueError('%r is not callable' % (type_func,))

----------
components: Library (Lib)
messages: 111316
nosy: bethard
priority: low
severity: normal
stage: needs patch
status: open
title: Calling argparse add_argument with a sequence as 'type' causes spurious error message
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Jul 23 15:34:16 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 23 Jul 2010 13:34:16 +0000
Subject: [New-bugs-announce] [issue9348] Calling argparse's add_argument
	with the wrong number of	metavars causes delayed error message
In-Reply-To: <1279892056.3.0.745674136702.issue9348@psf.upfronthosting.co.za>
Message-ID: <1279892056.3.0.745674136702.issue9348@psf.upfronthosting.co.za>


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

What steps will reproduce the problem?

parser = argparse.ArgumentParser()	
parser.add_argument('--foo', nargs=2, metavar=('X','Y','Z'))
parser.parse_args(['-h'])

The error dosn't show up until help is formatted.

Giving any incorrect length of metavar will produce the problem, which
includes a tuple whos length doesn't match a numerical value, more than two metavars to '*' or '+', and more than one metavar to '?'. Furthermore, a tuple of length one causes the error when nargs is greater than 1, '*', or '+'.

What is the expected output? What do you see instead?

When the help is displayed, you get:

TypeError: not all arguments converted during string formatting

Or a similar error message for other cases.

It would be expected that the error message would be more specific. The
error should definitely be raised when add_argument is called, rather than later.

There should be a test that does something like:

    for meta in ('X', ('X',), ('X','Y'), ('X','Y','Z')):
        for n in (1, 2, 3, '?', '+', '*'):
            parser = argparse.ArgumentParser()
            parser.add_argument('--foo', nargs=n, metavar=meta)
            parser.format_help()

and makes sure that the error shows up in add_argument, not format_help.

----------
components: Library (Lib)
messages: 111317
nosy: bethard
priority: normal
severity: normal
stage: needs patch
status: open
title: Calling argparse's add_argument with the wrong number of metavars causes delayed error message
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Jul 23 15:46:36 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 23 Jul 2010 13:46:36 +0000
Subject: [New-bugs-announce] [issue9349] document argparse's help=SUPPRESS
In-Reply-To: <1279892796.46.0.177553560445.issue9349@psf.upfronthosting.co.za>
Message-ID: <1279892796.46.0.177553560445.issue9349@psf.upfronthosting.co.za>


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

Argparse supports silencing help for certain options using SUPPRESS.

>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('--foo', help=argparse.SUPPRESS)
>>> parser.print_help()
usage: [-h]

optional arguments:
  -h, --help  show this help message and exit

This should be documented in the description of help=

http://docs.python.org/library/argparse.html#help

----------
assignee: docs at python
components: Documentation
messages: 111320
nosy: bethard, docs at python
priority: normal
severity: normal
status: open
title: document argparse's help=SUPPRESS
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Jul 23 15:51:28 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 23 Jul 2010 13:51:28 +0000
Subject: [New-bugs-announce] [issue9350] add remove_argument_group to
	argparse
In-Reply-To: <1279893088.18.0.675631346333.issue9350@psf.upfronthosting.co.za>
Message-ID: <1279893088.18.0.675631346333.issue9350@psf.upfronthosting.co.za>


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

[From http://code.google.com/p/argparse/issues/detail?id=71]

There is a method ArgumentParser.add_argument_group() to create and add an argument group to the parser.  I would like the ability to remove an argument group via a method like remove_argument_group(group).

The use case for me is I create an argument group and then conditionally add a bunch of arguments to it.  If zero arguments are added I would like to then remove the group so that an empty group does not show up in the help output.

----------
components: Library (Lib)
messages: 111321
nosy: bethard
priority: normal
severity: normal
stage: needs patch
status: open
title: add remove_argument_group to argparse
type: feature request

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

From report at bugs.python.org  Fri Jul 23 16:06:52 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 23 Jul 2010 14:06:52 +0000
Subject: [New-bugs-announce] [issue9351] argparse set_defaults on
	subcommands should override top	level set_defaults
In-Reply-To: <1279894012.43.0.0678646409.issue9351@psf.upfronthosting.co.za>
Message-ID: <1279894012.43.0.0678646409.issue9351@psf.upfronthosting.co.za>


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

If you use set_defaults on a subparser, but a default exists on the top level parser, the subparser defaults are ignored:

>>> parser = argparse.ArgumentParser()
>>> xparser = parser.add_subparsers().add_parser('X')
>>> parser.set_defaults(foo=1)
>>> xparser.set_defaults(foo=2)
>>> parser.parse_args(['X'])
Namespace(foo=1)

This is counter to what people probably expect, that the subparser, when selected, would override the top level parser.

The behavior is because of the following code in parse_known_args:

        for dest in self._defaults:
            if not hasattr(namespace, dest):
                setattr(namespace, dest, self._defaults[dest])

This happens before the subparser sees the namespace object, and so the subparser sees that no defaults need to be filled in.

----------
components: Library (Lib)
messages: 111324
nosy: bethard
priority: normal
severity: normal
stage: needs patch
status: open
title: argparse set_defaults on subcommands should override top level set_defaults
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Jul 23 16:18:24 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 23 Jul 2010 14:18:24 +0000
Subject: [New-bugs-announce] [issue9352] argparse eats characters when
	parsing multiple merged	short options
In-Reply-To: <1279894704.35.0.264649777176.issue9352@psf.upfronthosting.co.za>
Message-ID: <1279894704.35.0.264649777176.issue9352@psf.upfronthosting.co.za>


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

[Moved from http://code.google.com/p/argparse/issues/detail?id=73]

What steps will reproduce the problem?
parser = ArgumentParser(prefix_chars="-+")
parser.add_argument("-a",action="store_true")
parser.add_argument("+b",action="store_true")
parser.add_argument("+c",action="store_true")
print parser.parse_args("-abc".split())

What is the expected output? What do you see instead?
I would expect Namespace(a=True, b=True, c=True)
You get Namespace(a=True, b=False, c=True)

because in the loop that iterates through the prefix characters it builds an option_string to try by pulling the first character off explicit_arg. If it doesn't match any option then it will try the next prefix character, but it will have lost that character from the explicit_arg. This is also a problem even with only one prefix character because if it doesn't match an option the error message will be missing that one character.

The above match -a, tried -b and fails, but instead of trying +b, it tries +c because the b has been lost.

I've included multiple_short.patch which fixes just this bug. However, I also don't agree with the behavior of trying all prefix characters. I would expect that when merging short options together they would have to all share the same prefix character. If I have prefix_chars="-+" and I have options -a, +a, -b, and +b and I type +ab I would expect my action to be called with option_strings +a and +b, not +a and -b. The patch to fix the above bug *and* only try the same prefix character as the first option is multiple_short_same_prefix.patch.

[Only the latter patch (which sounds like the right behavior) is attached. It will need to be updated to work against Python trunk.]

----------
components: Library (Lib)
files: multiple_short_same_prefix.patch
keywords: patch
messages: 111328
nosy: bethard
priority: normal
severity: normal
stage: needs patch
status: open
title: argparse eats characters when parsing multiple merged short options
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file18147/multiple_short_same_prefix.patch

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

From report at bugs.python.org  Fri Jul 23 16:25:11 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 23 Jul 2010 14:25:11 +0000
Subject: [New-bugs-announce] [issue9353] argparse __all__ is incomplete
In-Reply-To: <1279895111.13.0.483513856318.issue9353@psf.upfronthosting.co.za>
Message-ID: <1279895111.13.0.483513856318.issue9353@psf.upfronthosting.co.za>


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

[Moved from http://code.google.com/p/argparse/issues/detail?id=75]

What steps will reproduce the problem?
1. import argparse
2. print dir(argparse)
3. print argparse.__all__

Compare the output for public methods and attributes from #2 that aren't in #3.

I see the following entries that look like they should be public but aren't in __all__::

'ArgumentTypeError', 'ONE_OR_MORE', 'OPTIONAL', 'PARSER', 'REMAINDER',  'SUPPRESS', 'ZERO_OR_MORE'

I was writing a compat layer to allow unbundling argparse from ipython if it's already installed in the system when I ran across this.  The particular public attribute that was missing there was 'SUPPRESS'

----------
components: Library (Lib)
messages: 111331
nosy: bethard
priority: normal
severity: normal
stage: needs patch
status: open
title: argparse __all__ is incomplete
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Jul 23 16:33:28 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 23 Jul 2010 14:33:28 +0000
Subject: [New-bugs-announce] [issue9354] fire_wrapper fails to provide
	getsockopt()
In-Reply-To: <1279895608.81.0.80539572871.issue9354@psf.upfronthosting.co.za>
Message-ID: <1279895608.81.0.80539572871.issue9354@psf.upfronthosting.co.za>


New submission from ?ukasz Langa <lukasz at langa.pl>:

Tested on Python 3.2a0 on Mac OS 10.6.4.

When you specify the most basic `file_dispatcher` and run the loop, `file_wrapper` fails because it doesn't provide the `getsockopt()` to fake being a socket.

The code
--------

import asyncore
import os

class FileDispatcher(asyncore.file_dispatcher):
    def handle_read(self):
        data = self.recv(8192)

fd = os.open('/etc/passwd', os.O_RDONLY)
s = FileDispatcher(fd)
os.close(fd)
asyncore.loop(timeout=0.01, use_poll=True, count=2)

Expected result
---------------
None, it should run OK silently.

Actual result
-------------
error: uncaptured python exception, closing channel <__main__.FileDispatcher at 0x100524e10> (<class 'AttributeError'>:'file_wrapper' object has no attribute 'getsockopt' [/opt/error-report/py3k/Lib/asyncore.py|readwrite|106] [/opt/error-report/py3k/Lib/asyncore.py|handle_write_event|449])
Traceback (most recent call last):
  File "/opt/error-report/py3k/Lib/asyncore.py", line 106, in readwrite
    obj.handle_write_event()
  File "/opt/error-report/py3k/Lib/asyncore.py", line 449, in handle_write_event
    err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR)
AttributeError: 'file_wrapper' object has no attribute 'getsockopt'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/error-report/error_report.py", line 11, in <module>
    asyncore.loop(timeout=0.01, use_poll=True, count=2)
  File "/opt/error-report/py3k/Lib/asyncore.py", line 214, in loop
    poll_fun(timeout, map)
  File "/opt/error-report/py3k/Lib/asyncore.py", line 195, in poll2
    readwrite(obj, flags)
  File "/opt/error-report/py3k/Lib/asyncore.py", line 119, in readwrite
    obj.handle_error()
  File "/opt/error-report/py3k/Lib/asyncore.py", line 489, in handle_error
    self.handle_close()
  File "/opt/error-report/py3k/Lib/asyncore.py", line 508, in handle_close
    self.close()
  File "/opt/error-report/py3k/Lib/asyncore.py", line 396, in close
    self.socket.close()
  File "/opt/error-report/py3k/Lib/asyncore.py", line 617, in close
    os.close(self.fd)
OSError: [Errno 9] Bad file descriptor

Patch
-----
Please find attached a patch that does add a unit test for this specific case and adds the most simple `getsockopt()` possible that is still reasonable. The patch was made with trunk r83090.

----------
components: Library (Lib)
messages: 111333
nosy: ambv, giampaolo.rodola, josiahcarlson
priority: normal
severity: normal
status: open
title: fire_wrapper fails to provide getsockopt()
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Jul 23 16:35:28 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 23 Jul 2010 14:35:28 +0000
Subject: [New-bugs-announce] [issue9355] argparse
	add_mutually_exclusive_group more than once has	incorrectly
	formatted help
In-Reply-To: <1279895728.08.0.860550350605.issue9355@psf.upfronthosting.co.za>
Message-ID: <1279895728.08.0.860550350605.issue9355@psf.upfronthosting.co.za>


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

[Moved from http://code.google.com/p/argparse/issues/detail?id=78]

What steps will reproduce the problem?
1. Create two mutually exclusive groups: eg

agroup = subcmd_parser.add_mutually_exclusive_group()
agroup.add_argument('--a1', action='store_true', help='blah')
agroup.add_argument('--a2', action='store_true', help='blah')
agroup.add_argument('--a3', action='store_true', help='blah')

bgroup = subcmd_parser.add_mutually_exclusive_group()
bgroup.add_argument('--b1', action='store_true', help='blah')
bgroup.add_argument('--b2', action='store_true', help='blah')
bgroup.add_argument('--b3', action='store_true', help='blah')

What is the expected output? What do you see instead?

Expected output (on running a help command which formats help) is:
[ --a1 | --a2 | --a3 ] [ --b1 | --b2 | --b3 ]

You see instead:
[ --a1 | --a2 | --a3 [ --b1 | --b2 | --b3 ]

Note that the closing brace for the first group is missing.

----------
components: Library (Lib)
messages: 111335
nosy: bethard
priority: normal
severity: normal
stage: needs patch
status: open
title: argparse add_mutually_exclusive_group more than once has incorrectly formatted help
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Jul 23 16:55:44 2010
From: report at bugs.python.org (Brian Brazil)
Date: Fri, 23 Jul 2010 14:55:44 +0000
Subject: [New-bugs-announce] [issue9356] Improved tests and style for fnmatch
In-Reply-To: <1279896944.36.0.615358088153.issue9356@psf.upfronthosting.co.za>
Message-ID: <1279896944.36.0.615358088153.issue9356@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

The attached path adds tests for translate and filter, and also fixes a few style issues in fnmatch itself.

----------
components: Interpreter Core
files: fnmatch_test_and_cleanup.patch
keywords: patch
messages: 111340
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Improved tests and style for fnmatch
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file18150/fnmatch_test_and_cleanup.patch

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

From report at bugs.python.org  Fri Jul 23 18:12:25 2010
From: report at bugs.python.org (Brian Brazil)
Date: Fri, 23 Jul 2010 16:12:25 +0000
Subject: [New-bugs-announce] [issue9357] Improve queue tests
In-Reply-To: <1279901545.74.0.17670937551.issue9357@psf.upfronthosting.co.za>
Message-ID: <1279901545.74.0.17670937551.issue9357@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

The attached patch improves the code coverage of queue to 98% by testing empty, full, put_nowait, get_nowait and some error conditions.

----------
components: Library (Lib)
files: test_queue.patch
keywords: patch
messages: 111354
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Improve queue tests
versions: Python 3.2
Added file: http://bugs.python.org/file18154/test_queue.patch

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

From report at bugs.python.org  Fri Jul 23 18:25:28 2010
From: report at bugs.python.org (Brian Brazil)
Date: Fri, 23 Jul 2010 16:25:28 +0000
Subject: [New-bugs-announce] [issue9358] Document fnmatch.translate's lack
	of support for escaping
In-Reply-To: <1279902328.19.0.409453550243.issue9358@psf.upfronthosting.co.za>
Message-ID: <1279902328.19.0.409453550243.issue9358@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

fnmatch.translate's docstraing says "There is no way to quote meta-characters.", but this isn't in the html docs. The attached patch fixes that.

----------
assignee: docs at python
components: Documentation
files: fnmatch_translate_doc.patch
keywords: patch
messages: 111358
nosy: bbrazil, docs at python
priority: normal
severity: normal
status: open
title: Document fnmatch.translate's lack of support for escaping
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file18156/fnmatch_translate_doc.patch

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

From report at bugs.python.org  Fri Jul 23 18:34:14 2010
From: report at bugs.python.org (Piotr Kasprzyk)
Date: Fri, 23 Jul 2010 16:34:14 +0000
Subject: [New-bugs-announce] [issue9359] Misspelled exception
In-Reply-To: <1279902854.94.0.37527153601.issue9359@psf.upfronthosting.co.za>
Message-ID: <1279902854.94.0.37527153601.issue9359@psf.upfronthosting.co.za>


New submission from Piotr Kasprzyk <ciri at ciri.pl>:

Misspelled: exception

----------
components: IDLE
files: misspelled_exception.diff
keywords: patch
messages: 111359
nosy: kwadrat
priority: normal
severity: normal
status: open
title: Misspelled exception
versions: Python 3.2
Added file: http://bugs.python.org/file18157/misspelled_exception.diff

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

From report at bugs.python.org  Fri Jul 23 18:54:17 2010
From: report at bugs.python.org (Dmitry Jemerov)
Date: Fri, 23 Jul 2010 16:54:17 +0000
Subject: [New-bugs-announce] [issue9360] nntplib cleanup
In-Reply-To: <1279904057.7.0.917806545674.issue9360@psf.upfronthosting.co.za>
Message-ID: <1279904057.7.0.917806545674.issue9360@psf.upfronthosting.co.za>


New submission from Dmitry Jemerov <intelliyole at gmail.com>:

The patch performs an extensive cleanup of nntplib:
 - Change API methods to return strings instead of bytes. This breaks API compatibility, but given that the parameters need to be passed as strings and many of the returned values would need to be passed to other API methods, I consider the current API to be broken. I've discussed this with Brett at the EuroPython sprint, and he agrees.
 - Add tests.
 - Add pending deprecation warnings for xgtitle() and xpath() methods, which are not useful in modern environments.
 - Use named tuples for returned values where appopriate.
 - Modernize the implementation a little bit.
 - Clean up the docstrings.

----------
components: Library (Lib)
files: nntplib_cleanup.patch
keywords: patch
messages: 111364
nosy: Dmitry.Jemerov
priority: normal
severity: normal
status: open
title: nntplib cleanup
versions: Python 3.2
Added file: http://bugs.python.org/file18159/nntplib_cleanup.patch

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

From report at bugs.python.org  Fri Jul 23 20:58:42 2010
From: report at bugs.python.org (John Chandler)
Date: Fri, 23 Jul 2010 18:58:42 +0000
Subject: [New-bugs-announce] [issue9361] Tests for leapdays in calendar.py
	module
In-Reply-To: <1279911522.69.0.474631084692.issue9361@psf.upfronthosting.co.za>
Message-ID: <1279911522.69.0.474631084692.issue9361@psf.upfronthosting.co.za>


New submission from John Chandler <therealmetaljoe at gmail.com>:

Hi,

Attaching a patch for the test_calendar.py file.

Adds four tests to provide coverage of the leapdays() function.


John

----------
components: Tests
files: test_calendar.diff
keywords: patch
messages: 111373
nosy: John.Chandler
priority: normal
severity: normal
status: open
title: Tests for leapdays in calendar.py module
versions: Python 3.2
Added file: http://bugs.python.org/file18161/test_calendar.diff

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

From report at bugs.python.org  Fri Jul 23 21:24:02 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 23 Jul 2010 19:24:02 +0000
Subject: [New-bugs-announce] [issue9362] Make exit/quit hint more novice
	friendly
In-Reply-To: <1279913042.97.0.618415832845.issue9362@psf.upfronthosting.co.za>
Message-ID: <1279913042.97.0.618415832845.issue9362@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

This bikeshed have been repainted several times already, but here is a true story.

Cast:

Me = myself
Novice = a 14-year-old boy
Laptop = a MacBook Air

Novice: How do i exit [from python prompt]?
Me: What's your best guess?
Novice: [typing] exit [pressing Enter]
Laptop: Use exit() or Ctrl-D (i.e. EOF) to exit
Novice: [typing] Ctrl...
Me: OMG, you don't know what Ctrl-D means?  Look for the Ctrl key.
Novice: There is no such key.
    --- curtains ---

I suggest changing

Use exit() or Ctrl-D (i.e. EOF) to exit

 to 

Type exit() or quit() and press the Enter key to exit

  or

Type exit() or quit() and press Enter to exit

 or just

Use exit() to exit

My theory is that someone who knows what EOF is, will probably already know how to exit from common terminal oriented programs and Ctrl-D is not universally bound to EOF.

TOOWTDI: two ways to exit is more than enough to teach a novice.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 111374
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: Make exit/quit hint more novice friendly
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Sat Jul 24 01:01:26 2010
From: report at bugs.python.org (rioch)
Date: Fri, 23 Jul 2010 23:01:26 +0000
Subject: [New-bugs-announce] [issue9363] data_files are not installed
	relative to sys.prefix
In-Reply-To: <1279926086.74.0.751307014326.issue9363@psf.upfronthosting.co.za>
Message-ID: <1279926086.74.0.751307014326.issue9363@psf.upfronthosting.co.za>


New submission from rioch <jon_black at mm.st>:

In the disutils documentation for data_files, it states:

"If directory is a relative path, it is interpreted relative to the installation prefix (Python?s sys.prefix for pure-Python packages, sys.exec_prefix  for packages that contain extension modules)."

However, on my system, sys.prefix outputs as '/usr' but the files are installed to '/usr/local'.

OS: Linux Mint 9
Python: 2.6.5

----------
assignee: tarek
components: Distutils
messages: 111396
nosy: rioch, tarek
priority: normal
severity: normal
status: open
title: data_files are not installed relative to sys.prefix
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Jul 24 07:23:47 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 24 Jul 2010 05:23:47 +0000
Subject: [New-bugs-announce] [issue9364] some problems with the
	documentation of pydoc
In-Reply-To: <1279949027.26.0.1869842795.issue9364@psf.upfronthosting.co.za>
Message-ID: <1279949027.26.0.1869842795.issue9364@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

The first paragraph in its documentation says:

"""
In the Python interpreter, do "from pydoc import help" to provide online
help.  Calling help(thing) on a Python object documents the object.
"""

Which is no longer accurate, because the help() function has long ago become a built-in.

Below is an excerpt from Terry Reedy in a private email discussion on this subject, that raises more issues.

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

1. The output from help(help) could be made more clear.

The nature of 'help' has been a point of confusion. A recent python-list post asked something like "What is 'help'?"

Now (with some parallel examples:

>>> help(int)
Help on class int in module builtins:

class int(object)
[snip]

>>> help(1)
Help on int object:

class int(object)
[snip]

>>> help(help)
Help on _Helper in module site object:

class _Helper(builtins.object)
 |  Define the built-in 'help'.
 |  This is a wrapper around pydoc.help (with a twist).
 |
 |  Methods defined here:
 |
 |  __call__(self, *args, **kwds)
 |

a. 'module site object' is nonsense, it should just be 'module site', except that to be parallel to what is done for other instances, it should be 'Help on _Helper object'. Why should help special-case itself (with a slightly garbled line?) Is that done in site._Helper or pydoc.help?

However, it would be more helpful for all instances to give the location of the class when one asks for help on an instance, just as when one asks for help on the class itself. It is annoying to to have to repeat help(<classname>) just to get that info. So I would like to see
"Help on instance of class int in module builtins:"
"Help on instance of class _Helper in module site:"

This would be a code patch to pydoc.help

b. "This is a wrapper around pydoc.help" good so far
"(with a twist)" thanks a lot. I think the comment should be either removed or explained. A reference manual should explain, not tease.

Replace "Define the built-in 'help'." with something clearer and more accurate, such as "The name 'help' is injected in module builtins after being bound to an instance of this class.". Put this after, not before, the 'wrapper' line.

A patch for site._Helper doc string.


2. Improve manual chapter for site module.

a. It currently starts "Importing this module will append site-specific paths to the module search path." Add "inject 'help' into builtins and " after append. Then add a short explanation paragraph before the search path stuff. Something like

"This module contains a class (_Helper) that wraps function pydoc.help. An instance of the class is bound to name 'help' in the builtins module."

A recent discussion on pydev or maybe python-list (in the thread mentioned above?) implied that one could usefully make another instance of _Helper or maybe a subclass thereof. I did not pay enough attention, though, to really get it.

b. It currently ends with "XXX Update documentation XXX document python -m site ?user-base ?user-site"

----------
assignee: docs at python
components: Documentation
messages: 111426
nosy: docs at python, eli.bendersky, tjreedy
priority: normal
severity: normal
status: open
title: some problems with the documentation of pydoc
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Jul 24 07:46:05 2010
From: report at bugs.python.org (Anthony Long)
Date: Sat, 24 Jul 2010 05:46:05 +0000
Subject: [New-bugs-announce] [issue9365] Installing a distro without sqlite3
	will require a	reinstall of python to function if installed
	at a later date
In-Reply-To: <1279950365.76.0.579184415242.issue9365@psf.upfronthosting.co.za>
Message-ID: <1279950365.76.0.579184415242.issue9365@psf.upfronthosting.co.za>


New submission from Anthony Long <antlong at gmail.com>:

install a distro of without sqlite3 support. now you should have a /usr/lib/python2.6/sqlite3, which obviously isn't usable.

now if you install sqlite3, and try a 'import sqlite3' it still doesn't work. so you have to compile/install python2.6 again. after which it works fine.


http://www.linuxfromscratch.org/blfs/view/svn/general/python.html

----------
components: Library (Lib)
messages: 111428
nosy: antlong
priority: normal
severity: normal
status: open
title: Installing a distro without sqlite3 will require a reinstall of python to function if installed at a later date
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Jul 24 11:46:41 2010
From: report at bugs.python.org (Kay Hayen)
Date: Sat, 24 Jul 2010 09:46:41 +0000
Subject: [New-bugs-announce] [issue9366] Reference leak for local new style
	class
In-Reply-To: <1279964801.22.0.925376306196.issue9366@psf.upfronthosting.co.za>
Message-ID: <1279964801.22.0.925376306196.issue9366@psf.upfronthosting.co.za>


New submission from Kay Hayen <kayhayen at gmx.de>:

Hello,

I have created tests that check the reference counting and found that the following simple function leaks references in CPython:

def simpleFunction39():
   class Parent( object ):
      pass

I have attached a test that needs to be run with python-dbg and checks the total reference count for many language constructs. Sometimes a warmup can be useful, if CPython caches something, but it doesn't help in this case. Removing object or replacing it with an old style class helps.

I think I saw that 3 references of object leak, and a total of ca. 20 for each call to the function. I suspect a memory leak too.

Use the attached file for reproduction of the problem.

----------
components: Interpreter Core
files: Referencing.py
messages: 111433
nosy: kayhayen
priority: normal
severity: normal
status: open
title: Reference leak for local new style class
type: resource usage
versions: Python 2.6
Added file: http://bugs.python.org/file18173/Referencing.py

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

From report at bugs.python.org  Sat Jul 24 11:52:04 2010
From: report at bugs.python.org (Darren Worrall)
Date: Sat, 24 Jul 2010 09:52:04 +0000
Subject: [New-bugs-announce] [issue9367] test_getgroups in test_posix fails
In-Reply-To: <1279965124.79.0.0313564801642.issue9367@psf.upfronthosting.co.za>
Message-ID: <1279965124.79.0.0313564801642.issue9367@psf.upfronthosting.co.za>


New submission from Darren Worrall <dw at darrenworrall.co.uk>:

In my checkout of py3k (r83123), test_getgroups in test_posix fails - the right elements are returned but the ordering is different:

$ ./python -m test.regrtest test_posix
test_posix
test test_posix failed -- Traceback (most recent call last):
  File "/home/daz/src/py3k/Lib/test/test_posix.py", line 360, in test_getgroups
    self.assertEqual([int(x) for x in groups.split()], posix.getgroups())
AssertionError: Lists differ: [1000, 4, 6, 20, 24, 46, 105, ... != [4, 6, 20, 24, 46, 105, 119, 1...

First differing element 0:
1000
4

- [1000, 4, 6, 20, 24, 46, 105, 119, 122, 125, 126, 128]
+ [4, 6, 20, 24, 46, 105, 119, 122, 125, 126, 128, 1000]

1 test failed:
    test_posix

Platform is Ubuntu 10.04 x86_64, kernel is 2.6.32 - unfortunately my C sucks so I'm not sure what's going on.

----------
messages: 111434
nosy: DazWorrall
priority: normal
severity: normal
status: open
title: test_getgroups in test_posix fails

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

From report at bugs.python.org  Sat Jul 24 11:52:59 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Sat, 24 Jul 2010 09:52:59 +0000
Subject: [New-bugs-announce] [issue9368] Const-Correctness for Method Calls
In-Reply-To: <1279965179.09.0.525264342338.issue9368@psf.upfronthosting.co.za>
Message-ID: <1279965179.09.0.525264342338.issue9368@psf.upfronthosting.co.za>


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

The following patch changes some parts of the public C API for const correctness which would help C++ programmers.

The original patch was provided by neXyon on irc.freenode.net.

It does not produce any compiler warnings on GCC and I don't expect any compiler warnings on other systems either.

----------
components: None
files: const.patch
keywords: patch
messages: 111435
nosy: aronacher
priority: normal
severity: normal
stage: patch review
status: open
title: Const-Correctness for Method Calls
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file18174/const.patch

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

From report at bugs.python.org  Sat Jul 24 11:53:22 2010
From: report at bugs.python.org (=?utf-8?b?SsO2cmcgTcO8bGxlcg==?=)
Date: Sat, 24 Jul 2010 09:53:22 +0000
Subject: [New-bugs-announce] [issue9369] const char* for PyObject_CallMethod
	and	PyObject_CallFunction
In-Reply-To: <1279965202.04.0.507207277215.issue9369@psf.upfronthosting.co.za>
Message-ID: <1279965202.04.0.507207277215.issue9369@psf.upfronthosting.co.za>


New submission from J?rg M?ller <nexyon at gmail.com>:

Patch attached

----------
components: Interpreter Core
files: patch.diff
keywords: patch
messages: 111437
nosy: neXyon
priority: normal
severity: normal
status: open
title: const char* for PyObject_CallMethod and PyObject_CallFunction
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file18175/patch.diff

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

From report at bugs.python.org  Sat Jul 24 12:49:07 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 24 Jul 2010 10:49:07 +0000
Subject: [New-bugs-announce] [issue9370] Add reader redirect from test
	package docs to unittest	module
In-Reply-To: <1279968547.11.0.280770421062.issue9370@psf.upfronthosting.co.za>
Message-ID: <1279968547.11.0.280770421062.issue9370@psf.upfronthosting.co.za>


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

Brett updated the docs for the test package to (correctly) point out that it is our internal testing package and isn't subject to the same stringent backwards compatibility rules as the rest of the standard library.

A "see also" link pointing readers that have landed there over to the unittest module for their testing infrastructure needs would be a friendly thing to include.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 111450
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Add reader redirect from test package docs to unittest module
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Jul 24 15:01:52 2010
From: report at bugs.python.org (Mark Smith)
Date: Sat, 24 Jul 2010 13:01:52 +0000
Subject: [New-bugs-announce] [issue9371] pulldom doesn't provide
	END_DOCUMENT or COMMENT nodes.
In-Reply-To: <1279976512.14.0.00983593867016.issue9371@psf.upfronthosting.co.za>
Message-ID: <1279976512.14.0.00983593867016.issue9371@psf.upfronthosting.co.za>


New submission from Mark Smith <mark.smith at practicalpoetry.co.uk>:

I've been developing unit tests to increase the code coverage for pulldom, and have discovered that comments and end_document do not appear to result in events being obtained from the DOMEventStream.

I've attached a failing TestCase to demonstrate this.

----------
components: XML
files: test_pulldom.py
messages: 111474
nosy: mark.smith
priority: normal
severity: normal
status: open
title: pulldom doesn't provide END_DOCUMENT or COMMENT nodes.
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file18183/test_pulldom.py

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

From report at bugs.python.org  Sat Jul 24 15:04:53 2010
From: report at bugs.python.org (Mark Smith)
Date: Sat, 24 Jul 2010 13:04:53 +0000
Subject: [New-bugs-announce] [issue9372] pulldom.DOMEventStream.__getitem__
	is broken
In-Reply-To: <1279976693.98.0.219854761696.issue9372@psf.upfronthosting.co.za>
Message-ID: <1279976693.98.0.219854761696.issue9372@psf.upfronthosting.co.za>


New submission from Mark Smith <mark.smith at practicalpoetry.co.uk>:

DOMEventStream implements __getitem__, but ignores the index/key that is passed in and simply returns the next item from the stream. This is seriously unexpected behaviour.

I don't believe this functionality can be sensibly implemented in this class, and plan to submit a patch deprecating this method.

----------
components: XML
messages: 111475
nosy: mark.smith
priority: normal
severity: normal
status: open
title: pulldom.DOMEventStream.__getitem__ is broken
versions: Python 3.2

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

From report at bugs.python.org  Sat Jul 24 15:06:44 2010
From: report at bugs.python.org (Mark Smith)
Date: Sat, 24 Jul 2010 13:06:44 +0000
Subject: [New-bugs-announce] [issue9373] pulldom has low code coverage
In-Reply-To: <1279976804.16.0.216063093383.issue9373@psf.upfronthosting.co.za>
Message-ID: <1279976804.16.0.216063093383.issue9373@psf.upfronthosting.co.za>


New submission from Mark Smith <mark.smith at practicalpoetry.co.uk>:

pulldom has poor code coverage, so I am currently implementing thorough unit tests for it.

----------
components: XML
messages: 111476
nosy: mark.smith
priority: normal
severity: normal
status: open
title: pulldom has low code coverage
versions: Python 3.2

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

From report at bugs.python.org  Sun Jul 25 00:58:41 2010
From: report at bugs.python.org (Nick Welch)
Date: Sat, 24 Jul 2010 22:58:41 +0000
Subject: [New-bugs-announce] [issue9374] urlparse should parse query and
	fragment for arbitrary	schemes
In-Reply-To: <1280012321.31.0.791086727515.issue9374@psf.upfronthosting.co.za>
Message-ID: <1280012321.31.0.791086727515.issue9374@psf.upfronthosting.co.za>


New submission from Nick Welch <mackstann at gmail.com>:

While the netloc/path parts of URLs are scheme-specific, and urlparse can be forgiven for refusing to parse them for unknown schemes, the query and fragment parts are standardized, and should be parsed for unrecognized schemes.

According to Wikipedia:
------------------
Internet standard STD 66 (also RFC 3986) defines the generic syntax to be used in all URI schemes. Every URI is defined as consisting of four parts, as follows:
<scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]
------------------
http://en.wikipedia.org/wiki/URI_scheme#Generic_syntax


Here is a demonstration of what urlparse currently does:

>>> urlparse.urlsplit('myscheme://netloc/path?a=b#frag')
SplitResult(scheme='myscheme', netloc='', path='//netloc/path?a=b#frag', query='', fragment='')

>>> urlparse.urlsplit('http://netloc/path?a=b#frag')
SplitResult(scheme='http', netloc='netloc', path='/path', query='a=b', fragment='frag')

----------
components: Library (Lib)
messages: 111511
nosy: Nick.Welch
priority: normal
severity: normal
status: open
title: urlparse should parse query and fragment for arbitrary schemes
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Jul 25 09:32:09 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 25 Jul 2010 07:32:09 +0000
Subject: [New-bugs-announce] [issue9375] ElementPath parser in ElementTree
	1.3 does not reject	"element//" as invalid
In-Reply-To: <1280043129.76.0.83882182954.issue9375@psf.upfronthosting.co.za>
Message-ID: <1280043129.76.0.83882182954.issue9375@psf.upfronthosting.co.za>


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

Subject says it all:

Python 2.7 (r27:82500, Jul  5 2010, 13:37:06) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import xml.etree.ElementTree as ET
>>> el = ET.Element('hui')
>>> el.findall('section//')
[]

----------
components: Library (Lib), XML
messages: 111521
nosy: scoder
priority: normal
severity: normal
status: open
title: ElementPath parser in ElementTree 1.3 does not reject "element//" as invalid
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Jul 25 13:58:46 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 25 Jul 2010 11:58:46 +0000
Subject: [New-bugs-announce] [issue9376] Refer to gnuwin32 diff util on
	development FAQ
In-Reply-To: <1280059126.9.0.527330657398.issue9376@psf.upfronthosting.co.za>
Message-ID: <1280059126.9.0.527330657398.issue9376@psf.upfronthosting.co.za>


New submission from Mark Lawrence <breamoreboy at yahoo.co.uk>:

Section 6.1 How to make a patch? currently reads in part

(a Windows version is available as part of the cygwin tools).

I suggest that this is reworded to read

(Windows versions are available as part of the cygwin tools or as part of the gnuwin32 project)

I simply find it much easier to download and install these individual tools, e.g. I also have their version of grep which is vastly superior to Windows find

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 111536
nosy: BreamoreBoy, docs at python
priority: normal
severity: normal
status: open
title: Refer to gnuwin32 diff util on development FAQ
type: feature request

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

From report at bugs.python.org  Sun Jul 25 20:33:04 2010
From: report at bugs.python.org (David Watson)
Date: Sun, 25 Jul 2010 18:33:04 +0000
Subject: [New-bugs-announce] [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <1280082784.57.0.628810673592.issue9377@psf.upfronthosting.co.za>
Message-ID: <1280082784.57.0.628810673592.issue9377@psf.upfronthosting.co.za>


New submission from David Watson <baikie at users.sourceforge.net>:

The functions in the socket module which return host/domain
names, such as gethostbyaddr() and getnameinfo(), are wrappers
around byte-oriented interfaces but return Unicode strings in
3.x, and have not been updated to deal with undecodable byte
sequences in the results, as discussed in PEP 383.

Some DNS resolvers do discard hostnames not matching the
ASCII-only RFC 1123 syntax, but checks for this may be absent or
turned off, and non-ASCII bytes can be returned via other lookup
facilities such as /etc/hosts.

Currently, names are converted to str objects using
PyUnicode_FromString(), i.e. by attempting to decode them as
UTF-8.  This can fail with UnicodeError of course, but even if it
succeeds, any non-ASCII names returned will fail to round-trip
correctly because most socket functions encode string arguments
into IDNA ASCII-compatible form before using them.  For example,
with UTF-8 encoded entries

127.0.0.2       ?
127.0.0.3       xn--lzg

in /etc/hosts, I get:

Python 3.1.2 (r312:79147, Mar 23 2010, 19:02:21) 
[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> from socket import *
>>> getnameinfo(("127.0.0.2", 0), 0)
('?', '0')
>>> getaddrinfo(*_)
[(2, 1, 6, '', ('127.0.0.3', 0)), (2, 2, 17, '', ('127.0.0.3', 0)), (2, 3, 0, '', ('127.0.0.3', 0))]

Here, getaddrinfo() has encoded "?" to its corresponding ACE
label "xn--lzg", which maps to a different address.

PEP 383 can't be applied as-is here, since if the name happened
to be decodable in the file system encoding (and thus was
returned as valid non-ASCII Unicode), the result would fail to
round-trip correctly as shown above, but I think there is a
solution which follows the general idea of PEP 383.

Surrogate characters are not allowed in IDNs, since they are
prohibited by Nameprep[1][2], so if names were instead decoded as
ASCII with the surrogateescape error handler, strings
representing non-ASCII names would always contain surrogate
characters representing the non-ASCII bytes, and would therefore
fail to encode with the IDNA codec.  Thus there would be no
ambiguity between these strings and valid IDNs.  The attached
ascii-surrogateescape.diff does this.

The returned strings could then be made to round-trip as
arguments, by having functions that take hostname arguments
attempt to encode them using ASCII/surrogateescape first before
trying IDNA encoding.  Since IDNA leaves ASCII names unchanged
and surrogate characters are not allowed in IDNs, this would not
change the interpretation of any string hostnames that are
currently accepted.  It would remove the 63-octet limit on label
length currently imposed due to the IDNA encoding, for ASCII
names only, but since this is imposed due to the 63-octet limit
of the DNS, and non-IDN names may be intended for other
resolution mechanisms, I think this is a feature, not a bug :)

The patch try-surrogateescape-first.diff implements the above for
all relevant interfaces, including gethostbyaddr() and
getnameinfo(), which do currently accept hostnames, even if the
documentation is vague (in the standard library, socket.fqdn()
calls gethostbyaddr() with a hostname, and the "os" module docs
suggest calling socket.gethostbyaddr(socket.gethostname()) to get
the fully-qualified hostname).

The patch still allows hostnames to be passed as bytes objects,
but to simplify the implementation, it removes support for
bytearray (as has been done for pathnames in 3.2).  Bytearrays
are currently only accepted by the socket object methods
(.connect(), etc.), and this is undocumented and perhaps
unintentional - the get*() functions have never accepted them.

One problem with the surrogateescape scheme would be with
existing code that looks up an address and then tries to write
the hostname to a log file or use it as part of the wire
protocol, since the surrogate characters would fail to encode as
ASCII or UTF-8, but the code would appear to work normally until
it encountered a non-ASCII hostname, allowing the problem to go
undetected.

On the other hand, such code is probably broken as things stand,
given that the address lookup functions can undocumentedly raise
UnicodeError in the same situation.  Also, protocol definitions
often specify some variant of the RFC 1123 syntax for hostnames
(thus making non-ASCII bytes illegal), so code that checked for
this prior to encoding the name would probably be OK, but it's
more likely the exception than the rule.

An alternative approach might be to return all hostnames as bytes
objects, thus breaking everything immediately and obviously...


[1] http://tools.ietf.org/html/rfc3491#section-5
[2] http://tools.ietf.org/html/rfc3454#appendix-C.5

----------
components: Extension Modules
files: ascii-surrogateescape.diff
keywords: patch
messages: 111550
nosy: baikie
priority: normal
severity: normal
status: open
title: socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file18195/ascii-surrogateescape.diff

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

From report at bugs.python.org  Sun Jul 25 21:12:35 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 25 Jul 2010 19:12:35 +0000
Subject: [New-bugs-announce] [issue9378] Make python -m pickle do something
	useful
In-Reply-To: <1280085155.28.0.122928002341.issue9378@psf.upfronthosting.co.za>
Message-ID: <1280085155.28.0.122928002341.issue9378@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Attached patch makes python -m pickle <pickle file> unpickle the first object from the pickle file and display it using pprint.  Future enhancements may include printing the summary (object number, object type) of the multiobject pickles, option to control display: pprint/repr or type only, lines/columns limits, and selective display from multi-object pickles.

I considered adding this functionality to pickletools (see issue 9094), but rejected because pickletools is more oriented towards pickle protocol developers and this functionality may be useful for casual pickle users.

----------
assignee: belopolsky
components: Library (Lib)
files: pickle-m.diff
keywords: easy, patch
messages: 111553
nosy: belopolsky
priority: normal
severity: normal
stage: patch review
status: open
title: Make python -m pickle do something useful
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file18197/pickle-m.diff

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

From report at bugs.python.org  Sun Jul 25 21:18:53 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sun, 25 Jul 2010 19:18:53 +0000
Subject: [New-bugs-announce] [issue9379] random.randrange behaviour problems
In-Reply-To: <1280085533.93.0.218883892309.issue9379@psf.upfronthosting.co.za>
Message-ID: <1280085533.93.0.218883892309.issue9379@psf.upfronthosting.co.za>


New submission from ?ukasz Langa <lukasz at langa.pl>:

Two behaviour problems with random.randrange:

1. Method argument `start` behaves as `stop` if `stop` is not defined:
======================================================================

>>> from random import randrange
>>> help(randrange)
Help on method randrange in module random:

randrange(self, start, stop=None, step=1, int=<class 'int'>, default=None, maxwidth=9007199254740992) method of random.Random instance
    Choose a random item from range(start, stop[, step]).

>>> randrange(10) #start=10
2

Clearly this is because randrange() mimicks the range() interface. Sphinx documentation specifies the behaviour clearly. The problem is, help() can mislead someone in this case.



2. `step` does not work when only `start` (acting as `stop`) specified:
=======================================================================

>>> [randrange(0, 10, step=5) for i in range(10)]
[5, 5, 5, 0, 5, 5, 5, 0, 0, 5]
>>> [randrange(10, step=5) for i in range(10)]
[5, 2, 4, 4, 6, 2, 7, 1, 5, 7]

One would expect the latter to work the same way as the former.



What next
=========

Case 2 is clearly a bug that should be addressed. Raymond, Mark - would a patch for this be accepted for 2.7.x, 3.1.x and 3.2? If so I can provide one.

In Case 1 we can do one of two things (or both):
A. Tweak the docstring to specify the actual behaviour explicitly.
B. Change the function definition to: `randrange(self, limit, *args, **kwargs)`. This is backwards compatible if we'd process `args` and `kwargs` correctly to keep the current interface intact (e.g. `start` would be processed in `kwargs`). This would leave a more predictable help().

Raymond, Mark - I'd say we absolutely do A. Does any of you object about B?

----------
components: Library (Lib)
messages: 111554
nosy: BreamoreBoy, lukasz.langa, rhettinger
priority: normal
severity: normal
status: open
title: random.randrange behaviour problems
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Jul 26 02:04:58 2010
From: report at bugs.python.org (ipatrol)
Date: Mon, 26 Jul 2010 00:04:58 +0000
Subject: [New-bugs-announce] [issue9380] Allow popping of n elements at once
	from a deque
In-Reply-To: <1280102698.23.0.646561377953.issue9380@psf.upfronthosting.co.za>
Message-ID: <1280102698.23.0.646561377953.issue9380@psf.upfronthosting.co.za>


New submission from ipatrol <ipatrol6010 at yahoo.com>:

Yes, I know, this was proposed with builtin lists years before. But I can't help but think that at least for pop-append oriented deques, a popping analogue to extend would make use of deques in iterators easier. It should ideally return an iterator, possibly with an added __len__ method. I suggest the names popn and popnleft.

----------
components: Library (Lib)
messages: 111583
nosy: ipatrol
priority: normal
severity: normal
status: open
title: Allow popping of n elements at once from a deque
type: feature request
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Jul 26 06:53:03 2010
From: report at bugs.python.org (Chris Rebert)
Date: Mon, 26 Jul 2010 04:53:03 +0000
Subject: [New-bugs-announce] [issue9381] syntax error in Unicode C API docs
In-Reply-To: <1280119983.35.0.570535028701.issue9381@psf.upfronthosting.co.za>
Message-ID: <1280119983.35.0.570535028701.issue9381@psf.upfronthosting.co.za>


New submission from Chris Rebert <pybugs at rebertia.com>:

See http://docs.python.org/py3k/c-api/unicode.html#file-system-encoding

Note the literal and unhyperlinked ":func:PyUnicode_FSConverter" in the last sentence of the first paragraph. I suspect there's a trivial syntax error in the ReST source.

----------
assignee: docs at python
components: Documentation
messages: 111596
nosy: cvrebert, docs at python
priority: normal
severity: normal
status: open
title: syntax error in Unicode C API docs
versions: Python 3.3

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

From report at bugs.python.org  Mon Jul 26 07:24:09 2010
From: report at bugs.python.org (Chris Rebert)
Date: Mon, 26 Jul 2010 05:24:09 +0000
Subject: [New-bugs-announce] [issue9382] os.popen referenced but not
	documented in Python 3.x
In-Reply-To: <1280121849.18.0.464291520909.issue9382@psf.upfronthosting.co.za>
Message-ID: <1280121849.18.0.464291520909.issue9382@psf.upfronthosting.co.za>


New submission from Chris Rebert <pybugs at rebertia.com>:

http://docs.python.org/py3k/library/os.html  currently mentions os.popen() in several places. The docs for os.popen() itself say:
'These functions are described in section "File Object Creation"'

However, unlike the 2.x version of that section ( http://docs.python.org/library/os.html#file-object-creation ), the os.popen*() family is not documented there [or indeed anywhere] anymore ( http://docs.python.org/py3k/library/os.html#os-newstreams ); the entire section now only documents os.fdopen().

The 2.7 docs say that the os.popen*() family are deprecated, and indeed, of the family, only os.popen() seems to still exist in Python 3.x (at least based on my testing via ideone.com).

Thus, from what I can see, one of the following is the case:
(A) The entire os.popen*() family is supposed be gone in Python 3.x, so os.popen() should be removed entirely from both the code and the docs.
(B) os.popen() is the sole legitimate survivor of its family, and should be properly documented again.
(C) os.popen() was left in as a kludge, shouldn't be mentioned in the docs, and possibly should be renamed os._popen() to reflect its status.

So, which one of these is it?

----------
assignee: docs at python
components: Documentation
messages: 111597
nosy: cvrebert, docs at python
priority: normal
severity: normal
status: open
title: os.popen referenced but not documented in Python 3.x
versions: Python 3.1

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

From report at bugs.python.org  Mon Jul 26 17:08:32 2010
From: report at bugs.python.org (Arrnaud Fabre)
Date: Mon, 26 Jul 2010 15:08:32 +0000
Subject: [New-bugs-announce] [issue9383] PIL Bug with split
In-Reply-To: <1280156912.66.0.913857583224.issue9383@psf.upfronthosting.co.za>
Message-ID: <1280156912.66.0.913857583224.issue9383@psf.upfronthosting.co.za>


New submission from Arrnaud Fabre <arnaud333 at gmail.com>:

>>> import Image
>>> im = Image.open('whatever')
>>> im.split()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 1497, in split
    if self.im.bands == 1:
AttributeError: 'NoneType' object has no attribute 'bands'

Bug can be fixed by using getdata before split() :

>>> import Image
>>> im = Image.open('whatever')
>>> im.getdata()
<ImagingCore object at 0x7fad913c0090>
>>> im.split()
(<Image.Image image mode=L size=360x480 at 0x1CAE320>, <Image.Image image mode=L size=360x480 at 0x1CAE368>, <Image.Image image mode=L size=360x480 at 0x1CAE3B0>)

----------
messages: 111630
nosy: Arrnaud.Fabre
priority: normal
severity: normal
status: open
title: PIL Bug with split
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul 26 18:45:01 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 26 Jul 2010 16:45:01 +0000
Subject: [New-bugs-announce] [issue9384] Tkinter windows pop under the
	terminal in OSX
In-Reply-To: <1280162701.76.0.316880678419.issue9384@psf.upfronthosting.co.za>
Message-ID: <1280162701.76.0.316880678419.issue9384@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

I believe any Tkinter app will exhibit the same behavior, but I discovered this with idle and verified with wish.py:


$ ./python.exe Demo/tkinter/guido/wish.py 
% quit
Traceback (most recent call last):
  File "Demo/tkinter/guido/wish.py", line 22, in <module>
    if tk.getboolean(tk.call('info', 'complete', cmd)):
_tkinter.TclError: expected boolean value but got ""


Note that the Traceback above is probably due to another bug.

If you start wish.py from a terminal covering the top left corner of the screen, the wish window will appear under the terminal window.

----------
assignee: ronaldoussoren
components: IDLE, Macintosh, Tkinter
messages: 111641
nosy: belopolsky, ronaldoussoren
priority: normal
severity: normal
status: open
title: Tkinter windows pop under the terminal in OSX
type: behavior

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

From report at bugs.python.org  Mon Jul 26 19:02:36 2010
From: report at bugs.python.org (Radoslaw Madej)
Date: Mon, 26 Jul 2010 17:02:36 +0000
Subject: [New-bugs-announce] [issue9385] python-2.6.5 and 3.2.1 uses 'rwx'
	mmap() calls for the	ctypes module
In-Reply-To: <1280163756.22.0.278914543931.issue9385@psf.upfronthosting.co.za>
Message-ID: <1280163756.22.0.278914543931.issue9385@psf.upfronthosting.co.za>


New submission from Radoslaw Madej <radegand at o2.pl>:

Hi,

Python ctypes module creates a 'rwx' memory mapping (defined in malloc_closure.c) which causes python to crash when running under grsecurity enabled kernel and could also have a negative security impact. 

Is there any specific need for the mmap call to create an executable mapping or can it be safely removed? 

Please refer here for more information and proposed patch:
http://bugs.gentoo.org/show_bug.cgi?id=329499

The actual mmap call:
item = (ITEM *)mmap(NULL,
                            count * sizeof(ITEM),
                            PROT_READ | PROT_WRITE | PROT_EXEC,
                            MAP_PRIVATE | MAP_ANONYMOUS,
                            -1,
                            0);

There has been further investigation done by Gentoo users and work towards python handling this error gracefully rather than segfaulting. It seems that dereference at Py_XDECREF(self->restype); (line 23 of Modules/_ctypes/callbacks.c) causes the segfault.

Thanks.

----------
assignee: theller
components: ctypes
messages: 111644
nosy: radegand532, theller
priority: normal
severity: normal
status: open
title: python-2.6.5 and 3.2.1 uses 'rwx' mmap() calls for the ctypes module
type: security
versions: Python 2.6, Python 3.2

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

From report at bugs.python.org  Mon Jul 26 19:28:25 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 26 Jul 2010 17:28:25 +0000
Subject: [New-bugs-announce] [issue9386] Bad indentation in urllib import
	fixer with multipe	imports
In-Reply-To: <1280165305.89.0.706403927201.issue9386@psf.upfronthosting.co.za>
Message-ID: <1280165305.89.0.706403927201.issue9386@psf.upfronthosting.co.za>


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

Running 2to3 on lxml-2.2.6 failed with broken indentation.

This fragment from lxml/html/__init__.py:
> def open_http_urllib(method, url, values):
>     ## FIXME: should test that it's not a relative URL or something
>     try:
>        from urllib import urlencode, urlopen
>     except ImportError: # Python 3

became:
> def open_http_urllib(method, url, values):
>     ## FIXME: should test that it's not a relative URL or something
>     try:
>         from urllib.parse import urlencode
> from urllib.request import urlopen
>     except ImportError: # Python 3

which is syntactically invalid: note the invalid indentation for the second "import" line.

Seems to work when there's a single name imported per line; fails when more than one name is imported from urlib.


Am attaching a patch to test_fixers (for the 2.7 branch) which adds a reproducer.  I don't have a fix.

test test_lib2to3 failed -- Traceback (most recent call last):
  File "/home/david/coding/python-svn/2.7-2to3/Lib/lib2to3/tests/test_fixers.py", line 1858, in test_import_indentation
    self.check(b, a)
  File "/home/david/coding/python-svn/2.7-2to3/Lib/lib2to3/tests/test_fixers.py", line 37, in check
    tree = self._check(before, after)
  File "/home/david/coding/python-svn/2.7-2to3/Lib/lib2to3/tests/test_fixers.py", line 33, in _check
    self.assertEqual(after, unicode(tree))
AssertionError: u"\ndef foo():\n    from urllib.parse import urlencode\n    from urllib.parse im [truncated]... != u"\ndef foo():\n    from urllib.parse import urlencode\nfrom urllib.request impo [truncated]...
  
  def foo():
      from urllib.parse import urlencode
-     from urllib.parse import urlopen
? ----            --  ^
+ from urllib.request import urlopen
?              ++++ ^
      print('got here')
  
(Note to self: tracking this downstream in Fedora for lxml as https://bugzilla.redhat.com/show_bug.cgi?id=600036 )

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: urllib-indentation-issue.patch
keywords: patch
messages: 111649
nosy: dmalcolm
priority: normal
severity: normal
stage: needs patch
status: open
title: Bad indentation in urllib import fixer with multipe imports
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file18212/urllib-indentation-issue.patch

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

From report at bugs.python.org  Mon Jul 26 19:46:28 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 26 Jul 2010 17:46:28 +0000
Subject: [New-bugs-announce] [issue9387] Make python -m tkinter run tkinter
	test
In-Reply-To: <1280166388.67.0.0667183564509.issue9387@psf.upfronthosting.co.za>
Message-ID: <1280166388.67.0.0667183564509.issue9387@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Since tkinter is a package, it requires __main__.py in order to be runnable using -m option.  Attached tkinter-m.patch fixes this.

----------
assignee: belopolsky
components: Tkinter
files: tkinter-m.py
keywords: easy
messages: 111654
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Make python -m tkinter run tkinter test
type: feature request
Added file: http://bugs.python.org/file18213/tkinter-m.py

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

From report at bugs.python.org  Tue Jul 27 06:09:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 27 Jul 2010 04:09:16 +0000
Subject: [New-bugs-announce] [issue9388] locale documentation describes
	non-existing ERA_YEAR	constant
In-Reply-To: <1280203756.3.0.102200795898.issue9388@psf.upfronthosting.co.za>
Message-ID: <1280203756.3.0.102200795898.issue9388@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Grepping through the source tree, reveals a single match for ERA_YEAR:

Doc/library/locale.rst:247:   .. data:: ERA_YEAR

Google search for it shows an OpenSolaris bug report that explains the origin of this constant:

"""
There appears to be an IBM-private field in _LC_time_t struct, 
era_year.   We should remove "era_year" from the _LC_time_t struct.  
This should only affect the LC_TIME functions, localedef 
command, and locale objects.  (nl_langinfo and langinfo.h are
unaffected because they don't reference era_year.) 
"""

I believe this entry should simply be removed.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 111683
nosy: belopolsky, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: locale documentation describes non-existing ERA_YEAR constant
versions: Python 3.2

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

From report at bugs.python.org  Tue Jul 27 06:32:41 2010
From: report at bugs.python.org (Guy)
Date: Tue, 27 Jul 2010 04:32:41 +0000
Subject: [New-bugs-announce] [issue9389] Traceback: Exception Shows Code
	that's On-Disk (Not in	memory)
In-Reply-To: <1280205161.63.0.842402205651.issue9389@psf.upfronthosting.co.za>
Message-ID: <1280205161.63.0.842402205651.issue9389@psf.upfronthosting.co.za>


New submission from Guy <Guy at openmail.cc>:

When an exception is raised and Python's showing a traceback, the lines of the Python scripts are that of those on-disk, not in memory.

For example, if I run a Python script which raises an exception, but I edit the line the exception occurs on and save the script in the same location, the new line (The one that's not interpreted), will be shown in the traceback.

----------
components: Interpreter Core
messages: 111685
nosy: Guy
priority: normal
severity: normal
status: open
title: Traceback: Exception Shows Code that's On-Disk (Not in memory)
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jul 27 14:51:29 2010
From: report at bugs.python.org (sorin)
Date: Tue, 27 Jul 2010 12:51:29 +0000
Subject: [New-bugs-announce] [issue9390] Error in sys.excepthook on windows
	when redirecting	output of the script
In-Reply-To: <1280235089.13.0.870066677678.issue9390@psf.upfronthosting.co.za>
Message-ID: <1280235089.13.0.870066677678.issue9390@psf.upfronthosting.co.za>


New submission from sorin <sorin.sbarnea at gmail.com>:

create a test.py with this content:
print("test")

run this file from command line by redirecting the output:
test.py >out.log

You get:
----
close failed in file object destructor:                                                                                                     
Error in sys.excepthook:                                                                                                                    
                                                                                                                                            
Original exception was:                
----

This does not happen if you call the script by using "python test.py >out.log"

Also this does not reproduce with Python 3.1 but it does reproduce with latest Python 2.6 and 2.7 under windows.

You can switch the registered python interpreter via registry key:

[HKEY_CLASSES_ROOT\Python.File\shell\open\command]
@="\"C:\\lib\\Python27\\python.exe\" \"%1\" %*"

----------
components: Windows
messages: 111695
nosy: sorin
priority: normal
severity: normal
status: open
title: Error in sys.excepthook on windows when redirecting output of the script
type: crash
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Jul 27 20:29:43 2010
From: report at bugs.python.org (Anthony Long)
Date: Tue, 27 Jul 2010 18:29:43 +0000
Subject: [New-bugs-announce] [issue9391] Allow docstrings on dicts and named
	tuples outside of	functions or classes.
In-Reply-To: <1280255383.56.0.833674044306.issue9391@psf.upfronthosting.co.za>
Message-ID: <1280255383.56.0.833674044306.issue9391@psf.upfronthosting.co.za>


New submission from Anthony Long <antlong at gmail.com>:

I would like to add docstrings to dicts and named tuples. Dicts can be used to hold many different kinds of information, and docstrings would help to shed light on what the dict does to others.

Named tuples also should have docstrings, since they can also include information which can be explained it great detail within docstrings.

----------
components: Interpreter Core
messages: 111711
nosy: antlong
priority: normal
severity: normal
status: open
title: Allow docstrings on dicts and named tuples outside of functions or classes.
type: feature request
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Jul 27 21:51:30 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 27 Jul 2010 19:51:30 +0000
Subject: [New-bugs-announce] [issue9392] 2.7 framework install doesn't
	create 2to3-2.7
In-Reply-To: <1280260290.87.0.060778319608.issue9392@psf.upfronthosting.co.za>
Message-ID: <1280260290.87.0.060778319608.issue9392@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

Framework installs ensure that all tools and scripts are installed using versioned names (as well as the regular names) to make it easier to use multiple versions of  python side by side.

The 2.7 tree fails to create a versioned name of the 2to3 tool (while 2.6, 3.1 and 3.2 do)

I have a patch and will commit that once I've tested it.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 111721
nosy: ronaldoussoren
priority: normal
severity: normal
status: open
title: 2.7 framework install doesn't create 2to3-2.7
versions: Python 2.7

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

From report at bugs.python.org  Wed Jul 28 11:10:43 2010
From: report at bugs.python.org (wjm251)
Date: Wed, 28 Jul 2010 09:10:43 +0000
Subject: [New-bugs-announce] [issue9393] shelve.open/bsddb.hashopen raise
	Exception'No such file	or directory'for "Chinese path"
In-Reply-To: <1280308243.23.0.510970772038.issue9393@psf.upfronthosting.co.za>
Message-ID: <1280308243.23.0.510970772038.issue9393@psf.upfronthosting.co.za>


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

Windows XP Simple Chinese Version
in python2.5,Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)] on win32
I have a directory "D:\???????"
my code is as follows: 
#--------------------------------------
temppath = u"D:\\???????\\a"
import shelve
cache = shelve.open(temppath, 'c')
#--------------------------------------

when use temppath.encode("utf-8"),it works,
but in python2.6,temppath can works properly

but I got a Error with such traceback

Traceback (most recent call last):
  File "D:\eclipse_workspace\pytest\src\test.py", line 5, in <module>
    cache = shelve.open(temppath, 'c')
  File "D:\eclipse_workspace\omstarv5r6\linksvn\src\UNPPython\pywindows\Lib\shelve.py", line 225, in open
    return DbfilenameShelf(filename, flag, protocol, writeback)
  File "D:\eclipse_workspace\omstarv5r6\linksvn\src\UNPPython\pywindows\Lib\shelve.py", line 209, in __init__
    Shelf.__init__(self, anydbm.open(filename, flag), protocol, writeback)
  File "D:\eclipse_workspace\omstarv5r6\linksvn\src\UNPPython\pywindows\Lib\anydbm.py", line 83, in open
    return mod.open(file, flag, mode)
  File "D:\eclipse_workspace\omstarv5r6\linksvn\src\UNPPython\pywindows\Lib\dbhash.py", line 16, in open
    return bsddb.hashopen(file, flag, mode)
  File "D:\eclipse_workspace\omstarv5r6\linksvn\src\UNPPython\pywindows\Lib\bsddb\__init__.py", line 310, in hashopen
    d.open(file, db.DB_HASH, flags, mode)
bsddb.db.DBNoSuchFileError: (2, 'No such file or directory')

----------
components: Library (Lib)
messages: 111779
nosy: wjm251
priority: normal
severity: normal
status: open
title: shelve.open/bsddb.hashopen raise Exception'No such file or directory'for "Chinese path"
versions: Python 2.5

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

From report at bugs.python.org  Wed Jul 28 11:16:49 2010
From: report at bugs.python.org (wjm251)
Date: Wed, 28 Jul 2010 09:16:49 +0000
Subject: [New-bugs-announce] [issue9394] shelve.open/bsddb.hashopen
	raise	bsddb.db.DBNoSuchFileError: (2,
	'No such file or directory') with Chinese Path
In-Reply-To: <1280308609.85.0.47516967523.issue9394@psf.upfronthosting.co.za>
Message-ID: <1280308609.85.0.47516967523.issue9394@psf.upfronthosting.co.za>


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

Windows XP Simple Chinese Version
in python2.5,Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)] on win32
I have a directory "D:\???????"
my code is as follows: 
#--------------------------------------
temppath = u"D:\\???????\\a"
import shelve
cache = shelve.open(temppath, 'c')
#--------------------------------------

when use temppath.encode("utf-8"),it works,
but in python2.6,temppath can works properly

but I got a Error with such traceback

Traceback (most recent call last):
  File "D:\eclipse_workspace\pytest\src\test.py", line 5, in <module>
    cache = shelve.open(temppath, 'c')
  File "D:\eclipse_workspace\omstarv5r6\linksvn\src\UNPPython\pywindows\Lib\shelve.py", line 225, in open
    return DbfilenameShelf(filename, flag, protocol, writeback)
  File "D:\eclipse_workspace\omstarv5r6\linksvn\src\UNPPython\pywindows\Lib\shelve.py", line 209, in __init__
    Shelf.__init__(self, anydbm.open(filename, flag), protocol, writeback)
  File "D:\eclipse_workspace\omstarv5r6\linksvn\src\UNPPython\pywindows\Lib\anydbm.py", line 83, in open
    return mod.open(file, flag, mode)
  File "D:\eclipse_workspace\omstarv5r6\linksvn\src\UNPPython\pywindows\Lib\dbhash.py", line 16, in open
    return bsddb.hashopen(file, flag, mode)
  File "D:\eclipse_workspace\omstarv5r6\linksvn\src\UNPPython\pywindows\Lib\bsddb\__init__.py", line 310, in hashopen
    d.open(file, db.DB_HASH, flags, mode)
bsddb.db.DBNoSuchFileError: (2, 'No such file or directory')

----------
components: Library (Lib)
messages: 111780
nosy: wjm251
priority: normal
severity: normal
status: open
title: shelve.open/bsddb.hashopen raise bsddb.db.DBNoSuchFileError: (2, 'No such file or directory') with Chinese Path
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Wed Jul 28 12:09:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 28 Jul 2010 10:09:31 +0000
Subject: [New-bugs-announce] [issue9395] clean does not remove all temp files
In-Reply-To: <1280311771.86.0.556150594835.issue9395@psf.upfronthosting.co.za>
Message-ID: <1280311771.86.0.556150594835.issue9395@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

The clean command does not delete all build artifacts.

----------
assignee: tarek
components: Distutils, Distutils2
messages: 111781
nosy: exarkun, merwok, tarek
priority: normal
severity: normal
stage: unit test needed
status: open
title: clean does not remove all temp files
type: behavior

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

From report at bugs.python.org  Wed Jul 28 13:27:12 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 28 Jul 2010 11:27:12 +0000
Subject: [New-bugs-announce] [issue9396] Standardise (and publish?) cache
	handling in standard	library
In-Reply-To: <1280316432.08.0.674221936967.issue9396@psf.upfronthosting.co.za>
Message-ID: <1280316432.08.0.674221936967.issue9396@psf.upfronthosting.co.za>


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

The standard library has several cache implementations (e.g. in re, fnmatch and ElementTree) with different cache size limiting strategies. These should be standardised and possibly even exposed for general use.

Refer to python-dev discussion:
http://mail.python.org/pipermail/python-dev/2010-July/102473.html

----------
components: Library (Lib)
messages: 111790
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Standardise (and publish?) cache handling in standard library
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Wed Jul 28 16:08:29 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Jul 2010 14:08:29 +0000
Subject: [New-bugs-announce] [issue9397] Remove references to the missing
	dbm.bsd module
In-Reply-To: <1280326109.56.0.0484206700812.issue9397@psf.upfronthosting.co.za>
Message-ID: <1280326109.56.0.0484206700812.issue9397@psf.upfronthosting.co.za>


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

dbm doc tells that there is a dbm.bsd module, but no, there is not. The third party module, pybsddb (or "bsddb3"), is installed as "bsddb3".

Python3 dbm module was created by #2881 (r63662).

Some references to dbm.bsd were removed by r72711, but not all.

----------
components: Library (Lib)
messages: 111813
nosy: georg.brandl, haypo
priority: normal
severity: normal
status: open
title: Remove references to the missing dbm.bsd module
versions: Python 3.2

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

From report at bugs.python.org  Wed Jul 28 17:04:02 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 28 Jul 2010 15:04:02 +0000
Subject: [New-bugs-announce] [issue9398] Unify sys.settrace and
	sys.setprofile tests
In-Reply-To: <1280329442.24.0.0145405625071.issue9398@psf.upfronthosting.co.za>
Message-ID: <1280329442.24.0.0145405625071.issue9398@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Th sys.settrace and sys.setprofile functions have the same interface an very similar purpose.  The difference is in the types of events that get reported.  However the tests for these functions are implemented separately and cover different sets of scenarios.  As proposed in python-dev thread, "Does trace modules have a unit test?" [1], this RFE proposes to

"""
Create tracetester helper file with abstract test cases made
from the union of test_sys_settrace and  test_sys_setprofile test
cases and replace the concrete test cases in test_sys_set* with
subclasses that define setmethod, getmethod and expected_output.
"""
[1] http://mail.python.org/pipermail/python-dev/2010-July/102308.html

See also issue 9315.

----------
assignee: belopolsky
components: Tests
messages: 111823
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: Unify sys.settrace and sys.setprofile tests
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Jul 28 17:10:40 2010
From: report at bugs.python.org (Dennis Malcorps)
Date: Wed, 28 Jul 2010 15:10:40 +0000
Subject: [New-bugs-announce] [issue9399] Provide a 'print' action for
	argparse
In-Reply-To: <1280329840.94.0.288179215378.issue9399@psf.upfronthosting.co.za>
Message-ID: <1280329840.94.0.288179215378.issue9399@psf.upfronthosting.co.za>


New submission from Dennis Malcorps <dennis.malcorps at googlemail.com>:

Currently argparse has a 'version' action which can be triggered by user defined options which prints out a custom string.

parser.add_argument("--version", action="version", version="test 1.2.3")

Since the 'version' action can be added multiple times, it can be used to output different kinds of information, like the program's license.

parser.add_argument("--license", action="version", version="This file is licensed under GPL.... [a huge amount of text]")

The only drawback is that linebreaks are substituted with a normal space. So I propose a 'print' action (perhaps as a replacement for 'version'?) which respects whitespace characters.

parser.add_argument("--version", action="print", message="test 1.2.3")
parser.add_argument("--license", action="print", message="This file is licensed under GPL.... [a huge amount of text, now properly formatted!]")
parser.add_argument("--insult-me", action="print", message="You sick *peep* , *peep* yourself in *peep*")

Currently, the only solution is to create a custom action which is IMHO a bit overkill for just printing a simple string to stdout.

----------
components: Library (Lib)
messages: 111824
nosy: travistouchdown
priority: normal
severity: normal
status: open
title: Provide a 'print' action for argparse
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Jul 28 18:03:47 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 28 Jul 2010 16:03:47 +0000
Subject: [New-bugs-announce] [issue9400]
	multiprocessing.pool.AsyncResult.get() messes up	exceptions
In-Reply-To: <1280333027.17.0.112361474517.issue9400@psf.upfronthosting.co.za>
Message-ID: <1280333027.17.0.112361474517.issue9400@psf.upfronthosting.co.za>


New submission from Nikolaus Rath <Nikolaus at rath.org>:

The attached test program calls apply_async with a function that will raise CalledProcessError. However, when result.get() is called, it raises a TypeError and the program hangs:

$ ./bug.py
ERROR:root:ops
Traceback (most recent call last):
  File "./bug.py", line 19, in run_with
    dW1 = run_dcon()
  File "./bug.py", line 26, in run_dcon
    subprocess.check_call(['dcon'], stdout=fh, stderr=fh)
  File "/usr/lib/python2.6/subprocess.py", line 498, in check_call
    raise CalledProcessError(retcode, cmd)
CalledProcessError: Command '['dcon']' returned non-zero exit status 127
Exception in thread Thread-2:
Traceback (most recent call last):
  File "/usr/lib/python2.6/threading.py", line 532, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.6/threading.py", line 484, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib/python2.6/multiprocessing/pool.py", line 259, in _handle_results
    task = get()
TypeError: ('__init__() takes exactly 3 arguments (1 given)', <class 'subprocess.CalledProcessError'>, ())

----------
components: Library (Lib)
files: bug.py
messages: 111827
nosy: Nikratio
priority: normal
severity: normal
status: open
title: multiprocessing.pool.AsyncResult.get() messes up exceptions
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file18233/bug.py

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

From report at bugs.python.org  Wed Jul 28 19:56:56 2010
From: report at bugs.python.org (Michael Gilbert)
Date: Wed, 28 Jul 2010 17:56:56 +0000
Subject: [New-bugs-announce] [issue9401] automatically try forward
	operations when reverse	operations are NotImplemented
In-Reply-To: <1280339816.95.0.28348031653.issue9401@psf.upfronthosting.co.za>
Message-ID: <1280339816.95.0.28348031653.issue9401@psf.upfronthosting.co.za>


New submission from Michael Gilbert <michael.s.gilbert at gmail.com>:

in order to make overrides simpler, and more obvious to average developers, it would be very useful to automatically call the forward operations (e.g. __mul__) when the reverse operations (e.g. __rmul__) are NotImplemented.  

i spent quite a bit of time trying to discover why x*3 worked (where x is a class that i created with a __mul__ method); whereas 3*x wouldn't. this feature would really help since in most applications the same behavior is expected from forward and reverse operations.

for now, i am content with doing this manually, but it would be nice if it were automated.  all of my reverse operations just do:

    def __rmul__( self , other ):
        return self.__mul__( other )

where i manually check the type of other in the forward operation, and then handle it appropriately.

thanks for considering this.

best wishes,
mike

----------
components: Interpreter Core
messages: 111833
nosy: Michael.Gilbert
priority: normal
severity: normal
status: open
title: automatically try forward operations when reverse operations are NotImplemented
type: feature request
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Wed Jul 28 22:53:48 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Jul 2010 20:53:48 +0000
Subject: [New-bugs-announce] [issue9402] pyexpat: replace PyObject_DEL() by
	Py_DECREF() to fix a	crash in pydebug mode
In-Reply-To: <1280350428.05.0.23614798147.issue9402@psf.upfronthosting.co.za>
Message-ID: <1280350428.05.0.23614798147.issue9402@psf.upfronthosting.co.za>


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

PyObject_DEL() should not be used to destroy an object because it will break the linked list of allocated objects using in pydebug mode to detect bugs. pyexpat should use Py_DECREF() instead of PyObject_DEL() to destroy an object.

Attached patch fixes that.

See #3299 for the whole story.

----------
components: Library (Lib)
files: pyexpat_py_decref.patch
keywords: patch
messages: 111845
nosy: haypo
priority: normal
severity: normal
status: open
title: pyexpat: replace PyObject_DEL() by Py_DECREF() to fix a crash in pydebug mode
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file18235/pyexpat_py_decref.patch

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

From report at bugs.python.org  Wed Jul 28 22:58:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Jul 2010 20:58:25 +0000
Subject: [New-bugs-announce] [issue9403] cElementTree: replace
	PyObject_DEL() by Py_DECREF() to	fix a crash in pydebug mode
In-Reply-To: <1280350705.3.0.213499722891.issue9403@psf.upfronthosting.co.za>
Message-ID: <1280350705.3.0.213499722891.issue9403@psf.upfronthosting.co.za>


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

PyObject_DEL() should not be used to destroy an object because it will break the linked list of allocated objects, list used in pydebug mode to detect bugs. cElementTree should use Py_DECREF() instead of PyObject_DEL() to destroy an objects.

Attached patch fixes that:
 * Replace PyObject_Del() by Py_DECREF()
 * Catch element_new_extra() errors
 * parser dealloc: replace Py_DECREF() by Py_XDECREF() because the pointer may be NULL (error in the constructor)
 * set all parser attributes to NULL at the beginning of the constructor to be able to call safetly the destructor
 * element_new(): define tag, text, tail attributes before calling element_new_extra() to be able to call the destructor
 * raise a MemoryError on element_new_extra() failure. element_new() didn't raise any error on element_new_extra() failure. Other functions just forget to catch element_new_extra() error.

See #3299 for the whole story.

----------
components: Library (Lib)
files: celementtree_py_decref.patch
keywords: patch
messages: 111846
nosy: haypo
priority: normal
severity: normal
status: open
title: cElementTree: replace PyObject_DEL() by Py_DECREF() to fix a crash in pydebug mode
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file18236/celementtree_py_decref.patch

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

From report at bugs.python.org  Wed Jul 28 23:28:00 2010
From: report at bugs.python.org (Chris Leaf)
Date: Wed, 28 Jul 2010 21:28:00 +0000
Subject: [New-bugs-announce] [issue9404] IDLE won't launch on XP
In-Reply-To: <1280352480.94.0.617351160567.issue9404@psf.upfronthosting.co.za>
Message-ID: <1280352480.94.0.617351160567.issue9404@psf.upfronthosting.co.za>


New submission from Chris Leaf <xcyborgninja at gmail.com>:

I have been using IDLE on my previous laptop and it was working well although I have to say I'm still very new to python. I've read around about the issue and can't find any solution I can use. I can run the IDLE GUI through the python command line version by saying "import idle" but it generates a bunch of error lines (copied the command prompt):

>>> import idle
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "c:\python31\lib\idlelib\idle.py", line 11, in <module>
    idlelib.PyShell.main()
  File "c:\python31\lib\idlelib\PyShell.py", line 1388, in main
    shell = flist.open_shell()
  File "c:\python31\lib\idlelib\PyShell.py", line 277, in open_shell
    self.pyshell = PyShell(self)
  File "c:\python31\lib\idlelib\PyShell.py", line 813, in __init__
    OutputWindow.__init__(self, flist, None, None)
  File "c:\python31\lib\idlelib\OutputWindow.py", line 16, in __init__
    EditorWindow.__init__(self, *args)
  File "c:\python31\lib\idlelib\EditorWindow.py", line 261, in __init__
    self.update_recent_files_list()
  File "c:\python31\lib\idlelib\EditorWindow.py", line 779, in update_recent_fil
es_list
    rf_file = open(self.recent_files_path, 'w')
IOError: [Errno 13] Permission denied: 'C:\\Documents and Settings\\<USERNAME>\\.idle
rc\\recent-files.lst'


I have tried to use Explorer to reach the files and I get a permission error (the same occurs when trying to reach with the command prompt). I have tried to change the read only nature of this folder and it automatically reverts after the attribute is set. Also the folder is empty according to explorer. I have tried running it with my firewall disabled. 

I am running 32bit XP on a lenovo T510 with 3.1.2 python installed

Thanks in advance!

----------
components: IDLE
messages: 111850
nosy: Chris.Leaf
priority: normal
severity: normal
status: open
title: IDLE won't launch on XP
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Wed Jul 28 23:30:35 2010
From: report at bugs.python.org (mike bayer)
Date: Wed, 28 Jul 2010 21:30:35 +0000
Subject: [New-bugs-announce] [issue9405] crash when calling
	urllib.getproxies() under OSX with	subprocess / particular
	memory usage
In-Reply-To: <1280352635.35.0.910645426575.issue9405@psf.upfronthosting.co.za>
Message-ID: <1280352635.35.0.910645426575.issue9405@psf.upfronthosting.co.za>


New submission from mike bayer <mike_mp at zzzcomputing.com>:

I'm not optimistic that this will be reproducible elsewhere.   I get a silent failure with 2.6 and a crash dialog with 2.7 with the following script.   All elements are necessary, although the "pkg_resources" import may be arbitrary, and reproduces if it comes from the latest setuptools or if it comes from Distribute.    I've attached the crash report generated by OSX in the event that someone knows how to interpret it.   The script fails for me every time, though not for other people I've had test.


import pkg_resources

import urllib
import multiprocessing

def sub():
    print "about to call getproxies !"
    urllib.getproxies()
    print "getproxies has completed !"
    
process = multiprocessing.Process(target=sub)
process.start()

print "hi!"

process.join()



Process:         Python [79964]
Path:            /Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
Identifier:      Python
Version:         ??? (???)
Code Type:       X86 (Native)
Parent Process:  Python [79963]

Date/Time:       2010-07-28 17:24:19.281 -0400
OS Version:      Mac OS X 10.6.4 (10F569)
Report Version:  6

Interval Since Last Report:          1137309 sec
Crashes Since Last Report:           87
Per-App Crashes Since Last Report:   86
Anonymous UUID:                      848E03B6-EF61-45EA-9BB7-BF9E584CC670

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000104
Crashed Thread:  0  Dispatch queue: CFMachPort

Thread 0 Crashed:  Dispatch queue: CFMachPort
0   libSystem.B.dylib             	0x94419bdd _dispatch_wakeup + 91
1   libSystem.B.dylib             	0x9454a1f2 _dispatch_queue_push_list_slow + 37
2   libSystem.B.dylib             	0x94419c22 _dispatch_wakeup + 160
3   libSystem.B.dylib             	0x944196e6 _dispatch_source_create2 + 194
4   libSystem.B.dylib             	0x94419278 dispatch_source_timer_create_f + 286
5   libSystem.B.dylib             	0x94419158 dispatch_source_timer_create + 81
6   com.apple.CoreFoundation      	0x92fde72a ___CFMachPortCreateWithPort2_block_invoke_1 + 762
7   libSystem.B.dylib             	0x944190c3 dispatch_barrier_sync_f + 78
8   libSystem.B.dylib             	0x94418f9d dispatch_sync + 48
9   com.apple.CoreFoundation      	0x92fde350 _CFMachPortCreateWithPort2 + 272
10  com.apple.CoreFoundation      	0x92fe5e1c CFMachPortCreate + 204
11  com.apple.CoreFoundation      	0x92fe5c39 _CFXNotificationCenterCreate + 281
12  com.apple.CoreFoundation      	0x92fe5ad6 _CFXNotificationGetHostCenter + 86
13  com.apple.CoreFoundation      	0x92feb432 __CFXPreferencesGetSourceForTriplet + 354
14  com.apple.CoreFoundation      	0x92fea6ad __CFXPreferencesGetSearchListForBundleID + 205
15  com.apple.CoreFoundation      	0x92fea555 CFPreferencesCopyAppValue + 53
16  com.apple.SystemConfiguration 	0x90fc7348 SCDynamicStoreCopyProxies + 44
17  _scproxy.so                   	0x00746e31 get_proxies + 33
18  org.python.python             	0x000ca2b3 PyEval_EvalFrameEx + 20419
19  org.python.python             	0x000cbc88 PyEval_EvalFrameEx + 27032
20  org.python.python             	0x000cbc88 PyEval_EvalFrameEx + 27032
21  org.python.python             	0x000cc4ba PyEval_EvalCodeEx + 2042
22  org.python.python             	0x00041ca2 function_call + 162
23  org.python.python             	0x0000f375 PyObject_Call + 85
24  org.python.python             	0x000c7d5b PyEval_EvalFrameEx + 10859
25  org.python.python             	0x000cbc88 PyEval_EvalFrameEx + 27032
26  org.python.python             	0x000cbc88 PyEval_EvalFrameEx + 27032
27  org.python.python             	0x000cc4ba PyEval_EvalCodeEx + 2042
28  org.python.python             	0x00041ca2 function_call + 162
29  org.python.python             	0x0000f375 PyObject_Call + 85
30  org.python.python             	0x00021c66 instancemethod_call + 422
31  org.python.python             	0x0000f375 PyObject_Call + 85
32  org.python.python             	0x0007c8a7 slot_tp_init + 87
33  org.python.python             	0x0007b2d0 type_call + 176
34  org.python.python             	0x0000f375 PyObject_Call + 85
35  org.python.python             	0x000c8ad6 PyEval_EvalFrameEx + 14310
36  org.python.python             	0x000cbc88 PyEval_EvalFrameEx + 27032
37  org.python.python             	0x000cc4ba PyEval_EvalCodeEx + 2042
38  org.python.python             	0x000cc647 PyEval_EvalCode + 87
39  org.python.python             	0x000f0ae8 PyRun_FileExFlags + 168
40  org.python.python             	0x000f1a23 PyRun_SimpleFileExFlags + 867
41  org.python.python             	0x0010a42b Py_Main + 3163
42  org.python.python             	0x00001f82 0x1000 + 3970
43  org.python.python             	0x00001ea9 0x1000 + 3753

Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0xa04c511c  ebx: 0xa04c50f4  ecx: 0x00000001  edx: 0x00000100
  edi: 0x003011e0  esi: 0x003011d0  ebp: 0xbfffd5e8  esp: 0xbfffd5c0
   ss: 0x0000001f  efl: 0x00010206  eip: 0x94419bdd   cs: 0x00000017
   ds: 0x0000001f   es: 0x0000001f   fs: 0x00000000   gs: 0x00000037
  cr2: 0x00000104

Binary Images:
    0x1000 -     0x1ff5 +org.python.python 2.7.0 (2.7.0) <E493A842-C949-A532-656D-BC10750CCB80> /Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
    0x5000 -   0x142fe3 +org.python.python 2.7.0, (c) 2004-2008 Python Software Foundation. (2.7.0) <2815ECAD-BE96-97DE-C757-303EB571862B> /Library/Frameworks/Python.framework/Versions/2.7/Python
  0x2e1000 -   0x2f2ffd +zlib.so ??? (???) <B540E76D-58F8-F173-604E-3DA51E931A83> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/zlib.so
  0x2f7000 -   0x2f8fff +time.so ??? (???) <36AF5C9C-9495-3868-8A5A-4706C959F102> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/time.so
  0x561000 -   0x564fff +strop.so ??? (???) <255B3A81-AAF1-B616-41BC-C7B31DC15E8E> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/strop.so
  0x56a000 -   0x56affd +gestalt.so ??? (???) <E0CFE5CF-4765-4B7C-B708-2D2A5BED89B5> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/gestalt.so
  0x56e000 -   0x56fffe +MacOS.so ??? (???) <5E7E7E83-F983-3B58-053C-3114B498F8E3> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/MacOS.so
  0x5b4000 -   0x5bbff7 +_socket.so ??? (???) <6FFA1EB1-7D65-C514-22D2-20B663BC031D> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_socket.so
  0x5c4000 -   0x5c4ff3 +_functools.so ??? (???) <16603A15-F05E-ABA0-1AC4-86CD702988ED> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_functools.so
  0x5c8000 -   0x5cbff7 +_ssl.so ??? (???) <F675870E-3EF6-56D1-36F4-4D2F3B668199> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_ssl.so
  0x5d1000 -   0x5f7fff  libssl.0.9.7.dylib 0.9.7 (compatibility 0.9.7) <73B10885-F9AF-5B9D-A91C-D96869959EA5> /usr/lib/libssl.0.9.7.dylib
  0x606000 -   0x6bbfe7  libcrypto.0.9.7.dylib 0.9.7 (compatibility 0.9.7) <2E52683A-7E8E-68D5-5AC6-09962C37CB98> /usr/lib/libcrypto.0.9.7.dylib
  0x701000 -   0x702ff2 +cStringIO.so ??? (???) <C4534024-CC9B-BBBE-BBC1-337FF5BF6180> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/cStringIO.so
  0x707000 -   0x70aff3 +_collections.so ??? (???) <99610C80-5BDE-9B42-326E-C84573CF9ACC> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_collections.so
  0x710000 -   0x713ff7 +operator.so ??? (???) <286CBCF9-86C0-F84F-659C-F3EE95C7D4E1> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/operator.so
  0x71a000 -   0x71fff6 +itertools.so ??? (???) <47DA9FDB-A82B-FE94-1445-207EF0CF75B0> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/itertools.so
  0x728000 -   0x728ff5 +_bisect.so ??? (???) <0E86828B-074D-1E3B-4E6D-0871A2C3C65E> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_bisect.so
  0x72c000 -   0x72dff9 +_heapq.so ??? (???) <6C69EE01-CD6B-5092-B0DD-8DBE3FAACB50> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_heapq.so
  0x732000 -   0x735fff +_struct.so ??? (???) <0770C896-2971-B7E4-99F6-ECC9506E3A18> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_struct.so
  0x73c000 -   0x741fff +binascii.so ??? (???) <0ABB3540-FABB-FCB4-98FE-9997110E0713> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/binascii.so
  0x746000 -   0x746ff0 +_scproxy.so ??? (???) <8181FFBE-17E2-C16E-4DF3-4C692A430C22> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_scproxy.so
  0x78a000 -   0x78aff5 +_weakref.so ??? (???) <CC5A6874-5A1A-4431-FB8B-3CA18F0DDE5D> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_weakref.so
  0x78e000 -   0x790fff +_multiprocessing.so ??? (???) <B6B48505-F5BD-034F-2AFD-335DEF372EAF> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_multiprocessing.so
  0x795000 -   0x7a3fff +cPickle.so ??? (???) <EE83DA36-2629-B5FB-DCC5-677176844189> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/cPickle.so
0x8fe00000 - 0x8fe4162b  dyld 132.1 (???) <A4F6ADCC-6448-37B4-ED6C-ABB2CD06F448> /usr/lib/dyld
0x90003000 - 0x90104fe7  libxml2.2.dylib 10.3.0 (compatibility 10.0.0) <AB3A3749-B577-1EB3-72DF-215E866F1168> /usr/lib/libxml2.2.dylib
0x90105000 - 0x901bbffb  libFontParser.dylib ??? (???) <067DC1A2-764B-41EA-B07E-4205472749B7> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib
0x909b5000 - 0x909b8ff7  libCoreVMClient.dylib ??? (???) <420D9D10-B00E-202D-AA98-026996AB97DD> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib
0x909b9000 - 0x909dafe7  com.apple.opencl 12.1 (12.1) <DA2AC3FA-ED11-2D10-21E9-7BDF4778B228> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
0x90a53000 - 0x90a99ff7  libauto.dylib ??? (???) <0898A4A1-28BC-5337-EE17-D55C74F975F4> /usr/lib/libauto.dylib
0x90a9a000 - 0x90ab2ff7  com.apple.CFOpenDirectory 10.6 (10.6) <1537FB4F-C112-5D12-1E5D-3B1002A4038F> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
0x90ab3000 - 0x90b2efe7  com.apple.audio.CoreAudio 3.2.2 (3.2.2) <51D0E2DC-B15F-AF6C-70D8-026DDAD4E2A5> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
0x90b6a000 - 0x90b6aff7  com.apple.ApplicationServices 38 (38) <8012B504-3D83-BFBB-DA65-065E061CFE03> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
0x90b6b000 - 0x90baffe7  com.apple.Metadata 10.6.3 (507.10) <630494FA-3BB3-EDD3-E10B-8DAAF4831E26> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
0x90bf7000 - 0x90db1fe3  com.apple.ImageIO.framework 3.0.3 (3.0.3) <A93A514B-C1BF-21D0-FB03-CB775DE4FFAA> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO
0x90db2000 - 0x90dc3ff7  com.apple.LangAnalysis 1.6.6 (1.6.6) <97511CC7-FE23-5AC3-2EE2-B5479FAEB316> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis
0x90f5a000 - 0x90f5eff7  IOSurface ??? (???) <66E11D8E-CF4B-EFD0-37F9-20177C647021> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface
0x90fb9000 - 0x90ff6ff7  com.apple.SystemConfiguration 1.10.2 (1.10.2) <398BB007-41FD-1A30-26D8-CB86ED5E467E> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
0x90ff7000 - 0x91061fe7  libstdc++.6.dylib 7.9.0 (compatibility 7.0.0) <411D87F4-B7E1-44EB-F201-F8B4F9227213> /usr/lib/libstdc++.6.dylib
0x91062000 - 0x91084fef  com.apple.DirectoryService.Framework 3.6 (621.3) <BCB030BE-60E2-9AF3-80BE-CC090FCEA6F0> /System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryService
0x91085000 - 0x91088ffb  com.apple.help 1.3.1 (41) <EF92C648-2085-C085-8EA7-A1AF37AE94F4> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
0x910c8000 - 0x91123ff7  com.apple.framework.IOKit 2.0 (???) <A013B850-6ECB-594A-CBD6-DB156B11871B> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
0x91124000 - 0x911fffe7  com.apple.DesktopServices 1.5.7 (1.5.7) <A69072AD-C47E-A00D-4A69-6E46A7FB2119> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
0x91233000 - 0x91294fe7  com.apple.CoreText 3.1.0 (???) <F9E654F5-107E-8CED-2D6A-F5008A854A4D> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText
0x91295000 - 0x912a3ff7  com.apple.opengl 1.6.8 (1.6.8) <EBB7B411-60DD-DB9D-20C0-3E6258762EF0> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
0x912bd000 - 0x9135afe3  com.apple.LaunchServices 362.1 (362.1) <ED243C3B-9A16-A6CB-CA51-5924F48569DE> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
0x9137b000 - 0x913b3ff7  libcups.2.dylib 2.8.0 (compatibility 2.0.0) <76C02F5C-98FD-BD64-B5FB-C698FB76EA25> /usr/lib/libcups.2.dylib
0x913bb000 - 0x913bdff7  com.apple.securityhi 4.0 (36638) <38D36D4D-C798-6ACE-5FA8-5C001993AD6B> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
0x913be000 - 0x913d2ffb  com.apple.speech.synthesis.framework 3.10.35 (3.10.35) <0DBE17D5-17A2-8A0E-8572-5A78408B41C9> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
0x913d3000 - 0x9146bfe7  edu.mit.Kerberos 6.5.10 (6.5.10) <8B83AFF3-C074-E47C-4BD0-4546EED0D1BC> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
0x9146c000 - 0x914eeffb  SecurityFoundation ??? (???) <3670AE8B-06DA-C447-EB14-79423DB9C474> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
0x9151b000 - 0x915c8fe7  libobjc.A.dylib 227.0.0 (compatibility 1.0.0) <22CD62D4-9E7D-C31A-F585-FCEF1FE4C39A> /usr/lib/libobjc.A.dylib
0x91673000 - 0x918e3ffb  com.apple.Foundation 6.6.3 (751.29) <E77D3906-99F4-FEF4-FBB0-86FB3C94073E> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x918e4000 - 0x91915ff7  libGLImage.dylib ??? (???) <B45EA17E-03EF-3575-0843-A1205F29E71E> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
0x91916000 - 0x9193cfff  com.apple.DictionaryServices 1.1.1 (1.1.1) <00C1B034-5AE7-996C-CDD3-5A21DA1DBAC9> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
0x91974000 - 0x91993ff7  com.apple.CoreVideo 1.6.1 (45.5) <2FB7F93F-39C8-6ACE-EDFD-C843965842CD> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
0x91994000 - 0x91998ff7  libGIF.dylib ??? (???) <3ECD4D2C-40FE-E9A0-A2D2-E36D1C00D3A8> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
0x91999000 - 0x919abff7  com.apple.MultitouchSupport.framework 204.13 (204.13) <F91A4E32-01AA-49DB-2205-3DBE1FEFFC43> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport
0x91af8000 - 0x91b0dfff  com.apple.ImageCapture 6.0 (6.0) <0E86F45E-E656-9015-7AD4-A2C5F8D8A2FA> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture
0x91b0e000 - 0x91b18fe7  com.apple.audio.SoundManager 3.9.3 (3.9.3) <5F494955-7290-2D91-DA94-44B590191771> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CarbonSound.framework/Versions/A/CarbonSound
0x928bc000 - 0x92975fe7  libsqlite3.dylib 9.6.0 (compatibility 9.0.0) <16CEF8E8-8C9A-94CD-EF5D-05477844C005> /usr/lib/libsqlite3.dylib
0x92a89000 - 0x92e9fff7  libBLAS.dylib 219.0.0 (compatibility 1.0.0) <C4FB303A-DB4D-F9E8-181C-129585E59603> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
0x92fa5000 - 0x9311ffe3  com.apple.CoreFoundation 6.6.3 (550.29) <00373783-3744-F47D-2191-BEEA658F0C3D> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x9314a000 - 0x9314aff7  com.apple.CoreServices 44 (44) <AC35D112-5FB9-9C8C-6189-5F5945072375> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
0x932ac000 - 0x932b0ff7  libGFXShared.dylib ??? (???) <B6028E64-3F3B-C637-DA04-D0CD528F6E1F> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib
0x932b1000 - 0x932c1ff7  libsasl2.2.dylib 3.15.0 (compatibility 3.0.0) <C8744EA3-0AB7-CD03-E639-C4F2B910BE5D> /usr/lib/libsasl2.2.dylib
0x932c2000 - 0x932d6fe7  libbsm.0.dylib ??? (???) <821E415B-6C42-D359-78FF-E892792F8C52> /usr/lib/libbsm.0.dylib
0x932e3000 - 0x932e3ff7  com.apple.Accelerate 1.6 (Accelerate 1.6) <BC501C9F-7C20-961A-B135-0A457667D03C> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
0x932e4000 - 0x932e7fe7  libmathCommon.A.dylib 315.0.0 (compatibility 1.0.0) <1622A54F-1A98-2CBE-B6A4-2122981A500E> /usr/lib/system/libmathCommon.A.dylib
0x932f0000 - 0x93614fef  com.apple.HIToolbox 1.6.3 (???) <0A5F56E2-9AF3-728D-70AE-429522AEAD8A> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
0x93657000 - 0x93721fef  com.apple.CoreServices.OSServices 357 (357) <CF9530AD-F581-B831-09B6-16D9F9283BFA> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
0x93822000 - 0x93864ff7  libvDSP.dylib 268.0.1 (compatibility 1.0.0) <EF769BD0-63B6-B65D-FA54-8F2354CAD865> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
0x93865000 - 0x9386aff7  com.apple.OpenDirectory 10.6 (10.6) <92582807-E8F3-3DD9-EB42-4195CFB754A1> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
0x9386b000 - 0x93977ff7  libGLProgrammability.dylib ??? (???) <23AB2443-1DB3-3BFE-38A6-11F0BE453989> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib
0x93978000 - 0x93978ff7  com.apple.vecLib 3.6 (vecLib 3.6) <7362077A-890F-3AEF-A8AB-22247B10E106> /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib
0x939ae000 - 0x93a56ffb  com.apple.QD 3.35 (???) <37854644-864D-A3F2-7116-89F2F28E1CA4> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
0x93b06000 - 0x93b6affb  com.apple.htmlrendering 72 (1.1.4) <4D451A35-FAB6-1288-71F6-F24A4B6E2371> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering
0x93be7000 - 0x93c97ff3  com.apple.ColorSync 4.6.3 (4.6.3) <AA1076EA-7665-3005-A837-B661260DBE54> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync
0x93cbf000 - 0x93ccdfe7  libz.1.dylib 1.2.3 (compatibility 1.0.0) <3CE8AA79-F077-F1B0-A039-9103A4A02E92> /usr/lib/libz.1.dylib
0x93d1f000 - 0x93d9ffeb  com.apple.SearchKit 1.3.0 (1.3.0) <2F5DE102-A203-7905-7D12-FCBCF17BAEF8> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
0x94287000 - 0x942a3fe3  com.apple.openscripting 1.3.1 (???) <480D41B6-F98E-8E21-CA3C-4CA6A9752D3D> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
0x943ea000 - 0x943ebff7  com.apple.audio.units.AudioUnit 1.6.3 (1.6.3) <F3872A43-6157-098D-F9DD-210187B95FD3> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
0x943ec000 - 0x943f3ff3  com.apple.print.framework.Print 6.1 (237.1) <9758733E-7FBB-29CF-04F3-0D6D6B4C6A78> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
0x943f4000 - 0x9459afeb  libSystem.B.dylib 125.2.0 (compatibility 1.0.0) <3441F338-2218-6D36-3F95-3A16FBF6713D> /usr/lib/libSystem.B.dylib
0x9459b000 - 0x945deff7  com.apple.NavigationServices 3.5.4 (182) <ED268D94-E544-5548-AA59-7EC70DCB5EE4> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/NavigationServices.framework/Versions/A/NavigationServices
0x94610000 - 0x94612ff7  libRadiance.dylib ??? (???) <AB06F616-E3EA-5966-029A-8AA44BBE5B28> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
0x94949000 - 0x94992fe7  libTIFF.dylib ??? (???) <9CFF48CC-4852-4D06-17AC-3C947C824159> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
0x94a96000 - 0x94cf9fef  com.apple.security 6.1.1 (37594) <8AE73F5F-936C-80F6-B05B-A50C3082569C> /System/Library/Frameworks/Security.framework/Versions/A/Security
0x94cfa000 - 0x94d47feb  com.apple.DirectoryService.PasswordServerFramework 6.0 (6.0) <E2632F3E-6B5C-2E92-CD11-15BC0CE109CA> /System/Library/PrivateFrameworks/PasswordServer.framework/Versions/A/PasswordServer
0x94d48000 - 0x94d68fe7  libresolv.9.dylib 41.0.0 (compatibility 1.0.0) <751955F3-21FB-A03A-4E92-1F3D4EFB8C5B> /usr/lib/libresolv.9.dylib
0x94d69000 - 0x94dacff7  libGLU.dylib ??? (???) <B50572FF-3EAC-FD98-1A01-6B718D98F67F> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
0x95a9b000 - 0x95aa5ffb  com.apple.speech.recognition.framework 3.11.1 (3.11.1) <6E3481DF-645E-6095-0CD7-9BEBEC2ED9D1> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
0x95adf000 - 0x95b12ff7  com.apple.AE 496.4 (496.4) <582F5E9D-1B8E-6D03-EBB8-AA85F66253E2> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
0x95b53000 - 0x95be5fe3  com.apple.print.framework.PrintCore 6.2 (312.5) <2A8801E6-6D9F-68F5-947D-A1D68BE4F876> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
0x95be6000 - 0x95be6ff7  com.apple.Carbon 150 (152) <9252D5F2-462D-2C15-80F3-109644D6F704> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
0x95c29000 - 0x95d06ff7  com.apple.vImage 4.0 (4.0) <64597E4B-F144-DBB3-F428-0EC3D9A1219E> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
0x95d07000 - 0x95d12ff7  libGL.dylib ??? (???) <B87E0676-F5EF-8DA3-6DEE-13C43B3832A7> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
0x95d13000 - 0x95d37ff7  libJPEG.dylib ??? (???) <5CE96981-6B2A-D15B-4A17-E7BD329095B6> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
0x95e37000 - 0x9619fff7  com.apple.QuartzCore 1.6.2 (227.22) <4288F0D2-0C87-F054-C372-8764B44DE024> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
0x966a7000 - 0x966a8ff7  com.apple.TrustEvaluationAgent 1.1 (1) <07E7D892-5054-23A8-7144-3F19D3BFD48F> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent
0x966dc000 - 0x966e2fff  com.apple.CommonPanels 1.2.4 (91) <2438AF5D-067B-B9FD-1248-2C9987F360BA> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels
0x96a03000 - 0x96aacff7  com.apple.CFNetwork 454.9.7 (454.9.7) <B740E1BD-01B7-34C2-2A9A-6DBC68B1EA5B> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
0x96aad000 - 0x96b5bff3  com.apple.ink.framework 1.3.3 (107) <0AFEBD7C-D83C-7847-C075-9B427505F7F0> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
0x97aae000 - 0x97abaff7  libkxld.dylib ??? (???) <322A4B52-8305-3081-6B74-813C3A87A56D> /usr/lib/system/libkxld.dylib
0x97abb000 - 0x97ac4ff7  com.apple.DiskArbitration 2.3 (2.3) <E9C40767-DA6A-6CCB-8B00-2D5706753000> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
0x97ade000 - 0x97b22ff3  com.apple.coreui 2 (114) <E6096C79-94B0-730E-6070-3AE93B5678FE> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
0x97b23000 - 0x97e43feb  com.apple.CoreServices.CarbonCore 861.13 (861.13) <52803668-3669-36BD-57DD-078FBA835081> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
0x97e44000 - 0x98279ff7  libLAPACK.dylib 219.0.0 (compatibility 1.0.0) <5E2D2283-57DE-9A49-1DB0-CD027FEFA6C2> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
0x9827a000 - 0x983a6fff  com.apple.audio.toolbox.AudioToolbox 1.6.3 (1.6.3) <B9469F98-E349-3C27-86C4-B99AD178FDF1> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
0x9852e000 - 0x98620ff7  libcrypto.0.9.8.dylib 0.9.8 (compatibility 0.9.8) <D2C86308-F998-C83D-F49B-CD484D4EFE6A> /usr/lib/libcrypto.0.9.8.dylib
0x98854000 - 0x988a5ff7  com.apple.HIServices 1.8.0 (???) <BE4D9BC1-B527-D416-F4EB-FFB66EDA5DBB> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
0x989e2000 - 0x989efff7  com.apple.NetFS 3.2.1 (3.2.1) <E483137C-8239-E4DE-821C-05A9C22726AB> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
0x98a64000 - 0x98be6fe7  libicucore.A.dylib 40.0.0 (compatibility 1.0.0) <2314BD12-0821-75BB-F3BC-98D324CFD30A> /usr/lib/libicucore.A.dylib
0x98be7000 - 0x98c56ff7  libvMisc.dylib 268.0.1 (compatibility 1.0.0) <5C3D7DA5-29EB-A745-E32B-26DBF547D532> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
0x98c57000 - 0x98cf2ff7  com.apple.ApplicationServices.ATS 4.3 (???) <7ECA252B-5F67-2816-A4F0-73E1DC833728> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
0x98cf3000 - 0x994e2557  com.apple.CoreGraphics 1.543.50 (???) <74533178-5C90-0F54-1B06-2E1C5251ED5D> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
0x99501000 - 0x99501ff7  com.apple.Accelerate.vecLib 3.6 (vecLib 3.6) <1DEC639C-173D-F808-DE0D-4070CC6F5BC7> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
0x996a9000 - 0x996c4ff7  libPng.dylib ??? (???) <36A3D75E-5178-4358-7F02-444E276D61AD> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
0x998cc000 - 0x998f4ff7  libxslt.1.dylib 3.24.0 (compatibility 3.0.0) <769EF4B2-C1AD-73D5-AAAD-1564DAEA77AF> /usr/lib/libxslt.1.dylib
0x998f5000 - 0x99945ff7  com.apple.framework.familycontrols 2.0.1 (2010) <B9762E20-543D-13B9-F6BF-E8585F04CA01> /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls
0xffff0000 - 0xffff1fff  libSystem.B.dylib ??? (???) <3441F338-2218-6D36-3F95-3A16FBF6713D> /usr/lib/libSystem.B.dylib

Model: MacBookPro6,2, BootROM MBP61.0057.B09, 2 processors, Intel Core i7, 2.66 GHz, 8 GB, SMC 1.58f16
Graphics: NVIDIA GeForce GT 330M, NVIDIA GeForce GT 330M, PCIe, 512 MB
Graphics: Intel HD Graphics, Intel HD Graphics, Built-In, 288 MB
Memory Module: global_name
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x93), Broadcom BCM43xx 1.0 (5.10.131.16.1)
Bluetooth: Version 2.3.3f8, 2 service, 12 devices, 1 incoming serial ports
Network Service: AirPort, AirPort, en1
Serial ATA Device: Hitachi HTS545050B9SA02, 465.76 GB
Serial ATA Device: MATSHITADVD-R   UJ-898
USB Device: Hub, 0x0424  (SMSC), 0x2514, 0xfa100000
USB Device: Apple Internal Keyboard / Trackpad, 0x05ac  (Apple Inc.), 0x0236, 0xfa120000
USB Device: BRCM2070 Hub, 0x0a5c  (Broadcom Corp.), 0x4500, 0xfa110000
USB Device: Bluetooth USB Host Controller, 0x05ac  (Apple Inc.), 0x8218, 0xfa113000
USB Device: Internal Memory Card Reader, 0x05ac  (Apple Inc.), 0x8403, 0xfa130000
USB Device: Hub, 0x0424  (SMSC), 0x2514, 0xfd100000
USB Device: Built-in iSight, 0x05ac  (Apple Inc.), 0x8507, 0xfd110000
USB Device: IR Receiver, 0x05ac  (Apple Inc.), 0x8242, 0xfd120000

----------
assignee: ronaldoussoren
components: Macintosh
messages: 111851
nosy: ronaldoussoren, zzzeek
priority: normal
severity: normal
status: open
title: crash when calling urllib.getproxies() under OSX with subprocess / particular memory usage
type: crash
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Jul 28 23:31:07 2010
From: report at bugs.python.org (James Tatum)
Date: Wed, 28 Jul 2010 21:31:07 +0000
Subject: [New-bugs-announce] [issue9406] ConfigParser exceptions do not
	subclass StandardError
In-Reply-To: <1280352667.98.0.230915344385.issue9406@psf.upfronthosting.co.za>
Message-ID: <1280352667.98.0.230915344385.issue9406@psf.upfronthosting.co.za>


New submission from James Tatum <jtatum at gmail.com>:

ConfigParser defines a number of exception classes which all ultimately derive from ConfigParser.Error. ConfigParser.Error, however, only derives from Exception. These should all derive from StandardError.

----------
components: Library (Lib)
files: ConfigParser.StandardError.patch
keywords: patch
messages: 111852
nosy: jtatum
priority: normal
severity: normal
status: open
title: ConfigParser exceptions do not subclass StandardError
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file18237/ConfigParser.StandardError.patch

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

From martin at v.loewis.de  Wed Jul 28 23:39:22 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 28 Jul 2010 23:39:22 +0200
Subject: [New-bugs-announce] [issue9404] IDLE won't launch on XP
In-Reply-To: <1280352480.94.0.617351160567.issue9404@psf.upfronthosting.co.za>
References: <1280352480.94.0.617351160567.issue9404@psf.upfronthosting.co.za>
Message-ID: <4C50A38A.6030303@v.loewis.de>

> I have tried to use Explorer to reach the files and I get a
> permission error (the same occurs when trying to reach with the
> command prompt). I have tried to change the read only nature of this
> folder and it automatically reverts after the attribute is set. Also
> the folder is empty according to explorer. I have tried running it
> with my firewall disabled.

As a work-around, remove the hidden flag from the idlerc folder and
all of its files.

From report at bugs.python.org  Thu Jul 29 00:49:27 2010
From: report at bugs.python.org (Andrew Wu)
Date: Wed, 28 Jul 2010 22:49:27 +0000
Subject: [New-bugs-announce] [issue9407] ConfigParser documentation does not
	mention	ConfigParser.Error as base exception class for
	ConfigParser exceptions
In-Reply-To: <1280357367.5.0.752576251051.issue9407@psf.upfronthosting.co.za>
Message-ID: <1280357367.5.0.752576251051.issue9407@psf.upfronthosting.co.za>


New submission from Andrew Wu <andrewwu at gmail.com>:

* Reference bug http://bugs.python.org/issue9406
* Reference documentation at http://docs.python.org/library/configparser.html

The docs list all the specific errors to look out for, but does not mention the base exception class for ConfigParser errors (ConfigParser.Error).  It may be useful to mention it to show the exception heirarchy as well as in the case a user may want to catch all ConfigParser errors generally.

----------
assignee: docs at python
components: Documentation
messages: 111866
nosy: docs at python, pekkle
priority: normal
severity: normal
status: open
title: ConfigParser documentation does not mention ConfigParser.Error as base exception class for ConfigParser exceptions
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Thu Jul 29 01:49:52 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Jul 2010 23:49:52 +0000
Subject: [New-bugs-announce] [issue9408] curses: Link against libncursesw
	instead of libncurses
In-Reply-To: <1280360992.02.0.384889308435.issue9408@psf.upfronthosting.co.za>
Message-ID: <1280360992.02.0.384889308435.issue9408@psf.upfronthosting.co.za>


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

Because of #7384, Python3 now links _curses.so to ncurses library (bytes version) instead of ncursesw library (unicode version) if readline is linked to ncurses. I'm using Linux (Debian Sid).

On Linux, Python3 should maybe only link to the unicode version, because the bytes version has many issues with unicode and lacks many functions.

See also:
 - #1428494: "Prefer linking against ncursesw over ncurses library" (so I consider this issue as a regression).
 - #4787

(reuse the nosy list from #7384)

----------
components: Library (Lib), Unicode
messages: 111875
nosy: Arfrever, akuchling, asmodai, haypo, mark.dickinson, r.david.murray, rpetrov, skrah
priority: normal
severity: normal
status: open
title: curses: Link against libncursesw instead of libncurses
versions: Python 3.2

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

From report at bugs.python.org  Thu Jul 29 03:24:07 2010
From: report at bugs.python.org (Hugo Lopes Tavares)
Date: Thu, 29 Jul 2010 01:24:07 +0000
Subject: [New-bugs-announce] [issue9409] doctest in python2.7 can't handle
	non-ascii characters
In-Reply-To: <1280366647.79.0.277931146737.issue9409@psf.upfronthosting.co.za>
Message-ID: <1280366647.79.0.277931146737.issue9409@psf.upfronthosting.co.za>


New submission from Hugo Lopes Tavares <hltbra at gmail.com>:

When trying to run my test suite I had a problem with python2.7. My suite ran 100% in Python2.4, Python2.5, Python2.6 and Python3.2a0, so I thought it would be a kind of doctest flaw.

Taking a look at the code, there is the following in doctest.py:1331:

            source = example.source.encode('ascii', 'backslashreplace')

The problem is that my doctest file had non-ascii files and I got trouble.

hugo at hugo-laptop:~/issue$ python2.7 example.py 
non-ascii.txt
Doctest: non-ascii.txt ... ok
ascii.txt
Doctest: ascii.txt ... ERROR

======================================================================
ERROR: ascii.txt
Doctest: ascii.txt
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/doctest.py", line 2148, in runTest
    test, out=new.write, clear_globs=False)
  File "/usr/local/lib/python2.7/doctest.py", line 1382, in run
    return self.__run(test, compileflags, out)
  File "/usr/local/lib/python2.7/doctest.py", line 1272, in __run
    got += _exception_traceback(exc_info)
  File "/usr/local/lib/python2.7/doctest.py", line 244, in _exception_traceback
    traceback.print_exception(exc_type, exc_val, exc_tb, file=excout)
  File "/usr/local/lib/python2.7/traceback.py", line 125, in print_exception
    print_tb(tb, limit, file)
  File "/usr/local/lib/python2.7/traceback.py", line 69, in print_tb
    line = linecache.getline(filename, lineno, f.f_globals)
  File "/usr/local/lib/python2.7/linecache.py", line 14, in getline
    lines = getlines(filename, module_globals)
  File "/usr/local/lib/python2.7/doctest.py", line 1331, in __patched_linecache_getlines
    source = example.source.encode('ascii', 'backslashreplace')
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 19: ordinal not in range(128)

----------------------------------------------------------------------
Ran 2 tests in 0.006s

FAILED (errors=1)
hugo at hugo-laptop:~/issue$ 


Taking an inner look at doctest.py in python2.6 and python2.7 I realized there is another inconsistency with filenames in both (I was lucky to try at first a filename that doesn't match the regex):

    __LINECACHE_FILENAME_RE = re.compile(r'<doctest '
                                         r'(?P<name>[\w\.]+)'
                                         r'\[(?P<examplenum>\d+)\]>$')

Well, <name> is the file name, but filenames are not only composed of alphanums and dots. Maybe it should be slightly different, like:

    __LINECACHE_FILENAME_RE = re.compile(r'<doctest '
                                         r'(?P<name>.+?)'
                                         r'\[(?P<examplenum>\d+)\]>$', re.UNICODE)

Because we can have several kinds of names. But it is not the top of the iceberg, anyaway.

To solve my problem, I propose moving back that first snippet to how it was in python2.6. The diff would be:

--- /usr/local/lib/python2.7/doctest.py	2010-07-28 22:07:01.272234398 -0300
+++ doctest.py	2010-07-28 22:20:42.000000000 -0300
@@ -1328,8 +1328,7 @@
         m = self.__LINECACHE_FILENAME_RE.match(filename)
         if m and m.group('name') == self.test.name:
             example = self.test.examples[int(m.group('examplenum'))]
-            source = example.source.encode('ascii', 'backslashreplace')
-            return source.splitlines(True)
+            return example.source.splitlines(True)
         else:
             return self.save_linecache_getlines(filename, module_globals)

----------
files: ascii.txt
messages: 111881
nosy: hugo
priority: normal
severity: normal
status: open
title: doctest in python2.7 can't handle non-ascii characters
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file18242/ascii.txt

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

From report at bugs.python.org  Thu Jul 29 08:26:07 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 29 Jul 2010 06:26:07 +0000
Subject: [New-bugs-announce] [issue9410] Add Unladden Swallow's
	optimizations to Python 3's pickle.
In-Reply-To: <1280384767.75.0.12386540434.issue9410@psf.upfronthosting.co.za>
Message-ID: <1280384767.75.0.12386540434.issue9410@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti <alexandre at peadrop.com>:

This is a big patch. Please review at http://codereview.appspot.com/1694050/show

This patch adds the most interesting optimizations from Unladen Swallow to Python 3's pickle.

The core of the patch already been reviewed by Antoine and me (http://codereview.appspot.com/33070/show). One of the last issue remaining the unbounded size of the internal buffer. This shouldn't be a big issue for most uses of pickle, since the size of a  pickle is often several times smaller than the object hierarchy that created it. I still hope to fix this in a following patch.

The patch also include additional cleanups to the Pdata structure. The changes felt natural to make along with the other changes from Unladen Swallow. IIRC, these changes yield an additional 1-3% speedup.

----------
assignee: alexandre.vassalotti
components: Extension Modules
files: pickle_optimizations.diff
keywords: patch
messages: 111895
nosy: alexandre.vassalotti, belopolsky, collinwinter, haypo, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Add Unladden Swallow's optimizations to Python 3's pickle.
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file18246/pickle_optimizations.diff

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

From report at bugs.python.org  Thu Jul 29 10:08:20 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 29 Jul 2010 08:08:20 +0000
Subject: [New-bugs-announce] [issue9411] configparser doesn't support
	specifying encoding in read()
In-Reply-To: <1280390900.93.0.0125296662028.issue9411@psf.upfronthosting.co.za>
Message-ID: <1280390900.93.0.0125296662028.issue9411@psf.upfronthosting.co.za>


New submission from ?ukasz Langa <lukasz at langa.pl>:

By default, configparser classes simply `open()` and `read()` files specified in the list passed to `.read()`. This means these calls use the default platform-specific encoding and this is prone to breakage.

An existing solution is to use `readfp()` and pass files one by one to it, handling opening them with a specific encoding manually. This is needlessly complex as it increases the amount of boilerplate needed.

Please find attached a patch where I've added an `encoding=` argument to the `read()` method. By default it chooses `sys.getdefaultencoding()` so the behaviour is backwards compatible. We might consider switching that to 'UTF-8' but there are many INI files from the Windows land encoded in Windows specific codepages.

Anyway, the currently proposed implementation is compatible and enables specifying an `encoding` explicitly. The patch includes a new unit test and some minor fixes for behaviour exposed by this test.

----------
files: cfgparser.3
messages: 111899
nosy: brian.curtin, ezio.melotti, georg.brandl, lukasz.langa, michael.foord
priority: normal
severity: normal
status: open
title: configparser doesn't support specifying encoding in read()
Added file: http://bugs.python.org/file18247/cfgparser.3

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

From report at bugs.python.org  Thu Jul 29 11:02:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Jul 2010 09:02:32 +0000
Subject: [New-bugs-announce] [issue9412] test_smtpd leaks references
In-Reply-To: <1280394152.03.0.913816495774.issue9412@psf.upfronthosting.co.za>
Message-ID: <1280394152.03.0.913816495774.issue9412@psf.upfronthosting.co.za>


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

See http://mail.python.org/pipermail/python-checkins/2010-July/095648.html

test_smtpd leaked [25, 25, 25] references, sum=75

----------
assignee: richard
components: Library (Lib)
messages: 111901
nosy: giampaolo.rodola, pitrou, richard
priority: high
severity: normal
status: open
title: test_smtpd leaks references
type: resource usage
versions: Python 3.2

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

From report at bugs.python.org  Thu Jul 29 12:55:21 2010
From: report at bugs.python.org (me myself)
Date: Thu, 29 Jul 2010 10:55:21 +0000
Subject: [New-bugs-announce] [issue9413] asyncore.close_all() should call
	x.handle_close() instead	of x.close()
In-Reply-To: <1280400921.75.0.874188585283.issue9413@psf.upfronthosting.co.za>
Message-ID: <1280400921.75.0.874188585283.issue9413@psf.upfronthosting.co.za>


New submission from me myself <me.myself at mailinator.com>:

Title says it all.

----------
messages: 111908
nosy: me.myself
priority: normal
severity: normal
status: open
title: asyncore.close_all() should call x.handle_close() instead of x.close()
type: behavior
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Thu Jul 29 13:09:18 2010
From: report at bugs.python.org (gnuthor)
Date: Thu, 29 Jul 2010 11:09:18 +0000
Subject: [New-bugs-announce] [issue9414] infinite loop with specific regexp
In-Reply-To: <1280401758.9.0.252357713623.issue9414@psf.upfronthosting.co.za>
Message-ID: <1280401758.9.0.252357713623.issue9414@psf.upfronthosting.co.za>


New submission from gnuthor <jacob at internet24.de>:

The follow code hangs on vanilla compile python 2.7 on Ubuntu 10.04 x86_64 and all other versions of Python that I could find (i386/x86_64, 2.6.5/2.5.2/2.2):

>>> import re
>>> regex = re.compile(r'^((?:\.\d+)+|(?:\.?\w+(?:\-*\w+)+)+)\.(\d*?)$')
>>> match = regex.match('lldpLocChassisIdSubtype')
<infinite loop or possibly exponential time>

the regex is taken from file client.py of libsnmp-python ( version 5.4.2.1 ~dfsg0ubuntu1-0ubuntu2.1 in Ubuntu 10.04 )

libsnmp-python ( 5.4.1~dfsg-12  in Debian Lenny) contains
a previous version of this regex which does not produce an infinite loop

>>> regex = re.compile(r'^((?:\.\d+)+|(?:\.?\w+(?:\-*\w+)+)+)\.?(.*)$')
>>> match = regex.match('lldpLocChassisIdSubtype')
>>> print match
<_sre.SRE_Match object at 0x7f5d2abebc68>


Perl 5.10.1 can run both of the regular expressions without problems

$ perl -e '$x="lldpLocChassisIdSubtype"; print "$1" if $x =~ m/^((?:\.\d+)+|(?:\.?\w+(?:\-*\w+)+)+)\.(\d*?)$/;'
$ perl -e '$x="lldpLocChassisIdSubtype"; print "$1" if $x =~ m/^((?:\.\d+)+|(?:\.?\w+(?:\-*\w+)+)+)\.?(.*)$/;'
lldpLocChassisIdSubtype

I realise that these two regular expression might not particularly sensible and are certainly not equivalent semantically, but they are syntactically correct, as far as I can tell, and do not contain back references etc. and thus the matching process should be able to always
terminate.

----------
components: Regular Expressions
messages: 111909
nosy: gnuthor
priority: normal
severity: normal
status: open
title: infinite loop with specific regexp
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Jul 29 13:33:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Jul 2010 11:33:39 +0000
Subject: [New-bugs-announce] [issue9415] SSL issues on "Ubuntu i386"
	buildbots
In-Reply-To: <1280403219.86.0.90888491207.issue9415@psf.upfronthosting.co.za>
Message-ID: <1280403219.86.0.90888491207.issue9415@psf.upfronthosting.co.za>


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

The buildslaves "i386 Ubuntu" have been exhibiting some strange behaviour for some time now:

======================================================================
ERROR: test_protocol_sslv2 (test.test_ssl.ThreadedTests)
Connecting to an SSLv2 server with various client options
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/scratch/pybot-buildarea/2.7.klose-ubuntu-i386/build/Lib/test/test_ssl.py", line 879, in test_protocol_sslv2
    try_protocol_combo(ssl.PROTOCOL_SSLv2, ssl.PROTOCOL_SSLv2, True)
  File "/scratch/pybot-buildarea/2.7.klose-ubuntu-i386/build/Lib/test/test_ssl.py", line 751, in try_protocol_combo
    ciphers="ALL", chatty=False)
  File "/scratch/pybot-buildarea/2.7.klose-ubuntu-i386/build/Lib/test/test_ssl.py", line 703, in server_params_test
    s.connect((HOST, server.port))
  File "/scratch/pybot-buildarea/2.7.klose-ubuntu-i386/build/Lib/ssl.py", line 295, in connect
    self.ca_certs, self.ciphers)
SSLError: _ssl.c:312: Invalid SSL protocol variant specified.

(http://www.python.org/dev/buildbot/builders/i386%20Ubuntu%202.7/builds/78/steps/test/logs/stdio)

======================================================================
ERROR: test_constructor (test.test_ssl.ContextTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/scratch/pybot-buildarea/3.x.klose-ubuntu-i386/build/Lib/test/test_ssl.py", line 179, in test_constructor
    ctx = ssl.SSLContext(ssl.PROTOCOL_SSLv2)
  File "/scratch/pybot-buildarea/3.x.klose-ubuntu-i386/build/Lib/ssl.py", line 96, in __new__
    return _SSLContext.__new__(cls, protocol)
ssl.SSLError: failed to allocate SSL context

(http://www.python.org/dev/buildbot/builders/i386%20Ubuntu%203.x/builds/1689/steps/test/logs/stdio)

Matthias, can you give us more information about the system setup on these buildbots? It seems its OpenSSL library refuses to allocate any SSL context for the SSL v2 protocol. Is it some kind of patch added by the Ubuntu OpenSSL maintainers in order to disable SSLv2 entirely?

----------
components: Tests
messages: 111911
nosy: doko, pitrou
priority: normal
severity: normal
status: open
title: SSL issues on "Ubuntu i386" buildbots
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Jul 29 15:41:16 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Jul 2010 13:41:16 +0000
Subject: [New-bugs-announce] [issue9416] complex formatting incorrectly
	omits a negative zero real	part
In-Reply-To: <1280410876.49.0.963700796596.issue9416@psf.upfronthosting.co.za>
Message-ID: <1280410876.49.0.963700796596.issue9416@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

>>> format(complex(-0.0, 2.0), '.10')   # expected '(-0+2j)'
'(+2j)'
>>> format(complex(-0.0, 2.0), '')      # gives expected result
'(-0+2j)'

----------
assignee: mark.dickinson
messages: 111923
nosy: eric.smith, mark.dickinson
priority: normal
severity: normal
stage: unit test needed
status: open
title: complex formatting incorrectly omits a negative zero real part
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Jul 29 16:19:45 2010
From: report at bugs.python.org (Andrea Corbellini)
Date: Thu, 29 Jul 2010 14:19:45 +0000
Subject: [New-bugs-announce] [issue9417] Declaring a class creates circular
	references
In-Reply-To: <1280413185.92.0.0897116981748.issue9417@psf.upfronthosting.co.za>
Message-ID: <1280413185.92.0.0897116981748.issue9417@psf.upfronthosting.co.za>


New submission from Andrea Corbellini <corbellini.andrea at gmail.com>:

Creating a class (either using the 'class' statement or using type()) creates a circular reference.

I've attached a script that simply demonstrates this. The problem is caused by the fact that MyClass.__dict__['__dict__'].__objclass__ is MyClass.

Although most of the times classes are never deleted when the interpreted exits, some programs (like the popular Django framework) create temporary classes. And this is a pain because you can't disable the garbage collector.

----------
components: Interpreter Core
files: test.py
messages: 111935
nosy: candrea
priority: normal
severity: normal
status: open
title: Declaring a class creates circular references
type: resource usage
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/file18251/test.py

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

From report at bugs.python.org  Thu Jul 29 17:21:39 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 29 Jul 2010 15:21:39 +0000
Subject: [New-bugs-announce] [issue9418] Move _formatter_* methods from
	string type into _string	module
In-Reply-To: <1280416899.1.0.0890176421306.issue9418@psf.upfronthosting.co.za>
Message-ID: <1280416899.1.0.0890176421306.issue9418@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

Currently, the string type has two single-underscore methods, _formatter_parser and _formatter_field_name_split, that expose details of the new string formatting implementation to Python, so that it can be used by the string.Formatter class.

This patch removes these methods and puts them into their own "_string" module.

----------
assignee: eric.smith
components: Extension Modules, Library (Lib)
files: add_string_module.diff
keywords: patch
messages: 111948
nosy: eric.smith, georg.brandl
priority: normal
severity: normal
stage: patch review
status: open
title: Move _formatter_* methods from string type into _string module
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file18253/add_string_module.diff

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

From report at bugs.python.org  Thu Jul 29 19:07:02 2010
From: report at bugs.python.org (=?utf-8?q?Peter_H=C3=A4ring?=)
Date: Thu, 29 Jul 2010 17:07:02 +0000
Subject: [New-bugs-announce] [issue9419] RUNSHARED needs LDFLAGS
In-Reply-To: <1280423222.23.0.51081739049.issue9419@psf.upfronthosting.co.za>
Message-ID: <1280423222.23.0.51081739049.issue9419@psf.upfronthosting.co.za>


New submission from Peter H?ring <p.haering at gmx.net>:

test_distutils fails with 2.7 on a shared build (at least if building outside the source tree), 2.6 versions work. The reason for this is, that the test tries to link and doesn't find libpython-2.7.so.1.

A solution (or workaround) is to add LDFLAGS=-L`pwd` to the variable RUNSHARED, as I did in the attached file for SUNOS and GNU/Linux etc. Other systems probably need some similar patch.

----------
components: Build
files: Python-2.7-RUNSHARED.patch
keywords: patch
messages: 111970
nosy: phaering
priority: normal
severity: normal
status: open
title: RUNSHARED needs LDFLAGS
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file18255/Python-2.7-RUNSHARED.patch

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

From report at bugs.python.org  Thu Jul 29 19:26:20 2010
From: report at bugs.python.org (=?utf-8?q?Peter_H=C3=A4ring?=)
Date: Thu, 29 Jul 2010 17:26:20 +0000
Subject: [New-bugs-announce] [issue9420] gdbm with /usr/include/ndbm.h
In-Reply-To: <1280424380.77.0.379026276123.issue9420@psf.upfronthosting.co.za>
Message-ID: <1280424380.77.0.379026276123.issue9420@psf.upfronthosting.co.za>


New submission from Peter H?ring <p.haering at gmx.net>:

There are systems out there, wich don't have ndbm, but gdbm and ndbm.h directly in the include-path (usually /usr/include), not in the subdirectory i.e. gdbm.

setup.py at the moment assumes, that there is ndbm on the system, if there is ndbm.h in the include path. If it doesn't find libndbm, it continues to try to use ndbm without library, which doesn't work.
BLFS (http://www.linuxfromscratch.org/blfs/view/svn/general/python.html) fills in the gdbm and gdbm-compat library, which works, but is wrong, because we really use gdbm and not ndbm.
The right way is to start with the library change and then look for the header file, as it is in the proposed patch for setup.py

----------
components: Build
files: Python-2.7-gdbm.patch
keywords: patch
messages: 111978
nosy: phaering
priority: normal
severity: normal
status: open
title: gdbm with /usr/include/ndbm.h
versions: Python 2.7
Added file: http://bugs.python.org/file18256/Python-2.7-gdbm.patch

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

From report at bugs.python.org  Thu Jul 29 20:32:49 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 29 Jul 2010 18:32:49 +0000
Subject: [New-bugs-announce] [issue9421] configparser.ConfigParser's getint,
	getboolean and getfloat don't accept `vars`
In-Reply-To: <1280428369.21.0.84678458473.issue9421@psf.upfronthosting.co.za>
Message-ID: <1280428369.21.0.84678458473.issue9421@psf.upfronthosting.co.za>


New submission from ?ukasz Langa <lukasz at langa.pl>:

ConfigParser (and in effect SafeConfigParser) accept `vars` in the `get()` method so one can override values from the section, merge data from different sources or simply state some required keys for interpolation.

`getint()`, `getfloat()` and `getboolean()` don't accept this argument and this is the reason for this issue: for all getters to present a consistent interface.

There is a small design question here however. We have an inheritance model in configparser that goes like this:

  RawConfigParser -> ConfigParser -> SafeConfigParser

ConfigParser redefines `get()` for the purposes of interpolation but doesn't touch the other getters. It's good because in terms of implementation, they are just `type()` decoration over `get()` where type is `int`, `float` or `bool`.

The obvious solution would be to add **kwargs to these getters so that regardless of the implementation of the actual `get()`, all possible values are being passed to it. We can then comment in the docstring that for possible values of **kwargs, the user should check the interface of `get()`. Is that good enough?

Other ideas?

PS. I have a patch for the proposed design, will attach if there's consensus.

----------
components: Library (Lib)
messages: 111986
nosy: georg.brandl, lukasz.langa, michael.foord, pitrou
priority: normal
severity: normal
status: open
title: configparser.ConfigParser's getint, getboolean and getfloat don't accept `vars`
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Jul 29 22:33:35 2010
From: report at bugs.python.org (Winston451)
Date: Thu, 29 Jul 2010 20:33:35 +0000
Subject: [New-bugs-announce] [issue9422] Memory leak when reinitializing a
	Struct object
In-Reply-To: <1280435615.43.0.80003916996.issue9422@psf.upfronthosting.co.za>
Message-ID: <1280435615.43.0.80003916996.issue9422@psf.upfronthosting.co.za>


New submission from Winston451 <montag451 at laposte.net>:

The s_init function of the _struct.c file does not free the s_codes field before storing a new address into it. So when a Struct object is reinitialized the memory block pointed to by s_codes is lost. The file attached with the bug report shows a code which reproduce the problem.

----------
components: Library (Lib)
files: leak.py
messages: 111995
nosy: Winston451
priority: normal
severity: normal
status: open
title: Memory leak when reinitializing a Struct object
type: resource usage
versions: Python 2.6
Added file: http://bugs.python.org/file18262/leak.py

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

From report at bugs.python.org  Fri Jul 30 01:09:07 2010
From: report at bugs.python.org (Lyle Ross)
Date: Thu, 29 Jul 2010 23:09:07 +0000
Subject: [New-bugs-announce] [issue9423] Error in urllib2.do_open(self,
	http_class, req)
In-Reply-To: <1280444947.69.0.433745373781.issue9423@psf.upfronthosting.co.za>
Message-ID: <1280444947.69.0.433745373781.issue9423@psf.upfronthosting.co.za>


New submission from Lyle Ross <lyle.ross at us-cert.gov>:

W:\Production Apps\PyLib>python ProxyHTTPConnection.py

W:\Production Apps\PyLib>set path=C:\Python26;C:\Perl\bin\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\
Wbem;;C:\Program Files\RSA Security\RSA Authentication Agent\Agenthost Autoreg Utility;C:\WINDOWS\system32\Win
dowsPowerShell\v1.0;C:\WINDOWS\system32\WindowsPowerShell\v1.0;C:\Program Files\TortoiseSVN\bin;W:\cmd;C:\Pyth
on26;C:\Program Files\Java\jdk1.6.0_20\bin;W:\Programs\nmake15;W:\Programs\GnuPG;C:\Cygwin\bin

W:\Production Apps\PyLib>python.exe -u ProxyHTTPConnection.py
Enter ProxyHTTPConnection :: __main__
  call opener = urllib2.build_opener( ConnectHTTPHandler( proxy = thunderchild.bronze.us-cert.gov ), ConnectHT
TPSHandler( proxy = thunderchild.bronze.us-cert.gov ) )
Enter ConnectHTTPHandler :: __init__
  call urllib2.HTTPHandler.__init__
Exit ConnectHTTPHandler :: __init__
Enter ConnectHTTPSHandler :: __init__
  call urllib2.HTTPSHandler.__init__
Exit ConnectHTTPSHandler :: __init__
  call urllib2.install_opener( opener )
  call req = urllib2.Request( url = https://portal.cymru.com/export/darknet_top10src_24h.txt )
  call req.set_proxy( thunderchild.bronze.us-cert.gov, https )
  f = call urllib2.urlopen( req )
Enter ConnectHTTPSHandler :: do_open
  call req.set_proxy( thunderchild.bronze.us-cert.gov, 'https' )
  rc = call urllib2.HTTPSHandler.do_open( self, ProxyHTTPSConnection, req )

Traceback (most recent call last):
  File "ProxyHTTPConnection.py", line 243, in <module>
    f      = urllib2.urlopen( req )
  File "C:\Python26\lib\urllib2.py", line 126, in urlopen
    return _opener.open(url, data, timeout)
  File "C:\Python26\lib\urllib2.py", line 391, in open
    response = self._open(req, data)
  File "C:\Python26\lib\urllib2.py", line 409, in _open
    '_open', req)
  File "C:\Python26\lib\urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "C:\Python26\lib\urllib2.py", line 1169, in https_open
    return self.do_open(httplib.HTTPSConnection, req)
  File "ProxyHTTPConnection.py", line 204, in do_open
    rc = urllib2.HTTPSHandler.do_open( self, ProxyHTTPSConnection, req )
  File "C:\Python26\lib\urllib2.py", line 1107, in do_open
    h = http_class(host, timeout=req.timeout) # will parse host:port
TypeError: __init__() got an unexpected keyword argument 'timeout'
Exit ProxyHTTPConnection :: __main__
W:\Production Apps\PyLib>

NOTE: the proxy server used in this test is behind our firewall. You must change the proxy server if you attempt to replicate this test in your system.

----------
components: Library (Lib)
files: ProxyHTTPConnection.py
messages: 112022
nosy: lyle.ross
priority: normal
severity: normal
status: open
title: Error in urllib2.do_open(self, http_class, req)
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file18265/ProxyHTTPConnection.py

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

From report at bugs.python.org  Fri Jul 30 02:05:52 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 30 Jul 2010 00:05:52 +0000
Subject: [New-bugs-announce] [issue9424] deprecate
	unittest.TestCase.assertEquals
In-Reply-To: <1280448352.86.0.380978086896.issue9424@psf.upfronthosting.co.za>
Message-ID: <1280448352.86.0.380978086896.issue9424@psf.upfronthosting.co.za>


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

Now that deprecations are silent by default it would be much less intrusive to deprecate unittest.TestCase.assertEqual

We have a persistent issue in the Python test suite of developers using assertEquals when we have standardised on assertEqual. In regrtest we could patch TestCase.assertEquals to raise a (hopefully helpful) error. That'll stop the blighters!

----------
assignee: ezio.melotti
messages: 112025
nosy: ezio.melotti, michael.foord
priority: normal
severity: normal
status: open
title: deprecate unittest.TestCase.assertEquals
versions: Python 3.2

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

From report at bugs.python.org  Fri Jul 30 02:13:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Jul 2010 00:13:34 +0000
Subject: [New-bugs-announce] [issue9425] Rewrite import machinery to work
	with unicode paths
In-Reply-To: <1280448814.73.0.312881779361.issue9425@psf.upfronthosting.co.za>
Message-ID: <1280448814.73.0.312881779361.issue9425@psf.upfronthosting.co.za>


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

Python (2 and 3) is unable to load a module installed in a directory containing characters not encodable to the locale encoding. And Python doesn't work if it's installed in non-ASCII directory on Windows or with a locale encoding different than UTF-8. On Windows, the locale encoding is "mbcs", which is a small charset, unable to mix different languages, whereas the file system is fully unicode compatible (it uses UTF-16). Python should work with unicode strings (wchar_t*, Py_UNICODE* or PyUnicodeObject) instead of byte strings (char* or PyBytesObject), especially while loading a Python module.

It's not an easy task because it requires to change a lot of code, especially in Python/import.c. I am working on this topic since some months and I have now a working patch. It's now possible to run Python from the source tree containing a non-ASCII character in C locale (ASCII encoding). Except just a minor bug in test_gdb, all tests of the test suite pass.

I posted the whole patch on Rietveld for a review:
http://codereview.appspot.com/1874048

The patch is huge because it fixes different things:

 a) import machinery (import.c, getpath.c, importdl.c, ...)
 b) many error handlers using filenames (compile.c, errors.c, _warnings.c, sysmodule.c, ...)
 c) functions using filenames, especially Python full path: log the filename (eg. Lib/distutils/file_util.py), filename written to a program output (eg. Lib/platform.py)
 d) tests (Lib/test/test_*.py)

(b), (c) and (d) can be fixed before/without (a). But (a) requires other parts to work correctly.

If it's not possible to review the patch, I can try to split it in smaller parts.

--

Related issues:

 #3080: Full unicode import system
 #4352: imp.find_module() fails with a UnicodeDecodeError 
        when called with non-ASCII search paths
 #8611: Python3 doesn't support locale different than utf8 
        and an non-ASCII path (POSIX)
 #8988: import + coding = failure (3.1.2/win32)

--

See also my email sent to python-dev for more information:
http://mail.python.org/pipermail/python-dev/2010-July/101619.html

----------
components: Interpreter Core, Unicode
messages: 112026
nosy: haypo
priority: normal
severity: normal
status: open
title: Rewrite import machinery to work with unicode paths
versions: Python 3.2

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

From report at bugs.python.org  Fri Jul 30 10:34:16 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 30 Jul 2010 08:34:16 +0000
Subject: [New-bugs-announce] [issue9426] Explicitly state lack of support
	for keyword arguments in	builtin functions
In-Reply-To: <1280478856.92.0.712905377204.issue9426@psf.upfronthosting.co.za>
Message-ID: <1280478856.92.0.712905377204.issue9426@psf.upfronthosting.co.za>


New submission from ?ukasz Langa <lukasz at langa.pl>:

Currently it's somewhat surprising that while the documentation often states the default values for certain builtins, invoking the builtin with keyword arguments as described in the documentation does not work.

Original discussion: #7447

I'm going through all builtins to see how the keyword arg support looks and I'm going to present a patch for Doc/library/builtins.rst that explicitly states that builtins don't support this kind of invocation.

Expect a patch later today.

----------
assignee: docs at python
components: Documentation
messages: 112048
nosy: docs at python, lukasz.langa, tjreedy
priority: normal
severity: normal
status: open
title: Explicitly state lack of support for keyword arguments in builtin functions
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Jul 30 13:25:48 2010
From: report at bugs.python.org (Thomas Guettler)
Date: Fri, 30 Jul 2010 11:25:48 +0000
Subject: [New-bugs-announce] [issue9427] logging.error('...',
	exc_info=True) should display upper frames, too
In-Reply-To: <1280489148.4.0.967800282636.issue9427@psf.upfronthosting.co.za>
Message-ID: <1280489148.4.0.967800282636.issue9427@psf.upfronthosting.co.za>


New submission from Thomas Guettler <guettli at thomas-guettler.de>:

logging.error('...', exc_info=True) only displays the
frames downward. But I often need the upper frames, to debug a problem.

This example shows, that you don't see the "upper" frame in the stactrace. But that's information is important.

<pre>
import logging

def foo():
    try:
        raise Exception()
    except Exception, exc:
        logging.error('Exception occured: %s' % exc, exc_info=True)

def upper():
    foo()
upper()
</pre>

<pre>
===> python tmp/t.py
ERROR:root:Exception occured: 
Traceback (most recent call last):
  File "tmp/t.py", line 6, in foo
    raise Exception()
Exception
</pre>

----------
components: Library (Lib)
messages: 112063
nosy: guettli
priority: normal
severity: normal
status: open
title: logging.error('...', exc_info=True) should display upper frames, too
versions: Python 2.6

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

From report at bugs.python.org  Fri Jul 30 17:20:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 30 Jul 2010 15:20:17 +0000
Subject: [New-bugs-announce] [issue9428] profile.py bug with the main file
	being profiled
In-Reply-To: <1280503217.79.0.150148716747.issue9428@psf.upfronthosting.co.za>
Message-ID: <1280503217.79.0.150148716747.issue9428@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Attached patch, profile-run.diff, fixes the same bug as in issue9323, only in the profile rather than the trace module.

Even though the affected code is small, it may be a good idea to share it between the trace and profile modules as well as unify command line interfaces.  See also issue9325.

----------
assignee: belopolsky
components: Library (Lib)
files: profile-run.diff
keywords: easy, patch
messages: 112085
nosy: belopolsky
priority: normal
severity: normal
stage: patch review
status: open
title: profile.py bug with the main file being profiled
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file18270/profile-run.diff

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

From report at bugs.python.org  Fri Jul 30 20:19:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 30 Jul 2010 18:19:15 +0000
Subject: [New-bugs-announce] [issue9429] 2to3 does not rename
	test.test_support to test.support
In-Reply-To: <1280513955.81.0.17259447489.issue9429@psf.upfronthosting.co.za>
Message-ID: <1280513955.81.0.17259447489.issue9429@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Even though test.support is an internal module, it is helpful to have a 2to3 fixer for the 'test_support' to 'support' rename.

My naive attempt to add a fix (see patch pasted below), worked for "from test import test_support" but not for "import test.test_support.


Index: Lib/lib2to3/fixes/fix_imports.py
===================================================================
--- Lib/lib2to3/fixes/fix_imports.py	(revision 83283)
+++ Lib/lib2to3/fixes/fix_imports.py	(working copy)
@@ -55,6 +55,7 @@
            'UserList' : 'collections',
            'urlparse' : 'urllib.parse',
            'robotparser' : 'urllib.robotparser',
+           'test.test_support' : 'test.support',
 }
 
 
Index: Lib/lib2to3/fixes/fix_renames.py
===================================================================
--- Lib/lib2to3/fixes/fix_renames.py	(revision 83283)
+++ Lib/lib2to3/fixes/fix_renames.py	(working copy)
@@ -11,6 +11,7 @@
 from ..fixer_util import Name, attr_chain
 
 MAPPING = {"sys":  {"maxint" : "maxsize"},
+           "test": {"test_support": "support"},
           }
 LOOKUP = {}

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 112095
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: 2to3 does not rename test.test_support to  test.support
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Jul 30 20:57:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 30 Jul 2010 18:57:56 +0000
Subject: [New-bugs-announce] [issue9430] Document str() and repr() of
	timedelta.
In-Reply-To: <1280516276.66.0.738062201536.issue9430@psf.upfronthosting.co.za>
Message-ID: <1280516276.66.0.738062201536.issue9430@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Attaching a tentative patch.  I think it is better to document these as operations rather than special methods.  It may need to be clarified that "-2 days, 0:00:22" is timedelta(-2, 22) rather than -timedelta(2, 22), but I cannot come up with anything short enough for the ops table.  Maybe this should be done in a footnote.

----------
assignee: docs at python
components: Documentation
files: datetime.rst.diff
keywords: easy, patch
messages: 112096
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: Document str() and repr() of timedelta.
versions: Python 3.2
Added file: http://bugs.python.org/file18274/datetime.rst.diff

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

From report at bugs.python.org  Fri Jul 30 21:28:21 2010
From: report at bugs.python.org (George Boutsioukis)
Date: Fri, 30 Jul 2010 19:28:21 +0000
Subject: [New-bugs-announce] [issue9431] 2to3 reapplies fix_dict
In-Reply-To: <1280518101.61.0.560600920548.issue9431@psf.upfronthosting.co.za>
Message-ID: <1280518101.61.0.560600920548.issue9431@psf.upfronthosting.co.za>


New submission from George Boutsioukis <gboutsioukis at gmail.com>:

This only happens on somewhat complex files, I haven't been able yet to isolate the source of this but here goes:

For django trunk, running 2to3 on django/contrib/admin/options.py yields the following:

@@ -282,7 +282,7 @@
         if self.declared_fieldsets:
             return self.declared_fieldsets
         form = self.get_form(request, obj)
-        fields = [..].keys() + list([...])
+        fields = list(list([...]keys())) + list([...])

instead of

+        fields = list([...].keys()) + etc.

and there are a couple of more instances in the same file.

However running 2to3 on the single line above, out of the file gives the correct result. This is only an issue with the fix_dict fixer.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 112099
nosy: gboutsioukis
priority: normal
severity: normal
status: open
title: 2to3 reapplies fix_dict
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Jul 30 21:31:44 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 30 Jul 2010 19:31:44 +0000
Subject: [New-bugs-announce] [issue9432] unquote(None) raises AttributeError
	- Instead of TypeError
In-Reply-To: <1280518304.67.0.979148690814.issue9432@psf.upfronthosting.co.za>
Message-ID: <1280518304.67.0.979148690814.issue9432@psf.upfronthosting.co.za>


New submission from Senthil Kumaran <orsenthil at gmail.com>:

>>> from urllib.parse import unquote
>>> unquote(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/senthil/python/release31-maint/Lib/urllib/parse.py", line 331, in unquote
    res = string.split('%')
AttributeError: 'NoneType' object has no attribute 'split'

As obvious, the AttributeError above is not an Intentional one and is a mistake. TypeError is correct.

Opening this issue subsequent to the discussion in msg12098

----------
assignee: orsenthil
messages: 112100
nosy: orsenthil
priority: normal
severity: normal
status: open
title: unquote(None) raises AttributeError - Instead of TypeError
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat Jul 31 11:51:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 31 Jul 2010 09:51:47 +0000
Subject: [New-bugs-announce] [issue9433] regrtest.py -j 2 doesn't work on
	Windows: remove	close_fds=True on Windows
In-Reply-To: <1280569907.44.0.401416640246.issue9433@psf.upfronthosting.co.za>
Message-ID: <1280569907.44.0.401416640246.issue9433@psf.upfronthosting.co.za>


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

On Windows, subprocess doesn't support close_fds=True if stdin, stdout or stderr is redirected to a pipe.

The problem is in the work function: popen = Popen([sys.executable, '-E', '-m', 'test.regrtest', ...], ..., stdout=PIPE, stderr=PIPE, close_fds=True).

----------
messages: 112125
nosy: haypo
priority: normal
severity: normal
status: open
title: regrtest.py -j 2 doesn't work on Windows: remove close_fds=True on Windows
versions: Python 3.2

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

From report at bugs.python.org  Sat Jul 31 17:36:25 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 31 Jul 2010 15:36:25 +0000
Subject: [New-bugs-announce] [issue9435] test_distutils fails without zlib
In-Reply-To: <1280590585.97.0.266735291444.issue9435@psf.upfronthosting.co.za>
Message-ID: <1280590585.97.0.266735291444.issue9435@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

Noticed it in 3.2a1, but probably present on other branches.  It should not fail, but skip these tests.

----------
assignee: tarek
components: Distutils
messages: 112157
nosy: georg.brandl, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_distutils fails without zlib
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat Jul 31 17:53:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Jul 2010 15:53:11 +0000
Subject: [New-bugs-announce] [issue9436] test_sysconfig failure
In-Reply-To: <1280591591.84.0.476083865565.issue9436@psf.upfronthosting.co.za>
Message-ID: <1280591591.84.0.476083865565.issue9436@psf.upfronthosting.co.za>


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

When I use the following configuration (in order to build a 32-bit Python a 64-bit OS):
  ./configure --with-computed-gotos CFLAGS=-m32 LDFLAGS=-m32

I then get a failure in test_sysconfig:

======================================================================
FAIL: test_ldshared_value (test.test_sysconfig.TestSysConfig)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/m32/Lib/test/test_sysconfig.py", line 285, in test_ldshared_value
    self.assertIn(ldflags, ldshared)
AssertionError: '-m32 ' not found in 'gcc -pthread -shared'

----------
components: Library (Lib)
messages: 112162
nosy: jyasskin, pitrou, tarek
priority: normal
severity: normal
status: open
title: test_sysconfig failure
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat Jul 31 17:55:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Jul 2010 15:55:12 +0000
Subject: [New-bugs-announce] [issue9437] test_distutils failure with -m32
In-Reply-To: <1280591712.46.0.151463924195.issue9437@psf.upfronthosting.co.za>
Message-ID: <1280591712.46.0.151463924195.issue9437@psf.upfronthosting.co.za>


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

When I use the following configuration (in order to build a 32-bit Python a 64-bit OS):
  ./configure --with-computed-gotos CFLAGS=-m32 LDFLAGS=-m32

I then get two failures in test_distutils:

test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase) ... /tmp/tmpssz80G/tmp/tmpssz80G/xxmodule.o: could not read symbols: File in wrong format
collect2: ld a retourn? 1 code d'?tat d'ex?cution
ERROR
[...]
test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase) ... /tmp/tmphxwa1S/tempt/tmp/tmpuD17us/foo.o: could not read symbols: File in wrong format
collect2: ld a retourn? 1 code d'?tat d'ex?cution
ERROR
[...]

======================================================================
ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/m32/Lib/distutils/unixccompiler.py", line 254, in link
    self.spawn(linker + ld_args)
  File "/home/antoine/py3k/m32/Lib/distutils/ccompiler.py", line 909, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/home/antoine/py3k/m32/Lib/distutils/spawn.py", line 34, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/home/antoine/py3k/m32/Lib/distutils/spawn.py", line 138, in _spawn_posix
    % (cmd[0], exit_status))
distutils.errors.DistutilsExecError: command 'gcc' failed with exit status 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/antoine/py3k/m32/Lib/distutils/tests/test_build_ext.py", line 65, in test_build_ext
    cmd.run()
  File "/home/antoine/py3k/m32/Lib/distutils/command/build_ext.py", line 347, in run
    self.build_extensions()
  File "/home/antoine/py3k/m32/Lib/distutils/command/build_ext.py", line 456, in build_extensions
    self.build_extension(ext)
  File "/home/antoine/py3k/m32/Lib/distutils/command/build_ext.py", line 543, in build_extension
    target_lang=language)
  File "/home/antoine/py3k/m32/Lib/distutils/ccompiler.py", line 719, in link_shared_object
    extra_preargs, extra_postargs, build_temp, target_lang)
  File "/home/antoine/py3k/m32/Lib/distutils/unixccompiler.py", line 256, in link
    raise LinkError(msg)
distutils.errors.LinkError: command 'gcc' failed with exit status 1

======================================================================
ERROR: test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/m32/Lib/distutils/unixccompiler.py", line 254, in link
    self.spawn(linker + ld_args)
  File "/home/antoine/py3k/m32/Lib/distutils/ccompiler.py", line 909, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/home/antoine/py3k/m32/Lib/distutils/spawn.py", line 34, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/home/antoine/py3k/m32/Lib/distutils/spawn.py", line 138, in _spawn_posix
    % (cmd[0], exit_status))
distutils.errors.DistutilsExecError: command 'gcc' failed with exit status 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/antoine/py3k/m32/Lib/distutils/tests/test_build_ext.py", line 321, in test_get_outputs
    cmd.run()
  File "/home/antoine/py3k/m32/Lib/distutils/command/build_ext.py", line 347, in run
    self.build_extensions()
  File "/home/antoine/py3k/m32/Lib/distutils/command/build_ext.py", line 456, in build_extensions
    self.build_extension(ext)
  File "/home/antoine/py3k/m32/Lib/distutils/command/build_ext.py", line 543, in build_extension
    target_lang=language)
  File "/home/antoine/py3k/m32/Lib/distutils/ccompiler.py", line 719, in link_shared_object
    extra_preargs, extra_postargs, build_temp, target_lang)
  File "/home/antoine/py3k/m32/Lib/distutils/unixccompiler.py", line 256, in link
    raise LinkError(msg)
distutils.errors.LinkError: command 'gcc' failed with exit status 1

----------
assignee: tarek
components: Distutils, Tests
messages: 112163
nosy: jyasskin, pitrou, tarek
priority: high
severity: normal
stage: needs patch
status: open
title: test_distutils failure with -m32
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat Jul 31 19:07:48 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 31 Jul 2010 17:07:48 +0000
Subject: [New-bugs-announce] [issue9438] Clarify __debug__ restrictions
In-Reply-To: <1280596068.17.0.635843199861.issue9438@psf.upfronthosting.co.za>
Message-ID: <1280596068.17.0.635843199861.issue9438@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

On http://docs.python.org/library/constants.html?highlight=__debug__#__debug__

* Be more explicit that assigments to None and __debug__ are illegal even when
  used as attributes.  IOW it's not just assignment to the built-in names that
  are illegal.

* Add a "Changed in 2.7" to __debug__ stating that assignments to __debug__ as
  an attribute became illegal.

Add this to the NEWS and What's New files for 2.7.

(Also double check for Python 3.2)

----------
assignee: barry
components: Documentation
messages: 112167
nosy: barry
priority: normal
severity: normal
status: open
title: Clarify __debug__ restrictions
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Jul 31 19:14:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Jul 2010 17:14:38 +0000
Subject: [New-bugs-announce] [issue9439] Add SSL changes to 3.2 what's new
In-Reply-To: <1280596478.45.0.905218658684.issue9439@psf.upfronthosting.co.za>
Message-ID: <1280596478.45.0.905218658684.issue9439@psf.upfronthosting.co.za>


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

Patch waiting for un-freeze.

----------
assignee: georg.brandl
components: Documentation
files: whatsnew-ssl.patch
keywords: patch
messages: 112168
nosy: georg.brandl, pitrou
priority: low
severity: normal
stage: commit review
status: open
title: Add SSL changes to 3.2 what's new
versions: Python 3.2
Added file: http://bugs.python.org/file18287/whatsnew-ssl.patch

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

From report at bugs.python.org  Sat Jul 31 19:24:15 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 31 Jul 2010 17:24:15 +0000
Subject: [New-bugs-announce] [issue9440] Remove bad assert
	in	TestDateTime.test_microsecond_rounding
In-Reply-To: <1280597055.4.0.682917662697.issue9440@psf.upfronthosting.co.za>
Message-ID: <1280597055.4.0.682917662697.issue9440@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

The last assertion in TestDateTime.test_microsecond_rounding does not test a predictable outcome.  For example, on my box it passes with pydebug enabled and fails without.  It should just be removed.

----------
assignee: belopolsky
components: Tests
messages: 112169
nosy: belopolsky, georg.brandl
priority: high
severity: normal
status: open
title: Remove bad assert in TestDateTime.test_microsecond_rounding
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Jul 31 19:26:20 2010
From: report at bugs.python.org (Tom Dunham)
Date: Sat, 31 Jul 2010 17:26:20 +0000
Subject: [New-bugs-announce] [issue9441] increase logging handlers test
	coverage
In-Reply-To: <1280597180.41.0.450800729974.issue9441@psf.upfronthosting.co.za>
Message-ID: <1280597180.41.0.450800729974.issue9441@psf.upfronthosting.co.za>


New submission from Tom Dunham <tom at tomdunham.org>:

Some regression tests for logging handlers, brings coverage up from 37% to 52%. Mainly tests to rotating file handlers.

----------
components: Library (Lib)
files: rotating_file_handlers.patch
keywords: patch
messages: 112171
nosy: Tom
priority: normal
severity: normal
status: open
title: increase logging handlers test coverage
versions: Python 3.2
Added file: http://bugs.python.org/file18288/rotating_file_handlers.patch

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

From report at bugs.python.org  Sat Jul 31 21:46:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 31 Jul 2010 19:46:33 +0000
Subject: [New-bugs-announce] [issue9442] Update sys.version doc
In-Reply-To: <1280605593.44.0.301230771819.issue9442@psf.upfronthosting.co.za>
Message-ID: <1280605593.44.0.301230771819.issue9442@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Attaching a patch to edit mention of ?build number? in library/sys.

I also don?t understand ?The first three characters are used to identify the version in the installation directories (where appropriate on each platform)?, maybe someone who does could enlighten me.

If #5778 is rejected, the doc will need another update to mention that there may be a newline in sys.version.

----------
assignee: docs at python
components: Documentation
files: sys.version1.diff
keywords: patch
messages: 112189
nosy: docs at python, merwok
priority: normal
severity: normal
stage: patch review
status: open
title: Update sys.version doc
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file18289/sys.version1.diff

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