From report at bugs.python.org  Tue Jan  1 00:57:53 2013
From: report at bugs.python.org (Bryan Bishop)
Date: Mon, 31 Dec 2012 23:57:53 +0000
Subject: [New-bugs-announce] [issue16830] Add skip_host and
	skip_accept_encoding to	httplib/http.client
Message-ID: <1356998273.75.0.911756727263.issue16830@psf.upfronthosting.co.za>


New submission from Bryan Bishop:

Sometimes I am using httplib/http.client and the server is not exactly conforming to HTTP specs. I need to be able to specify the exact headers that are sent to the server. By default, httplib/http.client injects headers like "Host" and "Accept-Encoding".

Issue #831747 added skip_accept_encoding to httplib's putrequest method, but not on the request method. This current patch exposes these two toggles on the request method. This way, headers can be controlled without manually calling the connect/send/endheaders methods.

As a result, urllib/urllib3 can call urlopen and pass in these attributes to more directly control the headers sent to the remote server.

----------
components: Library (Lib)
files: httplib_better_header_skips.patch
keywords: patch
messages: 178719
nosy: kanzure
priority: normal
severity: normal
status: open
title: Add skip_host and skip_accept_encoding to httplib/http.client
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file28516/httplib_better_header_skips.patch

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

From report at bugs.python.org  Tue Jan  1 04:21:37 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 01 Jan 2013 03:21:37 +0000
Subject: [New-bugs-announce] [issue16831] Better docs for
	ABCMeta.__subclasshook__
Message-ID: <1357010497.63.0.917650591234.issue16831@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Authors of __subclasshook__ methods need to decide between returning True, False and NotImplemented in various cases. Making that decision requires a clear understanding that the checks in ABCMeta.__subclasscheck__ occur in the following order:

- explicit registrations
- the __subclasshook__ call
- ordinary inheritance

So, returning False from __subclasshook__ allows you to override normal rules of inheritance, while returning NotImplemented lets normal inheritance rules apply. Explicit registrations take precedence regardless.

----------
messages: 178724
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Better docs for ABCMeta.__subclasshook__

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

From report at bugs.python.org  Tue Jan  1 04:38:24 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 01 Jan 2013 03:38:24 +0000
Subject: [New-bugs-announce] [issue16832] Expose cache validity checking
	support in ABCMeta
Message-ID: <1357011504.56.0.782130595735.issue16832@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

ABCMeta uses an internal counter to invalidate the negative caches when a register() call changes the virtual inheritance graph. (A global count of register() calls is stored on ABCMeta, which ABCMeta.__instancecheck__ and ABCMeta.__subclasscheck__ then compare to a copy cached on the individual ABC)

To properly handle register() method calls on ABCs, generic function implementations also need a way to invalidate their own caches when that graph changes.

It seems like the simplest way to handle this would be to expose a read-only "ABCMeta.cache_token" property. Generic function implementations could then work the same way as ABCMeta itself: store explicit implementation registrations and a cache of derived implementations separately, and if a saved copy of the cache token doesn't match the current value of ABCMeta.cache_token, clear the derived cache.

----------
components: Library (Lib)
messages: 178725
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Expose cache validity checking support in ABCMeta
versions: Python 3.4

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

From report at bugs.python.org  Tue Jan  1 10:36:02 2013
From: report at bugs.python.org (Benno Leslie)
Date: Tue, 01 Jan 2013 09:36:02 +0000
Subject: [New-bugs-announce] [issue16833] httpc.lient delayed ack / Nagle
	algorithm optimisation	performs badly for large messages
Message-ID: <1357032962.36.0.684648136944.issue16833@psf.upfronthosting.co.za>


New submission from Benno Leslie:

he http.client HTTPConnection._send_output method has an optimization for avoiding bad interactions between delayed-ack and the Nagle algorithm:

http://hg.python.org/cpython/file/f32f67d26035/Lib/http/client.py#l884

Unfortunately this interacts rather poorly if the case where the message_body is a bytes instance and is rather large.

If the message_body is bytes it is appended to the headers, which causes a copy of the data. When message_body is large this duplication of data can cause a significant spike in memory usage.

(In my particular case I was uploading a 200MB file to 30 hosts at the same leading to memory spikes over 6GB.

[There is a short thread discussing this issue on python-dev; Subject: "http.client Nagle/delayed-ack optimization"; Date: Dec 15, 2012]

----------
components: Library (Lib)
files: http_opt.diff
keywords: patch
messages: 178728
nosy: bennoleslie
priority: normal
severity: normal
status: open
title: httpc.lient delayed ack / Nagle algorithm optimisation performs badly for large messages
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file28518/http_opt.diff

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

From report at bugs.python.org  Tue Jan  1 15:56:29 2013
From: report at bugs.python.org (Yuval Weinbaum)
Date: Tue, 01 Jan 2013 14:56:29 +0000
Subject: [New-bugs-announce] [issue16834] ioctl mutate_flag behavior in
	regard to the buffer size	limit
Message-ID: <1357052189.92.0.352175087043.issue16834@psf.upfronthosting.co.za>


New submission from Yuval Weinbaum:

In fcntl module, the documentation states the following regarding the mutate_flag in ioctl method:

***
If it is false, the buffer?s mutability is ignored and behaviour is as for a read-only buffer, except that the 1024 byte limit mentioned above is avoided ? so long as the buffer you pass is as least as long as what the operating system wants to put there, things should work.
***

However, looking at the code (fcntlmodule.c) it seems that the 1024 bytes limitation is avoided when the mutate_flag is set to True (the opposite of what is stated in the doc).

----------
assignee: docs at python
components: Documentation
messages: 178732
nosy: Yuval.Weinbaum, docs at python
priority: normal
severity: normal
status: open
title: ioctl mutate_flag behavior in regard to the buffer size limit
versions: Python 2.6

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

From report at bugs.python.org  Tue Jan  1 20:51:45 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 01 Jan 2013 19:51:45 +0000
Subject: [New-bugs-announce] [issue16835] Update PEP 399 to allow for test
	discovery
Message-ID: <1357069905.98.0.626196001358.issue16835@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Don't have the base tests inherit from TestCase else they will be discovered by unittest and run even though they are not fully defined.

See http://bugs.python.org/issue16748 as the trigger for this issue.

----------
messages: 178748
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Update PEP 399 to allow for test discovery

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

From report at bugs.python.org  Tue Jan  1 22:57:38 2013
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 01 Jan 2013 21:57:38 +0000
Subject: [New-bugs-announce] [issue16836] configure script disables support
	for IPv6 on a system	where IPv6 is disabled
Message-ID: <1357077458.8.0.894296515098.issue16836@psf.upfronthosting.co.za>


New submission from Ralf Schmitt:

The configure script uses a runtime check to determine if IPv6 is working. If IPv6 is disabled system-wide via a kernel option on linux, the resulting python interpreter is compiled as if "--disable-ipv6" had been passed to the configure script.

This causes multiple issues:
- http://bugs.python.org/issue7735
- http://bugs.python.org/issue16208

Both of the above issues have been closed as wontfix, and I have been told to not use --disable-ipv6 and instead disable IPv6 system wide via a boot option. This is what I did, and now I have the same issue because the configure script has this runtime check...

----------
messages: 178762
nosy: schmir
priority: normal
severity: normal
status: open
title: configure script disables support for IPv6 on a system where IPv6 is disabled
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Jan  2 00:26:03 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 01 Jan 2013 23:26:03 +0000
Subject: [New-bugs-announce] [issue16837] Number ABC can be instantiated
Message-ID: <1357082763.61.0.378054227113.issue16837@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

According to the reference manual, "None of the types defined in [numbers] module can be instantiated."  However,

>>> from numbers import *
>>> Number()
<numbers.Number object at 0x1005e5080>

This can probably be fixed by making Number.__hash__ an abstract method.

----------
messages: 178785
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Number ABC can be instantiated
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Jan  2 06:54:36 2013
From: report at bugs.python.org (Eiro Neemous)
Date: Wed, 02 Jan 2013 05:54:36 +0000
Subject: [New-bugs-announce] [issue16838] fail to import "locale" module
	when there
Message-ID: <1357106076.58.0.0839092173031.issue16838@psf.upfronthosting.co.za>


Changes by Eiro Neemous <dr.neemous at gmail.com>:


----------
components: 2to3 (2.x to 3.x conversion tool)
nosy: Cravix
priority: normal
severity: normal
status: open
title: fail to import "locale" module when there
versions: Python 3.3

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

From report at bugs.python.org  Wed Jan  2 14:50:36 2013
From: report at bugs.python.org (Masaya Suzuki)
Date: Wed, 02 Jan 2013 13:50:36 +0000
Subject: [New-bugs-announce] [issue16839] segmentation fault when
	unicode(classic_class_instance)
Message-ID: <1357134636.13.0.449777533909.issue16839@psf.upfronthosting.co.za>


New submission from Masaya Suzuki:

Python 2.7.3 crushes when the following code is run without any library, which means run python with -S option:

    class Test:
        pass
    unicode(Test())

In the course of the interpreter tries to find the "__unicode__" attribute in a class, it uses a cached python string of "__unicode__". The reason of this crush is that the cached value is used before initialized. It is initialized only when trying to find the one of a new-style class, so the interpreter will crush if one uses only classic classes.

The attached patch will fix this issue by initializing a cached value before it is used.

Thanks.

----------
components: Interpreter Core
files: object_unicode.patch
keywords: patch
messages: 178811
nosy: draftcode
priority: normal
severity: normal
status: open
title: segmentation fault when unicode(classic_class_instance)
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file28528/object_unicode.patch

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

From report at bugs.python.org  Wed Jan  2 16:09:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 02 Jan 2013 15:09:13 +0000
Subject: [New-bugs-announce] [issue16840] Tkinter doesn't support large
	integers
Message-ID: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

A long time Tcl got support first 64-bit integers, and then arbitrary size integers. Python also supports arbitrary size integers. However Tkinter supports only C?long integers. For example, on 32-bit platform:

>>> import tkinter
>>> t = tkinter.Tk()
>>> t.tk.call('expr', 2**30)
1073741824
>>> t.tk.call('expr', 2**31)
<wideInt object at 0x9122518>
>>> t.tk.call('expr', 2**63)
<bignum object at 0x9126010>

Those <wideInt object> and <bignum object> are not usable from Python. Potentially this can cause errors in some rare circumstances.

I'm working on a patch, but was faced with a problem. Tcl provides functions for conversions between Bignum Tcl object and mp_int, but it does not provide all functions for conversions between mp_int and bytes sequence. Which is better, add libtommath library to CPython dependencies, or implement the missing functionality manually? Or may be use haxadecimal representation for conversions?

----------
assignee: serhiy.storchaka
components: Tkinter
messages: 178815
nosy: gpolo, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Tkinter doesn't support large integers
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Jan  2 16:32:57 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 02 Jan 2013 15:32:57 +0000
Subject: [New-bugs-announce] [issue16841] Set st_dev on Windows as unsigned
	long
Message-ID: <1357140777.81.0.151859871717.issue16841@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

st_dev field of stat() result was set as signed long or long long, but now it is unsigned long on Windows (see issue11939). The proposed patch uses appropriate conversion for it.

----------
components: Extension Modules, Windows
files: st_dev_unsigned.patch
keywords: patch
messages: 178816
nosy: brian.curtin, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Set st_dev on Windows as unsigned long
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file28529/st_dev_unsigned.patch

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

From report at bugs.python.org  Wed Jan  2 21:08:25 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 02 Jan 2013 20:08:25 +0000
Subject: [New-bugs-announce] [issue16842] Allow to override a function
	signature for pydoc with a	docstring
Message-ID: <1357157305.88.0.0239428638229.issue16842@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Just a quote of Georg Brandl's msg178519:

> A simple, minimal-invasive solution would be to allow a signature for documentation purposes as the first line of the docstrings.
>
> pydoc could recognize this (if docstring.startswith(func.__name__ + '(') or something like that), and display the given signature instead of the introspected one.

I see only one obstacle. Some functions (like dict.update()) needs several signatures. How detect and format them?

----------
components: Interpreter Core
messages: 178846
nosy: georg.brandl, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Allow to override a function signature for pydoc with a docstring
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan  2 22:14:30 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 02 Jan 2013 21:14:30 +0000
Subject: [New-bugs-announce] [issue16843] sporadic test_sched failure
Message-ID: <1357161270.81.0.205627983057.issue16843@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Just got this:

[255/372/1] test_sched
Warning -- threading._dangling was modified by test_sched
test test_sched failed -- Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/test/test_sched.py", line 83, in test_cancel_concurrent
    scheduler.cancel(event1)
  File "/home/antoine/cpython/default/Lib/sched.py", line 96, in cancel
    self._queue.remove(event)
ValueError: list.remove(x): x not in list

----------
components: Library (Lib), Tests
messages: 178851
nosy: pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: sporadic test_sched failure
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan  2 23:37:22 2013
From: report at bugs.python.org (Alejandro Marco Ramos)
Date: Wed, 02 Jan 2013 22:37:22 +0000
Subject: [New-bugs-announce] [issue16844] funcName in logging module for
	python 2.6
Message-ID: <1357166242.35.0.208386343695.issue16844@psf.upfronthosting.co.za>


New submission from Alejandro Marco Ramos:

hi, when use the param 'funcName' in the logging module (version 0.4.9.6 for python 2.6) the module crash. Researching in the code (__init__.py) i see that the code for get the function name is in method '_log' in the class 'Logger'. The function 'findCaller()' returns in the last value the name of the function (in the variable name 'func'), but this variable is not present in the caller function for create a 'record' object (in this case 'makeRecord'). I added code to fix this but i like that review this bug.

----------
components: Extension Modules
messages: 178859
nosy: amarco
priority: normal
severity: normal
status: open
title: funcName in logging module for python 2.6
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Thu Jan  3 01:42:06 2013
From: report at bugs.python.org (Sebastian Berg)
Date: Thu, 03 Jan 2013 00:42:06 +0000
Subject: [New-bugs-announce] [issue16845] warnings.simplefilter should
	validate input
Message-ID: <1357173726.64.0.0586309357998.issue16845@psf.upfronthosting.co.za>


New submission from Sebastian Berg:

`warnings.simplefilter` does not validate that the category passed in is actually a class. This means that an invalid category leads to a `TypeError` whenever a warning would otherwise occur due to `issubclass` check failing.

It is a very small thing, but for usability it would be clearer if this was checked right away.

----------
messages: 178867
nosy: seberg
priority: normal
severity: normal
status: open
title: warnings.simplefilter should validate input
type: enhancement

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

From report at bugs.python.org  Thu Jan  3 06:52:11 2013
From: report at bugs.python.org (FizzledOut)
Date: Thu, 03 Jan 2013 05:52:11 +0000
Subject: [New-bugs-announce] [issue16846] relative import solution
Message-ID: <1357192331.61.0.693606949117.issue16846@psf.upfronthosting.co.za>


New submission from FizzledOut:

Instead of giving the error message " Attempted relative import in non-package", simply process the line!

from . import Example

whether or not the file is __main__, it should be able to go up one directory, if possible, and try to import Example.py.  It makes no sense that this cannot be done.

----------
components: Windows
messages: 178913
nosy: Fixpythonbugs
priority: normal
severity: normal
status: open
title: relative import solution
type: resource usage
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jan  3 07:56:50 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 03 Jan 2013 06:56:50 +0000
Subject: [New-bugs-announce] [issue16847] sha module broken
Message-ID: <1357196210.69.0.740863456669.issue16847@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

On OSX 10.8 with the following configure line and a fresh checkout (as of 10 minutes ago):

'../configure'  '--enable-framework' '--enable-universalsdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk' '--with-universal-archs=intel' '--with-framework-name=Python' 'MACOSX_DEPLOYMENT_TARGET=10.8' 'CC=clang' 'CXX=clang++'

The build fails because _PyUnicode_CheckConsistency cannot be found when trying to load (amongst others) _sha1. According to the unicodeobject.h that function is only available in debug builds, while it gets used unconditionally in sha1module.c

I haven't run a bisect yet to find why the build fails now, the call to _PyUnicode_CheckConsistency was added in April and the build failure is (much) more recent.

----------
keywords: 3.3regression
messages: 178916
nosy: ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: sha module broken
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Thu Jan  3 12:32:54 2013
From: report at bugs.python.org (Samuel John)
Date: Thu, 03 Jan 2013 11:32:54 +0000
Subject: [New-bugs-announce] [issue16848] Mac OS X: python-config --ldflags
	and location of	Python.framework
Message-ID: <1357212774.75.0.369526303193.issue16848@psf.upfronthosting.co.za>


New submission from Samuel John:

Some tools use `python-config --ldflags` to get the flags in order to link against the Python lib on OS X (for example gst-python from pygtk (2.x).

For framework builds, `python-config --ldflags` returns (among few other):

    -u _PyMac_Error Python.framework/Versions/2.7/Python

which is an incomplete path.

This issue is almost a duplicate of http://bugs.python.org/issue3588 and the fix discussed there would work. However I report this for Python 2.7.

We at Homebrew propose a very similar fix but I'd prefer the one in issue3588:

    LINKFORSHARED = -u _PyMac_Error -framework Python
    LDFLAGS += -F$(PYTHONFRAMEWORKPREFIX)

----------
components: Build
messages: 178936
nosy: hynek, ned.deily, ronaldoussoren, samueljohn
priority: normal
severity: normal
status: open
title: Mac OS X: python-config --ldflags and location of Python.framework
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Jan  3 13:36:42 2013
From: report at bugs.python.org (Franck Michea)
Date: Thu, 03 Jan 2013 12:36:42 +0000
Subject: [New-bugs-announce] [issue16849] Element.{get,
	iter} doesn't handle keyword arguments when using _elementtree
	C	accelerator.
Message-ID: <1357216602.29.0.17641407766.issue16849@psf.upfronthosting.co.za>


New submission from Franck Michea:

Documentation:
 - http://docs.python.org/3.3/library/xml.etree.elementtree.html#xml.etree.ElementTree.Element.get
 - http://docs.python.org/3.3/library/xml.etree.elementtree.html#xml.etree.ElementTree.Element.iter

These two functions are documented with keyword arguments. Python implementation works correctly, but as of 3.3, _etreeelement module in C is hot-patching this module to enhance speed. C implementation only expects normal arguments for get and iter. This is what this patch fixes.

First patch so:
 - I am not sure about the "key" string in kwlist array, I followed code above and it doesn't work without it, so I guess it's to for the normal arg.
 - I am not sure about how to test iter with this. tag argument is never used.
 - Included a test that shows the problem.

Have a nice day,

----------
components: Library (Lib), XML
files: etree.patch
keywords: patch
messages: 178939
nosy: kushou
priority: normal
severity: normal
status: open
title: Element.{get,iter} doesn't handle keyword arguments when using _elementtree C accelerator.
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file28541/etree.patch

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

From report at bugs.python.org  Thu Jan  3 16:23:26 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Jan 2013 15:23:26 +0000
Subject: [New-bugs-announce] [issue16850] Atomic open + close-and-exec
Message-ID: <1357226606.72.0.774782752961.issue16850@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Recent version on different operating systems support opening a file with close-on-exec flag set immediatly (atomic). This feature fixes a race condition when the process calls execv() between open() and fcntl() (to set the FD_CLOEXEC flag to the newly opened file).

It would be nice to expose this feature in Python. The problem is the find a portable and safe way to expose the feature: neologix is against a best-effort function. For example, Linux kernel older than 2.6.22 simply ignores O_CLOEXEC flag (while the libc may expose it).

The feature looks to be supported by at least:

 * Linux kernel >= 2.6.23
 * FreeBSD 8+
 * Windows: _open(filename, _O_NOINHERIT). Is it supported by Windows XP and older versions? http://msdn.microsoft.com/en-us/library/z0kc8e3z.aspx

See also:

 * Issue #12760 (closed): This issue added an "x" mode to open() to create a file in exclusive mode
 * Issue #12103: "Document how to use open with os.O_CLOEXEC"
 * Issue #12105: It was proposed to add an "e" mode to open() for O_CLOEXEC

----------
components: Interpreter Core
messages: 178949
nosy: alexey-smirnov, amaury.forgeotdarc, haypo, neologix, sbt
priority: normal
severity: normal
status: open
title: Atomic open + close-and-exec
versions: Python 3.4

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

From report at bugs.python.org  Thu Jan  3 17:41:29 2013
From: report at bugs.python.org (Wojciech Danilo)
Date: Thu, 03 Jan 2013 16:41:29 +0000
Subject: [New-bugs-announce] [issue16851] ismethod and isfunction methods
	error
Message-ID: <1357231289.77.0.0608728593688.issue16851@psf.upfronthosting.co.za>


New submission from Wojciech Danilo:

Hi! I think this behaviour is bug. Lets concider the following code:

import inspect
class X(object):
    def a(self):pass
    def b(self):pass
    def c(self):pass

print(inspect.getmembers(X, predicate=inspect.ismethod))
print(inspect.getmembers(X, predicate=inspect.isfunction))

In python 2.7, the results are:
[('a', <unbound method X.a>), ('b', <unbound method X.b>), ('c', <unbound method X.c>)]
[]

and in Python 3.2:
[]
[('a', <function a at 0x1b0fd10>), ('b', <function b at 0x1b0fe20>), ('c', <function c at 0x1b160d8>)]

I think, the results from python 2.7 are correct.

----------
components: Library (Lib)
messages: 178964
nosy: wdanilo
priority: normal
severity: normal
status: open
title: ismethod and isfunction methods error
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Jan  3 17:58:41 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 03 Jan 2013 16:58:41 +0000
Subject: [New-bugs-announce] [issue16852] Fix test discovery for
	test_genericpath.py
Message-ID: <1357232321.05.0.189321797188.issue16852@psf.upfronthosting.co.za>


New submission from Zachary Ware:

See Issue 16748 for previous discussion.

This patch should fix test_genericpath.py, with changes to test_macpath.py, test_ntpath.py, and test_posixpath.py required by the fix to test_genericpath.py.  This is version 2 of the patch after a review by Serhiy Storchaka in issue 16748.

----------
components: Tests
messages: 178967
nosy: brett.cannon, serhiy.storchaka, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_genericpath.py
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Jan  3 18:38:06 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 03 Jan 2013 17:38:06 +0000
Subject: [New-bugs-announce] [issue16853] add a Selector to the select module
Message-ID: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

Recently, the multiprocessing and telnetlib modules have been patched to use poll() instead of select() when available (mainly for the FD_SETSIZE limitation):
http://bugs.python.org/issue10527
http://bugs.python.org/issue14635

This leads to code duplication (just have a look at the commits to convince yourself), and also it highlights the fact that the select module is too low-level: right now, there's no easy way to do portable and efficient I/O multiplexing. What's more, /dev/poll and epoll() support have been added recently, which can make one puzzled by the myriad of available options.

Therefore, to reduce code duplication, and make writing portable and efficient code easier, I suggest the addition of a new select.Selector() class, which offers a - hopefully - simple and consistent API.
It has the following advantages:
- portable
- consistent (select() accepts and returns file objects, whereas pol() only returns FD, the timeouts don't have the same units - seconds/milliseconds, etc).

You'll find a tentative implementation attached, with tests (but no docs).

I'm also attaching two patches, one for multiprocessing.connection and the other for telnetlib, to show the before/after.

I'd like to have your feedback, especially on those points:
- right now, Selector.select() returns a set of (fd, event mask). What do you think, would a bare list be OK?
- the current version doesn't retry on EINTR, and I'd like to catch it by default: what do you think
- since I use an abstract base class, I don't know how to have docstrings show up in the help

----------
components: Library (Lib)
files: selector.diff
keywords: patch
messages: 178970
nosy: giampaolo.rodola, neologix, pitrou
priority: normal
severity: normal
status: open
title: add a Selector to the select module
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28546/selector.diff

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

From report at bugs.python.org  Thu Jan  3 20:47:09 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 03 Jan 2013 19:47:09 +0000
Subject: [New-bugs-announce] [issue16854] usage() is not defined in
	Lib/test/regrtest.py
Message-ID: <1357242429.96.0.115075788374.issue16854@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

$ ./python -m test.regrtest -u spam
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/home/serhiy/py/cpython/Lib/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "/home/serhiy/py/cpython/Lib/test/regrtest.py", line 1599, in <module>
    main()
  File "/home/serhiy/py/cpython/Lib/test/regrtest.py", line 473, in main
    usage('Invalid -u/--use option: ' + a)
NameError: global name 'usage' is not defined


This is 3.4 only issue.

----------
components: Tests
messages: 178977
nosy: ezio.melotti, michael.foord, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: usage() is not defined in Lib/test/regrtest.py
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Jan  3 22:49:05 2013
From: report at bugs.python.org (Walter Mundt)
Date: Thu, 03 Jan 2013 21:49:05 +0000
Subject: [New-bugs-announce] [issue16855] traceback module leaves off module
	name in last line of	formatted tracebacks
Message-ID: <1357249745.89.0.552193091281.issue16855@psf.upfronthosting.co.za>


New submission from Walter Mundt:

The documentation for the traceback module states that it "exactly mimics the behavior of the Python interpreter when it prints a stack trace."  However, this does not seem to be the case.  In Python 2.7.3, executing the following:

    import socket
    import sys
    import traceback
    
    def raises_socket_timeout():
        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        s.settimeout(0.001)
        s.connect(('8.8.8.8', 9999))
    
    try:
        raises_socket_timeout()
    except Exception:
        print "print_exc():"
        traceback.print_exc()
        print "-------------"
        print "uncaught:"
        raise

Results in this output:

    print_exc():
    Traceback (most recent call last):
      File "test.py", line 11, in <module>
        raises_socket_timeout()
      File "test.py", line 8, in raises_socket_timeout
        s.connect(('8.8.8.8', 9999))
      File "/usr/lib/python2.7/socket.py", line 224, in meth
        return getattr(self._sock,name)(*args)
    timeout: timed out
    -------------
    uncaught:
    Traceback (most recent call last):
      File "test.py", line 11, in <module>
        raises_socket_timeout()
      File "test.py", line 8, in raises_socket_timeout
        s.connect(('8.8.8.8', 9999))
      File "/usr/lib/python2.7/socket.py", line 224, in meth
        return getattr(self._sock,name)(*args)
    socket.timeout: timed out

Note that the last line of the former message is "timeout: timed out" while the latter is "socket.timeout: timed out" (much more informative).  I've run into this specific difference in trying to debug production systems that use the traceback module to log exceptions.  It also affects traceback.format_exc(), traceback.format_exception_only(), logging.exception(), and logging.info(..., exc_info=True) and friends.

----------
messages: 178991
nosy: waltermundt
priority: normal
severity: normal
status: open
title: traceback module leaves off module name in last line of formatted tracebacks
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jan  4 00:30:51 2013
From: report at bugs.python.org (David M. Cooke)
Date: Thu, 03 Jan 2013 23:30:51 +0000
Subject: [New-bugs-announce] [issue16856] Segfault from calling repr() on a
	dict with a key whose	repr raise an exception
Message-ID: <1357255851.7.0.241432552715.issue16856@psf.upfronthosting.co.za>


New submission from David M. Cooke:

The following segfaults:

class A(int):
    def __repr__(self):
        raise Exception()
a = A()
d = {a : 1}
repr(d)

This is with Python 3.3.0, running on Mac OS 10.7.5, from MacPorts:
Python 3.3.0 (default, Sep 29 2012, 08:16:08) 
[GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)] on darwin

----------
components: Interpreter Core
messages: 178997
nosy: david.m.cooke
priority: normal
severity: normal
status: open
title: Segfault from calling repr() on a dict with a key whose repr raise an exception
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Fri Jan  4 01:56:58 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 04 Jan 2013 00:56:58 +0000
Subject: [New-bugs-announce] [issue16857] replace email address on howto
	with my home page
Message-ID: <1357261018.26.0.114123625931.issue16857@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

I would rather not get the 'thanks' I have been getting since this was published. Rather let that be my website.

----------
assignee: docs at python
components: Documentation
files: no-mail.diff
keywords: patch
messages: 179000
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: replace email address on howto with my home page
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28554/no-mail.diff

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

From report at bugs.python.org  Fri Jan  4 08:53:48 2013
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 04 Jan 2013 07:53:48 +0000
Subject: [New-bugs-announce] [issue16858] tarfile silently hides errors
Message-ID: <1357286028.6.0.98597292825.issue16858@psf.upfronthosting.co.za>


New submission from ???? ?????????:

TarFile.next() silently drop error of one of 

- EOFHeaderError
- InvalidHeaderError

occur. So, extracting corrupted .tar file will not raise error.

----------
components: Library (Lib)
messages: 179005
nosy: mmarkk
priority: normal
severity: normal
status: open
title: tarfile silently hides errors
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jan  4 08:55:22 2013
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 04 Jan 2013 07:55:22 +0000
Subject: [New-bugs-announce] [issue16859] tarfile.TarInfo.fromtarfile does
	not check read() return	value
Message-ID: <1357286122.2.0.304851627332.issue16859@psf.upfronthosting.co.za>


New submission from ???? ?????????:

tarfile.TarInfo.fromtarfile does not check read() return value.
read() may return less than requested size, so,

buf = tarfile.fileobj.read(BLOCKSIZE)
...
obj.offset = tarfile.fileobj.tell() - BLOCKSIZE

may do something nasty.

----------
messages: 179006
nosy: mmarkk
priority: normal
severity: normal
status: open
title: tarfile.TarInfo.fromtarfile does not check read() return value

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

From report at bugs.python.org  Fri Jan  4 15:22:29 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Jan 2013 14:22:29 +0000
Subject: [New-bugs-announce] [issue16860] Use O_CLOEXEC in the tempfile
	module
Message-ID: <1357309349.04.0.535037454982.issue16860@psf.upfronthosting.co.za>


New submission from STINNER Victor:

os.O_CLOEXEC has been added to Python 3.3. This flag solves a race condition if the process is forked between open() and a call to fcntl() to set the FD_CLOEXEC flag.

The following patch written by neologix should fix this issue:
"""
diff --git a/Lib/tempfile.py b/Lib/tempfile.py
--- a/Lib/tempfile.py
+++ b/Lib/tempfile.py
@@ -57,6 +57,8 @@
 _allocate_lock = _thread.allocate_lock

 _text_openflags = _os.O_RDWR | _os.O_CREAT | _os.O_EXCL
+if hasattr(_os, 'O_CLOEXEC'):
+    _text_openflags |= _os.O_CLOEXEC
 if hasattr(_os, 'O_NOINHERIT'):
     _text_openflags |= _os.O_NOINHERIT
 if hasattr(_os, 'O_NOFOLLOW'):
"""

The patch can be applied to Python 3.3 and 3.4.

----------
components: Library (Lib)
messages: 179023
nosy: haypo, neologix
priority: normal
severity: normal
status: open
title: Use O_CLOEXEC in the tempfile module
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Jan  4 16:53:21 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 04 Jan 2013 15:53:21 +0000
Subject: [New-bugs-announce] [issue16861] Portion of code example not
	highlighted in collections	doc
Message-ID: <1357314801.72.0.589947390341.issue16861@psf.upfronthosting.co.za>


Changes by Ramchandra Apte <maniandram01 at gmail.com>:


----------
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: Portion of code example not highlighted in collections doc

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

From report at bugs.python.org  Fri Jan  4 17:13:47 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 04 Jan 2013 16:13:47 +0000
Subject: [New-bugs-announce] [issue16862] FAQ has outdated information about
	Stackless
Message-ID: <1357316027.38.0.0293877261012.issue16862@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

The FAQ says "It?s [Stackless] still experimental but looks very promising." AFAIK, Stackless is mature.

----------
assignee: docs at python
components: Documentation
messages: 179038
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: FAQ has outdated information about Stackless

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

From report at bugs.python.org  Fri Jan  4 17:37:44 2013
From: report at bugs.python.org (Charlie Dimino)
Date: Fri, 04 Jan 2013 16:37:44 +0000
Subject: [New-bugs-announce] [issue16863] Argparse tutorial outdated
Message-ID: <1357317464.45.0.840404790237.issue16863@psf.upfronthosting.co.za>


New submission from Charlie Dimino:

http://docs.python.org/2/howto/argparse.html

Error message in the first example is outdated, may indicate further out of date information on page.

Example:

The tutorial says:
prog.py: error: the following arguments are required: echo

When the actual error received is:
prog.py: error: too few arguments

----------
assignee: docs at python
components: Documentation
messages: 179041
nosy: Charlie.Dimino, docs at python
priority: normal
severity: normal
status: open
title: Argparse tutorial outdated
versions: Python 2.7

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

From report at bugs.python.org  Fri Jan  4 18:24:20 2013
From: report at bugs.python.org (Jim Minter)
Date: Fri, 04 Jan 2013 17:24:20 +0000
Subject: [New-bugs-announce] [issue16864] sqlite3.Cursor.lastrowid isn't
	populated when executing	a SQL REPLACE statement
Message-ID: <1357320260.32.0.764505068506.issue16864@psf.upfronthosting.co.za>


New submission from Jim Minter:

sqlite3 doesn't populate the lastrowid member of the Cursor object when a SQL REPLACE statement is executed.

The following snippet doesn't work as I would expect:
cursor = db.execute("REPLACE INTO table(column) VALUES ('datum')")
print cursor.lastrowid  # prints None

The following snippet, with SQL which is in effect identical to SQLite, does work as expected:
cursor = db.execute("INSERT OR REPLACE INTO table(column) VALUES ('datum')")
print cursor.lastrowid  # prints some rowid

Looking at Modules/_sqlite/cursor.c, in _pysqlite_query_execute(), the following snippet is found:

if (!multiple && statement_type == STATEMENT_INSERT) {
    Py_BEGIN_ALLOW_THREADS
    lastrowid = sqlite3_last_insert_rowid(self->connection->db);
    Py_END_ALLOW_THREADS
    self->lastrowid = PyLong_FromLong((long)lastrowid);
} else {
    Py_INCREF(Py_None);
    self->lastrowid = Py_None;
}

I suggest this should read something like:
if (!multiple && (statement_type == STATEMENT_INSERT || statement_type == STATEMENT_REPLACE)) {
instead of:
if (!multiple && statement_type == STATEMENT_INSERT) {

Thanks,

Jim

----------
components: Library (Lib)
messages: 179049
nosy: jim_minter
priority: normal
severity: normal
status: open
title: sqlite3.Cursor.lastrowid isn't populated when executing a SQL REPLACE statement
type: enhancement
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Fri Jan  4 22:28:18 2013
From: report at bugs.python.org (Jeffrey Bush)
Date: Fri, 04 Jan 2013 21:28:18 +0000
Subject: [New-bugs-announce] [issue16865] ctypes arrays >=2GB in length
	causes exception
Message-ID: <1357334898.38.0.395259266999.issue16865@psf.upfronthosting.co.za>


New submission from Jeffrey Bush:

The environment is Windows 8 Pro 64-bit running Python 64-bit in the WinPython distribution. Python is v2.7.3 built on Apr 10 2012. I first found this with create_string_buffer however I found out that it happens with an even simpler example.

The following code throws an AttributeException: class must define a _length_ attribute, which must be a positive integer.

import ctypes
c_char * int(2*1024*1024*1024) # 2GB, also fails with long() instead of int()

However the following works

import ctypes
c_char * int(2*1024*1024*1024-1) # 1 byte less than 2GB


This is the same with the other c_ types (not limited to size of memory since c_int * int(2*1024*1024*1024-1) works and would be nearly 4 times the size of the failed c_char one).

----------
components: ctypes
messages: 179080
nosy: coderforlife
priority: normal
severity: normal
status: open
title: ctypes arrays >=2GB in length causes exception
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Jan  5 04:47:30 2013
From: report at bugs.python.org (Benno Leslie)
Date: Sat, 05 Jan 2013 03:47:30 +0000
Subject: [New-bugs-announce] [issue16866] libainstall doesn't create all
	directories
Message-ID: <1357357650.4.0.164255645189.issue16866@psf.upfronthosting.co.za>


New submission from Benno Leslie:

make libainstall fails when $(BINDIR) does not exist.

----------
components: Build
files: ainstall.diff
keywords: patch
messages: 179103
nosy: bennoleslie
priority: normal
severity: normal
status: open
title: libainstall doesn't create all directories
type: compile error
versions: Python 3.4
Added file: http://bugs.python.org/file28569/ainstall.diff

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

From report at bugs.python.org  Sat Jan  5 04:59:55 2013
From: report at bugs.python.org (Benno Leslie)
Date: Sat, 05 Jan 2013 03:59:55 +0000
Subject: [New-bugs-announce] [issue16867] setup.py fails if there are no
	extensions
Message-ID: <1357358395.58.0.464299518205.issue16867@psf.upfronthosting.co.za>


New submission from Benno Leslie:

When building if there are zero extensions setup.py fails (max of a zero length list is undefined.)

Although not a very common case, there are potential speciality cases where there will be zero extensions.

----------
components: Build
files: zero_length_extensions.diff
keywords: patch
messages: 179104
nosy: bennoleslie
priority: normal
severity: normal
status: open
title: setup.py fails if there are no extensions
versions: Python 3.4
Added file: http://bugs.python.org/file28570/zero_length_extensions.diff

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

From report at bugs.python.org  Sat Jan  5 05:21:06 2013
From: report at bugs.python.org (Todd Rovito)
Date: Sat, 05 Jan 2013 04:21:06 +0000
Subject: [New-bugs-announce] [issue16868] Python Developer Guide: Include a
	reminder to "ping" bug	report if not reviewed in timely manner
Message-ID: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za>


New submission from Todd Rovito:

The Python Developer Guide in section 3.3 about the life cycle of a patch/review process makes no mention that a bug should be "pinged" first before posting to the python-dev at python.org email list requesting a review.  

For more information see this thread on the Python-Dev email list: http://mail.python.org/pipermail/python-dev/2013-January/123453.html

----------
assignee: docs at python
components: Documentation
messages: 179109
nosy: Todd.Rovito, docs at python
priority: normal
severity: normal
status: open
title: Python Developer Guide: Include a reminder to "ping" bug report if not reviewed in timely manner
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Jan  5 06:56:47 2013
From: report at bugs.python.org (Benno Leslie)
Date: Sat, 05 Jan 2013 05:56:47 +0000
Subject: [New-bugs-announce] [issue16869] makesetup should support .S source
	files
Message-ID: <1357365407.25.0.925950325615.issue16869@psf.upfronthosting.co.za>


New submission from Benno Leslie:

It is useful to be able to build .S files as built-in modules (in particular if you want ctypes as a built-in you need .S files)

The patch enables .S files to be specified in Setup.dist files.

----------
components: Build
files: makesetup-asm.diff
keywords: patch
messages: 179111
nosy: bennoleslie
priority: normal
severity: normal
status: open
title: makesetup should support .S source files
versions: Python 3.4
Added file: http://bugs.python.org/file28574/makesetup-asm.diff

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

From report at bugs.python.org  Sat Jan  5 10:21:55 2013
From: report at bugs.python.org (Poul-Henning Kamp)
Date: Sat, 05 Jan 2013 09:21:55 +0000
Subject: [New-bugs-announce] [issue16870] re fails to match ^ when start
	index is specified ?
Message-ID: <1357377715.09.0.558139465053.issue16870@psf.upfronthosting.co.za>


New submission from Poul-Henning Kamp:

I'm surprised that this does not find any matches:

    import re
    r = re.compile("^abc")
    s = "0123abcxyz"
    for i in range(0,len(s)):
        print(i, r.search(s, i))

I would have expected the i==4 case to match ?

(This is on:
Python 2.7.3 (default, Dec 14 2012, 02:46:02) 
[GCC 4.2.1 Compatible FreeBSD Clang 3.2 (branches/release_32 168974)] on freebsd10
)

----------
components: Regular Expressions
messages: 179116
nosy: bsdphk, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re fails to match ^ when start index is specified ?
versions: Python 2.7

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

From report at bugs.python.org  Sat Jan  5 17:08:57 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 05 Jan 2013 16:08:57 +0000
Subject: [New-bugs-announce] [issue16871] Cleanup a few minor things
Message-ID: <1357402137.77.0.591826422236.issue16871@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a set of patches which clean a few minor things: add spaces after if/while/return/etc, remove spaces after class/function name, remove redundant parens after if/while/return/etc. One set contains only space changes, another set contains parens changes.

----------
components: Library (Lib), Tests
messages: 179128
nosy: ezio.melotti, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Cleanup a few minor things
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From senthil at uthcode.com  Sat Jan  5 19:24:27 2013
From: senthil at uthcode.com (Senthil Kumaran)
Date: Sat, 5 Jan 2013 10:24:27 -0800
Subject: [New-bugs-announce] [issue16869] makesetup should support .S
 source files
In-Reply-To: <1357365407.25.0.925950325615.issue16869@psf.upfronthosting.co.za>
References: <1357365407.25.0.925950325615.issue16869@psf.upfronthosting.co.za>
Message-ID: <CAPOVWOSdQZHccUVUSpBYMrUDr9xQhNA_zsyE9xu=VwuWyytx-Q@mail.gmail.com>

Should not this be?

*.S) obj=`basename $src .S`.o; cc='$(CC)';; #

The filetype extension .S instead .cpp.

And, I have less know-how on these, but for my understanding how would
non-preprocessed asm files (.s) will be handled? And doc reference to
how this change is help as well (unless some other core dev knowing
BUILD takes up).



On Fri, Jan 4, 2013 at 9:56 PM, Benno Leslie <report at bugs.python.org> wrote:

>
> New submission from Benno Leslie:
>
> It is useful to be able to build .S files as built-in modules (in
> particular if you want ctypes as a built-in you need .S files)
>
> The patch enables .S files to be specified in Setup.dist files.
>
> ----------
> components: Build
> files: makesetup-asm.diff
> keywords: patch
> messages: 179111
> nosy: bennoleslie
> priority: normal
> severity: normal
> status: open
> title: makesetup should support .S source files
> versions: Python 3.4
> Added file: http://bugs.python.org/file28574/makesetup-asm.diff
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue16869>
> _______________________________________
> _______________________________________________
> New-bugs-announce mailing list
> New-bugs-announce at python.org
> http://mail.python.org/mailman/listinfo/new-bugs-announce
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20130105/65c4d11f/attachment.html>

From report at bugs.python.org  Sat Jan  5 21:09:45 2013
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Sat, 05 Jan 2013 20:09:45 +0000
Subject: [New-bugs-announce] [issue16872] Metaclass conflict proposition
Message-ID: <1357416585.82.0.262219789669.issue16872@psf.upfronthosting.co.za>


New submission from Jo?o Bernardo:

This is actually a proposition for a behavior change caused by a bugfix.

I have a project dealing with a metaclass factory and the next thing in the TODO list was to add multiple inheritance support.
For my surprise, I tried and there was no metaclass conflict on Python 2.7... I've been developing on Py3.2 and now on Py3.3 an it couldn't obviously choose one of the metaclass to use.

I found this(http://hg.python.org/cpython/rev/c2a89b509be4) commit saying the metaclass calculation was fixed on some special cases (I think it is because of the __new__ method on the metaclass). Py3.1 and inferior are not affected.

----

The thing is: My metaclasses are smart enough to produce the right behavior so the "bug" doesn't bother me as long as this bugfix never gets backported.

For Python 3.2+, the solution requires some more code/knowledge for the user:

If I have this class diagram for "Obj", "A" and "B":


              Obj[type=M]                        M
              /        \             ->         / \
        A[type=MA]  B[type=MB]                 MA MB


then, I want to create C:

    class C(A, B, metaclass=something):
        pass

Where "something" cannot be neither "MA", "MB" or "M" because of metaclass conflict.

but if 

    something = lambda *args: M(*args)

I can call finally call my "smart" metaclass to solve the problem.

----

Now the proposition:

It is possible for the metaclass to have some special attribute (e.g. __call_me_maybe__ = True) so Python knows it can deal with these special cases and avoid the user to explicitly use the `metaclass` parameter?

So
    class C(A, B):
        pass

Would call "MA" because of the special attribute inherited from "M" and it would know how to deal with the B class. 
If it can't do it with some X class, just return NotImplemented or other thing so the `TypeError: metaclass conflict...` will finally be shown.

----------
components: Interpreter Core
messages: 179140
nosy: JBernardo
priority: normal
severity: normal
status: open
title: Metaclass conflict proposition
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Jan  6 01:33:24 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 06 Jan 2013 00:33:24 +0000
Subject: [New-bugs-announce] [issue16873] increase epoll.poll() maxevents
	default value, and improve documentation
Message-ID: <1357432404.49.0.731162769858.issue16873@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

In issue #16853, it was noted that many several projects don't set epoll.poll() maxevents argument, which effectively limits the number of events retuend to FD_SETSIZE-1 (set in selectmodule.c).

Also, the methode documentation can confuse users into thinking that by default, the number of events is unlimited:
"""

.. method:: epoll.poll(timeout=-1, maxevents=-1)

   Wait for events. timeout in seconds (float)
"""

It would probably make sense to use a larger default value for epoll max events (the only downside is increased memory consumption for the events array), maybe based on RLIMIT_NOFILE hard limit.
And the documentation should probably be improved.

----------
components: Library (Lib)
messages: 179157
nosy: neologix
priority: normal
severity: normal
stage: needs patch
status: open
title: increase epoll.poll() maxevents default value, and improve documentation
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Jan  6 02:14:24 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 06 Jan 2013 01:14:24 +0000
Subject: [New-bugs-announce] [issue16874] setup.py upload option repeated in
	docs
Message-ID: <1357434864.16.0.480016196716.issue16874@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The following page:

http://docs.python.org/dev/distutils/uploading.html

says, "Other upload options include --repository= or --repository= where url..."

I haven't looked into what the correct wording is meant to be.

----------
assignee: eric.araujo
components: Distutils, Documentation
keywords: easy
messages: 179162
nosy: chris.jerdonek, eric.araujo, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: setup.py upload option repeated in docs
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Jan  6 03:49:22 2013
From: report at bugs.python.org (Glenn)
Date: Sun, 06 Jan 2013 02:49:22 +0000
Subject: [New-bugs-announce] [issue16875] in 3.3.0 windows 64 idle editor
Message-ID: <1357440562.93.0.0668661513739.issue16875@psf.upfronthosting.co.za>


New submission from Glenn:

when in the Idle editor this line command does not work:
>>> print "Hello World!"

does not work it says it is a syntax error but 

>>> x="Hello World!"
>>> x
produces this
'Hello World!'

----------
components: IDLE
messages: 179164
nosy: pargo
priority: normal
severity: normal
status: open
title: in 3.3.0 windows 64 idle editor
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Jan  6 04:30:02 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 06 Jan 2013 03:30:02 +0000
Subject: [New-bugs-announce] [issue16876] epoll: reuse epoll_event buffer
	instead of allocating a	new one at each poll()
Message-ID: <1357443002.47.0.422738072867.issue16876@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

Currently, epoll.poll() allocates an epoll_event buffer every time/ this is bad, because it changes an O(number of ready FDs) syscall into a O(maxevents/FD_SETSIZE) complexity.
The patch attached allocates a epoll events buffer per epoll instance, and it only gets reallocated when necessary (note that the reallocation heuristic will probably be improved in #16873 (and having a per instance maxevents count will likely be useful).

Here's a benchmark without patch:
$ ./python -m timeit -s 'import select; ep = select.epoll(); ep.register(1, select.EPOLLOUT)' 'ep.poll()'
100000 loops, best of 3: 4.25 usec per loop

With patch:
$ ./python -m timeit -s 'import select; ep = select.epoll(); ep.register(1, select.EPOLLOUT)' 'ep.poll()'
100000 loops, best of 3: 3.38 usec per loop

----------
components: Extension Modules
files: epoll_realloc.diff
keywords: needs review, patch
messages: 179167
nosy: neologix
priority: normal
severity: normal
stage: patch review
status: open
title: epoll: reuse epoll_event buffer instead of allocating a new one at each poll()
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file28585/epoll_realloc.diff

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

From report at bugs.python.org  Sun Jan  6 05:25:15 2013
From: report at bugs.python.org (Ian Shields)
Date: Sun, 06 Jan 2013 04:25:15 +0000
Subject: [New-bugs-announce] [issue16877] Odd behavior of ~ in
	os.path.abspath and os.path.realpath
Message-ID: <1357446315.42.0.750501561867.issue16877@psf.upfronthosting.co.za>


New submission from Ian Shields:

Filespecs that start with ~ are not properly handled by os.path.realpath or os.path.abspath (and maybe other functions). Following console output from Fedora 17 using Puthon 3.2 illustrates the issue. Similar issue in 2.7
[ian at attic4 developerworks]$ cd ..
[ian at attic4 ~]$ mkdir testpath
[ian at attic4 ~]$ cd testpath
[ian at attic4 testpath]$ pwd
/home/ian/testpath
[ian at attic4 testpath]$ python3
Python 3.2.3 (default, Jun  8 2012, 05:36:09) 
[GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.path.abspath("~")
'/home/ian/testpath/~'
>>> os.path.realpath("~/xxx/zzz")
'/home/ian/testpath/~/xxx/zzz'
>>> os.path.abspath("~/..")
'/home/ian/testpath'

Function should probably use expanduser to determine if path is already absolute. Documentation at http://docs.python.org/3/library/os.path.html is also misleading as this is not how these functions work if given an absolute path to start with.

----------
components: None
messages: 179170
nosy: ibshields
priority: normal
severity: normal
status: open
title: Odd behavior of ~ in os.path.abspath and os.path.realpath
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Jan  6 10:41:39 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 06 Jan 2013 09:41:39 +0000
Subject: [New-bugs-announce] [issue16878] argparse: positional args with
	nargs='*' defaults to []
Message-ID: <1357465299.57.0.35284685768.issue16878@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

In argparse, positional arguments with nargs='*' default to [] rather None, even if default=None is passed explicitly.  The documentation says otherwise:

"The default keyword argument of add_argument(), whose value defaults to None, specifies what value should be used if the command-line argument is not present. ... For positional arguments with nargs equal to ? or *, the default value is used when no command-line argument was present:"

(from http://docs.python.org/dev/library/argparse.html#default )

import argparse

def parse(args, **kwargs):
    parser = argparse.ArgumentParser()
    parser.add_argument('foo', **kwargs)
    ns = parser.parse_args(args)
    print(repr(ns.foo))

parse([], nargs='?')                # None
parse([], nargs='*')                # []    <--
parse([], nargs='*', default=None)  # []    <--
parse([], nargs='*', default=False) # False
parse([], nargs='*', default=0)     # 0

Three options include (there may be more):

(1) document the behavior
(2) make a default of None yield None
(3) do (2), but change the default to [] instead of None when nargs='*'

----------
components: Library (Lib)
messages: 179174
nosy: bethard, chris.jerdonek
priority: normal
severity: normal
status: open
title: argparse: positional args with nargs='*' defaults to []
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Jan  6 13:44:37 2013
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Sun, 06 Jan 2013 12:44:37 +0000
Subject: [New-bugs-announce] [issue16879] distutils.command.config uses
	fragile constant temporary	file name
Message-ID: <1357476277.46.0.0647034504115.issue16879@psf.upfronthosting.co.za>


New submission from Micha? G?rny:

The distutils.command.config module reads:

    def _gen_temp_sourcefile(self, body, headers, lang):
        filename = "_configtest" + LANG_EXT[lang]

which means that every time one of the functions is used, a temporary file with the same name will be created. This is really fragile and fails terribly whenever more than one process tries to use the relevant functions in the same working directory.

I believe this code should use the tempfile module to generate unique temporary files names instead.

----------
assignee: eric.araujo
components: Distutils
messages: 179179
nosy: eric.araujo, mgorny, tarek
priority: normal
severity: normal
status: open
title: distutils.command.config uses fragile constant temporary file name
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/issue16879>
_______________________________________

From report at bugs.python.org  Sun Jan  6 16:20:25 2013
From: report at bugs.python.org (Jeffrey Armstrong)
Date: Sun, 06 Jan 2013 15:20:25 +0000
Subject: [New-bugs-announce] [issue16880] Importing "imp" will fail if
	dynamic loading not	supported
Message-ID: <1357485625.89.0.912311839023.issue16880@psf.upfronthosting.co.za>


New submission from Jeffrey Armstrong:

On a platform where dynamic loading is unsupported, the function "imp_load_dynamic" is not compiled (Python/import.c:1775), and the Python function "load_dynamic" (Python/import.c:1845) will not be included in the _imp module.  However, Lib/imp.py attempts to import "load_dynamic" from _imp (Lib/imp.py:9), causing an ImportError if dynamic loading is unsupported.  

The interpreter is unable to start under these circumstances.  The error was encountered on m68k-atari-mint using GCC as the compiler.  This platform is a desktop environment, but has no support for true shared objects and libraries.

----------
components: Library (Lib)
messages: 179186
nosy: Jeffrey.Armstrong
priority: normal
severity: normal
status: open
title: Importing "imp" will fail if dynamic loading not supported
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Jan  6 16:32:47 2013
From: report at bugs.python.org (Jeffrey Armstrong)
Date: Sun, 06 Jan 2013 15:32:47 +0000
Subject: [New-bugs-announce] [issue16881] Py_ARRAY_LENGTH macro incorrect
	with GCC < 3.1
Message-ID: <1357486367.34.0.653712599224.issue16881@psf.upfronthosting.co.za>


New submission from Jeffrey Armstrong:

The Py_ARRAY_LENGTH macro (Include/pymacro.h:36) checks to see if using GCC by simply looking for __GCC__ being defined.  If so, it uses the GCC extension function "__builtin_types_compatible_p."  However, this function was not introduced until GCC 3.1.  This simple check for a GCC compiler causes the Python build to fail on GCC < 3.1 (2.95 for example).

The check should actually be:

#if (defined(__GNUC__) && !defined(__STRICT_ANSI__) && \
    ((__GNUC__ == 3) && (__GNU_MINOR__) >= 1) || (__GNUC__ >= 4)))

Similar checks are made in other locations in the core library, just not here.  

This bug was discovered while attempting a build on m68k-atari-mint, which relies on GCC 2.95.3.  Other systems may also be using this compiler still.

----------
components: Build
messages: 179187
nosy: Jeffrey.Armstrong
priority: normal
severity: normal
status: open
title: Py_ARRAY_LENGTH macro incorrect with GCC < 3.1
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Mon Jan  7 07:25:28 2013
From: report at bugs.python.org (Isaac (.ike) Levy)
Date: Mon, 07 Jan 2013 06:25:28 +0000
Subject: [New-bugs-announce] [issue16882] Python 2.7 has 73 files with hard
	references to	/usr/local when building on *NIX
Message-ID: <1357539928.45.0.253239442495.issue16882@psf.upfronthosting.co.za>


New submission from Isaac (.ike) Levy:

There are currently 73 files with hard-coded references to /usr/local,

To see what I'm talking about, unpack a source Python tarball, and check it out like so:

# cd Python-2.7.3
# grep -Rl '\/usr\/local' ./* | wc -l
73

To read more detail,
# grep -R '\/usr\/local' ./*


Some of these hardcoded /usr/local lines are innocuous or merely misleading,

./README:        1) CONFIG_SHELL=/usr/local/bin/bash CC=cc RANLIB=: \
- or -
./Demo/tkinter/guido/ManPage.py:    MANDIR = '/usr/local/man/mann'

Yet, some of these create unexpected installation behavior when configuring using the --prefix flag to specify an alternative install location, 

./setup.py:        # Ensure that /usr/local is always used
- or-
./setup.py:            db_inc_paths.append('/usr/local/BerkeleyDB.4.%d/include' % x)

(Are items installed outside of your --prefix?  Which ones?  What about dependencies compiled outside of /usr/local?)


###################
A terrible solution

It seems most UNIX package managers elect some form of finding and replace all occurances,  for example,

# dirty deeds, done dirt cheap
for i in `grep -Rl '\/usr\/local' ./*` ; do
   safe sed -i 's#\/usr\/local#\/usr\/mypath#g' "$i"
done

./configure --prefix="/usr/mypath"
...continue the make dance...


#################
A better solution

Prioritize some re-factoring work Python 2.7.3 installation, just enough to get sysadmins like myself by until Python3000 is commonplace...

I'd be happy to help, but as a community outsider, I'm not sure how to make the cleanup work stick.

----------
components: Installation
messages: 179246
nosy: ikeaxial
priority: normal
severity: normal
status: open
title: Python 2.7 has 73 files with hard references to /usr/local when building on *NIX
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Mon Jan  7 07:29:16 2013
From: report at bugs.python.org (Isaac (.ike) Levy)
Date: Mon, 07 Jan 2013 06:29:16 +0000
Subject: [New-bugs-announce] [issue16883] "--enable-shared" during configure
	forces "2.7.3" to	build as "2.7.2+" on Ubuntu 11.10
Message-ID: <1357540156.49.0.232787491234.issue16883@psf.upfronthosting.co.za>


New submission from Isaac (.ike) Levy:

Host OS: Ubuntu 11.10 (oneiric)
--enable-shared flag during configure forces 2.7.3 to build as 2.7.2+

TO REPLICATE:

unpack Python tarball,

# cd Python-2.7.3/
# ./configure --enable-shared
# make
# ./python -V
2.7.2+

# make clean ; ./configure --enable-shared ; make ; ./python -V
2.7.3


--
Additionally, 2.7.2+ build seems to carry over a resolved urandom issue,

    # (post-install on Ubuntu 11.10)
    # /usr/local/bin/python
    Python 2.7.2+ (default, Oct  4 2011, 20:41:12)
    [GCC 4.6.1] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> from os import urandom
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ImportError: cannot import name urandom
    >>>

----------
components: Installation
messages: 179247
nosy: ikeaxial
priority: normal
severity: normal
status: open
title: "--enable-shared" during configure forces "2.7.3" to build as "2.7.2+" on Ubuntu 11.10
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Mon Jan  7 12:34:53 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 07 Jan 2013 11:34:53 +0000
Subject: [New-bugs-announce] [issue16884] logging handler automatically
	added starting in 3.2+
Message-ID: <1357558493.08.0.0121878103652.issue16884@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

Starting in 3.2, the logging module no longer outputs the following message when logging and no handlers are configured for the root logger:

    log = logging.getLogger()
    log.error('test')

'No handlers could be found for logger "root"'

However, I can't seem to find any version-changed about this in the docs.  The code change may be from this commit: c86dc2bd3ae8

Incidentally, I also noticed that three logging paragraphs begin with "PLEASE NOTE:"  Those should probably be changed to ".. note::" etc.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 179257
nosy: chris.jerdonek, docs at python, vinay.sajip
priority: normal
severity: normal
status: open
title: logging handler automatically added starting in 3.2+
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Jan  7 15:43:50 2013
From: report at bugs.python.org (Jamie Spence)
Date: Mon, 07 Jan 2013 14:43:50 +0000
Subject: [New-bugs-announce] [issue16885] SQLite3 iterdump ordering
Message-ID: <1357569830.11.0.727312766793.issue16885@psf.upfronthosting.co.za>


New submission from Jamie Spence:

After dumping a database with iterdump, trying to execute the dumped SQL sometimes results in an error because the statement order may be wrong. In my case, it is a view that is being created before the view it is referencing. Would ordering the sqlite_master table view query in dump.py by ID fix this issue?

----------
messages: 179267
nosy: Jamie.Spence
priority: normal
severity: normal
status: open
title: SQLite3 iterdump ordering
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jan  7 18:12:14 2013
From: report at bugs.python.org (Frank Wierzbicki)
Date: Mon, 07 Jan 2013 17:12:14 +0000
Subject: [New-bugs-announce] [issue16886] Doctests in test_dictcomp depend
	on dict order
Message-ID: <1357578734.97.0.0359073794819.issue16886@psf.upfronthosting.co.za>


New submission from Frank Wierzbicki:

test_dictcomp hard codes the dict output of various tests of Dict Comprehensions. Since Jython has a different dict ordering we are currently altering this test. When we get to 3.x it will be nicer if we can use this test as is. Also I've seen some discussion on Python-Dev that CPython devs want to get rid of dict ordering in the tests anyway. Patch attached, which assigns the dict values to a variable and compares it in the tests instead of just dumping the output in the doctests.

----------
components: Tests
files: test_dictcomp.patch
keywords: patch
messages: 179272
nosy: fwierzbicki
priority: normal
severity: normal
status: open
title: Doctests in test_dictcomp depend on dict order
versions: Python 3.4
Added file: http://bugs.python.org/file28613/test_dictcomp.patch

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

From report at bugs.python.org  Mon Jan  7 21:57:42 2013
From: report at bugs.python.org (Roger Serwy)
Date: Mon, 07 Jan 2013 20:57:42 +0000
Subject: [New-bugs-announce] [issue16887] IDLE - tabify/untabify applied
	when clicking Cancel
Message-ID: <1357592262.2.0.644397432764.issue16887@psf.upfronthosting.co.za>


New submission from Roger Serwy:

Krystian Rosi?ski notified me about an error with Tabify/Untabify. Clicking cancel still performs the operation because the _asktabwidth function in Lib/idlelib/EditorWindow.py always returns a number, regardless of cancel being clicked.

This bug is visibly noticeable with IdleX since it highlights all \t Tabs, but not with the original IDLE.

The attached patch solves the problem.

----------
components: IDLE
files: tabify.patch
keywords: patch
messages: 179282
nosy: serhiy.storchaka, serwy
priority: low
severity: normal
stage: patch review
status: open
title: IDLE - tabify/untabify applied when clicking Cancel
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28620/tabify.patch

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

From report at bugs.python.org  Mon Jan  7 23:40:41 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 07 Jan 2013 22:40:41 +0000
Subject: [New-bugs-announce] [issue16888] Fix test discovery for
	test_array.py
Message-ID: <1357598441.54.0.816719600523.issue16888@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Here's a patch to fix test_array.py

----------
components: Tests
files: test_array.diff
keywords: patch
messages: 179291
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_array.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28624/test_array.diff

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

From report at bugs.python.org  Tue Jan  8 02:58:04 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 08 Jan 2013 01:58:04 +0000
Subject: [New-bugs-announce] [issue16889] facilitate log output starting at
	beginning of line
Message-ID: <1357610284.86.0.286455325565.issue16889@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

In certain situations (e.g. when logging while using unittest), log messages can start in the middle of a line, for example:

........................log: [INFO] foo
..................................................

It was trickier than I thought it needed to be to get log messages to start at the beginning of a line, which seems like a reasonable expectation.

It would be good if the logging module (or perhaps unittest for when running tests?) provided assistance here, either through documentation or an enhancement.

The way I did this was wrap sys.stderr in a class that remembers the last written character, pass this to the test runner, and then subclass logging.StreamHandler to have emit() check whether a newline was the last character.  But perhaps there is a much simpler way.

----------
components: Library (Lib)
messages: 179304
nosy: chris.jerdonek, r.david.murray, vinay.sajip
priority: normal
severity: normal
status: open
title: facilitate log output starting at beginning of line
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Jan  8 03:58:47 2013
From: report at bugs.python.org (Javier Domingo)
Date: Tue, 08 Jan 2013 02:58:47 +0000
Subject: [New-bugs-announce] [issue16890] minidom error
Message-ID: <1357613927.36.0.626944272723.issue16890@psf.upfronthosting.co.za>


New submission from Javier Domingo:

Hi I found something like a bug, I can't get this working:

import xml.dom.minidom as minidom
document="""<a>
    <b>
        <c />
        <c />
    </b>
</a>""" 
dom = minidom.parseString(document)

dom.childNodes
dom.childNodes[0].childNodes
dom.childNodes[0].childNodes[1].childNodes

def delete_recursive(parent):
    for child in parent.childNodes:
        if child.hasChildNodes():
            delete_recursive(child)
        else:
            parent.removeChild(child)

delete_recursive(dom)

dom.childNodes
dom.childNodes[0].childNodes
dom.childNodes[0].childNodes[0].childNodes

Executes as:
>>> import xml.dom.minidom as minidom
>>> document="""<a>
...     <b>
...         <c />
...         <c />
...     </b>
... </a>""" 
>>> dom = minidom.parseString(document)
>>> 
>>> dom.childNodes
[<DOM Element: a at 0x7f5408e717d0>]
>>> dom.childNodes[0].childNodes
[<DOM Text node "'\n    '">, <DOM Element: b at 0x7f5408e71f50>, <DOM Text node "'\n'">]
>>> dom.childNodes[0].childNodes[1].childNodes
[<DOM Text node "'\n        '">, <DOM Element: c at 0x7f5408e93290>, <DOM Text node "'\n        '">, <DOM Element: c at 0x7f5408e93310>, <DOM Text node "'\n    '">]
>>> 
>>> def delete_recursive(parent):
...     for child in parent.childNodes:
...         if child.hasChildNodes():
...             delete_recursive(child)
...         else:
...             parent.removeChild(child)
... 
>>> delete_recursive(dom)
>>> 
>>> dom.childNodes
[<DOM Element: a at 0x7f5408e717d0>]
>>> dom.childNodes[0].childNodes
[<DOM Element: b at 0x7f5408e71f50>]
>>> dom.childNodes[0].childNodes[0].childNodes
[<DOM Text node "'\n        '">, <DOM Element: c at 0x7f5408e93290>, <DOM Text node "'\n        '">, <DOM Element: c at 0x7f5408e93310>, <DOM Text node "'\n    '">]

The problem here is this last line, those text nodes shouldn't be here! I have traced the problem, and seem that the for loop is not correctly executed

----------
components: XML
messages: 179309
nosy: txomon
priority: normal
severity: normal
status: open
title: minidom error
versions: Python 3.2

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

From report at bugs.python.org  Tue Jan  8 09:14:31 2013
From: report at bugs.python.org (Dmitry Mugtasimov)
Date: Tue, 08 Jan 2013 08:14:31 +0000
Subject: [New-bugs-announce] [issue16891] Fix docs about module search order
Message-ID: <1357632871.49.0.196561776247.issue16891@psf.upfronthosting.co.za>


New submission from Dmitry Mugtasimov:

http://docs.python.org/2/tutorial/modules.html should be rewritten.
AS IS
6.1.2. The Module Search Path

When a module named spam is imported, the interpreter first searches for a built-in module with that name. If not found, it then searches for a file named spam.py in a list of directories given by the variable sys.path. sys.path is initialized from these locations:

TO BE
6.1.2. The Module Search Path

When a module named spam is imported, the interpreter first searches for a built-in module with that name. If not found, it looks in the containing package (the package of which the current module is a submodule). If not found, it then searches for a file named spam.py in a list of directories given by the variable sys.path. sys.path is initialized from these locations:

------
Note that now "6.1.2. The Module Search Path" and "6.4.2. Intra-package References" are contradictary since in 6.4.2 it is said: "In fact, such references are so common that the import statement first looks in the containing package before looking in the standard module search path.", but this is not reflected in 6.1.2.

------
EXAMPLE (for more information see  http://stackoverflow.com/questions/14183541/why-python-finds-module-instead-of-package-if-they-have-the-same-name#comment19687166_14183541 ):
/home/dmugtasimov/tmp/name-res3/xyz
    __init__.py
    a.py
    b.py
    t.py
    xyz.py

Files init.py, b.py and xyz.py are empty
File a.py:

import os, sys
ROOT_DIRECTORY = os.path.abspath(os.path.join(os.path.dirname(__file__), '..'))
if not sys.path or ROOT_DIRECTORY not in sys.path:
    print 'sys.path is modified in a.py'
    sys.path.insert(0, ROOT_DIRECTORY)
else:
    print 'sys.path is NOT modified in a.py'

print 'sys.path:', sys.path
print 'BEFORE import xyz.b'
import xyz.b
print 'AFTER import xyz.b'

File t.py:

import os, sys
ROOT_DIRECTORY = os.path.abspath(os.path.join(os.path.dirname(__file__), '..'))
if not sys.path or ROOT_DIRECTORY not in sys.path:
    print 'sys.path is modified in t.py'
    sys.path.insert(0, ROOT_DIRECTORY)
else:
    print 'sys.path is NOT modified in t.py'

import xyz.a

Run:

python a.py

Output:

    sys.path is modified in a.py
    sys.path: ['/home/dmugtasimov/tmp/name-res3', '/home/dmugtasimov/tmp/name-res3/xyz',
     '/usr/local/lib/python2.7/dist-packages/tornado-2.3-py2.7.egg',
     '/home/dmugtasimov/tmp/name-res3/xyz', '/usr/lib/python2.7',
     '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk',
     '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload',
     '/usr/local/lib/python2.7/dist-packages',
     '/usr/local/lib/python2.7/dist-packages/setuptools-0.6c11-py2.7.egg-info',
     '/usr/lib/python2.7/dist-packages',
     '/usr/lib/python2.7/dist-packages/PIL',
     '/usr/lib/python2.7/dist-packages/gst-0.10',
     '/usr/lib/python2.7/dist-packages/gtk-2.0',
     '/usr/lib/python2.7/dist-packages/ubuntu-sso-client']
    BEFORE import xyz.b
    AFTER import xyz.b

Run:

python -vv a.py

Output:

    import xyz # directory /home/dmugtasimov/tmp/name-res3/xyz
    # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__module.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__.py
    # /home/dmugtasimov/tmp/name-res3/xyz/__init__.pyc matches /home/dmugtasimov/tmp/name-res3/xyz/__init__.py
    import xyz # precompiled from /home/dmugtasimov/tmp/name-res3/xyz/__init__.pyc
    # trying /home/dmugtasimov/tmp/name-res3/xyz/b.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/bmodule.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/b.py
    # /home/dmugtasimov/tmp/name-res3/xyz/b.pyc matches /home/dmugtasimov/tmp/name-res3/xyz/b.py
    import xyz.b # precompiled from /home/dmugtasimov/tmp/name-res3/xyz/b.pyc

Run:

python t.py

Output:

    sys.path is modified in t.py
    sys.path is NOT modified in a.py
    sys.path: ['/home/dmugtasimov/tmp/name-res3', '/home/dmugtasimov/tmp/name-res3/xyz',
     '/usr/local/lib/python2.7/dist-packages/tornado-2.3-py2.7.egg',
     '/home/dmugtasimov/tmp/name-res3/xyz', '/usr/lib/python2.7',
     '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk',
     '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload',
     '/usr/local/lib/python2.7/dist-packages',
     '/usr/local/lib/python2.7/dist-packages/setuptools-0.6c11-py2.7.egg-info',
     '/usr/lib/python2.7/dist-packages',
     '/usr/lib/python2.7/dist-packages/PIL',
     '/usr/lib/python2.7/dist-packages/gst-0.10',
     '/usr/lib/python2.7/dist-packages/gtk-2.0',
     '/usr/lib/python2.7/dist-packages/ubuntu-sso-client']
    BEFORE import xyz.b
    Traceback (most recent call last):
      File "t.py", line 9, in <module>
        import xyz.a
      File "/home/dmugtasimov/tmp/name-res3/xyz/a.py", line 11, in <module>
        import xyz.b
    ImportError: No module named b

Run:

python -vv t.py

Output:

    import xyz # directory /home/dmugtasimov/tmp/name-res3/xyz
    # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__module.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__.py
    # /home/dmugtasimov/tmp/name-res3/xyz/__init__.pyc matches /home/dmugtasimov/tmp/name-res3/xyz/__init__.py
    import xyz # precompiled from /home/dmugtasimov/tmp/name-res3/xyz/__init__.pyc
    # trying /home/dmugtasimov/tmp/name-res3/xyz/a.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/amodule.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/a.py
    # /home/dmugtasimov/tmp/name-res3/xyz/a.pyc matches /home/dmugtasimov/tmp/name-res3/xyz/a.py
    import xyz.a # precompiled from /home/dmugtasimov/tmp/name-res3/xyz/a.pyc
    # trying /home/dmugtasimov/tmp/name-res3/xyz/os.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/osmodule.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/os.py
    # trying /home/dmugtasimov/tmp/name-res3/xyz/os.pyc
    # trying /home/dmugtasimov/tmp/name-res3/xyz/sys.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/sysmodule.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/sys.py
    # trying /home/dmugtasimov/tmp/name-res3/xyz/sys.pyc
    # trying /home/dmugtasimov/tmp/name-res3/xyz/xyz.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/xyzmodule.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/xyz.py
    # /home/dmugtasimov/tmp/name-res3/xyz/xyz.pyc matches /home/dmugtasimov/tmp/name-res3/xyz/xyz.py
    import xyz.xyz # precompiled from /home/dmugtasimov/tmp/name-res3/xyz/xyz.pyc
    #   clear[2] __file__
    #   clear[2] __package__
    #   clear[2] sys
    #   clear[2] ROOT_DIRECTORY
    #   clear[2] __name__
    #   clear[2] os
    sys.path is modified in t.py
    sys.path is NOT modified in a.py
    sys.path: ['/home/dmugtasimov/tmp/name-res3', '/home/dmugtasimov/tmp/name-res3/xyz',
     '/usr/local/lib/python2.7/dist-packages/tornado-2.3-py2.7.egg',
     '/home/dmugtasimov/tmp/name-res3/xyz', '/usr/lib/python2.7',
     '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk',
     '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload',
     '/usr/local/lib/python2.7/dist-packages',
     '/usr/local/lib/python2.7/dist-packages/setuptools-0.6c11-py2.7.egg-info',
     '/usr/lib/python2.7/dist-packages',
     '/usr/lib/python2.7/dist-packages/PIL',
     '/usr/lib/python2.7/dist-packages/gst-0.10',
     '/usr/lib/python2.7/dist-packages/gtk-2.0',
     '/usr/lib/python2.7/dist-packages/ubuntu-sso-client']
    BEFORE import xyz.b
    Traceback (most recent call last):
      File "t.py", line 9, in <module>
        import xyz.a
      File "/home/dmugtasimov/tmp/name-res3/xyz/a.py", line 11, in <module>
        import xyz.b
    ImportError: No module named b

As you see sys.path is the same for both cases:

sys.path: ['/home/dmugtasimov/tmp/name-res3', '/home/dmugtasimov/tmp/name-res3/xyz', '/usr/local/lib/python2.7/dist-packages/tornado-2.3-py2.7.egg', '/home/dmugtasimov/tmp/name-res3/xyz', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/local/lib/python2.7/dist-packages/setuptools-0.6c11-py2.7.egg-info', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PIL', '/usr/lib/python2.7/dist-packages/gst-0.10', '/usr/lib/python2.7/dist-packages/gtk-2.0', '/usr/lib/python2.7/dist-packages/ubuntu-sso-client']

But the behaviour is different. For a.py python searches for package xyz first, and them for module b in it:

    import xyz # directory /home/dmugtasimov/tmp/name-res3/xyz
    # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__module.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__.py
    # /home/dmugtasimov/tmp/name-res3/xyz/__init__.pyc matches /home/dmugtasimov/tmp/name-res3/xyz/__init__.py
    import xyz # precompiled from /home/dmugtasimov/tmp/name-res3/xyz/__init__.pyc
    # trying /home/dmugtasimov/tmp/name-res3/xyz/b.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/bmodule.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/b.py
    # /home/dmugtasimov/tmp/name-res3/xyz/b.pyc matches /home/dmugtasimov/tmp/name-res3/xyz/b.py
    import xyz.b # precompiled from /home/dmugtasimov/tmp/name-res3/xyz/b.pyc

In other words:

    Search PACKAGE xyz in directory sys.path[0] -> FOUND
    Search module b in PACKAGE xyz -> FOUND
    Continue execution

For t.py it searches for moduel xyz in the same directory as a.py itself and then fails to find module b in module xyz:

    # trying /home/dmugtasimov/tmp/name-res3/xyz/xyz.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/xyzmodule.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/xyz.py
    # /home/dmugtasimov/tmp/name-res3/xyz/xyz.pyc matches /home/dmugtasimov/tmp/name-res3/xyz/xyz.py
    import xyz.xyz # precompiled from /home/dmugtasimov/tmp/name-res3/xyz/xyz.pyc

In other words:

    Search MODULE xyz in directory in the same directory as a.py (or sys.path[1] ?) -> FOUND
    Search MODULE b in MODULE xyz -> NOT FOUND
    ImportError

So it looks like if "import xyz.b" bahaves different depending on how a.py was initially loaded as a script or imported from another module.

----------
assignee: docs at python
components: Documentation
messages: 179321
nosy: dmugtasimov, docs at python
priority: normal
severity: normal
status: open
title: Fix docs about module search order
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jan  8 14:44:24 2013
From: report at bugs.python.org (Robert Oeffner)
Date: Tue, 08 Jan 2013 13:44:24 +0000
Subject: [New-bugs-announce] [issue16892] Windows bug picking up stdin from
	a pipe
Message-ID: <1357652664.69.0.880454684679.issue16892@psf.upfronthosting.co.za>


New submission from Robert Oeffner:

Hi,

This is a bug that seems to exist on python 2.7, python 3.3 on Windows versions XP, Vista, 7 and 8 and has been around for some years, presumably also in other python versions. It is only recently I have managed to better isolate it although not completely.

My Windows PC is set up with some doskey macros that are loaded at each
instance of the commandline interpreter cmd.exe with the registry key
HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun\mymacros.cmd
Unfortunately this seems to delete stdin when stdin is piped to python scripts that runs another executable invoked with subprocess. In this case the command:

python32 testsubproc.py < mytextfile.txt

will not work. The textfile mytextfile.txt will be ignored. If subprocess is invoked with shell=False the textfile does get piped into stdin. This is however not an option as our porgrams are distributed on other platforms. It would also give an inconsistent experience on the same OS (Windows).

If mymacros.cmd is called interactively from the command prompt the problem does not exist and stdin can be piped into the python script with no problem.

I have attached a working script below which includes a comment section with a small C++ program and the registry key in question to demonstrate the problem.

I would be grateful if there are people who know how to get to the bottom of this bug or even fix it.


Many thanks,


Robert

----------
components: Build, Windows
files: testsubproc.py
messages: 179352
nosy: oeffner
priority: normal
severity: normal
status: open
title: Windows bug picking up stdin from a pipe
type: behavior
versions: Python 2.6, Python 2.7, Python 3.3
Added file: http://bugs.python.org/file28631/testsubproc.py

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

From report at bugs.python.org  Tue Jan  8 17:45:12 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 08 Jan 2013 16:45:12 +0000
Subject: [New-bugs-announce] [issue16893] Create IDLE help.txt from
	Doc/library/idle.rst
Message-ID: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Lib/idlelib/help.txt and Doc/library/idle.rst contain almost exactly the same information, only formatted a bit differently.  This issue is to suggest the merger of the two files, by way of creating help.txt from idle.rst as a part of the build or install process.

This could be as simple as merely copying the one to the other, but that of course leaves in place all reST directives that mean nothing to a simple text document.  Thus, idle.rst should be processed to create help.txt.  This could be done with sphinx/docutils, but to avoid having the CPython build process (not just the doc build process) depend on those tools, I think a very simple dedicated script could be created to do the processing without much trouble.

As far as I can tell, this new script would only have to do a few simple steps:

- Remove comments (including index markers, etc.)
- Remove reST roles (replace ":role:`" with "`", possibly remove "`" as well)
- Remove backslash escapes
- Remove (or undouble) double colons
- Replace "#." with "1.", etc.

Thoughts?

----------
assignee: docs at python
components: Documentation, IDLE
messages: 179362
nosy: Todd.Rovito, docs at python, eric.araujo, zach.ware
priority: normal
severity: normal
status: open
title: Create IDLE help.txt from Doc/library/idle.rst
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Jan  8 19:43:12 2013
From: report at bugs.python.org (David Beazley)
Date: Tue, 08 Jan 2013 18:43:12 +0000
Subject: [New-bugs-announce] [issue16894] Function attribute access doesn't
	invoke methods in dict	subclasses
Message-ID: <1357670592.25.0.470525675752.issue16894@psf.upfronthosting.co.za>


New submission from David Beazley:

Suppose you subclass a dictionary:

class mdict(dict):
    def __getitem__(self, index):
        print('Getting:', index)
        return super().__getitem__(index)

Now, suppose you define a function and perform these steps that reassign the function's attribute dictionary:

>>> def foo():
...     pass
... 
>>> foo.__dict__ = mdict()
>>> foo.x = 23
>>> foo.x          # Observe: No output from overridden __getitem__
23
>>> type(foo.__dict__)
<class '__main__.mdict'>
>>> foo.__dict__
{'x': 23}
>>> 

Carefully observe that access to foo.x does not invoke the overridden __getitem__() method in mdict.  Instead, it just directly accesses the default __getitem__() on dict. 

Admittedly, this is a really obscure corner case.  However, if the __dict__ attribute of a function can be legally reassigned, it might be nice for inheritance to work ;-).

----------
components: Interpreter Core
messages: 179364
nosy: dabeaz
priority: normal
severity: normal
status: open
title: Function attribute access doesn't invoke methods in dict subclasses
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Jan  8 21:43:41 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 08 Jan 2013 20:43:41 +0000
Subject: [New-bugs-announce] [issue16895] Batch file to mimic 'make' on
	Windows
Message-ID: <1357677821.21.0.151237367429.issue16895@psf.upfronthosting.co.za>


New submission from Zachary Ware:

I find myself frustrated with some of the hoops I have to jump through and extra things I have to remember when I want to play around with Python on Windows.  To make things a little easier, I've created a 'make.bat' file that can sit in the root of the repository and do a few of the more common tasks:

make [build] [-64] -- Runs Tools\buildbot\build[-amd64].bat
make clean [-64] -- Runs Tools\buildbot\clean[-amd64].bat
make doc [args] -- Runs Doc\make.bat [args] with %PYTHON% set to 'py.exe -2'
make patchcheck -- Runs Tools\scripts\patchcheck.py
make test [test args] -- Runs the test suite with passed arguments

It seems to work pretty well for me and I think it could be very useful to others, particularly new contributors.  I'm sure there's plenty of room for improvement, though :)

I don't know if this script might interfere or conflict with Cygwin or other tools; if so and it were decided to include this file, it could easily be renamed to 'wmake.bat' or some such.

Hope this is useful enough to include, or at least useful to someone else :)

----------
components: Windows
files: Make.bat
messages: 179369
nosy: zach.ware
priority: normal
severity: normal
status: open
title: Batch file to mimic 'make' on Windows
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28632/Make.bat

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

From report at bugs.python.org  Tue Jan  8 22:07:48 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 08 Jan 2013 21:07:48 +0000
Subject: [New-bugs-announce] [issue16896] Fix test discovery for
	test_asyncore.py
Message-ID: <1357679268.03.0.58943461997.issue16896@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Here's the fix for test_asyncore.py.

----------
components: Tests
files: test_asyncore_fix.diff
keywords: patch
messages: 179373
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_asyncore.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28633/test_asyncore_fix.diff

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

From report at bugs.python.org  Tue Jan  8 22:39:05 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 08 Jan 2013 21:39:05 +0000
Subject: [New-bugs-announce] [issue16897] Fix test discovery for
	test_bisect.py
Message-ID: <1357681145.64.0.619169785001.issue16897@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Here's the fix for test_bisect.py.

This one has an extra change, that of replacing the manual method of obtaining c_bisect and py_bisect with two calls to support.import_fresh_module.

This one also has an extra wrench thrown in the gears by including a few doctests.  I haven't changed anything in relation to those doctests, but I wonder if there's really any point to keeping them there considering they claim to be pulled from the docs but are in fact significantly different from what is in the docs these days.

----------
components: Tests
files: test_bisect_fix.diff
keywords: patch
messages: 179374
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_bisect.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28634/test_bisect_fix.diff

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

From report at bugs.python.org  Tue Jan  8 22:43:35 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 08 Jan 2013 21:43:35 +0000
Subject: [New-bugs-announce] [issue16898] Fix test discovery for
	test_bufio.py
Message-ID: <1357681415.26.0.614642834127.issue16898@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
components: Tests
files: test_bufio_fix.diff
keywords: patch
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_bufio.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28635/test_bufio_fix.diff

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

From report at bugs.python.org  Tue Jan  8 23:06:03 2013
From: report at bugs.python.org (Vladimir Rutsky)
Date: Tue, 08 Jan 2013 22:06:03 +0000
Subject: [New-bugs-announce] [issue16899] Add support for C99 complex type
	(_Complex) as	ctypes.c_complex
Message-ID: <1357682763.46.0.590255439385.issue16899@psf.upfronthosting.co.za>


New submission from Vladimir Rutsky:

It would be nice if Python will be able to access variables with C99 complex types through ctypes module.

----------
components: ctypes
messages: 179378
nosy: rutsky
priority: normal
severity: normal
status: open
title: Add support for C99 complex type (_Complex) as ctypes.c_complex
type: enhancement

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

From report at bugs.python.org  Wed Jan  9 00:17:40 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 08 Jan 2013 23:17:40 +0000
Subject: [New-bugs-announce] [issue16900] SSL sockets don't give resource
	warnings
Message-ID: <1357687060.67.0.213189094158.issue16900@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

Python 3.3.0+ (3.3:ab36d3bb5996+, Jan  8 2013, 17:08:35) 
[GCC 4.5.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> del s
__main__:1: ResourceWarning: unclosed <socket.socket object, fd=3, family=2, type=1, proto=0>
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> import ssl
>>> ssl.wrap_socket(s)
<ssl.SSLSocket object, fd=3, family=2, type=1, proto=0>
>>> del s

We can just remove the __del__ on SSLSocket, right?

----------
messages: 179394
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: SSL sockets don't give resource warnings
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Jan  9 00:37:01 2013
From: report at bugs.python.org (py.user)
Date: Tue, 08 Jan 2013 23:37:01 +0000
Subject: [New-bugs-announce] [issue16901] In http.cookiejar.FileCookieJar()
	the .load() and	.revert() methods don't work
Message-ID: <1357688221.9.0.622857187739.issue16901@psf.upfronthosting.co.za>


New submission from py.user:

>>> import http.cookiejar
>>> cjf = http.cookiejar.FileCookieJar()
>>> cjf.load('file.txt')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.3/http/cookiejar.py", line 1767, in load
    self._really_load(f, filename, ignore_discard, ignore_expires)
AttributeError: 'FileCookieJar' object has no attribute '_really_load'
>>> 
>>> 
>>> import http.cookiejar
>>> cjf = http.cookiejar.FileCookieJar('file.txt')
>>> cjf.load()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.3/http/cookiejar.py", line 1767, in load
    self._really_load(f, filename, ignore_discard, ignore_expires)
AttributeError: 'FileCookieJar' object has no attribute '_really_load'
>>>
>>> 
>>> cjf.revert()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.3/http/cookiejar.py", line 1789, in revert
    self.load(filename, ignore_discard, ignore_expires)
  File "/usr/local/lib/python3.3/http/cookiejar.py", line 1767, in load
    self._really_load(f, filename, ignore_discard, ignore_expires)
AttributeError: 'FileCookieJar' object has no attribute '_really_load'
>>>

----------
components: Library (Lib)
messages: 179398
nosy: py.user
priority: normal
severity: normal
status: open
title: In http.cookiejar.FileCookieJar() the .load() and .revert() methods don't work
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Jan  9 09:27:20 2013
From: report at bugs.python.org (brian-cameron-oracle)
Date: Wed, 09 Jan 2013 08:27:20 +0000
Subject: [New-bugs-announce] [issue16902] Add OSS module support for Solaris
Message-ID: <1357720040.2.0.175199652567.issue16902@psf.upfronthosting.co.za>


New submission from brian-cameron-oracle:

Solaris supports OSS, but the attached patch is needed to get it to build.

Note that some of the EXPORT_INT lines in Modules/ossaudiodev.c need to be
#ifndef'ed out on Sun since OSS on Solaris doesn't support them all. 

Does it make sense to use #ifndef like this, or should each EXPORT_INT be encapsulated by its own #ifdef?

----------
components: Extension Modules
files: ossaudiodev.patch
keywords: patch
messages: 179424
nosy: brian-cameron-oracle
priority: normal
severity: normal
status: open
title: Add OSS module support for Solaris
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file28644/ossaudiodev.patch

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

From report at bugs.python.org  Wed Jan  9 10:28:57 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 09 Jan 2013 09:28:57 +0000
Subject: [New-bugs-announce] [issue16903] subprocess.Popen.communicate
	with	universal_newlines=True doesn't accept strings on 3.2
Message-ID: <1357723737.45.0.474075490157.issue16903@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

On 3.2 subprocess.Popen.communicate with universal_newlines=True accepts bytes and doesn't accept strings. 

$ ./python -c "import subprocess; subprocess.Popen(['cat'], stdin=subprocess.PIPE, stdout=subprocess.PIPE, universal_newlines=True).communicate('qwerty')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/serhiy/py/cpython3.2/Lib/subprocess.py", line 833, in communicate
    return self._communicate(input)
  File "/home/serhiy/py/cpython3.2/Lib/subprocess.py", line 1470, in _communicate
    stdout, stderr = self._communicate_with_poll(input)
  File "/home/serhiy/py/cpython3.2/Lib/subprocess.py", line 1537, in _communicate_with_poll
    input_offset += os.write(fd, chunk)
TypeError: 'str' does not support the buffer interface

On 3.3+ it accepts strings and doesn't accept bytes.

----------
components: IO, Library (Lib), Unicode
messages: 179425
nosy: ezio.melotti, serhiy.storchaka
priority: normal
severity: normal
status: open
title: subprocess.Popen.communicate with universal_newlines=True doesn't accept strings on 3.2
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Jan  9 11:28:27 2013
From: report at bugs.python.org (Attila Gerendi)
Date: Wed, 09 Jan 2013 10:28:27 +0000
Subject: [New-bugs-announce] [issue16904] Avoid unnecessary and possibly
	unsafe code from	http.client.HTTPConnection.send
Message-ID: <1357727307.69.0.69749124261.issue16904@psf.upfronthosting.co.za>


New submission from Attila Gerendi:

In http.client.HTTPConnection's send(data) method if data has attribute read after is handled correctly as file-like object and sent out successfully the code continues to what should be an else branch (~line 858) and tries to send out again the data. This is harmless in most situations but only by chance and also run's unnecessary code.

I propose either to use an else branch for the code after line 858 or simply instead break return at line 853.

Cheers,
Sanyi

----------
components: Library (Lib)
messages: 179429
nosy: sanyi
priority: normal
severity: normal
status: open
title: Avoid unnecessary and possibly unsafe code from http.client.HTTPConnection.send
type: performance
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jan  9 12:13:37 2013
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 09 Jan 2013 11:13:37 +0000
Subject: [New-bugs-announce] [issue16905] Fix test discovery for
	test_warnings
Message-ID: <1357730017.55.0.973895693576.issue16905@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
components: Tests
files: test_warnings_discovery.diff
keywords: patch
nosy: berker.peksag, brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_warnings
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28645/test_warnings_discovery.diff

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

From report at bugs.python.org  Wed Jan  9 12:31:37 2013
From: report at bugs.python.org (Prashant Kurnawal)
Date: Wed, 09 Jan 2013 11:31:37 +0000
Subject: [New-bugs-announce] [issue16906] Bug in
	_PyUnicode_ClearStaticStrings() method of	unicodeobject.c
Message-ID: <1357731097.9.0.701098252698.issue16906@psf.upfronthosting.co.za>


New submission from Prashant Kurnawal:

I have embedded python3.3 in my application.
I got a crash when I ran a python script containing sample TK window creation code in it.
 
On interpreter shutdown, all strings are released (through _PyUnicode_ClearStaticStrings). (I Found this description in one of the comments of object.h header file)
 
When I tried to debug python source, I found a defect in _PyUnicode_ClearStaticStrings() method.
 
Existing function definition in python3.3 source (unicodeobject.c) is as follows

void _PyUnicode_ClearStaticStrings()
{
     _Py_Identifier *i;
      for (i = static_strings; i; i = i->next) {
           Py_DECREF(i->object);
           i->object = NULL;
           i->next = NULL;
      }
}
 
Here, for loop will not free all the static strings. It will free only the first static string in the list.
This loop needs to be corrected.
 
I corrected the loop in following way and its working fine for me.
 
void _PyUnicode_ClearStaticStrings()
{
    _Py_Identifier *i;
    while(static_strings->next != NULL)
    {
        i = static_strings;
        static_strings = static_strings->next;
        Py_DECREF(i->object);
        i->object = NULL;
        i->next = NULL;
    }
   
    Py_DECREF(static_strings->object);
    static_strings->object = NULL;
    static_strings = NULL;
}
 
Is this a bug or it is done so intentionally..?

----------
components: None
files: unicodeobject.c
messages: 179432
nosy: benjamin.peterson, brett.cannon, georg.brandl, goodger, larry, prashantkurnawal, python-dev
priority: normal
severity: normal
status: open
title: Bug in _PyUnicode_ClearStaticStrings() method of unicodeobject.c
type: crash
versions: Python 3.3
Added file: http://bugs.python.org/file28646/unicodeobject.c

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

From report at bugs.python.org  Wed Jan  9 13:22:42 2013
From: report at bugs.python.org (klo uo)
Date: Wed, 09 Jan 2013 12:22:42 +0000
Subject: [New-bugs-announce] [issue16907] Distutils fails to build extension
	in path with spaces
Message-ID: <1357734162.78.0.136546351961.issue16907@psf.upfronthosting.co.za>


New submission from klo uo:

I noticed this issue, while trying to compile Cython extension, when source file is in path with spaces. Extension wouldn't compile because LIBDIR is passed to MinGW g++ (though not to gcc) or MSVC compilers unquoted. I tracked the problem to "distutils/build_ext.py" in get_ext_fullpath() function.

I patched it, this way:

========================================
--- build_ext.bak
+++ build_ext.py
@@ -647,6 +647,11 @@
         package = '.'.join(modpath[0:-1])
         build_py = self.get_finalized_command('build_py')
         package_dir = os.path.abspath(build_py.get_package_dir(package))
+        try:
+            from win32api import GetShortPathName
+            package_dir = GetShortPathName(package_dir)
+        except:
+            pass
         # returning
         #   package_dir/filename
         return os.path.join(package_dir, filename)
========================================

which is just one way to do it.

----------
assignee: eric.araujo
components: Distutils
messages: 179434
nosy: eric.araujo, klo.uo, tarek
priority: normal
severity: normal
status: open
title: Distutils fails to build extension in path with spaces
versions: Python 2.7

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

From report at bugs.python.org  Wed Jan  9 13:31:57 2013
From: report at bugs.python.org (Sworddragon)
Date: Wed, 09 Jan 2013 12:31:57 +0000
Subject: [New-bugs-announce] [issue16908] Enhancing performance and memory
	usage
Message-ID: <1357734717.89.0.0863381712936.issue16908@psf.upfronthosting.co.za>


New submission from Sworddragon:

On my system (Linux 64 Bit) I figured out that python 3 needs a little more memory than python 2 and it is a little bit slower. Here are some examples:

sworddragon at ubuntu:~$ execution-time 'python2 -c print\("0"\)'
0.21738
sworddragon at ubuntu:~$ execution-time 'python2 -OO -c print\("0"\)'
0.22559
sworddragon at ubuntu:~$ execution-time 'python3 -c print\("0"\)'
0.37962
sworddragon at ubuntu:~$ execution-time 'python3 -OO -c print\("0"\)'
0.37825

Checking the memory usage after python 2 and python 3 are started in a terminal shows the following:

python2: RES 4780 / SHR: 2212
python3: RES 6168 / SHR: 2660

----------
components: Interpreter Core
messages: 179435
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Enhancing performance and memory usage
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Wed Jan  9 15:46:51 2013
From: report at bugs.python.org (Olof Johansson)
Date: Wed, 09 Jan 2013 14:46:51 +0000
Subject: [New-bugs-announce] [issue16909] urlparse: add userinfo attribute
Message-ID: <1357742811.51.0.916599948648.issue16909@psf.upfronthosting.co.za>


New submission from Olof Johansson:

Hi,

The urlparse library's "netloc" attribute is today further split into the following attributes: username, password, hostname, port. The attributes preceding the @ (username, password) are refered to in RFC 3986 [1] as "userinfo", the format of which is scheme dependant. E.g. the (expired) internet draft for SSH/SFTP urls [2] have connection parameters within the userinfo (user;cparams at host).

In some cases, the deprecated "username:password" syntax is required to be supported even with, e.g. "connection parameters". For this reason, I propose a new attribute, "userinfo", that exposes the "raw" userinfo string, without any splitting on : etc. I've had a go at a patch, with updated unit tests and documentation. Any feedback is welcome!

Regards,

1: http://tools.ietf.org/rfc/rfc3986.txt
2: http://tools.ietf.org/id/draft-ietf-secsh-scp-sftp-ssh-uri-04.txt

----------
components: None
files: urlparse_userinfo.diff
keywords: patch
messages: 179447
nosy: olof
priority: normal
severity: normal
status: open
title: urlparse: add userinfo attribute
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file28649/urlparse_userinfo.diff

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

From report at bugs.python.org  Wed Jan  9 18:00:17 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 09 Jan 2013 17:00:17 +0000
Subject: [New-bugs-announce] [issue16910] Fix test discovery for
	bytes/string tests
Message-ID: <1357750817.34.0.0240998301281.issue16910@psf.upfronthosting.co.za>


New submission from Zachary Ware:

This patch fixes discovery for test_bytes.py.  That fix changes string_tests.py, which breaks test_unicode.py and test_userstring.py, so those two files have been changed as well.  All three test files also use unittest.main() now instead of test_main().

----------
components: Tests
files: bytes_string_tests_discovery.diff
keywords: patch
messages: 179475
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for bytes/string tests
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28657/bytes_string_tests_discovery.diff

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

From report at bugs.python.org  Wed Jan  9 22:04:26 2013
From: report at bugs.python.org (Ronnie Ghose)
Date: Wed, 09 Jan 2013 21:04:26 +0000
Subject: [New-bugs-announce] [issue16911] Socket Documentation Error
Message-ID: <1357765466.06.0.116052267024.issue16911@psf.upfronthosting.co.za>


New submission from Ronnie Ghose:

Running the example given in the docs gives the following:


In [8]: socket.getaddrinfo('www.python.org',80)
Out[8]:
[(2, 1, 6, '', ('82.94.164.162', 80)),
 (2, 2, 17, '', ('82.94.164.162', 80)),
 (2, 3, 0, '', ('82.94.164.162', 80)),
 (10, 1, 6, '', ('2001:888:2000:d::a2', 80, 0, 0)),
 (10, 2, 17, '', ('2001:888:2000:d::a2', 80, 0, 0)),
 (10, 3, 0, '', ('2001:888:2000:d::a2', 80, 0, 0))]

In [9]: socket.getaddrinfo('www.python.org',80,socket.SOL_TCP)
---------------------------------------------------------------------------
gaierror                                  Traceback (most recent call last)
/home/sghose/ADAPT/dns/<ipython-input-9-faa58a2f7926> in <module>()
----> 1 socket.getaddrinfo('www.python.org',80,socket.SOL_TCP)

gaierror: [Errno -6] ai_family not supported

----------
assignee: docs at python
components: Documentation
messages: 179487
nosy: docs at python, sghose
priority: normal
severity: normal
status: open
title: Socket Documentation Error
versions: Python 2.7

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

From report at bugs.python.org  Wed Jan  9 23:57:44 2013
From: report at bugs.python.org (fenrirsoul)
Date: Wed, 09 Jan 2013 22:57:44 +0000
Subject: [New-bugs-announce] [issue16912] Wrong float sum w/ 10.14+10.1 and
	10.24+10.2
Message-ID: <1357772264.12.0.237958866341.issue16912@psf.upfronthosting.co.za>


New submission from fenrirsoul:

When 10.14+10.1 is typed, it's result is 20.240000000000002 and when 10.24+10.2 is typed, it's result is 20.439999999999998, i just found these two occurences.

----------
components: None
messages: 179495
nosy: fenrirsoul
priority: normal
severity: normal
status: open
title: Wrong float sum w/ 10.14+10.1 and 10.24+10.2
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Jan 10 06:20:09 2013
From: report at bugs.python.org (Frank)
Date: Thu, 10 Jan 2013 05:20:09 +0000
Subject: [New-bugs-announce] [issue16913] ElementTree tostring error when
	method='text'
Message-ID: <1357795209.81.0.959594987478.issue16913@psf.upfronthosting.co.za>


New submission from Frank:

Since upgrading to python 3.3 the tostring method fails when the output method is requested as text. Code like this:

with open(fp, mode='rt') as f:
    data = f.read()
tree, idmap = ET.XMLID(data)
print(ET.tostring(tree, method='text', encoding='unicode'))

Generates the following error:

Traceback (most recent call last):
  File "/home/john/Desktop/docs/Pear/pear.py", line 64, in pass_four
    print(ET.tostring(tree, method='text', encoding='unicode'))
  File "/usr/lib/python3.3/xml/etree/ElementTree.py", line 1171, in tostring
    ElementTree(element).write(stream, encoding, method=method)
  File "/usr/lib/python3.3/xml/etree/ElementTree.py", line 824, in write
    _serialize_text(write, self._root)
  File "/usr/lib/python3.3/xml/etree/ElementTree.py", line 1057, in _serialize_text
    write(part)
TypeError: string argument expected, got 'list'

Whereas it used to return plain text with formatting tags stripped from the root element on prior versions of python.

----------
components: XML
messages: 179523
nosy: Frank
priority: normal
severity: normal
status: open
title: ElementTree tostring error when method='text'
versions: Python 3.3

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

From report at bugs.python.org  Thu Jan 10 13:41:48 2013
From: report at bugs.python.org (gac)
Date: Thu, 10 Jan 2013 12:41:48 +0000
Subject: [New-bugs-announce] [issue16914] timestamping in smtplib.py to help
	troubleshoot server	timeouts/delays
Message-ID: <1357821708.32.0.469925509105.issue16914@psf.upfronthosting.co.za>


New submission from gac:

I had cause to use smtplib to help me pinpoint why some outgoing mail was failing, but found that while it offered verbose logging (via debuglevel 1) this was without timestamps, making it difficult to make my case to the server operator that it was a server-side delay causing the issue. I've changed smtplib.py to add a second debugging level which includes timestamps down to microsecond granularity so that the debug log produced can pinpoint when a server isn't responding promptly.

debuglevel 1 is unchanged, so anyone depending on the output from this being in a particular format won't be affected (either by setting debuglevel to "1" or "true"), but if debuglevel 2 is used explicitly then the standard output is preceded by a timestamp.

----------
components: Library (Lib)
files: smtplib.py.patch
keywords: patch
messages: 179538
nosy: gac
priority: normal
severity: normal
status: open
title: timestamping in smtplib.py to help troubleshoot server timeouts/delays
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28667/smtplib.py.patch

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

From report at bugs.python.org  Thu Jan 10 14:40:17 2013
From: report at bugs.python.org (Antoon Pardon)
Date: Thu, 10 Jan 2013 13:40:17 +0000
Subject: [New-bugs-announce] [issue16915] mode of socket.makefile is more
	limited than	documentation suggests
Message-ID: <1357825217.2.0.655032840521.issue16915@psf.upfronthosting.co.za>


New submission from Antoon Pardon:

The documentation of socket.makefile states that its arguments are interpreted the same way as by the built-in open() function. However the mode argument of socket.makefile only allows 'r', 'w' and 'b'.

That some options are not allowed seems perfectly normal, like there being no use of an 'x' option but the documentation should probably reflect that.

But I don't see why the 't' should cause trouble. If people can open a file explicitly in text mode, I don't see why it wouldn't be possible to explicitly ask for text mode in socket.makefile

----------
components: Library (Lib)
messages: 179543
nosy: Antoon.Pardon
priority: normal
severity: normal
status: open
title: mode of socket.makefile is more limited than documentation suggests
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Jan 10 15:08:15 2013
From: report at bugs.python.org (Marco Buttu)
Date: Thu, 10 Jan 2013 14:08:15 +0000
Subject: [New-bugs-announce] [issue16916] The Extended Iterable Unpacking
	(PEP-3132) for byte	strings doesn't match the specification
Message-ID: <1357826895.67.0.646270991721.issue16916@psf.upfronthosting.co.za>


New submission from Marco Buttu:

The PEP 3132 said:
"""
... if seq is a slicable sequence, all the following assignments are equivalent if seq has at least three elements:

a, b, c = seq[0], seq[1:-1], seq[-1]
a, *b, c = seq
[a, *b, c] = seq
"""

But this doesn't happen for byte strings:

>>> seq = b'xyz'
>>> a, b, c = seq[0], seq[1:-1], seq[-1]
>>> a, b, c
(120, b'y', 122)
>>> a, *b, c = seq
>>> a, b, c
(120, [121], 122)

Tested on Python3.3 and Python3.2 (Linux Ubuntu 11.04)

----------
components: Interpreter Core
messages: 179545
nosy: marco.buttu
priority: normal
severity: normal
status: open
title: The Extended Iterable Unpacking (PEP-3132) for byte strings doesn't match the specification
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jan 10 15:09:31 2013
From: report at bugs.python.org (=?utf-8?q?Dra=C5=BEen_Lu=C4=8Danin?=)
Date: Thu, 10 Jan 2013 14:09:31 +0000
Subject: [New-bugs-announce] [issue16917] Misleading missing parenthesis
	syntax error
Message-ID: <1357826971.05.0.673810917447.issue16917@psf.upfronthosting.co.za>


New submission from Dra?en Lu?anin:

When running this script:

things = ['a', 'b']
things.append('c'
for a in things:
    print a

I get the following output:

$ python script.py 
  File "script.py", line 3
    for a in things:
                   ^
SyntaxError: invalid syntax

the SyntaxError is very misguiding. The error is in a missing parenthesis after the append call, but the error output points to the colon in the for loop. It got me looking for some invisible characters around the colon (which sometimes do pop up in my IPython notebook in OS X).

Expected behaviour - the interpreter should warn me that I have an unmatched parenthesis or at least give some hint as to what possible tokens were expected instead of a colon to help me identify the faulty expression. It is hard to match all parentheses as it is, let alone when the error caused by them shows up in a different line pointing to a token of a different expression with a very vague description.

----------
components: Interpreter Core
messages: 179547
nosy: kermit666
priority: normal
severity: normal
status: open
title: Misleading missing parenthesis syntax error
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Thu Jan 10 17:39:57 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 10 Jan 2013 16:39:57 +0000
Subject: [New-bugs-announce] [issue16918] Fix test discovery for
	test_codecs.py
Message-ID: <1357835997.28.0.488005818919.issue16918@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Here's the fix for test_codecs.py, I believe.  I had a few headaches trying to get this patch created without changing some of the characters or adding a BOM to the file, and at one point the test was failing for no apparent reason.  This version of the patch seems to work on my machine, though.

----------
components: Tests
files: test_codecs_discovery.diff
keywords: patch
messages: 179571
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_codecs.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28670/test_codecs_discovery.diff

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

From report at bugs.python.org  Thu Jan 10 17:51:23 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 10 Jan 2013 16:51:23 +0000
Subject: [New-bugs-announce] [issue16919] Fix test discovery for
	test_crypt.py
Message-ID: <1357836683.17.0.872052983842.issue16919@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Here's a fix for test_crypt.py, inspired by Ezio's mention of using setUpModule in issue 16905.

I can't test this on a platform that actually has _crypt at the moment, but I should be able to later today if nobody else has before then.  Some tinkering has shown me that it /should/ work, though.

----------
components: Tests
files: test_crypt_discovery.diff
keywords: patch
messages: 179572
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_crypt.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28671/test_crypt_discovery.diff

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

From report at bugs.python.org  Thu Jan 10 18:19:32 2013
From: report at bugs.python.org (John Brearley)
Date: Thu, 10 Jan 2013 17:19:32 +0000
Subject: [New-bugs-announce] [issue16920] multiprocessing.connection
	listener gets MemoryError on	recv
Message-ID: <1357838372.36.0.779855402088.issue16920@psf.upfronthosting.co.za>


New submission from John Brearley:

Using a multiprocessing.connection listener, I can accept an incoming socket OK, but when I do conn.recv(), I get memory error. The attached script mpl_bug.py will readily reproduce the issues on WinXP & WinVista, see sample output below:

<pre>
c:\>python mpl_bug.py
main server listening on host  port 10500
main created simple_client <Process(Process-1, initial)>
simple_client connecting to host localhost port 10500
main conn: <multiprocessing.connection.Connection object at 0x00C94B50> waiting
for data
simple_client sending: b'abcd'
simple_client waiting for data
Traceback (most recent call last):
  File "mpl_bug.py", line 61, in <module>
    data=conn.recv()   ;# Memory Error occurs here <<<==========================
======================
  File "c:\python33\lib\multiprocessing\connection.py", line 251, in recv
    buf = self._recv_bytes()
  File "c:\python33\lib\multiprocessing\connection.py", line 405, in _recv_bytes

    return self._recv(size)
  File "c:\python33\lib\multiprocessing\connection.py", line 380, in _recv
    chunk = read(handle, remaining)
MemoryError
</pre>

----------
files: mpl_bug.py
messages: 179577
nosy: jbrearley
priority: normal
severity: normal
status: open
title: multiprocessing.connection listener gets MemoryError on recv
versions: Python 3.3
Added file: http://bugs.python.org/file28673/mpl_bug.py

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

From report at bugs.python.org  Thu Jan 10 18:42:20 2013
From: report at bugs.python.org (Torsten Landschoff)
Date: Thu, 10 Jan 2013 17:42:20 +0000
Subject: [New-bugs-announce] [issue16921] Docs of
	subprocess.CREATE_NEW_CONSOLE are wrong
Message-ID: <1357839740.51.0.95267360969.issue16921@psf.upfronthosting.co.za>


New submission from Torsten Landschoff:

The documentation of CREATE_NEW_CONSOLE at http://docs.python.org/3/library/subprocess.html#subprocess.CREATE_NEW_CONSOLE states:

    This flag is always set when Popen is created with shell=True.

This does not fit the code which does

    if (_subprocess.GetVersion() >= 0x80000000 or os.path.basename(comspec).lower() == "command.com"):
        # Win9x, or using command.com on NT. We need to
        creationflags |= _subprocess.CREATE_NEW_CONSOLE

So the statement is only true on very old versions on Windows. I suggest to fix the documentation (patch attached) or to remove that obsolete hack (and drop support for Windows <= NT).

----------
components: Windows
files: create_new_console.diff
keywords: patch
messages: 179578
nosy: torsten
priority: normal
severity: normal
status: open
title: Docs of subprocess.CREATE_NEW_CONSOLE are wrong
versions: Python 3.5
Added file: http://bugs.python.org/file28674/create_new_console.diff

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

From report at bugs.python.org  Thu Jan 10 19:10:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 10 Jan 2013 18:10:33 +0000
Subject: [New-bugs-announce] [issue16922] ElementTree.findtext() returns
	empty bytes object	instead of empty string
Message-ID: <1357841433.69.0.0821104490374.issue16922@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

>>> import xml.etree.cElementTree as ET
>>> ET.XML('<root><empty /></root>').findtext('empty')
b''

----------
components: XML
files: etree_finditer_empty.patch
keywords: patch
messages: 179580
nosy: eli.bendersky, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: ElementTree.findtext() returns empty bytes object instead of empty string
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28675/etree_finditer_empty.patch

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

From report at bugs.python.org  Thu Jan 10 21:18:15 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 10 Jan 2013 20:18:15 +0000
Subject: [New-bugs-announce] [issue16923] test_ssl kicks up a lot of
	ResourceWarnings
Message-ID: <1357849095.58.0.0656533205618.issue16923@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

Now #16900 is fixed, we get gunk like this:

 $ ./python -Wall Lib/test/regrtest.py -uall test_ssl
[1/1] test_ssl
/home/benjamin/dev/python/3.3/Lib/unittest/case.py:385: ResourceWarning: unclosed <ssl.SSLSocket object, fd=6, family=2, type=1, proto=0>
  function()
/home/benjamin/dev/python/3.3/Lib/test/test_ssl.py:211: ResourceWarning: unclosed <ssl.SSLSocket object, fd=6, family=2, type=1, proto=0>
  del ss
/home/benjamin/dev/python/3.3/Lib/test/test_ssl.py:232: ResourceWarning: unclosed <ssl.SSLSocket object, fd=6, family=2, type=1, proto=0>
  ss = ssl.wrap_socket(s)
/home/benjamin/dev/python/3.3/Lib/test/test_ssl.py:232: ResourceWarning: unclosed <ssl.SSLSocket object, fd=7, family=2, type=2049, proto=0>
  ss = ssl.wrap_socket(s)
/home/benjamin/dev/python/3.3/Lib/unittest/case.py:385: ResourceWarning: unclosed <ssl.SSLSocket object, fd=6, family=2, type=2049, proto=0>
  function()
/home/benjamin/dev/python/3.3/Lib/test/test_ssl.py:374: ResourceWarning: unclosed <ssl.SSLSocket object, fd=6, family=2, type=1, proto=0>
  ss = ssl.wrap_socket(s, server_side=True, certfile=CERTFILE)
/home/benjamin/dev/python/3.3/Lib/unittest/case.py:385: ResourceWarning: unclosed <ssl.SSLSocket object, fd=7, family=2, type=1, proto=0>
  function()
/home/benjamin/dev/python/3.3/Lib/unittest/case.py:385: ResourceWarning: unclosed <ssl.SSLSocket object, fd=6, family=2, type=1, proto=0>
  function()
/home/benjamin/dev/python/3.3/Lib/unittest/case.py:385: ResourceWarning: unclosed <ssl.SSLSocket object, fd=6, family=2, type=1, proto=0>
  function()
/home/benjamin/dev/python/3.3/Lib/unittest/case.py:385: ResourceWarning: unclosed <ssl.SSLSocket object, fd=8, family=2, type=2049, proto=0>
  function()
/home/benjamin/dev/python/3.3/Lib/test/test_ssl.py:874: ResourceWarning: unclosed <ssl.SSLSocket object, fd=7, family=2, type=2049, proto=0>
  cert_reqs=ssl.CERT_NONE, ciphers="DEFAULT")
/home/benjamin/dev/python/3.3/Lib/unittest/case.py:385: ResourceWarning: unclosed <ssl.SSLSocket object, fd=8, family=2, type=2049, proto=0>
  function()
Resource 'ipv6.google.com' is not available
/home/benjamin/dev/python/3.3/Lib/unittest/case.py:385: ResourceWarning: unclosed <ssl.SSLSocket object, fd=8, family=2, type=1, proto=0>
  function()
/home/benjamin/dev/python/3.3/Lib/unittest/case.py:385: ResourceWarning: unclosed <ssl.SSLSocket object, fd=9, family=2, type=1, proto=0>
  function()
/home/benjamin/dev/python/3.3/Lib/unittest/case.py:385: ResourceWarning: unclosed <ssl.SSLSocket object, fd=8, family=2, type=1, proto=0>
  function()
1 test OK.


This should be fixed.

----------
keywords: easy
messages: 179594
nosy: benjamin.peterson
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ssl kicks up a lot of ResourceWarnings
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Jan 11 03:06:26 2013
From: report at bugs.python.org (Justin Eittreim)
Date: Fri, 11 Jan 2013 02:06:26 +0000
Subject: [New-bugs-announce] [issue16924] try: except: ordering error
Message-ID: <1357869986.79.0.0900594167753.issue16924@psf.upfronthosting.co.za>


New submission from Justin Eittreim:

When running multiple nested loops (to emulate the circumstances of a program running multiple different modules at once,) each with their own try: except: block (in this case for KeyboardInterrupt,) the order of operations seems to fall out of place. As you can see in the screenshot, even though the inner-most loop should never have been left (or ended for that matter,) the parent loop catches the exception in its place on occasion. While this isn't necessarily a huge issue, for certain things it can be rather annoying and downright confusing. For most all other languages, for example, the inner-most loop would, of course, catch the exception first.

Requesting more insight on this issue.

----------
components: None
files: 2013-01-10 17_55_13-Python Shell.png
messages: 179613
nosy: DivinityArcane
priority: normal
severity: normal
status: open
title: try: except: ordering error
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file28682/2013-01-10 17_55_13-Python Shell.png

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

From report at bugs.python.org  Fri Jan 11 04:24:30 2013
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 11 Jan 2013 03:24:30 +0000
Subject: [New-bugs-announce] [issue16925] Fix test discovery for
	test_configparser.py
Message-ID: <1357874670.05.0.375078566106.issue16925@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
components: Tests
files: test_configparser_discovery.diff
keywords: patch
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_configparser.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28683/test_configparser_discovery.diff

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

From report at bugs.python.org  Fri Jan 11 05:24:01 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 11 Jan 2013 04:24:01 +0000
Subject: [New-bugs-announce] [issue16926] setup.py register does not always
	respect --repository
Message-ID: <1357878241.89.0.365738814483.issue16926@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

$ python setup.py --dry-run register --repository http://testpypi.python.org/pypi
...
Registering Foo to http://pypi.python.org/pypi
Server response (200): OK

This is with a .pypirc file with a [server-login] section.

It seems like this can cause unintended registrations on PyPI, etc.  It also makes it unclear how to get the URL that setup() will use prior to the real invocation (e.g. if you would like to prompt the user with the URL they will be pushing to).

----------
assignee: eric.araujo
components: Distutils, Library (Lib)
messages: 179624
nosy: chris.jerdonek, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: setup.py register does not always respect --repository
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Jan 11 06:50:04 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 11 Jan 2013 05:50:04 +0000
Subject: [New-bugs-announce] [issue16927] Separate built-in types from
	functions and group similar	functions in functions.rst
Message-ID: <1357883404.71.0.215467038207.issue16927@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

http://docs.python.org/3/library/functions.html currently lists all the builtin objects.
This include two main groups that should be separated in two different sections:  built-in types and functions.
In addition, similar/related functions should be grouped together.  This will make it easier to find similar functions, and will allow us to factor out some documentation that is repeated[0].

A possible division might be:

built-in types:
  dict, int, str, list, tuple, bytes, bool, object, float, complex, bytearray, set, frozenset, memoryview, range, slice

functions:
  base conversion: bin, oct, hex
  attribute-related: getattr, setattr, hasattr, delattr
  math-related: abs, pow, round, divmod, hash
  string-related: ascii, repr, format, chr, ord
  IO: input, print, open,
  OOP: staticmethod, classmethod, property, super
  introspection: isinstance, issubclass, callable, dir, help, vars, id, type, locals, globals
  sequence/iterable-related: len, min, max, sum, all, any, next, iter, sorted, reversed, enumerate,  filter, zip, map
  code-related: eval, exec, compile, __import__

This is just to give an idea -- the important thing is to rearrange the functions so that e.g. min/max, any/all, chr/ord, hex/oct/bin, getattr/setattr/hasattr/delattr, etc. are close to each other -- having separate sections is not strictly necessary though.  Some functions can also be listed on their own.

The table at the beginning of functions.rst and ctrl+f are enough to find functions, so I don't think that preserving the current alphabetical order is too useful -- grouping is more important.

[0] see e.g #16665. What is reported for hex() there is valid for bin() and oct() too, so a paragraph about how to use format() and its format codes can be added once at the top of the section.
This also came up on other issues where we were discussing about documenting the built-in types as "functions" (e.g. in str(someobj)), or as types (e.g. isinstance(someobj, type)).  A paragraph to explain this "duality" will help solve the problem.

----------
assignee: ezio.melotti
messages: 179632
nosy: chris.jerdonek, eric.araujo, ezio.melotti, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Separate built-in types from functions and group similar functions in functions.rst
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Jan 11 08:45:16 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 11 Jan 2013 07:45:16 +0000
Subject: [New-bugs-announce] [issue16928] spurious Cron Daemon e-mails to
	docs@dinsdale.python.org
Message-ID: <1357890316.54.0.914803734426.issue16928@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

Some spurious e-mails are sent to python-checkins, e.g.

Subject: [Python-checkins] Cron <docs at dinsdale> /home/docs/build-devguide
From: Cron Daemon root at python.org 
To:  docs at dinsdale.python.org

/home/docs/devguide/documenting.rst:766: WARNING: term not in glossary: bytecode

(from http://mail.python.org/pipermail/python-checkins/2013-January/118934.html )

The e-mail is spurious in part because "bytecode" links correctly on the actual online version.

----------
assignee: docs at python
components: Devguide, Documentation
messages: 179643
nosy: chris.jerdonek, docs at python, eric.araujo, ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: spurious Cron Daemon e-mails to docs at dinsdale.python.org

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

From report at bugs.python.org  Fri Jan 11 09:36:44 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 11 Jan 2013 08:36:44 +0000
Subject: [New-bugs-announce] [issue16929] poll()/epoll() are not thread-safe
Message-ID: <1357893404.57.0.0716117445862.issue16929@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

After optimizing epoll() to use a per-instance buffer like poll() does (http://bugs.python.org/issue16876), I realized that it wasn't thread-safe, and can result in crashes:
"""
 ./python /tmp/test.py
*** glibc detected *** ./python: free(): corrupted unsorted chunks: 0x0000000001c8e690 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3041c75676]
./python[0x4fd9ae]
./python(PyThreadState_DeleteCurrent+0x10c)[0x4fdb91]
./python[0x52a444]
/lib64/libpthread.so.0[0x30428077e1]
/lib64/libc.so.6(clone+0x6d)[0x3041ce153d]
======= Memory map: ========
[...]
"""

The problem is that poll (and now epoll) array is stored per-instance, and if second call to poll() is made while another thread is currently blocked on poll(), the array is reallocated (through PyMem_Resize()) if the buffer size has changed (if the number of FDs registered has changed).

"""
static int
update_ufd_array(pollObject *self)
[...]
    self->ufd_len = PyDict_Size(self->dict);
    PyMem_RESIZE(self->ufds, struct pollfd, self->ufd_len);
[...]
"""

can be called while another thread is blocked there:
"""
    /* call poll() */
    Py_BEGIN_ALLOW_THREADS
    poll_result = poll(self->ufds, self->ufd_len, timeout);
    Py_END_ALLOW_THREADS
"""

So when the first call to poll() returns, it can end up in SIGSEGV or heap corruption (unless the array was increased an realloc() was able to expand it in-place).

Reproducer script attached.

----------
components: Extension Modules
files: test.py
messages: 179647
nosy: christian.heimes, neologix
priority: normal
severity: normal
stage: needs patch
status: open
title: poll()/epoll() are not thread-safe
type: crash
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28685/test.py

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

From report at bugs.python.org  Fri Jan 11 09:38:39 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 11 Jan 2013 08:38:39 +0000
Subject: [New-bugs-announce] [issue16930] mention limitations and/or
	alternatives to hg graft
Message-ID: <1357893519.23.0.747104705775.issue16930@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

In various places, the devguide recommends `hg graft`, but it appears it might not be possible to use on some systems or in certain situations.  For example, when I tried grafting a trivial change from 2.7 to 3.2 on Mac OS X, I got the following fatal error:

$ hg graft 2.7
grafting revision 81391
abort: case-folding collision between Lib/ConfigParser.py and Lib/configparser.py

Here is some related information: http://mercurial.selenic.com/wiki/FixingCaseCollisions

At the least, we might want to add a note saying that `hg graft` may not work on certain systems (and name those systems).

----------
components: Devguide
messages: 179650
nosy: chris.jerdonek, eric.araujo, ezio.melotti, ncoghlan
priority: normal
severity: normal
status: open
title: mention limitations and/or alternatives to hg graft

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

From report at bugs.python.org  Fri Jan 11 09:56:51 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 11 Jan 2013 08:56:51 +0000
Subject: [New-bugs-announce] [issue16931] mention work-around to create
	diffs in default/non-git	mode
Message-ID: <1357894611.9.0.235167303817.issue16931@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to mention in the devguide how to create diffs with the changeset number when --git is configured on.  Perhaps this can be done via a FAQ like: "How can I get Rietveld to work with a 2.7 patch?"

Background: Currently, the devguide recommends configuring Mercurial to use --git when making diffs.  However, this causes the changeset ID to be left off of patch files and, for example, prevents Rietveld from working with patches to non-default branches.  See also this thread:

http://mail.python.org/pipermail/python-dev/2011-March/108765.html

This issue describes a couple work-arounds:

http://bz.selenic.com/show_bug.cgi?id=3761

----------
components: Devguide
messages: 179654
nosy: chris.jerdonek, eric.araujo, ezio.melotti, ncoghlan
priority: normal
severity: normal
status: open
title: mention work-around to create diffs in default/non-git mode

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

From report at bugs.python.org  Fri Jan 11 12:29:29 2013
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 11 Jan 2013 11:29:29 +0000
Subject: [New-bugs-announce] [issue16932] urlparse fails at parsing
	"www.python.org:80/"
Message-ID: <1357903769.2.0.674766943444.issue16932@psf.upfronthosting.co.za>


New submission from Sandro Tosi:

Hello,
as reported at http://mail.python.org/pipermail/docs/2013-January/012375.html urlparse fails to parse URLs without a schema and with a url path, as opposed to what's documented at http://docs.python.org/2/library/urlparse.html?highlight=urlparse#urlparse :

./python -c "from urlparse import urlparse ; print(urlparse('python.org:80/'))"
ParseResult(scheme='python.org', netloc='', path='80/', params='', query='', fragment='')

(that is for 2.7, but the same happens on all the 3.x active branches).

i'm attaching a test to expose this failure.

----------
components: Library (Lib)
files: urlparse.diff
keywords: patch
messages: 179670
nosy: sandro.tosi
priority: normal
severity: normal
stage: needs patch
status: open
title: urlparse fails at parsing "www.python.org:80/"
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28692/urlparse.diff

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

From report at bugs.python.org  Fri Jan 11 14:44:18 2013
From: report at bugs.python.org (Thomas Guettler)
Date: Fri, 11 Jan 2013 13:44:18 +0000
Subject: [New-bugs-announce] [issue16933] argparse: remove magic from
	examples
Message-ID: <1357911858.69.0.0703193383433.issue16933@psf.upfronthosting.co.za>


New submission from Thomas Guettler:

The current argparse documentation is not easy to read people new to python.

http://docs.python.org/dev/library/argparse.html#choices

{{{
current: parser.add_argument('foo', choices='abc')
}}}

Please make this more explicit:
{{{
better: parser.add_argument('foo', choices=['one', 'two', 'three'])
}}}

{{{
current: parser.parse_args('c'.split()) # looks like perl to me
}}}

{{{
better: parser.parse_args(['c'])
}}}

Next: Please use a more common type, not "complex" in the choices example. It confuses a lot of people.

----------
messages: 179679
nosy: guettli
priority: normal
severity: normal
status: open
title: argparse: remove magic from examples

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

From report at bugs.python.org  Fri Jan 11 15:13:56 2013
From: report at bugs.python.org (Stephane Poirier)
Date: Fri, 11 Jan 2013 14:13:56 +0000
Subject: [New-bugs-announce] [issue16934] qsort doesn't work for double
	arrays
Message-ID: <1357913636.91.0.603686278342.issue16934@psf.upfronthosting.co.za>


New submission from Stephane Poirier:

qsort doesn't sort arrays that are defined with double elements.
You can find attached a script that shows this function working well for int (as described in the ctypes documentation). If int array is replaced by double array qsort doesn't sort any more.
Even worse, with python 2.6, the difference between a[0] and b[0] may be nan.
The script can be launch by 
python.exe testQSort33.py

----------
components: ctypes
files: testQSort33.py
messages: 179680
nosy: stephane.poirier
priority: normal
severity: normal
status: open
title: qsort doesn't work for double arrays
type: behavior
versions: Python 2.6, Python 2.7, Python 3.3
Added file: http://bugs.python.org/file28696/testQSort33.py

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

From report at bugs.python.org  Fri Jan 11 15:43:08 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 11 Jan 2013 14:43:08 +0000
Subject: [New-bugs-announce] [issue16935] unittest should understand
	SkipTest at import time	during test discovery
Message-ID: <1357915388.69.0.583817209092.issue16935@psf.upfronthosting.co.za>


New submission from Brett Cannon:

For test discovery to work where a dependent module is optional, you end up needing to do something like what is done in http://hg.python.org/cpython/rev/15ddd683c321:

-crypt = support.import_module('crypt')
+def setUpModule():
+    # this import will raise unittest.SkipTest if _crypt doesn't exist,
+    # so it has to be done in setUpModule for test discovery to work
+    global crypt
+    crypt = support.import_module('crypt')

That's kind of ugly. It would be better if unittest recognized SkipTest at import time during test discovery

----------
assignee: michael.foord
components: Library (Lib)
messages: 179681
nosy: brett.cannon, michael.foord
priority: normal
severity: normal
stage: test needed
status: open
title: unittest should understand SkipTest at import time during test discovery
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Jan 11 16:31:22 2013
From: report at bugs.python.org (Jens Lechtenboerger)
Date: Fri, 11 Jan 2013 15:31:22 +0000
Subject: [New-bugs-announce] [issue16936] Documentation for stat.S_IFMT
	inconsistent
Message-ID: <1357918282.52.0.0217764551769.issue16936@psf.upfronthosting.co.za>


New submission from Jens Lechtenboerger:

The documentation for the stat module is inconsistent
(Doc/library/stat.rst, at least for Python 2.7.2 and 3.3.0):
It talks about a function stat.S_IFMT() and a bit mask stat.S_IFMT.
Only the former does exist.

Besides, it states: "For complete details about the stat(), fstat()
and lstat() calls, consult the documentation for your system."
I suggest to add some pointers on what systems one might consult
what documentation: "(e.g., on GNU/Linux invoke 'man 2 stat')"
I don't know about other systems, though.

So, doing "man 2 stat", which refers to the POSIX standard and which
seems to have served as blueprint for stat's interface, I expected
to find the bit mask S_IFMT.
However, that does not exist.  In contrast, in stat.py that bit mask
is hard-coded as 0o170000 in the definition of S_IFMT().

As long-term, backwards-incompatible fix, I suggest to export
S_IFMT = 0o170000
and to rename the function S_IFMT().  That way, stat would in fact
be aligned with the documentation for my system.

As short-term fix, I suggest to correct stat.rst.

Replace
> Use of the functions above is more portable than use of the first
> set of flags:
>
> stat.S_IFMT
>    Bit mask for the file type bit fields.

with
> Use of the functions above may be more portable than use of the
> first set of flags.
>
> Warning: Note that the stat module does not export a bit mask
> S_IFMT. (As stated incorrectly in previous versions of the
> documentation.)

Here, I replaced "is more portable" with "may be more portable" as
the constant 0o170000 is hard-coded into S_IFMT() in stat.py.  Maybe
somebody could add a hint in what sense portability is improved?
Alternatively that sentence could be deleted.

A diff for stat.rst (Python 3.3.0) is attached.

----------
assignee: docs at python
components: Documentation
files: stat.rst.diff
keywords: patch
messages: 179687
nosy: docs at python, lechten
priority: normal
severity: normal
status: open
title: Documentation for stat.S_IFMT inconsistent
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file28697/stat.rst.diff

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

From report at bugs.python.org  Fri Jan 11 19:22:02 2013
From: report at bugs.python.org (Martijn Pieters)
Date: Fri, 11 Jan 2013 18:22:02 +0000
Subject: [New-bugs-announce] [issue16937] -u (unbuffered I/O) command line
	option documentation	mismatch for sys.stdin
Message-ID: <1357928522.67.0.838908652159.issue16937@psf.upfronthosting.co.za>


New submission from Martijn Pieters:

Run `python3.3 -h` and the `-u` option is documented as:

>     -u     : unbuffered binary stdout and stderr; also PYTHONUNBUFFERED=x
>              see man page for details on internal buffering relating to '-u'

Note that only `stdout` and `stderr` are mentioned.

The online documentation at http://docs.python.org/3/using/cmdline.html#cmdoption-u doesn't agree:

> ... the binary layer of the stdin, stdout and stderr streams ...

nor does `man python3.3`, which claims:

>    -u     Force the binary I/O layers of stdin, stdout and stderr to be unbuffered.  The text I/O layer will still
>           be line-buffered.

So, is `stdin` going to be unbuffered, or not, when using `-u`?

Running a simple test shows that `stdin` is firmly being buffered regardless of the `-u` switch:

    $ python3.3 -c 'import sys; print(sys.stdin.buffer, sys.stdout.buffer)'
    <_io.BufferedReader name='<stdin>'> <_io.BufferedWriter name='<stdout>'>
    $ python3.3 -u -c 'import sys; print(sys.stdin.buffer, sys.stdout.buffer)'
    <_io.BufferedReader name='<stdin>'> <_io.FileIO name='<stdout>' mode='wb'>

I'll presume here that `stdin` is deliberately buffered, regardless, and that the documentation and man page are out of date here (in python 2, `-u` does include `stdin`).

----------
assignee: docs at python
components: Documentation
messages: 179718
nosy: docs at python, mjpieters
priority: normal
severity: normal
status: open
title: -u (unbuffered I/O) command line option documentation mismatch for sys.stdin
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Jan 11 23:42:09 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 11 Jan 2013 22:42:09 +0000
Subject: [New-bugs-announce] [issue16938] pydoc confused by __dir__
Message-ID: <1357944129.98.0.501949279766.issue16938@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

If a class implements __dir__ to also return a number of attributes that aren't present in the class __dict__ inspect.classify_class_attrs gets confused and assumes the home class is None.

This in turn confused pydoc, docclass in pydoc assumes that the 'class' slot in the sequence returned by classify_class_attrs is actually a class and fails when it None (because None doesn't have a __name__ attribute).

I've classified this as "low" because I've found a useable workaround: I have implemented a "__objclass__" property for my custom descriptor and with that pydoc works.

It would be nice if pydoc wouldn't crash on this. One possible workaround: assume that the class is the inspected class when a name returned by dir(cls) cannot be found in one of the classes on the mro.

I'll provide a patch if this would be acceptable behavior.

----------
components: Library (Lib)
messages: 179738
nosy: ronaldoussoren
priority: low
severity: normal
stage: test needed
status: open
title: pydoc confused by __dir__
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Sat Jan 12 03:59:11 2013
From: report at bugs.python.org (Jason Alvarado)
Date: Sat, 12 Jan 2013 02:59:11 +0000
Subject: [New-bugs-announce] [issue16939] Broken link in 14. Cryptographic
	Service
Message-ID: <1357959551.72.0.678573558111.issue16939@psf.upfronthosting.co.za>


New submission from Jason Alvarado:

http://docs.python.org/3.1/library/crypto.html

The link to A.M, Kuchling URL is broken

http://www.amk.ca/python/code/crypto.html

----------
assignee: docs at python
components: Documentation
messages: 179758
nosy: Jason.Alvarado, docs at python
priority: normal
severity: normal
status: open
title: Broken link in 14. Cryptographic Service
versions: Python 3.1

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

From report at bugs.python.org  Sat Jan 12 05:00:57 2013
From: report at bugs.python.org (paul j3)
Date: Sat, 12 Jan 2013 04:00:57 +0000
Subject: [New-bugs-announce] [issue16940] argparse 15.4.5.1. Sub-commands
	documentation missing	indentation
Message-ID: <1357963257.08.0.262737985676.issue16940@psf.upfronthosting.co.za>


New submission from paul j3:

Argparse
15.4.5.1. Sub-commands

In the example:

>>> parser.parse_args(['--help'])
usage: PROG [-h] [--foo] {a,b} ...

positional arguments:
  {a,b}   sub-command help
a     a help
b     b help

optional arguments:
  -h, --help  show this help message and exit
  --foo   foo help

The 'a help', 'b help' lines should be indented

----------
assignee: docs at python
components: Documentation
messages: 179766
nosy: docs at python, paul.j3
priority: normal
severity: normal
status: open
title: argparse 15.4.5.1. Sub-commands documentation missing indentation
versions: Python 2.7

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

From report at bugs.python.org  Sat Jan 12 06:24:41 2013
From: report at bugs.python.org (Leon Maurer)
Date: Sat, 12 Jan 2013 05:24:41 +0000
Subject: [New-bugs-announce] [issue16941] TkInter won't update display on OS
	X if delay is too	small
Message-ID: <1357968281.99.0.183131083594.issue16941@psf.upfronthosting.co.za>


New submission from Leon Maurer:

I'm running in to a problem where TkInter won't update the display on OS X. I've attached a simple piece of code that has this problem, and I've also made a short screen-cast of the problem:

https://mywebspace.wisc.edu/lnmaurer/web/updatebug/updatebug.mov

The program is simple -- basically a big canvas with a some text in the middle that counts up.

The screen-cast has three parts. First, it shows the program working as it should. Then, I add a simple background image to the canvas (a black rectangle), and the interface refuses to refresh at all; I get a spinning beach ball wheel (although that doesn't show up in the screen-cast). Then, I increase the delay between updates, and the interface refreshes as it should.

The middle case, where the interface becomes totally unresponsive, is a bug.

I haven't been able to reproduce this problem under Linux or Windows; I've only run in to it on OS X. Also, the size of the canvas and image matters; if I make them small enough, the interface won't freeze up.

Computer and software information:
OS X 10.6.8
Python 2.7.3
ActiveTcl 8.5.13
PIL 1.1.7
MacBookPro5,5 w/ 2.26GHz Core 2 Duo (so a machine that's kind of slow by today's standards -- maybe faster machines won't run in to this problem, but this machine doesn't have the problem when running Windows or Linux)

----------
components: Tkinter
files: bugtest.py
messages: 179769
nosy: Leon.Maurer
priority: normal
severity: normal
status: open
title: TkInter won't update display on OS X if delay is too small
versions: Python 2.7
Added file: http://bugs.python.org/file28704/bugtest.py

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

From report at bugs.python.org  Sat Jan 12 09:12:56 2013
From: report at bugs.python.org (C19)
Date: Sat, 12 Jan 2013 08:12:56 +0000
Subject: [New-bugs-announce] [issue16942] seriously?
	http.cookiejar.FileCookieJar().save method	NOTImplemented?
Message-ID: <1357978376.78.0.27832756308.issue16942@psf.upfronthosting.co.za>


New submission from C19:

Is it means that we should use MozillaCookieJar LWPCookieJar or MSIECookieJar?

But the document says "perhaps save cookies to, a file on disk. "
http://docs.python.org/2/library/cookielib.html?highlight=filecookiejar#cookielib.FileCookieJar

it looks like FileCookieJar is just a base class.it shouldn't be used on normal purpose(like save your cookie).then the document should be modified.
but I think it's better to make the FileCookieJar works as expected.

----------
messages: 179777
nosy: C19
priority: normal
severity: normal
status: open
title: seriously? http.cookiejar.FileCookieJar().save method NOTImplemented?
type: enhancement
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jan 12 09:29:18 2013
From: report at bugs.python.org (C19)
Date: Sat, 12 Jan 2013 08:29:18 +0000
Subject: [New-bugs-announce] [issue16943] seriously? FileCookieJar can't
	really save ? save method	is NotImplemented
Message-ID: <1357979358.05.0.978193495603.issue16943@psf.upfronthosting.co.za>


New submission from C19:

Is it means that we should use MozillaCookieJar LWPCookieJar or MSIECookieJar?

But the document says "perhaps save cookies to, a file on disk. "
http://docs.python.org/2/library/cookielib.html?highlight=filecookiejar#cookielib.FileCookieJar

it looks like FileCookieJar is just a base class.it shouldn't be used on normal purpose(like save your cookie).then the document should be modified.
but I think it's better to make the FileCookieJar works as expected.

----------
messages: 179779
nosy: C19
priority: normal
severity: normal
status: open
title: seriously? FileCookieJar can't really save ?  save method is NotImplemented

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

From report at bugs.python.org  Sat Jan 12 12:26:56 2013
From: report at bugs.python.org (Peter Stahl)
Date: Sat, 12 Jan 2013 11:26:56 +0000
Subject: [New-bugs-announce] [issue16944] German number separators not
	working using format	language and locale "de_DE"
Message-ID: <1357990016.64.0.159100060877.issue16944@psf.upfronthosting.co.za>


New submission from Peter Stahl:

Yesterday, I opened a question on Stackoverflow that explains my problem in detail. Please read this page first:

http://stackoverflow.com/questions/14287051/german-number-separators-using-format-language-on-osx

A short summary: I'm on OSX 10.8.2. I wanted to format numbers according to the German numbering convention using Python's format language and the locale setting "de_DE". Actually, the following should work to achieve that:

>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'de_DE')
>>> '{0:n}'.format(1234.56)

The result of the last expressions should be 1.234,56. However, my result is 1234,56. More examples are on Stackoverflow.

According to what other SO members have found out, this is a problem with the locale settings of OSX because the grouping of numbers is not fully part of the locale "de_DE". On Windows, however, grouping works fine using the locale "deu_deu" which is not available on OSX.

Is this a bug? At least, it doesn't seem to be documented anywhere and is probably not the correct behavior even on OSX. Others have reported similar problems on OSX as well.

Do you have a quick solution for this issue? Thanks in advance.

----------
components: Library (Lib)
messages: 179785
nosy: Peter.Stahl
priority: normal
severity: normal
status: open
title: German number separators not working using format language and locale "de_DE"
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/issue16944>
_______________________________________

From report at bugs.python.org  Sat Jan 12 15:14:43 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 12 Jan 2013 14:14:43 +0000
Subject: [New-bugs-announce] [issue16945] rewrite CGIHTTPRequestHandler to
	always use subprocess
Message-ID: <1358000083.64.0.0773347996342.issue16945@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

On Unix, CGIHTTPRequestHandler.run_cgi() uses the following code to run a CGI script:
"""
            pid = os.fork()
            [...]            
            # Child
            try:
                try:
                    os.setuid(nobody)
                except OSError:
                    pass
                os.dup2(self.rfile.fileno(), 0)
                os.dup2(self.wfile.fileno(), 1)
                os.execve(scriptfile, args, env)
"""

It's basically reimplementing subprocess.Popen, with a potential securiy issue: open file descriptors are not closed before exec, which means that the CGI script - which is run as 'nobody' on Unix to reduce its priviledges - can inherit open sockets or files (unless they're close-on-exec)...

The attached patch rewrites run_cgi() to use subprocess on all platorms.
I'm not at all familiar with CGI, so I don't guarantee it's correct, but  the regression test test_httpservers passes on Linux.

It leads to cleaner and safer code, so if someone with some httpsever/CGI background could review it, it would be great.

----------
files: cgi_subprocess.diff
keywords: needs review, patch
messages: 179797
nosy: neologix
priority: normal
severity: normal
stage: patch review
status: open
title: rewrite CGIHTTPRequestHandler to always use subprocess
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file28706/cgi_subprocess.diff

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

From report at bugs.python.org  Sat Jan 12 15:54:13 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 12 Jan 2013 14:54:13 +0000
Subject: [New-bugs-announce] [issue16946] subprocess:
	_close_open_fd_range_safe() does not set	close-on-exec flag
	on Linux < 2.6.23 if O_CLOEXEC is defined
Message-ID: <1358002453.56.0.227593845503.issue16946@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The following extract of _close_open_fd_range_safe() is not correct:

#ifdef O_CLOEXEC
    fd_dir_fd = open(FD_DIR, O_RDONLY | O_CLOEXEC, 0);
#else
    fd_dir_fd = open(FD_DIR, O_RDONLY, 0);
#ifdef FD_CLOEXEC
    {
        int old = fcntl(fd_dir_fd, F_GETFD);
        if (old != -1)
            fcntl(fd_dir_fd, F_SETFD, old | FD_CLOEXEC);
    }
#endif
#endif

On Linux older than 2.6.23, O_CLOEXEC may be defined by the glibc whereas the kernel does not support it. In this case, the flag is simply ignored and close-on-exec flag is not set on the file descriptor.

----------
messages: 179803
nosy: haypo, neologix
priority: normal
severity: normal
status: open
title: subprocess: _close_open_fd_range_safe() does not set close-on-exec flag on Linux < 2.6.23 if O_CLOEXEC is defined
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Jan 12 16:34:16 2013
From: report at bugs.python.org (Christoph Deil)
Date: Sat, 12 Jan 2013 15:34:16 +0000
Subject: [New-bugs-announce] [issue16947] Search for "sherpa" on pypi leads
	to gitflow
Message-ID: <1358004856.63.0.647695123889.issue16947@psf.upfronthosting.co.za>


New submission from Christoph Deil:

If you enter "sherpa" on http://pypi.python.org you currently get
http://pypi.python.org/pypi/gitflow/0.5.0

Why?
It doesn't make much sense as the term "sherpa" doesn't appear on that pypi page.
Instead pypi should say "not found", as the sherpa Python package
is not registered on pypi:
http://cxc.cfa.harvard.edu/contrib/sherpa/

----------
components: None
messages: 179813
nosy: Christoph.Deil
priority: normal
severity: normal
status: open
title: Search for "sherpa" on pypi leads to gitflow
type: behavior

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

From report at bugs.python.org  Sat Jan 12 19:52:55 2013
From: report at bugs.python.org (Jakub Wilk)
Date: Sat, 12 Jan 2013 18:52:55 +0000
Subject: [New-bugs-announce] [issue16948] email.mime.text.MIMEText: QP
	encoding broken with	charset!=ISO-8859-1
Message-ID: <1358016775.26.0.412297588527.issue16948@psf.upfronthosting.co.za>


New submission from Jakub Wilk:

If you try to create MIMEText object with text containing characters outside the ISO-8859-1 range,
the quoted-printable encoder fails with KeyError:

Python 3.2.3 (default, Sep 10 2012, 12:58:42) 
[GCC 4.7.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import email.mime.text
>>> email.mime.text.MIMEText('\u017c', 'plain', 'ISO-8859-2')
Traceback (most recent call last):
  File "/usr/lib/python3.2/email/message.py", line 331, in set_charset
    cte(self)
TypeError: 'str' object is not callable

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/email/mime/text.py", line 30, in __init__
    self.set_payload(_text, _charset)
  File "/usr/lib/python3.2/email/message.py", line 296, in set_payload
    self.set_charset(charset)
  File "/usr/lib/python3.2/email/message.py", line 333, in set_charset
    self._payload = charset.body_encode(self._payload)
  File "/usr/lib/python3.2/email/charset.py", line 395, in body_encode
    return email.quoprimime.body_encode(string)
  File "/usr/lib/python3.2/email/quoprimime.py", line 240, in body_encode
    if body_check(ord(c)):
  File "/usr/lib/python3.2/email/quoprimime.py", line 81, in body_check
    return chr(octet) != _QUOPRI_BODY_MAP[octet]
KeyError: 380

----------
components: Library (Lib)
messages: 179826
nosy: jwilk
priority: normal
severity: normal
status: open
title: email.mime.text.MIMEText: QP encoding broken with charset!=ISO-8859-1
versions: Python 3.2

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

From report at bugs.python.org  Sun Jan 13 10:56:42 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 13 Jan 2013 09:56:42 +0000
Subject: [New-bugs-announce] [issue16949] removal of string exceptions is
	already done
Message-ID: <1358071002.08.0.359993938626.issue16949@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

This part of the PEP is written as if string exceptions are currently being removed, which is not the case.

Also, it is probably more accurate to say "they are forbidden *and* are removed", instead of "they are forbidden *because* they are are removed.

----------
assignee: docs at python
components: Documentation
files: string-exceptions.diff
keywords: patch
messages: 179854
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: removal of string exceptions is already done
Added file: http://bugs.python.org/file28712/string-exceptions.diff

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

From report at bugs.python.org  Sun Jan 13 11:20:38 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 13 Jan 2013 10:20:38 +0000
Subject: [New-bugs-announce] [issue16950] the old raise syntax is not legal
	in Python 3
Message-ID: <1358072438.43.0.0984946065161.issue16950@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

There is an outdated statement that "the old form of raising exceptions *will* be removed in Python 3". It's ambiguous in that you don't know if such was ever in Python 3, and it is also time-sensitive (and now outdated).

----------
assignee: docs at python
components: Documentation
messages: 179857
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: the old raise syntax is not legal in Python 3

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

From report at bugs.python.org  Sun Jan 13 11:43:21 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 13 Jan 2013 10:43:21 +0000
Subject: [New-bugs-announce] [issue16951] expand on meaning of 'string
	literals that rely on	significant trailing whitespace'
Message-ID: <1358073801.18.0.127692907122.issue16951@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

In PEP 8, there is:

> Don't write string literals that rely on significant trailing whitespace

It's not clear to me what this means, and therefore likely needs further explanation, or maybe an example.

----------
assignee: docs at python
components: Documentation
messages: 179861
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: expand on meaning of 'string literals that rely on significant trailing whitespace'

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

From report at bugs.python.org  Sun Jan 13 15:24:57 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 13 Jan 2013 14:24:57 +0000
Subject: [New-bugs-announce] [issue16952] test_kqueue failure on
	NetBSD/OpenBSD
Message-ID: <1358087097.62.0.636962955587.issue16952@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

test_kqueue fails on both NetBSD and OpenBSD:
http://buildbot.python.org/all/builders/AMD64 NetBSD 5.1.2 [SB] 2.7/builds/206/steps/test/logs/stdio
http://buildbot.python.org/all/builders/x86 OpenBSD 5.1 [SB] 2.7/builds/153/steps/test/logs/stdio

"""
======================================================================
FAIL: test_queue_event (test.test_kqueue.TestKQueue)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/2.7.snakebite-netbsd51-amd64-1/build/Lib/test/test_kqueue.py", line 129, in test_queue_event
    (server.fileno(), select.KQ_FILTER_WRITE, flags)])
AssertionError: Lists differ: [(10L, 1, 5L), (11L, 1, 5L)] != [(10, 1, 0), (11, 1, 0)]

First differing element 0:
(10L, 1, 5L)
(10, 1, 0)

- [(10L, 1, 5L), (11L, 1, 5L)]
?     -     ^^      -     ^^

+ [(10, 1, 0), (11, 1, 0)]
?          ^     
"""

The test assumes that the input flags (EV_ADD, EV_ENABLE...) will be returned in the output events. It's apparently not the case on OpenBSD and NetBSD (and probably on OS-X neither, because this check is disabled on this platform), and I can't see anything in the kqueue man pages hinting to this behavior (only specific flags will be set on output, like EV_ERROR). Knowing which flag was specified is not really useful actually.

The patch attached just removes this check (we keep checking the file descriptors and filter, of course).

----------
components: Tests
files: kqueue_flags.diff
keywords: needs review, patch
messages: 179877
nosy: neologix
priority: normal
severity: normal
stage: patch review
status: open
title: test_kqueue failure on NetBSD/OpenBSD
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28716/kqueue_flags.diff

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

From report at bugs.python.org  Sun Jan 13 16:16:47 2013
From: report at bugs.python.org (Jeffrey Armstrong)
Date: Sun, 13 Jan 2013 15:16:47 +0000
Subject: [New-bugs-announce] [issue16953] select module compile errors with
	broken poll()
Message-ID: <1358090207.46.0.168893562031.issue16953@psf.upfronthosting.co.za>


New submission from Jeffrey Armstrong:

On a platform with a broken poll() function (as detected during configure), Modules/selectmodule.c fails to compile.  The error occurs at two points:

./Modules/selectmodule.c:2100: `select_poll' undeclared here (not in a function)
./Modules/selectmodule.c:2100: initializer element is not constant
./Modules/selectmodule.c:2100: (near initialization for `select_methods[1].ml_meth')
./Modules/selectmodule.c:2100: `poll_doc' undeclared here (not in a function)
./Modules/selectmodule.c:2100: initializer element is not constant
./Modules/selectmodule.c:2100: (near initialization for `select_methods[1].ml_doc')
./Modules/selectmodule.c: In function `PyInit_select':
./Modules/selectmodule.c:2159: `poll_Type' undeclared (first use in this function)
./Modules/selectmodule.c:2159: (Each undeclared identifier is reported only once
./Modules/selectmodule.c:2159: for each function it appears in.)

The problem is occurring because both "select_poll" and "poll_Type" are undeclared if HAVE_BROKEN_POLL is declared.  The fix would be on two lines:

selectmodule.c:2099
#ifdef(HAVE_POLL)
should be:
#if defined(HAVE_POLL) && !defined(HAVE_BROKEN_POLL)

selectmodule.c:2149
#if defined(HAVE_POLL)
should be:
#if defined(HAVE_POLL) && !defined(HAVE_BROKEN_POLL)

Making these two minor changes allows selectmodule.c to compile fine in the case where the platform has a "broken" poll().

This bug was found on m68k-atari-mint compiling using gcc 2.95.3

----------
components: Build
messages: 179880
nosy: Jeffrey.Armstrong
priority: normal
severity: normal
status: open
title: select module compile errors with broken poll()
versions: Python 3.3

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

From report at bugs.python.org  Sun Jan 13 16:26:53 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 13 Jan 2013 15:26:53 +0000
Subject: [New-bugs-announce] [issue16954] Add docstrings for ElementTree
	module
Message-ID: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Perhaps almost all Doxygen comments in ElementTree module should be converted to docstrings.

----------
assignee: docs at python
components: Documentation, XML
messages: 179881
nosy: docs at python, eli.bendersky, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Add docstrings for ElementTree module
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Jan 13 18:37:15 2013
From: report at bugs.python.org (John Brearley)
Date: Sun, 13 Jan 2013 17:37:15 +0000
Subject: [New-bugs-announce] [issue16955] multiprocessing.connection poll()
	always returns false
Message-ID: <1358098635.68.0.0505000601155.issue16955@psf.upfronthosting.co.za>


New submission from John Brearley:

In the attached multiprocessing.connection simple client script, the poll() method is always returning false. If I force the temp variable to 1, the recv()method happily gets the incoming data. I had hoped to use the poll() method to implement a timeout error, to avoid the blocking nature of the client.

----------
files: socket_client_mp.py
messages: 179885
nosy: jbrearley
priority: normal
severity: normal
status: open
title: multiprocessing.connection poll() always returns false
versions: Python 3.3
Added file: http://bugs.python.org/file28717/socket_client_mp.py

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

From report at bugs.python.org  Sun Jan 13 19:42:34 2013
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 13 Jan 2013 18:42:34 +0000
Subject: [New-bugs-announce] [issue16956] Allow signed line number deltas in
	the code object's	line number table
Message-ID: <1358102554.86.0.0981281614451.issue16956@psf.upfronthosting.co.za>


New submission from Mark Shannon:

The restriction that line numbers must be monotonically increasing w.r.t bytecode offset in the co_lnotab array prevents a number of beneficial transformations in the bytecode compiler.

This patch allows negative line number deltas and uses this capability to generate code for 'while' loops in standard text book fashion, putting the test *after* the body.

----------
hgrepos: 172
messages: 179887
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Allow signed line number deltas in the code object's  line number table

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

From report at bugs.python.org  Sun Jan 13 23:13:51 2013
From: report at bugs.python.org (Thomas Kluyver)
Date: Sun, 13 Jan 2013 22:13:51 +0000
Subject: [New-bugs-announce] [issue16957] shutil.which() shouldn't look in
	working directory on	unix-y systems
Message-ID: <1358115231.51.0.337758586749.issue16957@psf.upfronthosting.co.za>


New submission from Thomas Kluyver:

There's a 'short circuit' in shutil.which(), described as 'If we're given a full path which matches the mode and it exists, we're done here.'

It also matches if an executable file of the same name is present in the working directory, although on most Unix-y systems you need ./ to execute such files in a shell (i.e. ./foo, not just foo).

This could fool code calling which() into thinking that a program is installed, when it is not.

If we consider this a bug, one simple fix would be to only allow the short circuit with an absolute path, so the line

    if _access_check(cmd, mode):

would become

    if os.path.isabs(cmd) and _access_check(cmd, mode):

----------
components: Library (Lib)
messages: 179897
nosy: takluyver
priority: normal
severity: normal
status: open
title: shutil.which() shouldn't look in working directory on unix-y systems
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Jan 14 01:46:45 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Jan 2013 00:46:45 +0000
Subject: [New-bugs-announce] [issue16958] The sqlite3 context manager does
	not work with	isolation_level=None
Message-ID: <1358124405.04.0.0310758361359.issue16958@psf.upfronthosting.co.za>


New submission from R. David Murray:

Its operation is also not particularly intuitive if isolation_level is not None, so its documentation needs some clarification.

Currently the transaction manager does nothing on enter, and does a commit or rollback on exit, depending on whether or not there was an exception inside the with block.  With isolation_level set to None, the sqlite3 library is in autocommit mode, so changes will get committed immediately inside the with, which is simply broken.

If isolation_level is not None, then the behavior of the transaction manager depends heavily on what happens inside the with block.  If the with block contains only the defined DQL statements (insert, update, delete, replace) and select statements, then things will work as expected.  However, if another statement (such as a CREATE TABLE or a PRAGMA) is included in the with block, an intermediate commit will be done and a new transaction started.

I propose to do two things to fix this issue: explain the above in the transactions manager docs, and have the context manager check to see if we are in isolation_level None, and if so, issue a begin (and then document that as well).

One question is, can the fix be backported?  It will change the behavior of code that doesn't throw an error, but most such code won't be doing what the author expected (run the with block inside a transaction...in pure autocommit mode the transaction manager is a no-op).  One place code could break is if someone figured out this issue and worked around it by explicitly starting a transaction before (or after) entering the with block.  In this case they would now get an error that a transaction cannot be started inside another.  I would think this is unlikely...the more obvious workaround would be to write a custom transaction manager, so I suspect that that is what is actually in the field.  But that's a (hopeful :) guess.

A fix for this problem would be to use 'savepoint' instead of 'begin' if the sqlite3 version supports it (it is apparently supported as of 3.6.8).

So, I'd like to see the fix, conditionally using SAVEPOINT, (once it written and tested) applied to all active python versions, but am open to the argument that it shouldn't be.

----------
components: Extension Modules, Library (Lib)
keywords: easy
messages: 179909
nosy: ghaering, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: The sqlite3 context manager does not work with isolation_level=None
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Jan 14 04:59:03 2013
From: report at bugs.python.org (Aaron Meurer)
Date: Mon, 14 Jan 2013 03:59:03 +0000
Subject: [New-bugs-announce] [issue16959] rlcompleter doesn't work if
	__main__ can't be imported
Message-ID: <1358135943.75.0.97619198268.issue16959@psf.upfronthosting.co.za>


New submission from Aaron Meurer:

The rlcompleter module does not work if __main__ cannot be imported, even though it can be used without it.  For example, on the App Engine, __main__ is not usable.  

If one creates the example app described at https://developers.google.com/appengine/docs/python/gettingstartedpython27/helloworld, and adds "import rlcompleter" to the top of helloworld.py, you get the following error in the AppEngine

Traceback (most recent call last):
  File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/runtime/wsgi.py", line 196, in Handle
    handler = _config_handle.add_wsgi_middleware(self._LoadHandler())
  File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/runtime/wsgi.py", line 255, in _LoadHandler
    handler = __import__(path[0])
  File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 692, in Decorate
    return func(self, *args, **kwargs)
  File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 1766, in load_module
    return self.FindAndLoadModule(submodule, fullname, search_path)
  File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 692, in Decorate
    return func(self, *args, **kwargs)
  File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 1630, in FindAndLoadModule
    description)
  File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 692, in Decorate
    return func(self, *args, **kwargs)
  File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 1577, in LoadModuleRestricted
    description)
  File "/Users/aaronmeurer/Desktop/helloworld/helloworld.py", line 2, in <module>
    import rlcompleter
  File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 692, in Decorate
    return func(self, *args, **kwargs)
  File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 1766, in load_module
    return self.FindAndLoadModule(submodule, fullname, search_path)
  File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 692, in Decorate
    return func(self, *args, **kwargs)
  File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 1630, in FindAndLoadModule
    description)
  File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 692, in Decorate
    return func(self, *args, **kwargs)
  File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 1577, in LoadModuleRestricted
    description)
  File "/sw/lib/python2.7/rlcompleter.py", line 43, in <module>
    import __main__
  File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 692, in Decorate
    return func(self, *args, **kwargs)
  File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 1766, in load_module
    return self.FindAndLoadModule(submodule, fullname, search_path)
  File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 692, in Decorate
    return func(self, *args, **kwargs)
  File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 1630, in FindAndLoadModule
    description)
  File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 692, in Decorate
    return func(self, *args, **kwargs)
  File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/dev_appserver_import_hook.py", line 1577, in LoadModuleRestricted
    description)
ImportError: Cannot re-init internal module __main__

Now, I don't really understand what the issue is here.  I don't really get how __main__ is supposed to work, whether this is something that might be expected to happen in an environment that isn't highly modded like the App Engine's.  Probably this should at least be considered an App Engine bug. 

My point is that it's possible to use the rlcompleter module completely without __main__, if one passes the optional argument to Completer.  

My suggestion is to catch ImportError when importing __main__, and if it isn't importable, make the argument to Completer required. It should be a minimal code change.

----------
components: Library (Lib)
messages: 179917
nosy: Aaron.Meurer
priority: normal
severity: normal
status: open
title: rlcompleter doesn't work if __main__ can't be imported
type: behavior

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

From report at bugs.python.org  Mon Jan 14 09:59:39 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Mon, 14 Jan 2013 08:59:39 +0000
Subject: [New-bugs-announce] [issue16960] Fix PEP8 errors in stdlib.
Message-ID: <1358153979.38.0.822935227823.issue16960@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

This bug is intended to contain all the patches for fixing PEP8 errors in stdlib.
I am thinking of using a tool such as autopep8 to help fix the errors.

----------
messages: 179921
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: Fix PEP8 errors in stdlib.

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

From report at bugs.python.org  Mon Jan 14 13:03:14 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 14 Jan 2013 12:03:14 +0000
Subject: [New-bugs-announce] [issue16961] No regression tests for -E and
	individual environment	vars
Message-ID: <1358164994.53.0.497203238771.issue16961@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Accessing an environment variable without Py_GETENV (or breaking Py_IgnoreEnvironmentFlag configuration *cough*) may lead to environment variables being accessed even if -E is passed on the command line.

As part of the PEP 432 implementation, I'm adding appropriate regression tests for affected environment variables as I go.

Creating this as a reminder to look into backporting the relevant regression tests at least to 3.3

----------
assignee: ncoghlan
messages: 179934
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: No regression tests for -E and individual environment vars
versions: Python 3.3

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

From report at bugs.python.org  Mon Jan 14 13:22:02 2013
From: report at bugs.python.org (Riku Voipio)
Date: Mon, 14 Jan 2013 12:22:02 +0000
Subject: [New-bugs-announce] [issue16962] _posixsubprocess module uses
	outdated getdents system	call
Message-ID: <1358166122.64.0.0915225985014.issue16962@psf.upfronthosting.co.za>


New submission from Riku Voipio:

Getdents system call was superseded with with getdents64 in Linux 2.4 (January 2001). New architectures, such as 64-Bit ARM opt out not to support legacy system calls, and getdents is one of them. 

Since getdents64 has been supported for over a decade, I don't think adding ifdef to support both makes sense. Using getdents64 cleans up the current _posixsubprocess code as the entries are long long everywhere.

The attached patch makes _posixsubprocess module compile on 64-Bit ARM and causes on regressions on the python3.3 testsuite on x86 and x86_64

----------
components: Extension Modules
files: movetogetdents64.diff
keywords: patch
messages: 179937
nosy: riku-voipio
priority: normal
severity: normal
status: open
title: _posixsubprocess module uses outdated getdents system call
versions: Python 3.3
Added file: http://bugs.python.org/file28723/movetogetdents64.diff

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

From report at bugs.python.org  Mon Jan 14 13:54:15 2013
From: report at bugs.python.org (sean)
Date: Mon, 14 Jan 2013 12:54:15 +0000
Subject: [New-bugs-announce] [issue16963] module html.parser HTMLParser's
	strict mode don't work
Message-ID: <1358168055.33.0.344614733443.issue16963@psf.upfronthosting.co.za>


New submission from sean:

NOTE: SAME AS Python 3.2.2, Python 3.3 from python.org/download

Python 3.2.2 Stackless 3.1b3 060516 (default, Feb 20 2012, 13:36:12) [MSC v.1500 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> from html.parser import HTMLParser
>>> class LooseParser(HTMLParser):
	def __init__(self, strict=False):
		HTMLParser.__init__(self, strict=strict)
	def handle_starttag(self, tag, attrs):
		print('Tag:', tag)

		
>>> p = LooseParser()
>>> p.feed('<p>hello</p>')
>>>

----------
components: Library (Lib)
messages: 179938
nosy: pysean
priority: normal
severity: normal
status: open
title: module html.parser HTMLParser's strict mode don't work
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Jan 14 17:54:54 2013
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 14 Jan 2013 16:54:54 +0000
Subject: [New-bugs-announce] [issue16964] Add 'm' format specifier for
	mon_grouping etc.
Message-ID: <1358182494.33.0.0372215578091.issue16964@psf.upfronthosting.co.za>


New submission from Stefan Krah:

This issue proposes an additional 'm' format specifier that behaves like
'n', but uses mon_grouping, mon_decimal_point and mon_thousands_sep.

See #16944 for the rationale.

----------
components: Interpreter Core
messages: 179955
nosy: Peter.Stahl, eric.smith, mark.dickinson, skrah
priority: low
severity: normal
stage: needs patch
status: open
title: Add 'm' format specifier for mon_grouping etc.
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Jan 14 19:24:06 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 14 Jan 2013 18:24:06 +0000
Subject: [New-bugs-announce] [issue16965] 2to3 should rewrite execfile() to
	open in 'rb' mode
Message-ID: <1358187846.57.0.700535378161.issue16965@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

In this distribute bug I describe a problem when pip installing mimeparse, which has a setup.py with a BOM.  distribute uses execfile() which gets fixed in Python 3 to use a combination of compile(open()) as the fixer.

https://bitbucket.org/tarek/distribute/issue/349/dont-rely-on-2to3-to-properly-rewrite

I think the problem is that the fixer opens the file in text mode, which leaves the BOM as a bogus first character, causing the SyntaxError.  Instead, if the fixer opened the file in binary mode, then the BOM would be handled correctly by compile().

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 179964
nosy: barry
priority: normal
severity: normal
status: open
title: 2to3 should rewrite execfile() to open in 'rb' mode
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Jan 14 19:42:54 2013
From: report at bugs.python.org (John Brearley)
Date: Mon, 14 Jan 2013 18:42:54 +0000
Subject: [New-bugs-announce] [issue16966] Publishing multiprocessing
	listener code
Message-ID: <8053927136E1407BA60A52EA84F498B8@jrb>


New submission from John Brearley:

Hi Richard: I have published my multiprocessing server & client scripts on the 2
web sites shown below in the hopes that they will help others learning this
module. I haven't seen anyplace on the python.org web site that might be
suitable for a copy. Are people encouraged to post sample scripts on python.org?

http://codereview.stackexchange.com/questions/20516/sample-python-multiprocessin
g-connection-server

http://www.tek-tips.com/viewthread.cfm?qid=1701937

Regards, John Brearley 
613-259-5622 (H)

----------
messages: 179968
nosy: jbrearley
priority: normal
severity: normal
status: open
title: Publishing multiprocessing listener code

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

From report at bugs.python.org  Mon Jan 14 20:37:14 2013
From: report at bugs.python.org (Kay Hayen)
Date: Mon, 14 Jan 2013 19:37:14 +0000
Subject: [New-bugs-announce] [issue16967] Keyword keyword only default
	parameters are evaluated	before po
Message-ID: <1358192234.34.0.230545519043.issue16967@psf.upfronthosting.co.za>


New submission from Kay Hayen:

Suprisingly, keyword only arguments become evaluated first:

>>> def f(a=undefined1,*,b=undefined2):pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'undefined2' is not defined

It should be "undefined1".

I am sure, this is going to surprise developers and breaks assumptions, people tend to make. So far (to my knowledge) nothing that was separated by a "," could be evaluated in a mixed order.

Please consider to change this around.

----------
components: Interpreter Core
messages: 179970
nosy: Kay.Hayen
priority: normal
severity: normal
status: open
title: Keyword keyword only default parameters are evaluated before po
versions: Python 3.2

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

From report at bugs.python.org  Mon Jan 14 23:19:34 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 14 Jan 2013 22:19:34 +0000
Subject: [New-bugs-announce] [issue16968] Fix test discovery for
	test_concurrent_futures.py
Message-ID: <1358201974.23.0.0352259739582.issue16968@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Here's an incomplete patch to test_concurrent_futures.py that does not convert from test_main() to unittest.main(); the decorator on test_main has me unsure how to make the conversion.  I've attempted moving various parts of the decorator's functions to setUpModule and tearDownModule functions, but always wind up with a warning that the test has modified threading._dangling.

Guidance on this one would be much appreciated :)

----------
components: Tests
files: test_concurrent_futures_discovery.diff
keywords: patch
messages: 179983
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_concurrent_futures.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28729/test_concurrent_futures_discovery.diff

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

From report at bugs.python.org  Tue Jan 15 06:51:57 2013
From: report at bugs.python.org (Ry Erickson)
Date: Tue, 15 Jan 2013 05:51:57 +0000
Subject: [New-bugs-announce] [issue16969] test_urlwithfrag fail
Message-ID: <1358229117.2.0.683341810449.issue16969@psf.upfronthosting.co.za>


New submission from Ry Erickson:

Prevents correct installation. OS: Linux Mint 12 Lisa.

----------
components: Tests
files: test
messages: 180003
nosy: Ry
priority: normal
severity: normal
status: open
title: test_urlwithfrag fail
type: compile error
versions: Python 3.3
Added file: http://bugs.python.org/file28730/test

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

From report at bugs.python.org  Tue Jan 15 13:09:51 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 15 Jan 2013 12:09:51 +0000
Subject: [New-bugs-announce] [issue16970] argparse: bad nargs value raises
	misleading message
Message-ID: <1358251791.34.0.358251606196.issue16970@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('foo', nargs='a')
  ...
  File ".../Lib/argparse.py", line 1333, in add_argument
    raise ValueError("length of metavar tuple does not match nargs")
ValueError: length of metavar tuple does not match nargs

The message should really be about nargs not having a valid value.  The nargs value is invalid regardless of the metavar.  There is also this:

>>> parser.add_argument('foo', nargs=-1)
_StoreAction(option_strings=[], dest='foo', nargs=-1, const=None, default=None, type=None, choices=None, help=None, metavar=None)

which is not consistent with this:

>>> parser.add_argument('foo', nargs=0)
  ...
    raise ValueError('nargs for store actions must be > 0; if you '
ValueError: nargs for store actions must be > 0; if you have nothing to store, actions such as store true or store const may be more appropriate

----------
components: Library (Lib)
keywords: easy
messages: 180012
nosy: bethard, chris.jerdonek
priority: normal
severity: normal
stage: needs patch
status: open
title: argparse: bad nargs value raises misleading message
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Jan 15 15:05:51 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2013 14:05:51 +0000
Subject: [New-bugs-announce] [issue16971] Refleaks in charmap decoder
Message-ID: <1358258751.8.0.391798915658.issue16971@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Charmap decoder can leak a reference in case of error.

----------
components: Unicode
files: charmap_decode_leaks-3.3.patch
keywords: 3.3regression, patch
messages: 180018
nosy: ezio.melotti, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Refleaks in charmap decoder
type: resource usage
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28738/charmap_decode_leaks-3.3.patch

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

From report at bugs.python.org  Tue Jan 15 16:19:18 2013
From: report at bugs.python.org (Kirill)
Date: Tue, 15 Jan 2013 15:19:18 +0000
Subject: [New-bugs-announce] [issue16972] Useless function call in site.py
Message-ID: <1358263158.12.0.256435330615.issue16972@psf.upfronthosting.co.za>


New submission from Kirill:

In Lib/site.py:149 [1] _init_pathinfo call has no effect.  Looks like it's here because in the past _init_pathinfo was changing a global variable [2].  I believe that it should be changed to `known_paths = _init_pathinfo()`, in the same way as it's done in addsitedir function [3].

[1] http://hg.python.org/cpython/file/fb17969ace93/Lib/site.py#l149
[2] http://hg.python.org/cpython/annotate/ac13a6ce13e2/Lib/site.py#l102
[3] http://hg.python.org/cpython/file/fb17969ace93/Lib/site.py#l189

----------
components: Library (Lib)
files: patch.diff
keywords: patch
messages: 180022
nosy: x746e
priority: normal
severity: normal
status: open
title: Useless function call in site.py
type: enhancement
Added file: http://bugs.python.org/file28740/patch.diff

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

From report at bugs.python.org  Tue Jan 15 17:07:47 2013
From: report at bugs.python.org (Grant)
Date: Tue, 15 Jan 2013 16:07:47 +0000
Subject: [New-bugs-announce] [issue16973] Extending the datetime package by
	adding a workDayMath	module
Message-ID: <1358266067.49.0.788080325558.issue16973@psf.upfronthosting.co.za>


New submission from Grant:

This module would allow programmers to perform high level workday addition and subtraction - a commonly needed function in the finance and accounting world not yet provided in a standard python module.

----------
components: Extension Modules
files: workDayMath.py
messages: 180029
nosy: belopolsky, grantf
priority: normal
severity: normal
status: open
title: Extending the datetime package by adding a workDayMath module
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file28741/workDayMath.py

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

From report at bugs.python.org  Tue Jan 15 22:40:06 2013
From: report at bugs.python.org (Eric Lammerts)
Date: Tue, 15 Jan 2013 21:40:06 +0000
Subject: [New-bugs-announce] [issue16974] when "python -c command" does a
	traceback, it open the file "<string>"
Message-ID: <1358286006.48.0.232332339533.issue16974@psf.upfronthosting.co.za>


New submission from Eric Lammerts:

$ echo lovely spam > "<string>"

$ python -c 'open("nonexistent","r")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
    lovely spam
IOError: [Errno 2] No such file or directory: 'nonexistent'

I see this in python 2.7.3 and 3.2.3 from Ubuntu 12.04.

----------
messages: 180055
nosy: eric-bugs-python
priority: normal
severity: normal
status: open
title: when "python -c command" does a traceback, it open the file "<string>"
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Jan 15 22:42:51 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2013 21:42:51 +0000
Subject: [New-bugs-announce] [issue16975] Broken error handling in
	codecs.escape_decode()
Message-ID: <1358286171.54.0.132780688137.issue16975@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

>>> import codecs
>>> codecs.escape_decode(r'\x1\x2\x3\x4\x5\x6\x7\x8\x9', 'replace')
(b'?\\x1?\\x2?\\x3?\\x4?\\x5?\\x6?\\x', 27)
>>> codecs.escape_decode(r'\x1\x2\x3\x4\x5\x6\x7\x8\x9' * 1000, 'replace')
Segmentation fault

----------
components: Interpreter Core
messages: 180056
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Broken error handling in codecs.escape_decode()
type: crash
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Jan 15 23:02:45 2013
From: report at bugs.python.org (Anthony Lozano)
Date: Tue, 15 Jan 2013 22:02:45 +0000
Subject: [New-bugs-announce] [issue16976] Asyncore/asynchat hangs when used
	with ssl sockets
Message-ID: <1358287365.37.0.159760356153.issue16976@psf.upfronthosting.co.za>


New submission from Anthony Lozano:

If you create a asynchat subclass with a SSL socket asyncore can hang when data larger than the ac_in_buffer_size comes in. 

What (I think) happens is that asyncore uses a select.select call to determine when to read more data from the socket. On the first call, this will correctly see that there is data to recv and we will continue on to the handle_read function in asynchat. Once there, if there is more than ac_in_buffer_size data to read, handle_read will not find the terminator, and thus not call find_terminator, expecting to find it on the next pass with another self.recv. Unfortunately, the SSL wrapped socket will not play nicely with next select call (the one that should be triggering the next handle_read) because the ssl socket might internally read more data, and select is looking at the raw socket which is empty now thanks to ssl (at least according to an answer here: http://stackoverflow.com/questions/3187565/select-and-ssl-in-python).

 A solution would be to check the if the socket has any data pending with the sslsock.pending() method and read the rest out. I am doing this in the handle_read function of my child class as attached, but I don't know if that's a generic enough solution for everyone.

----------
components: None
files: asychat_fix.py
messages: 180058
nosy: Anthony.Lozano
priority: normal
severity: normal
status: open
title: Asyncore/asynchat hangs when used with ssl sockets
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file28746/asychat_fix.py

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

From report at bugs.python.org  Wed Jan 16 03:30:07 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 16 Jan 2013 02:30:07 +0000
Subject: [New-bugs-announce] [issue16977] argparse: mismatch between choices
	parsing and	usage/error message
Message-ID: <1358303407.58.0.0453921356618.issue16977@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

When passing a string for the choices argument, argparse's usage and error messages differ from its behavior:

>>> p = argparse.ArgumentParser()
>>> p.add_argument('a', choices='abc')
>>> p.parse_args(['d'])
usage: [-h] {a,b,c}
: error: argument a: invalid choice: 'd' (choose from 'a', 'b', 'c')
>>> p.parse_args(['bc'])
Namespace(a='bc')

This is because argparse uses the "in" operator instead of sequence iteration to check whether an argument value is valid.  Any resolution should also consider the behavior for string subclasses as well as perhaps bytes-like objects.

----------
components: Library (Lib)
messages: 180068
nosy: chris.jerdonek
priority: normal
severity: normal
stage: test needed
status: open
title: argparse: mismatch between choices parsing and usage/error message
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Jan 16 07:39:36 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 16 Jan 2013 06:39:36 +0000
Subject: [New-bugs-announce] [issue16978] fix grammar in 'threading'
	documentation
Message-ID: <1358318376.01.0.33023815863.issue16978@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
assignee: docs at python
components: Documentation
files: grammar.diff
keywords: patch
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: fix grammar in 'threading' documentation
versions: Python 2.7
Added file: http://bugs.python.org/file28748/grammar.diff

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

From report at bugs.python.org  Wed Jan 16 11:46:45 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 16 Jan 2013 10:46:45 +0000
Subject: [New-bugs-announce] [issue16979] Broken error handling in
	codecs.unicode_escape_decode()
Message-ID: <1358333205.49.0.474914292402.issue16979@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

An error handler in unicode_escape_decode() eats at least one byte (or more) after illegal escape sequence.

>>> import codecs
>>> codecs.unicode_escape_decode(br'\u!@#', 'replace')
('?', 5)
>>> codecs.unicode_escape_decode(br'\u!@#$', 'replace')
('?@#$', 6)

raw_unicode_escape_decode() works right:

>>> codecs.raw_unicode_escape_decode(br'\u!@#', 'replace')
('?!@#', 5)
>>> codecs.raw_unicode_escape_decode(br'\u!@#$', 'replace')
('?!@#$', 6)

See also issue16975.

----------
assignee: serhiy.storchaka
components: Unicode
messages: 180077
nosy: ezio.melotti, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Broken error handling in codecs.unicode_escape_decode()
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Jan 16 14:42:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 16 Jan 2013 13:42:27 +0000
Subject: [New-bugs-announce] [issue16980] SystemError in
	codecs.unicode_escape_decode()
Message-ID: <1358343747.58.0.471745996102.issue16980@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

>>> import codecs
>>> codecs.unicode_escape_decode(b'\\\x80')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: invalid maximum character passed to PyUnicode_New

----------
assignee: serhiy.storchaka
components: Unicode
keywords: 3.3regression
messages: 180089
nosy: ezio.melotti, serhiy.storchaka
priority: high
severity: normal
stage: needs patch
status: open
title: SystemError in codecs.unicode_escape_decode()
type: crash
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Jan 16 17:18:05 2013
From: report at bugs.python.org (Brian Sutherland)
Date: Wed, 16 Jan 2013 16:18:05 +0000
Subject: [New-bugs-announce] [issue16981] ImportError hides real error when
	there too many open	files during an import
Message-ID: <1358353085.87.0.599698387339.issue16981@psf.upfronthosting.co.za>


New submission from Brian Sutherland:

When running Python inside PostgreSQL using plpython on OSX 10.7.5 I started coming across very strange and apparently random ImportErrors. For example, failing to find the stat module while importing site:

     Traceback (most recent call last):
       File "/Users/jinty/.buildout/eggs/setuptools-0.6c11-py2.7.egg/site.py", line 73, in <module>
         __boot()
       File "/Users/jinty/.buildout/eggs/setuptools-0.6c11-py2.7.egg/site.py", line 2, in __boot
         import sys, imp, os, os.path
       File "/Users/jinty/src/mp/lib/python2.7/os.py", line 49, in <module>
         import posixpath as path
       File "/Users/jinty/src/mp/lib/python2.7/posixpath.py", line 15, in <module>
         import stat
     ImportError: No module named stat

I debugged this by using PYTHONVERBOSE and modifying import.c with the attached patch. I found that stat.py was not found because fopen() failed with "Too many open files". There were not enough open files because OSX has insanely low limits and PostgreSQL was using a large chunk of that. ulimit -n 4096 resolved the errors. I spent a LOT of time trying to figure that out (see the thread at http://www.postgresql.org/message-id/20130114163014.GA600 at Brians-MacBook-Air.local).

The bug I wish to report is that the real error (Too many open files) is hidden by "ImportError: No module named stat". For anyone who does not want to modify import.c and rebuild python, it is almost impossible to figure out what is really happening.

----------
files: patch-Python-import.c.diff
keywords: patch
messages: 180092
nosy: jinty
priority: normal
severity: normal
status: open
title: ImportError hides real error when there too many open files during an import
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file28753/patch-Python-import.c.diff

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

From report at bugs.python.org  Wed Jan 16 17:56:20 2013
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 16 Jan 2013 16:56:20 +0000
Subject: [New-bugs-announce] [issue16982] _ssl not built --without-threads
Message-ID: <1358355380.96.0.943245942304.issue16982@psf.upfronthosting.co.za>


New submission from Stefan Krah:

_ssl is not built on the Fedora buildbot:

http://buildbot.python.org/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/3798/steps/test/logs/stdio


building '_ssl' extension
gcc -fPIC -Wno-unused-result -g -O0 -Wall -Wstrict-prototypes -I./Include -I. -IInclude -I/usr/local/include -I/home/buildbot/buildarea/3.x.krah-fedora/build/Include -I/home/buildbot/buildarea/3.x.krah-fedora/build -c /home/buildbot/buildarea/3.x.krah-fedora/build/Modules/_ssl.c -o build/temp.linux-x86_64-3.4-pydebug/home/buildbot/buildarea/3.x.krah-fedora/build/Modules/_ssl.o
/home/buildbot/buildarea/3.x.krah-fedora/build/Modules/_ssl.c: In function ?_servername_callback?:
/home/buildbot/buildarea/3.x.krah-fedora/build/Modules/_ssl.c:2398:5: warning: implicit declaration of function ?PyGILState_Ensure? [-Wimplicit-function-declaration]
/home/buildbot/buildarea/3.x.krah-fedora/build/Modules/_ssl.c:2403:9: warning: implicit declaration of function ?PyGILState_Release? [-Wimplicit-function-declaration]
gcc -shared build/temp.linux-x86_64-3.4-pydebug/home/buildbot/buildarea/3.x.krah-fedora/build/Modules/_ssl.o -L/usr/local/lib -lssl -lcrypto -o build/lib.linux-x86_64-3.4-pydebug/_ssl.cpython-34dm.so
*** WARNING: renaming "_ssl" since importing it failed: build/lib.linux-x86_64-3.4-pydebug/_ssl.cpython-34dm.so: undefined symbol: PyGILState_Release

Python build finished, but the necessary bits to build these modules were not found:
_lzma                 _multiprocessing                         
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


Failed to build these modules:
_ssl

----------
components: Extension Modules
messages: 180094
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: _ssl not built --without-threads
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan 16 22:13:44 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 16 Jan 2013 21:13:44 +0000
Subject: [New-bugs-announce] [issue16983] header parsing could apply
	postel's law to encoded words	inside quotes
Message-ID: <1358370824.34.0.785969797245.issue16983@psf.upfronthosting.co.za>


New submission from R. David Murray:

It has come to my attention that at least some mail agents apply postel's law to addresses like the following:

   From: "=?utf-8?Q?not_really_valid?=" <foo at example.com>

Since encountering something that looks like an encoded word but that is not is a very unlikely occurrence, we could go ahead and decode such strings, resulting in

   "not really valid" <foo at example.com>

a defect would be registered, and some sort of 'strict' policy mode could refuse to do the decode (as well as several other non-compliant patterns, such as encoded words not separated by whitespace).  I think the decoding should be the default, though.

This applies also to other headers where words or phrases can be quoted, such as in filenames.  I have also encountered the quoted-encoded-word-as-filename in the wild.

----------
components: email
messages: 180108
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: header parsing could apply postel's law to encoded words inside quotes
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan 16 22:53:03 2013
From: report at bugs.python.org (Sureyya Sahin)
Date: Wed, 16 Jan 2013 21:53:03 +0000
Subject: [New-bugs-announce] [issue16984] idle problem with dark color
	schemes in kde
Message-ID: <1358373183.37.0.59367070531.issue16984@psf.upfronthosting.co.za>


New submission from Sureyya Sahin:

I am trying to use IDLE in kde linux environment (kubuntu 12.10). I recently switched to a dark color scheme from kde settings and discovered that IDLE is having issues with dark colors.

The Completions boxes are not readable, after I switched to the dark color scheme in kde. The completions are white text on white background colored boxes which is making the text unreadable. If I select the options in the completions dialog box, my selection is highlighted and thus I can read the text.

----------
components: IDLE
files: snapshot-idle.png
messages: 180111
nosy: sahin
priority: normal
severity: normal
status: open
title: idle problem with dark color schemes in kde
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file28755/snapshot-idle.png

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

From report at bugs.python.org  Thu Jan 17 16:10:38 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 17 Jan 2013 15:10:38 +0000
Subject: [New-bugs-announce] [issue16985] Docs reference a concrete UTC
	tzinfo, but none exists
Message-ID: <1358435438.99.0.679592351451.issue16985@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

The Python 2.7 docs for datetime state, "The standard library has no tzinfo instances except for UTC," but if I read issue5094 correctly, Python 2.7 does not even have a UTC tzinfo instance, and never will. Is there any reason I shouldn't correct the docs to remove 'except for UTC'?

----------
assignee: docs at python
components: Documentation
messages: 180138
nosy: docs at python, jason.coombs
priority: normal
severity: normal
status: open
title: Docs reference a concrete UTC tzinfo, but none exists
versions: Python 2.7

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

From report at bugs.python.org  Thu Jan 17 17:54:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 17 Jan 2013 16:54:19 +0000
Subject: [New-bugs-announce] [issue16986] ElementTree incorrectly parses
	strings with declared	encoding not UTF-8
Message-ID: <1358441659.05.0.359191214505.issue16986@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

>>> import xml.etree.ElementTree
>>> data = '<?xml version="1.0" encoding="iso-8859-1"?>\n<money value="$\xa3\u20ac\U0001017b">$\xa3\u20ac\U0001017b</money>'
>>> xml.etree.ElementTree.tostring(xml.etree.ElementTree.fromstring(data), 'unicode')
'<money value="$???\x82??\x90\x85?">$???\x82??\x90\x85?</money>'

----------
components: XML
messages: 180143
nosy: eli.bendersky, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: ElementTree incorrectly parses strings with declared encoding not UTF-8
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Jan 17 20:24:46 2013
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 17 Jan 2013 19:24:46 +0000
Subject: [New-bugs-announce] [issue16987] HP-UX: SHLIB_EXT is not set
Message-ID: <1358450686.82.0.952706053804.issue16987@psf.upfronthosting.co.za>


New submission from Stefan Krah:

Since 5e33b27c71a8 SHLIB_EXT is not set in configure.ac, since
the block in which $SO is defined has been moved below this line:

AC_DEFINE_UNQUOTED(SHLIB_EXT, "$SO", [Define this to be extension of shared libraries (including the dot!).])


This prevents extension module loading on HP-UX.

----------
components: Extension Modules
messages: 180148
nosy: skrah
priority: normal
severity: normal
status: open
title: HP-UX: SHLIB_EXT is not set
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Jan 17 22:30:15 2013
From: report at bugs.python.org (Robert Leenders)
Date: Thu, 17 Jan 2013 21:30:15 +0000
Subject: [New-bugs-announce] [issue16988] argparse: PARSER option for nargs
	not documented
Message-ID: <1358458215.07.0.403888123098.issue16988@psf.upfronthosting.co.za>


New submission from Robert Leenders:

There is a value for nargs: PARSER="A..." which is not documented at http://docs.python.org/3.4/library/argparse.html#nargs. The docstring for the action class in argparse.py also does not list PARSER as a valid value for nargs.

In argparse.py on line 2199-2201 it says:
# Allow one argument followed by any number of options or arguments
elif nargs == PARSER:
    nargs_pattern = '(-*A[-AO]*)'

This is the only hint that I could find on what it is about.

----------
assignee: docs at python
components: Documentation
messages: 180155
nosy: ReDAeR, bethard, docs at python
priority: normal
severity: normal
status: open
title: argparse: PARSER option for nargs not documented
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Jan 18 00:41:55 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 17 Jan 2013 23:41:55 +0000
Subject: [New-bugs-announce] [issue16989] allow distutils debug mode to be
	enabled more easily
Message-ID: <1358466115.01.0.322407717365.issue16989@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to allow distutils's debug mode [1] to be enabled more easily (e.g. programmatically).

Currently, for example, distutils.core does the following:

    from distutils.debug import DEBUG

(from http://hg.python.org/cpython/file/cb297930d2cf/Lib/distutils/core.py#l12)

which means that it's not sufficient to set the DEBUG attribute on the distutils.debug module.  Instead, to enable debug mode programmatically you have to do something like the following prior to importing from distutils:

    import os
    os.environ['DISTUTILS_DEBUG'] = "1"  # "" for False or "1" for True.

This issue can be fixed simply by changing the affected import statements from importing the value to importing just the module (and subsequently accessing the value via the module).


[1] http://docs.python.org/dev/distutils/setupscript.html#debugging-the-setup-script

----------
assignee: eric.araujo
components: Distutils
keywords: easy
messages: 180161
nosy: chris.jerdonek, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: allow distutils debug mode to be enabled more easily
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Jan 18 00:49:03 2013
From: report at bugs.python.org (Jared Grubb)
Date: Thu, 17 Jan 2013 23:49:03 +0000
Subject: [New-bugs-announce] [issue16990] re: match of nongreedy regex not
	grouping right
Message-ID: <1358466543.42.0.996552051054.issue16990@psf.upfronthosting.co.za>


New submission from Jared Grubb:

re.match matches, but the capture groups are empty. That's not possible.

Python 2.7.2 (default, Oct 11 2012, 20:14:37) 
[GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re.match('.*', 'stuff').group()  # greedy matches and captures; cool.
'stuff'
>>> re.match('.*?', 'stuff').group() # nongreedy matches (cool) but doesnt capture (huh?)
''

----------
components: Library (Lib)
messages: 180162
nosy: jaredgrubb
priority: normal
severity: normal
status: open
title: re: match of nongreedy regex not grouping right
versions: Python 2.7

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

From report at bugs.python.org  Fri Jan 18 05:08:30 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 18 Jan 2013 04:08:30 +0000
Subject: [New-bugs-announce] [issue16991] Add OrderedDict written in C
Message-ID: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za>


New submission from Eric Snow:

Here's an initial stab at writing OrderedDict in C.  Though, the implementation is not heavily optimized and isn't super subclass-friendly, my hope is that it's relatively close to the final version.  I'm getting this up now to get some eyes on it.

The spot in the builtins is mostly for convenience, but I expect it will need to be exposed somewhere (perhaps _collections?).

My experience with the C-API is relatively limited and my C-fu is not at a professional level.  However, I'm pretty sure that I have most everything correct.

The ultimate goal for this type is to use it for **kwargs.

Note: this first patch has some reference leaks that I'm tracking down.

----------
assignee: eric.snow
components: Interpreter Core
files: odict.diff
keywords: patch
messages: 180170
nosy: eric.snow, rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: Add OrderedDict written in C
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28762/odict.diff

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

From report at bugs.python.org  Fri Jan 18 05:28:59 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 18 Jan 2013 04:28:59 +0000
Subject: [New-bugs-announce] [issue16992] signal.set_wakeup_fd(400) crashes
	on Windows
Message-ID: <1358483339.76.0.550693501788.issue16992@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

On Windows I get an immediate crash with the following code:

import signal
signal.set_wakeup_fd(400)

I think there's a range check missing somewhere.

(I found this because I was passing a socket's fileno() -- my bug, but shouldn't crash.)

----------
messages: 180171
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: signal.set_wakeup_fd(400) crashes on Windows
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Jan 18 10:25:25 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 18 Jan 2013 09:25:25 +0000
Subject: [New-bugs-announce] [issue16993] shutil.which() should preserve
	path case
Message-ID: <1358501125.46.0.971219977164.issue16993@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Now which lowercase found directory name and extension on Windows.

>>> shutil.which("python")
'c:\\python33\\python.exe'

Proposed patch preserve case.

>>> shutil.which("python")
'C:\\Python33\\python.exe'

Please test this on Windows.

----------
messages: 180181
nosy: hynek, serhiy.storchaka, tarek
priority: normal
severity: normal
status: open
title: shutil.which() should preserve path case
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Jan 18 13:24:33 2013
From: report at bugs.python.org (David Coallier)
Date: Fri, 18 Jan 2013 12:24:33 +0000
Subject: [New-bugs-announce] [issue16994] collections.Counter.least_common
Message-ID: <1358511873.97.0.161301766615.issue16994@psf.upfronthosting.co.za>


New submission from David Coallier:

The `collections.Counter` library contains very useful methods for playing with dicts and sets (mainly the most_common()) function.

Even though it is fairly trivial to retrieve the least common elements in a Counter() by doing Counter(...).most_common(n)[:-n:-1] I believe that for the sake of consistency, the `least_common` method should also be available. 

The attached patch contains the following:
- The method definition in Lib/__init__.py to support least_common;
- The tests to make sure least_common behaves as expected;
- The documentation for 2.7 and the general documentation.

Everywhere `most_common` was mentioned, you will now find `least_common` mentioned as well.

----------
components: Library (Lib)
files: collections.Counter.least_common.patch
keywords: patch
messages: 180189
nosy: davidcoallier
priority: normal
severity: normal
status: open
title: collections.Counter.least_common
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file28764/collections.Counter.least_common.patch

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

From report at bugs.python.org  Fri Jan 18 19:21:19 2013
From: report at bugs.python.org (=?utf-8?q?Matth=C3=A4us_Wander?=)
Date: Fri, 18 Jan 2013 18:21:19 +0000
Subject: [New-bugs-announce] [issue16995] Add Base32 support for RFC4648
	"Extended Hex" alphabet	(patch attached)
Message-ID: <1358533279.94.0.666576182033.issue16995@psf.upfronthosting.co.za>


New submission from Matth?us Wander:

RFC4648 specifies two different alphabets for Base32: 1) the common one already used in RFC3548 and implemented in Python, and 2) an "Extended Hex" alphabet which is used by e.g. DNSSEC NSEC3 but not yet implemented in Python.

The attached patches add the "Extended Hex" alphabet to Python 2.7 and 3 via an optional parameter 'base32hex=False'. Default behavior is not changed.

patch Lib/base64.py < py27_base64.patch
patch Lib/test/test_base64.py < py27_test_base64.patch

----------
components: Library (Lib)
files: base32hex.tar.gz
messages: 180206
nosy: matthaeus.wander
priority: normal
severity: normal
status: open
title: Add Base32 support for RFC4648 "Extended Hex" alphabet (patch attached)
type: enhancement
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file28771/base32hex.tar.gz

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

From report at bugs.python.org  Fri Jan 18 21:44:35 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 18 Jan 2013 20:44:35 +0000
Subject: [New-bugs-announce] [issue16996] Reuse shutil.which() in webbrowser
	module
Message-ID: <1358541875.07.0.897350417662.issue16996@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

We can get rid of private webbrowser functions and reuse shutil.which().

----------
components: Library (Lib)
files: webbrowser_which.patch
keywords: patch
messages: 180220
nosy: georg.brandl, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Reuse shutil.which() in webbrowser module
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28775/webbrowser_which.patch

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

From report at bugs.python.org  Fri Jan 18 22:07:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Jan 2013 21:07:11 +0000
Subject: [New-bugs-announce] [issue16997] subtests
Message-ID: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

subtests are a light alternative to parametered tests as in issue7897. They don't generate the tests for you, they simply allow to partition a given test case in several logical units. Meaning, when a subtest fails, the other subtests in the test will still run (and the failures will print their respective parameters).

Concretely, running the follow example:

class MyTest(unittest.TestCase):

    def test_b(self):
        """some test"""
        for i in range(2, 5):
            for j in range(0, 3):
                with self.subTest(i=i, j=j):
                    self.assertNotEqual(i % 3, j)


will give the following output:

======================================================================
FAIL: test_b (__main__.MyTest) (i=2, j=2)
some test
----------------------------------------------------------------------
Traceback (most recent call last):
  File "subtests.py", line 11, in test_b
    self.assertNotEqual(i % 3, j)
AssertionError: 2 == 2

======================================================================
FAIL: test_b (__main__.MyTest) (i=3, j=0)
some test
----------------------------------------------------------------------
Traceback (most recent call last):
  File "subtests.py", line 11, in test_b
    self.assertNotEqual(i % 3, j)
AssertionError: 0 == 0

======================================================================
FAIL: test_b (__main__.MyTest) (i=4, j=1)
some test
----------------------------------------------------------------------
Traceback (most recent call last):
  File "subtests.py", line 11, in test_b
    self.assertNotEqual(i % 3, j)
AssertionError: 1 == 1

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

----------
components: Library (Lib)
messages: 180221
nosy: Julian, Yaroslav.Halchenko, abingham, bfroehle, borja.ruiz, brian.curtin, chris.jerdonek, eric.araujo, eric.snow, exarkun, ezio.melotti, florian-rathgeber, fperez, hpk, michael.foord, nchauvat, ncoghlan, pitrou, r.david.murray, santa4nt, spiv
priority: normal
severity: normal
status: open
title: subtests
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Jan 19 20:13:57 2013
From: report at bugs.python.org (Jens Lechtenboerger)
Date: Sat, 19 Jan 2013 19:13:57 +0000
Subject: [New-bugs-announce] [issue16998] Lost updates with
	multiprocessing.Value
Message-ID: <1358622837.13.0.603431337609.issue16998@psf.upfronthosting.co.za>


New submission from Jens Lechtenboerger:

Maybe I'm misreading the documentation of multiprocessing.Value and
multiprocessing.sharedctypes.Value.
I thought that access to the value field of Value instances was protected by
locks to avoid lost updates.

Specifically, for multiprocessing.Value(typecode_or_type, *args[, lock]) and
multiprocessing.sharedctypes.Value(typecode_or_type, *args[, lock]) the
documentation states:
> By default the return value is actually a synchronized wrapper for the
> object. [...]
> If lock is True (the default) then a new lock object is created to
> synchronize access to the value. If lock is a Lock or RLock object then that
> will be used to synchronize access to the value. If lock is False then
> access to the returned object will not be automatically protected by a lock,
> so it will not necessarily be ?process-safe?.

(By the way, I'm not sure why both, multiprocessing.Value and
multiprocessing.sharedctypes.Value are documented.  They appear to be the same
thing.)

The following tests (also attached as file) show that lost updates may occur
if several instances of multiprocessing.Process increment the same Value that
is passed as args parameter.

def do_inc(integer):
    """Increment integer.value for multiprocessing.Value integer."""
    integer.value += 1

def do_test(notasks):
    """Create notasks processes, each incrementing the same Value.

    As the Value is initialized to 0, its final value is expected to be
    notasks.
    """
    tasks = list()
    integer = multiprocessing.sharedctypes.Value("i", 0)
    for run in range(notasks):
        proc = multiprocessing.Process(target=do_inc, args=(integer,))
        proc.start()
        tasks.append(proc)
    for proc in tasks:
        proc.join()
    if integer.value != notasks:
        logging.error(
            "Unexpected value: %d (expected: %d)", integer.value, notasks)

if __name__ == "__main__":
    do_test(100)


Sample invocations and results:

Note that on a single CPU machine the error is not reported for every
execution but only for about every third run.
$ python --version
Python 2.6.5
$ uname -a
Linux ubuntu-desktop 2.6.32.11+drm33.2 #2 Fri Jun 18 20:30:49 CEST 2010 i686 GNU/Linux
$ python test_multiprocessing.py
ERROR:root:Unexpected value: 99 (expected: 100)

On a quadcore, the error occurs almost every time.
$ uname -a
Linux PC 2.6.35.13 #4 SMP Tue Dec 20 15:22:02 CET 2011 x86_64 GNU/Linux
$ ~/local/Python-2.7.3/python test_multiprocessing.py
ERROR:root:Unexpected value: 95 (expected: 100)
$ ~/local/Python-3.3.0/python test_multiprocessing.py
ERROR:root:Unexpected value: 86 (expected: 100)

----------
components: Library (Lib)
files: test_multiprocessing.py
messages: 180251
nosy: lechten
priority: normal
severity: normal
status: open
title: Lost updates with multiprocessing.Value
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file28782/test_multiprocessing.py

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

From report at bugs.python.org  Sun Jan 20 01:36:10 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Jan 2013 00:36:10 +0000
Subject: [New-bugs-announce] [issue17000] Remove cruft from unittest docs
Message-ID: <1358642170.4.0.68119991166.issue17000@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

There's a lot of obsolete or simply pointless cruft in the unittest docs, including references to the runTest method, or a detailed description of how to manually collect test suites. Following patch simplifies things a lot and makes the doc easier to read.

----------
assignee: docs at python
components: Documentation
files: unittest-doc-fix.patch
keywords: patch
messages: 180273
nosy: docs at python, ezio.melotti, michael.foord, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Remove cruft from unittest docs
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28791/unittest-doc-fix.patch

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

From report at bugs.python.org  Sun Jan 20 01:36:10 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Jan 2013 00:36:10 +0000
Subject: [New-bugs-announce] [issue16999] Remove cruft from unittest docs
Message-ID: <1358642170.4.0.233806283226.issue16999@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

There's a lot of obsolete or simply pointless cruft in the unittest docs, including references to the runTest method, or a detailed description of how to manually collect test suites. Following patch simplifies things a lot and makes the doc easier to read.

----------
assignee: docs at python
components: Documentation
files: unittest-doc-fix.patch
keywords: patch
messages: 180274
nosy: docs at python, ezio.melotti, michael.foord, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Remove cruft from unittest docs
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28790/unittest-doc-fix.patch

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

From report at bugs.python.org  Sun Jan 20 04:51:39 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sun, 20 Jan 2013 03:51:39 +0000
Subject: [New-bugs-announce] [issue17001] Make uuid.UUID use
	functools.total_ordering
Message-ID: <1358653899.33.0.0649555844846.issue17001@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

This would reduce the complexity of uuid.UUID and also if the way it compares changes, one would't have to change all the compare methods.
Attached is a patch.

----------
components: Library (Lib)
files: issue.patch
keywords: patch
messages: 180275
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: Make uuid.UUID use functools.total_ordering
versions: Python 3.4
Added file: http://bugs.python.org/file28792/issue.patch

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

From report at bugs.python.org  Sun Jan 20 11:54:01 2013
From: report at bugs.python.org (=?utf-8?q?Cillian_de_R=C3=B3iste?=)
Date: Sun, 20 Jan 2013 10:54:01 +0000
Subject: [New-bugs-announce] [issue17002] html.entities ImportError in
	distutils2/pypi/simple.py	on Python2.7
Message-ID: <1358679241.64.0.323379841838.issue17002@psf.upfronthosting.co.za>


New submission from Cillian de R?iste:

I guess it should be wrapped in a try, except:

try:
    from html.entities import name2codepoint
except ImportError:
    from htmlentitydefs import name2codepoint

This works locally

Here's a sample traceback:

Traceback (most recent call last):
  File "python2nix.py", line 119, in <module>
    egg_release = pypi.get_release(egg['name'] + '==' + version)
  File "/nix/var/nix/profiles/plone/lib/python2.7/site-packages/Distutils2-1.0a4-py2.7.egg/distutils2/pypi/simple.py", line 201, in get_release
    releases = self.get_releases(predicate, prefer_final)
  File "/nix/var/nix/profiles/plone/lib/python2.7/site-packages/Distutils2-1.0a4-py2.7.egg/distutils2/pypi/simple.py", line 189, in get_releases
    self._process_index_page(predicate.name)
  File "/nix/var/nix/profiles/plone/lib/python2.7/site-packages/Distutils2-1.0a4-py2.7.egg/distutils2/pypi/simple.py", line 75, in wrapped
    return func(self, *args, **kwargs)
  File "/nix/var/nix/profiles/plone/lib/python2.7/site-packages/Distutils2-1.0a4-py2.7.egg/distutils2/pypi/simple.py", line 397, in _process_index_page
    self._process_url(url, name)
  File "/nix/var/nix/profiles/plone/lib/python2.7/site-packages/Distutils2-1.0a4-py2.7.egg/distutils2/pypi/simple.py", line 320, in _process_url
    for link, is_download in link_matcher(f.read().decode(), base_url):
  File "/nix/var/nix/profiles/plone/lib/python2.7/site-packages/Distutils2-1.0a4-py2.7.egg/distutils2/pypi/simple.py", line 362, in _simple_link_matcher
    url = self._get_full_url(match.group(1), base_url)
  File "/nix/var/nix/profiles/plone/lib/python2.7/site-packages/Distutils2-1.0a4-py2.7.egg/distutils2/pypi/simple.py", line 349, in _get_full_url
    return urlparse.urljoin(base_url, self._htmldecode(url))
  File "/nix/var/nix/profiles/plone/lib/python2.7/site-packages/Distutils2-1.0a4-py2.7.egg/distutils2/pypi/simple.py", line 469, in _htmldecode
    return ENTITY_SUB(self._decode_entity, text)
  File "/nix/var/nix/profiles/plone/lib/python2.7/site-packages/Distutils2-1.0a4-py2.7.egg/distutils2/pypi/simple.py", line 463, in _decode_entity
    from html.entities import name2codepoint
ImportError: No module named html.entities

----------
assignee: eric.araujo
components: Distutils2
messages: 180285
nosy: alexis, eric.araujo, goibhniu, tarek
priority: normal
severity: normal
status: open
title: html.entities ImportError in distutils2/pypi/simple.py on Python2.7
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Sun Jan 20 17:13:14 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Jan 2013 16:13:14 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue17003=5D_Unification_of_rea?=
 =?utf-8?q?d=28=29=C2=A0and_readline=28=29_argument_names?=
Message-ID: <1358698394.54.0.180835263252.issue17003@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

read()?and readline() optional parameter which limit the amount of read data has different names in different classes. All this classes mimic (less or more) io classes. Keyword parameter name is a part of method specification. Therefore it will be good made all read() arguments names the same and all readline() arguments names the same (and be consistent with documentation and C implementation). At least we should choose most consistent name for new implementations. If existent C implementation of some method doesn't support keyword argument (all _io classes) or argument names in C and Python implementations are different then we are free to change this name without breaking existing code.

For example, read()'s parameter named as:

"n" in _pyio, zipfile, and io documentation;
"size" in gzip, bz2, imaplib, tarfile, codecs, mailbox;
"len"?in ssl;
"wtd" or "totalwtd" in binhex;
"amt" in http/client;
"chars" in codecs;
"buffersize" in os.

readline()'s parameter named as:

"limit" in _pyio, zipfile, and io documentation;
"size" in gzip, bz2, codecs, mailbox, lzma.

----------
assignee: docs at python
components: Documentation, IO, Library (Lib)
messages: 180298
nosy: benjamin.peterson, christian.heimes, docs at python, hynek, pitrou, serhiy.storchaka, stutzbach
priority: normal
severity: normal
status: open
title: Unification of read()?and readline() argument names
type: enhancement

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

From report at bugs.python.org  Sun Jan 20 19:41:42 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 20 Jan 2013 18:41:42 +0000
Subject: [New-bugs-announce] [issue17004] Expand zipimport to include other
	compression methods
Message-ID: <1358707302.86.0.811743649739.issue17004@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Only a little of the existing logic is tied to the zipfile format.  Consider adding support for xz, tar, tar.gz, tar.bz2, etc.

In particular, xz has better compression, resulting in both space savings and faster load times.

----------
messages: 180307
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Expand zipimport to include other compression methods
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Jan 20 22:39:12 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 20 Jan 2013 21:39:12 +0000
Subject: [New-bugs-announce] [issue17005] Add a topological sort algorithm
Message-ID: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

I suggest adding a topological sort algorithm to the standard library.

In addition to being a fundamental algorithm, it is immediately useful in demonstrating how the MRO computation works and for pure Python implementations of MRO logic.   IIRC, the pgen code was also expressed in pure Python for the same reason.

I've attached a first-draft of the algorithm and an alternative that only implements a topological merge.  This is just an early draft and there are a number of open points:

* which module to put it in
* a better implementation may be possible (perhaps using fewer dictionaries and sets).

----------
files: mro_merge.py
messages: 180319
nosy: rhettinger
priority: low
severity: normal
status: open
title: Add a topological sort algorithm
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28800/mro_merge.py

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

From report at bugs.python.org  Mon Jan 21 09:48:02 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 21 Jan 2013 08:48:02 +0000
Subject: [New-bugs-announce] [issue17006] Warn users about hashing secrets?
Message-ID: <1358758082.76.0.415880124971.issue17006@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Lot's of people still think that something like sha512(secret + message), sha1(password + salt) or even sha1(password) is secure. Except it isn't. Most crypto hash functions like md5, sha1, sha2 family (sha256, sha384, sha512) use a Merkle?Damg?rd construction [1]. The construction is vulnerable to several attack vectors like length extension attacks. Passwords needs special care, too.

I propose we add a warning to the documentation of hashlib. It's not the right place to teach cryptographics but it's a good place to raise attention. The warning should explain that you shouldn't solely hash secrets or messages containing a secret. For messages a MAC algorithm like HMAC should be used. For passwords a key stretching and key derivation function like PBKDF2, bcrypt or scrypt is much more secure.

[1] http://en.wikipedia.org/wiki/Merkle%E2%80%93Damg%C3%A5rd_construction

----------
assignee: docs at python
components: Documentation
messages: 180330
nosy: christian.heimes, docs at python
priority: normal
severity: normal
status: open
title: Warn users about hashing secrets?
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Jan 21 18:31:40 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 21 Jan 2013 17:31:40 +0000
Subject: [New-bugs-announce] [issue17007] logging documentation
	clarifications
Message-ID: <1358789500.77.0.271536300349.issue17007@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

Here are some suggestions of things to clarify in the logging documentation after consulting it as an end-user:

1. Clarify in Logger.filter(), Handler.filter(), and probably also in the Filter section that the case of more than filter behaves as follows: filters are applied until a filter says the record should not be processed.  In particular, a record gets processed only if all filters say it should be processed rather than at least one.

This is especially worth clarifying because with the above behavior combined with the Filter class's default behavior, it never makes sense to add more than one filter (because you can replace a group of filters with their lowest common ancestor).  It's only needed with custom filters.

2. Clarify that a handler can log the same record multiple times if it is attached to an ancestor logger.  This clarification perhaps best goes in the Logger.propagate section.  Currently, it's not clear whether loggers/handlers are "smart" in the sense that they keep track of whether a given message has already been passed to a given handler (independent of what loggers it is attached to): "Logger.propagate: If this evaluates to true, logging messages are passed by this logger and by its child loggers to the handlers of higher level (ancestor) loggers."

Incidentally, is there any case where you would want the same handler to process the same record more than once?

3. Clarify in the LogRecord section that the "name" attribute refers to the name of the logger used in the end-user's code rather than the name of the logger handling the message.  In particular, a record logged by a logger and an ancestor logger will have the same "name" field for both.

4. Clarify the last part of this sentence: "Note that filters attached to handlers are consulted whenever an event is emitted by the handler, whereas filters attached to loggers are consulted whenever an event is logged to the handler (using debug(), info(), etc.)"

It should say something like, "whereas filters attached to loggers are consulted prior to sending an event to its handlers."  In particular, there can be more than one handler, and it happens before rather than after being logged to the handlers ("whenever" is somewhat ambiguous).

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 180344
nosy: chris.jerdonek, docs at python, vinay.sajip
priority: normal
severity: normal
status: open
title: logging documentation clarifications
type: enhancement

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

From report at bugs.python.org  Mon Jan 21 18:49:12 2013
From: report at bugs.python.org (stuart)
Date: Mon, 21 Jan 2013 17:49:12 +0000
Subject: [New-bugs-announce] [issue17008] Descriptor __get__() invoke is
	bypassed in the class	context
Message-ID: <1358790552.82.0.446038520087.issue17008@psf.upfronthosting.co.za>


New submission from stuart:

I emulated a real classmethod using python:

class cm(object):
    def __init__(self, o):
        self.o = o
    def __get__(self, obj, type=None):
        return self.o.__get__(obj, type)

then I check whether it is workable in the interactive mode and it is working:

Python 2.7.3 (default, Sep 26 2012, 21:53:58) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def foo(cls):
...     print cls
... 
>>> cm = cm(foo)
>>> cm.__get__(int, type)
<bound method type.foo of <type 'int'>>

then I tried it in the real class but it failed:

>>> class C(object):
...     @cm
...     def foo(cls):
...         print cls
... 
>>> C.foo
<unbound method C.foo>

----------
components: None
messages: 180346
nosy: Stuart
priority: normal
severity: normal
status: open
title: Descriptor __get__() invoke is bypassed in the class context
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jan 21 21:20:22 2013
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 21 Jan 2013 20:20:22 +0000
Subject: [New-bugs-announce] [issue17009] "Thread Programming With Python"
	should be removed
Message-ID: <1358799622.32.0.0901338309925.issue17009@psf.upfronthosting.co.za>


New submission from Ned Batchelder:

Sorry if this is the wrong bug tracker for this issue.

Someone just asked in #python what they should do about the fact that Python has no threads on the Mac.  When asked why they thought that, they pointed to this:   http://www.python.org/doc/essays/threads.html

This essay is undated and unsigned, and is out of date.  It should be removed from the site, or significantly edited, or at least marked at the top as "For Historical Interest Only."

----------
components: None
messages: 180355
nosy: nedbat
priority: normal
severity: normal
status: open
title: "Thread Programming With Python" should be removed

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

From report at bugs.python.org  Tue Jan 22 00:57:37 2013
From: report at bugs.python.org (Bryan G. Olson)
Date: Mon, 21 Jan 2013 23:57:37 +0000
Subject: [New-bugs-announce] [issue17010] Windows launcher ignores active
	virtual environment
Message-ID: <1358812657.25.0.839528896034.issue17010@psf.upfronthosting.co.za>


New submission from Bryan G. Olson:

Python 3.3 includes PEP 397, a Python launcher for Windows, and PEP 405, virtual environment support in core. Unfortunately the Windows launcher does not respect virtual environments. Even with with a virtual environment activated and the current directory at the virtual environment's root, the Windows launcher will start python with the system environment, not the active virtual environment.


To demo:

Install python 3.3 for windows.

Create a virtual environment:

  C:\>c:\Python33\Tools\Scripts\pyvenv.py c:\virtpy

Activate the virtual environment:

  C:\>virtpy\Scripts\activate.bat
  (virtpy) C:\>

Optionally cd to the virtual environment:

  (virtpy) C:\>cd virtpy
  (virtpy) C:\virtpy>

Start Python 3 with the new windows launcher:

  (virtpy) C:\virtpy>py -3
  Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit (Intel)] on win32
  Type "help", "copyright", "credits" or "license" for more information.
  >>>

Check sys.path

  >>> import sys
  >>>
  >>> sys.path
  ['', 'C:\\Windows\\system32\\python33.zip', 'C:\\bin\\Python33\\DLLs', 'C:\\bin\\Python33\\lib', 'C:\\bin\\Python33', 'C:\\bin\\Python33\\lib\\site-packages']
  >>>


The worst effect I've found is that installation of a package with windows launcher, "py -3 setup.py install", will ignore the active virtual environment and will change the system Python environment. That's bad because users frequently employ virtual environments to isolate changes that could damage a system configuration.

----------
components: Installation, Windows
messages: 180362
nosy: bryangeneolson
priority: normal
severity: normal
status: open
title: Windows launcher ignores active virtual environment
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Jan 22 08:16:24 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 22 Jan 2013 07:16:24 +0000
Subject: [New-bugs-announce] [issue17011] ElementPath ignores different
	namespace mappings for the	same path expression
Message-ID: <1358838984.91.0.0315362873275.issue17011@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

There's a bug originally report for lxml that also applies to ElementTree:

https://github.com/lxml/lxml/issues/95

Passing different namespace mappings into the Element.find*() methods will always reuse the first one due to incorrect caching based only on the literal path, not all parameters. My fix is here:

https://github.com/lxml/lxml/commit/8bafbdc13ffb4fb8436eda01594780aac4735528

The lookup performance regression when a namespace mapping is passed (sorting etc.) is acceptable as most use cases won't pass any namespaces anyway, so this is a problem that rarely shows in practice.

----------
components: XML
messages: 180366
nosy: scoder
priority: normal
severity: normal
status: open
title: ElementPath ignores different namespace mappings for the same path expression
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Jan 22 13:14:00 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Jan 2013 12:14:00 +0000
Subject: [New-bugs-announce] [issue17012] Differences between /usr/bin/which
	and shutil.which()
Message-ID: <1358856840.71.0.975366262743.issue17012@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

$ PATH= /usr/bin/which python
$ PATH=: /usr/bin/which python
./python
$ PATH=/usr: /usr/bin/which python
./python

>>> shutil.which('python', path='')
'/usr/bin/python'
>>> shutil.which('python', path=':')
'python'
>>> shutil.which('python', path='/usr:')
'python'

First, I propose interpret path='' as an empty path, not as a default path (we have None for this). However the interpreting of an empty directory in non-empty PATH can be platform-depending.

----------
components: Library (Lib)
messages: 180376
nosy: brian.curtin, hynek, pitrou, serhiy.storchaka, tarek
priority: normal
severity: normal
status: open
title: Differences between /usr/bin/which and shutil.which()
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Jan 22 13:15:47 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Jan 2013 12:15:47 +0000
Subject: [New-bugs-announce] [issue17013] Allow waiting on a mock
Message-ID: <1358856947.82.0.71016271567.issue17013@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

In non-trivial tests, you may want to wait for a method to be called in another thread. This is a case where unittest.mock currently doesn't help. It would be nice to be able to write:

  myobj.some_method = Mock(side_effect=myobj.some_method)
  # launch some thread
  myobj.some_method.wait_until_called()

And perhaps

  myobj.some_method.wait_until_called_with(...)

(with an optional timeout?)

If we don't want every Mock object to embed a threading.Event, perhaps there could be a ThreadedMock subclass?
Or perhaps even:

  WaitableMock(..., event_class=threading.Event)

so that people can pass multiprocessing.Event if they want to wait on the mock from another process?

----------
components: Library (Lib)
messages: 180377
nosy: michael.foord, pitrou
priority: normal
severity: normal
status: open
title: Allow waiting on a mock
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Jan 22 13:28:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Jan 2013 12:28:39 +0000
Subject: [New-bugs-announce] [issue17014] _getfinalpathname() no more used
	in 3.4
Message-ID: <1358857719.02.0.193361070638.issue17014@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

It was a helper function for samepath on windows and not used more since samepath implementation was changed.

Here is a patch which remove it.

----------
components: Extension Modules, Library (Lib), Windows
files: drop_getfinalpathname.patch
keywords: patch
messages: 180379
nosy: brian.curtin, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: _getfinalpathname() no more used in 3.4
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28802/drop_getfinalpathname.patch

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

From report at bugs.python.org  Tue Jan 22 13:44:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Jan 2013 12:44:11 +0000
Subject: [New-bugs-announce] [issue17015] mock could be smarter and inspect
	the spec's signature
Message-ID: <1358858651.94.0.425572209999.issue17015@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

This is a bit annoying:

>>> def f(a, b): pass
... 
>>> mock = Mock(spec=f)
>>> mock(1, 2)
<Mock name='mock()' id='140654219634288'>
>>> mock.assert_called_with(1, 2)
>>> mock.assert_called_with(a=1, b=2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/cpython/default/Lib/unittest/mock.py", line 726, in assert_called_with
    raise AssertionError(msg)
AssertionError: Expected call: mock(b=2, a=1)
Actual call: mock(1, 2)

This means your test assertions will depend unduly on some code style details (whether some function is called using positional or keyword arguments).
Note: if this is fixed, it should be made to work with method calls too.

----------
components: Library (Lib)
messages: 180381
nosy: michael.foord, pitrou
priority: normal
severity: normal
status: open
title: mock could be smarter and inspect the spec's signature
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Jan 22 16:54:28 2013
From: report at bugs.python.org (Nickolai Zeldovich)
Date: Tue, 22 Jan 2013 15:54:28 +0000
Subject: [New-bugs-announce] [issue17016] _sre: avoid relying on pointer
	overflow
Message-ID: <1358870068.45.0.162917053865.issue17016@psf.upfronthosting.co.za>


New submission from Nickolai Zeldovich:

Modules/_sre.c relies on pointer overflow in 5 places to check that the supplied offset does not cause wraparound when added to a base pointer; e.g.:

                    SRE_CODE prefix_len;
                    GET_ARG; prefix_len = arg;
                    GET_ARG;
                    /* Here comes the prefix string */
                    if (code+prefix_len < code || code+prefix_len > newcode)
                        FAIL;

however, pointer wraparound is undefined behavior in C, and gcc will optimize away (code+prefix_len < code) to (true), since prefix_len is an unsigned value.  This will happen with -O2 and even with -fwrapv:

nickolai at sahara:/tmp$ cat x.c
void bar();

void
foo(int *p, unsigned int x)
{
  if (p + x < p)
    bar();
}
nickolai at sahara:/tmp$ gcc x.c -S -o - -O2 -fwrapv
...
foo:
.LFB0:
	.cfi_startproc
	rep
	ret
	.cfi_endproc
...
nickolai at sahara:/tmp$ 

On a 32-bit platform with the development version of cpython, prefix_len seems to end up being an 'unsigned int', so I suspect that supplying a large prefix_len value (perhaps 0xffffffff) could lead to the subsequent loop writing garbage all over memory, or worse (but I have not tried to construct a concrete input that triggers this bug, so maybe there are some checks that make it difficult to trigger the bug).

In any case, this might be worth fixing -- the attached patch provides one proposed fix.  Another option might be to add -fno-strict-overflow to the gcc flags, which may be a reasonable additional measure to take, to avoid such problems biting Python in the future, but I would suggest doing this in addition to fixing the code (since not all compilers support such a flag to disable certain optimizations).

----------
components: None
files: pp.patch
keywords: patch
messages: 180403
nosy: Nickolai.Zeldovich
priority: normal
severity: normal
status: open
title: _sre: avoid relying on pointer overflow
type: security
versions: Python 3.5
Added file: http://bugs.python.org/file28804/pp.patch

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

From report at bugs.python.org  Wed Jan 23 00:51:42 2013
From: report at bugs.python.org (Andreas Dewes)
Date: Tue, 22 Jan 2013 23:51:42 +0000
Subject: [New-bugs-announce] [issue17017] email.utils.getaddresses fails for
	certain addresses
Message-ID: <1358898702.5.0.0944995793434.issue17017@psf.upfronthosting.co.za>


New submission from Andreas Dewes:

email.utils.getaddresses doesn't seem to work if the quoted part of address contains "\r" or "\n" characters. An example:

---
from email.utils import getaddresses
address = '"Data Mining, Statistics, Big Data, and Data Visualization Group\r\n Members" <group-digests at linkedin.com>'
getaddresses([address])
---

In Python 2.7.3, this returns:

[('', u'Data Mining, Statistics, Big Data, and Data Visualization Group')]

Not sure if this is a real bug or if the address is malformed, in any case I encountered this issue when parsing e-mails fetched from GMail.

----------
components: email
messages: 180440
nosy: barry, japh44, r.david.murray
priority: normal
severity: normal
status: open
title: email.utils.getaddresses fails for certain addresses
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Jan 23 16:15:21 2013
From: report at bugs.python.org (Marcin Szewczyk)
Date: Wed, 23 Jan 2013 15:15:21 +0000
Subject: [New-bugs-announce] [issue17018] Inconsistent behaviour of methods
	waiting for child	process
Message-ID: <1358954121.08.0.546295178726.issue17018@psf.upfronthosting.co.za>


New submission from Marcin Szewczyk:

I've done some experiments with:
1) multiprocessing.Process.join()
2) os.waitpid()
3) subprocess.Popen.wait()

These three methods behave completely different when interrupted with a signal which I find disturbing.

Reactions are:
1) exit with no exception or special return code
2) OSError exception
3) quiet retry (no exit)

The 1) case is very impractical.

Is there any movement towards standardization of those 3?

Now I know I can loop around Process.join() and check exitcode or is_alive, but it requires more code.

It has been pointed out that it changed between 2.6 and 2.7.

Associated bug: http://bugs.python.org/issue1731717

Relevant sources:
http://svn.python.org/view/python/branches/release26-maint/Lib/multiprocessing/forking.py?revision=84031&view=markup
http://hg.python.org/releasing/2.7.3/file/7bb96963d067/Lib/multiprocessing/forking.py
http://hg.python.org/cpython/rev/41aef062d529/

I think the behaviour of those three should be at least documented, especially if every one of them behaves differently and it changes between versions.

My environment is:
$ python --version
Python 2.7.3rc2

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 7.0 (wheezy)
Release:        7.0
Codename:       wheezy

$ uname -a
Linux magazyn-ziarno 3.2.0-4-686-pae #1 SMP Debian 3.2.35-2 i686 GNU/Linux

Filing a bug as advised on python-dev mailing list (<kdmikh$h3h$1 at ger.gmane.org>).

----------
messages: 180465
nosy: wodny
priority: normal
severity: normal
status: open
title: Inconsistent behaviour of methods waiting for child process
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Jan 23 17:44:32 2013
From: report at bugs.python.org (mtb)
Date: Wed, 23 Jan 2013 16:44:32 +0000
Subject: [New-bugs-announce] [issue17019] Invitation to connect on LinkedIn
Message-ID: <321996729.23497561.1358959469883.JavaMail.app@ela4-app2315.prod>


New submission from mtb:

LinkedIn
------------

I'd like to add you to my professional network on LinkedIn.

- Matthew

Matthew Burns
unemployed at n/a
Greater Los Angeles Area

Confirm that you know Matthew Burns:
https://www.linkedin.com/e/-3qcne3-hcapdpuw-2h/isd/10664060930/HGLNsmfN/?hs=false&tok=3M68u6D1DIClA1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-3qcne3-hcapdpuw-2h/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I3541514734_1/?hs=false&tok=1flNx1ai_IClA1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

----------
messages: 180469
nosy: zubah
priority: normal
severity: normal
status: open
title: Invitation to connect on LinkedIn

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

From report at bugs.python.org  Wed Jan 23 18:32:12 2013
From: report at bugs.python.org (Floris van Manen)
Date: Wed, 23 Jan 2013 17:32:12 +0000
Subject: [New-bugs-announce] [issue17020] random.random() generating values
	>= 1.0
Message-ID: <1358962332.33.0.660025767409.issue17020@psf.upfronthosting.co.za>


New submission from Floris van Manen:

I recently noticed that the standard random() function generates values >= 1.0

As processes are called from an event scheduler, each process has its own Random() instance.

    self.random = random.Random(seed)
    self.randomState = self.random.getstate()



keeping track of multiple objects:

    self.random.setstate(self.randomState)
    self.random.jumpahead(1)
    self.randomState = self.random.getstate()


Also gammavariate() generates errors as it too makes use of the _random() call

A workaround is to check each response of random() for values >= 1.0

----------
assignee: ronaldoussoren
components: Macintosh
messages: 180480
nosy: klankschap, ronaldoussoren
priority: normal
severity: normal
status: open
title: random.random() generating values >= 1.0
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Thu Jan 24 03:46:59 2013
From: report at bugs.python.org (Hank Christian)
Date: Thu, 24 Jan 2013 02:46:59 +0000
Subject: [New-bugs-announce] [issue17021] Invitation to connect on LinkedIn
Message-ID: <261743059.559914.1358995617320.JavaMail.app@ela4-app2309.prod>


New submission from Hank Christian:

LinkedIn
------------

Python,

I'd like to add you to my professional network on LinkedIn.

- Henry

Henry Christian
ADJUNCT PROFESSOR at Central Texas College
Greater Los Angeles Area

Confirm that you know Henry Christian:
https://www.linkedin.com/e/-3qcne3-hcbawhei-t/isd/10674146693/f8KKDSuG/?hs=false&tok=1CeofNO2B6D5A1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-3qcne3-hcbawhei-t/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I3544543039_1/?hs=false&tok=2VYf22chR6D5A1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

----------
messages: 180502
nosy: hankchristian
priority: normal
severity: normal
status: open
title: Invitation to connect on LinkedIn

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

From report at bugs.python.org  Thu Jan 24 10:30:55 2013
From: report at bugs.python.org (Gabriel Nistor)
Date: Thu, 24 Jan 2013 09:30:55 +0000
Subject: [New-bugs-announce] [issue17022] Inline assignation uses the newly
	created object
Message-ID: <1359019855.42.0.818555984965.issue17022@psf.upfronthosting.co.za>


New submission from Gabriel Nistor:

I am using Lubuntu x64 version and python 3.2.3
I have a tree search method:

node = self
while xpaths:
    xpath = xpaths.popleft()
    for path, child in node.childrens.items():
        if path == xpath:
            node = child
            break
    else:
        node = node.childrens[xpath] = Node(xpath)
return node

This fails because the node is created and then the node.childrens[xpath] assignation is done on the new created node rather then the old node, I needed to do something like:
        child = node.childrens[xpath] = Node(xpath)
        node = child
to have the proper behavior.

----------
components: Interpreter Core
messages: 180518
nosy: chupym
priority: normal
severity: normal
status: open
title: Inline assignation uses the newly created object
versions: Python 3.2

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

From report at bugs.python.org  Thu Jan 24 14:09:21 2013
From: report at bugs.python.org (=?utf-8?q?Pekka_Kl=C3=A4rck?=)
Date: Thu, 24 Jan 2013 13:09:21 +0000
Subject: [New-bugs-announce] [issue17023] Subprocess does not find
	executable on Windows if it is	PATH with quotes
Message-ID: <1359032961.6.0.0734607018969.issue17023@psf.upfronthosting.co.za>


New submission from Pekka Kl?rck:

If you add a directory into PATH on Windows so that the directory is in quotes, subprocess does not find executables in it. They are found by the operating system, though, at least when run on the command prompt.

To reproduce:

C:\>python --version
Python 2.7.3
C:\>type test\script.bat
@echo off
echo hello
C:\>set ORIG=%PATH%
C:\>set PATH=%ORIG%;test
C:\>script.bat
hello
C:\>python -c "from subprocess import call; call('script.bat')"
hello
C:\>set PATH=%ORIG%;"test"
C:\>script.bat
hello
C:\>python -c "from subprocess import call; call('script.bat')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Python27\lib\subprocess.py", line 493, in call
    return Popen(*popenargs, **kwargs).wait()
  File "C:\Python27\lib\subprocess.py", line 679, in __init__
    errread, errwrite)
  File "C:\Python27\lib\subprocess.py", line 896, in _execute_child
    startupinfo)
WindowsError: [Error 2] The system cannot find the file specified


I don't think you ever need those quotes, even if the directory would have spaces, but it is very confusing that the behavior is different on the command prompt and with subprocess. Additionally, Linux does not suffer from this problem:

$ python --version
Python 2.7.3
$ cat test/script.sh 
#!/bin/sh
echo "hello"
$ PATH=$PATH:test script.sh
hello
$ PATH=$PATH:test python -c "from subprocess import call; call('script.sh')"
hello
$ PATH=$PATH:"test" script.sh
hello
$ PATH=$PATH:"test" python -c "from subprocess import call; call('script.sh')"
hello

----------
messages: 180520
nosy: pekka.klarck
priority: normal
severity: normal
status: open
title: Subprocess does not find executable on Windows if it is PATH with quotes

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

From report at bugs.python.org  Thu Jan 24 16:10:08 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 24 Jan 2013 15:10:08 +0000
Subject: [New-bugs-announce] [issue17024] cElementTree calls end() on parser
	taget even if start()	fails
Message-ID: <1359040208.76.0.707549580683.issue17024@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

The following compatibility unit test fails for me in lxml since Py3.3.

    etree = xml.etree.ElementTree

    def test_parser_target_error_in_start(self):
        assertEqual = self.assertEqual

        events = []
        class Target(object):
            def start(self, tag, attrib):
                events.append("start")
                assertEqual("TAG", tag)
                raise ValueError("TEST")
            def end(self, tag):
                events.append("end")
                assertEqual("TAG", tag)
            def close(self):
                return "DONE"

        parser = self.etree.XMLParser(target=Target())

        try:
            parser.feed("<TAG/>")
        except ValueError:
            self.assertTrue('TEST' in str(sys.exc_info()[1]))
        else:
            self.assertTrue(False)

        # ERROR HERE - gives ["start", "end"] in Py3.3
        self.assertEqual(["start"], events)

It seems like cET doesn't handle exceptions early enough and still calls the end() method. Neither Python ElementTree nor lxml do this.

Some more tests are here:

https://github.com/lxml/lxml/blob/master/src/lxml/tests/test_elementtree.py#L3446

(all tests in that file are known to work with ET)

----------
components: Library (Lib), XML
messages: 180526
nosy: eli.bendersky, scoder
priority: normal
severity: normal
status: open
title: cElementTree calls end() on parser taget even if start() fails
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Jan 24 16:49:06 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 24 Jan 2013 15:49:06 +0000
Subject: [New-bugs-announce] [issue17025] reduce multiprocessing.Queue
	contention
Message-ID: <1359042546.71.0.578815247507.issue17025@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

Here's an implementation of the idea posted on python-ideas (http://mail.python.org/pipermail/python-ideas/2013-January/018846.html).

The principle is really simple, we just serialize/unserialize the objects before/after holding the locks. This leads to reduced contention.

Here are the results of a benchmark using from 1 reader/1 writer up to 4 readers/4 writers, on a 8-cores box:

without patch:
$ ./python /tmp/multi_queue.py
took 0.8340198993682861 seconds with 1 workers
took 1.956531047821045 seconds with 2 workers
took 3.175778865814209 seconds with 3 workers
took 4.277260780334473 seconds with 4 workers

with patch:
$ ./python /tmp/multi_queue.py
took 0.7945001125335693 seconds with 1 workers
took 0.7428359985351562 seconds with 2 workers
took 0.7897098064422607 seconds with 3 workers
took 1.1860828399658203 seconds with 4 workers

I tried Richard's suggestion of serializing the data inside put(), but this reduces performance quite notably:
$ ./python /tmp/multi_queue.py
took 1.412883996963501 seconds with 1 workers
took 1.3212130069732666 seconds with 2 workers
took 1.2271699905395508 seconds with 3 workers
took 1.4817359447479248 seconds with 4 workers

Although I didn't analyse it further, I guess one reason could be that if the serializing is done in put(), the feeder thread has nothing to do but keep waiting for data to be available from the buffer, send it, and block until there's more to do: basically, it almost doesn't use its time-slice, and spends its time blocking and doing context switches.

----------
files: queues_contention.diff
keywords: patch
messages: 180532
nosy: neologix, pitrou, sbt
priority: normal
severity: normal
status: open
title: reduce multiprocessing.Queue contention
type: performance
Added file: http://bugs.python.org/file28812/queues_contention.diff

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

From report at bugs.python.org  Thu Jan 24 18:18:33 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 24 Jan 2013 17:18:33 +0000
Subject: [New-bugs-announce] [issue17026] pdb frames accessible after the
	termination occurs on	uncaught exception
Message-ID: <1359047913.36.0.999891280978.issue17026@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

The following test illustrates the problem.
script.py contains the line "1 / 0".
The 'bt' command is also wrong.

$ python3 -m pdb script.py
> /tmp/script.py(1)<module>()
-> 1 / 0
(Pdb) continue
Traceback (most recent call last):
  File "/usr/local/lib/python3.3/pdb.py", line 1651, in main
    pdb._runscript(mainpyfile)
  File "/usr/local/lib/python3.3/pdb.py", line 1532, in _runscript
    self.run(statement)
  File "/usr/local/lib/python3.3/bdb.py", line 405, in run
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "/tmp/script.py", line 1, in <module>
    1 / 0
ZeroDivisionError: division by zero
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> /tmp/script.py(1)<module>()
-> 1 / 0
(Pdb) up
> <string>(1)<module>()
(Pdb) up
> /usr/local/lib/python3.3/bdb.py(405)run()
-> exec(cmd, globals, locals)
(Pdb) up
> /usr/local/lib/python3.3/pdb.py(1532)_runscript()
-> self.run(statement)
(Pdb) up
> /usr/local/lib/python3.3/pdb.py(1651)main()
-> pdb._runscript(mainpyfile)
(Pdb) up
*** Oldest frame
(Pdb)

----------
components: Library (Lib)
messages: 180535
nosy: xdegaye
priority: normal
severity: normal
status: open
title: pdb frames accessible after the termination occurs on uncaught exception
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Jan 25 06:36:07 2013
From: report at bugs.python.org (Sarbjit singh)
Date: Fri, 25 Jan 2013 05:36:07 +0000
Subject: [New-bugs-announce] [issue17027] support for drag and drop of files
	to tkinter application
Message-ID: <1359092167.25.0.0405358457492.issue17027@psf.upfronthosting.co.za>


New submission from Sarbjit singh:

It would be nice to have a support to drop the files (files from the file explorer i.e. from outside the application) to the tkinter application which could then set the file path/ directory path depending upon the configuration set in the module. This feature would be very helpful in applications where user need to select some file/directory.

----------
components: Tkinter
messages: 180554
nosy: Sarbjit.singh
priority: normal
severity: normal
status: open
title: support for drag and drop of files to tkinter application
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Jan 25 11:56:24 2013
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 25 Jan 2013 10:56:24 +0000
Subject: [New-bugs-announce] [issue17028] launcher
Message-ID: <1359111384.85.0.88838799187.issue17028@psf.upfronthosting.co.za>


New submission from Thomas Heller:

The python launcher does not parse the shebang if arguments for the Python interpreter are given on the command line.  For example:

py.exe test.py # uses shebang line
py.exe -u test.py # does NOT use shebang line

The attached patch fixes this.

----------
components: Windows
files: launcher.patch
keywords: patch
messages: 180565
nosy: theller
priority: normal
severity: normal
stage: patch review
status: open
title: launcher
type: enhancement
Added file: http://bugs.python.org/file28820/launcher.patch

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

From report at bugs.python.org  Fri Jan 25 12:59:29 2013
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 25 Jan 2013 11:59:29 +0000
Subject: [New-bugs-announce] [issue17029] h2py.py: search the multiarch
	include dir if it does	exist
Message-ID: <1359115169.66.0.228835023529.issue17029@psf.upfronthosting.co.za>


New submission from Matthias Klose:

On MultiArch systems, header files are split into /usr/include and /usr/include/<multiarch-tuple>. Make sure that h2py finds all headers. Currently the build of IN.py is broken, when running on such a system.

----------
components: Build
files: ma-h2py.diff
keywords: patch
messages: 180571
nosy: doko
priority: normal
severity: normal
status: open
title: h2py.py: search the multiarch include dir if it does exist
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28821/ma-h2py.diff

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

From report at bugs.python.org  Fri Jan 25 13:57:46 2013
From: report at bugs.python.org (Stephan)
Date: Fri, 25 Jan 2013 12:57:46 +0000
Subject: [New-bugs-announce] [issue17030] strange import visibility
Message-ID: <1359118666.97.0.0299772103321.issue17030@psf.upfronthosting.co.za>


New submission from Stephan:

$ cat a.py
import dbus
import b
dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
print "Hello, World."
$ cat b.py
import dbus.mainloop.glib
$ python a.py
Hello, World.
$

If I remove the ?import b? line, the output is:

$ python a.py
Traceback (most recent call last):
  File "a.py", line 3, in <module>
    dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
AttributeError: 'module' object has no attribute 'mainloop'
$

In my opinion this is inconsistent. Either both versions should fail with that error, because ?dbus.mainloop.glib? is imported in ?b?, not ?a?; or both should succeed, because ?a? imports dbus.

This is Python 2.7.3 and python-dbus 1.0.0 on Ubuntu 12.4.2

----------
components: Interpreter Core
messages: 180574
nosy: geryon
priority: normal
severity: normal
status: open
title: strange import visibility
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jan 25 15:21:30 2013
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 25 Jan 2013 14:21:30 +0000
Subject: [New-bugs-announce] [issue17031] fix running regen in cross builds
Message-ID: <1359123690.9.0.217015982102.issue17031@psf.upfronthosting.co.za>


New submission from Matthias Klose:

currently regen calls the python interpreter for the host, not the build machine. You can't directly use BUILD_FOR_PYTHON, because this one uses ./python explicitly, so use BUILDPYTHON instead.

I'd like to see this for 3.3 and the trunk.

----------
assignee: doko
components: Cross-Build
files: regen.diff
keywords: needs review, patch
messages: 180588
nosy: doko
priority: normal
severity: normal
status: open
title: fix running regen in cross builds
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28822/regen.diff

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

From report at bugs.python.org  Fri Jan 25 15:42:54 2013
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 25 Jan 2013 14:42:54 +0000
Subject: [New-bugs-announce] [issue17032] Misleading error message: global
	name 'X' is not defined
Message-ID: <1359124974.58.0.158587338796.issue17032@psf.upfronthosting.co.za>


New submission from Ram Rachum:

Every single time I see the error message `global name 'X' is not defined` I say to myself, "ah yeah, I mistyped a variable name."

But then it occurred to me, why should I have to do this mental translation from "global name not defined" to "I mistyped a variable name"?

Now, I'm not asking for the error message to say "You mistyped a variable name", because that goes too much into second-guessing the user. But can we at least drop the reference to a global name? I understand that Python first searches the local namespace, and only then in the global namespace, and if the name isn't found there then an error is raised. But that doesn't mean that the error message should just assume that the variable is supposed to be global. It's misleading to say that a variable is global when it's in fact local.

I think that the error message should just say `Variable 'X' not defined`. Maybe add a suggestion `(Typo?)` at the end.


Example:

    >>> def f():
    ...     meow = 0
    ...     return meoow
    ...
    >>> f()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "<stdin>", line 3, in f
    NameError: global name 'meoow' is not defined

I'd make the error message:

    NameError: Variable 'meoow' is not defined

----------
components: Interpreter Core
messages: 180591
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Misleading error message: global name 'X' is not defined
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jan 25 16:53:33 2013
From: report at bugs.python.org (Taavi Burns)
Date: Fri, 25 Jan 2013 15:53:33 +0000
Subject: [New-bugs-announce] [issue17033] RPM spec file has old
	config_binsuffix value
Message-ID: <1359129213.62.0.851750342405.issue17033@psf.upfronthosting.co.za>


New submission from Taavi Burns:

Looking at the Misc/RPM/python-X.X.spec files, they seem to be slightly out of date. Near the top of the file is a config_binsuffix configuration setting that is "2.6" for both the 2.7 and 3.3 branches!

I suspect that it should be updated with the version and libvers variables a bit later in the file.

----------
components: Build
files: python-2.7.spec.diff
keywords: patch
messages: 180596
nosy: taavi-burns
priority: normal
severity: normal
status: open
title: RPM spec file has old config_binsuffix value
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file28823/python-2.7.spec.diff

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

From report at bugs.python.org  Fri Jan 25 21:14:51 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Jan 2013 20:14:51 +0000
Subject: [New-bugs-announce] [issue17034] Initialization of globals in
	stringobject.c
Message-ID: <1359144891.77.0.961082315571.issue17034@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The patch for stringobject.c is similar to patch for unicodeobject.c in issue10156, but more simpler.

----------
components: Interpreter Core
files: string_globals.patch
keywords: patch
messages: 180621
nosy: serhiy.storchaka, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Initialization of globals in stringobject.c
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file28830/string_globals.patch

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

From report at bugs.python.org  Fri Jan 25 22:13:13 2013
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 25 Jan 2013 21:13:13 +0000
Subject: [New-bugs-announce] [issue17035] Use new style classes in {class,
	static}method examples
Message-ID: <1359148393.48.0.512379058161.issue17035@psf.upfronthosting.co.za>


New submission from Berker Peksag:

The examples in the built-in functions documentation[1] should be consistent and use new style classes.

[1] http://docs.python.org/2.7/library/functions.html

----------
assignee: docs at python
components: Documentation
files: new-style-classes.diff
keywords: patch
messages: 180624
nosy: berker.peksag, docs at python
priority: normal
severity: normal
status: open
title: Use new style classes in {class, static}method examples
versions: Python 2.7
Added file: http://bugs.python.org/file28831/new-style-classes.diff

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

From report at bugs.python.org  Fri Jan 25 23:01:25 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Jan 2013 22:01:25 +0000
Subject: [New-bugs-announce] [issue17036] Implementation of the PEP 433:
	Easier suppression of	file descriptor inheritance
Message-ID: <1359151285.62.0.659364968053.issue17036@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I create this issue to review and track the implementation of the PEP 433: "Easier suppression of file descriptor inheritance"
http://www.python.org/dev/peps/pep-0433/

----------
components: Interpreter Core
hgrepos: 173
messages: 180630
nosy: haypo
priority: normal
severity: normal
status: open
title: Implementation of the PEP 433: Easier suppression of file descriptor inheritance
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Jan 26 06:48:48 2013
From: report at bugs.python.org (Eric Snow)
Date: Sat, 26 Jan 2013 05:48:48 +0000
Subject: [New-bugs-announce] [issue17037] Add conforms_to_pep399() to
	test.support
Message-ID: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za>


New submission from Eric Snow:

Related to issue #16817 and to my efforts on a C OrderedDict, I think it would be nice to have a class decorator that handles most of the PEP 399 requirements for you.  The attached patch adds such a decorator to test.support.

----------
assignee: eric.snow
components: Library (Lib)
files: conforms-to-pep399.diff
keywords: patch
messages: 180641
nosy: brett.cannon, eric.snow
priority: normal
severity: normal
stage: patch review
status: open
title: Add conforms_to_pep399() to test.support
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28840/conforms-to-pep399.diff

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

From report at bugs.python.org  Sat Jan 26 10:39:23 2013
From: report at bugs.python.org (HadiM)
Date: Sat, 26 Jan 2013 09:39:23 +0000
Subject: [New-bugs-announce] [issue17038] multiprocessing only use one core
	when C module are	imported
Message-ID: <1359193163.5.0.985528068255.issue17038@psf.upfronthosting.co.za>


New submission from HadiM:

Hi,

This is the first time I report a bug so if I did something wrong please let me know. I also tried to ask on #python and #python-fr before posting here to know if it was a bug or a possible multiprocessing limitation on Linux. So I'm sorry if it's not a bug... 

The problem appears when a module with .c compiled file is imported (sush as numpy, scipy, pandas, tables, skimage, I did not tested with a custom .c module). Multiprocessing and more specifically imap and map method of Pool class did not distribute processes along all the core but only on one core. This problem does not appears when I don't import a module with .c compiled.

I know distributing processes along cores is specific to the OS implementation and not related to Python but I said that to illustrate the behaviour.

I should notice that I did not see the bug with a Windows 7, 32 bits (Virtualbox).

My laptop run with the latest ubuntu 64bits (tested with both kernel 3.5 and 3.8 last rc). It's a classic Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz with 4 cores.

You can try to reproduce the bug with the attached file. You can also find the same file here : http://pastebin.com/jqq9G5Ph

Thank you for your time !

----------
components: Library (Lib), ctypes
files: bug.py
messages: 180648
nosy: hadim
priority: normal
severity: normal
status: open
title: multiprocessing only use one core when C module are imported
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file28841/bug.py

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

From report at bugs.python.org  Sat Jan 26 12:30:10 2013
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Sat, 26 Jan 2013 11:30:10 +0000
Subject: [New-bugs-announce] [issue17039] socket.SocketIO hides socket
	timeouts as blocking errors
Message-ID: <1359199810.96.0.970549154582.issue17039@psf.upfronthosting.co.za>


New submission from Ronny Pfannschmidt:

the change to conform with pep 3114 makes socketSocketIO hide Timeouts,
since they are also denoted with EAGAIN (which is one of the blocking errors a nonblocking socket will raise)

that causes read/readinto return None, when one would expect a Timeout

----------
messages: 180660
nosy: Ronny.Pfannschmidt
priority: normal
severity: normal
status: open
title: socket.SocketIO hides socket timeouts as blocking errors
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Jan 26 14:26:50 2013
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 26 Jan 2013 13:26:50 +0000
Subject: [New-bugs-announce] [issue17040] Document context manager support
	for shelf objects
Message-ID: <1359206810.79.0.264675757917.issue17040@psf.upfronthosting.co.za>


New submission from Berker Peksag:

Context manager support for shelf objects was added in issue 13896, but not documented.

----------
assignee: docs at python
components: Documentation
files: shelve-context-manager-doc.diff
keywords: patch
messages: 180667
nosy: asvetlov, berker.peksag, docs at python
priority: normal
severity: normal
status: open
title: Document context manager support for shelf objects
versions: Python 3.4
Added file: http://bugs.python.org/file28843/shelve-context-manager-doc.diff

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

From report at bugs.python.org  Sat Jan 26 14:35:37 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Jan 2013 13:35:37 +0000
Subject: [New-bugs-announce] [issue17041] Fix tests for build
	--without-doc-strings
Message-ID: <1359207337.13.0.919853887813.issue17041@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Some tests failed when Python built without docstrings (--without-doc-strings options). Proposed patch fixes most of tests.

Only doctests in test_generators and test_genexps don't fixed. I?don't know how to make doctests conditional.

[135/372] test_generators
**********************************************************************
File "/home/serhiy/py/cpython-without-doc-strings/Lib/test/test_generators.py", line ?, in test.test_generators.__test__.email
Failed example:
    print(i.__next__.__doc__)
Expected:
    x.__next__() <==> next(x)
Got:
    <BLANKLINE>
**********************************************************************
1 items had failures:
   1 of  31 in test.test_generators.__test__.email
***Test Failed*** 1 failures.
test test_generators failed -- 1 of 287 doctests failed

[137/372/1] test_genexps
**********************************************************************
File "/home/serhiy/py/cpython-without-doc-strings/Lib/test/test_genexps.py", line ?, in test.test_genexps.__test__.doctests
Failed example:
    print(g.__next__.__doc__)
Expected:
    x.__next__() <==> next(x)
Got:
    <BLANKLINE>
**********************************************************************
1 items had failures:
   1 of  75 in test.test_genexps.__test__.doctests
***Test Failed*** 1 failures.
test test_genexps failed -- 1 of 75 doctests failed

----------
components: Tests
files: tests_without_docstrings.patch
keywords: patch
messages: 180668
nosy: serhiy.storchaka, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Fix tests for build --without-doc-strings
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28844/tests_without_docstrings.patch

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

From report at bugs.python.org  Sat Jan 26 19:20:37 2013
From: report at bugs.python.org (Eric Snow)
Date: Sat, 26 Jan 2013 18:20:37 +0000
Subject: [New-bugs-announce] [issue17042] Example in C-API memory management
	doc has confusing	order
Message-ID: <1359224437.99.0.267409459887.issue17042@psf.upfronthosting.co.za>


New submission from Eric Snow:

In http://docs.python.org/dev/c-api/memory.html#examples:

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
char *buf1 = PyMem_New(char, BUFSIZ);
char *buf2 = (char *) malloc(BUFSIZ);
char *buf3 = (char *) PyMem_Malloc(BUFSIZ);
...
PyMem_Del(buf3);  /* Wrong -- should be PyMem_Free() */
free(buf2);       /* Right -- allocated via malloc() */
free(buf1);       /* Fatal -- should be PyMem_Del()  */
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Is there a good reason to have the second set of 3 lines in the opposite order as the first three?  At first I missed that they were in a different order and thought there was an error in the example.  If there's no good reason for the order, it would be worth fixing.  If there is a good reason,  a comment in the example would help.  Either way I'd be glad to patch it (will go ahead with fixing the ordering later today if no one does it first).

----------
assignee: docs at python
components: Documentation
messages: 180697
nosy: docs at python, eric.snow
priority: low
severity: normal
stage: needs patch
status: open
title: Example in C-API memory management doc has confusing order
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Jan 26 21:41:15 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 26 Jan 2013 20:41:15 +0000
Subject: [New-bugs-announce] [issue17043] Invalid read in test_codecs
Message-ID: <1359232875.45.0.401299451794.issue17043@psf.upfronthosting.co.za>


New submission from Stefan Krah:

Found this in test_codecs running under Valgrind (Python 3.3):


test_bug1251300 (test.test_codecs.UnicodeInternalTest) ... ==11511== Invalid read of size 1
==11511==    at 0x44AF37: _PyUnicode_DecodeUnicodeInternal (unicodeobject.c:6133)
==11511==    by 0x4DEB5C: unicode_internal_decode (_codecsmodule.c:251)
==11511==    by 0x5093F6: PyObject_Call (abstract.c:2082)
==11511==    by 0x47D7F2: PyEval_CallObjectWithKeywords (ceval.c:3942)
==11511==    by 0x491C38: PyCodec_Decode (codecs.c:403)
==11511==    by 0x459D7D: PyUnicode_Decode (unicodeobject.c:3129)
==11511==    by 0x45A287: PyUnicode_FromEncodedObject (unicodeobject.c:3023)
==11511==    by 0x519A45: bytes_decode (bytesobject.c:2320)
==11511==    by 0x484AB8: PyEval_EvalFrameEx (ceval.c:4374)
==11511==    by 0x485ACB: PyEval_EvalFrameEx (ceval.c:4150)
==11511==    by 0x486779: PyEval_EvalCodeEx (ceval.c:3433)
==11511==    by 0x4859CA: PyEval_EvalFrameEx (ceval.c:4160)
==11511==  Address 0x984a7e2 is 0 bytes after a block of size 34 alloc'd
==11511==    at 0x4C27972: realloc (vg_replace_malloc.c:525)
==11511==    by 0x51AC34: _PyBytes_Resize (bytesobject.c:2881)
==11511==    by 0x51B1FA: PyBytes_FromObject (bytesobject.c:2732)
==11511==    by 0x51C134: bytes_new (bytesobject.c:2594)
==11511==    by 0x42A4E4: type_call (typeobject.c:723)
==11511==    by 0x5093F6: PyObject_Call (abstract.c:2082)
==11511==    by 0x4843D5: PyEval_EvalFrameEx (ceval.c:4282)
==11511==    by 0x485ACB: PyEval_EvalFrameEx (ceval.c:4150)
==11511==    by 0x486779: PyEval_EvalCodeEx (ceval.c:3433)
==11511==    by 0x4859CA: PyEval_EvalFrameEx (ceval.c:4160)
==11511==    by 0x486779: PyEval_EvalCodeEx (ceval.c:3433)
==11511==    by 0x538EF8: function_call (funcobject.c:633)
==11511== 



_PyUnicode_DecodeUnicodeInternal (s=0x984a7e0 "", size=<value optimized out>, errors=0x0)
    at Objects/unicodeobject.c:6133
6133            ((char *) &uch)[2] = s[2];




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




==11511== 
==11511== Debugger has detached.  Valgrind regains control.  We continue.
==11511== Invalid read of size 1
==11511==    at 0x44AF3E: _PyUnicode_DecodeUnicodeInternal (unicodeobject.c:6134)
==11511==    by 0x4DEB5C: unicode_internal_decode (_codecsmodule.c:251)
==11511==    by 0x5093F6: PyObject_Call (abstract.c:2082)
==11511==    by 0x47D7F2: PyEval_CallObjectWithKeywords (ceval.c:3942)
==11511==    by 0x491C38: PyCodec_Decode (codecs.c:403)
==11511==    by 0x459D7D: PyUnicode_Decode (unicodeobject.c:3129)
==11511==    by 0x45A287: PyUnicode_FromEncodedObject (unicodeobject.c:3023)
==11511==    by 0x519A45: bytes_decode (bytesobject.c:2320)
==11511==    by 0x484AB8: PyEval_EvalFrameEx (ceval.c:4374)
==11511==    by 0x485ACB: PyEval_EvalFrameEx (ceval.c:4150)
==11511==    by 0x486779: PyEval_EvalCodeEx (ceval.c:3433)
==11511==    by 0x4859CA: PyEval_EvalFrameEx (ceval.c:4160)
==11511==  Address 0x984a7e3 is 1 bytes after a block of size 34 alloc'd
==11511==    at 0x4C27972: realloc (vg_replace_malloc.c:525)
==11511==    by 0x51AC34: _PyBytes_Resize (bytesobject.c:2881)
==11511==    by 0x51B1FA: PyBytes_FromObject (bytesobject.c:2732)
==11511==    by 0x51C134: bytes_new (bytesobject.c:2594)
==11511==    by 0x42A4E4: type_call (typeobject.c:723)
==11511==    by 0x5093F6: PyObject_Call (abstract.c:2082)
==11511==    by 0x4843D5: PyEval_EvalFrameEx (ceval.c:4282)
==11511==    by 0x485ACB: PyEval_EvalFrameEx (ceval.c:4150)
==11511==    by 0x486779: PyEval_EvalCodeEx (ceval.c:3433)
==11511==    by 0x4859CA: PyEval_EvalFrameEx (ceval.c:4160)
==11511==    by 0x486779: PyEval_EvalCodeEx (ceval.c:3433)
==11511==    by 0x538EF8: function_call (funcobject.c:633)
==11511== 


Loaded symbols for /usr/lib/gconv/ISO8859-9.so
_PyUnicode_DecodeUnicodeInternal (s=0x8295790 "", size=<value optimized out>, errors=0x0)
    at Objects/unicodeobject.c:6134
6134            ((char *) &uch)[3] = s[3];

----------
messages: 180709
nosy: serhiy.storchaka, skrah
priority: normal
severity: normal
status: open
title: Invalid read in test_codecs
versions: Python 3.3

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

From report at bugs.python.org  Sat Jan 26 22:29:18 2013
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 26 Jan 2013 21:29:18 +0000
Subject: [New-bugs-announce] [issue17044] Implement PEP 422: Simple class
	initialisation hook
Message-ID: <1359235758.38.0.556194565574.issue17044@psf.upfronthosting.co.za>


New submission from Daniel Urban:

The attached patch implements PEP 422 -- Simple class initialisation hook (__init_class__). It includes tests, but it doesn't include documentation yet.

----------
components: Interpreter Core, Library (Lib)
files: pep422_1.patch
keywords: needs review, patch
messages: 180714
nosy: daniel.urban, ncoghlan
priority: normal
severity: normal
stage: patch review
status: open
title: Implement PEP 422: Simple class initialisation hook
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28859/pep422_1.patch

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

From report at bugs.python.org  Sun Jan 27 01:11:25 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 27 Jan 2013 00:11:25 +0000
Subject: [New-bugs-announce] [issue17045] Improve C-API doc for PyTypeObject
Message-ID: <1359245485.06.0.557532055897.issue17045@psf.upfronthosting.co.za>


New submission from Eric Snow:

http://docs.python.org/dev/c-api/typeobj.html

I found the the documentation for PyTypeObject to be somewhat harder to use than it need be.  In the end I distilled the info down for my own use.  I'm comfortable with what I came up with, so I'd like to at least add a condensed version of one or two of the tables I made to the top of the doc, with the slot names linking to each description as it currently exists.  Attached is a patch.

(I also plan on reformatting the doc source so the lines wrap better--70 columns or so.)

As well, I have a couple open questions that I'll address separately:
* should tp_del be added?
* inheritance of tp_flags...

----------
files: typeobj-doc.diff
keywords: patch
messages: 180723
nosy: eric.snow
priority: normal
severity: normal
status: open
title: Improve C-API doc for PyTypeObject
Added file: http://bugs.python.org/file28864/typeobj-doc.diff

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

From report at bugs.python.org  Sun Jan 27 07:04:12 2013
From: report at bugs.python.org (Ned Deily)
Date: Sun, 27 Jan 2013 06:04:12 +0000
Subject: [New-bugs-announce] [issue17046] test_subprocess
	test_executable_without_cwd fails when	run with installed python
Message-ID: <1359266652.98.0.400492689788.issue17046@psf.upfronthosting.co.za>


New submission from Ned Deily:

./configure --enable-shared --with-pydebug --prefix=/py/root && make && make install
cd
export LD_LIBRARY_PATH=/py/root/lib
/py/root/bin/python3.4 -m test -w -uall,-largefile test_subprocess


======================================================================
FAIL: test_executable_without_cwd (test.test_subprocess.ProcessTestCase)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "/py/root/lib/python3.4/test/test_subprocess.py", line 346, in test_executable_without_cwd
    self._assert_cwd('', "somethingyoudonthave", executable=sys.executable)
  File "/py/root/lib/python3.4/test/test_subprocess.py", line 274, in _assert_cwd
    normcase(p.stdout.read().decode("utf-8")))
AssertionError: '' != '/tmp/test_python_22505'
+ /tmp/test_python_22505

======================================================================
FAIL: test_executable_without_cwd (test.test_subprocess.ProcessTestCaseNoPoll)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/py/root/lib/python3.4/test/test_subprocess.py", line 346, in test_executable_without_cwd
    self._assert_cwd('', "somethingyoudonthave", executable=sys.executable)
  File "/py/root/lib/python3.4/test/test_subprocess.py", line 274, in _assert_cwd
    normcase(p.stdout.read().decode("utf-8")))
AssertionError: '' != '/tmp/test_python_22505'
+ /tmp/test_python_22505

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

If we don't already have one, it would probably be a good idea to set up at least one buildbot that does a "make install" and runs the tests using the installed Python.

----------
components: Tests
messages: 180745
nosy: chris.jerdonek, ned.deily
priority: normal
severity: normal
status: open
title: test_subprocess test_executable_without_cwd fails when run with installed python
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Jan 27 09:07:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Jan 2013 08:07:10 +0000
Subject: [New-bugs-announce] [issue17047] Fix double double words words
Message-ID: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In additional to changeset 07488c3c85f1, here are yet some possible word duplications:

Lib/_pyio.py:306:        Change the stream position to byte offset offset. offset is
Lib/concurrent/futures/_base.py:520:            fn: A callable that will take take as many arguments as there are
Lib/tkinter/__init__.py:3116:        have the same start and and end line as the parent widget, but
Lib/tkinter/tix.py:149:        """Locates a bitmap file of the name name.xpm or name in one of the
Lib/tkinter/tix.py:160:        """Locates an image file of the name name.xpm, name.xbm or name.ppm
Lib/lib2to3/pgen2/grammar.py:23:    """Pgen parsing tables tables conversion class.
Lib/lib2to3/pgen2/grammar.py:48:                     states, each state is is a list of arcs, and each
Lib/email/_header_value_parser.py:1866:    We allow anything except the excluded characters, but but if we find any
Lib/email/_encoded_words.py:17:# to to the CTE tables, but YAGNI for now.  'q' is Quoted Printable, 'b' is
Lib/email/mime/text.py:29:        # If no _charset was specified, check to see see if there are non-ascii
Lib/email/policy.py:26:    The API extensions enabled by this this policy are currently provisional.
Lib/unittest/mock.py:1420:    attributes that your production code creates at runtime. It is off by by
Lib/test/test_socket.py:845:        # Try udp, but don't barf it it doesn't exist
Lib/test/test_descrtut.py:322:getx() and and setx():
Lib/test/test_decimal.py:4495:        # Do operations and check that it didn't change change internal objects.
Lib/distutils/command/install.py:266:            raise DistutilsOptionError("can't combine user with with prefix/"
Lib/distutils/tests/test_install.py:168:        # can't combine user with with prefix/exec_prefix/home or
python-gdb.py:1466:        '''Is this frame "collect" within the the garbage-collector?'''
Include/pyport.h:884: * also also takes care of Apple's universal builds.
Modules/_io/iobase.c:79:    "Change the stream position to byte offset offset. offset is\n"
Modules/_heapqmodule.c:91:    /* The leaf at pos is empty now.  Put newitem there, and and bubble
Modules/_heapqmodule.c:431:    /* The leaf at pos is empty now.  Put newitem there, and and bubble
Modules/socketmodule.c:3547:           ensures that that doesn't happen. */
Modules/binascii.c:41:** I have attempted to break with this tradition, but I guess that that
Modules/posixmodule.c:9747:Return the value of extended attribute attribute on path.\n\
Modules/posixmodule.c:9825:Set extended attribute attribute on path to value.\n\
Modules/posixmodule.c:9890:Remove extended attribute attribute on path.\n\
PC/msvcrtmodule.c:133:Create a C runtime file descriptor from the file handle handle. The\n\
Doc/c-api/intro.rst:436::c:func:`sum_sequence` example above.  It so happens that that example doesn't
Doc/c-api/long.rst:206:   Return a C :c:type:`size_t` representation of of *pylong*.  *pylong* must be
Doc/c-api/long.rst:218:   Return a C :c:type:`unsigned PY_LONG_LONG` representation of of *pylong*.
Doc/library/stdtypes.rst:2640:      Cast 1D/unsigned char to to 2D/unsigned long::
Doc/library/email.policy.rst:330:      line breaks and and any (RFC invalid) binary data it may contain.
Doc/library/unittest.mock.rst:991:    attributes that your production code creates at runtime. It is off by by
Doc/whatsnew/3.3.rst:1539:New attribute attribute :data:`multiprocessing.Process.sentinel` allows a
Lib/idlelib/extend.txt:57:Here is a complete example example:
Lib/idlelib/extend.txt:75:used to to configure the loading of extensions and to establish key (or, more

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 180747
nosy: docs at python, ezio.melotti, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Fix double double words words
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Jan 27 09:38:10 2013
From: report at bugs.python.org (Robert Xiao)
Date: Sun, 27 Jan 2013 08:38:10 +0000
Subject: [New-bugs-announce] [issue17048] calendar should understand full-
	vs. half-width	characters
Message-ID: <1359275890.12.0.683153995486.issue17048@psf.upfronthosting.co.za>


New submission from Robert Xiao:

Try this at your command-prompt (requires utf8 support in the terminal emulator):

$ python3 -m calendar -L zh_CN -e utf8

The result is a mess like this:

                                  2013

         ??                        ??                        ??
?  ?  ?  ?  ?  ?  ?       ?  ?  ?  ?  ?  ?  ?       ?  ?  ?  ?  ?  ?  ?
    1  2  3  4  5  6                   1  2  3                   1  2  3
 7  8  9 10 11 12 13       4  5  6  7  8  9 10       4  5  6  7  8  9 10
14 15 16 17 18 19 20      11 12 13 14 15 16 17      11 12 13 14 15 16 17
21 22 23 24 25 26 27      18 19 20 21 22 23 24      18 19 20 21 22 23 24
28 29 30 31               25 26 27 28               25 26 27 28 29 30 31

Note the irregular spacing. The calendar module assumes that the characters are half-width, when in reality they are full-width characters.

calendar should use unicodedata.east_asian_width to determine if a character is full- or half-width, and adjust the spacing accordingly.

----------
components: Library (Lib)
messages: 180748
nosy: nneonneo
priority: normal
severity: normal
status: open
title: calendar should understand full- vs. half-width characters
versions: Python 3.2

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

From report at bugs.python.org  Sun Jan 27 09:48:46 2013
From: report at bugs.python.org (Robert Xiao)
Date: Sun, 27 Jan 2013 08:48:46 +0000
Subject: [New-bugs-announce] [issue17049] calendar throws UnicodeEncodeError
	when locale is	specified
Message-ID: <1359276526.88.0.340808653296.issue17049@psf.upfronthosting.co.za>


New submission from Robert Xiao:

Try this at a command-prompt:

$ python -m calendar -L ja_JP --encoding utf8

The result is a crash:

Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/calendar.py", line 708, in <module>
    main(sys.argv)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/calendar.py", line 703, in main
    result = result.encode(options.encoding)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe6 in position 49: ordinal not in range(128)

The reason is because the TimeEncoding class doesn't properly return the encoding it should use, so 'encoding' ends up being None in "with TimeEncoding(self.locale) as encoding:" lines.

Trivial patch:

--- calendar.py	2013-01-27 03:48:08.000000000 -0500
+++ calendar.py	2013-01-27 03:48:08.000000000 -0500
@@ -488,6 +488,7 @@
     def __enter__(self):
         self.oldlocale = _locale.getlocale(_locale.LC_TIME)
         _locale.setlocale(_locale.LC_TIME, self.locale)
+        return self.locale[1]
 
     def __exit__(self, *args):
         _locale.setlocale(_locale.LC_TIME, self.oldlocale)

----------
components: Library (Lib)
messages: 180750
nosy: nneonneo
priority: normal
severity: normal
status: open
title: calendar throws UnicodeEncodeError when locale is specified
versions: Python 2.7

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

From report at bugs.python.org  Sun Jan 27 09:51:01 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 27 Jan 2013 08:51:01 +0000
Subject: [New-bugs-announce] [issue17050] argparse.REMAINDER doesn't work as
	first argument
Message-ID: <1359276661.57.0.274871702559.issue17050@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

Works:

>>> p = ArgumentParser(prog='test.py')
>>> p.add_argument('pos')
>>> p.add_argument('remainder', nargs=argparse.REMAINDER)
>>> p.parse_args(['abc', '--def'])
Namespace(pos='abc', remainder=['--def'])

Doesn't work:

>>> p = ArgumentParser(prog='test.py')
>>> p.add_argument('remainder', nargs=argparse.REMAINDER)
>>> p.parse_args(['--def'])
usage: test.py [-h] ...
test.py: error: unrecognized arguments: --def

This use case comes up, for example, if you would like to extract all the arguments passed to a subparser in order to pass to a different program.

----------
components: Library (Lib)
messages: 180752
nosy: bethard, chris.jerdonek
priority: normal
severity: normal
stage: test needed
status: open
title: argparse.REMAINDER doesn't work as first argument
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Jan 27 10:10:56 2013
From: report at bugs.python.org (Robert Xiao)
Date: Sun, 27 Jan 2013 09:10:56 +0000
Subject: [New-bugs-announce] [issue17051] Memory leak in os.path.isdir under
	Windows
Message-ID: <1359277856.16.0.886323650341.issue17051@psf.upfronthosting.co.za>


New submission from Robert Xiao:

[From http://stackoverflow.com/questions/12648737/huge-memory-leak-in-repeated-os-path-isdir-calls]

os.path.isdir() leaks memory under Windows in Python 2.7. The core cause is this snippet:

Modules/posixmodule.c:4226:
    if (!PyArg_ParseTuple(args, "et:_isdir",
                          Py_FileSystemDefaultEncoding, &path))
        return NULL;

    attributes = GetFileAttributesA(path);
    if (attributes == INVALID_FILE_ATTRIBUTES)
        Py_RETURN_FALSE;

check:
    if (attributes & FILE_ATTRIBUTE_DIRECTORY)
        Py_RETURN_TRUE;
    else
        Py_RETURN_FALSE;


The buffer returned by the "et" ParseTuple format must be freed after use. Since it isn't freed, we get a memory leak here.

Patch:

--- a/Modules/posixmodule.c	Mon Apr 09 19:04:04 2012 -0400
+++ b/Modules/posixmodule.c	Sun Jan 27 04:10:34 2013 -0500
@@ -4226,6 +4226,7 @@
         return NULL;
 
     attributes = GetFileAttributesA(path);
+    PyMem_Free(path);
     if (attributes == INVALID_FILE_ATTRIBUTES)
         Py_RETURN_FALSE;

----------
components: Library (Lib)
messages: 180754
nosy: nneonneo
priority: normal
severity: normal
status: open
title: Memory leak in os.path.isdir under Windows
type: resource usage
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Sun Jan 27 11:11:51 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 27 Jan 2013 10:11:51 +0000
Subject: [New-bugs-announce] [issue17052] unittest discovery should use
	self.testLoader
Message-ID: <1359281511.22.0.555240068262.issue17052@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The _do_discovery() method of unittest.TestProgram:

    def _do_discovery(self, argv, Loader=loader.TestLoader):

(from http://hg.python.org/cpython/file/2cf89e2e6247/Lib/unittest/main.py#l222 )

should be using self.testLoader instead of loader.TestLoader.  It's not consistent for some parts of TestProgram to use loader.TestLoader and other parts to use the testLoader passed in via the constructor.

----------
components: Library (Lib)
messages: 180755
nosy: chris.jerdonek, ezio.melotti, michael.foord
priority: normal
severity: normal
stage: test needed
status: open
title: unittest discovery should use self.testLoader
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Jan 27 14:17:12 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 27 Jan 2013 13:17:12 +0000
Subject: [New-bugs-announce] [issue17053] pydoc should use inspect.signature
	instead of	inspect.getfullargspec
Message-ID: <1359292632.3.0.760417514127.issue17053@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

pydoc currently uses inspect.getfullargspec to determine the signature of a callable when rendering its documentation. It should use inspect.signature instead because that function can work with callables that aren't python functions or methods.

Changing pydoc to use inspect.signature would make it possible to render more useful documentation for callables implemented in C, when those callables also implement the "__signature__" special method.

----------
components: Library (Lib)
messages: 180768
nosy: ronaldoussoren
priority: low
severity: normal
stage: needs patch
status: open
title: pydoc should use inspect.signature instead of inspect.getfullargspec
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Jan 27 21:33:45 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Jan 2013 20:33:45 +0000
Subject: [New-bugs-announce] [issue17054] cStringIO.StringIO aborted when
	more then INT_MAX bytes	written
Message-ID: <1359318825.63.0.912749070119.issue17054@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Reproduced on x8 snakebite.

% ./python.exe 
Python 2.7.3+ (2.7:38a10d0778d2+, Jan 27 2013, 20:05:15) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
Could not open PYTHONSTARTUP
IOError: [Errno 2] No such file or directory: '/Users/cpython/.pythonrc'
>>> from cStringIO import StringIO
[38179 refs]
>>> f = StringIO()
[38181 refs]
>>> s = 'x' * 2**30
[38183 refs]
>>> f.write(s)
[38183 refs]
>>> f.write(s)
Assertion failed: (oself->pos + l < INT_MAX), function O_cwrite, file /Users/cpython/hg/storchaka/Modules/cStringIO.c, line 421.
zsh: abort      ./python.exe

----------
components: IO
messages: 180790
nosy: serhiy.storchaka
priority: high
severity: normal
stage: needs patch
status: open
title: cStringIO.StringIO aborted when more then INT_MAX bytes written
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Sun Jan 27 23:48:28 2013
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Jastrz=C4=99bski?=)
Date: Sun, 27 Jan 2013 22:48:28 +0000
Subject: [New-bugs-announce] [issue17055] ftplib.ftpcp test
Message-ID: <1359326908.35.0.973015877338.issue17055@psf.upfronthosting.co.za>


New submission from Micha? Jastrz?bski:

Test for ftplib.ftpcp.

----------
components: Tests
files: ftpcp_test.patch
keywords: patch
messages: 180802
nosy: inc0
priority: normal
severity: normal
status: open
title: ftplib.ftpcp test
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28875/ftpcp_test.patch

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

From report at bugs.python.org  Mon Jan 28 00:52:19 2013
From: report at bugs.python.org (Gili T.)
Date: Sun, 27 Jan 2013 23:52:19 +0000
Subject: [New-bugs-announce] [issue17056] Support Visual Studio 2012
Message-ID: <1359330739.37.0.839652698697.issue17056@psf.upfronthosting.co.za>


New submission from Gili T.:

msvc9compiler needs to check for the VS110COMNTOOLS environment variable in order to support Visual Studio 2012. Currently it complains "cannot find vcvarsall.bat".

The following workaround works for now:

SET VS90COMNTOOLS=%VS110COMNTOOLS%

----------
components: Build
messages: 180808
nosy: cowwoc
priority: normal
severity: normal
status: open
title: Support Visual Studio 2012
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Mon Jan 28 01:24:17 2013
From: report at bugs.python.org (Hobs)
Date: Mon, 28 Jan 2013 00:24:17 +0000
Subject: [New-bugs-announce] [issue17057] Data model documentation grammar
Message-ID: <1359332657.03.0.048046509713.issue17057@psf.upfronthosting.co.za>


New submission from Hobs:

New-style and old-style class expalanation in the datamodel section has minor grammatical errors and one minor ambiguity that could be improved.

http://docs.python.org/2/reference/datamodel.html#new-style-and-classic-classes

* "independently of" should always be "indepenent of"
* single hyphens (-) should be double-hyphens (--) for an m-dash
* "flavour" should be "flavor" (used 100x more often in docs.python)
* "only the symantics of..." is ambiguous. can't tell if 'only' modifies 'symantics' or 'new-style classes'?

----------
assignee: docs at python
components: Documentation
files: datamodel-reference-docs.patch
keywords: patch
messages: 180812
nosy: Hobson.Lane, docs at python
priority: normal
severity: normal
status: open
title: Data model documentation grammar
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file28876/datamodel-reference-docs.patch

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

From report at bugs.python.org  Mon Jan 28 02:00:14 2013
From: report at bugs.python.org (Gili T.)
Date: Mon, 28 Jan 2013 01:00:14 +0000
Subject: [New-bugs-announce] [issue17058] Python crashes with error
	0xc0000417
Message-ID: <1359334814.47.0.391505698869.issue17058@psf.upfronthosting.co.za>


New submission from Gili T.:

Python keeps on crashing with error:

The following repro steps are a slight variation of http://packages.python.org/RhodeCode/setup.html.

My installation environment is Windows 7, 64-bit, Visual Studio 2012. I doubt the bug is specific to this environment but I'm providing it as a point of reference. This issue is 100% reproducible for me:

1. Install Python 2.7.3, 64-bit
2. Download https://raw.github.com/pypa/virtualenv/master/virtualenv.py
3. From a VS2012 64-bit command-prompt, run "python virtualenv c:\users\<name>\documents\rhodecode"
4. "cd \users\<name>\documents\rhodecode"
5. "scripts\activate"
6. "pip install rhodecode"
7. "paster make-config RhodeCode production.ini"
8. "paster setup-rhodecode production.ini"
9. You need to point at a directory that contains at least one Mercurial repository.

Code will output:
  [...]
  2013-01-27 19:51:05,855 INFO sqlalchemy.engine.base.Engine ()
  2013-01-27 19:51:05.861 INFO  [rhodecode.model.scm] scanning for repositories in
   C:\Users\Gili\Documents\MercurialRepositories

The thread 0x3b4 has exited with code -1073740777 (0xc0000417).
The thread 0x1bfc has exited with code -1073740777 (0xc0000417).
The thread 0x39c has exited with code -1073740777 (0xc0000417).
The thread 0x1fcc has exited with code -1073740777 (0xc0000417).
The program '[1260] python.exe' has exited with code -1073740777 (0xc0000417).

and crash. The stack-trace is:

>	msvcr90.dll!0000000071059f64()	Unknown
 	msvcr90.dll!00000000710551ec()	Unknown
 	msvcr90.dll!00000000710552d4()	Unknown
 	msvcr90.dll!000000007104f335()	Unknown
 	python27.dll!000000001e0a89f9()	Unknown
 	python27.dll!000000001e0a8c0e()	Unknown
 	python27.dll!000000001e0a9379()	Unknown
 	osutil.pyd!000007fefc62176f()	Unknown
 	python27.dll!000000001e0c0966()	Unknown
 	python27.dll!000000001e110484()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e115439()	Unknown
 	python27.dll!000000001e10eba9()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e115439()	Unknown
 	python27.dll!000000001e0b2553()	Unknown
 	python27.dll!000000001e08adf5()	Unknown
 	python27.dll!000000001e099211()	Unknown
 	python27.dll!000000001e08adf5()	Unknown
 	python27.dll!000000001e0e02be()	Unknown
 	python27.dll!000000001e08adf5()	Unknown
 	python27.dll!000000001e10fc7b()	Unknown
 	python27.dll!000000001e11052a()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e10eb38()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e10eb38()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e115439()	Unknown
 	python27.dll!000000001e0b2553()	Unknown
 	python27.dll!000000001e08adf5()	Unknown
 	python27.dll!000000001e099211()	Unknown
 	python27.dll!000000001e08adf5()	Unknown
 	python27.dll!000000001e0e086e()	Unknown
 	python27.dll!000000001e0dd5e6()	Unknown
 	python27.dll!000000001e08adf5()	Unknown
 	python27.dll!000000001e10fc7b()	Unknown
 	python27.dll!000000001e11052a()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e115439()	Unknown
 	python27.dll!000000001e10eba9()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e115439()	Unknown
 	python27.dll!000000001e0b2553()	Unknown
 	python27.dll!000000001e08adf5()	Unknown
 	python27.dll!000000001e099211()	Unknown
 	python27.dll!000000001e08adf5()	Unknown
 	python27.dll!000000001e0e086e()	Unknown
 	python27.dll!000000001e0dd5e6()	Unknown
 	python27.dll!000000001e08adf5()	Unknown
 	python27.dll!000000001e10fc7b()	Unknown
 	python27.dll!000000001e11052a()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e115439()	Unknown
 	python27.dll!000000001e10eba9()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e115439()	Unknown
 	python27.dll!000000001e10eba9()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e10eb38()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e10eb38()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e10eb38()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e10eb38()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e10eb38()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e10eb38()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e10eb38()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e115439()	Unknown
 	python27.dll!000000001e10eba9()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e115439()	Unknown
 	python27.dll!000000001e1154d9()	Unknown
 	python27.dll!000000001e14166a()	Unknown
 	python27.dll!000000001e14295a()	Unknown
 	python27.dll!000000001e142f9a()	Unknown
 	python27.dll!000000001e1439c3()	Unknown
 	python27.dll!000000001e0443c0()	Unknown
 	python.exe!000000001d00119e()	Unknown
 	kernel32.dll!000000007746652d()	Unknown
 	ntdll.dll!0000000077a5c521()	Unknown

There is no known workaround.

----------
components: Windows
messages: 180816
nosy: cowwoc
priority: normal
severity: normal
status: open
title: Python crashes with error 0xc0000417
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Jan 28 04:50:01 2013
From: report at bugs.python.org (Damian)
Date: Mon, 28 Jan 2013 03:50:01 +0000
Subject: [New-bugs-announce] [issue17059] tarfile.is_tarfile without read
	permissions raises	AttributeError
Message-ID: <1359345001.7.0.483862840582.issue17059@psf.upfronthosting.co.za>


New submission from Damian:

Hi. While porting a library of mine from python 2.7 to 3.2 I noticed that tarfile.is_tarfile() now raises an AttributeError rather than IOError when it lacks read permissions...

atagar at morrigan:~$ touch dummy_file.tar
atagar at morrigan:~$ chmod 000 dummy_file.tar 
atagar at morrigan:~$ pwd
/home/atagar

atagar at morrigan:~$ python
Python 2.7.1+ (r271:86832, Sep 27 2012, 21:16:52) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tarfile
>>> tarfile.is_tarfile("/home/atagar/dummy_file.tar")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/tarfile.py", line 2583, in is_tarfile
    t = open(name)
  File "/usr/lib/python2.7/tarfile.py", line 1658, in open
    return func(name, "r", fileobj, **kwargs)
  File "/usr/lib/python2.7/tarfile.py", line 1720, in gzopen
    fileobj = bltn_open(name, mode + "b")
IOError: [Errno 13] Permission denied: '/home/atagar/dummy_file.tar'

atagar at morrigan:~$ python3
Python 3.2 (r32:88445, Oct 20 2012, 14:09:50) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tarfile
>>> tarfile.is_tarfile("/home/atagar/dummy_file.tar")
Traceback (most recent call last):
  File "/usr/lib/python3.2/tarfile.py", line 1805, in gzopen
    fileobj = gzip.GzipFile(name, mode + "b", compresslevel, fileobj)
  File "/usr/lib/python3.2/gzip.py", line 157, in __init__
    fileobj = self.myfileobj = builtins.open(filename, mode or 'rb')
IOError: [Errno 13] Permission denied: '/home/atagar/dummy_file.tar'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/tarfile.py", line 2593, in is_tarfile
    t = open(name)
  File "/usr/lib/python3.2/tarfile.py", line 1739, in open
    return func(name, "r", fileobj, **kwargs)
  File "/usr/lib/python3.2/tarfile.py", line 1809, in gzopen
    fileobj.close()
AttributeError: 'NoneType' object has no attribute 'close'

>>> try:
...   tarfile.is_tarfile("/home/atagar/dummy_file.tar")
... except IOError:
...   print("caught an IOError")
... except AttributeError:
...   print("caught an AttributeError")
... 
caught an AttributeError


... easy to work around, but I suspect this wasn't intentional. :)

----------
components: None
messages: 180824
nosy: atagar
priority: normal
severity: normal
status: open
title: tarfile.is_tarfile without read permissions raises AttributeError
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Jan 28 10:17:44 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Jan 2013 09:17:44 +0000
Subject: [New-bugs-announce] [issue17060] IDLE -- jump to home should not go
	past the PS1 and PS2	prompts
Message-ID: <1359364664.26.0.133025400757.issue17060@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

In IDLE's shell, pressing <home> or <control-a> currently jumps to the beginning of a line.   Instead it should stop *after* the ">>> "  prompt.

----------
components: IDLE
messages: 180841
nosy: rhettinger
priority: normal
severity: normal
status: open
title: IDLE -- jump to home should not go past the PS1 and PS2 prompts
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Jan 28 12:14:28 2013
From: report at bugs.python.org (Thomas Kluyver)
Date: Mon, 28 Jan 2013 11:14:28 +0000
Subject: [New-bugs-announce] [issue17061] tokenize unconditionally emits NL
	after comment lines &	blank lines
Message-ID: <1359371668.59.0.445577508897.issue17061@psf.upfronthosting.co.za>


New submission from Thomas Kluyver:

The docs describe the NL token as "Token value used to indicate a non-terminating newline. The NEWLINE token indicates the end of a logical line of Python code; NL tokens are generated when a logical line of code is continued over multiple physical lines."

However, after a comment or a blank line, tokenize emits NL, even when it's not inside a multi-line statement. For example:

In [15]: for tok in tokenize.generate_tokens(StringIO('#comment\n').readline):  print(tok)
TokenInfo(type=54 (COMMENT), string='#comment', start=(1, 0), end=(1, 8), line='#comment\n')
TokenInfo(type=55 (NL), string='\n', start=(1, 8), end=(1, 9), line='#comment\n')
TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='')

This makes it difficult to use tokenize to detect multi-line statements, as we want to do in IPython.

In my tests so far, changing two instances of NL to NEWLINE in this block (lines 530 & 533) makes it behave as I expect:
http://hg.python.org/cpython/file/a375c3d88c7e/Lib/tokenize.py#l524

----------
messages: 180846
nosy: takluyver
priority: normal
severity: normal
status: open
title: tokenize unconditionally emits NL after comment lines & blank lines
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Jan 28 12:17:08 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 28 Jan 2013 11:17:08 +0000
Subject: [New-bugs-announce] [issue17062] An os.walk inspired replacement
	for pkgutil.walk_packages
Message-ID: <1359371828.89.0.768628623008.issue17062@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

I recently had occasion to use pkgutil.walk_packages, and my immediate thought was that it would have been a lot easier for me to use if it worked more like os.walk with topdown=True, producing tuples of (pkg, subpackages, modules)

"pkg" would be the package object at the current level (None for the top level)

"packages" would be a dictionary mapping fully qualified module names to loader objects for the subpackages (i.e. subdirectories)

"modules" would be a dictionary mapping fully qualified module names to loader objects for every submodule that wasn't a subpackage

As with editing the "subdirs" list with os.walk, editing the "packages" dictionary with this new API would keep the iterator from loading that subpackage and avoid recursing into it (this is the part I wanted in my current use case).

(This may even be PEP material, guiding some additions to the importer/finder API)

----------
components: Library (Lib)
messages: 180847
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: An os.walk inspired replacement for pkgutil.walk_packages
versions: Python 3.4

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

From report at bugs.python.org  Mon Jan 28 13:50:20 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Jan 2013 12:50:20 +0000
Subject: [New-bugs-announce] [issue17063] assert_called_with could be more
	powerful if it allowed	placeholders
Message-ID: <1359377420.39.0.0447874471019.issue17063@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

assert_called_with currently compares every argument for equality, which is not very practical when one of the arguments is a complex object, of which you only want to check certain properties.

It could be very nice if you could write e.g.:

from mock import Mock, PLACEHOLDER

...
my_mock(1, someobj(), bar=someotherobj()):
foo, bar = my_mock.assert_called_with(
    1, PLACEHOLDER, bar=PLACEHOLDER)
self.assertIsInstance(bar, someobj)
self.assertIsInstance(foo, someotherobj)


(another name for PLACEHOLDER could be CAPTURE, regex-style :-))

----------
messages: 180852
nosy: michael.foord, pitrou
priority: normal
severity: normal
status: open
title: assert_called_with could be more powerful if it allowed placeholders
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Jan 28 18:14:19 2013
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 28 Jan 2013 17:14:19 +0000
Subject: [New-bugs-announce] [issue17064] Fix sporadic buildbot failures for
	test_mailbox
Message-ID: <1359393259.56.0.519558675211.issue17064@psf.upfronthosting.co.za>


New submission from Jeremy Kloth:

Attached is an attempt at fixing the sporadic failures of test_mailbox on the AMD64 Windows buildbot.

It fails due to access errors on some directories which leads me to believe the helper functions in test.support should fix the problem.

----------
components: Tests
files: test_mailbox.diff
keywords: patch
messages: 180862
nosy: jkloth
priority: normal
severity: normal
status: open
title: Fix sporadic buildbot failures for test_mailbox
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file28882/test_mailbox.diff

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

From report at bugs.python.org  Mon Jan 28 18:19:06 2013
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 28 Jan 2013 17:19:06 +0000
Subject: [New-bugs-announce] [issue17065] Fix sporadic buildbot failures for
	test_winreg
Message-ID: <1359393546.73.0.336232098313.issue17065@psf.upfronthosting.co.za>


New submission from Jeremy Kloth:

test_winreg fails sporadically on the AMD64 Windows buildbot.  Looking at the test, it appears that concurrent runs of the test would fail if different processes attempted to modify the test key at the same time.

The attached patch resolves this by using a per-process unique test key name using the process ID.

----------
components: Tests
files: test_winreg.diff
keywords: patch
messages: 180863
nosy: jkloth
priority: normal
severity: normal
status: open
title: Fix sporadic buildbot failures for test_winreg
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file28883/test_winreg.diff

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

From report at bugs.python.org  Mon Jan 28 21:32:51 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 28 Jan 2013 20:32:51 +0000
Subject: [New-bugs-announce] [issue17066] Fix test discovery for
	test_robotparser.py
Message-ID: <1359405171.11.0.463426342019.issue17066@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Here's a fix for test_robotparser.py.  With this patch, the command 'python -m unittest discover Lib/test/ "test_*.py"' can actually be run--before the patch, test_robotparser's unique TestCase subclass causes unexpected errors for discovery.

----------
components: Tests
files: test_robotparser_discovery.diff
keywords: patch
messages: 180878
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_robotparser.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28885/test_robotparser_discovery.diff

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

From report at bugs.python.org  Mon Jan 28 22:15:46 2013
From: report at bugs.python.org (Carsten Klein)
Date: Mon, 28 Jan 2013 21:15:46 +0000
Subject: [New-bugs-announce] [issue17067] Examples in documentation for 3.x
	in 23.1.3.4. Deferred	translations are rather weak
Message-ID: <1359407746.0.0.0107296426233.issue17067@psf.upfronthosting.co.za>


New submission from Carsten Klein:

The examples for the topic presented are rather weak. In fact, they merely present do nothing replacements for an actually working, deferred localization mechanism or some sort of prototypical implementation thereof.

As such I propose that they be replaced with something more meaningful,
for example such as 


class DeferredTranslation(object):

    def __init__(self, message, ...):

        self.message = message

    def __str__(self):

        return gettext.translation(...).lgettext(self.message)


def _(message, ...):

    return DeferredTranslation(message, ...)


MSG = _('localized message')


Or something else along that way other than the currently presented examples :D

----------
assignee: docs at python
components: Documentation
messages: 180882
nosy: carsten.klein at axn-software.de, docs at python
priority: normal
severity: normal
status: open
title: Examples in documentation for 3.x in 23.1.3.4. Deferred translations are rather weak
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Mon Jan 28 23:19:04 2013
From: report at bugs.python.org (Neal Norwitz)
Date: Mon, 28 Jan 2013 22:19:04 +0000
Subject: [New-bugs-announce] [issue17068] peephole optimization for constant
	strings
Message-ID: <1359411544.64.0.96683095685.issue17068@psf.upfronthosting.co.za>


New submission from Neal Norwitz:

I was looking through code like this:

  foo = '%s%s%s' % ('https://', host, uri)

and realized this could be rewritten by the interpreter as:

  foo = 'https://%s%s' % (host, uri)

I tried to determine how much code this might affect, but it was pretty hard for me to come up with a decent regex to filter out all the false positives.  There were too many hits to determine if this would be used often.

----------
components: Interpreter Core
messages: 180885
nosy: nnorwitz
priority: normal
severity: normal
status: open
title: peephole optimization for constant strings
type: performance

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

From report at bugs.python.org  Tue Jan 29 12:29:17 2013
From: report at bugs.python.org (Tuure Laurinolli)
Date: Tue, 29 Jan 2013 11:29:17 +0000
Subject: [New-bugs-announce] [issue17069] HTTP result code in
	urllib2.urlopen() file object	undocumented
Message-ID: <1359458957.32.0.0277538347747.issue17069@psf.upfronthosting.co.za>


New submission from Tuure Laurinolli:

As per documentation at http://docs.python.org/2/library/urllib2.html the file-like object returned by urllib2.urlopen() should have methods geturl() and info(). It actually also has getcode(), which appears to do the same as getcode() on urllib.urlopen() responses.

This should be a documented feature of urllib2.

----------
components: Library (Lib)
messages: 180900
nosy: tazle
priority: normal
severity: normal
status: open
title: HTTP result code in urllib2.urlopen() file object undocumented
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Jan 29 14:09:17 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Jan 2013 13:09:17 +0000
Subject: [New-bugs-announce] [issue17070] Use the new cloexec to improve
	security and avoid bugs
Message-ID: <1359464957.74.0.458887600287.issue17070@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patches use the new cloexec parameter added by the PEP 433 (see issue #17036).

cloexec_fs_walk.patch: [security] don't leak a file descriptors of directories to a child processes
cloexec_listening_socket.patch: [security] don't leak a listening socket to child processes, see also #12107
cloexec_log_file.patch: [security] don't leak the file descriptor of a log file to child processes
cloexec_subprocess.patch: [security/bugs] don't leak file descriptors to child processes
cloexec_misc.patch: misc mmodules

"security" is a strong word: if subprocess is called with close_fds=True, there is no such problem at all. It's more a theorical problem if a process is created in another thread without using the subprocess module (but directly low level functions).

----------
components: Library (Lib)
files: cloexec_fs_walk.patch
keywords: patch
messages: 180905
nosy: haypo, neologix
priority: normal
severity: normal
status: open
title: Use the new cloexec to improve security and avoid bugs
versions: Python 3.4
Added file: http://bugs.python.org/file28888/cloexec_fs_walk.patch

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

From report at bugs.python.org  Tue Jan 29 14:10:10 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Jan 2013 13:10:10 +0000
Subject: [New-bugs-announce] [issue17071] Signature.bind() fails with a
	keyword argument named	"self"
Message-ID: <1359465010.37.0.373880220978.issue17071@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

>>> def f(a, self): pass
... 
>>> sig = inspect.signature(f)
>>> sig.bind(1, 2)
<inspect.BoundArguments object at 0x7f607ead1e28>
>>> sig.bind(a=1, self=2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: bind() got multiple values for argument 'self'

----------
components: Library (Lib)
messages: 180906
nosy: larry, pitrou, yselivanov
priority: normal
severity: normal
status: open
title: Signature.bind() fails with a keyword argument named "self"
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Jan 29 17:14:16 2013
From: report at bugs.python.org (Hakim Taklanti)
Date: Tue, 29 Jan 2013 16:14:16 +0000
Subject: [New-bugs-announce] [issue17072] Decimal, quantize,
	round and negative value
Message-ID: <1359476056.94.0.303954404669.issue17072@psf.upfronthosting.co.za>


New submission from Hakim Taklanti:

>>> from decimal import Decimal
>>> from decimal import ROUND_UP, ROUND_DOWN
>>> a = Decimal("-3.86")
>>> b = Decimal("5.73")
>>> a_up = a.quantize(Decimal(".1"), ROUND_UP)
>>> a.quantize(Decimal(".1"), ROUND_UP) # -3.8 expected
Decimal('-3.9') 
>>> a.quantize(Decimal(".1"), ROUND_DOWN) # -3.9 expected
Decimal('-3.8') 
>>> b.quantize(Decimal(".1"), ROUND_UP) # Ok
Decimal('5.8')
>>> b.quantize(Decimal(".1"), ROUND_DOWN) # Ok
Decimal('5.7')

----------
components: Library (Lib)
messages: 180911
nosy: Hakim.Taklanti
priority: normal
severity: normal
status: open
title: Decimal, quantize, round and negative value
versions: Python 2.7

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

From report at bugs.python.org  Tue Jan 29 18:01:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Jan 2013 17:01:48 +0000
Subject: [New-bugs-announce] [issue17073] Integer overflow in sqlite module
Message-ID: <1359478908.69.0.671503350697.issue17073@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch fixes an integer overflow in such cases:

1. When an authorizer callback (registered with set_authorizer()) returns an integer which doesn't fit into C?int. Now integers out of C?int range interpreted as SQLITE_DENY (as any non-integer values).

2. When a callable used in create_collation() returns an integer which doesn't fit into C?int. Now all Python integers work.

3. When Python integer doesn't fit into SQLite INTEGER. Now overflow detected and an exception raised.

4. Now sqlite module built even when HAVE_LONG_LONG is not defined.

----------
components: Extension Modules
messages: 180915
nosy: ghaering, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Integer overflow in sqlite module
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Jan 29 18:57:49 2013
From: report at bugs.python.org (Zearin)
Date: Tue, 29 Jan 2013 17:57:49 +0000
Subject: [New-bugs-announce] [issue17074] (docs) Consistent formatting of
	constants
Message-ID: <1359482269.16.0.953084487714.issue17074@psf.upfronthosting.co.za>


New submission from Zearin:

When reading the docs, I noticed that the capitalization and formatting of the Python constants ``True``, ``False``, and ``None`` were inconsistent.

The attached patch contains a fix for all such occurrences under ``/Doc/library/``.

(I **think** I correctly made the patch.  I hardly ever make patches, so if I screwed up, let me know and I?ll see if I can get it right. ?)


Parent commit: 
9137e2d1c00c6906af206d1c9d217b15613bb1ed

----------
assignee: docs at python
components: Documentation
files: python_docs_constants.diff
keywords: patch
messages: 180918
nosy: docs at python, zearin
priority: normal
severity: normal
status: open
title: (docs) Consistent formatting of constants
versions: Python 2.7
Added file: http://bugs.python.org/file28897/python_docs_constants.diff

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

From report at bugs.python.org  Tue Jan 29 19:05:06 2013
From: report at bugs.python.org (Aaron Sherman)
Date: Tue, 29 Jan 2013 18:05:06 +0000
Subject: [New-bugs-announce] [issue17075] logging documentation for library
	cleanup
Message-ID: <1359482706.26.0.367132377172.issue17075@psf.upfronthosting.co.za>


New submission from Aaron Sherman:

This documentation states that libraries can turn off logging by adding a NullHandler:

http://docs.python.org/2/howto/logging.html#configuring-logging-for-a-library

This is not entirely true. It only holds true if the application which calls the library has not called basicConfig on the root logger. If it has, you get logs to both the root logger and the NullLogger, defeating the point of having added a NullLogger in the first place.

The correct way for a library to silence log messages is to both set a NullHandler and set propagate to false.

For an example of the behavior on the current docs, see:

  import logging
  import sys
  # Application configures its root logger
  logging.basicConfig(level=logging.DEBUG)
  
  # Library configures a NullLogger:
  logger = logging.getLogger('foo')
  logger.setLevel(logging.DEBUG)
  handler = logging.NullHandler()
  handler.setLevel(logging.DEBUG)
  logger.addHandler(handler)
  
  # Library then logs:
  logger.warning("BLAH")

This example is not terribly interesting, but the more interesting example is when the library configures a real log handler (e.g. in order to create a separate security log in an authorization module). In this case, the log messages will be sent to both the file log and the root logger by default, as long as any part of the application has configured the root logger.

IMHO, propagate should always be False for all new loggers, but at the very least the fact that it is True should be documented in the section on library logging...

----------
assignee: docs at python
components: Documentation
messages: 180919
nosy: ajs, docs at python
priority: normal
severity: normal
status: open
title: logging documentation for library cleanup
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jan 29 19:18:12 2013
From: report at bugs.python.org (Thomas Wouters)
Date: Tue, 29 Jan 2013 18:18:12 +0000
Subject: [New-bugs-announce] [issue17076] shutil.copytree failing on
	xattr-less filesystems (like	NFS)
Message-ID: <1359483492.58.0.639649244817.issue17076@psf.upfronthosting.co.za>


New submission from Thomas Wouters:

The new xattr support in shutil causes shutil.copytree and shutil.copy2 to fail inelegantly on (source) filesystems that do not support xattrs (like NFS):

# /home/twouters does not support xattrs
>>> os.listxattr("/home/twouters/foo")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 95] Operation not supported: '/home/twouters/foo'

>>> shutil.copytree("/home/twouters/spam", "/tmp/spam")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/twouters/gvs-pristine/python/Python-3.3.0/Lib/shutil.py", line 345, in copytree
    raise Error(errors)
shutil.Error: [('/home/twouters/spam/ham', '/tmp/spam/ham', "[Errno 95] Operation not supported: '/home/twouters/spam/ham'"), ('/home/twouters/spam/eggs', '/tmp/spam/eggs', "[Errno 95] Operation not supported: '/home/twouters/spam/eggs'"), ('/home/twouters/spam', '/tmp/spam', "[Errno 95] Operation not supported: '/home/twouters/spam'")]

(The actual files will have been copied, since xattr copies are done after everything else.)  Interestingly shutil._copyxattr does try to cope with unsupported xattrs on the *target* filesystem (which seems like it might be a mistake to do, since it loses data), just not the original filesystem (which seems like a sensible thing instead):

# /tmp does support xattrs
>>> os.listxattr("/tmp/spam")
[]
>>> shutil.copytree("/tmp/spam", "/home/twouters/spam-new")
'/home/twouters/spam-new'

The attached patch fixes shutil._copyxattr to also ignore unsupported/empty xattrs (but not permission errors) on the source. (I'm not certain if errno.ENODATA can be expected from os.listxattr(), but internet searches suggest that some people think so, and I don't know what other meaning it could have.)

----------
files: shutil.patch
keywords: needs review, patch
messages: 180920
nosy: twouters
priority: high
severity: normal
stage: patch review
status: open
title: shutil.copytree failing on xattr-less filesystems (like NFS)
type: crash
versions: Python 3.3
Added file: http://bugs.python.org/file28898/shutil.patch

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

From report at bugs.python.org  Tue Jan 29 19:39:37 2013
From: report at bugs.python.org (Jeremy Kloth)
Date: Tue, 29 Jan 2013 18:39:37 +0000
Subject: [New-bugs-announce] [issue17077] Fix test_tools hangs
Message-ID: <1359484777.42.0.023750065374.issue17077@psf.upfronthosting.co.za>


New submission from Jeremy Kloth:

Attached is a patch to test_tools that gets it back to a run-able state.

----------
components: Tests
files: test_tools.diff
keywords: patch
messages: 180925
nosy: jkloth, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Fix test_tools hangs
versions: Python 3.2
Added file: http://bugs.python.org/file28899/test_tools.diff

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

From report at bugs.python.org  Tue Jan 29 22:30:46 2013
From: report at bugs.python.org (Adam Kellas)
Date: Tue, 29 Jan 2013 21:30:46 +0000
Subject: [New-bugs-announce] [issue17078] string.Template.safe_substitute
	hard-wires "braces" as {}
Message-ID: <1359495046.85.0.635388190725.issue17078@psf.upfronthosting.co.za>


New submission from Adam Kellas:

If you use safe_substitute and try to use a variable reference style other than ${foo}, you will find that it assumes ${foo} style. In particular, when evaluating $[foo] (square braces) and 'foo' is not defined, safe_substitute will put the string back together using ${foo} (curly braces).

See <http://stackoverflow.com/questions/14573230/pythons-string-template-changes-brackets-when-variable-is-unset> for details and test case.

----------
components: Library (Lib)
messages: 180949
nosy: Adam.Kellas
priority: normal
severity: normal
status: open
title: string.Template.safe_substitute hard-wires "braces" as {}
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jan 29 23:20:46 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 29 Jan 2013 22:20:46 +0000
Subject: [New-bugs-announce] [issue17079] Fix test discovery for
	test_ctypes.py
Message-ID: <1359498046.65.0.0354719315528.issue17079@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
components: Tests
files: test_ctypes_discovery.diff
keywords: patch
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_ctypes.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28906/test_ctypes_discovery.diff

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

From report at bugs.python.org  Wed Jan 30 09:33:13 2013
From: report at bugs.python.org (Jonathan Livni)
Date: Wed, 30 Jan 2013 08:33:13 +0000
Subject: [New-bugs-announce] [issue17080] A better error message for float()
Message-ID: <1359534793.39.0.291653711097.issue17080@psf.upfronthosting.co.za>


New submission from Jonathan Livni:

These lines of Python (2.7):

    y = float(x)

gives the error:

    TypeError: float() argument must be a string or a number.

In various cases such as:

    x = [0]
    x = None
    x = SomeClass()

In addition to the information given in the error message, it could help, for debugging purposes, to state the type of the object given.

----------
components: Interpreter Core
messages: 180967
nosy: Jonathan.Livni
priority: normal
severity: normal
status: open
title: A better error message for float()
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed Jan 30 10:05:10 2013
From: report at bugs.python.org (wohugb)
Date: Wed, 30 Jan 2013 09:05:10 +0000
Subject: [New-bugs-announce] [issue17081] documentation
Message-ID: <1359536710.83.0.297139982136.issue17081@psf.upfronthosting.co.za>


Changes by wohugb <wohugb at qq.com>:


----------
assignee: docs at python
components: Documentation
nosy: docs at python, wohugb
priority: normal
severity: normal
status: open
title: documentation
versions: Python 3.3

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

From report at bugs.python.org  Wed Jan 30 18:57:57 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 30 Jan 2013 17:57:57 +0000
Subject: [New-bugs-announce] [issue17082] Fix test discovery for test_dbm*.py
Message-ID: <1359568677.42.0.42152696128.issue17082@psf.upfronthosting.co.za>


New submission from Zachary Ware:

This patch fixes discovery for test_dbm.py and removes test_main() from test_dbm, test_dbm_dumb, test_dbm_gnu, and test_dbm_ndbm.

It also removes unnecessary __init__ methods from DumbDBMTestCase and WhichDBTestCase, which only called unittest.TestCase.__init__ with all supplied arguments.

----------
components: Tests
files: test_dbm-s_discovery.diff
keywords: patch
messages: 180979
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_dbm*.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28909/test_dbm-s_discovery.diff

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

From report at bugs.python.org  Wed Jan 30 19:32:05 2013
From: report at bugs.python.org (Bryant)
Date: Wed, 30 Jan 2013 18:32:05 +0000
Subject: [New-bugs-announce] [issue17083] can't specify newline string for
	readline for binary	files
Message-ID: <1359570725.1.0.7766942653.issue17083@psf.upfronthosting.co.za>


New submission from Bryant:

When opening binary files in Python 3, the newline parameter cannot be set. While this kind of makes sense, readline() can still be used on binary files. This is great for my usage, but it is doing universal newline mode, I believe, so that any \r, \n, or \r\n triggers an EOL.

The data I'm working with is mixed ASCII/binary, with line termination specified by \r\n. I can't read a line (even though that concept occurs in my file) because some of the binary data includes \r or \n even though they aren't newlines in this context.

The issue here is that if the newline string can't be specified, readline() is useless on binary data, which often uses custom EOL strings. So would it be reasonable to add the newline parameter support to binary files? If not, then shouldn't readline() throw an exception when used on binary files?

I don't know if it's helpful here, but I've written a binary_readline() function supporting arbitrary EOL strings:

def binary_readline(file, newline=b'\r\n'):
    line = bytearray()
    newlineIndex = 0
    while True:
        x = file.read(1)
        if x:
            line += x
        else:
            if len(line) == 0:
                return None
            else:
                return line
        # If this character starts to match the newline string, start that comparison til it matches or doesn't.
        while line[-1] == newline[newlineIndex]:
            x = file.read(1)
            if x:
                line += x
            else:
                return line
            newlineIndex += 1
            if newlineIndex == len(newline):
                return line
               
        # We failed checking for the newline string, so reset the checking index
        newlineIndex = 0

----------
components: Library (Lib)
messages: 180984
nosy: susurrus
priority: normal
severity: normal
status: open
title: can't specify newline string for readline for binary files
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Jan 30 20:16:53 2013
From: report at bugs.python.org (David Holm)
Date: Wed, 30 Jan 2013 19:16:53 +0000
Subject: [New-bugs-announce] [issue17084] nntplib.NNTP.xover does not always
	return results as	documented
Message-ID: <1359573413.45.0.835923158727.issue17084@psf.upfronthosting.co.za>


New submission from David Holm:

The response from NNTP.xover doesn't always match the format described in the documentation. It is supposed to return a (result, list) where the list contains entries of the format (article number, subject, poster, date, id, references, size, lines). However, I have found it to sometimes split the subject into two entries or only one of multiple references being in a list (see example below).

I am attempting to interpret the data using an enum-like structure to match the indices to the values but it fails very often because the date field contains part of the subject or the size field contains a cross reference entry.

Example using Python 2.7:

    >>> import nntplib
    >>> c = nntplib.NNTP(..)
    >>> c.group('alt.binaries.linux')
    ('211 317334 3 317336 alt.binaries.linux', '317334', '3', '317336', 'alt.binaries.linux')
    >>> resp, lst = c.xover('114179', '114179')
    >>> print resp
    224 data follows
    >>> print lst
    [('114179', 'Re: Newsposter - The Linux Binary Posting Script Version 7.2', 'Patriot <American1 at shangri.la.org>', 'Mon, 04 Jan 2010 17:36:44 -0600', '<cu-dnfpXgcsR5t_WnZ2dnUVZ_rBi4p2d at giganews.com>', ['<5aydnT9obM20bKrWnZ2dnUVZ_v2dnZ2d at giganews.com>'], '<XGa0n.15891$0U1.11678 at newsfe16.iad>', '1443')]

In the example above '<XGa0n.15891$0U1.11678 at newsfe16.iad>' can be found at index 6 where the size is supposed to be.

----------
components: Library (Lib)
messages: 180987
nosy: dholm
priority: normal
severity: normal
status: open
title: nntplib.NNTP.xover does not always return results as documented
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Jan 30 22:17:08 2013
From: report at bugs.python.org (ddvento@ucar.edu)
Date: Wed, 30 Jan 2013 21:17:08 +0000
Subject: [New-bugs-announce] [issue17085] test_socket crashes the whole test
	suite
Message-ID: <1359580628.83.0.173179383331.issue17085@psf.upfronthosting.co.za>


New submission from ddvento at ucar.edu:

While running "make test" on my build of python 2.7.3 the suite aborts with

[..omiss..]
test_socket
make: *** [test] Alarm clock

Trying to run individually the offending test reveals a little more


$ ./python Lib/test/regrtest.py -v test_socket
== CPython 2.7.3 (default, Jan 29 2013, 11:23:48) [GCC 4.7.2]
==   Linux-2.6.32-220.13.1.el6.x86_64-x86_64-with-redhat-6.2-Santiago little-endian
==   /glade/scratch/ddvento/build/Python-2.7.3-westmere/build/test_python_12171
Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0)
test_socket
TIPC module is not loaded, please 'sudo modprobe tipc'
testCrucialConstants (test.test_socket.GeneralModuleTests) ... ok
testDefaultTimeout (test.test_socket.GeneralModuleTests) ... ok
testGetServBy (test.test_socket.GeneralModuleTests) ... ok
testGetSockOpt (test.test_socket.GeneralModuleTests) ... ok
testGetaddrinfo (test.test_socket.GeneralModuleTests) ... ok
testHostnameRes (test.test_socket.GeneralModuleTests) ... ok
testIPv4_inet_aton_fourbytes (test.test_socket.GeneralModuleTests) ... ok
testIPv4toString (test.test_socket.GeneralModuleTests) ... ok
testIPv6toString (test.test_socket.GeneralModuleTests) ... ok
testInterpreterCrash (test.test_socket.GeneralModuleTests) ... ok
testListenBacklog0 (test.test_socket.GeneralModuleTests) ... ok
testNewAttributes (test.test_socket.GeneralModuleTests) ... ok
testNtoH (test.test_socket.GeneralModuleTests) ... ok
testNtoHErrors (test.test_socket.GeneralModuleTests) ... ok
testRefCountGetNameInfo (test.test_socket.GeneralModuleTests) ... ok
testSendAfterClose (test.test_socket.GeneralModuleTests) ... ok
testSendtoErrors (test.test_socket.GeneralModuleTests) ... ok
testSetSockOpt (test.test_socket.GeneralModuleTests) ... ok
testSockName (test.test_socket.GeneralModuleTests) ... ok
testSocketError (test.test_socket.GeneralModuleTests) ... ok
testStringToIPv4 (test.test_socket.GeneralModuleTests) ... ok
testStringToIPv6 (test.test_socket.GeneralModuleTests) ... ok
test_flowinfo (test.test_socket.GeneralModuleTests) ... ok
test_getsockaddrarg (test.test_socket.GeneralModuleTests) ... ok
test_sendall_interrupted (test.test_socket.GeneralModuleTests) ... FAIL
test_sendall_interrupted_with_timeout (test.test_socket.GeneralModuleTests) ... FAIL
test_sock_ioctl (test.test_socket.GeneralModuleTests) ... skipped 'Windows specific'
test_weakref (test.test_socket.GeneralModuleTests) ... ok
testDup (test.test_socket.BasicTCPTest) ... ok
testFromFd (test.test_socket.BasicTCPTest) ... ok
testOverFlowRecv (test.test_socket.BasicTCPTest) ... ok
testOverFlowRecvFrom (test.test_socket.BasicTCPTest) ... ok
testRecv (test.test_socket.BasicTCPTest) ... ok
testRecvFrom (test.test_socket.BasicTCPTest) ... ok
testSendAll (test.test_socket.BasicTCPTest) ... ok
testShutdown (test.test_socket.BasicTCPTest) ... ok
testClose (test.test_socket.TCPCloserTest) ... Alarm clock

$ echo $?
142

Of course my installation has an issue (which I'm trying to identify), but the test suite should not crash on a failure of individual test. I believe this is related to Issue1326841 in that the test author forgot to install the signal handler, or maybe was expecting the behavior Paul Rubin suggested in said bug.

----------
components: Tests
messages: 180993
nosy: ddvento at ucar.edu
priority: normal
severity: normal
status: open
title: test_socket crashes the whole test suite
versions: Python 2.7

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

From report at bugs.python.org  Thu Jan 31 00:10:20 2013
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 30 Jan 2013 23:10:20 +0000
Subject: [New-bugs-announce] [issue17086] backport cross-build patches to
	the 2.7 branch
Message-ID: <1359587420.86.0.11365762234.issue17086@psf.upfronthosting.co.za>


New submission from Matthias Klose:

I would like to check in a backport of the cross build patches on Thu or Fri, so that these can be checked for the upcoming 2.7.4 release.  The backport was made using the current state of the cross build support on the 3.3 branch.

The patch is tested with native builds on linux, and a cross build targeting arm-linux-gnueabihf.

----------
assignee: doko
files: cross-2.7.diff
keywords: patch
messages: 180998
nosy: benjamin.peterson, doko
priority: normal
severity: normal
status: open
title: backport cross-build patches to the 2.7 branch
versions: Python 2.7
Added file: http://bugs.python.org/file28914/cross-2.7.diff

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

From report at bugs.python.org  Thu Jan 31 00:53:02 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 30 Jan 2013 23:53:02 +0000
Subject: [New-bugs-announce] [issue17087] Improve the repr for regular
	expression match objects
Message-ID: <1359589982.45.0.929656950631.issue17087@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Experience teaching Python has shown that people have a hard time learning to work with match objects.  A contributing cause is the opaque repr:

    >>> import re
    >>> s = 'On 3/14/2013, Python celebrate Pi day.'
    >>> mo = re.search(r'\d+/\d+/\d+', s)
    >>> mo
    <_sre.SRE_Match object at 0x100456100>

They could explore the match object with dir() and help() and the matchobject methods and attributes:

    >>> dir(mo)
    ['__class__', '__copy__', '__deepcopy__', ...
     'end', 'endpos', 'expand', 'group', ... ]
     
    >>> mo.start()
    3
    >>> mo.end()
    12
    >>> mo.group(0)
    '3/14/2013'

However, this gets old when experimenting with alternative regular expressions.  A better solution is to improve the repr:

    >>> re.search(r'\d+/\d+/\d+', s)
    <SRE Match object: start=3, stop=12, group(0)='3/14/2013'>

This would make the regular expression module much easier to work with.

----------
components: Library (Lib)
messages: 180999
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Improve the repr for regular expression match objects
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Jan 31 03:35:07 2013
From: report at bugs.python.org (Silverback Networks)
Date: Thu, 31 Jan 2013 02:35:07 +0000
Subject: [New-bugs-announce] [issue17088] ElementTree incorrectly refuses to
	write attributes	without namespaces when default_namespace is used
Message-ID: <1359599707.26.0.771342463799.issue17088@psf.upfronthosting.co.za>


New submission from Silverback Networks:

ET reads a default-namespaced (xmnls="whatever") file correctly but won't write it back out.

The error given is:
ValueError: cannot use non-qualified names with default_namespace option

The XML reference is reasonably clear on this:
http://www.w3.org/TR/REC-xml-names/#defaulting
"Default namespace declarations do not apply directly to attribute names;"
"The namespace name for an unprefixed attribute name always has no value."

Therefore, it is not an error to write non-qualified _attribute_ names with a default namespace; they're just considered un-namespaced anyway. The trivial case where a file is read in with a default namespace and written out with the same one should make it obvious:

from xml.etree.ElementTree import *
register_namespace('svg', 'http://www.w3.org/2000/svg')
svg = ElementTree(XML("""
<svg width="12cm" height="4cm" viewBox="0 0 1200 400" xmlns="http://www.w3.org/2000/svg" version="1.1">
<rect x="1" y="1" width="1198" height="398" fill="none" stroke="blue" stroke-width="2" />
</svg>
"""))
svg.write('simple_new.svg',encoding='UTF-8',default_namespace='svg')

Yet this will fail with the error above. By leaving off default_namespace, every element is pointlessly prefixed by 'svg:' in the resulting file, but it does work.

----------
components: XML
messages: 181005
nosy: silverbacknet
priority: normal
severity: normal
status: open
title: ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jan 31 11:01:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 31 Jan 2013 10:01:19 +0000
Subject: [New-bugs-announce] [issue17089] Expat parser parses strings only
	when XML encoding is	UTF-8
Message-ID: <1359626479.25.0.87229024986.issue17089@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

xmlparser.Parse() works with string data only if XML encoding is utf-8 (or ascii). Examples:

>>> import xml.parsers.expat
>>> parser = xml.parsers.expat.ParserCreate()
>>> content = []
>>> parser.CharacterDataHandler = content.append
>>> parser.Parse("<?xml version='1.0' encoding='utf-8'?><tag>\xb5</tag>")
1
>>> content
['?']
>>> parser = xml.parsers.expat.ParserCreate()
>>> content = []
>>> parser.CharacterDataHandler = content.append
>>> parser.Parse("<?xml version='1.0' encoding='iso8859'?><tag>\xb5</tag>")
1
>>> content
['??']
>>> parser = xml.parsers.expat.ParserCreate()
>>> content = []
>>> parser.CharacterDataHandler = content.append
>>> parser.Parse("<?xml version='1.0' encoding='utf-16'?><tag>\xb5</tag>")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
xml.parsers.expat.ExpatError: encoding specified in XML declaration is incorrect: line 1, column 30

This affects all other modules which works with XML: xml.sax, xml.dom.minidom, xml.dom.pulldom, xml.etree.ElementTree.

Here is a patch which fixes parsing string data with non-UTF-8 XML.

----------
assignee: serhiy.storchaka
components: Extension Modules, Unicode, XML
files: pyexpat_parse_str.patch
keywords: patch
messages: 181014
nosy: ezio.melotti, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Expat parser parses strings only when XML encoding is UTF-8
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28916/pyexpat_parse_str.patch

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

From report at bugs.python.org  Thu Jan 31 16:28:27 2013
From: report at bugs.python.org (Christoph Rauch)
Date: Thu, 31 Jan 2013 15:28:27 +0000
Subject: [New-bugs-announce] [issue17090] io.TextIOWrapper does not handle
	UTF-8 encoded streams	correctly
Message-ID: <1359646107.71.0.993136506568.issue17090@psf.upfronthosting.co.za>


New submission from Christoph Rauch:

I have uncovered a strange behavior in io.TextIOWrapper which I think is a bug.

#!/usr/bin/env python
# encoding: utf-8

import csv 
import io
                                                                                                                                                                                                              
raw_file = io.FileIO('utf-8-encoded.csv', 'rb')
stream = io.BufferedReader(raw_file)
stream = io.TextIOWrapper(stream, encoding="UTF-8")
reader = csv.reader(stream, delimiter=";")

cells = 0 

for row in reader:
    # Cells should contain 4 Unicode characters.
    assert all([len(cell.decode('utf-8')) == 4 for cell in row]), row 
    cells += len(row)

assert cells == 210, cells

This produces a not very useful:

Traceback (most recent call last):
  File "utf8-textio-test.py", line 15, in <module>
    for row in reader:
UnicodeEncodeError: 'ascii' codec can't encode characters in position 1-4: ordinal not in range(128)

The only way to let it *not* crash is to set encoding to ascii and errors to ignore, but this clears out all the characters with ord>128, clearly not useful as well, so I hope this behavior is not intended.

I appended a file with which to test this problem.

----------
components: IO
files: utf-8-encoded.csv
messages: 181028
nosy: Christoph.Rauch
priority: normal
severity: normal
status: open
title: io.TextIOWrapper does not handle UTF-8 encoded streams correctly
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file28922/utf-8-encoded.csv

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

From report at bugs.python.org  Thu Jan 31 17:58:07 2013
From: report at bugs.python.org (Armin Rigo)
Date: Thu, 31 Jan 2013 16:58:07 +0000
Subject: [New-bugs-announce] [issue17091] thread.lock.acquire docstring bug
Message-ID: <1359651487.53.0.770851412418.issue17091@psf.upfronthosting.co.za>


New submission from Armin Rigo:

The docstring of thread.lock.acquire() (or _thread on Python 3) is bogus: it says that if called without argument, the return value is None; it is only if called with a "blocking" argument that it returns True or False.  But since a long time it was always returning a boolean, never None.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 181035
nosy: arigo, docs at python
priority: normal
severity: normal
status: open
title: thread.lock.acquire docstring bug
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Thu Jan 31 18:12:52 2013
From: report at bugs.python.org (ddvento@ucar.edu)
Date: Thu, 31 Jan 2013 17:12:52 +0000
Subject: [New-bugs-announce] [issue17092] Disable TIPC in configure
Message-ID: <1359652372.04.0.314648330864.issue17092@psf.upfronthosting.co.za>


New submission from ddvento at ucar.edu:

This is related to Issue17085 and Issue1646

My system is a cluster Red Hat Enterprise Linux Server release 6.2 (Santiago) and it happens to have /usr/include/linux/tipc.h but probably tipc disabled in the kernel for some reasons which I ignore. There is little interest and no time from the sysadministrators to investigate TIPC, or to remove unneeded files or packages.

When I configure and build Python 2.7.3, it seems to  build correctly. However the test suite crashes as described in Issue17085.

Therefore, I want to rebuild Python 2.7.3 with TIPC disabled. Unfortunately, configure seems to ignore all of the followings:

./configure --without-tipc
./configure --without-TIPC
HAVE_LINUX_TIPC_H=0 ./configure
HAVE_LINUX_TIPC_H=0 ./configure HAVE_LINUX_TIPC_H=0

(for the record, my other configure options are --enable-shared --with-system-expat --prefix=my-path)

I also tried to manually editing config.status as follows:

--- config.status.orig  2013-01-31 09:24:04.109311726 -0700
+++ config.status       2013-01-31 09:28:28.397660288 -0700
@@ -854,7 +854,7 @@
 D["HAVE_SYS_RESOURCE_H"]=" 1"
 D["HAVE_NETPACKET_PACKET_H"]=" 1"
 D["HAVE_SYSEXITS_H"]=" 1"
-D["HAVE_LINUX_TIPC_H"]=" 1"
+D["HAVE_LINUX_TIPC_H"]=" 0"
 D["HAVE_SPAWN_H"]=" 1"
 D["HAVE_DIRENT_H"]=" 1"
 D["HAVE_TERM_H"]=" 1"

then run it and check that pyconfig.h has #define HAVE_LINUX_TIPC_H 0 (which it did). Running make and make test after this, produces exactly the same issue as described in Issue17085.

Is there a way to force configure to ignore TIPC?

----------
components: Build
messages: 181037
nosy: ddvento at ucar.edu
priority: normal
severity: normal
status: open
title: Disable TIPC in configure
versions: Python 2.7

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

From report at bugs.python.org  Thu Jan 31 22:06:41 2013
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 31 Jan 2013 21:06:41 +0000
Subject: [New-bugs-announce] [issue17093] Make importlib.abc more
	inheritance-friendly
Message-ID: <1359666401.55.0.375165619272.issue17093@psf.upfronthosting.co.za>


New submission from Brett Cannon:

ABCs, even though they are almost always at the bottom of an inheritance hierarchy, should still do the right thing in the face of being in the middle of an MRO. That means that they should call super() as appropriate. So for methods that return a value, blindly call super(). For methods that do not necessarily return anything (e.g. invalidate_caches()), check if super() as the method and it is callable and if that is true then make the super() call.

This is not backwards-compatible as it is new semantics people will rely on, but neither is it a bug but a bad design decision on my part.

----------
components: Library (Lib)
keywords: easy
messages: 181044
nosy: brett.cannon
priority: low
severity: normal
stage: test needed
status: open
title: Make importlib.abc more inheritance-friendly
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Jan 31 22:39:23 2013
From: report at bugs.python.org (Stefan Ring)
Date: Thu, 31 Jan 2013 21:39:23 +0000
Subject: [New-bugs-announce] [issue17094] sys._current_frames() reports too
	many/wrong stack frames
Message-ID: <1359668363.58.0.777154629349.issue17094@psf.upfronthosting.co.za>


New submission from Stefan Ring:

After a fork, the list of thread states contains all the threads from before. It is especially unfortunate that, at least for me, it usually happens that threads created in the forked process reuse the same thread ids, and sys._current_frames will then return wrong stack frames for existing threads because the old entries occur towards the tail of the linked list and overwrite the earlier, correct ones, in _PyThread_CurrentFrames.

The attached patch is certainly not the most complete solution, but it solves my problem.

With Python 2.7.3 I get:

Exception in thread Thread-6:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/threading.py", line 551, in __bootstrap_inner
    self.run()
  File "/usr/lib64/python2.7/threading.py", line 504, in run
    self.__target(*self.__args, **self.__kwargs)
  File "test-fork-frames.py", line 24, in do_verify
    assert frame_from_sys is real_frame
AssertionError

With my patch applied, it passes silently. I can reproduce this on CentOS 6.3 x86_64 as well as Fedora 18 x86_64.

----------
components: Interpreter Core
files: current-frames-cleanup.patch
keywords: patch
messages: 181045
nosy: Ringding
priority: normal
severity: normal
status: open
title: sys._current_frames() reports too many/wrong stack frames
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file28924/current-frames-cleanup.patch

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

From report at bugs.python.org  Thu Jan 31 22:54:56 2013
From: report at bugs.python.org (Thomas Wouters)
Date: Thu, 31 Jan 2013 21:54:56 +0000
Subject: [New-bugs-announce] [issue17095] Modules/Setup *shared* support
	broken
Message-ID: <1359669296.59.0.227426586133.issue17095@psf.upfronthosting.co.za>


New submission from Thomas Wouters:

At some point (probably in 3.2) the support for shared modules built using Modules/Setup was broken, for two reasons:

 - Python no longer considers 'foomodule.so' when looking for a module called 'foo', but Modules/makesetup still appends 'module.so' for a 'foo' module.

 - Python no longer considers Modules/ to be the exec_prefix (and instead uses what was loaded from the build-info .txt written by setup.py) but the build process still leaves these Modules/Setup-built shared modules in the Modules directory (and it doesn't know about the directory setup.py will make, so it can't really do anything else.)

This patch fixes both problems, by making Modules/makesetup name shared library modules 'foo.so' and by adding the Modules subdirectory to sys.path (after the setup.py-provided directory) when running from the build directory. (The existing build process has no problem _installing_ the Modules/Setup-built extension modules, it's just Python that doesn't know how to find them.)

----------
components: Build
files: getpath.diff
keywords: patch
messages: 181048
nosy: twouters
priority: normal
severity: normal
status: open
title: Modules/Setup *shared* support broken
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28928/getpath.diff

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