From report at bugs.python.org  Tue Oct  1 09:05:14 2013
From: report at bugs.python.org (Andre M. Descombes)
Date: Tue, 01 Oct 2013 07:05:14 +0000
Subject: [New-bugs-announce] [issue19135] Check out my profile on LinkedIn
Message-ID: <966608683.31805291.1380611111380.JavaMail.app@ela4-bed84.prod>


New submission from Andre M. Descombes:

LinkedIn
------------

I'd like to include you in my network to share updates and stay in touch.

- Andre

Andre Descombes
DQM at Coheris
Paris Area, France

Confirm that you know Andre Descombes:
https://www.linkedin.com/e/-3qcne3-hm8s7jcj-8/isd/16969775744/B54_m0Jy/?hs=false&tok=0vJyT35US96RY1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-3qcne3-hm8s7jcj-8/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I5638997180_1/?hs=false&tok=2uJc6djm696RY1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

----------
messages: 198751
nosy: amdescombes
priority: normal
severity: normal
status: open
title: Check out my profile on LinkedIn

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

From report at bugs.python.org  Tue Oct  1 09:14:23 2013
From: report at bugs.python.org (Graham Wideman)
Date: Tue, 01 Oct 2013 07:14:23 +0000
Subject: [New-bugs-announce] [issue19136] CSV, builtin open(),
	newline arg. Docs broken again.
Message-ID: <1380611663.89.0.558350750014.issue19136@psf.upfronthosting.co.za>


New submission from Graham Wideman:

The docs appear to be incorrect for CSV at: http://docs.python.org/3.3/library/csv.html.

Per issue http://bugs.python.org/issue7198 , there's a long history of contention between os.open and csv.writer, in which, on Windows, the default result is an unwanted additional '\r'. That was 'fixed' by using the newline='' argument to open(). 

This is reflected in the docs at the above link:

with open('eggs.csv', 'w', newline='') as csvfile:
    spamwriter = csv.writer(csvfile, delimiter=...)

However, in python 3.3.2 use of the newline argument returns: "TypeError: 'newline' is an invalid keyword argument for this function."

In brief testing, it appears that a correct result can be obtain by calling open as follows:

with open(somepath, 'wb') as writerfile: 
    writer = csv.writer(writerfile, delimiter=...)

Note: binary mode, not text as previously needed and currently documented.

----------
assignee: docs at python
components: Documentation
messages: 198752
nosy: docs at python, gwideman
priority: normal
severity: normal
status: open
title: CSV, builtin open(), newline arg. Docs broken again.
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Oct  1 16:55:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 01 Oct 2013 14:55:31 +0000
Subject: [New-bugs-announce] [issue19137] pprint wrongly format set and
	frozenset subclasses
Message-ID: <1380639331.5.0.0634997889933.issue19137@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Example:

>>> import pprint
>>> class S(set): pass
... 
>>> S('abc')
S({'a', 'b', 'c'})
>>> pprint.pprint(S('abc'))
S({'a', 'b', 'c'})
>>> pprint.pprint(S('abc'), width=1)
{'a',
 'b',
 'c'}

And same for frozenset.

Here is a patch which fixes this issue. With a patch:

>>> pprint.pprint(S('abc'), width=1)
S({'a',
   'b',
   'c'})

----------
files: pprint_set_subclass.patch
keywords: patch
messages: 198788
nosy: fdrake, pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: pprint wrongly format set and frozenset subclasses
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31934/pprint_set_subclass.patch

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

From report at bugs.python.org  Tue Oct  1 17:54:51 2013
From: report at bugs.python.org (John Murphy)
Date: Tue, 01 Oct 2013 15:54:51 +0000
Subject: [New-bugs-announce] [issue19138] doctest.IGNORE_EXCEPTION_DETAIL
	doesn't match when no	detail exists
Message-ID: <1380642891.76.0.189533758192.issue19138@psf.upfronthosting.co.za>


New submission from John Murphy:

The doctest.IGNORE_EXCEPTION_DETAIL optionflag does not seem to have the
desired behavior when the exception does not provide a message, due to the
regular expressions in doctest.DocTestRunner.__run expecting a colon in the
second group::

                elif self.optionflags & IGNORE_EXCEPTION_DETAIL:
                    m1 = re.match(r'(?:[^:]*\.)?([^:]*:)', example.exc_msg)
                    m2 = re.match(r'(?:[^:]*\.)?([^:]*:)', exc_msg)
                    if m1 and m2 and check(m1.group(1), m2.group(1),
                                           self.optionflags):
                        outcome = SUCCESS

Normally this wouldn't matter, as there's no need to ignore the exception
detail if there is no detail to normalize, but since
http://bugs.python.org/issue7490 it looks like the blessed method of
normalizing Python 2 and 3 exceptions in doctests is to use
IGNORE_EXCEPTION_DETAIL.  This doesn't work for any exceptions which do
not have a message.

Example::

    >>> def f(x):
    ...     r'''
    ...     >>> from http.client import HTTPException
    ...     >>> raise HTTPException() #doctest: +IGNORE_EXCEPTION_DETAIL
    ...     Traceback (most recent call last):
    ...     foo.bar.HTTPException
    ...     '''
    >>> test = doctest.DocTestFinder().find(f)[0]
    >>> doctest.DocTestRunner(verbose=True).run(test)
    Failed example:
        raise HTTPException() #doctest: +IGNORE_EXCEPTION_DETAIL
    Expected:
        Traceback (most recent call last):
        foo.bar.HTTPException
    Got:
        Traceback (most recent call last):
        ...
        http.client.HTTPException

I've attached a test and a very naive fix of the regular expression.

----------
components: Tests
files: exception_normalize.patch
keywords: patch
messages: 198792
nosy: jamur2
priority: normal
severity: normal
status: open
title: doctest.IGNORE_EXCEPTION_DETAIL doesn't match when no detail exists
type: behavior
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file31936/exception_normalize.patch

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

From report at bugs.python.org  Tue Oct  1 19:58:33 2013
From: report at bugs.python.org (Paul Moore)
Date: Tue, 01 Oct 2013 17:58:33 +0000
Subject: [New-bugs-announce] [issue19139] In venv,
	__VENV_NAME__ is the prompt, not the name
Message-ID: <1380650313.1.0.884499965527.issue19139@psf.upfronthosting.co.za>


New submission from Paul Moore:

The documentation for venv states that __VENV_NAME__ in scripts is replaced by the name of the virtualenv. In fact, it is replaced by context.prompt, which is the prompt, rather than the name.

The various activate scripts are not consistent with this behaviour. Most seem to expect a prompt, but activate.csh does not.

I would prefer __VENV_NAME__ to actually *be* the name, and either have an extra substitution variable __VENV_PROMPT__ or just leave it to the scripts themselves to format the prompt using the name.

I could supply a patch (it's not hard) but would need agreement on the right approach.

----------
assignee: vinay.sajip
components: Library (Lib)
messages: 198795
nosy: pmoore, vinay.sajip
priority: normal
severity: normal
status: open
title: In venv, __VENV_NAME__ is the prompt, not the name
versions: Python 3.4

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

From report at bugs.python.org  Tue Oct  1 22:50:06 2013
From: report at bugs.python.org (Yann Kaiser)
Date: Tue, 01 Oct 2013 20:50:06 +0000
Subject: [New-bugs-announce] [issue19140] inspect.Signature.bind()
	inaccuracies
Message-ID: <1380660606.62.0.855384003289.issue19140@psf.upfronthosting.co.za>


New submission from Yann Kaiser:

A pair of inconsistencies I've found using Signature.bind:

(<a>=0).bind() -*> TypeError
Letting the default value of a positional-only parameter be used raises a TypeError with message that 'a' was passed by name.

(a, *args).bind(a=0, args=1) -> BoundArguments({'a': 0, 'args': 1})
Should positional arguments not be enough for bind() to reach the parameter before *args, bind() will process the *args parameter while looking for named arguments, and eventually bind the *args parameter to any named argument for it, instead of leaving that named argument for **kwargs or erroring out.

I've attached a patch that tests and fixes both issues.

I've taken the liberty of extending test_inspect.TestSignatureBind.test_signature_bind_positional_only as it already did all the setup needed but overlooked to check the condition where a defaulted positional-only parameter is left out.

----------
components: Library (Lib)
files: sig_bind_posodefa_varargs.patch
keywords: patch
messages: 198806
nosy: epsy
priority: normal
severity: normal
status: open
title: inspect.Signature.bind() inaccuracies
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31940/sig_bind_posodefa_varargs.patch

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

From report at bugs.python.org  Wed Oct  2 01:16:49 2013
From: report at bugs.python.org (Graham Wideman)
Date: Tue, 01 Oct 2013 23:16:49 +0000
Subject: [New-bugs-announce] [issue19141] Windows Launcher fails to respect
	PATH
Message-ID: <1380669409.4.0.896421919729.issue19141@psf.upfronthosting.co.za>


New submission from Graham Wideman:

Python Launcher for Windows provides some important value for Windows users, but its ability to invoke python versions not on the PATH is a problem.

py.exe chooses a version of Python to invoke, in more or less this order of decreasing priority; it is the *last* one that occurs by default in a new install of python 3.3.x:

1. Shebang line in myscript.py

2. py.exe -n argument (n can be 2, 3, 3.2 etc). Launcher chooses the latest installed version so specified.

3. PY_PYTHON environment variable

4. py.ini in C:\WINDOWS or user's %LOCALAPPDATA% directory

5. Launcher hunts through registry for ALL previously installed pythons, and picks the latest version in the 2.x series. DEFAULT.

The first issue to note is that, to my knowledge, the exact precedence order is not documented... it would greatly help if this were done.

That said, the focus in this report is case 5, which as noted is the default behavior when python 3.3.2 is installed (and py.exe invoked with scripts having no launcher-aware shebang line).

In case 5, py.exe completely ignores the PATH environment variable. So, whereas PATH is used to find py.exe, or when the user invokes 'python' on the command line, py.exe ignores PATH and launches a version of python that is not necessarily in the PATH.

In case 2 where the user supplies a value for 'n', finding a non-PATH version of python is excusable on the basis that the user deliberately requests a version.

However, in case 5, the user is not invoking py explicitly, and is not necessarily aware of py's algorithm for finding all installed versions. The user might reasonably expect that invoking a script or double clicking it would just invoke 'python' the same as the 'python' command, using PATH.

In particular, if the user understands how PATH works (as reviewed in the docs here: http://docs.python.org/3/using/windows.html#finding-the-python-executable), then upon installing 3.3.x, he or she might explicitly *remove* python 2.x from PATH in the expectation that this will disable python 2.x. It is surprising and potentially harmful that py.exe does not abide by that choice.

A potential improvement is to interpose an item '4.5' in the above list, in which py.exe looks for a version of python on the PATH before falling back to searching for latest 2.x python ever installed.

(It is not clear that py.exe should *ever* fallback to just picking the latest 2.x in the registry (item 5). It is conceivable that a user may have configured one of those pythons to do something destructive or insecure on startup, and it will be a great surprise if py.exe "randomly" invokes it just because it has the highest version number.)

----------
components: Windows
messages: 198812
nosy: gwideman
priority: normal
severity: normal
status: open
title: Windows Launcher fails to respect PATH
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Oct  2 01:41:38 2013
From: report at bugs.python.org (Trevor Bowen)
Date: Tue, 01 Oct 2013 23:41:38 +0000
Subject: [New-bugs-announce] [issue19142] Cross-compile fails trying to
	execute foreign pgen on	build host
Message-ID: <1380670898.69.0.308819053325.issue19142@psf.upfronthosting.co.za>


New submission from Trevor Bowen:

FWIW, I'm using a Freescale cross-compile tool-chain on a Linux x86-64 build host, although I have duplicated the cross-compile error on an x86 Ubunutu 10.04 build host.

Steps to reproduce:

$ wget http://www.python.org/ftp/python/2.7.5/Python-2.7.5.tar.bz2
$ tar -jxf Python-2.7.5.tar.bz2
$ cd Python-2.7.5
$ export PATH="/opt/freescale/usr/local/gcc-4.3.74-eglibc-2.8.74-dp-2/powerpc-none-linux-gnuspe/bin:${PATH}"
# For info only:
$ ls -l /opt/freescale/usr/local/gcc-4.3.74-eglibc-2.8.74-dp-2/powerpc-none-linux-gnuspe/bin 
total 10472
-rwxrwxrwx 1 root root  590485 Mar  5  2012 powerpc-none-linux-gnuspe-addr2line
-rwxrwxrwx 1 root root  614647 Mar  5  2012 powerpc-none-linux-gnuspe-ar
-rwxrwxrwx 1 root root  897161 Mar  5  2012 powerpc-none-linux-gnuspe-as
-rwxrwxrwx 1 root root  235382 Mar  5  2012 powerpc-none-linux-gnuspe-c++
-rwxrwxrwx 1 root root  589227 Mar  5  2012 powerpc-none-linux-gnuspe-c++filt
-rwxrwxrwx 1 root root  234277 Mar  5  2012 powerpc-none-linux-gnuspe-cpp
-rwxrwxrwx 1 root root    8503 Mar  5  2012 powerpc-none-linux-gnuspe-embedspu
-rwxrwxrwx 1 root root  235382 Mar  5  2012 powerpc-none-linux-gnuspe-g++
-rwxrwxrwx 1 root root  233126 Mar  5  2012 powerpc-none-linux-gnuspe-gcc
-rwxrwxrwx 1 root root  233126 Mar  5  2012 powerpc-none-linux-gnuspe-gcc-4.3.2
-rwxrwxrwx 1 root root   16512 Mar  5  2012 powerpc-none-linux-gnuspe-gccbug
-rwxrwxrwx 1 root root   28017 Mar  5  2012 powerpc-none-linux-gnuspe-gcov
-rwxrwxrwx 1 root root  655127 Mar  5  2012 powerpc-none-linux-gnuspe-gprof
-rwxrwxrwx 1 root root 1036372 Mar  5  2012 powerpc-none-linux-gnuspe-ld
-rwxrwxrwx 1 root root  603678 Mar  5  2012 powerpc-none-linux-gnuspe-nm
-rwxrwxrwx 1 root root  750617 Mar  5  2012 powerpc-none-linux-gnuspe-objcopy
-rwxrwxrwx 1 root root  895336 Mar  5  2012 powerpc-none-linux-gnuspe-objdump
-rwxrwxrwx 1 root root  614647 Mar  5  2012 powerpc-none-linux-gnuspe-ranlib
-rwxrwxrwx 1 root root  264063 Mar  5  2012 powerpc-none-linux-gnuspe-readelf
-rwxrwxrwx 1 root root  593901 Mar  5  2012 powerpc-none-linux-gnuspe-size
-rwxrwxrwx 1 root root  591853 Mar  5  2012 powerpc-none-linux-gnuspe-strings
-rwxrwxrwx 1 root root  750617 Mar  5  2012 powerpc-none-linux-gnuspe-strip
$ ./configure --host=powerpc-none-linux-gnuspe \
    --build=i586-linux-gnu --prefix=/          \
    --disable-ipv6 ac_cv_file__dev_ptmx=no     \
    ac_cv_file__dev_ptc=no
$ make

Make fails because the foreign (powerpc, in this case) pgen binary is used to build the $(GRAMMAR_H).  Instead, a native version of the python interpreter (preferrable) and pgen (essential) need to be built first using the host's toolchain.  Then, these tools can be used to build the full foreign suite.

FWIW, This 2 step process is well documented here:

http://randomsplat.com/id5-cross-compiling-python-for-embedded-linux.html

However, the cross-compile fixes from Issue17086 may have helped this process.  (It's hard for me to determine how to take advantage of these updates.)  Certainly, they changed the above process dramatically.

Incidentally, Python 3.3.2 exhibits almost the exact same build error, if not the same.

Build log on an x86-64 host for Python-2.7.5 for a PowerPC-linux target is attached.

Tail of log:

make Parser/pgen
make[1]: Entering directory `/home/user/Python-2.7.5'
powerpc-none-linux-gnuspe-gcc -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o Python/mysnprintf.o Python/mysnprintf.c
powerpc-none-linux-gnuspe-gcc -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o Python/pyctype.o Python/pyctype.c
powerpc-none-linux-gnuspe-gcc -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o Parser/tokenizer_pgen.o Parser/tokenizer_pgen.c
powerpc-none-linux-gnuspe-gcc -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o Parser/printgrammar.o Parser/printgrammar.c
powerpc-none-linux-gnuspe-gcc -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o Parser/pgenmain.o Parser/pgenmain.c
powerpc-none-linux-gnuspe-gcc -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/mysnprintf.o Python/pyctype.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/pgenmain.o -lpthread -ldl  -lpthread -lutil -o Parser/pgen
make[1]: Leaving directory `/home/user/Python-2.7.5'
Parser/pgen ./Grammar/Grammar Include/graminit.h Python/graminit.c
Parser/pgen: Parser/pgen: cannot execute binary file
make: *** [Include/graminit.h] Error 126
make Parser/pgen
make[1]: Entering directory `/home/user/Python-2.7.5'
make[1]: `Parser/pgen' is up to date.
make[1]: Leaving directory `/home/user/Python-2.7.5'
Parser/pgen ./Grammar/Grammar Include/graminit.h Python/graminit.c
Parser/pgen: Parser/pgen: cannot execute binary file
make: *** [Include/graminit.h] Error 126

----------
components: Cross-Build
files: cross-compile.log
messages: 198813
nosy: Trevor.Bowen
priority: normal
severity: normal
status: open
title: Cross-compile fails trying to execute foreign pgen on build host
type: compile error
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file31942/cross-compile.log

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

From report at bugs.python.org  Wed Oct  2 02:50:04 2013
From: report at bugs.python.org (Tim Peters)
Date: Wed, 02 Oct 2013 00:50:04 +0000
Subject: [New-bugs-announce] [issue19143] Finding the Windows version
	getting messier
Message-ID: <1380675004.25.0.239416620624.issue19143@psf.upfronthosting.co.za>


New submission from Tim Peters:

This question:

    http://stackoverflow.com/questions/19128219/detect-windows-8-1-in-python

reports that Python is returning incorrect version info under Windows 8.1.

Alas, it appears MS is "deprecating" `GetVersionEx()`:

    http://msdn.microsoft.com/en-us/library/windows/desktop/ms724451(v=vs.85).aspx

and replacing it with a whole slew of annoying "yes or no?" functions:

    http://msdn.microsoft.com/en-us/library/windows/desktop/dn424972(v=vs.85).aspx

Heh ;-)

----------
components: Interpreter Core, Windows
messages: 198814
nosy: tim.peters
priority: normal
severity: normal
status: open
title: Finding the Windows version getting messier
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Oct  2 13:53:20 2013
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 02 Oct 2013 11:53:20 +0000
Subject: [New-bugs-announce] [issue19144] test_inspect: failure without
	threads
Message-ID: <1380714800.29.0.936969806599.issue19144@psf.upfronthosting.co.za>


New submission from Stefan Krah:

On the Fedora 16 buildbot:

======================================================================
ERROR: test_qualname_source (test.test_inspect.TestMain)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/test/test_inspect.py", line 2414, in test_qualname_source
    module = importlib.import_module('concurrent.futures')
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/importlib/__init__.py", line 95, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1613, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1594, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1561, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 607, in _check_name_wrapper
  File "<frozen importlib._bootstrap>", line 1056, in load_module
  File "<frozen importlib._bootstrap>", line 926, in load_module
  File "<frozen importlib._bootstrap>", line 274, in _call_with_frames_removed
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/concurrent/futures/__init__.py", line 8, in <module>
    from concurrent.futures._base import (FIRST_COMPLETED,
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/concurrent/futures/_base.py", line 8, in <module>
    import threading
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/threading.py", line 4, in <module>
    import _thread
ImportError: No module named '_thread'

----------
messages: 198828
nosy: skrah
priority: normal
severity: normal
status: open
title: test_inspect: failure without threads

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

From report at bugs.python.org  Wed Oct  2 17:23:16 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 02 Oct 2013 15:23:16 +0000
Subject: [New-bugs-announce] [issue19145] Inconsistent behaviour in
	itertools.repeat when using	negative times
Message-ID: <1380727396.47.0.412229295257.issue19145@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

>>> from itertools import repeat
>>> repeat(2, -10).__length_hint__()
0
>>> repeat(2, times=-10).__length_hint__()
18446744073709551606
>>> repeat(2, times=-10)
repeat(2, -10)
>>> repeat(2, -10)
repeat(2, 0)

Hereby, I attached two alternatives of patch to make the behaviour consistent.

The first one makes the negative number parameter/keyword ALWAYS means endless.

----------
components: Library (Lib)
files: fix_itertools_repeat_negative_number_means_endless.patch
keywords: patch
messages: 198849
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Inconsistent behaviour in itertools.repeat when using negative times
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31943/fix_itertools_repeat_negative_number_means_endless.patch

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

From report at bugs.python.org  Wed Oct  2 19:03:01 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 02 Oct 2013 17:03:01 +0000
Subject: [New-bugs-announce] [issue19146] Improvements to traceback module
Message-ID: <1380733381.79.0.0175162036016.issue19146@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

The traceback module is driving me nuts.  It has some handy helpers to extract info about a traceback or a full stack without formatting them, but (a) these are _internal, and (b) they don't return the frame object as part of the information, so code that wants to do additional stuff (e.g. print the values of local variables) cannot use them. (I guess in a sense the two problems cancel each other out. :-)

Here's a proposed fix.  (I know it is lacking tests.)

It adds extract_tb_ex() and extract_stack_ex() functions that return a list of 5-tuples filename, line number, function name, text, frame).

I'm also reworking the lowest-level internal function, _extract_tb_or_stack_iter(), to take an iterator instead of a starting point and a function to get the info and the next starting point.  The old design feels unpythonic to me -- the task at hand so clearly feels like it should wrap an iterator!

Finally, I'm adding some important info to a few docstrings: when the limit clips the number of frames, you get the *oldest* frames from a traceback, but the *newest* frames from a stack. That makes sense when you think about it, but I still think it's worth mentioning.

Feedback?

----------
messages: 198852
nosy: akuchling, benjamin.peterson, gvanrossum
priority: normal
severity: normal
status: open
title: Improvements to traceback module

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

From report at bugs.python.org  Wed Oct  2 19:17:35 2013
From: report at bugs.python.org (Andrew Parker)
Date: Wed, 02 Oct 2013 17:17:35 +0000
Subject: [New-bugs-announce] [issue19147] pydoc3 fcntl.flock documentation
	gives wrong man page	section for flock
Message-ID: <1380734255.97.0.651100978858.issue19147@psf.upfronthosting.co.za>


New submission from Andrew Parker:

On my Linux system the docs for fcntl.flock gives me "man 3 flock" for more details:

    $ pydoc3 fcntl.flock
    Help on built-in function flock in fcntl:
    
    fcntl.flock = flock(...)
        flock(fd, operation)
    
        Perform the lock operation op on file descriptor fd.  See the Unix 
        manual page for flock(3) for details.  (On some systems, this function is
        emulated using fcntl().)

However, at least for Fedora 19 and RHEL 6, that should be "man 2 flock" or "See the manual page for flock(2) for details":

    $ man 3 flock | wc -l
    No manual entry for flock in section 3
    0
    $ man 2 flock | wc -l
    85

Note that http://docs.python.org/3/library/fcntl.html#fcntl.flock and http://docs.python.org/2/library/fcntl.html#fcntl.flock both have it right.

----------
assignee: docs at python
components: Documentation
messages: 198856
nosy: Andrew.Parker, docs at python
priority: normal
severity: normal
status: open
title: pydoc3 fcntl.flock documentation gives wrong man page section for flock
versions: Python 2.6, Python 2.7, Python 3.3

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

From report at bugs.python.org  Wed Oct  2 22:29:21 2013
From: report at bugs.python.org (Esa Peuha)
Date: Wed, 02 Oct 2013 20:29:21 +0000
Subject: [New-bugs-announce] [issue19148] Minor issues with Enum docs
Message-ID: <1380745761.79.0.183004061407.issue19148@psf.upfronthosting.co.za>


New submission from Esa Peuha:

I noticed a couple of issues with the Enum documentation. First, there are some markup bugs which should be fixed by the attached file. Second, I think "If the only change desired is no aliases allowed" is very bad English and should be reworded; I would go with "If you only want to disallow aliases" but maybe other people have better ideas.

----------
assignee: docs at python
components: Documentation
files: enum.diff
keywords: patch
messages: 198869
nosy: Esa.Peuha, docs at python
priority: normal
severity: normal
status: open
title: Minor issues with Enum docs
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31947/enum.diff

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

From report at bugs.python.org  Thu Oct  3 06:02:41 2013
From: report at bugs.python.org (Martin)
Date: Thu, 03 Oct 2013 04:02:41 +0000
Subject: [New-bugs-announce] [issue19149] python bug report
Message-ID: <CAB7xb6L9nt68O4=GUSibZj_U9PKXLsHyTeMMr2bs87TVM5aENg@mail.gmail.com>


New submission from Martin:

Hello! My name is Martin, a member of Free Software in Comahue National
University of Neuqu?n, Argentina. We have detected an error in the compiler
for Python 2.7 using Ubuntu 12.04: I write the code, without realizing I
leave a comment with syntax error in that line (do not put the # of
comments), compile and get error of sistaxis in that line. Fix the error
adding # to comment, I do compile again and it shows me various errors that
take over the Python compiler and I am forced to close it. Hope your
response with a possible solution to this problem, my idea is to continue
using this version of Python. Thank yo

----------
messages: 198878
nosy: Grupobetatesting
priority: normal
severity: normal
status: open
title: python bug report

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

From report at bugs.python.org  Thu Oct  3 06:04:58 2013
From: report at bugs.python.org (Martin)
Date: Thu, 03 Oct 2013 04:04:58 +0000
Subject: [New-bugs-announce] [issue19150] python bug report
Message-ID: <1380773098.03.0.70627839845.issue19150@psf.upfronthosting.co.za>


New submission from Martin:

Hello! My name is Martin, a member of Free Software in Comahue National University of Neuqu?n, Argentina. We have detected an error in the compiler for Python 2.7 using Ubuntu 12.04: I write the code, without realizing I leave a comment with syntax error in that line (do not put the # of comments), compile and get error of sistaxis in that line. Fix the error adding # to comment, I do compile again and it shows me various errors that take over the Python compiler and I am forced to close it. Hope your response with a possible solution to this problem, my idea is to continue using this version of Python. Thank yo

----------
components: IDLE
files: Captura de pantalla de 2013-10-02 23:52:10.png
messages: 198879
nosy: Grupobetatesting
priority: normal
severity: normal
status: open
title: python bug report
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file31948/Captura de pantalla de 2013-10-02 23:52:10.png

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

From report at bugs.python.org  Thu Oct  3 08:15:48 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 03 Oct 2013 06:15:48 +0000
Subject: [New-bugs-announce] [issue19151] Docstring and
	WindowsRegistryFinder wrong relative
	to	importlib._bootstrap._get_supported_file_loaders()
Message-ID: <1380780948.31.0.22137513887.issue19151@psf.upfronthosting.co.za>


New submission from Eric Snow:

Changeset 1db6553f3f8c for issue #15576 changed importlib._bootstrap._get_supported_file_loaders() to return a list of 2-tuples instead of 3-tuples.  However, the docstring for the function was not updated to reflect that.  More importantly, WindowsRegistryFinder.find_module() still expects 3-tuples.

The fix is relatively trivial (patch attached).  However, I'm not aware of any reports of problems related to what should be a very broken WindowsRegistryFinder.  So I just wanted to double-check that I haven't missed something here.  Undoubtedly the code simply hasn't gotten a lot of exposure since the patch (Aug. 2012).

----------
assignee: eric.snow
components: Interpreter Core
files: fix-get-supported-file-loaders.diff
keywords: patch
messages: 198883
nosy: brett.cannon, eric.snow
priority: normal
severity: normal
stage: commit review
status: open
title: Docstring and WindowsRegistryFinder wrong relative to importlib._bootstrap._get_supported_file_loaders()
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31951/fix-get-supported-file-loaders.diff

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

From report at bugs.python.org  Thu Oct  3 09:01:35 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 03 Oct 2013 07:01:35 +0000
Subject: [New-bugs-announce] [issue19152] ExtensionFileLoader missing
	get_filename()
Message-ID: <1380783695.34.0.941035195145.issue19152@psf.upfronthosting.co.za>


New submission from Eric Snow:

Any reason why ExtensionFileLoader does not implement get_filename()?  I'm guessing it just slipped through the cracks.  It should be there (and be registered as implementing ExecutionLoader).

----------
assignee: eric.snow
components: Interpreter Core
messages: 198886
nosy: brett.cannon, eric.snow
priority: normal
severity: normal
status: open
title: ExtensionFileLoader missing get_filename()
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Oct  3 18:36:53 2013
From: report at bugs.python.org (Rinat)
Date: Thu, 03 Oct 2013 16:36:53 +0000
Subject: [New-bugs-announce] [issue19153] Embedding into a shared library
	fails again
Message-ID: <1380818213.13.0.0445211197564.issue19153@psf.upfronthosting.co.za>


New submission from Rinat:

I have same error as here described http://bugs.python.org/issue4434

I made everythings according this article http://docs.python.org/2/extending/embedding.html#compiling-and-linking-under-unix-like-systems and more but when i try to call interpriter from C++ it fails with errors

python_support::pre_process_payment() failed
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "<hidden-path>/payments/__init__.py", line 1, in <module>
    from .factory import *
  File "<hidden-path>/payments/factory.py", line 7, in <module>
    import psycopg2
  File "/usr/local/lib/python2.7/dist-packages/psycopg2/__init__.py", line 50, in <module>
    from psycopg2._psycopg import BINARY, NUMBER, STRING, DATETIME, ROWID
ImportError: /usr/local/lib/python2.7/dist-packages/psycopg2/_psycopg.so: undefined symbol: PyExc_SystemError
Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 66, in apport_excepthook
    from apport.fileutils import likely_packaged, get_recent_crashes
  File "/usr/lib/python2.7/dist-packages/apport/__init__.py", line 1, in <module>
    from apport.report import Report
  File "/usr/lib/python2.7/dist-packages/apport/report.py", line 16, in <module>
    from xml.parsers.expat import ExpatError
  File "/usr/lib/python2.7/xml/parsers/expat.py", line 4, in <module>
    from pyexpat import *
ImportError: /usr/lib/python2.7/lib-dynload/pyexpat.so: undefined symbol: _Py_ZeroStruct

Original exception was:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "<hidden-path>/payments/__init__.py", line 1, in <module>
    from .factory import *
  File "<hidden-path>/payments/factory.py", line 7, in <module>
    import psycopg2
  File "/usr/local/lib/python2.7/dist-packages/psycopg2/__init__.py", line 50, in <module>
    from psycopg2._psycopg import BINARY, NUMBER, STRING, DATETIME, ROWID
ImportError: /usr/local/lib/python2.7/dist-packages/psycopg2/_psycopg.so: undefined symbol: PyExc_SystemError


Environment
3.2.0-54-generic-pae #82-Ubuntu (12.04)
g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Boost.Python 1.48
Python 2.7.3 (default, Sep 26 2013, 20:08:41) 
[GCC 4.6.3] on linux2

No custom builds. Every package from ubuntu repository. Psycopg2 installed by pip

Project is big so i can't to provide code

----------
components: Library (Lib)
messages: 198900
nosy: rinatous
priority: normal
severity: normal
status: open
title: Embedding into a shared library fails again
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct  3 19:12:38 2013
From: report at bugs.python.org (Florent Viard)
Date: Thu, 03 Oct 2013 17:12:38 +0000
Subject: [New-bugs-announce] [issue19154] AttributeError: 'NoneType' in
	http/client.py when using	select when file descriptor is closed.
Message-ID: <1380820358.99.0.777618727237.issue19154@psf.upfronthosting.co.za>


New submission from Florent Viard:

In Lib/http/client.py +682    (Formerly httplib)

    def fileno(self):
        return self.fp.fileno()

This function should be modified to be able to handle the case where the http request is already completed and so "fp" is closed. Ex.:
    def fileno(self):
        if self.fp:
            return self.fp.fileno()
        else:
            return -1

I encountered the issue in the following context:
while 1:
  read_list = select([req], ...)[0]
  if read_list:
    req.read(CHUNK_SIZE)
  ...

Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/nappstore/server_comm.py", line 211, in download_file
    ready = select.select([req], [], [], timeout)[0]
  File "/usr/lib/python2.7/socket.py", line 313, in fileno
    return self._sock.fileno()
  File "/usr/lib/python2.7/httplib.py", line 655, in fileno
    return self.fp.fileno()
  AttributeError: 'NoneType' object has no attribute 'fileno'

For the returned value, I'm not sure because there is currently 2 different cases for other objects returning a fileno. 
In Lib/fileinput.py:
  -1 is returned in case of ValueError (no fileno value as fp was closed)
but in Lib/socket.py:
  ValueError is raised in that case and default value for fileno for a socket is None

----------
components: Library (Lib)
messages: 198902
nosy: fviard
priority: normal
severity: normal
status: open
title: AttributeError: 'NoneType' in http/client.py when using select when file descriptor is closed.
type: crash
versions: Python 2.6, 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/issue19154>
_______________________________________

From report at bugs.python.org  Thu Oct  3 22:00:38 2013
From: report at bugs.python.org (Peng Yu)
Date: Thu, 03 Oct 2013 20:00:38 +0000
Subject: [New-bugs-announce] [issue19155] Display stack info with color in
	pdb (the "w" command)
Message-ID: <1380830438.89.0.93033218412.issue19155@psf.upfronthosting.co.za>


New submission from Peng Yu:

Currently, the "w" command does not show the stack info in color. I think that it might be visually helpful to add some color to emphasize the current frame, etc. May I suggest to add this feature to pdb? Thanks.

----------
messages: 198916
nosy: Peng.Yu
priority: normal
severity: normal
status: open
title: Display stack info with color in pdb (the "w" command)
type: enhancement

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

From report at bugs.python.org  Fri Oct  4 00:08:19 2013
From: report at bugs.python.org (CliffM)
Date: Thu, 03 Oct 2013 22:08:19 +0000
Subject: [New-bugs-announce] [issue19156] Enum helper functions test-coverage
Message-ID: <1380838099.92.0.195815500358.issue19156@psf.upfronthosting.co.za>


New submission from CliffM:

Added some tests for the _is_sunder and _is_dunder helper functions in the enum module.

----------
components: Tests
files: enum.patch
keywords: patch
messages: 198923
nosy: CliffM
priority: normal
severity: normal
status: open
title: Enum helper functions test-coverage
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31955/enum.patch

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

From report at bugs.python.org  Fri Oct  4 00:51:31 2013
From: report at bugs.python.org (Michiel)
Date: Thu, 03 Oct 2013 22:51:31 +0000
Subject: [New-bugs-announce] [issue19157] ipaddress.IPv6Network.hosts
	function omits network and	broadcast addresses
Message-ID: <1380840691.26.0.505062253334.issue19157@psf.upfronthosting.co.za>


New submission from Michiel:

(See also: http://stackoverflow.com/q/19159168/1298153. This is my first bug submission)
Contrary to IPv4, IPv6 does not have a concept of network and broadcast addresses. It looks like the same code is used to generate the hosts for both IPv4 and IPv6, resulting in the network and broadcast addresses being omitted in IPv6, even though these are valid IPv6 addresses, albeit they may have a special meaning.

Repro:

$ python3
Python 3.3.2 (default, Sep  6 2013, 09:30:10) 
[GCC 4.8.1 20130725 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ipaddress
>>> print("\n".join([str(x) for x in ipaddress.ip_network("2001:0db8::/120").hosts()]))
2001:db8::1
2001:db8::2
...
2001:db8::fe
>>> 
>>> hex(int(ipaddress.ip_address('2001:db8::fe')))
'0x20010db80000000000000000000000fe'

The v4 docs state, that the hosts() function...
"Returns an iterator over the usable hosts in the network. The usable hosts are all the IP addresses that belong to the network, except the network address itself and the network broadcast address."

Assuming hosts excludes routers, this should probably return a generator/an iterator covering all addresses in the network, apart from the very first one (all 0's after the prefix), since this is typically the subnet-router anycast address (http://tools.ietf.org/html/rfc4291#section-2.6.1).

While the top range (including the currently omitted prefix + "all 1's" address) contains reserved anycast addresses (http://tools.ietf.org/html/rfc2526), I'm not sure whether excluding them is a great idea, as in the future some of these may become valid (anycast) host addresses.

Backwards compatibility considerations:
The proposed fix would add one extra address to the ones already returned. I think this is less likely to break code, than, say, removing all the reserved anycast addresses.

Implementation options:
1. override _BaseNetwork hosts() implementation in IPv6Network
2. add an is_host_address(ip_address) method, or something along those lines, to IPv4 and IPv6Address classes, and change the hosts() function to only return addresses for which is_host_address is True. This function might be generally useful, but the implementation is likely to be slower than 1.
3. use address_exclude perhaps..

I'm sure there are many other ways to implement the fix, but I've attached a "naive" diff. I'm not sure if there's a better way to implement it that doesn't involve copying code from hosts()/__iter__ and slightly tweaking it.

With 1:
>>> print("\n".join([str(x) for x in ipaddress.ip_network("2001:0db8::/124").hosts()]))
2001:db8::1
2001:db8::2
2001:db8::3
2001:db8::4
2001:db8::5
2001:db8::6
2001:db8::7
2001:db8::8
2001:db8::9
2001:db8::a
2001:db8::b
2001:db8::c
2001:db8::d
2001:db8::e
2001:db8::f

----------
components: Library (Lib)
files: ipaddress_ipv6_hosts.diff
keywords: patch
messages: 198927
nosy: m01
priority: normal
severity: normal
status: open
title: ipaddress.IPv6Network.hosts function omits network and broadcast addresses
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31956/ipaddress_ipv6_hosts.diff

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

From report at bugs.python.org  Fri Oct  4 02:00:16 2013
From: report at bugs.python.org (Tim Peters)
Date: Fri, 04 Oct 2013 00:00:16 +0000
Subject: [New-bugs-announce] [issue19158] BoundedSemaphore.release() subject
	to races
Message-ID: <1380844816.11.0.829919053917.issue19158@psf.upfronthosting.co.za>


New submission from Tim Peters:

I'm sure this flaw exists on more than just the current default branch, but didn't check.

BoundedSemaphore.release() doesn't quite do what it thinks it's doing.  By eyeball, the code obviously suffers from a small timing hole:  multiple threads releasing at the same time can all see "self._value >= self._initial_value" as false before any of them actually releases the semaphore.  So the value of ._value can become arbitrarily higher than ._initial_value.

This is hard to provoke.  The attached patch adds a TESTWAIT Event to BoundedSemaphore so that the new file (unbounded.py) can demonstrate the race reliably.  The patch doesn't fix anything - it's just a way to demonstrate the problem.  At the end, unbounded.py prints

bs._value is 2

That should be "impossible" for a BoundedSemaphore(1).

----------
components: Library (Lib)
files: sema
messages: 198928
nosy: tim.peters
priority: normal
severity: normal
stage: needs patch
status: open
title: BoundedSemaphore.release() subject to races
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file31957/sema

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

From report at bugs.python.org  Fri Oct  4 02:57:01 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 04 Oct 2013 00:57:01 +0000
Subject: [New-bugs-announce] [issue19159] 2to3 incorrectly converts two
	parameter unicode()	constructor to str()
Message-ID: <1380848221.34.0.113318109219.issue19159@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

>From a conversion through 2to3:

<       default_value=unicode("", "utf-8"),
---
>       default_value=str("", "utf-8"),

The Python 2 unicode constructor takes an optional second parameter which is the codec to use to convert when the first parameter is non-unicode.

2to3 should check the parameters on uses of unicode() and if there is a second parameter and the first is explicitly b"" bytes it should turn it into
  default_value=b"whatever".decode(second_param)

if the first is valid utf-8 and the second is "utf-8" (or its other spellings) it should leave it as is and simply become:
  default_value="thing passed to unicode() that was already utf-8"

----------
messages: 198929
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: 2to3 incorrectly converts two parameter unicode() constructor to str()
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Oct  4 03:36:13 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 04 Oct 2013 01:36:13 +0000
Subject: [New-bugs-announce] [issue19160] Inconsistent size for GIL release
	in hashlib
Message-ID: <1380850573.19.0.333542059882.issue19160@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n:

In http://docs.python.org/3.3/library/hashlib.html there is a contradiction:

"""
For better multithreading performance, the Python GIL is released for strings of more than 2047 bytes at object creation or on update.

[...]

Changed in version 3.1: The Python GIL is released to allow other threads to run while hash updates on data larger than 2048 bytes is taking place when using hash algorithms supplied by OpenSSL.
"""

So is it 2047 or 2048? :)

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 198930
nosy: docs at python, jcea
priority: normal
severity: normal
status: open
title: Inconsistent size for GIL release in hashlib
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Oct  4 12:07:23 2013
From: report at bugs.python.org (Adam Davison)
Date: Fri, 04 Oct 2013 10:07:23 +0000
Subject: [New-bugs-announce] [issue19161] collections Counter handles nan
	strangely
Message-ID: <1380881243.0.0.773040970534.issue19161@psf.upfronthosting.co.za>


New submission from Adam Davison:

If you pass an array containing nan to collections.Counter, rather than counting the number of 'nan's it outputs "'nan': 1" n times into the dictionary. I appreciate using this on an array of floats is a bit of an unusual case but I don't think this is the expected behaviour based on the documentation.

To reproduce, try e.g.:
a = [1, 1, 1, 2, 'nan', 'nan', 'nan']
collections.Counter(map(float, a))

Based on the documentation I expected to see:
{1.0: 3, 2.0: 1, nan: 3}

But it actually returns:
{1.0: 3, 2.0: 1, nan: 1, nan: 1, nan: 1}

Presumably this relates to the fact that nan != nan. I'm not 100% sure if this is a bug or maybe just something that should be mentioned in the documentation... Certainly it's not what I wanted it to do :)

Thanks,

Adam

----------
components: Library (Lib)
messages: 198938
nosy: Adam.Davison
priority: normal
severity: normal
status: open
title: collections Counter handles nan strangely
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Oct  4 13:00:07 2013
From: report at bugs.python.org (Filip Zyzniewski)
Date: Fri, 04 Oct 2013 11:00:07 +0000
Subject: [New-bugs-announce] [issue19162]
	datetime.datetime.min.strftime('%Y') not working
Message-ID: <1380884407.41.0.543045955431.issue19162@psf.upfronthosting.co.za>


New submission from Filip Zyzniewski:

The datetime class provides a min datetime object which is not formattable:

on Python 2:

$ python
Python 2.7.3 (default, Apr 10 2013, 05:13:16) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> datetime.datetime.min.strftime('%Y')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: year=1 is before 1900; the datetime strftime() methods require year >= 1900
>>> 

and on Python 3:

$ python3
Python 3.2.3 (default, Apr 10 2013, 05:07:54) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> datetime.datetime.min.strftime('%Y')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: year=1 is before 1000; the datetime strftime() methods require year >= 1000
>>>

It seems to me that either datetime.datetime.min.year should be increased to 1900/1000 or strftime should be able to format year=1 - it is strange that the API doesn't support its own constants.

----------
components: Library (Lib)
messages: 198941
nosy: filip.zyzniewski
priority: normal
severity: normal
status: open
title: datetime.datetime.min.strftime('%Y') not working
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Oct  4 13:09:58 2013
From: report at bugs.python.org (hiroaki itoh)
Date: Fri, 04 Oct 2013 11:09:58 +0000
Subject: [New-bugs-announce] [issue19163] PyString_Format with dict
Message-ID: <1380884998.67.0.733002313929.issue19163@psf.upfronthosting.co.za>


New submission from hiroaki itoh:

http://docs.python.org/2.7/c-api/string.html#PyString_Format

The documents says `The args argument must be a tuple.',
But if format is like '%(key)s', PyString_Format claims
args must be mapping protocol.
(At least 2.7.3.)

----------
assignee: docs at python
components: Documentation
messages: 198942
nosy: docs at python, xwhhsprings
priority: normal
severity: normal
status: open
title: PyString_Format with dict
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Oct  4 13:18:10 2013
From: report at bugs.python.org (Marco Buccini)
Date: Fri, 04 Oct 2013 11:18:10 +0000
Subject: [New-bugs-announce] [issue19164] Update uuid.UUID TypeError
	exception: integer should not	be an argument.
Message-ID: <1380885490.13.0.480584034262.issue19164@psf.upfronthosting.co.za>


New submission from Marco Buccini:

When you try to use uuid.UUID() without arguments you get a TypeError exception saying that you can actually use an integer (while you cannot). 

Python 2.6.8 (default, Apr 26 2013, 16:24:53) 
[GCC 4.6.3] on linux2
>>> uuid.UUID()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/uuid.py", line 129, in __init__
    raise TypeError('need one of hex, bytes, bytes_le, fields, or int')
TypeError: need one of hex, bytes, bytes_le, fields, or int

>>> uuid.UUID(uuid.uuid4().int)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/uuid.py", line 131, in __init__
    hex = hex.replace('urn:', '').replace('uuid:', '')
AttributeError: 'long' object has no attribute 'replace'

So, let's check with an integer - maybe an int has 'replace'.
>>> uuid.UUID(1231231)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/uuid.py", line 131, in __init__
    hex = hex.replace('urn:', '').replace('uuid:', '')
AttributeError: 'int' object has no attribute 'replace'

No, it doesn't. Anyway, with a propery hex value, it works (of course!).

>>> uuid.UUID(uuid.uuid4().hex)
UUID('89b1283d-c32e-4b8a-a9e3-a699445fdd4d')

----------
assignee: docs at python
components: Documentation
messages: 198943
nosy: docs at python, makronized
priority: normal
severity: normal
status: open
title: Update uuid.UUID TypeError exception: integer should not be an argument.
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Oct  4 17:40:15 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Oct 2013 15:40:15 +0000
Subject: [New-bugs-announce] [issue19165] Change formatter warning to
	DeprecationWarning in 3.5
Message-ID: <1380901215.35.0.522211470055.issue19165@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee: brett.cannon
components: Library (Lib)
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Change formatter warning to DeprecationWarning in 3.5
versions: Python 3.5

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

From report at bugs.python.org  Fri Oct  4 17:53:20 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 04 Oct 2013 15:53:20 +0000
Subject: [New-bugs-announce] [issue19166] Unusued variable in test_keys in
	Lib/test/test_dict.py
Message-ID: <1380902000.81.0.140295441911.issue19166@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

This is the test.

   def test_keys(self):
        d = {}
        self.assertEqual(set(d.keys()), set())
        d = {'a': 1, 'b': 2}
        k = d.keys()
        self.assertIn('a', d)
        self.assertIn('b', d)
        self.assertRaises(TypeError, d.keys, None)
        self.assertEqual(repr(dict(a=1).keys()), "dict_keys(['a'])")

As you can see, the variable k is never used. Attached the patch to give purpose to variable k.

----------
components: Tests
files: fix_test_dict_unused_variable.patch
keywords: patch
messages: 198957
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Unusued variable in test_keys in Lib/test/test_dict.py
versions: Python 3.4
Added file: http://bugs.python.org/file31958/fix_test_dict_unused_variable.patch

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

From report at bugs.python.org  Fri Oct  4 22:53:03 2013
From: report at bugs.python.org (mpb)
Date: Fri, 04 Oct 2013 20:53:03 +0000
Subject: [New-bugs-announce] [issue19167] sqlite3 cursor.description varies
	across Linux (3.3.1), Win32 (3.3.2), when selecting from a view.
Message-ID: <1380919983.53.0.47531466178.issue19167@psf.upfronthosting.co.za>


New submission from mpb:

On Win32, when I select from an SQLite view, and enclose the column name in double quotes in the select query, the cursor description (erroneously?) contains the double quotes.

On Linux (or on Win32 when selecting from a table rather than a view) the cursor description does not contain the double quotes.  I expect the Linux behavior, not the Win32 behavior.

The following code demonstrates the problem.
----
import sqlite3, sys

print (sys.platform)
print (sys.version)

conn = sqlite3.connect (':memory:')
cur  = conn.cursor ()

cur.execute ('create table Foo ( foo_id integer primary key ) ;')
cur.execute ('create view  Foo_View as select * from Foo ;')

cur.execute ('select foo_id from Foo;')
print (cur.description[0][0])
cur.execute ('select "foo_id" from Foo;')
print (cur.description[0][0])
cur.execute ('select foo_id from Foo_View;')
print (cur.description[0][0])
cur.execute ('select "foo_id" from Foo_View;')
print (cur.description[0][0])
----

Sample output on Linux and Win32.
----
linux
3.3.1 (default, Apr 17 2013, 22:32:14) 
[GCC 4.7.3]
foo_id
foo_id
foo_id
foo_id
----
win32
3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600 32 bit (Intel)]
foo_id
foo_id
foo_id
"foo_id"
----

Above, please note the (erroneous?) double quotes around the final foo_id.

----------
components: Library (Lib)
messages: 198964
nosy: mpb
priority: normal
severity: normal
status: open
title: sqlite3 cursor.description varies across Linux (3.3.1), Win32 (3.3.2), when selecting from a view.
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Oct  5 00:39:34 2013
From: report at bugs.python.org (Alexis Layton)
Date: Fri, 04 Oct 2013 22:39:34 +0000
Subject: [New-bugs-announce] [issue19168] pprint.pprint(...,
	compact=True) not implemented
Message-ID: <1380926374.45.0.423470167923.issue19168@psf.upfronthosting.co.za>


New submission from Alexis Layton:

Documentation for 3.4 states that the compact keyword-only argument has been added to 3.4. However:

Python 3.4.0a3 (default, Oct  2 2013, 14:05:02) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pprint
>>> pprint(3, compact=True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'module' object is not callable
>>> pprint.pprint(3, compact=True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: pprint() got an unexpected keyword argument 'compact'
>>>

----------
components: Library (Lib)
messages: 198969
nosy: AlexisLayton
priority: normal
severity: normal
status: open
title: pprint.pprint(..., compact=True) not implemented
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Oct  5 13:33:40 2013
From: report at bugs.python.org (CliffM)
Date: Sat, 05 Oct 2013 11:33:40 +0000
Subject: [New-bugs-announce] [issue19169] random.py : simple tidying
Message-ID: <1380972820.55.0.891016437173.issue19169@psf.upfronthosting.co.za>


New submission from CliffM:

Standardising some name-shortening in the _randbelow() method.

----------
components: Extension Modules
files: shorten.patch
keywords: patch
messages: 198984
nosy: CliffM
priority: normal
severity: normal
status: open
title: random.py : simple tidying
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31961/shorten.patch

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

From report at bugs.python.org  Sat Oct  5 15:16:09 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 05 Oct 2013 13:16:09 +0000
Subject: [New-bugs-announce] [issue19170] telnetlib: use selectors
Message-ID: <1380978969.74.0.714959132131.issue19170@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

The patch attached uses selector in telnetlib.
This removes a lot of duplicated code.

----------
components: Library (Lib)
files: telnetlib_selectors.diff
keywords: needs review, patch
messages: 198986
nosy: neologix
priority: normal
severity: normal
stage: patch review
status: open
title: telnetlib: use selectors
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31962/telnetlib_selectors.diff

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

From report at bugs.python.org  Sat Oct  5 16:07:17 2013
From: report at bugs.python.org (Armin Rigo)
Date: Sat, 05 Oct 2013 14:07:17 +0000
Subject: [New-bugs-announce] [issue19171] pow() improvement on longs
Message-ID: <1380982037.44.0.922369997614.issue19171@psf.upfronthosting.co.za>


New submission from Armin Rigo:

The attached patch (which can be applied on both trunk and 2.7) gives a huge speed improvement for the case 'pow(huge_number, smallish_number, smallish_number)'.  The improvement is unbounded: I get 20x with 'pow(x, y, z)' with the arguments 'x = 3 ** 10000, y = 10 ** 51 - 2, z = 10 ** 51' but increasing x just increases the factor.

This is inspired by https://github.com/pyca/ed25519: check out revision 9f3e838d90ded42a86ec74c5e9f5e37dec8122a0, run it with 'time python -u signfast.py < sign.input'.  This patch gives around 14% improvement.  So it's a case that occurs in practice.

----------
components: Interpreter Core
files: pow_speedup.diff
keywords: patch
messages: 198987
nosy: arigo
priority: normal
severity: normal
status: open
title: pow() improvement on longs
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file31964/pow_speedup.diff

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

From report at bugs.python.org  Sat Oct  5 16:40:38 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 05 Oct 2013 14:40:38 +0000
Subject: [New-bugs-announce] [issue19172] selectors: add keys() method
Message-ID: <1380984038.36.0.521182029078.issue19172@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

This adds a keys() method to selectors, to return all the registered keys.
It's useful, because one often needs to loop until all registered file objects have been unregistered e.g. (inspired from subprocess, see #18923):

while selector.keys():
   for key, events in selector.select():
       # process events

also, it can be useful if you want e.g. the list of all currently logged users, etc. It avoids having to maintain a separate data-structure tracking registered file objects.

The patch attached returns a new set upon each call: another way to handle this would be to just return the dictionary's .values() view: it would be faster and use less memory, but it's immutable and also this would prevent the user from doing:
for key in selectior.keys():
   if somecondition:
       selector.unregister(key.fileobj)

(since you'll get "dictonary changed size during iteration").

----------
components: Library (Lib)
files: selectors_keys.diff
keywords: needs review, patch
messages: 198988
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: selectors: add keys() method
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31965/selectors_keys.diff

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

From report at bugs.python.org  Sat Oct  5 19:30:41 2013
From: report at bugs.python.org (noxdafox)
Date: Sat, 05 Oct 2013 17:30:41 +0000
Subject: [New-bugs-announce] [issue19173] Expose Queue maxsize parameter to
	multiprocessing.Pool	class
Message-ID: <1380994241.79.0.709476745668.issue19173@psf.upfronthosting.co.za>


New submission from noxdafox:

As a developer I want the multiprocessing Pool class to expose the internal queue size limit in order to better control the task flow in my application.

Consider the following scenarios:
1. The tasks I want to run into the pool require a considerably big amount of data as input (a big XML string for example). A limitless queue and a high number of tasks would cause my application to consume a huge amount of memory, this is unacceptable.
2. I want to always ensure a small amount of tasks queued into the pool so that, if my application crashes, I won't loose much data.

Patch includes code changes, tests and documentation.

----------
components: Library (Lib)
files: maxqueuesize.patch
keywords: patch
messages: 198992
nosy: noxdafox
priority: normal
severity: normal
status: open
title: Expose Queue maxsize parameter to multiprocessing.Pool class
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31967/maxqueuesize.patch

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

From report at bugs.python.org  Sat Oct  5 20:54:41 2013
From: report at bugs.python.org (Peter)
Date: Sat, 05 Oct 2013 18:54:41 +0000
Subject: [New-bugs-announce] [issue19174] Add range to future_builtins
Message-ID: <1380999281.69.0.809167641275.issue19174@psf.upfronthosting.co.za>


New submission from Peter:

Much like how iterator style filter, map and zip are available via future_builtins (issue #2171), it would be natural to expect range to be there too, e.g.

>>> from future_builtins import range
>>> range(5)
range(0, 5)

The 2to3 fixers would need to be modified in the same way the map/filter/zip fixers were to be aware when a Python3 style range was in use via this import.

----------
messages: 198997
nosy: maubp
priority: normal
severity: normal
status: open
title: Add range to future_builtins
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Sun Oct  6 06:14:24 2013
From: report at bugs.python.org (David Chambers)
Date: Sun, 06 Oct 2013 04:14:24 +0000
Subject: [New-bugs-announce] [issue19175] Erroneous reference to "integer"
	in format string grammar
Message-ID: <1381032864.93.0.113807397977.issue19175@psf.upfronthosting.co.za>


New submission from David Chambers:

I first raised this issue on Stack Overflow: http://stackoverflow.com/questions/19203194

The [replacement field grammar][1] states that an [integer][2] is a valid field_name, but this is inaccurate:

    >>> '{0}'.format('zero')
    'zero'
    >>> '{0x0}.format('zero')
    KeyError: '0x0'
    >>> '{0o0}.format('zero')
    KeyError: '0o0'
    >>> '{0b0}.format('zero')
    KeyError: '0b0'

This [comment][3] by Eric Smith suggests that the above is the intended behaviour:

> get_integer uses the narrowest possible definition for integer indexes,
> in order to pass all other strings to mappings.

The documentation should be updated to match the actual behaviour. abarnert on Stack Overflow suggested the following change:

    -arg_name          ::=  [identifier | integer]
    +arg_name          ::=  [identifier | digit+]


[1]: http://docs.python.org/2/library/string.html#format-string-syntax
[2]: http://docs.python.org/2/reference/lexical_analysis.html#grammar-token-integer
[3]: http://bugs.python.org/issue8985#msg107705

----------
assignee: docs at python
components: Documentation
messages: 199024
nosy: davidchambers, docs at python
priority: normal
severity: normal
status: open
title: Erroneous reference to "integer" in format string grammar
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Oct  6 08:42:30 2013
From: report at bugs.python.org (Martin Panter)
Date: Sun, 06 Oct 2013 06:42:30 +0000
Subject: [New-bugs-announce] [issue19176] DeprecationWarning for doctype()
	method when subclassing	_elementtree.XMLParser
Message-ID: <1381041750.41.0.637077946349.issue19176@psf.upfronthosting.co.za>


New submission from Martin Panter:

I am using the C version of Element Tree via the main ElementTree module. I have subclassed XMLParser, and created my own target object. I am not that interested in XML doctypes, but the following simplified code raises a DeprecationWarning:

$ python3.3 -Wall
Python 3.3.2 (default, May 16 2013, 23:40:52) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree.ElementTree import XMLParser
>>> class CustomParser(XMLParser): pass
... 
>>> CustomParser().feed("<!DOCTYPE blaua>")
__main__:1: DeprecationWarning: This method of XMLParser is deprecated.  Define doctype() method on the TreeBuilder target.

Looking at the C code, the logic is wrong. Subclasses of XMLParser will normally always have a doctype() method, at least by inheritance. So the code should compare the method with the XMLParser.doctype() base method rather than just checking that it exists. The native Python version seems to get it right.

http://hg.python.org/cpython/file/50ea4dccb03e/Modules/_elementtree.c#l3091

It looks like this may not be an issue for Python 3.4 because according to Issue 13248 the deprecated doctype() method is due to be removed.

----------
components: Extension Modules
messages: 199031
nosy: vadmium
priority: normal
severity: normal
status: open
title: DeprecationWarning for doctype() method when subclassing _elementtree.XMLParser
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Oct  6 09:28:26 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 06 Oct 2013 07:28:26 +0000
Subject: [New-bugs-announce] [issue19177] Link to "TLS (Transport Layer
	Security) and SSL (Secure	Socket Layer)" dead
Message-ID: <1381044506.5.0.0801676720641.issue19177@psf.upfronthosting.co.za>


New submission from Georg Brandl:

This page doesn't seem to exist anymore.  Antoine, you added the link, I guess it was an introductory page? Do you have another one in mind?

It's still in the Wayback Machine, so for the time being we can replace the link to go there.

----------
assignee: pitrou
components: Documentation
messages: 199037
nosy: georg.brandl, pitrou
priority: low
severity: normal
status: open
title: Link to "TLS (Transport Layer Security) and SSL (Secure Socket Layer)" dead
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Oct  6 10:42:53 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 06 Oct 2013 08:42:53 +0000
Subject: [New-bugs-announce] [issue19178] Entries for "module" and "package"
	in glossary
Message-ID: <1381048973.81.0.279739415702.issue19178@psf.upfronthosting.co.za>


New submission from Georg Brandl:

>From Kevin Murphy on docs@:

> I think newbies might like having 'module' and 'package' defined in 
> the glossary, e.g. http://docs.python.org/2/glossary.html

I agree.

----------
assignee: docs at python
components: Documentation
messages: 199052
nosy: docs at python, georg.brandl
priority: normal
severity: normal
stage: needs patch
status: open
title: Entries for "module" and "package" in glossary
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Oct  6 13:01:32 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 06 Oct 2013 11:01:32 +0000
Subject: [New-bugs-announce] [issue19179] doc bug: confusing table of values
In-Reply-To: <CAOaTG=63P-5B04GDz2mCyoEgC01yio6bXGwCxvBgfrfXJk6i+A@mail.gmail.com>
Message-ID: <52514342.6020404@python.org>


New submission from Georg Brandl:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[From Jason Scherer on docs at python.org]

On this page:

http://docs.python.org/2/library/xml.html

The table of truth values is a bit confusing because it's not clear from the
context what it's actually saying is true, or false.

It might be better to replace the words "true" and "false" with "vulnerable" and
"protected" or something like that.  Otherwise, I can't tell if "true" means
"yes, this parser is vulnerable to this attack" or if "true" means "yes, this
parser is protected from this attack"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (GNU/Linux)

iEYEARECAAYFAlJRQ0IACgkQN9GcIYhpnLCziACeO3MzVKKcH8RLlU+w11hAy9Kh
wo4AnRYvAXuCCLdlrED2SHJ0oexW1vj0
=dxxa
-----END PGP SIGNATURE-----

----------
messages: 199066
nosy: georg.brandl
priority: normal
severity: normal
status: open
title: doc bug: confusing table of values

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

From report at bugs.python.org  Sun Oct  6 13:07:47 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 06 Oct 2013 11:07:47 +0000
Subject: [New-bugs-announce] [issue19180] some RFC references could be
	updated
In-Reply-To: <519ADE01.7090104@ieca.com>
Message-ID: <525144B9.3040305@python.org>


New submission from Georg Brandl:

-------- Original-Nachricht --------
Betreff: [docs] some RFC references could be updated
Datum: Mon, 20 May 2013 22:37:53 -0400
Von: Sean Turner <turners at ieca.com>
An: docs at python.org

Hi,

Just starting to learn python and have noted that at the bottom of this
page:

http://docs.python.org/3/library/ssl.html

There's a couple of out of date references:

0) RFC 1750 has been been obsoleted by RFC 4086 so maybe this is a
better reference (and I prefer the datatracker view as opposed to the
tools view):

http://datatracker.ietf.org/doc/rfc4086/

Same could be done on this link:

http://docs.python.org/3.4/library/ssl.html

1) RFC 3280 has been obsoleted by RFC 5280 so maybe:

http://datatracker.ietf.org/doc/rfc5280/

Same could be done on this link:

http://docs.python.org/3.4/library/ssl.html

2) RFC 4366 has been obsoleted by RFC 6066 so maybe:

http://datatracker.ietf.org/doc/rfc6066/

On http://docs.python.org/3.4/library/ssl.html you could probably just
drop the reference and change in the ssl.HAS_SNI section.

3) The link to TLS seems broken maybe just point to:

TLS 1.0 http://datatracker.ietf.org/doc/rfc2246/
TLS 1.1 http://datatracker.ietf.org/doc/rfc4346/
TLS 1.2 http://datatracker.ietf.org/doc/rfc5246/
SSL 3.0 http://datatracker.ietf.org/doc/rfc6101/

Actually the same link is broken on:

http://docs.python.org/3.4/library/ssl.html

4) (this is a shameless plug) Might be worth adding a reference in the
ssl.PROTOCOL_SSLv2 section that points to:

http://datatracker.ietf.org/doc/rfc6146/

----------
assignee: docs at python
components: Documentation
messages: 199069
nosy: docs at python, georg.brandl
priority: normal
severity: normal
status: open
title: some RFC references could be updated

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

From report at bugs.python.org  Sun Oct  6 13:28:44 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 06 Oct 2013 11:28:44 +0000
Subject: [New-bugs-announce] [issue19181] ftp.cwi.nl used as example does
	not exist anymore
In-Reply-To: <002d01cded5f$6d1fa980$475efc80$@gravitymarketing.com.au>
Message-ID: <525149A2.2010402@python.org>


New submission from Georg Brandl:

ftp.python.org doesn't seem to listen on port 21 either... anyone know a public
FTP server we can use as example?

-------- Original-Nachricht --------
Betreff: 	[docs] quick note on ftplib for python
Datum: 	Tue, 8 Jan 2013 16:17:14 +1100
Von: 	Jeremy Orchard <jeremy at gravitymarketing.com.au>
An: 	<docs at python.org>

Hello,

Quick note, ftplib gives example host ftp.cwi.nl

In its documentation which is a url which is no longer active? when you try the
dummy example, ftplib doesn?t really output a clear error so it might be worth
updating the host, (though most programmers should assume this quickly),

Python 2.7 > documentation for ftplib which introduced the feature FTP_TLS gives
the examplehost ftp.python.org <ftp://ftp.python.org> which is possibly the
ideal candidate for the change.

Not really a bug, thought id save you the trouble by reporting just incase, it
was something worth changing.

----------
assignee: docs at python
components: Documentation
messages: 199070
nosy: docs at python, georg.brandl
priority: normal
severity: normal
status: open
title: ftp.cwi.nl used as example does not exist anymore

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

From report at bugs.python.org  Sun Oct  6 15:39:44 2013
From: report at bugs.python.org (Esa Peuha)
Date: Sun, 06 Oct 2013 13:39:44 +0000
Subject: [New-bugs-announce] [issue19182] Socket leak in logging.handlers
Message-ID: <1381066784.25.0.989730227562.issue19182@psf.upfronthosting.co.za>


New submission from Esa Peuha:

Running test_logging produces the following:

/home/peuha/python/cpython/Lib/logging/handlers.py:550: ResourceWarning: unclosed <socket.socket fd=4, family=1, type=2049, proto=0>
  self.retryTime = now + self.retryPeriod
/home/peuha/python/cpython/Lib/logging/handlers.py:550: ResourceWarning: unclosed <socket.socket fd=4, family=1, type=2049, proto=0>
  self.retryTime = now + self.retryPeriod

This turns out to be a bug in SocketHandler.makeSocket; the attachment should fix it.

----------
components: Library (Lib)
files: logging.handlers.diff
keywords: patch
messages: 199074
nosy: Esa.Peuha
priority: normal
severity: normal
status: open
title: Socket leak in logging.handlers
type: behavior
Added file: http://bugs.python.org/file31973/logging.handlers.diff

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

From report at bugs.python.org  Sun Oct  6 16:58:27 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 06 Oct 2013 14:58:27 +0000
Subject: [New-bugs-announce] [issue19183] PEP 456 Secure and interchangeable
	hash algorithm
Message-ID: <1381071507.59.0.633396312817.issue19183@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The patch implements the current state of PEP 456 plus a configure option to select the hash algorithm. I have tested it only on 64bit Linux so far.

----------
components: Interpreter Core
files: pep-0456-1.patch
keywords: patch
messages: 199078
nosy: christian.heimes, ncoghlan, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: PEP 456 Secure and interchangeable hash algorithm
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31974/pep-0456-1.patch

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

From report at bugs.python.org  Sun Oct  6 18:46:52 2013
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 06 Oct 2013 16:46:52 +0000
Subject: [New-bugs-announce] [issue19184] dis module has incorrect docs for
	RAISE_VARARGS
Message-ID: <1381078012.05.0.236677780468.issue19184@psf.upfronthosting.co.za>


New submission from Ned Batchelder:

The order of values on the stack is backwards for RAISE_VARARGS.  The docs say:

"Raises an exception. argc indicates the number of parameters to the raise statement, ranging from 0 to 3. The handler will find the traceback as TOS2, the parameter as TOS1, and the exception as TOS."

But in fact, the order is reverse of that.  In the one-parameter case, the exception is TOS, in the two-parameter case, the value is TOS, and in the three-parameter case, the traceback is TOS.  Not sure how to write that concisely, thought.  :)

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 199096
nosy: docs at python, nedbat
priority: normal
severity: normal
status: open
title: dis module has incorrect docs for RAISE_VARARGS
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Sun Oct  6 22:14:30 2013
From: report at bugs.python.org (Matteo Cafasso)
Date: Sun, 06 Oct 2013 20:14:30 +0000
Subject: [New-bugs-announce] [issue19185] Allow multiprocessing Pool
	initializer to return values
Message-ID: <1381090470.56.0.579888919868.issue19185@psf.upfronthosting.co.za>


New submission from Matteo Cafasso:

This patch allows the pool initializer function to return the initialized values. The returned values will be passed to the called function as first positional argument.

Previously the common pattern was to store the initialized objects into global variables making the code more difficult to manage.

The patch is not breaking any backward compatibility as the previous initializers were not supposed to return any value, if the initializer does not return anything the behavior is the same as usual.

----------
files: pool_initializer.patch
keywords: patch
messages: 199116
nosy: noxdafox
priority: normal
severity: normal
status: open
title: Allow multiprocessing Pool initializer to return values
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31978/pool_initializer.patch

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

From report at bugs.python.org  Mon Oct  7 15:04:57 2013
From: report at bugs.python.org (AThompson)
Date: Mon, 07 Oct 2013 13:04:57 +0000
Subject: [New-bugs-announce] [issue19186] expat symbols should be namespaced
	in pyexpat again
Message-ID: <1381151097.4.0.844657685559.issue19186@psf.upfronthosting.co.za>


New submission from AThompson:

The issue with confliciting expat versions has poped up again in python 3.
http://bugs.python.org/issue1295808

It looks like the fix for this was removed when upgrading to expat 2.1 in http://hg.python.org/cpython/rev/e4dc8be9a72f      on Sat, 14 Jul 2012 14:12:35 -0700 Gregory P. Smith
--- a/Modules/expat/expat_external.h
/* Namespace external symbols to allow multiple libexpat version to
-   co-exist. */
-#include "pyexpatns.h"

Same backtrace as before.
#0  0x0000003507481321 in __strlen_sse2 () from /lib64/libc.so.6
#1  0x00007facace1b0d0 in PyUnicode_FromString (u=0x0) at Objects/unicodeobject.c:1824
#2  0x00007facaceefddc in PyModule_AddStringConstant (m=0x7fac9c7cf678,
    name=0x7fac9c5ab2e3 "XML_ERROR_UNBOUND_PREFIX", value=0x0) at Python/modsupport.c:554
#3  0x00007fac9c582f31 in PyInit_pyexpat () at /home/hex/Downloads/Python-3.3.2/Modules/pyexpat.c:1870
#4  0x00007facacee8f89 in _PyImport_LoadDynamicModule (name=0x7fac9c7db450, path=0x7fac9cdf9928, fp=0x0)

----------
components: Extension Modules
messages: 199143
nosy: athompson
priority: normal
severity: normal
status: open
title: expat symbols should be namespaced in pyexpat again
type: crash
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Oct  7 21:18:53 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Oct 2013 19:18:53 +0000
Subject: [New-bugs-announce] [issue19187] Use a set for interned strings
Message-ID: <1381173533.0.0.681038585832.issue19187@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

This is a simple enhancement that may reduce memory consumption by a bit (unfortunately, this is difficult to measure using standard tools).

----------
components: Interpreter Core
files: setintern.patch
keywords: patch
messages: 199154
nosy: haypo, pitrou
priority: low
severity: normal
stage: patch review
status: open
title: Use a set for interned strings
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file31986/setintern.patch

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

From report at bugs.python.org  Mon Oct  7 21:35:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 07 Oct 2013 19:35:39 +0000
Subject: [New-bugs-announce] [issue19188] Add PySet_CheckExact()
Message-ID: <1381174539.56.0.480859980209.issue19188@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There are PyFrozenSet_CheckExact() and PyAnySet_CheckExact() but there is no PySet_CheckExact(). Perhaps we should add it for consistency.

----------
components: Interpreter Core
messages: 199157
nosy: christian.heimes, pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Add PySet_CheckExact()
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Oct  7 22:39:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 07 Oct 2013 20:39:13 +0000
Subject: [New-bugs-announce] [issue19189] Improve cross-references in pickle
	documentation.
Message-ID: <1381178353.55.0.131251765353.issue19189@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which fixes internal references in the documentation of the pickle package.

----------
assignee: docs at python
components: Documentation
files: refs.pickle.patch
keywords: patch
messages: 199162
nosy: alexandre.vassalotti, docs at python, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Improve cross-references in pickle documentation.
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31988/refs.pickle.patch

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

From report at bugs.python.org  Mon Oct  7 22:40:06 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 07 Oct 2013 20:40:06 +0000
Subject: [New-bugs-announce] [issue19190] Improve cross-references in
	builtins documentation.
Message-ID: <1381178406.23.0.925502914141.issue19190@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which fixes internal references for in the documentation of builtins.

----------
assignee: docs at python
components: Documentation
files: refs.builtins.patch
keywords: patch
messages: 199163
nosy: docs at python, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Improve cross-references in builtins documentation.
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31989/refs.builtins.patch

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

From report at bugs.python.org  Tue Oct  8 17:25:06 2013
From: report at bugs.python.org (xiaowei)
Date: Tue, 08 Oct 2013 15:25:06 +0000
Subject: [New-bugs-announce] [issue19191] os.path.splitext in windows ,
	a little question
Message-ID: <1381245906.23.0.98078809812.issue19191@psf.upfronthosting.co.za>


New submission from xiaowei:

>>> print( os.path.splitext.__doc__ )
Split the extension from a pathname.

    Extension is everything from the last dot to the end, ignoring
    leading dots.  Returns "(root, ext)"; ext may be empty.
>>> os.path.splitext('.txt')
('.txt', '')

#### 
I think, in windows it should be ('','.txt'), because the first dot doesnot mean hiding. Actually, in windows file explorer , it will show a empty file name and hide the extension if the extension has been related a program except shell32.dll?just like the attachment show. So, in windows, the last dot , even it's the first character of the file name, it still means the start of the file extension name.

In this case, windows doesnot like linux, we donot have to make them same. 

If you agree, then
why we can talk ignoring leading dots or not ......
i mean
os.path.splitext('...ext')

Anyway, thank you , for your work, even you donot think so

----------
components: Windows
files: fileext.JPG
messages: 199208
nosy: xiaowei.py
priority: normal
severity: normal
status: open
title: os.path.splitext in windows , a little question
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file31999/fileext.JPG

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

From report at bugs.python.org  Tue Oct  8 18:26:11 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 08 Oct 2013 16:26:11 +0000
Subject: [New-bugs-announce] [issue19192] Move test_current_time from
	test_xmlrpc_net to	test_xmlrpc
Message-ID: <1381249571.28.0.993585174787.issue19192@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Currently, the test_current_time is idle because the server (time.xmlrpc.com) that it requires is dead (at the moment being and no end in sight).

The patch moved the test from Lib/test/test_xmlrpc_net.py to Lib/test/test_xmlrpc.py and simulate the time.xmlrpc.com server using http_server's TestInstanceClass.

----------
components: Tests
files: move_current_time_test_from_xmlrpc_net_to_xmlrpc.patch
keywords: patch
messages: 199218
nosy: r.david.murray, vajrasky
priority: normal
severity: normal
status: open
title: Move test_current_time from test_xmlrpc_net to test_xmlrpc
versions: Python 3.4
Added file: http://bugs.python.org/file32000/move_current_time_test_from_xmlrpc_net_to_xmlrpc.patch

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

From report at bugs.python.org  Tue Oct  8 20:16:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 08 Oct 2013 18:16:58 +0000
Subject: [New-bugs-announce] [issue19193] Improve cross-references in
	tutorial
Message-ID: <1381256218.12.0.311002758548.issue19193@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which fixes internal references in the tutorial.

----------
assignee: docs at python
components: Documentation
files: refs.tutorial.patch
keywords: patch
messages: 199228
nosy: docs at python, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Improve cross-references in tutorial
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32001/refs.tutorial.patch

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

From report at bugs.python.org  Tue Oct  8 21:50:40 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 08 Oct 2013 19:50:40 +0000
Subject: [New-bugs-announce] [issue19194] Improve cross-references in fcntl
	documentation
Message-ID: <1381261840.65.0.334313272339.issue19194@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which fixes internal references in the documentation of the fcntl package.

----------
assignee: docs at python
components: Documentation
files: refs.fcntl.patch
keywords: patch
messages: 199242
nosy: docs at python, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Improve cross-references in fcntl documentation
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32002/refs.fcntl.patch

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

From report at bugs.python.org  Tue Oct  8 21:56:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 08 Oct 2013 19:56:31 +0000
Subject: [New-bugs-announce] [issue19195] Improve cross-references in C API
Message-ID: <1381262191.72.0.573497194321.issue19195@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which fixes internal references in C API and extension documentation.

----------
assignee: docs at python
components: Documentation
files: refs.c-api.patch
keywords: patch
messages: 199243
nosy: docs at python, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Improve cross-references in C API
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32003/refs.c-api.patch

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

From report at bugs.python.org  Tue Oct  8 22:00:00 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 08 Oct 2013 20:00:00 +0000
Subject: [New-bugs-announce] [issue19196] Improve cross-references in pickle
	documentation
Message-ID: <1381262400.58.0.379802599514.issue19196@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which fixes internal references in distutils  documentation.

----------
assignee: docs at python
components: Documentation
files: refs.distutils.patch
keywords: patch
messages: 199244
nosy: docs at python, eric.araujo, serhiy.storchaka, tarek
priority: normal
severity: normal
stage: patch review
status: open
title: Improve cross-references in pickle documentation
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32004/refs.distutils.patch

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

From report at bugs.python.org  Tue Oct  8 23:03:49 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 08 Oct 2013 21:03:49 +0000
Subject: [New-bugs-announce] [issue19197] Improve cross-references in shlex
	documentation
Message-ID: <1381266229.65.0.408303361922.issue19197@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which fixes internal references in the documentation of the shlex module.

----------
assignee: docs at python
components: Documentation
files: refs.shlex.patch
keywords: patch
messages: 199247
nosy: docs at python, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Improve cross-references in shlex documentation
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32005/refs.shlex.patch

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

From report at bugs.python.org  Tue Oct  8 23:05:35 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 08 Oct 2013 21:05:35 +0000
Subject: [New-bugs-announce] [issue19198] Improve cross-references in cgi
	documentation
Message-ID: <1381266335.84.0.645626523869.issue19198@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which fixes internal references in the documentation of the cgi module.

----------
assignee: docs at python
components: Documentation
files: refs.cgi.patch
keywords: patch
messages: 199249
nosy: docs at python, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Improve cross-references in cgi documentation
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32006/refs.cgi.patch

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

From report at bugs.python.org  Tue Oct  8 23:18:41 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Oct 2013 21:18:41 +0000
Subject: [New-bugs-announce] [issue19199] Remove PyThreadState.tick_counter
	field
Message-ID: <1381267121.14.0.275844287932.issue19199@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The C structure "PyThreadState" has a counter which is incremented in the bytecode evaluation loop (ceval.c), but never used.

    /* XXX doesn't mean anything anymore (the comment below is obsolete)
       => deprecate or remove? */
    /* tick_counter is incremented whenever the check_interval ticker
     * reaches zero. The purpose is to give a useful measure of the number
     * of interpreted bytecode instructions in a given thread.  This
     * extremely lightweight statistic collector may be of interest to
     * profilers (like psyco.jit()), although nothing in the core uses it.
     */
    int tick_counter;

Antoine Pitrou added the XXX comment when he merged the "new GIL" of Python 3.2.

Can we now remove it?

----------
messages: 199256
nosy: haypo, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
versions: Python 3.4

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

From report at bugs.python.org  Wed Oct  9 00:33:38 2013
From: report at bugs.python.org (Elazar Gershuni)
Date: Tue, 08 Oct 2013 22:33:38 +0000
Subject: [New-bugs-announce] [issue19200] grammar in forkserver docs
Message-ID: <1381271618.79.0.0617201422198.issue19200@psf.upfronthosting.co.za>


New submission from Elazar Gershuni:

in http://docs.python.org/3.4/library/multiprocessing.html#start-methods
for `forkserver`:
"whenever a new process is need the parent process connects to the server and requests that it fork a new process."

replace "need " with "needed, ".

----------
assignee: docs at python
components: Documentation
messages: 199269
nosy: docs at python, elazar
priority: normal
severity: normal
status: open
title: grammar in forkserver docs
versions: Python 3.4

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

From report at bugs.python.org  Wed Oct  9 03:31:54 2013
From: report at bugs.python.org (Tim Heaney)
Date: Wed, 09 Oct 2013 01:31:54 +0000
Subject: [New-bugs-announce] [issue19201] lzma and 'x' mode open
Message-ID: <1381282314.82.0.620935912444.issue19201@psf.upfronthosting.co.za>


New submission from Tim Heaney:

I love the 'x' mode open in recent versions of Python. I just discovered that lzma.open doesn't support it. It seems there's an elif that explicitly checks the modes allowed. I added "x" and "xb" to the choices and now it works as I would like.

----------
files: patch.lzma.py
messages: 199272
nosy: oylenshpeegul
priority: normal
severity: normal
status: open
title: lzma and 'x' mode open
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32010/patch.lzma.py

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

From report at bugs.python.org  Wed Oct  9 12:09:16 2013
From: report at bugs.python.org (Esa Peuha)
Date: Wed, 09 Oct 2013 10:09:16 +0000
Subject: [New-bugs-announce] [issue19202] Additions to docs
Message-ID: <1381313356.45.0.650070848794.issue19202@psf.upfronthosting.co.za>


New submission from Esa Peuha:

Here are some additions to documentation of a few functions:

all, any: alternative definitions using functools.reduce
enumerate: alternative definition using zip and itertools.count
sum: equivalent definition using functools.reduce and operator.add
functools.reduce: equivalent definitions, use operator.add in example
itertools.accumulate: point to functools.reduce
itertools.filterfalse: point to filter

----------
assignee: docs at python
components: Documentation
files: doc.diff
keywords: patch
messages: 199281
nosy: Esa.Peuha, docs at python
priority: normal
severity: normal
status: open
title: Additions to docs
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32013/doc.diff

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

From report at bugs.python.org  Wed Oct  9 14:17:57 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 09 Oct 2013 12:17:57 +0000
Subject: [New-bugs-announce] [issue19203] Improve cross-references in curses
	howto
Message-ID: <1381321077.27.0.332235799284.issue19203@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which fixes internal references in the howto of the curses module.

----------
assignee: docs at python
components: Documentation
files: refs.curses-howto.patch
keywords: patch
messages: 199291
nosy: akuchling, docs at python, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Improve cross-references in curses howto
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32014/refs.curses-howto.patch

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

From report at bugs.python.org  Wed Oct  9 14:27:21 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 09 Oct 2013 12:27:21 +0000
Subject: [New-bugs-announce] [issue19204] Improve cross-references in urllib
	documentation
Message-ID: <1381321641.68.0.236509571307.issue19204@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which fixes internal references in the documentation of the urllib package.

----------
assignee: docs at python
components: Documentation
files: refs.urllib.patch
keywords: patch
messages: 199292
nosy: docs at python, orsenthil, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Improve cross-references in urllib documentation
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32016/refs.urllib.patch

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

From report at bugs.python.org  Wed Oct  9 15:15:01 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 09 Oct 2013 13:15:01 +0000
Subject: [New-bugs-announce] [issue19205] Don
Message-ID: <1381324501.56.0.878877827164.issue19205@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Don

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

From report at bugs.python.org  Wed Oct  9 15:17:03 2013
From: report at bugs.python.org (Itamar Turner-Trauring)
Date: Wed, 09 Oct 2013 13:17:03 +0000
Subject: [New-bugs-announce] [issue19206] Support disabling file I/O when
	doing traceback	formatting
Message-ID: <1381324623.16.0.375897659555.issue19206@psf.upfronthosting.co.za>


New submission from Itamar Turner-Trauring:

In certain situations it is best to avoid doing file I/O. For example, a program that runs in an event loop may wish to avoid any potentially blocking operations; reading from a file usually is fast, but can sometimes take arbitrary long. Another example (my specific use case) is a logging library - you don't want to block for an arbitrary amount of time when creating log messages in an application thread (a separate thread would do the writing).

Unfortunately, the traceback.py module reads from files to load the source lines for the traceback (using linecache.py). This means if you want to format a traceback without file I/O you have to either recreate some logic from the standard library, monkey-patch globally, or do a terrible hack you don't want to know about.

It would be better if the there was some way to ask the traceback.py module's functions to not do file I/O. The actual change would be fairly minor I suspect since the formatting functions already support getting None back from linecache.

----------
components: Library (Lib)
messages: 199294
nosy: itamarst
priority: normal
severity: normal
status: open
title: Support disabling file I/O when doing traceback formatting
type: enhancement

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

From report at bugs.python.org  Wed Oct  9 15:39:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 09 Oct 2013 13:39:10 +0000
Subject: [New-bugs-announce] [issue19207] Improve cross-references in os
	documentation
Message-ID: <1381325950.91.0.175108750844.issue19207@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which fixes internal references in the documentation of the os, os.path and posix modules.

----------
assignee: docs at python
components: Documentation
files: refs.os.patch
keywords: patch
messages: 199296
nosy: docs at python, loewis, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Improve cross-references in os documentation
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32018/refs.os.patch

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

From report at bugs.python.org  Wed Oct  9 15:55:35 2013
From: report at bugs.python.org (Tymoteusz Paul)
Date: Wed, 09 Oct 2013 13:55:35 +0000
Subject: [New-bugs-announce] [issue19208] Bas64.decodestring() returns data
	instead of throwing	exception
Message-ID: <1381326935.62.0.967416907354.issue19208@psf.upfronthosting.co.za>


New submission from Tymoteusz Paul:

What happens (and how to reproduce):

import base64
str = """GET http://www.google.com.hk/search?q=hotels+near+airport&pws=1&igu=1&ip=0.0.0.0&safe=images&gl=CN&gll=39.913889,116.391667&near=china&hl=zh-CN HTTP/1.0\nContent-Length: 0\nUser-Agent: Opera/9.80 (X11; Linux i686; U; en-US) Presto/2.9.173 Version/12.00\nProxy-Authorization: Basic\nAuthorization: Basic\nReferer: http://www.google.com/\n\n"""
base64.decodestring(str)

What is expected:
Exception should be throw as provided string is not encoded with base64. 

What is the result:
We receive some garbage string which hex representation is '\x18D\xe1\xb6\xda\x7f\xff\x0c0\x82\x8a \x95\xe7(\x9a\x19?\xb1\xe6\xabr\x1a'

----------
messages: 199299
nosy: Tymoteusz.Paul
priority: normal
severity: normal
status: open
title: Bas64.decodestring() returns data instead of throwing exception
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Oct  9 16:21:20 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 09 Oct 2013 14:21:20 +0000
Subject: [New-bugs-announce] [issue19209] Remove import copyreg from os
	module
Message-ID: <1381328480.57.0.127685895203.issue19209@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The patch removes "import copyreg" from the os module and moves the registration of the hooks to copyreg. This speeds up the startup of the interpreter a tiny bit.

----------
files: os_no_copyreg.patch
keywords: patch
messages: 199303
nosy: christian.heimes
priority: normal
severity: normal
stage: patch review
status: open
title: Remove import copyreg from os module
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file32020/os_no_copyreg.patch

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

From report at bugs.python.org  Wed Oct  9 18:39:21 2013
From: report at bugs.python.org (Stephen Tucker)
Date: Wed, 09 Oct 2013 16:39:21 +0000
Subject: [New-bugs-announce] [issue19210] Unicode Objects in Tuples
Message-ID: <1381336761.68.0.499147739849.issue19210@psf.upfronthosting.co.za>


New submission from Stephen Tucker:

If a tuple consists of a single unicode object with non-ASCII characters in it, the printing of the tuple causes the non-ASCII characters to appear correctly as characters.

If the tuple contains such a unicode object and anything else (even if it contains nothing else but two or more such unicode objects), the printing of the tuple causes all non-ASCII characters in the objects to appear as their "\uxxxx" escapes instead of as their characters.

The same thing happens when writing such tuples to a file that has been opened using codecs.open (<filename>, 'w', 'utf-8').

----------
components: Windows
messages: 199308
nosy: Stephen_Tucker
priority: normal
severity: normal
status: open
title: Unicode Objects in Tuples
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Oct  9 20:18:04 2013
From: report at bugs.python.org (Ethan Glasser-Camp)
Date: Wed, 09 Oct 2013 18:18:04 +0000
Subject: [New-bugs-announce] [issue19211] from relative_module import seems
	to import wrong module
Message-ID: <1381342684.04.0.290393809096.issue19211@psf.upfronthosting.co.za>


New submission from Ethan Glasser-Camp:

I have a library lib. lib/__init__.py does the following:

    from .subdir import a
    from . import a
    import sys

    print(sys.modules['lib.a'])

This code fails with a KeyError. It seems that despite the second line, lib.a does not get imported. Printing a.__name__ shows lib.subdir.a. Commenting out the first line makes the code work fine, as does moving the code from lib/__init__.py to lib/api.py. This happens under both Python 2.7 and Python 3.3.

Here is my sys.path, sys.meta_path, and sys.path_hooks under Python 2.7:

(['/home/ethan/tmp/import-madness', '/home/ethan/tmp/software/notmuch/bindings/python', '/home/ethan/local/lib/python2.7/site-packages', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/home/ethan/.local/lib/python2.7/site-packages', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PILcompat', '/usr/lib/python2.7/dist-packages/gst-0.10', '/usr/lib/python2.7/dist-packages/gtk-2.0', '/usr/lib/pymodules/python2.7'], [], [<type 'zipimport.zipimporter'>])

The same under Python 3:

['/home/ethan/tmp/import-madness', '/home/ethan/local/lib/python2.7/site-packages', '/usr/lib/python3.3', '/usr/lib/python3.3/plat-x86_64-linux-gnu', '/usr/lib/python3.3/lib-dynload', '/usr/local/lib/python3.3/dist-packages', '/usr/lib/python3/dist-packages'] [<class '_frozen_importlib.BuiltinImporter'>, <class '_frozen_importlib.FrozenImporter'>, <class '_frozen_importlib.PathFinder'>] [<class 'zipimport.zipimporter'>, <function FileFinder.path_hook.<locals>.path_hook_for_FileFinder at 0x7f0728babdd0>]

----------
components: Interpreter Core
files: __init__.py
messages: 199320
nosy: ethan.glasser.camp
priority: normal
severity: normal
status: open
title: from relative_module import seems to import wrong module
type: behavior
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file32022/__init__.py

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

From report at bugs.python.org  Wed Oct  9 23:11:59 2013
From: report at bugs.python.org (Caitlin Potter)
Date: Wed, 09 Oct 2013 21:11:59 +0000
Subject: [New-bugs-announce] [issue19212] Invitation to connect on LinkedIn
Message-ID: <1942377297.24265262.1381353116671.JavaMail.app@ela4-app0130.prod>


New submission from Caitlin Potter:

LinkedIn
------------

Python,

I'd like to add you to my professional network on LinkedIn.

- Caitlin

Caitlin Potter
Freelance Developer at freelance software developer "self employed"
Toronto, Canada Area

Confirm that you know Caitlin Potter:
https://www.linkedin.com/e/-3qcne3-hml1zaap-1f/isd/17195171015/l2fhHe9j/?hs=false&tok=2MQlcG4YvniRY1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-3qcne3-hml1zaap-1f/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I5707467440_1/?hs=false&tok=1rzhxcavbniRY1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

----------
messages: 199343
nosy: Caitlin.Potter
priority: normal
severity: normal
status: open
title: Invitation to connect on LinkedIn

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

From report at bugs.python.org  Wed Oct  9 23:14:58 2013
From: report at bugs.python.org (Alexander Boyd)
Date: Wed, 09 Oct 2013 21:14:58 +0000
Subject: [New-bugs-announce] [issue19213] platform.linux_distribution
	detects Oracle Linux as Red	Hat Enterprise Linux
Message-ID: <1381353298.1.0.0482171871073.issue19213@psf.upfronthosting.co.za>


New submission from Alexander Boyd:

Tested on 3.3.2 and 2.6.6.

On Oracle Linux, platform.linux_distribution detects the current distribution as Red Hat Enterprise Linux:

>>> import platform
>>> platform.linux_distribution()
('Red Hat Enterprise Linux Server', '6.2', 'Santiago')

I would have expected something along the lines of:

>>> import platform
>>> platform.linux_distribution()
('Oracle Linux', '6.2', '')

Or perhaps ('Oracle Linux Server', '6.2', '').

----------
components: Library (Lib)
messages: 199345
nosy: javawizard
priority: normal
severity: normal
status: open
title: platform.linux_distribution detects Oracle Linux as Red Hat Enterprise Linux
type: behavior
versions: Python 2.6, Python 3.3

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

From report at bugs.python.org  Thu Oct 10 10:50:37 2013
From: report at bugs.python.org (Andreas Hilboll)
Date: Thu, 10 Oct 2013 08:50:37 +0000
Subject: [New-bugs-announce] [issue19214] shutil.make_archive should
	recognize extensions in	filenames
Message-ID: <1381395037.28.0.850005234621.issue19214@psf.upfronthosting.co.za>


New submission from Andreas Hilboll:

shutil.make_archive should be able to automatically determine the desired *format* from the given filename. It would make life easier, because the programmer wouldn't need to strip the extension from the filename before passing it to make_archive. I'm think of something along the lines of

        if base_path.lower().endswith(".zip"):
            fmt = "zip"
            base_path = base_path[:-4]
        elif base_path.lower().endswith(".tar.gz") or base_path.lower().endswith(".tgz"):
            fmt = "gztar"
            base_path = base_path[:-7]
        elif base_path.lower().endswith(".tar.bz2"):
            fmt = "bztar"
            base_path = base_path[:-8]
        elif base_path.lower().endswith(".tar"):
            fmt = "tar"
            base_path = base_path[:-4]

----------
messages: 199373
nosy: andreas-h
priority: normal
severity: normal
status: open
title: shutil.make_archive should recognize extensions in filenames
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct 10 11:57:59 2013
From: report at bugs.python.org (=?utf-8?q?Zden=C4=9Bk_Pavlas?=)
Date: Thu, 10 Oct 2013 09:57:59 +0000
Subject: [New-bugs-announce] [issue19215]
	StringIO.StringIO('foo').readline(0) == 'foo'
Message-ID: <1381399079.81.0.443745839975.issue19215@psf.upfronthosting.co.za>


New submission from Zden?k Pavlas:

The behavior contradicts documentation and is inconsistent with both cStringIO and File objects.  Patch attached.

>>> StringIO.StringIO('foo').readline(0)
'foo'
>>> cStringIO.StringIO('foo').readline(0)
''
>>> open('/etc/passwd').readline(0)
''

----------
components: Library (Lib)
files: stringio.patch
keywords: patch
messages: 199376
nosy: Zden?k.Pavlas
priority: normal
severity: normal
status: open
title: StringIO.StringIO('foo').readline(0) == 'foo'
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file32029/stringio.patch

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

From report at bugs.python.org  Thu Oct 10 13:20:50 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 10 Oct 2013 11:20:50 +0000
Subject: [New-bugs-announce] [issue19216] stat cache for import bootstrap
Message-ID: <1381404050.43.0.806301244574.issue19216@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The import library uses excessive stat() calls. I've implemented a simple cache for the bootstrap module that reduces the amount of stat() calls by almost 1/3 (236 -> 159 on Linux).

----------
assignee: brett.cannon
files: import_stat_cache.patch
keywords: patch
messages: 199378
nosy: brett.cannon, christian.heimes
priority: normal
severity: normal
stage: patch review
status: open
title: stat cache for import bootstrap
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file32032/import_stat_cache.patch

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

From report at bugs.python.org  Thu Oct 10 15:04:46 2013
From: report at bugs.python.org (Jacek Bzdak)
Date: Thu, 10 Oct 2013 13:04:46 +0000
Subject: [New-bugs-announce] [issue19217] Calling assertEquals for
	moderately long list takes too	long
Message-ID: <1381410286.72.0.514206486634.issue19217@psf.upfronthosting.co.za>


New submission from Jacek Bzdak:

Call to assertEquals(list1, list2) does not finish (takes more than couple of minutes), for lists that containt 10000 elements if all list elements are different. The same call in python2.6 finishes instanteneously. 

This occours even if error message is truncated using maxDiff.

----------
components: Library (Lib)
files: unittest_scse.py
messages: 199383
nosy: Jacek.Bzdak
priority: normal
severity: normal
status: open
title: Calling assertEquals for moderately long list takes too long
type: resource usage
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file32033/unittest_scse.py

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

From report at bugs.python.org  Thu Oct 10 20:08:01 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 10 Oct 2013 18:08:01 +0000
Subject: [New-bugs-announce] [issue19218] Use of MutableMapping in os module
	slows down	interpreter startup
Message-ID: <1381428481.39.0.771776860266.issue19218@psf.upfronthosting.co.za>


New submission from Eric Snow:

There has been some discussion on python-dev about improving interpreter startup time.  Christian Heimes brought up how the os module imports collections (so _Environ can inherit from it) [1], and mentioned a couple of solutions [2].

[1]https://mail.python.org/pipermail/python-dev/2013-October/129312.html
[2]https://mail.python.org/pipermail/python-dev/2013-October/129367.html

----------
components: Library (Lib)
messages: 199402
nosy: christian.heimes, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Use of MutableMapping in os module slows down interpreter startup
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Oct 10 21:49:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Oct 2013 19:49:12 +0000
Subject: [New-bugs-announce] [issue19219] speed up marshal.loads()
Message-ID: <1381434552.02.0.780065524081.issue19219@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

This patch contains assorted improvements for unmarshalling pyc files. It will also make them ~10% smaller.

$ ./python -m timeit -s "import marshal; d=marshal.dumps(tuple((i, str(i)) for i in range(1000)))" "marshal.loads(d)"

-> 3.4 unpatched: 232 usec per loop
-> 3.4 patched: 96.3 usec per loop
-> 2.7 (for reference): 76.5 usec per loop

----------
components: Interpreter Core
files: marshal_opts4.patch
keywords: patch
messages: 199408
nosy: barry, christian.heimes, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: speed up marshal.loads()
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file32037/marshal_opts4.patch

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

From report at bugs.python.org  Thu Oct 10 22:52:30 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 10 Oct 2013 20:52:30 +0000
Subject: [New-bugs-announce] [issue19220] Outdated unicodedata.__doc__
Message-ID: <1381438350.75.0.839860647652.issue19220@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

Unicode version was updated in 3.3 and 3.4, but unicodedata.__doc__ was not updated.

$ for version in 3.2 3.3 3.4; do python${version} -c 'import unicodedata; print("%s\n\"%s\"\n" % (unicodedata.unidata_version, unicodedata.__doc__))'; done
6.0.0
"This module provides access to the Unicode Character Database which
defines character properties for all Unicode characters. The data in
this database is based on the UnicodeData.txt file version
6.0.0 which is publically available from ftp://ftp.unicode.org/.

The module uses the same names and symbols as defined by the
UnicodeData File Format 6.0.0 (see
http://www.unicode.org/reports/tr44/tr44-6.html)."

6.1.0
"This module provides access to the Unicode Character Database which
defines character properties for all Unicode characters. The data in
this database is based on the UnicodeData.txt file version
6.0.0 which is publically available from ftp://ftp.unicode.org/.

The module uses the same names and symbols as defined by the
UnicodeData File Format 6.0.0 (see
http://www.unicode.org/reports/tr44/tr44-6.html)."
                                                                                                                                                             
6.2.0                                                                                                                                                        
"This module provides access to the Unicode Character Database which                                                                                         
defines character properties for all Unicode characters. The data in                                                                                         
this database is based on the UnicodeData.txt file version                                                                                                   
6.0.0 which is publically available from ftp://ftp.unicode.org/.                                                                                             

The module uses the same names and symbols as defined by the
UnicodeData File Format 6.0.0 (see
http://www.unicode.org/reports/tr44/tr44-6.html)."


URL for 6.1.0: http://www.unicode.org/reports/tr44/tr44-8.html
URL for 6.2.0: http://www.unicode.org/reports/tr44/tr44-10.html

----------
messages: 199411
nosy: Arfrever
priority: normal
severity: normal
status: open
title: Outdated unicodedata.__doc__
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Oct 10 22:54:33 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 10 Oct 2013 20:54:33 +0000
Subject: [New-bugs-announce] [issue19221] Upgrade to Unicode 6.3.0
Message-ID: <1381438473.54.0.298872784227.issue19221@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

Unicode 6.3.0 was released on 2013-09-30.

Please remember to update unicodedata.__doc__.
New URL for unicodedata.__doc__: http://www.unicode.org/reports/tr44/tr44-12.html

----------
messages: 199412
nosy: Arfrever
priority: normal
severity: normal
status: open
title: Upgrade to Unicode 6.3.0
versions: Python 3.4

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

From report at bugs.python.org  Thu Oct 10 23:32:12 2013
From: report at bugs.python.org (Tim Heaney)
Date: Thu, 10 Oct 2013 21:32:12 +0000
Subject: [New-bugs-announce] [issue19222] gzip and 'x' mode open
Message-ID: <1381440732.5.0.887732797238.issue19222@psf.upfronthosting.co.za>


New submission from Tim Heaney:

This is analogous to issue19201, but for gzip. Recent versions of Python have an 'x' mode for open, but gzip doesn't support it. It looks like everything is passed to builtins.open eventually, so if we just allow the 'x' option to pass through, all will be well.

----------
files: patch.gzip.py
messages: 199416
nosy: oylenshpeegul
priority: normal
severity: normal
status: open
title: gzip and 'x' mode open
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32039/patch.gzip.py

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

From report at bugs.python.org  Thu Oct 10 23:34:35 2013
From: report at bugs.python.org (Tim Heaney)
Date: Thu, 10 Oct 2013 21:34:35 +0000
Subject: [New-bugs-announce] [issue19223] bz2 and 'x' mode open
Message-ID: <1381440875.62.0.537853075258.issue19223@psf.upfronthosting.co.za>


New submission from Tim Heaney:

This is analogous to issue19201, but for bz2. Recent versions of Python have an 'x' mode for open, but bz2 doesn't support it. It looks like everything is passed to builtins.open eventually, so if we just allow the 'x' option to pass through, all will be well.

----------
files: patch.bz2.py
messages: 199418
nosy: oylenshpeegul
priority: normal
severity: normal
status: open
title: bz2 and 'x' mode open
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32040/patch.bz2.py

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

From report at bugs.python.org  Fri Oct 11 06:03:41 2013
From: report at bugs.python.org (Qiangning Hong)
Date: Fri, 11 Oct 2013 04:03:41 +0000
Subject: [New-bugs-announce] [issue19224] Make hash(None) consistent among
	processes
Message-ID: <1381464221.0.0.181699047962.issue19224@psf.upfronthosting.co.za>


New submission from Qiangning Hong:

Integers, strings, and bool's hash are all consistent for processes of a same interpreter.  However, hash(None) differs.

$ python -c "print(hash(None))"
272931276
$ python -c "print(hash(None))"
277161420

It's wired and make difficulty for distributed systems partitioning data according hash of keys if the system wants the keys support None.

This patch makes hash(None) always return 0 to resolve that problem.  And it is used in DPark(Python clone of Spark, a MapReduce alike framework in Python, https://github.com/douban/dpark) to speed up portable hash (see line https://github.com/douban/dpark/blob/65a3ba857f11285667c61e2e134dacda44c13a2c/dpark/util.py#L47).

davies.liu at gmail.com is the original author of this patch.  All credit goes to him.

----------
messages: 199439
nosy: hongqn
priority: normal
severity: normal
status: open
title: Make hash(None) consistent among processes

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

From report at bugs.python.org  Fri Oct 11 12:02:57 2013
From: report at bugs.python.org (hiroaki itoh)
Date: Fri, 11 Oct 2013 10:02:57 +0000
Subject: [New-bugs-announce] [issue19225] lack of PyExc_BufferError doc
Message-ID: <1381485777.95.0.364414099437.issue19225@psf.upfronthosting.co.za>


New submission from hiroaki itoh:

http://docs.python.org/2.7/c-api/exceptions.html#standard-exceptions

Python2.7 (at least 2.7.5) has PyExc_BufferError, but the document does not tell it.

----------
assignee: docs at python
components: Documentation
messages: 199458
nosy: docs at python, xwhhsprings
priority: normal
severity: normal
status: open
title: lack of PyExc_BufferError doc
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Oct 11 18:31:15 2013
From: report at bugs.python.org (W. Trevor King)
Date: Fri, 11 Oct 2013 16:31:15 +0000
Subject: [New-bugs-announce] [issue19226] distutils/command/upload.py show
	response gives:	TypeError: sequence item 1: expected str
	instance, bytes found
Message-ID: <1381509075.7.0.951655438313.issue19226@psf.upfronthosting.co.za>


New submission from W. Trevor King:

Avoid:

    Traceback (most recent call last):
      File "setup.py", line 61, in <module>
        'html2text (>=3.0.1)',
      File "/.../python3.2/distutils/core.py", line 148, in setup
        dist.run_commands()
      File "/.../python3.2/distutils/dist.py", line 917, in run_commands
        self.run_command(cmd)
      File "/.../python3.2/distutils/dist.py", line 936, in run_command
        cmd_obj.run()
      File "/.../python3.2/distutils/command/upload.py", line 66, in run
        self.upload_file(command, pyversion, filename)
      File "/.../python3.2/distutils/command/upload.py", line 201, in upload_file
        msg = '\n'.join(('-' * 75, r.read(), '-' * 75))
    TypeError: sequence item 1: expected str instance, bytes found

by converting the bytes returned by HTTPResponse.read [1] to a string
before joinging it with other strings.  HTTPResponse.headers supports
the Message interface [2], so we can use get_param to extract the
charset [3], falling back on ISO-8859-1 [4].

[1]: http://docs.python.org/3/library/http.client.html#http.client.HTTPResponse.read
[2]: http://docs.python.org/3/library/http.client.html#httpmessage-objects
[3]: http://docs.python.org/3/library/email.message.html#email.message.Message.get_param
[4]: http://tools.ietf.org/html/rfc2616#section-3.7.1

----------
assignee: eric.araujo
components: Distutils
files: show-response-string.patch
keywords: patch
messages: 199489
nosy: eric.araujo, labrat, tarek
priority: normal
severity: normal
status: open
title: distutils/command/upload.py show response gives: TypeError: sequence item 1: expected str instance, bytes found
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file32045/show-response-string.patch

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

From report at bugs.python.org  Fri Oct 11 20:51:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Oct 2013 18:51:12 +0000
Subject: [New-bugs-announce] [issue19227] test_multiprocessing_xxx hangs
	under Gentoo buildbots
Message-ID: <1381517472.99.0.071022574131.issue19227@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

test_multiprocessing has started to hang frequently on the Gentoo buildbots.

It seems it has started happening with the "OpenSSL re-seeding" commits:
http://hg.python.org/cpython/rev/8e1194c39beddb83337c0acb9e4c2922a02a36cf

David, could you try to investigate on the buildbot? If this security fix can crash some machines, we'd better find a workaround.

----------
components: Interpreter Core, Library (Lib), Tests
keywords: buildbot
messages: 199497
nosy: christian.heimes, pitrou, r.david.murray, sbt
priority: critical
severity: normal
status: open
title: test_multiprocessing_xxx hangs under Gentoo buildbots
type: crash
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Oct 12 00:56:52 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Oct 2013 22:56:52 +0000
Subject: [New-bugs-announce] [issue19228] type.__qualname__ should not strip
	the module name
Message-ID: <1381532212.21.0.0772191194155.issue19228@psf.upfronthosting.co.za>


New submission from STINNER Victor:

type.__qualname__ getter type_qualname() calls type_name() which strips the module name from the type name (type->tp_name).

Attached patch fixes this.

----------
files: type_qualname.patch
keywords: patch
messages: 199518
nosy: haypo
priority: normal
severity: normal
status: open
title: type.__qualname__ should not strip the module name
versions: Python 3.4
Added file: http://bugs.python.org/file32052/type_qualname.patch

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

From report at bugs.python.org  Sat Oct 12 01:49:11 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Oct 2013 23:49:11 +0000
Subject: [New-bugs-announce] [issue19229] operator.py: move the Python
	implementation in the else	block of try/except ImportError
Message-ID: <1381535351.94.0.0685942795619.issue19229@psf.upfronthosting.co.za>


New submission from STINNER Victor:

To speedup Python startup, it may be interesting to not create useless many functions and classes in operator.py: "from _operator import *" will remove them a few line later.

What do you think of moving the Python implementation of the operator module inside in the else block of "try/except ImportError" section?

See attached operator.py for an example.

It adds an ugly level of indentation, but it's for performances!

Another option is to add a _pyoperator module.

----------
files: operator.py
messages: 199525
nosy: christian.heimes, haypo
priority: normal
severity: normal
status: open
title: operator.py: move the Python implementation in the else block of try/except ImportError
versions: Python 3.4
Added file: http://bugs.python.org/file32053/operator.py

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

From report at bugs.python.org  Sat Oct 12 02:33:11 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 12 Oct 2013 00:33:11 +0000
Subject: [New-bugs-announce] [issue19230] Reimplement the keyword module in C
Message-ID: <1381537991.31.0.762180400628.issue19230@psf.upfronthosting.co.za>


New submission from STINNER Victor:

To speedup Python startup, I propose to reimplement the keyword module in C. Attached patch implements it.

* Remove Lib/keyword.py
* Add Tools/scripts/keyword.py: script to build Modules/keyword.h
* The new module is Modules/keyword.c

I chose to change the keyword.kwlist type from list to tuple. The documentation only says they that kwlist is a "Sequence":
http://docs.python.org/dev/library/keyword.html#keyword.kwlist

The keyword is now used by the collections module in the implementation of namedtuple.

The keyword module is trivial: it only contains a sequence of strings and a method checking if a string is part of this sequence. It would be simpler to add this to an existing module. I suppose that a new module was added for technical reasons.

----------
files: keyword.patch
keywords: patch
messages: 199528
nosy: christian.heimes, haypo, pitrou
priority: normal
severity: normal
status: open
title: Reimplement the keyword module in C
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file32054/keyword.patch

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

From report at bugs.python.org  Sat Oct 12 14:02:49 2013
From: report at bugs.python.org (FreedomKnight)
Date: Sat, 12 Oct 2013 12:02:49 +0000
Subject: [New-bugs-announce] [issue19231] ctype cant's use printf
Message-ID: <1381579369.49.0.578493785687.issue19231@psf.upfronthosting.co.za>


New submission from FreedomKnight:

the code is simple, so i paste all of mycode

    #!/usr/bin/env python3
    from ctypes import *

    cdll.LoadLibrary("libc.so.6")
    libc = CDLL("libc.so.6")
    libc.printf("hello\n")

result:
h

expect result:
hello

plateform:
fedora 19 x64
python3 (3.3.2)

----------
components: ctypes
messages: 199552
nosy: FreedomKnight
priority: normal
severity: normal
status: open
title: ctype cant's use printf
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Sat Oct 12 14:03:19 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 12 Oct 2013 12:03:19 +0000
Subject: [New-bugs-announce] [issue19232] Speed up _decimal import
Message-ID: <1381579399.63.0.316110193187.issue19232@psf.upfronthosting.co.za>


New submission from Stefan Krah:

As discussed on python-dev, importing _decimal at the bottom of
decimal.py is about 9x slower than importing _decimal directly.

----------
assignee: skrah
components: Extension Modules
messages: 199553
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: Speed up _decimal import
type: performance
versions: Python 3.4

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

From report at bugs.python.org  Sat Oct 12 14:54:42 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 12 Oct 2013 12:54:42 +0000
Subject: [New-bugs-announce] [issue19233]
	test_io.test_interrupted_write_retry_text() hangs on	Solaris
	10 and FreeBSD 7.2
Message-ID: <1381582482.49.0.0638429802819.issue19233@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/x86%20FreeBSD%207.2%203.x/builds/4531/steps/test/logs/stdio


[136/380] test_io
Timeout (1:00:00)!
Thread 0x28401040:
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_io.py", line 3215 in check_interrupted_write_retry
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_io.py", line 3237 in test_interrupted_write_retry_text
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 571 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 610 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 117 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 79 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 117 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 79 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 117 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 79 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/runner.py", line 168 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support/__init__.py", line 1661 in _run_suite
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support/__init__.py", line 1695 in run_unittest
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/regrtest.py", line 1275 in <lambda>
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/regrtest.py", line 1276 in runtest_inner
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/regrtest.py", line 965 in runtest
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/regrtest.py", line 761 in main
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/regrtest.py", line 1560 in main_in_temp_cwd
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/__main__.py", line 3 in <module>
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/runpy.py", line 73 in _run_code
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/runpy.py", line 160 in _run_module_as_main


and

http://buildbot.python.org/all/builders/SPARC%20Solaris%2010%20%28cc%2C%2064b%29%20%5BSB%5D%203.x/builds/980/steps/test/logs/stdio

[324/377/2] test_io
Timeout (1:00:00)!
Thread 0x0000000000000001:
  File "/home/cpython/buildslave/cc-64/3.x.snakebite-sol10-sparc-cc-64/build/Lib/test/test_io.py", line 3215 in check_interrupted_write_retry
  File "/home/cpython/buildslave/cc-64/3.x.snakebite-sol10-sparc-cc-64/build/Lib/test/test_io.py", line 3237 in test_interrupted_write_retry_text
  File "/home/cpython/buildslave/cc-64/3.x.snakebite-sol10-sparc-cc-64/build/Lib/unittest/case.py", line 496 in run
  File "/home/cpython/buildslave/cc-64/3.x.snakebite-sol10-sparc-cc-64/build/Lib/unittest/case.py", line 535 in __call__
  File "/home/cpython/buildslave/cc-64/3.x.snakebite-sol10-sparc-cc-64/build/Lib/unittest/suite.py", line 105 in run
  File "/home/cpython/buildslave/cc-64/3.x.snakebite-sol10-sparc-cc-64/build/Lib/unittest/suite.py", line 67 in __call__
  File "/home/cpython/buildslave/cc-64/3.x.snakebite-sol10-sparc-cc-64/build/Lib/unittest/suite.py", line 105 in run
  File "/home/cpython/buildslave/cc-64/3.x.snakebite-sol10-sparc-cc-64/build/Lib/unittest/suite.py", line 67 in __call__
  File "/home/cpython/buildslave/cc-64/3.x.snakebite-sol10-sparc-cc-64/build/Lib/unittest/suite.py", line 105 in run
  File "/home/cpython/buildslave/cc-64/3.x.snakebite-sol10-sparc-cc-64/build/Lib/unittest/suite.py", line 67 in __call__
  File "/home/cpython/buildslave/cc-64/3.x.snakebite-sol10-sparc-cc-64/build/Lib/unittest/runner.py", line 168 in run
  File "/home/cpython/buildslave/cc-64/3.x.snakebite-sol10-sparc-cc-64/build/Lib/test/support/__init__.py", line 1624 in _run_suite
  File "/home/cpython/buildslave/cc-64/3.x.snakebite-sol10-sparc-cc-64/build/Lib/test/support/__init__.py", line 1658 in run_unittest
  File "/home/cpython/buildslave/cc-64/3.x.snakebite-sol10-sparc-cc-64/build/Lib/test/regrtest.py", line 1304 in <lambda>
  File "/home/cpython/buildslave/cc-64/3.x.snakebite-sol10-sparc-cc-64/build/Lib/test/regrtest.py", line 1305 in runtest_inner
  File "/home/cpython/buildslave/cc-64/3.x.snakebite-sol10-sparc-cc-64/build/Lib/test/regrtest.py", line 998 in runtest
  File "/home/cpython/buildslave/cc-64/3.x.snakebite-sol10-sparc-cc-64/build/Lib/test/regrtest.py", line 796 in main
  File "/home/cpython/buildslave/cc-64/3.x.snakebite-sol10-sparc-cc-64/build/Lib/test/regrtest.py", line 1590 in main_in_temp_cwd
  File "/home/cpython/buildslave/cc-64/3.x.snakebite-sol10-sparc-cc-64/build/Lib/test/__main__.py", line 3 in <module>
  File "/home/cpython/buildslave/cc-64/3.x.snakebite-sol10-sparc-cc-64/build/Lib/runpy.py", line 73 in _run_code
  File "/home/cpython/buildslave/cc-64/3.x.snakebite-sol10-sparc-cc-64/build/Lib/runpy.py", line 160 in _run_module_as_main

----------
messages: 199561
nosy: haypo
priority: normal
severity: normal
status: open
title: test_io.test_interrupted_write_retry_text() hangs on Solaris 10 and FreeBSD 7.2
versions: Python 3.4

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

From report at bugs.python.org  Sat Oct 12 18:33:57 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 12 Oct 2013 16:33:57 +0000
Subject: [New-bugs-announce] [issue19234] socket.fileno() documentation
In-Reply-To: <1984648.JD0MPFlghQ@noisy.pr41.sk>
Message-ID: <52597A2F.60807@python.org>


New submission from Georg Brandl:

-------- Original-Nachricht --------
Betreff: [docs] socket.fileno() documentation
Datum: Thu, 10 Oct 2013 19:27:35 +0200
Von: Vlado Potisk <vlado at poti.sk>
An: docs at python.org

I might be wrong but in my opinion the socket library documentation is not
clear enough regarding the behaviour of the fileno() method in a case of a
failure.

In the Python 3.2 socket library documentation there is:
----
exception socket.error

    A subclass of IOError, this exception is raised for socket-related errors.
-----
 socket.close()

    Close the socket. All future operations on the socket object will fail.
----
 socket.fileno()

    Return the socket?s file descriptor (a small integer).
----

Based on the information quoted above, I wrote a test if a socket is active or
if it has been closed already:

try:
	sock.fileno()
except socket.error:
	return False
return True

But is doesn't work. I have found out that fileno() returns -1 on a closed
socket. Replacing fileno() with e.g. getsockname() fixes the code.

It looks like a fileno's failure - unlike to getsockname's failure - is not
expressed by raising an exception, but by returning -1. However this seems to
be not documented and that's why I'm unsure if I may rely on this.

----------
assignee: docs at python
components: Documentation
messages: 199592
nosy: docs at python, georg.brandl
priority: normal
severity: normal
status: open
title: socket.fileno() documentation

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

From report at bugs.python.org  Sat Oct 12 18:41:47 2013
From: report at bugs.python.org (Elazar Gershuni)
Date: Sat, 12 Oct 2013 16:41:47 +0000
Subject: [New-bugs-announce] [issue19235] Add a dedicated subclass for
	recursion errors
Message-ID: <1381596107.9.0.320701037292.issue19235@psf.upfronthosting.co.za>


New submission from Elazar Gershuni:

There's no dedicated StackOverflowErrorException, So there is no way to accurately distinguish a recursion overflow from a general RuntimeError. 

One cannot use the exception message, since the docs explicitly says that "Exception messages are not part of the Python API", and checking for

    len(traceback.extract_tb(trace)) >= sys.getrecursionlimit()-1

is ugly, and (AFAIK) not guaranteed to be correct.

Use case: I've found this while trying to create a cycle detector that will compress the traceback of such errors.

See discussion in python-ideas:
https://mail.python.org/pipermail/python-ideas/2013-September/023190.html

An cycle-detection implementation:
http://code.activestate.com/recipes/578660-concise-output-for-maximum-recursion-depth-exceede/

----------
components: Library (Lib)
messages: 199595
nosy: elazar
priority: normal
severity: normal
status: open
title: Add a dedicated subclass for recursion errors
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Oct 12 21:15:31 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Oct 2013 19:15:31 +0000
Subject: [New-bugs-announce] [issue19236] Add Tornado HTTP benchmark
Message-ID: <1381605331.62.0.22076893629.issue19236@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Tornado 3.1.1 is compatible with Python 2.6, 2.7, 3.2 and upwards, which makes it a good candidate for a networking benchmark.

Here is a patch adding a HTTP (server + client) benchmark. A trivial HTTP server is spawned which writes a sizable body in response to requests. HTTP clients then connect with a certain amount of concurrency and fetch the HTTP server's resource.

(note: the patch omits the Tornado lib itself for readability)

----------
files: tornado_bench.patch
keywords: patch
messages: 199613
nosy: brett.cannon, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Add Tornado HTTP benchmark
type: enhancement
versions: 3rd party
Added file: http://bugs.python.org/file32067/tornado_bench.patch

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

From report at bugs.python.org  Sat Oct 12 23:39:45 2013
From: report at bugs.python.org (CliffM)
Date: Sat, 12 Oct 2013 21:39:45 +0000
Subject: [New-bugs-announce] [issue19237] Proposal : LCM function to
	complement GCD
Message-ID: <1381613985.13.0.579421159234.issue19237@psf.upfronthosting.co.za>


New submission from CliffM:

While implementing a Least-Common-Multiple function (LCM), I noticed that although python has a Greatest-Common-Divisor (GCD) function in the fractions module, the LCM, its counterpart is not there.

I've attached a patch which implements and tests LCM in the fractions module. 

It would really need documentation, but maybe GCD and LCD should be moved to the math module first ?

----------
components: Extension Modules
files: lcm.patch
keywords: patch
messages: 199624
nosy: CliffM
priority: normal
severity: normal
status: open
title: Proposal : LCM function to complement GCD
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32068/lcm.patch

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

From report at bugs.python.org  Sun Oct 13 00:27:49 2013
From: report at bugs.python.org (David Chambers)
Date: Sat, 12 Oct 2013 22:27:49 +0000
Subject: [New-bugs-announce] [issue19238] Misleading explanation of fill and
	align in format_spec
Message-ID: <1381616869.75.0.196962613989.issue19238@psf.upfronthosting.co.za>


New submission from David Chambers:

>From http://docs.python.org/3/library/string.html#formatspec:

> The presence of a fill character is signaled by the character
> following it, which must be one of the alignment options. If the
> second character of format_spec is not a valid alignment option,
> then it is assumed that both the fill character and the alignment
> option are absent.

The fact that the second character in the format_spec is not an
alignment option is not sufficient to declare that the alignment
option is absent: the alignment option may be the first character
in the format_spec. For example:

    >>> '{:^10}'.format(42)
    '    42    '

I suggest the following wording:

The presence of a fill character is signaled by the character
following it, which must be one of the alignment options. Unless
the second character of format_spec is a valid alignment option,
the fill character is assumed to be absent.

----------
assignee: docs at python
components: Documentation
messages: 199633
nosy: davidchambers, docs at python
priority: normal
severity: normal
status: open
title: Misleading explanation of fill and align in format_spec

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

From report at bugs.python.org  Sun Oct 13 00:35:29 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 12 Oct 2013 22:35:29 +0000
Subject: [New-bugs-announce] [issue19239] add inspect functions to
Message-ID: <1381617329.76.0.628803647816.issue19239@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: ethan.furman
priority: normal
severity: normal
status: open
title: add inspect functions to

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

From ethan at stoneleaf.us  Sun Oct 13 00:39:34 2013
From: ethan at stoneleaf.us (Ethan Furman)
Date: Sat, 12 Oct 2013 15:39:34 -0700
Subject: [New-bugs-announce] [issue19239] add inspect functions to
 retrieve attributes from both old dir() and overridden dir()
In-Reply-To: <1381617329.76.0.628803647816.issue19239@psf.upfronthosting.co.za>
References: <1381617329.76.0.628803647816.issue19239@psf.upfronthosting.co.za>
Message-ID: <5259CFA6.1010501@stoneleaf.us>

Sorry, finger hit <enter> too soon.

Here's the text:

Currently we have

   - inspect.getmembers
   - inspect.classify_class_attrs

But they only return what dir() returns.

It is proposed that we add

   - inspect.get_all_members
   - inspect.classify_all_class_attrs

which will look at all the attributes returned by both the original dir() and the overridden dir().

From report at bugs.python.org  Sun Oct 13 03:42:58 2013
From: report at bugs.python.org (Miki Tebeka)
Date: Sun, 13 Oct 2013 01:42:58 +0000
Subject: [New-bugs-announce] [issue19240] iglob should try to use `readdir`
Message-ID: <1381628578.0.0.047697770755.issue19240@psf.upfronthosting.co.za>


New submission from Miki Tebeka:

Currently glob.iglob calls os.listdir internally. Which means that if there are many files in the directory - a big list of them is created in memory.

iglob should try to use readdir and be a "true" iterator, not consuming a lot of memory.

See one possible implementation using ctypes at http://stackoverflow.com/questions/4403598/list-files-in-a-folder-as-a-stream-to-begin-process-immediately

----------
components: Library (Lib)
messages: 199649
nosy: tebeka
priority: normal
severity: normal
status: open
title: iglob should try to use `readdir`
type: performance
versions: Python 3.4

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

From report at bugs.python.org  Sun Oct 13 12:55:24 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 13 Oct 2013 10:55:24 +0000
Subject: [New-bugs-announce] [issue19241] MINGW: install import library
Message-ID: <1381661724.71.0.909185396021.issue19241@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Enhancement of issue3871 - installation

----------
components: Installation
files: 0001-MINGW-install-import-library.patch
keywords: patch
messages: 199689
nosy: rpetrov
priority: normal
severity: normal
status: open
title: MINGW: install import library
versions: Python 3.4
Added file: http://bugs.python.org/file32085/0001-MINGW-install-import-library.patch

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

From report at bugs.python.org  Sun Oct 13 12:57:09 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 13 Oct 2013 10:57:09 +0000
Subject: [New-bugs-announce] [issue19242] MINGW: generalization of posix
	installation in distutils
Message-ID: <1381661829.44.0.682603781281.issue19242@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Enhancement of issue3871 - installation

----------
files: 0002-MINGW-generalization-of-posix-installation-in-distut.patch
keywords: patch
messages: 199690
nosy: rpetrov
priority: normal
severity: normal
status: open
title: MINGW: generalization of posix installation in distutils
Added file: http://bugs.python.org/file32086/0002-MINGW-generalization-of-posix-installation-in-distut.patch

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

From report at bugs.python.org  Sun Oct 13 13:00:20 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 13 Oct 2013 11:00:20 +0000
Subject: [New-bugs-announce] [issue19243] MINGW: support stdcall without
	underscore
Message-ID: <1381662020.61.0.491449073615.issue19243@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Split of issue3871

----------
components: Extension Modules, Installation
files: 0003-MINGW-support-stdcall-without-underscore.patch
keywords: patch
messages: 199692
nosy: rpetrov
priority: normal
severity: normal
status: open
title: MINGW: support stdcall without underscore
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32087/0003-MINGW-support-stdcall-without-underscore.patch

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

From report at bugs.python.org  Sun Oct 13 13:02:49 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 13 Oct 2013 11:02:49 +0000
Subject: [New-bugs-announce] [issue19244] MINGW: use replace instead rename
	to avoid failure on	windows
Message-ID: <1381662169.98.0.886605409124.issue19244@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Enhancement of issue3871 - installation

----------
components: Installation
files: 0004-use-replace-instead-rename-to-avoid-failure-on-windo.patch
keywords: patch
messages: 199693
nosy: rpetrov
priority: normal
severity: normal
status: open
title: MINGW: use replace instead rename to avoid failure on windows
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32088/0004-use-replace-instead-rename-to-avoid-failure-on-windo.patch

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

From report at bugs.python.org  Sun Oct 13 13:06:00 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 13 Oct 2013 11:06:00 +0000
Subject: [New-bugs-announce] [issue19245] mingw-meta: installation
Message-ID: <1381662360.07.0.972595151036.issue19245@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

this is meta issue for enhancement of issue3871 -  part related to installation. Remark: build of  core modules is in issue18653 .

01 : issue19241 : install import library
02 : issue19242 : generalization of posix installation in distutils
03 : issue19243 : support stdcall without underscore
04 : issue19244 : use replace instead rename to avoid failure on windows

----------
components: Installation
messages: 199694
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw-meta: installation
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Oct 13 14:00:01 2013
From: report at bugs.python.org (=?utf-8?b?0J/RkdGC0YAg0JTRkdC80LjQvQ==?=)
Date: Sun, 13 Oct 2013 12:00:01 +0000
Subject: [New-bugs-announce] [issue19246] GC does not really free up memory
	in console
Message-ID: <1381665601.5.0.467418586985.issue19246@psf.upfronthosting.co.za>


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

Taken from http://stackoverflow.com/a/19287553/135079
When I consume all memory:


    Python 2.7 (r27:82525, Jul  4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> a = {}
    >>> for k in xrange(1000000): a['a' * k] = k
    ...
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    MemoryError
    >>> len(a)
    64036

If we'll take summary keys length:

    >>> log(sum(xrange(64036)), 2)
    30.93316861532543

we'll get near 32-bit integer overflow. After that done,

    >>> a = {}

will free all 2 Gb of allocated memory (as shown in Task Manager), but executing:

    >>> for k in xrange(1000000): a[k] = k

Will cause:

    MemoryError

And dictionary length something like:

    >>> len(a)
    87382

----------
components: Windows
messages: 199698
nosy: ????.?????
priority: normal
severity: normal
status: open
title: GC does not really free up memory in console
type: resource usage
versions: Python 2.7

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

From report at bugs.python.org  Sun Oct 13 16:12:57 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 13 Oct 2013 14:12:57 +0000
Subject: [New-bugs-announce] [issue19247] Describe surrogateescape algorithm
	in the Library	Reference
Message-ID: <1381673577.83.0.634006615694.issue19247@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

The codecs module currently refers out to PEP 383 as the documentation for the details of the ``surrogateescape`` error handler.

Instead (as per the recent python-dev discussion about not using PEPs as substitutes for reference docs), there should be a section providing details on surrogateescape directly in the library reference for the codecs module.

This may involve breaking out the current table of standard error handlers under its own heading rather than including it in the intro to codec base classes. Then the detailed description of surrogateescape could go under a dedicated subheading.

----------
messages: 199707
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Describe surrogateescape algorithm in the Library Reference
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Oct 13 21:09:31 2013
From: report at bugs.python.org (Nick Guenther)
Date: Sun, 13 Oct 2013 19:09:31 +0000
Subject: [New-bugs-announce] [issue19248] sphinx is not py3k compatible
Message-ID: <1381691371.24.0.619813163861.issue19248@psf.upfronthosting.co.za>


New submission from Nick Guenther:

I'm running Arch. I just checked out python's hg and tried to build the docs, and found that I couldn't:

$ cd cpython/doc
$ make update
[lots of output stripped]
$ make pydoc-topics
mkdir -p build/pydoc-topics build/doctrees
python tools/sphinx-build.py -b pydoc-topics -d build/doctrees -D latex_paper_size=  . build/pydoc-topics 
Traceback (most recent call last):
  File "tools/sphinx-build.py", line 27, in <module>
    from sphinx import main
  File "/home/kousu/pro/cpython/Doc/tools/sphinx/__init__.py", line 44
    except ImportError, err:
                      ^
SyntaxError: invalid syntax
make: *** [build] Error 1

I edited the Makefile to say PYTHON       = python2
and then it worked. Is the assumption that python2 is still supposed to be the default python everywhere? Is python 3 not able to build itself yet?



[kousu at galleon Doc]$ pacman -Qi python
Name           : python
Version        : 3.3.2-2
Description    : Next generation of the python high-level scripting language
Architecture   : x86_64
URL            : http://www.python.org/
Licenses       : custom
Groups         : None
Provides       : python3
Depends On     : expat  bzip2  gdbm  openssl  libffi  zlib
Optional Deps  : tk: for tkinter [installed]
                 sqlite [installed]
Required By    : cython  ipython  ktoblzcheck  libreoffice-common  python-cairo  python-dateutil  python-dbus  python-markupsafe
                 python-numpy  python-pyparsing  python-pytz  python-pyzmq  python-setuptools  python-sip  python-six  python-sympy
                 python-tornado  python-xdg  ranger  youtube-dl
Optional For   : systemd
Conflicts With : None
Replaces       : python3
Installed Size : 86980.00 KiB
Packager       : Bart
Build Date     : Fri Sep 6 03:31:57 2013
Install Date   : Tue Sep 17 10:29:36 2013
Install Reason : Installed as a dependency for another package
Install Script : No
Validated By   : Signature

----------
assignee: docs at python
components: Documentation
messages: 199764
nosy: docs at python, kousu
priority: normal
severity: normal
status: open
title: sphinx is not py3k compatible
versions: 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/issue19248>
_______________________________________

From report at bugs.python.org  Sun Oct 13 21:38:20 2013
From: report at bugs.python.org (CliffM)
Date: Sun, 13 Oct 2013 19:38:20 +0000
Subject: [New-bugs-announce] [issue19249] Enumeration.__eq__
Message-ID: <1381693100.88.0.523701824631.issue19249@psf.upfronthosting.co.za>


New submission from CliffM:

Given that enumeration members are Singletons, can we not rely on the default
__eq__() method ?  (FWIW the existing tests all pass if you delete it)

This might be confusing for a reader later, so needs documenting.  Although I think it should be documented (in enum.py) either way.

Maybe also add a singletoness test ?

def test_singleton(self):
        class A(Enum):
            X=1
            Y=2

        self.assertTrue(id(A.X)==id(A.X))


Of course there is good chance that there is a test-case I have not thought of that will defeat this.  I am thinking about :

a) weak-ref handling of Enums 

b) unpickling, say by a user of the ZODB

Which might break the singletonicity. ??  Any offers ??

----------
components: Tests
messages: 199774
nosy: CliffM
priority: normal
severity: normal
status: open
title: Enumeration.__eq__
versions: Python 3.4

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

From report at bugs.python.org  Sun Oct 13 21:40:35 2013
From: report at bugs.python.org (Nick Guenther)
Date: Sun, 13 Oct 2013 19:40:35 +0000
Subject: [New-bugs-announce] [issue19250] Duplicate import documentation in
	py3k
Message-ID: <1381693235.0.0.590158180035.issue19250@psf.upfronthosting.co.za>


New submission from Nick Guenther:

Python3's docs given by
>> help("import")

duplicate these two paragraphs:
"The *public names* defined by a module are determined by checking the
module's namespace for a variable named ``__all__``; if defined, it
must be a sequence of strings which are names defined or imported by
that module.  The names given in ``__all__`` are all considered public
and are required to exist.  If ``__all__`` is not defined, the set of
public names includes all names found in the module's namespace which
do not begin with an underscore character (``'_'``).  ``__all__``
should contain the entire public API. It is intended to avoid
accidentally exporting items that are not part of the API (such as
library modules which were imported and used within the module).

The ``from`` form with ``*`` may only occur in a module scope.
Attempting to use it in class or function definitions will raise a
``SyntaxError``."

(full output attached for proof)

Digging through the sources, I can't find where this is defined. The python2 on my system has the same two paragraphs but they are *not* duplicated there, and in the sources, which admittedly I don't know my way around, Doc/reference/simple_stmts.rst contains these paragraphs but only once each, and grep seems to imply this is the source of them.

Did sphinx screw up somewhere between your hg and my distro mirror?

Here's my version info (arch linux, 64 bit)
[kousu at galleon ~]$ pacman -Qi python
Name           : python
Version        : 3.3.2-2
Description    : Next generation of the python high-level scripting language
Architecture   : x86_64
URL            : http://www.python.org/
Licenses       : custom
Groups         : None
Provides       : python3
Depends On     : expat  bzip2  gdbm  openssl  libffi  zlib
Optional Deps  : tk: for tkinter [installed]
                 sqlite [installed]
Required By    : cython  ipython  ktoblzcheck  libreoffice-common  python-cairo  python-dateutil  python-dbus  python-markupsafe
                 python-numpy  python-pyparsing  python-pytz  python-pyzmq  python-setuptools  python-sip  python-six  python-sympy
                 python-tornado  python-xdg  ranger  youtube-dl
Optional For   : systemd
Conflicts With : None
Replaces       : python3
Installed Size : 86980.00 KiB
Packager       : Bart
Build Date     : Fri Sep 6 03:31:57 2013
Install Date   : Tue Sep 17 10:29:36 2013
Install Reason : Installed as a dependency for another package
Install Script : No
Validated By   : Signature

----------
assignee: docs at python
components: Documentation
files: The ``import`` statement - (2013-10-13 15:36:07)
messages: 199775
nosy: docs at python, kousu
priority: normal
severity: normal
status: open
title: Duplicate import documentation in py3k
versions: Python 3.3
Added file: http://bugs.python.org/file32096/The ``import`` statement - (2013-10-13 15:36:07)

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

From report at bugs.python.org  Sun Oct 13 22:07:27 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 13 Oct 2013 20:07:27 +0000
Subject: [New-bugs-announce] [issue19251] bitwise ops for bytes of equal
	length
Message-ID: <1381694847.24.0.709324715816.issue19251@psf.upfronthosting.co.za>


New submission from Christian Heimes:

I like to propose a new feature for bytes and perhaps bytearray. None of the bytes types support bitwise operations like &, | and ^. I like to add the bitwise protocol between byte objects of equal length:

>>> a, b = b"123", b"abc"
>>> bytes(x ^ y for x, y in zip(a, b)) 
b'PPP'
>>> a ^ b
b'PPP'

----------
components: Interpreter Core
messages: 199785
nosy: christian.heimes
priority: normal
severity: normal
stage: needs patch
status: open
title: bitwise ops for bytes of equal length
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Oct 13 22:51:42 2013
From: report at bugs.python.org (CliffM)
Date: Sun, 13 Oct 2013 20:51:42 +0000
Subject: [New-bugs-announce] [issue19252] Enum.py : Enum.__new__() : Test
	Coverage
Message-ID: <1381697502.11.0.490856984285.issue19252@psf.upfronthosting.co.za>


New submission from CliffM:

test_nonhash_value tests the lookup of an Enum Member from a value.

The current test does not exercise the iteration over values completely -- the if-clause being redundant wrt the existing test.

My patch adds an additional test which requires the if-clause.

----------
components: Extension Modules, Tests
files: enum.patch
keywords: patch
messages: 199800
nosy: CliffM
priority: normal
severity: normal
status: open
title: Enum.py : Enum.__new__() : Test Coverage
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32099/enum.patch

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

From report at bugs.python.org  Sun Oct 13 23:08:13 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 13 Oct 2013 21:08:13 +0000
Subject: [New-bugs-announce] [issue19253] PyArg_ParseTuple: wrong use of
	seterror() clips helpful	type error annotation
Message-ID: <1381698493.04.0.861687446453.issue19253@psf.upfronthosting.co.za>


New submission from Georg Brandl:

Follow-up to #6624. This issue changed a call to seterror() whose last argument is supposed to be NULL or a "custom error message" given by the ";message" format character.  This had two effects:

* the custom message (if present) is never printed
* the helpful "function() argument X " is omitted and only "must be str, not int" remains

>>> format(None, 1)     # current behavior
TypeError: must be str, not int
>>> format(None, 1)     # with #6624 reverted (= patch to this issue applied)
TypeError: format() argument 2 must be str, not int



Almost all uses of the ";" format code are currently broken: the strings must give a complete message, but only give a description of the expected arguments.  Most of them should probably just be removed.

----------
components: Interpreter Core
files: seterror_fix.patch
keywords: patch
messages: 199804
nosy: benjamin.peterson, georg.brandl, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: PyArg_ParseTuple: wrong use of seterror() clips helpful type error annotation
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32100/seterror_fix.patch

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

From report at bugs.python.org  Sun Oct 13 23:31:20 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 13 Oct 2013 21:31:20 +0000
Subject: [New-bugs-announce] [issue19254] Python implementation of
	PBKDF2_HMAC
Message-ID: <1381699880.62.0.48701357342.issue19254@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The patch provides a Python implementation of pbkdf2_hmac with Python's hmac module. Although I'm using some tricks it's more than six times slower than OpenSSL's implementation.

----------
files: pbkdf2_py.patch
keywords: patch
messages: 199808
nosy: christian.heimes
priority: normal
severity: normal
stage: patch review
status: open
title: Python implementation of PBKDF2_HMAC
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32101/pbkdf2_py.patch

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

From report at bugs.python.org  Sun Oct 13 23:34:15 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 13 Oct 2013 21:34:15 +0000
Subject: [New-bugs-announce] [issue19255] Don't "wipe" builtins at shutdown
Message-ID: <1381700055.32.0.691639350713.issue19255@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Many __del__ methods expect that builtins are existing at the time of executing. But when the object survives until the builtins module is wiped, __del__ will fail with unexpected AttributeError (see issue19021 for example). We can change __del__'s in the stdlib to not use non-cached builtins, but third party code will be broken.

Perhaps we should special case shutdown of the builtins module. E.g. reset it to initial value (all initial members of the builtins module are immutable and can't create resource loops) instead wiping.

----------
components: Interpreter Core
messages: 199810
nosy: pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Don't "wipe" builtins at shutdown
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Oct 14 00:30:08 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 13 Oct 2013 22:30:08 +0000
Subject: [New-bugs-announce] [issue19256] Optimize marshal format and add
	version token.
Message-ID: <1381703408.57.0.928931596293.issue19256@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson:

Issue $19219 added new tokens making marshal format smaller and faster.
This patch adds two new tokens:
TYPE_SHORT_REF for which the ref index is a byte and
TYPE_VERSION for which the operand is the protocol version.

The former helps because it catches common singletons such as 0, 1, () and so on which typically show up early in a pickle.  they then need only two bytes to encoded.
This shrinks the code for the decimal.py module from 172K to 162K.


The second can help break backwards compatibility requirements in the future.  The format (if 4 or larger) is now put into the stream, so that future new formats can re-assign opcodes if needed.

I don't reassign the version number, leaving it at the new value of 4.  This change is still backwards compatible with the previous '4' so there should be no problem.

For size / performance comparison, try:
python.exe -m timeit -s "import decimal; c=compile(open(decimal.__file__).read(), decimal.__file__, 'exec'); import marshal; d=marshal.dumps(c); print(len(d))" "marshal.loads(d)"

----------
files: marshal.patch
keywords: patch
messages: 199818
nosy: haypo, kristjan.jonsson, pitrou
priority: normal
severity: normal
status: open
title: Optimize marshal format and add version token.
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32102/marshal.patch

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

From report at bugs.python.org  Mon Oct 14 09:29:15 2013
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 14 Oct 2013 07:29:15 +0000
Subject: [New-bugs-announce] [issue19257] Sub-optimal error message when
	importing a non-package
Message-ID: <1381735755.7.0.417601101762.issue19257@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

Use case:

Alexanders-MacBook-Pro:pypy alex_gaynor$ python3.3
Python 3.3.2 (default, May 29 2013, 14:03:57)
[GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime.datetime
Traceback (most recent call last):
  File "<frozen importlib._bootstrap>", line 1521, in _find_and_load_unlocked
AttributeError: 'module' object has no attribute '__path__'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named 'datetime.datetime'; datetime is not a package
>>>



Showing the user the original "module has no attribute __path__" error is just confusing, we should hide it.

----------
messages: 199847
nosy: alex
priority: normal
severity: normal
status: open
title: Sub-optimal error message when importing a non-package

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

From report at bugs.python.org  Mon Oct 14 11:40:15 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 14 Oct 2013 09:40:15 +0000
Subject: [New-bugs-announce] [issue19258] Got resource warning when running
	wsgiref demo app
Message-ID: <1381743615.58.0.125660440046.issue19258@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

./python Lib/wsgiref/simple_server.py 
Serving HTTP on 0.0.0.0 port 8000 ...
127.0.0.1 - - [14/Oct/2013 17:23:43] "GET /xyz?abc HTTP/1.1" 200 4510
sys:1: ResourceWarning: unclosed <socket.socket fd=4, family=2, type=1, proto=0, laddr=('0.0.0.0', 8000)>

Attached the patch to close the socket.

----------
components: Library (Lib)
files: close_server_in_wsgiref_demo.patch
keywords: patch
messages: 199858
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Got resource warning when running wsgiref demo app
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file32111/close_server_in_wsgiref_demo.patch

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

From report at bugs.python.org  Mon Oct 14 13:30:56 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 14 Oct 2013 11:30:56 +0000
Subject: [New-bugs-announce] [issue19259] Provide Python implementation
	of	operator.compare_digest()
Message-ID: <1381750256.83.0.263124716214.issue19259@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The operator module doesn't have a Python implementation of _compare_digest. This code mimicks the C code:

def _compare_digest(a, b):
    if isinstance(a, str) and isinstance(b, str):
        a = a.encode("ascii")
        b = b.encode("ascii")
    a = memoryview(a)
    len_a = len(a)
    right = memoryview(b)
    len_b = len(right)
    if len_a == len_b:
        result = 0
        left = a
    # loop count depends on length of b
    if len_a != len_b:
        result = 1
        left = b
    for l, r in zip(left, right):
        result |= l ^ r
    return result == 0

----------
messages: 199868
nosy: christian.heimes, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Provide Python implementation of operator.compare_digest()
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Oct 14 14:44:36 2013
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 14 Oct 2013 12:44:36 +0000
Subject: [New-bugs-announce] [issue19260] "int" comment in marshal.c is
	outdated
Message-ID: <1381754676.73.0.103403492624.issue19260@psf.upfronthosting.co.za>


New submission from Larry Hastings:

In r_string() (read a string) in marshal.c we see this comment:

    /* The result fits into int because it must be <=n. */
    read = fread(p->buf, 1, n, p->fp);

This comment was first committed in r36501 by MvL.  Back then the "read" and "n" variables were int, but (of course) the return size of fread was size_t.  Since then, both n and read have become ssize_t.

I suggest changing the wording slightly anyway, because I had to meditate on what the comment was originally trying to say.  I suggest:

    /* The result fits into ssize_t because n is ssize_t. */

Patch appended too.  Bikeshedding away!

Should this be fixed in previous versions too?

----------
files: larry.marshal.outdated.comment.r1.diff
keywords: patch
messages: 199883
nosy: larry
priority: normal
severity: normal
status: open
title: "int" comment in marshal.c is outdated
versions: Python 3.4
Added file: http://bugs.python.org/file32116/larry.marshal.outdated.comment.r1.diff

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

From report at bugs.python.org  Mon Oct 14 18:17:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 14 Oct 2013 16:17:27 +0000
Subject: [New-bugs-announce] [issue19261] Add support for 24-bit in the
	sunau module
Message-ID: <1381767447.21.0.93278402116.issue19261@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a simple patch which adds support for writing 24-bit samples in the sunau module.

Actually the sunau module already supports reading 24-bit samples and AUDIO_FILE_ENCODING_LINEAR_24 mentioned as supported encoding. So perhaps this should be considered as a bugfix.

----------
assignee: serhiy.storchaka
components: Library (Lib)
files: sunau_pcm24.patch
keywords: patch
messages: 199923
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add support for 24-bit in the sunau module
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32122/sunau_pcm24.patch

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

From report at bugs.python.org  Mon Oct 14 23:18:19 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 14 Oct 2013 21:18:19 +0000
Subject: [New-bugs-announce] [issue19262] Add asyncio (tulip,
	PEP 3156) to stdlin
Message-ID: <1381785499.02.0.594919468001.issue19262@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

I'll add the tests next.  The plan is to get this in the next (last) alpha release.

----------
messages: 199953
nosy: gvanrossum, larry, pitrou
priority: release blocker
severity: normal
stage: patch review
status: open
title: Add asyncio (tulip, PEP 3156) to stdlin
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Oct 15 00:47:01 2013
From: report at bugs.python.org (CliffM)
Date: Mon, 14 Oct 2013 22:47:01 +0000
Subject: [New-bugs-announce] [issue19263] enum.py : Enum.__new__().
	__objclass__
Message-ID: <1381790821.01.0.959200663601.issue19263@psf.upfronthosting.co.za>


New submission from CliffM:

Is the assignment __objclass__ = enum_class  in enum.py(149) needed ?

I cannot find any other reference to it (even Google) and it seems that __class__ is already set to enum_class :


enum_member.__objclass__ = enum_class     < not sure what this is doing >

I have attached a patch that forces the assignment, but would rather understand what is intended here -- and test for that.

----------
components: Tests
files: enum.patch
keywords: patch
messages: 199964
nosy: CliffM, ethan.furman
priority: normal
severity: normal
status: open
title: enum.py : Enum.__new__(). __objclass__
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32126/enum.patch

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

From report at bugs.python.org  Tue Oct 15 07:43:16 2013
From: report at bugs.python.org (Peter Graham)
Date: Tue, 15 Oct 2013 05:43:16 +0000
Subject: [New-bugs-announce] [issue19264] subprocess.Popen doesn't support
	unicode on Windows
Message-ID: <1381815796.03.0.914223470735.issue19264@psf.upfronthosting.co.za>


New submission from Peter Graham:

On Windows, subprocess.Popen requires the executable name and working directory to be ascii.  This is because it calls CreateProcess instead of CreateProcessW.

----------
components: Library (Lib), Unicode, Windows
messages: 199976
nosy: ezio.melotti, peter0
priority: normal
severity: normal
status: open
title: subprocess.Popen doesn't support unicode on Windows
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Oct 15 13:24:40 2013
From: report at bugs.python.org (Colin Williams)
Date: Tue, 15 Oct 2013 11:24:40 +0000
Subject: [New-bugs-announce] [issue19265] Increased test coverage for
	datetime pickling
Message-ID: <1381836280.6.0.648453742391.issue19265@psf.upfronthosting.co.za>


New submission from Colin Williams:

This just increases test coverage for the datetime module by one line.

----------
components: Library (Lib)
files: datetimepickling.patch
keywords: patch
messages: 199993
nosy: Colin.Williams
priority: normal
severity: normal
status: open
title: Increased test coverage for datetime pickling
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file32132/datetimepickling.patch

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

From report at bugs.python.org  Tue Oct 15 13:50:54 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 15 Oct 2013 11:50:54 +0000
Subject: [New-bugs-announce] [issue19266] Rename contextlib.ignore to
	contextlib.suppress
Message-ID: <1381837854.83.0.526181978582.issue19266@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Issue 15806 added contextlib.ignored to the standard library (later renamed to contextlib.ignore), as a simple helper that allows code like:

    try:
        os.remove(fname)
    except FileNotFoundError:
        pass

to instead be written as:

    with ignore(FileNotFoundError):
        os.remove('somefile.tmp')

The point has been made that "ignore" may easily be taken to mean preventing the exception being raised *at all* (since truly ignoring the exception would mean not skipping the rest of the with statement), rather than suppressing the exception in the context manager's __exit__ method.

If you look at the rest of the contextlib docs, as well as the docs for the with statement and context manager objects, they don't refer to returning True from __exit__ as ignoring the exception, but rather as *suppressing* it. Even the docs for contextlib.ignore now make use of the term "suppress".

So I think it makes sense to rename the context manager to "suppress", while keeping the same semantics:

    with suppress(FileNotFoundError):
        os.remove('somefile.tmp')

----------
components: Library (Lib)
messages: 199995
nosy: ncoghlan, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Rename contextlib.ignore to contextlib.suppress
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Oct 15 17:08:24 2013
From: report at bugs.python.org (=?utf-8?q?Pawe=C5=82_Wroniszewski?=)
Date: Tue, 15 Oct 2013 15:08:24 +0000
Subject: [New-bugs-announce] [issue19267] Logging to file does not accept
	UTF16
Message-ID: <1381849704.17.0.355561894294.issue19267@psf.upfronthosting.co.za>


New submission from Pawe? Wroniszewski:

The following code reproduces the error:

import logging
logging.root.addHandler(logging.FileHandler(filename='test.log',encoding='UTF16'))
logging.error( u'b\u0142\u0105d')

I think the problem is in the line
logging/__init__.py:860: ufs = fs.decode(stream.encoding)

as Python can't really handle the following code:

fs = "%s\n"
print fs.decode('utf16') % u'foo'

----------
components: Library (Lib)
messages: 200001
nosy: pwronisz, vinay.sajip
priority: normal
severity: normal
status: open
title: Logging to file does not accept UTF16
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Oct 15 17:30:41 2013
From: report at bugs.python.org (Ivan Pozdeev)
Date: Tue, 15 Oct 2013 15:30:41 +0000
Subject: [New-bugs-announce] [issue19268] Local variable created with
	reflection cannot be	referenced with identifier
Message-ID: <1381851041.52.0.723888518937.issue19268@psf.upfronthosting.co.za>


New submission from Ivan Pozdeev:

It appears that the interpreter assigns an identifier to local or global scope at compilation time rather than searching locals, then globals (i.e. vars()) at the time of execution.

An example:

>>> def test():
...   vars()['a']=1
...   print(a)
...
>>> test()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in test
NameError: global name 'a' is not defined
>>>

----------
components: Interpreter Core
messages: 200004
nosy: native_api
priority: normal
severity: normal
status: open
title: Local variable created with reflection cannot be referenced with identifier
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/issue19268>
_______________________________________

From report at bugs.python.org  Wed Oct 16 07:09:20 2013
From: report at bugs.python.org (Pete)
Date: Wed, 16 Oct 2013 05:09:20 +0000
Subject: [New-bugs-announce] [issue19269] subtraction of pennies incorrect
	rounding or truncation	problem
Message-ID: <1381900160.57.0.820538942315.issue19269@psf.upfronthosting.co.za>


New submission from Pete:

Python makes errors on simple subtraction with 'pennies'. 
>>> 2000.0 - 1880.98
119.01999999999998

See attached file for more examples...

----------
components: Windows
files: py_subtraction_bug
messages: 200035
nosy: radiokinetics.pete
priority: normal
severity: normal
status: open
title: subtraction of pennies incorrect rounding or truncation problem
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file32141/py_subtraction_bug

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

From report at bugs.python.org  Wed Oct 16 10:47:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 16 Oct 2013 08:47:32 +0000
Subject: [New-bugs-announce] [issue19270] sched.cancel() breaks events order
Message-ID: <1381913252.24.0.629122693277.issue19270@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

sched.cancel() breaks events order if events are scheduled on same time and have same priority.

Patch contains tests which expose this issue.

----------
components: Library (Lib)
files: sched_test_stable.patch
keywords: patch
messages: 200040
nosy: giampaolo.rodola, pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: sched.cancel() breaks events order
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32142/sched_test_stable.patch

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

From report at bugs.python.org  Wed Oct 16 10:50:11 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 16 Oct 2013 08:50:11 +0000
Subject: [New-bugs-announce] [issue19271] Update OrderedDict "see also" link
Message-ID: <1381913411.15.0.258294798121.issue19271@psf.upfronthosting.co.za>


New submission from Mark Lawrence:

Both Python 2 and 3 docs refer to Raymond Hettinger's original recipe here http://code.activestate.com/recipes/576693/.  Would it be better to link to pypi https://pypi.python.org/pypi/ordereddict?

----------
assignee: docs at python
components: Documentation
messages: 200041
nosy: BreamoreBoy, docs at python
priority: normal
severity: normal
status: open
title: Update OrderedDict "see also" link
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Oct 16 18:56:36 2013
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 16 Oct 2013 16:56:36 +0000
Subject: [New-bugs-announce] [issue19272] Can't pickle lambda (while named
	functions are ok)
Message-ID: <1381942596.3.0.421261732602.issue19272@psf.upfronthosting.co.za>


New submission from Facundo Batista:

This is ok:

Python 3.4.0a3+ (default:86af5991c809, Oct 13 2013, 16:42:52) 
...
>>> import pickle
>>> def f():  
...   pass
... 
>>> pickle.dumps(f)
b'\x80\x03c__main__\nf\nq\x00.'


However, when trying to pickle a lambda, it fails:
>>>         
>>> pickle.dumps(lambda: None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
_pickle.PicklingError: Can't pickle <class 'function'>: attribute lookup builtins.function failed


(Found this because I'm getting the same problem but when trying to use concurrent.futures.ProcessExecutor)

----------
components: Library (Lib)
messages: 200062
nosy: facundobatista
priority: normal
severity: normal
status: open
title: Can't pickle lambda (while named functions are ok)
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Oct 16 22:52:04 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 16 Oct 2013 20:52:04 +0000
Subject: [New-bugs-announce] [issue19273] Update PCbuild/readme.txt
Message-ID: <1381956724.6.0.425752006149.issue19273@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Full title: Update PCbuild/readme.txt to be more accurate, more descriptive, more complete, less repetitive, more audience-aware, and all around, hopefully, better.

What started as a simple patch to fix the supported Windows versions list, the legacy build folders list, and a couple other minor factual errors turned into a nearly complete rewrite of the whole file.  The changes are too extensive to list out in this message; I'll use Rietveld to point out particular changes and my reasoning for them as soon as I'm able.  Also, due to the nature of the changes, it may be simpler to review the changed file itself rather than the patch, so I'll post the patched file as well.

At least 90% of these changes also apply to 3.3, but not all; I'd be happy to backport this patch or provide a new patch that strictly addresses factual errors in 3.3, as desired.

Thanks,

Zach

----------
assignee: docs at python
components: Documentation, Windows
files: pcbuild_readme.diff
keywords: patch
messages: 200085
nosy: docs at python, zach.ware
priority: normal
severity: normal
status: open
title: Update PCbuild/readme.txt
versions: Python 3.4
Added file: http://bugs.python.org/file32148/pcbuild_readme.diff

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

From report at bugs.python.org  Wed Oct 16 23:43:52 2013
From: report at bugs.python.org (Christian Tismer)
Date: Wed, 16 Oct 2013 21:43:52 +0000
Subject: [New-bugs-announce] [issue19274] make zipfile.PyZipFile more usable
Message-ID: <1381959832.11.0.559988604291.issue19274@psf.upfronthosting.co.za>


New submission from Christian Tismer:

zipfile.PyZipFile needs a filter function.

Reason:
When creating an archive of the python lib, we don't want the tests.
Especially the test file "badsyntax_future3.py" does not compile.

Use case:

With this little addition, it becomes very easy to create a zip file
of the whole python library. See the attached use case.

----------
components: Library (Lib)
files: zipfile.diff
keywords: patch
messages: 200088
nosy: Christian.Tismer
priority: normal
severity: normal
status: open
title: make zipfile.PyZipFile more usable
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file32150/zipfile.diff

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

From report at bugs.python.org  Thu Oct 17 04:43:46 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 17 Oct 2013 02:43:46 +0000
Subject: [New-bugs-announce] [issue19275] test_site is failing on AMD64 Snow
	Leopard
Message-ID: <1381977826.53.0.553154234488.issue19275@psf.upfronthosting.co.za>


New submission from R. David Murray:

See eg http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/158/steps/test/logs/stdio

----------
keywords: buildbot
messages: 200104
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: test_site is failing on AMD64 Snow Leopard
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Oct 17 05:38:02 2013
From: report at bugs.python.org (David Edelsohn)
Date: Thu, 17 Oct 2013 03:38:02 +0000
Subject: [New-bugs-announce] [issue19276] test_wave failing on PPC64 Linux
Message-ID: <1381981082.23.0.996279918128.issue19276@psf.upfronthosting.co.za>


Changes by David Edelsohn <dje.gcc at gmail.com>:


----------
components: Extension Modules
nosy: David.Edelsohn
priority: normal
severity: normal
status: open
title: test_wave failing on PPC64 Linux
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Oct 17 09:55:31 2013
From: report at bugs.python.org (Tobias Oberstein)
Date: Thu, 17 Oct 2013 07:55:31 +0000
Subject: [New-bugs-announce] [issue19277] zlib compressobj: missing
	parameter doc strings
Message-ID: <1381996531.24.0.0813249128928.issue19277@psf.upfronthosting.co.za>


New submission from Tobias Oberstein:

Currently the `zlib` module documents

    zlib.compressobj([level])

However, there are more parameters present already today:

    zlib.compressobj([level, method, wbits])

These other parameters are used in at least 2 deployed libraries (in the context of WebSocket compression):

https://github.com/tavendo/AutobahnPython/blob/master/autobahn/autobahn/compress_deflate.py#L527

http://code.google.com/p/pywebsocket/source/browse/trunk/src/mod_pywebsocket/util.py#231

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 200113
nosy: docs at python, oberstet
priority: normal
severity: normal
status: open
title: zlib compressobj: missing parameter doc strings
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct 17 10:06:27 2013
From: report at bugs.python.org (Tobias Oberstein)
Date: Thu, 17 Oct 2013 08:06:27 +0000
Subject: [New-bugs-announce] [issue19278] zlib compressobj: expose missing
	knobs
Message-ID: <1381997187.57.0.66132821735.issue19278@psf.upfronthosting.co.za>


New submission from Tobias Oberstein:

The zlib library provides a couple of knobs to control the behavior and resource consumption of compression:

    ZEXTERN int ZEXPORT deflateInit2 OF((z_streamp strm,
                                         int  level,
                                         int  method,
                                         int  windowBits,
                                         int  memLevel,
                                         int  strategy));

Of these, only `level`, `method` and `windowBits` are exposed on `zlib.compressobj` (and only the first is even documented: see issue #19277).

However, as was recently found from emperical evidence in the context of WebSocket compression

http://www.ietf.org/mail-archive/web/hybi/current/msg10222.html

the `memLevel` parameter in particular is very valuable in controlling memory consumption.

For WebSocket compression (with JSON payload), the following parameter set was found to provide a useful resource-consumption/compression-ratio tradeoff:

window bits=11
memory level=4

Hence, it would be useful to expose _all_ parameters in Python, that is `memLevel` and `strategy` too.

----------
components: Library (Lib)
messages: 200114
nosy: oberstet
priority: normal
severity: normal
status: open
title: zlib compressobj: expose missing knobs
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct 17 11:55:36 2013
From: report at bugs.python.org (Guillaume Lebourgeois)
Date: Thu, 17 Oct 2013 09:55:36 +0000
Subject: [New-bugs-announce] [issue19279] UTF-7 to UTF-8 decoding crash
Message-ID: <1382003736.62.0.288611587107.issue19279@psf.upfronthosting.co.za>


New submission from Guillaume Lebourgeois:

After the fetch of a webpage with a wrongly declared encoding, the use of codecs module for a conversion crashes.

The issue is reproducible this way : 

>>> content = b"+1911\' rel=\'stylesheet\' type=\'text/css\' />\n<link rel="alternate" type="application/rss+xml"
>>> codecs.utf_7_decode(content, "replace", True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: invalid maximum character passed to PyUnicode_New

Original issue here  : https://github.com/kennethreitz/requests/issues/1682

----------
components: Library (Lib)
messages: 200117
nosy: glebourgeois
priority: normal
severity: normal
status: open
title: UTF-7 to UTF-8 decoding crash
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Thu Oct 17 16:13:03 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 17 Oct 2013 14:13:03 +0000
Subject: [New-bugs-announce] [issue19280] Add a datatype to represent mime
	types to the email	module
Message-ID: <1382019183.72.0.422205662358.issue19280@psf.upfronthosting.co.za>


New submission from R. David Murray:

In issue 18891, Stephen Turnbull wondered if adding a datatype to represent mime types would be worthwhile.  

I think it would be.  A mimetype is a pair (maintype/subtype), and while one may test the subparts independently in logic, the representation and what needs to be passed from place to place in the code is always a pair.  Most importantly, having a datatype to represent this would eliminate a common class of errors: forgetting to test the component strings case-insensitively.  If one is manipulating a Message object, the get_xxx methods used to access the mimetype do do case coercion, but within the email code itself there are a number of places where the raw strings are manipulated, and I have already made, discovered, and fixed case insensitivity bugs in that code.

It is not clear at this point if the object should be exposed, though I'm inclined that way.  I'd propose using a string subclass with maintype and subtype attributes, and this object could then be returned by get_content_type without breaking backward compatibility.  Another advantage of using a string subclass is that the original casing of the values is easily retained and easily accessible, which while not critical is something the email package normally does (preserve the case of the original data).

----------
components: email
keywords: easy
messages: 200128
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Add a datatype to represent mime types to the email module
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Fri Oct 18 09:41:51 2013
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 18 Oct 2013 07:41:51 +0000
Subject: [New-bugs-announce] [issue19281] add __objclass__ to the docs
Message-ID: <1382082111.84.0.378259232568.issue19281@psf.upfronthosting.co.za>


New submission from Ethan Furman:

Currently __objclass__ is only documented in a ten-year old PEP.

----------
messages: 200190
nosy: eric.araujo, ethan.furman, ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: add __objclass__ to the docs

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

From report at bugs.python.org  Fri Oct 18 09:45:10 2013
From: report at bugs.python.org (Nick Guenther)
Date: Fri, 18 Oct 2013 07:45:10 +0000
Subject: [New-bugs-announce] [issue19282] dbm is not a context manager
Message-ID: <1382082310.98.0.0309554787542.issue19282@psf.upfronthosting.co.za>


New submission from Nick Guenther:

This code doesn't work. I think it should.

import dbm
with dbm.open("what is box.db", "c") as db:
   db["Bpoind"] = Boing

Indeed, there is nothing supporting PEP 343 for dbm on my system:
[kousu at galleon ~]$ grep -r __exit__ /usr/lib/python3.3/dbm             
[kousu at galleon ~]$

----------
components: Library (Lib)
messages: 200191
nosy: kousu
priority: normal
severity: normal
status: open
title: dbm is not a context manager
versions: 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/issue19282>
_______________________________________

From report at bugs.python.org  Fri Oct 18 12:19:47 2013
From: report at bugs.python.org (Debarshi Goswami)
Date: Fri, 18 Oct 2013 10:19:47 +0000
Subject: [New-bugs-announce] [issue19283] Need support to avoid Windows CRT
	compatibility issue.
Message-ID: <1382091587.94.0.520470804942.issue19283@psf.upfronthosting.co.za>


New submission from Debarshi Goswami:

Some support is needed to avoid compatibility issues in different version of CRT in Windows.
I have an application which embeds Python interpreter and the application is build on MSVC11, whereas I am using Python 3.3.2 which is build on MSVC10. I know there are some compatibility issues which are addressed in Issue10082 and Issue1003535. But even other Python APIs which uses FILE pointer inside are failing too. I tried the following things ? 
1.	PyRun_FileExFlags with MSVC11 FILE*. It crashes as expected.
2.	PyRun_FileExFlags with MSVC10 FILE* using _Py_fopen() directly passing to it. It is also crashing whereas _Py_fopen() returns FILE* of MSVC10 type.
3.	Py_CompileString() also crashes. I don?t know the reason, but here my application is not providing FILE* from outside. It uses FILE* of Python library which is of MSVC10 type.
I did some investigation and found if I provide FILE* of MSVC10 type from my application in PyRun_File() or if I call Py_CompileString(), it crashes after parsing the file (I am not totally sure, but it seems to me). Here is the call stack ? 
python33.dll!PyUnicode_InternInPlace(_object * * p) Line 14220 C
python33.dll!new_identifier(const char * n, compiling * c) Line 570 C
python33.dll!alias_for_import_name(compiling * c, const _node * n, int store) Line 2808 C
python33.dll!ast_for_import_stmt(compiling * c, const _node * n) Line 2892  C
python33.dll!PyAST_FromNode(const _node * n, PyCompilerFlags * flags, const char * filename, _arena * arena) Line 724   C
python33.dll!PyParser_ASTFromFile(_iobuf * fp, const char * filename, const char * enc, int start, char * ps1, char * ps2, PyCompilerFlags * flags, int * errcode, _arena * arena) Line 2124    C
python33.dll!PyRun_FileExFlags(_iobuf * fp, const char * filename, int start, _object * globals, _object * locals, int closeit, PyCompilerFlags * flags) Line 1931  C

It fails in PyDict_GetItem() call in PyUnicode_InternInPlace() function. Here is the snippet - 

/* It might be that the GetItem call fails even
   though the key is present in the dictionary,
   namely when this happens during a stack overflow. */
Py_ALLOW_RECURSION
t = PyDict_GetItem(interned, s);
Py_END_ALLOW_RECURSION

I am not sure why PyDict_GetItem() is failing because of FILE*. It seems to me that Python is able to parse file provided successfully.

I am initializing interpreter successfully and PyRun_String() API works fine. But I dont want to use PyRun_String() as it performs everything virtually and provide no debug support.

----------
components: Interpreter Core, Windows
messages: 200238
nosy: debarshig
priority: normal
severity: normal
status: open
title: Need support to avoid Windows CRT compatibility issue.
versions: Python 3.3

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

From report at bugs.python.org  Fri Oct 18 14:33:53 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 18 Oct 2013 12:33:53 +0000
Subject: [New-bugs-announce] [issue19284]
	subprocess._args_from_interpreter_flags() mishandles -R
Message-ID: <1382099633.49.0.620998143192.issue19284@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Trying to provoke the buildbot failure from issue 16129 I was puzzled as to why setting PYTHONHASHSEED was behaving strangely.

The subprocess._args_from_interpreter_flags() helper used by test.support (and multiprocessing) misbehaves when PYTHONHASHSEED is set to a specific value: whatever the seed is, it repeats the 'R' in -R that many times (the helper appears to assume that the only flag with a value greater than 1 will be '-v')

----------
components: Tests
keywords: buildbot
messages: 200244
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: subprocess._args_from_interpreter_flags() mishandles -R
versions: Python 3.4

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

From report at bugs.python.org  Fri Oct 18 20:37:42 2013
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 18 Oct 2013 18:37:42 +0000
Subject: [New-bugs-announce] [issue19285] test_asyncio failures on FreeBSD
Message-ID: <1382121462.63.0.212652473904.issue19285@psf.upfronthosting.co.za>


New submission from Stefan Krah:

I'm splitting this off of #19262, since certain failures (hanging for
one hour) remind me of #15599, which is an issue of epic proportions.

Also it should not be a release blocker, since threading failures under
FreeBSD-9 (running under KVM!) aren't uncommon.

----------
keywords: buildbot
messages: 200294
nosy: gvanrossum, koobs, pitrou, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: test_asyncio failures on FreeBSD
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Oct 18 21:11:00 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 18 Oct 2013 19:11:00 +0000
Subject: [New-bugs-announce] [issue19286] error: can't copy '<dirname>':
	doesn't exist or not a	regular file
Message-ID: <1382123460.13.0.176528626985.issue19286@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

On Python 2.7 and 3.3, if the package_data glob happens to match a directory, it will trigger this error during build:

error: can't copy '<package>/<dirname>': doesn't exist or not a regular file

It seems that package_data is not very smart about filtering out directories, and assumes every name matched in the glob is a file. This is particularly inconvenient when one has a directory structure of package data. Consider:

	package_data={
		'bug_pkg': (
			[
				'html/*.*',
				'html/something-1.0/*.*',
			]
		),
	},

with a directory structure of:

.
?   setup.py
?
????bug_pkg
    ?   __init__.py
    ?
    ????html
        ?   index.html
        ?
        ????something-1.0
                index.dat

Since 'html/*.*' matches 'something-1.0', distutils assumes something-1.0 is a file and tries to copy it and fails with:

error: can't copy 'bug_pkg/html/something-1.0': doesn't exist or not a regular file

I believe distutils should be filtering out folders from package_data. In the past, users (including myself) have worked around the issue by using '*.*' to match only files, but that's a poor heuristic is the above example demonstrates.

This issue was encountered when using sphinx-bootstrap-theme, which adds directories to sphinx HTML docs with directories like 'bootstrap-3.0.0', which are difficult to not match in a glob.

Is there any reason why globs specified in package_data should not exclude all directories?

----------
assignee: eric.araujo
components: Distutils
messages: 200298
nosy: eric.araujo, jason.coombs, tarek
priority: normal
severity: normal
status: open
title: error: can't copy '<dirname>': doesn't exist or not a regular file
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Oct 18 21:57:22 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 18 Oct 2013 19:57:22 +0000
Subject: [New-bugs-announce] [issue19287] __contains__() of dbm.ndbm
	databases fails with str
Message-ID: <1382126242.51.0.42060822734.issue19287@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

__contains__()  of dbm.ndbm databases fails with str, probably since 8beaa9a37387.
This is a regression in Python 3.3.

$ python3.2 -c 'import dbm.ndbm; db=dbm.ndbm.open("/tmp/db1", "c"); db["key"]="value"; print(b"key" in db); print("key" in db)'
True
True
$ python3.3 -c 'import dbm.ndbm; db=dbm.ndbm.open("/tmp/db2", "c"); db["key"]="value"; print(b"key" in db); print("key" in db)'
True
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: dbm key must be string, not str
$ python3.4 -c 'import dbm.ndbm; db=dbm.ndbm.open("/tmp/db3", "c"); db["key"]="value"; print(b"key" in db); print("key" in db)'
True
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: dbm key must be string, not str


Also please improve error message to e.g. "dbm key must be bytes or string, not %.100s".

----------
components: Library (Lib)
keywords: 3.3regression
messages: 200303
nosy: Arfrever, loewis
priority: normal
severity: normal
status: open
title: __contains__()  of dbm.ndbm databases fails with str
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Oct 18 22:23:13 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 18 Oct 2013 20:23:13 +0000
Subject: [New-bugs-announce] [issue19288] __contains__() of dbm.gnu
	databases fails with str
Message-ID: <1382127793.56.0.416420933735.issue19288@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

__contains__()  of dbm.gnu databases fails with str.
This is inconsistent with other databases (dbm.ndbm (issue #19287) and dbm.dumb).


$ python3.2 -c 'import dbm.ndbm; db=dbm.ndbm.open("/tmp/ndbm_db", "c"); db["key"]="value"; print(b"key" in db); print("key" in db)'
True
True
$ python3.4 -c 'import dbm.dumb; db=dbm.dumb.open("/tmp/dumb_db", "c"); db["key"]="value"; print(b"key" in db); print("key" in db)'
True
True
$ python3.4 -c 'import dbm.gnu; db=dbm.gnu.open("/tmp/gdbm_db", "c"); db["key"]="value"; print(b"key" in db); print("key" in db)'
True
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: gdbm key must be bytes, not str

----------
components: Library (Lib)
messages: 200305
nosy: Arfrever
priority: normal
severity: normal
status: open
title: __contains__()  of dbm.gnu databases fails with str
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Oct 18 23:31:41 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 18 Oct 2013 21:31:41 +0000
Subject: [New-bugs-announce] [issue19289] Incorrect documentation for
	format's fill character.
Message-ID: <1382131901.96.0.924496461441.issue19289@psf.upfronthosting.co.za>


New submission from Eric V. Smith:

In http://docs.python.org/library/string.html#format-specification-mini-language, it says "The fill character can be any character other than ?{? or ?}?."

But that's not actually true. It's only true when using str.format, as it does the parsing and the { and } mean special things for that parser. 

But for format itself there is no restriction:

>>> format(3, '{>10')
'{{{{{{{{{3'

As this section should be documenting the format specifiers themselves, I think it should not concern itself with restrictions imposed by str.format.

----------
assignee: docs at python
components: Documentation
messages: 200308
nosy: docs at python, eric.smith
priority: low
severity: normal
status: open
title: Incorrect documentation for format's fill character.
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Oct 19 00:25:32 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Oct 2013 22:25:32 +0000
Subject: [New-bugs-announce] [issue19290] Clarify compile and eval
	interaction.
Message-ID: <1382135132.91.0.187309157375.issue19290@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

This issue was stimulated by #17294 where there seems to be some confusion over the purpose of the compile modes with regards to return values. I then noticed that the eval doc starts wrong and later corrects itself.

I think the following sentence from the compile doc could be improved. The current version:

"The mode argument specifies what kind of code must be compiled; it can be 'exec' if source consists of a sequence of statements, 'eval' if it consists of a single expression, or 'single' if it consists of a single interactive statement (in the latter case, expression statements that evaluate to something other than None will be printed)."

My suggestion:

"The mode argument specifies the allowed source and the return value when the result is passed to eval(). It can be 'exec' for any source (a sequence of 0 to many statements); the return value will be None. It can be 'eval' if the source is a single expression; the return value will be the value of the expression. It can be 'single' if the source is a single non-empty interactive statement; the return value will be None, as with 'exec', but if the statement is an expression that evaluates to something other than None, the value will be printed."

(#13677 is about changing the doc and docstring for the compile flags argument. Patches for that and this should be disjoint.)

The eval(expression, ..) doc say that expression is a string. It much later says that it can also be a code object. I think the eval doc should follow the exec doc and call the first positional-only arg 'object' and then say the same thing: 'object must be either a string or a code object.' I don't have a complete suggested revision yet.

----------
assignee: docs at python
components: Documentation
messages: 200318
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Clarify compile and eval interaction.
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Oct 19 00:58:39 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 18 Oct 2013 22:58:39 +0000
Subject: [New-bugs-announce] [issue19291] Add docs for asyncio package
	(Tulip, PEP 3156)
Message-ID: <1382137119.85.0.0934203099722.issue19291@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

The asyncio module needs documentation.  I'll work on this in time for the beta 1 release.  Until then, please refer to PEP 3156.

----------
assignee: gvanrossum
messages: 200324
nosy: gvanrossum
priority: deferred blocker
severity: normal
status: open
title: Add docs for asyncio package (Tulip, PEP 3156)
versions: Python 3.4

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

From report at bugs.python.org  Sat Oct 19 01:18:54 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 18 Oct 2013 23:18:54 +0000
Subject: [New-bugs-announce] [issue19292] Make
	SSLContext.set_default_verify_paths() work on	Windows
Message-ID: <1382138334.23.0.419355699391.issue19292@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

See discussion on https://groups.google.com/forum/#!topic/python-tulip/c_lqdFjPEbE .

If you set sslcontext.verify_mode = ssl.CERT_REQUIRED and call sslcontext.set_default_verify_paths(), the stdlib ought to have enough smarts to use the system root certificates.

I understand this is difficult, as the location of the root certificates may vary between Windows versions or installations.  But if we leave this up to the app developer they are much more likely to disable certificate verification by setting verify_mode to CERT_NONE than to provide secure root certs (or do even less secure things, like using plain HTTP :-).

----------
messages: 200328
nosy: gvanrossum
priority: normal
severity: normal
stage: needs patch
status: open
title: Make SSLContext.set_default_verify_paths() work on Windows
type: security
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Oct 19 06:20:34 2013
From: report at bugs.python.org (David Edelsohn)
Date: Sat, 19 Oct 2013 04:20:34 +0000
Subject: [New-bugs-announce] [issue19293] test_asyncio failures on AIX
Message-ID: <1382156434.98.0.895187743681.issue19293@psf.upfronthosting.co.za>


New submission from David Edelsohn:

test_asyncio times out after one hour on AIX and leaves a process consuming 100% of a thread.

[145/382/3] test_asyncio
Timeout (1:00:00)!
Thread 0x00000001:
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/selectors.py", line 265 in select
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/asyncio/base_events.py", line 576 in _run_once
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/asyncio/base_events.py", line 153 in run_forever
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/asyncio/base_events.py", line 172 in run_until_complete
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_asyncio/test_events.py", line 1012 in test_subprocess_interactive
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/case.py", line 571 in run
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/case.py", line 610 in __call__
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 117 in run
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 79 in __call__
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 117 in run
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 79 in __call__
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 117 in run
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 79 in __call__
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/runner.py", line 168 in run
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/support/__init__.py", line 1661 in _run_suite
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/support/__init__.py", line 1695 in run_unittest
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_asyncio/__init__.py", line 26 in test_main
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/regrtest.py", line 1276 in runtest_inner
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/regrtest.py", line 965 in runtest
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/regrtest.py", line 761 in main
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/regrtest.py", line 1560 in main_in_temp_cwd
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/__main__.py", line 3 in <module>
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/runpy.py", line 73 in _run_code
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/runpy.py", line 160 in _run_module_as_main
make: 1254-004 The error code from the last command is 1.

----------
messages: 200364
nosy: David.Edelsohn
priority: normal
severity: normal
status: open
title: test_asyncio failures on AIX
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Oct 19 10:46:44 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 19 Oct 2013 08:46:44 +0000
Subject: [New-bugs-announce] [issue19294] test_asyncio fails intermittently
	on OS X 10.4
Message-ID: <1382172404.1.0.731084144387.issue19294@psf.upfronthosting.co.za>


New submission from Ned Deily:

Since asyncio was checked in, there have been a couple of similar buildbot failures on the OS X 10.4 (Tiger) buildbot sandwiched around a successful run.  I also saw a similar failure on a 10.4 system I have.  So far, the OS X 10.6 (Snow Leopard) buildbot has not had any failures nor have I seen any so far in limited testing on other OS X version (newer than 10.4).

http://buildbot.python.org/all/builders/x86%20Tiger%203.x/builds/7093

http://buildbot.python.org/all/builders/x86%20Tiger%203.x/builds/7095

>From the 

======================================================================
ERROR: test_subprocess_shell (test.test_asyncio.test_events.KqueueEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 1034, in test_subprocess_shell
    self.loop.run_until_complete(connect())
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/asyncio/base_events.py", line 177, in run_until_complete
    return future.result()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/asyncio/futures.py", line 221, in result
    raise self._exception
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/asyncio/tasks.py", line 261, in _step
    result = next(coro)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 1031, in connect
    'echo "Python"')
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/asyncio/base_events.py", line 521, in subprocess_shell
    protocol, cmd, True, stdin, stdout, stderr, bufsize, **kwargs)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/asyncio/unix_events.py", line 161, in _make_subprocess_transport
    yield from transp._post_init()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/asyncio/unix_events.py", line 483, in _post_init
    proc.stdin)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/asyncio/base_events.py", line 507, in connect_write_pipe
    transport = self._make_write_pipe_transport(pipe, protocol, waiter)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/asyncio/unix_events.py", line 150, in _make_write_pipe_transport
    return _UnixWritePipeTransport(self, pipe, protocol, waiter, extra)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/asyncio/unix_events.py", line 273, in __init__
    if not stat.S_ISFIFO(os.fstat(self._fileno).st_mode):
OSError: [Errno 9] Bad file descriptor

======================================================================
ERROR: test_subprocess_shell (test.test_asyncio.test_events.SelectEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 1034, in test_subprocess_shell
    self.loop.run_until_complete(connect())
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/asyncio/base_events.py", line 177, in run_until_complete
    return future.result()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/asyncio/futures.py", line 221, in result
    raise self._exception
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/asyncio/tasks.py", line 261, in _step
    result = next(coro)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_asyncio/test_events.py", line 1031, in connect
    'echo "Python"')
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/asyncio/base_events.py", line 521, in subprocess_shell
    protocol, cmd, True, stdin, stdout, stderr, bufsize, **kwargs)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/asyncio/unix_events.py", line 161, in _make_subprocess_transport
    yield from transp._post_init()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/asyncio/unix_events.py", line 483, in _post_init
    proc.stdin)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/asyncio/base_events.py", line 507, in connect_write_pipe
    transport = self._make_write_pipe_transport(pipe, protocol, waiter)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/asyncio/unix_events.py", line 150, in _make_write_pipe_transport
    return _UnixWritePipeTransport(self, pipe, protocol, waiter, extra)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/asyncio/unix_events.py", line 273, in __init__
    if not stat.S_ISFIFO(os.fstat(self._fileno).st_mode):
OSError: [Errno 9] Bad file descriptor

----------
components: Tests
keywords: buildbot
messages: 200389
nosy: gvanrossum, ned.deily
priority: normal
severity: normal
status: open
title: test_asyncio fails intermittently on OS X 10.4
versions: Python 3.4

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

From report at bugs.python.org  Sat Oct 19 12:31:06 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 19 Oct 2013 10:31:06 +0000
Subject: [New-bugs-announce] [issue19295] Make asyncio work without threads
Message-ID: <1382178666.39.0.442915890559.issue19295@psf.upfronthosting.co.za>


New submission from Stefan Krah:

I'm referring to msg200288.  I guess this is low priority, since
not many people will want to use asyncio on a build --without-threads.

----------
keywords: buildbot
messages: 200399
nosy: gvanrossum, skrah
priority: low
severity: normal
stage: needs patch
status: open
title: Make asyncio work without threads
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Oct 19 13:02:46 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 19 Oct 2013 11:02:46 +0000
Subject: [New-bugs-announce] [issue19296] Compiler warning when compiling
	dbm module
Message-ID: <1382180566.13.0.638248121089.issue19296@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

I got this warning when compiling dbm module with Python 3.4.

/home/sky/Code/python/programming_language/cpython/Modules/_dbmmodule.c: In function ?newdbmobject?:
/home/sky/Code/python/programming_language/cpython/Modules/_dbmmodule.c:55:5: warning: passing argument 1 of ?dbm_open? discards ?const? qualifier from pointer target type [enabled by default]
In file included from /home/sky/Code/python/programming_language/cpython/Modules/_dbmmodule.c:16:0:
/usr/include/ndbm.h:55:14: note: expected ?char *? but argument is of type ?const char *?

I have two ndbm.h.

/usr/include/ndbm.h
/usr/include/gdbm/ndbm.h

Both of them expect char *file not const char *file in dbm_open.

I downloaded the newest GNU database manager from http://www.gnu.org.ua/software/gdbm/download.html (gdbm-1.10.tar.gz). It expects char *file as well in dbm_open.

Attached the patch to silent the compiler warning.

But when I searched 'dbm_open' in search engines or did "man dbm_open", I got:

DBM *dbm_open(const char *file, int open_flags, mode_t file_mode);

So I am not really sure about this. Feel free to close this ticket if it is not valid.

----------
components: Extension Modules
files: silent_compiler_warning_dbm_module.patch
keywords: patch
messages: 200402
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Compiler warning when compiling dbm module
versions: Python 3.4
Added file: http://bugs.python.org/file32223/silent_compiler_warning_dbm_module.patch

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

From report at bugs.python.org  Sat Oct 19 15:49:32 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 19 Oct 2013 13:49:32 +0000
Subject: [New-bugs-announce] [issue19297] test_asyncio: unclosed sockets
Message-ID: <1382190572.42.0.767959680712.issue19297@psf.upfronthosting.co.za>


New submission from Stefan Krah:

unittest produces the following resource warnings:

$ ./python -m test -uall test_asyncio
[1/1] test_asyncio
/home/stefan/hg/master/Lib/unittest/case.py:571: ResourceWarning: unclosed <socket.socket fd=7, family=2, type=1, proto=0, laddr=('127.0.0.1', 49177)>
  testMethod()
/home/stefan/hg/master/Lib/unittest/case.py:571: ResourceWarning: unclosed <socket.socket fd=7, family=2, type=1, proto=0, laddr=('127.0.0.1', 56385)>
  testMethod()
/home/stefan/hg/master/Lib/unittest/case.py:571: ResourceWarning: unclosed <socket.socket fd=7, family=2, type=1, proto=0, laddr=('127.0.0.1', 56244)>
  testMethod()
[...]


It seems to happen whenever run_test_server() from asyncio/test_utils.py is
used.

----------
components: Tests
messages: 200417
nosy: skrah
priority: normal
severity: normal
status: open
title: test_asyncio: unclosed sockets
versions: Python 3.4

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

From report at bugs.python.org  Sat Oct 19 16:37:31 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 19 Oct 2013 14:37:31 +0000
Subject: [New-bugs-announce] [issue19298] Use __atribute__(cleanup ...) to
	detect refleaks
Message-ID: <1382193451.78.0.278113981899.issue19298@psf.upfronthosting.co.za>


New submission from Brett Cannon:

GCC defines an __attribute__ called 'cleanup' which attaches to a variable declaration and specifies a function to execute with an argument of a pointer to the variable when the block scope is left. Typically this is used to automate cleanup (much like smart pointers in C++), but we can't do that if we want to support compilers other than GCC (and Clang based on my testing). Cleanup's definition can be found at http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html .

But what we can use it for is refcount verification. So if we defined a freed(PyObject **) cleanup function we could verify in a debug build that the memory in fact was erased with the memory pattern that a debug build overwrites memory with. If something is expected to have <= 1 refcount (i.e. the variable's value is to be returned assuming nothing went wrong) then we could check if it was freed or if it had exactly a refcount of 1. This obviously only works for local variables which are assigned fresh objects (since there is no way to measure the delta of a refcount from assignment to block exit), but it would still help detect some refleaks. It would also potentially help with Dave Malcolm's gcc refleak detector by providing hints as to what the expected outcome is.

Credit to David Stutzbach for suggesting this usage.

----------
components: Extension Modules, Interpreter Core
messages: 200423
nosy: brett.cannon, dmalcolm, stutzbach
priority: normal
severity: normal
stage: test needed
status: open
title: Use __atribute__(cleanup ...) to detect refleaks
type: enhancement

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

From report at bugs.python.org  Sat Oct 19 17:04:04 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Oct 2013 15:04:04 +0000
Subject: [New-bugs-announce] [issue19299] test_asyncio refleak failures
Message-ID: <1382195044.62.0.738507777021.issue19299@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Either the tests forget to cleanup resources at the end, or the library itself has resource management issues.

$ ./python -Wi -m test -R 3:3 test_asyncio
[1/1] test_asyncio
beginning 6 repetitions
123456
......
test_asyncio leaked [240, -677, -158] references, sum=-595
test_asyncio leaked [36, -116, -29] memory blocks, sum=-109

----------
components: Library (Lib), Tests
messages: 200425
nosy: gvanrossum, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: test_asyncio refleak failures
type: resource usage
versions: Python 3.4

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

From report at bugs.python.org  Sat Oct 19 19:06:22 2013
From: report at bugs.python.org (py.user)
Date: Sat, 19 Oct 2013 17:06:22 +0000
Subject: [New-bugs-announce] [issue19300] Swap keyword arguments in open()
	to make encoding easier	to use
Message-ID: <1382202382.72.0.542427782667.issue19300@psf.upfronthosting.co.za>


New submission from py.user:

>>> print(open.__doc__)
open(file, mode='r', buffering=-1, encoding=None,
     errors=None, newline=None, closefd=True, opener=None) -> file object


It would be handy to use
open('file.txt', 'r', 'utf-8')

instead of
open('file.txt', 'r', encoding='utf-8')

----------
components: Interpreter Core
messages: 200445
nosy: py.user
priority: normal
severity: normal
status: open
title: Swap keyword arguments in open() to make encoding easier to use
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Oct 19 19:56:32 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 19 Oct 2013 17:56:32 +0000
Subject: [New-bugs-announce] [issue19301] Globals declared in function scope
	have wrong	__qualname__
Message-ID: <1382205392.94.0.868971273395.issue19301@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti:

The value of __qualname__ for globals declared in function scope doesn't seems right to me:

>>> def f():
...    global C
...    class C: pass
...    return C.__qualname__
...
>>> f()
'f.<locals>.C'

It would be much more useful to return 'C' in this case. In my case, fixing this would help me write cleaner unit tests for pickle, since it would allow me to keep test classes with their test code.

----------
assignee: alexandre.vassalotti
messages: 200453
nosy: alexandre.vassalotti, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: Globals declared in function scope have wrong __qualname__
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Oct 19 20:03:29 2013
From: report at bugs.python.org (David Edelsohn)
Date: Sat, 19 Oct 2013 18:03:29 +0000
Subject: [New-bugs-announce] [issue19302] Add support for AIX pollset
	efficient event I/O polling
Message-ID: <1382205809.97.0.496335957362.issue19302@psf.upfronthosting.co.za>


New submission from David Edelsohn:

Implement AIX pollset in Modules/selectmodule.c

----------
components: Extension Modules
messages: 200457
nosy: David.Edelsohn
priority: normal
severity: normal
status: open
title: Add support for AIX pollset efficient event I/O polling
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sat Oct 19 20:43:55 2013
From: report at bugs.python.org (Martin Matusiak)
Date: Sat, 19 Oct 2013 18:43:55 +0000
Subject: [New-bugs-announce] [issue19303] Typo in devguide - coverage
Message-ID: <1382208235.18.0.0734246482972.issue19303@psf.upfronthosting.co.za>


New submission from Martin Matusiak:

- Another option is to use an installed copy of coverage.py if you already have an installed copy.

----------
components: Devguide
files: typo_coverage.diff
keywords: patch
messages: 200474
nosy: ezio.melotti, numerodix
priority: normal
severity: normal
status: open
title: Typo in devguide - coverage
Added file: http://bugs.python.org/file32228/typo_coverage.diff

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

From report at bugs.python.org  Sat Oct 19 21:07:19 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Sat, 19 Oct 2013 19:07:19 +0000
Subject: [New-bugs-announce] [issue19304] Typo in statistics.rst
Message-ID: <1382209639.62.0.731892223733.issue19304@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

There are two small typos in statistics.rst.

----------
assignee: docs at python
components: Documentation
files: typos.patch
keywords: patch
messages: 200480
nosy: Claudiu.Popa, docs at python
priority: normal
severity: normal
status: open
title: Typo in statistics.rst
versions: Python 3.4
Added file: http://bugs.python.org/file32230/typos.patch

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

From report at bugs.python.org  Sun Oct 20 01:18:45 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Oct 2013 23:18:45 +0000
Subject: [New-bugs-announce] [issue19305] sporadic test_asyncio failure
	under FreeBSD
Message-ID: <1382224725.63.0.152708776647.issue19305@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x/builds/626/steps/test/logs/stdio

======================================================================
FAIL: test_create_server (test.test_asyncio.test_events.SelectEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/test_asyncio/test_events.py", line 568, in test_create_server
    self.assertEqual(3, proto.nbytes)
AssertionError: 3 != 0

----------
components: Library (Lib), Tests
keywords: buildbot
messages: 200515
nosy: gvanrossum, koobs, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: sporadic test_asyncio failure under FreeBSD
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Oct 20 02:23:25 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 20 Oct 2013 00:23:25 +0000
Subject: [New-bugs-announce] [issue19306] Warn unsuspecting readers that
	thread stacks are in	reverse order
Message-ID: <1382228605.25.0.0617949824826.issue19306@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

I was confused for a while when seeing the thread stacks dumped by the faulthandler module.  (See issue 19293.)

I propose the following tweaks of the output to make this more obvious. The first chunk changes the header written when called as _Py_DumpTraceback(), the second change the per-thread headers printed by _Py_DumpTracebackThreads().

diff -r 02f6922e6a7e Python/traceback.c
--- a/Python/traceback.c        Sat Oct 19 17:04:25 2013 -0700
+++ b/Python/traceback.c        Sat Oct 19 17:19:29 2013 -0700
@@ -603,7 +603,7 @@
     unsigned int depth;

     if (write_header)
-        PUTS(fd, "Traceback (most recent call first):\n");
+        PUTS(fd, "Stack (most recent call first):\n");

     frame = _PyThreadState_GetFrame(tstate);
     if (frame == NULL)
@@ -642,7 +642,7 @@
     else
         PUTS(fd, "Thread 0x");
     dump_hexadecimal(sizeof(long)*2, (unsigned long)tstate->thread_id, fd);
-    PUTS(fd, ":\n");
+    PUTS(fd, " (most recent call first):\n");
 }

 const char*

----------
assignee: pitrou
keywords: easy
messages: 200527
nosy: gvanrossum, pitrou
priority: low
severity: normal
stage: patch review
status: open
title: Warn unsuspecting readers that thread stacks are in reverse order
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Oct 20 07:16:39 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 20 Oct 2013 05:16:39 +0000
Subject: [New-bugs-announce] [issue19307] Improve TypeError message in
	json.loads()
Message-ID: <1382246199.49.0.284372498766.issue19307@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

Currently the error raised when bytes are passed to json.loads() is not very clear:
>>> json.loads(b'')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/wolf/dev/py/py3k/Lib/json/__init__.py", line 316, in loads
    return _default_decoder.decode(s)
  File "/home/wolf/dev/py/py3k/Lib/json/decoder.py", line 344, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
TypeError: can't use a string pattern on a bytes-like object

The attached patch changes the error message to:
>>> json.loads(b'')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/wolf/dev/py/py3k/Lib/json/__init__.py", line 315, in loads
    s.__class__.__name__))
TypeError: the JSON object must be str, not 'bytes'

(This came up on #18958, and it's required in order to check for a UTF-8 BOM without producing an even more misleading error message.)

----------
assignee: ezio.melotti
components: Library (Lib)
files: json-error-msg.diff
keywords: patch
messages: 200545
nosy: ezio.melotti, ncoghlan, pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: commit review
status: open
title: Improve TypeError message in json.loads()
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32238/json-error-msg.diff

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

From report at bugs.python.org  Sun Oct 20 11:24:14 2013
From: report at bugs.python.org (David Coles)
Date: Sun, 20 Oct 2013 09:24:14 +0000
Subject: [New-bugs-announce] [issue19308] Tools/gdb/libpython.py does not
	support GDB linked	against Python 3
Message-ID: <1382261054.14.0.65764193658.issue19308@psf.upfronthosting.co.za>


New submission from David Coles:

Tools/gdb/libpython.py is currently Python 3 incompatible. Unfortunately recent versions of gdb (such as the one provided in Ubuntu 13.10) may be linked against Python 3 rather than Python 2, breaking debugging support.

Most of the issues appear to be trivial issues such as the print statement syntax and removal of functions like xrange, unichr and long.

----------
components: Demos and Tools
messages: 200554
nosy: dcoles
priority: normal
severity: normal
status: open
title: Tools/gdb/libpython.py does not support GDB linked against Python 3
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Oct 20 11:51:57 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 20 Oct 2013 09:51:57 +0000
Subject: [New-bugs-announce] [issue19309] asyncio: fix handling of processes
	in a different	process group
Message-ID: <1382262717.42.0.688031898655.issue19309@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

See https://groups.google.com/forum/#!topic/python-tulip/9T2_tGWe0Sc

The attached patch just changes waitpid(0) to waitpid(-1), and comes with a trivial test.

----------
components: Library (Lib)
files: asyncio_process_group.diff
keywords: easy, needs review, patch
messages: 200555
nosy: gvanrossum, neologix
priority: normal
severity: normal
stage: patch review
status: open
title: asyncio: fix handling of processes in a different process group
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file32240/asyncio_process_group.diff

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

From report at bugs.python.org  Sun Oct 20 12:33:29 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 20 Oct 2013 10:33:29 +0000
Subject: [New-bugs-announce] [issue19310] asyncio: fix waitpid() logic
Message-ID: <1382265209.42.0.484907222023.issue19310@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

The current SIGCHILD handler has two bugs:
- it reschedules itself if waitpid() returns 0: so if this ever happens, it will enter a busy-loop until all children have exited
- it doesn't reschedule itself if waitpid() succeeds in reaping a child: since signals can be coalesced, we must keep calling waitpid() as long as it succeeds, since the incoming SIGCHLD signal could actually be due to more than one child exited (and there won't be a SIGCHILD coming later for the processes we didn't wait right away).

----------
components: Library (Lib)
files: asyncio_waitpid_loop.diff
keywords: needs review, patch
messages: 200561
nosy: gvanrossum, neologix
priority: normal
severity: normal
stage: patch review
status: open
title: asyncio: fix waitpid() logic
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file32242/asyncio_waitpid_loop.diff

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

From report at bugs.python.org  Sun Oct 20 12:57:20 2013
From: report at bugs.python.org (Martin Matusiak)
Date: Sun, 20 Oct 2013 10:57:20 +0000
Subject: [New-bugs-announce] [issue19311] devguide: hg bisect section could
	be clearer
Message-ID: <1382266640.75.0.952779110911.issue19311@psf.upfronthosting.co.za>


New submission from Martin Matusiak:

The offending section:
http://docs.python.org/devguide/faq.html#how-do-i-find-which-changeset-introduced-a-bug-or-regression

I think this could be improved a bit. The key point is that "hg bisect --bad/good" is a command relative to the checked out changeset. So the instructions tell me to run "hg bisect --bad" and then "hg bisect --good", but they could do with a more explicit instruction to run "hg update <ref-id>" in between.

- You can conveniently choose a faraway changeset (for example a former release), and check that it is indeed ?good?

This could be construed as just peeking at the changeset using hg log or whatever, not actually checking it out.

- Mercurial will automatically bisect so as to narrow the range of possible culprits, until a single changeset is isolated.

Here too it could be made more explicit that mercurial will navigate to (ie. check out each changeset) as it's doing this, so that at every invocation of "hg bisect --bad/good" the changeset to be tested is checked out for you, not merely computed.

----------
components: Devguide
messages: 200565
nosy: ezio.melotti, numerodix
priority: normal
severity: normal
status: open
title: devguide: hg bisect section could be clearer

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

From report at bugs.python.org  Sun Oct 20 13:52:19 2013
From: report at bugs.python.org (Martin Matusiak)
Date: Sun, 20 Oct 2013 11:52:19 +0000
Subject: [New-bugs-announce] [issue19312] Typo in devguide - compiler
Message-ID: <1382269939.53.0.178642768375.issue19312@psf.upfronthosting.co.za>


New submission from Martin Matusiak:

- The purpose of this document is to outline how the latter three steps of the process works.

work

----------
components: Devguide
files: typo_compiler.diff
keywords: patch
messages: 200567
nosy: ezio.melotti, numerodix
priority: normal
severity: normal
status: open
title: Typo in devguide - compiler
Added file: http://bugs.python.org/file32243/typo_compiler.diff

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

From report at bugs.python.org  Sun Oct 20 14:03:02 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Oct 2013 12:03:02 +0000
Subject: [New-bugs-announce] [issue19313] reference leaks
Message-ID: <1382270582.6.0.446986399732.issue19313@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Given the huge leakage in test_ast, it looks like a compiler issue.

results for 68a7bc8bb663 on branch "default"
--------------------------------------------

test_grammar leaked [3, 3, 3] references, sum=9
test_opcodes leaked [16, 16, 16] references, sum=48
test_builtin leaked [11, 11, 11] references, sum=33
test_unittest leaked [7, 7, 7] references, sum=21
test_doctest leaked [55, 55, 55] references, sum=165
test_doctest leaked [3, 3, 3] memory blocks, sum=9
test_support leaked [9, 9, 9] references, sum=27
test_support leaked [8, 8, 8] memory blocks, sum=24
test_ast leaked [6885, 6885, 6885] references, sum=20655
test_ast leaked [4888, 4890, 4890] memory blocks, sum=14668
test_atexit leaked [2, 2, 2] references, sum=6
test_cgi leaked [9, 9, 9] references, sum=27
test_cgi leaked [8, 8, 8] memory blocks, sum=24
test_cmd leaked [2, 2, 2] references, sum=6
test_cmd_line_script leaked [12, 12, 12] references, sum=36
test_code leaked [7, 7, 7] references, sum=21
test_codeop leaked [44, 44, 44] references, sum=132
test_codeop leaked [4, 4, 4] memory blocks, sum=12
test_collections leaked [243, 243, 243] references, sum=729
test_collections leaked [216, 216, 216] memory blocks, sum=648
test_compile leaked [122, 122, 122] references, sum=366
test_compile leaked [108, 108, 108] memory blocks, sum=324
test_ctypes leaked [1, 1, 1] references, sum=3
test_decorators leaked [4, 4, 4] references, sum=12
test_deque leaked [4, 4, 4] references, sum=12
test_descrtut leaked [39, 39, 39] references, sum=117
test_descrtut leaked [19, 19, 19] memory blocks, sum=57
test_difflib leaked [2, 2, 2] references, sum=6
test_dis leaked [769, 769, 769] references, sum=2307
test_distutils leaked [2, 2, 2] references, sum=6
test_dynamic leaked [1, 1, 1] references, sum=3
test_extcall leaked [35, 35, 35] references, sum=105
test_extcall leaked [9, 9, 9] memory blocks, sum=27
test_funcattrs leaked [1, 1, 1] references, sum=3
test_gc leaked [1, 1, 1] references, sum=3
test_generators leaked [110, 110, 110] references, sum=330
test_generators leaked [25, 25, 25] memory blocks, sum=75
test_genexps leaked [30, 30, 30] references, sum=90
test_genexps leaked [4, 4, 4] memory blocks, sum=12
test_gettext leaked [25, 25, 25] references, sum=75
test_import leaked [4, 4, 4] references, sum=12
test_importlib leaked [36, 36, 36] references, sum=108
test_importlib leaked [32, 32, 32] memory blocks, sum=96
test_inspect leaked [45, 45, 45] references, sum=135
test_itertools leaked [22, 22, 22] references, sum=66
test_itertools leaked [2, 2, 2] memory blocks, sum=6
test_json leaked [2, 2, 2] references, sum=6
test_keywordonlyarg leaked [1, 1, 1] references, sum=3
test_listcomps leaked [39, 39, 39] references, sum=117
test_listcomps leaked [19, 19, 19] memory blocks, sum=57
test_marshal leaked [2, 2, 2] references, sum=6
test_math leaked [1, 1, 1] references, sum=3
test_metaclass leaked [38, 38, 38] references, sum=114
test_metaclass leaked [10, 10, 10] memory blocks, sum=30
test_module leaked [3, 3, 3] references, sum=9
test_module leaked [2, 2, 2] memory blocks, sum=6
test_modulefinder leaked [17, 17, 17] references, sum=51
test_modulefinder leaked [12, 12, 12] memory blocks, sum=36
test_peepholer leaked [1, 1, 1] references, sum=3
test_pydoc leaked [9, 9, 9] references, sum=27
test_pydoc leaked [8, 8, 8] memory blocks, sum=24
test_runpy leaked [35, 35, 35] references, sum=105
test_scope leaked [27, 27, 27] references, sum=81
test_scope leaked [18, 18, 18] memory blocks, sum=54
test_setcomps leaked [40, 40, 40] references, sum=120
test_setcomps leaked [19, 19, 19] memory blocks, sum=57
test_site leaked [0, 0, 2] references, sum=2
test_site leaked [0, 0, 2] memory blocks, sum=2
test_super leaked [2, 2, 2] references, sum=6
test_syntax leaked [4, 4, 4] references, sum=12
test_sys_settrace leaked [2, 2, 2] references, sum=6
test_threaded_import leaked [1, 1, 1] references, sum=3
test_threading leaked [22, 22, 22] references, sum=66
test_threading leaked [17, 17, 17] memory blocks, sum=51
test_threading_local leaked [10, 10, 10] references, sum=30
test_threading_local leaked [4, 4, 4] memory blocks, sum=12
test_timeit leaked [22, 22, 22] references, sum=66
test_tools leaked [44, 44, 44] references, sum=132
test_tools leaked [18, 18, 18] memory blocks, sum=54
test_trace leaked [1599, 1599, 1599] references, sum=4797
test_trace leaked [1125, 1127, 1127] memory blocks, sum=3379
test_unpack leaked [5, 5, 5] references, sum=15
test_unpack leaked [2, 2, 2] memory blocks, sum=6
test_unpack_ex leaked [7, 7, 7] references, sum=21
test_unpack_ex leaked [2, 2, 2] memory blocks, sum=6
test_weakref leaked [8, 8, 8] references, sum=24
test_weakref leaked [2, 2, 2] memory blocks, sum=6
test_zipimport leaked [38, 38, 38] references, sum=114
test_zipimport_support leaked [84, 84, 84] references, sum=252
test_zipimport_support leaked [20, 20, 20] memory blocks, sum=60


Command line was: ['./python', '-m', 'test.regrtest', '-uall', '-R', '3:3:/home/antoine/cpython/refleaks/reflogYgMGKS', '-x']

----------
assignee: benjamin.peterson
components: Interpreter Core
messages: 200568
nosy: benjamin.peterson, larry, pitrou
priority: release blocker
severity: normal
status: open
title: reference leaks
type: resource usage
versions: Python 3.4

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

From report at bugs.python.org  Sun Oct 20 14:03:15 2013
From: report at bugs.python.org (Martin Matusiak)
Date: Sun, 20 Oct 2013 12:03:15 +0000
Subject: [New-bugs-announce] [issue19314] Typo in devguide - compiler
Message-ID: <1382270595.82.0.866623736172.issue19314@psf.upfronthosting.co.za>


New submission from Martin Matusiak:

- Querying data from the node structs can be done with the following macros (which are all defined in Include/token.h

They are actually in Include/node.h, which is logical, because that is where "node" is defined.

----------
components: Devguide
files: typo_compiler_nodeh.diff
keywords: patch
messages: 200569
nosy: ezio.melotti, numerodix
priority: normal
severity: normal
status: open
title: Typo in devguide - compiler
Added file: http://bugs.python.org/file32244/typo_compiler_nodeh.diff

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

From report at bugs.python.org  Sun Oct 20 14:12:53 2013
From: report at bugs.python.org (Martin Matusiak)
Date: Sun, 20 Oct 2013 12:12:53 +0000
Subject: [New-bugs-announce] [issue19315] devguide: compiler - poor wording
Message-ID: <1382271173.25.0.518279475594.issue19315@psf.upfronthosting.co.za>


New submission from Martin Matusiak:

Location:
http://docs.python.org/devguide/compiler.html#parse-trees

- To tie all of this example, consider the rule for ?while?:

Probably meant to be: To tie all of this together with an example, ...

- The node representing this will have TYPE(node) == while_stmt and the number of children can be 4 or 7 depending on if there is an ?else? statement.

s/if/whether/g is slightly better English imo

- To access what should be the first ?:? and require it be an actual ?:? token, (REQ(CHILD(node, 2), COLON)`.

Understandable with some effort on the reader's part, but it's not very well worded.

Notice also the closing backtick: markup typo.

----------
components: Devguide
messages: 200570
nosy: ezio.melotti, numerodix
priority: normal
severity: normal
status: open
title: devguide: compiler - poor wording

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

From report at bugs.python.org  Sun Oct 20 14:28:46 2013
From: report at bugs.python.org (Martin Matusiak)
Date: Sun, 20 Oct 2013 12:28:46 +0000
Subject: [New-bugs-announce] [issue19316] devguide: compiler - wording
Message-ID: <1382272126.03.0.859419260116.issue19316@psf.upfronthosting.co.za>


New submission from Martin Matusiak:

-  All code relating to the arena is in either Include/pyarena.h or Python/pyarena.c .

I propose: All code relating to the arena is either in Include/pyarena.h or in Python/pyarena.c .

----------
components: Devguide
files: wording_compiler.diff
keywords: patch
messages: 200572
nosy: ezio.melotti, numerodix
priority: normal
severity: normal
status: open
title: devguide: compiler - wording
Added file: http://bugs.python.org/file32246/wording_compiler.diff

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

From report at bugs.python.org  Sun Oct 20 17:31:38 2013
From: report at bugs.python.org (=?utf-8?q?Maciej_Blizi=C5=84ski?=)
Date: Sun, 20 Oct 2013 15:31:38 +0000
Subject: [New-bugs-announce] [issue19317] ctypes.util.find_library should
	examine binary's RPATH	on Solaris
Message-ID: <1382283098.83.0.173984225129.issue19317@psf.upfronthosting.co.za>


New submission from Maciej Blizi?ski:

On Solaris, when you want to link shared libraries from custom directories, you most often don't modify the system search path, but instead set RPATH in your binaries. For example, OpenCSW packages Python into /opt/csw, and sets Python executable's RPATH to /opt/csw/lib. Therefore, dynamically opening shared libraries will by default look into /opt/csw/lib first, and find_library should do the same. I wrote a sample implementation.

----------
components: ctypes
files: find_library_looks_into_rpath.patch
keywords: patch
messages: 200593
nosy: automatthias
priority: normal
severity: normal
status: open
title: ctypes.util.find_library should examine binary's RPATH on Solaris
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32255/find_library_looks_into_rpath.patch

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

From report at bugs.python.org  Sun Oct 20 20:19:17 2013
From: report at bugs.python.org (James Lu)
Date: Sun, 20 Oct 2013 18:19:17 +0000
Subject: [New-bugs-announce] [issue19318] break more than once
Message-ID: <1382293157.67.0.695051872631.issue19318@psf.upfronthosting.co.za>


New submission from James Lu:

break 2 would break out of one loop then break out of another.
break
break
would just break once and not execute the second break.
break 2 when there are only 1 thing to break would raise raise a SyntaxError: Can only break 1 time, need to break 2 times.

----------
messages: 200603
nosy: James.Lu
priority: normal
severity: normal
status: open
title: break more than once

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

From report at bugs.python.org  Sun Oct 20 20:19:33 2013
From: report at bugs.python.org (Christoph Baumgartner)
Date: Sun, 20 Oct 2013 18:19:33 +0000
Subject: [New-bugs-announce] [issue19319] misleading comment regarding C
Message-ID: <1382293173.85.0.561092351963.issue19319@psf.upfronthosting.co.za>


New submission from Christoph Baumgartner:

The documentation about ctypes.sizeof:

"Returns the size in bytes of a ctypes type or instance memory buffer. Does the same as the C sizeof() function."

'sizeof' is an operator. I would drop the parentheses as well.

----------
assignee: docs at python
components: Documentation
messages: 200604
nosy: Christoph.Baumgartner, docs at python
priority: normal
severity: normal
status: open
title: misleading comment regarding C

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

From report at bugs.python.org  Sun Oct 20 22:47:36 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Oct 2013 20:47:36 +0000
Subject: [New-bugs-announce] [issue19320] Tkinter tests ran with wantobjects
	is false
Message-ID: <1382302056.06.0.500513298536.issue19320@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

On some Windows buildbots (e.g. [1]) Tkinter tests ran with wantobjects is false. This brake some tests purposed to check converting values between Python and Tcl.

There are two solutions.
1) Skip these tests if wantobjects is false.
2) If wantobjects is false tests with other expected values.

[1] http://buildbot.python.org/all/builders/x86%20Windows%20Server%202003%20%5BSB%5D%202.7

----------
components: Library (Lib), Tkinter
messages: 200630
nosy: gpolo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Tkinter tests ran with wantobjects is false
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Oct 20 23:00:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Oct 2013 21:00:32 +0000
Subject: [New-bugs-announce] [issue19321] memoryview should be a context
	manager
Message-ID: <1382302832.21.0.943595938282.issue19321@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

memoryview() acquires resource but it rarely released explicitly. I propose to made memoryview a context manager which calls the release() method in the __exit__() method. Perhaps it worth also add resource warning in the __del__() method if a memoryview was not released.

----------
components: Interpreter Core
keywords: easy
messages: 200633
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: memoryview should be a context manager
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Oct 21 05:26:24 2013
From: report at bugs.python.org (David)
Date: Mon, 21 Oct 2013 03:26:24 +0000
Subject: [New-bugs-announce] [issue19322] Python crashes on re.search in new
	regex module.
Message-ID: <1382325984.24.0.110925786536.issue19322@psf.upfronthosting.co.za>


New submission from David:

Python crashes while executing the following code using the new regex module. Have I made a mistake?

import regex as re
rx = re.compile(r'\bt(est){i<2}', flags=re.V1)
print "Prints here"
rx.findall("Some text") # Python crashes
print "Fails to print"

I get the same results using 64-bit and 32-bit Python on Windows 7 (64bit) when using regex-2013-10-04 and regex-2013-08-04. However, the code does not crash when using regex-2013-03-11.

----------
components: Regular Expressions
messages: 200690
nosy: cronkd, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Python crashes on re.search in new regex module.
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Oct 21 09:05:12 2013
From: report at bugs.python.org (Michael Merickel)
Date: Mon, 21 Oct 2013 07:05:12 +0000
Subject: [New-bugs-announce] [issue19323] typo in statistics documentation
Message-ID: <1382339112.75.0.593469307038.issue19323@psf.upfronthosting.co.za>


New submission from Michael Merickel:

http://docs.python.org/dev/library/statistics.html#mean describes the mean as "effected" by outliers, when it should say "affected".

----------
assignee: docs at python
components: Documentation
messages: 200704
nosy: docs at python, mmerickel
priority: normal
severity: normal
status: open
title: typo in statistics documentation
versions: Python 3.4

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

From report at bugs.python.org  Mon Oct 21 10:58:55 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 21 Oct 2013 08:58:55 +0000
Subject: [New-bugs-announce] [issue19324] Expose Linux-specific APIs in
	resource module
Message-ID: <1382345935.87.0.308038663771.issue19324@psf.upfronthosting.co.za>


New submission from Christian Heimes:

See #16595
and http://mail.python.org/pipermail/python-ideas/2012-June/015323.html

I'm going to add the extra constants before beta.

RLIMIT_MSGQUEUE
RLIMIT_NICE
RLIMIT_RTPRIO
RLIMIT_RTTIME
RLIMIT_SIGPENDING

----------
assignee: christian.heimes
messages: 200727
nosy: christian.heimes, giampaolo.rodola
priority: normal
severity: normal
stage: needs patch
status: open
title: Expose Linux-specific APIs in resource module
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Oct 21 11:09:04 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 21 Oct 2013 09:09:04 +0000
Subject: [New-bugs-announce] [issue19325] _osx_support imports many modules
Message-ID: <1382346544.59.0.0118958375765.issue19325@psf.upfronthosting.co.za>


New submission from Christian Heimes:

On Mac OS X the site module imports sysconfig which imports _osx_support which in turn imports several more modules like the re module. More modules == slower startup. See #19205 for background information on the issue.

----------
assignee: ronaldoussoren
components: Library (Lib), Macintosh
messages: 200733
nosy: christian.heimes, ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: _osx_support imports many modules
type: performance
versions: Python 3.4

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

From report at bugs.python.org  Mon Oct 21 12:15:57 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 21 Oct 2013 10:15:57 +0000
Subject: [New-bugs-announce] [issue19326] asyncio: child process exit isn't
	detected if its	stdin/stdout/stderr FDs have been inherited
	by a child process
Message-ID: <1382350557.5.0.977227670741.issue19326@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

(This is a spinoff from http://bugs.python.org/issue19293#msg200598)

When SIGCHLD is received, _sig_chld() is executed:

    def _sig_chld(self):
        [...]
        transp = self._subprocesses.get(pid)
        if transp is not None:
            transp._process_exited(returncode)

Then, here's _process_exited():

    def _process_exited(self, returncode):
        assert returncode is not None, returncode
        assert self._returncode is None, self._returncode
        self._returncode = returncode
        self._loop._subprocess_closed(self)
        self._call(self._protocol.process_exited)
        self._try_finish()

And here's _try_finish():

    def _try_finish(self):
        assert not self._finished
        if self._returncode is None:
            return
        if all(p is not None and p.disconnected
               for p in self._pipes.values()):
            self._finished = True
            self._loop.call_soon(self._call_connection_lost, None)

Thus, _UnixSubprocessTransport protocol's connection_lost is only
called if the all() expression is true:
and it's true only if all the subprocess pipes have been disconnected
(or if we didn't setup any pipe).

Unfortunately, this might very well never happen: imagine that the
subprocess forks a process: this grand-child process inherits the
child process's pipes, so when the child process exits, we won't
receive any notification, since this grand-child process still has
open FDs pointing to the original child's stdin/stdout/stderr.

The following simple test will hang until the background 'sleep' exits:
"""
diff -r 47618b00405b Lib/test/test_asyncio/test_events.py
--- a/Lib/test/test_asyncio/test_events.py      Sat Oct 19 10:45:48 2013 +0300
+++ b/Lib/test/test_asyncio/test_events.py      Sun Oct 20 19:32:37 2013 +0200
@@ -1059,6 +1059,23 @@

     @unittest.skipIf(sys.platform == 'win32',
                      "Don't support subprocess for Windows yet")
+    def test_subprocess_inherit_fds(self):
+        proto = None
+
+        @tasks.coroutine
+        def connect():
+            nonlocal proto
+            transp, proto = yield from self.loop.subprocess_shell(
+                functools.partial(MySubprocessProtocol, self.loop),
+                'sleep 60 &')
+            self.assertIsInstance(proto, MySubprocessProtocol)
+
+        self.loop.run_until_complete(connect())
+        self.loop.run_until_complete(proto.completed)
+        self.assertEqual(0, proto.returncode)
+
+    @unittest.skipIf(sys.platform == 'win32',
+                     "Don't support subprocess for Windows yet")
     def test_subprocess_close_after_finish(self):
         proto = None
         transp = None
"""

If waitpid() returns a process's PID, then the process is done,
there's no reason to further wait for pipe's disconnection: they can
be used as a hint that the process terminated, but there's definitely
not required...

----------
messages: 200744
nosy: neologix
priority: normal
severity: normal
stage: needs patch
status: open
title: asyncio: child process exit isn't detected if its stdin/stdout/stderr FDs have been inherited by a child process
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Oct 21 13:24:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Oct 2013 11:24:02 +0000
Subject: [New-bugs-announce] [issue19327] re doesn't work with big charsets
Message-ID: <1382354642.85.0.292267314157.issue19327@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

>>> import re
>>> re.compile('[%s]' % ''.join(map(chr, range(256, 2**16, 255))))
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/sre_compile.py", line 211, in _optimize_charset
    charmap[fixup(av)] = 1
IndexError: list assignment index out of range

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/re.py", line 213, in compile
    return _compile(pattern, flags)
  File "/home/serhiy/py/cpython/Lib/re.py", line 280, in _compile
    p = sre_compile.compile(pattern, flags)
  File "/home/serhiy/py/cpython/Lib/sre_compile.py", line 489, in compile
    code = _code(p, flags)
  File "/home/serhiy/py/cpython/Lib/sre_compile.py", line 471, in _code
    _compile_info(code, p, flags)
  File "/home/serhiy/py/cpython/Lib/sre_compile.py", line 459, in _compile_info
    _compile_charset(charset, flags, code)
  File "/home/serhiy/py/cpython/Lib/sre_compile.py", line 177, in _compile_charset
    for op, av in _optimize_charset(charset, fixup):
  File "/home/serhiy/py/cpython/Lib/sre_compile.py", line 220, in _optimize_charset
    return _optimize_unicode(charset, fixup)
  File "/home/serhiy/py/cpython/Lib/sre_compile.py", line 342, in _optimize_unicode
    mapping = array.array('b', mapping).tobytes()
OverflowError: signed char is greater than maximum

----------
assignee: serhiy.storchaka
components: Library (Lib), Regular Expressions
files: re_bigcharset.patch
keywords: patch
messages: 200747
nosy: ezio.melotti, mrabarnett, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: re doesn't work with big charsets
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32277/re_bigcharset.patch

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

From report at bugs.python.org  Mon Oct 21 13:38:16 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 21 Oct 2013 11:38:16 +0000
Subject: [New-bugs-announce] [issue19328] Improve PBKDF2 documentation
Message-ID: <1382355496.68.0.742475173572.issue19328@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The new pbkdf2_hmac() feature #18582 #19254 needs more documentation. I'm going to explain round count, salt generation, user vs. application salt, salt length etc.

----------
assignee: christian.heimes
components: Documentation
messages: 200749
nosy: christian.heimes
priority: normal
severity: normal
stage: test needed
status: open
title: Improve PBKDF2 documentation
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Oct 21 14:01:18 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Oct 2013 12:01:18 +0000
Subject: [New-bugs-announce] [issue19329] Faster compiling of big charset
	regexpes
Message-ID: <1382356878.81.0.973141365685.issue19329@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which speed up compiling of regular expressions with big charsets.

Microbenchmark:
$ ./python -m timeit "from sre_compile import compile; r = '[%s]' % ''.join(map(chr, range(256, 2**16, 255)))"  "compile(r, 0)"

Unpatched (but with fixed issue19327): 119 msec per loop
Patched: 59.6 msec per loop

Compiling regular expressions with big charset was main cause of slowing down importing the email.message module (issue11454).

----------
assignee: serhiy.storchaka
components: Library (Lib), Regular Expressions
files: re_mk_bitmap.patch
keywords: patch
messages: 200755
nosy: ezio.melotti, haypo, mrabarnett, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Faster compiling of big charset regexpes
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file32278/re_mk_bitmap.patch

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

From report at bugs.python.org  Mon Oct 21 16:00:52 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 21 Oct 2013 14:00:52 +0000
Subject: [New-bugs-announce] [issue19330] Use public classes for
	contextlib.suppress and	redirect_stdout
Message-ID: <1382364052.22.0.450047950138.issue19330@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

I broke help() for instances of these context managers by trying to postpone exposing the class APIs until 3.5 (and didn't even record my full rationale, however flawed, in the associated comments).

The wrapper functions should be removed, making the classes the public implementation. I also plan to make the following changes (although I may end up moving them to separate issues):

- provide (and document) a public "target" attribute on redirect_stdout
- make redirect_stdout reentrant (and switch to ExitStack as the reusable-but-not-reentrant example)

- provide (and document) a public "exceptions" attribute on suppress
- return self from suppress.__enter__

----------
assignee: ncoghlan
components: Library (Lib)
messages: 200782
nosy: larry, ncoghlan
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Use public classes for contextlib.suppress and redirect_stdout
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Oct 21 16:01:48 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 21 Oct 2013 14:01:48 +0000
Subject: [New-bugs-announce] [issue19331] Revise PEP 8 recommendation for
	class names
Message-ID: <1382364108.83.0.592480403248.issue19331@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

PEP 8 says:

"""
Class Names
Almost without exception, class names use the CapWords convention. Classes for internal use have a leading underscore in addition.
"""

yet there are some notable exceptions in practice, such as classes designed to be context managers (used with the `with` statement).

This message indicates Nick's implementation choice of a wrapper function in part to avoid naming a class with all lower cases (which look better with `with`, but break the PEP 8 convention).

https://mail.python.org/pipermail/python-dev/2013-October/129791.html

The PEP 8 language should be revised, but striking the right balance might be a little tricky.

----------
messages: 200783
nosy: barry
priority: normal
severity: normal
status: open
title: Revise PEP 8 recommendation for class names

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

From report at bugs.python.org  Mon Oct 21 16:02:54 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Oct 2013 14:02:54 +0000
Subject: [New-bugs-announce] [issue19332] Guard against changing dict during
	iteration
Message-ID: <1382364174.9.0.836332683158.issue19332@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently dict iterating is guarded against changing dict's size. However when dict changed during iteration so that it's size left unchanged, this modification left unnoticed.

>>> d = dict.fromkeys('abcd')
>>> for i in d:
...     print(i)
...     d[i + 'x'] = None
...     del d[i]
... 
d
a
dx
dxx
ax
c
b

In general iterating over mutating dict considered logical error. It is good detect it as early as possible.

The proposed patch introduces a counter which changed every time when added or removed key. If an iterator detects that this counter is changed, it raises runtime error.

----------
components: Interpreter Core
files: dict_mutating_iteration.patch
keywords: patch
messages: 200784
nosy: pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Guard against changing dict during iteration
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32279/dict_mutating_iteration.patch

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

From report at bugs.python.org  Mon Oct 21 16:05:17 2013
From: report at bugs.python.org (Marius Gedminas)
Date: Mon, 21 Oct 2013 14:05:17 +0000
Subject: [New-bugs-announce] [issue19333]
	distutils.util.grok_environment_error loses the error	message
Message-ID: <1382364317.14.0.23941931119.issue19333@psf.upfronthosting.co.za>


New submission from Marius Gedminas:

Steps to reproduce:

$ python -c 'from distutils.util import grok_environment_error as e; print(e(IOError("message")))'

What I expect to see:
error: message

What I get instead:
error: None

This is a problem because it hides the error message in a real-life use case: trying to use the latest setuptools in an ancient virtualenv (see [1]).  TL;DR version:
- sysconfig (in the standard library) raises IOError(msg),
- which is then caught and passed throughdistutils.util.grok_environment_error(),
- which then returns an unfriendly 'error: None'.

[1] https://bitbucket.org/pypa/setuptools/issue/89/easy_install-quits-with-error-none-in

----------
assignee: eric.araujo
components: Distutils
messages: 200785
nosy: eric.araujo, mgedmin, tarek
priority: normal
severity: normal
status: open
title: distutils.util.grok_environment_error loses the error message
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon Oct 21 16:45:17 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 21 Oct 2013 14:45:17 +0000
Subject: [New-bugs-announce] [issue19334] test_asyncio hanging for 1 hour
	(non-AIX version)
Message-ID: <1382366717.5.0.644107908192.issue19334@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

There are still some problems with asyncio tests hanging on FreeBSD and possibly other platforms.

While these were originally conflated with a hang on AIX, the root causes are different; just the symptoms are the same (the test hangs forever and after exactly one hour the test runner kills the process).

I'm opening a new issue to discuss the issues on platforms other than AIX.

----------
messages: 200790
nosy: db3l, gvanrossum, haypo, larry, ncoghlan, neologix, pitrou, python-dev, sbt, skrah
priority: normal
severity: normal
status: open
title: test_asyncio hanging for 1 hour (non-AIX version)
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Oct 21 18:30:00 2013
From: report at bugs.python.org (Chris Angelico)
Date: Mon, 21 Oct 2013 16:30:00 +0000
Subject: [New-bugs-announce] [issue19335] IDLE over-enthusiastically
	verifies 'nonlocal' usage
Message-ID: <1382373000.68.0.189461007664.issue19335@psf.upfronthosting.co.za>


New submission from Chris Angelico:

IDLE tries to be helpful, but it errors on something that isn't yet an error. Pasting in this code works fine:

>>> def a():
	def b():
		nonlocal q
		q+=1
	q=1
	b()
	return q

>>> a()
2

But typing it, line by line, results in an error:

>>> def a():
	def b():
		nonlocal q
		
SyntaxError: no binding for nonlocal 'q' found

This doesn't occur with interactive command-line Python. A small issue, more of curiosity value than anything else - I don't have a non-trivial use-case where this causes problems.

----------
components: IDLE
messages: 200809
nosy: Rosuav
priority: normal
severity: normal
status: open
title: IDLE over-enthusiastically verifies 'nonlocal' usage
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Oct 21 18:34:26 2013
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 21 Oct 2013 16:34:26 +0000
Subject: [New-bugs-announce] [issue19336] No API to get events from epoll
	without allocating a list
Message-ID: <1382373266.71.0.522503434319.issue19336@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

select.epoll should expose an api such as `iterpoll` which returns an iterator over the ready events, rather than a list. Allocating a list is wasteful in many cases (e.g. twisted's event loop) and it'd be nice to have an API that was less wasteful.

----------
messages: 200810
nosy: alex
priority: normal
severity: normal
status: open
title: No API to get events from epoll without allocating a list

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

From report at bugs.python.org  Mon Oct 21 20:24:45 2013
From: report at bugs.python.org (Ribhi Kamal)
Date: Mon, 21 Oct 2013 18:24:45 +0000
Subject: [New-bugs-announce] [issue19337] MMAP: Bus error (core dump) under
	heavy read/write
Message-ID: <1382379885.04.0.64581281764.issue19337@psf.upfronthosting.co.za>


New submission from Ribhi Kamal:

I was about to use memory mapping for something when I discovered that the code example posted on python.org causes python to core dump. %100 reproducible

The steps are really simple. 
1- Create a file and map it using mmap.mmap
2- In a while loop, contintously read the file
3- From another process, like bash, continuously write to the file.

After about 5 iterations from the reader, python core dumps.

Reader code (python):
#!/usr/bin/python2.7

import mmap
import time

with open("hello.txt", "wb") as f:
    f.write("Hello Python! 1234123412341234\n")

with open("hello.txt", "r+b") as f:
    # memory-map the file, size 0 means whole file
    mm = mmap.mmap(f.fileno(), 0)
    count=0
    while count < 100:
       mm.seek(0)
       print mm.readline()
       time.sleep(0.1)
       count = count + 1

    # close the map
    mm.close()


Writer code (linux shell/bash):
#!/bin/bash
count=0
while true
do
 ((count++))
 echo $count > hello.txt
done


Now run the reader, then launch the writer in a terminal. In my case I get the following output:
>110
>
>462
>
>Bus error (core dumped)


Python 2.7.3
Linux 3.2.0-54-generic #82-Ubuntu SMP Tue Sep 10 20:09:12 UTC 2013 i686 i686 i386 GNU/Linux
Ubuntu 12.04.3 LTS
Intel(R) Core(TM)2 CPU          6300  @ 1.86GHz

----------
components: IO
messages: 200820
nosy: rbhkamal
priority: normal
severity: normal
status: open
title: MMAP: Bus error (core dump) under heavy read/write
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Oct 21 21:58:25 2013
From: report at bugs.python.org (Brodie Rao)
Date: Mon, 21 Oct 2013 19:58:25 +0000
Subject: [New-bugs-announce] [issue19338] multiprocessing: sys.exit() from a
	child with a non-int	exit code exits with 0
Message-ID: <1382385505.82.0.388398051493.issue19338@psf.upfronthosting.co.za>


New submission from Brodie Rao:

Normally:

  $ python
  >>> import sys
  >>> sys.exit('foo')
  foo
  $ echo $?
  1

However, with multiprocessing:

  >>> import sys
  >>> from multiprocessing import Process
  >>> p = Process(target=lambda: sys.exit('foo'))
  >>> p.start()
  >>> foo
  
  >>> p.join()
  >>> p.is_alive()
  False
  >>> p.exitcode
  0

p.exitcode should be 1, not 0. sys.exit() with a non-int object should always exit with 1.

This regression was introduced in da5b370f41a1 on the 2.7 branch (making it into the 2.7.4 release) and 4346cba353b4 on the 3.2 branch (making it into the 3.2.5 release).

Less important things to note:

- multiprocessing calls str() on the object passed to sys.exit() to print it out. The interpreter doesn't do that with the argument is a unicode object (it tries to let sys.stderr encode it and print it).

- The interpreter also ignores all exceptions in this process.

I'll attach patches for the 2.7 and 3.3 branches that just addresses the exit code problem.

----------
components: Library (Lib)
messages: 200833
nosy: brodie
priority: normal
severity: normal
status: open
title: multiprocessing: sys.exit() from a child with a non-int exit code exits with 0
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/issue19338>
_______________________________________

From report at bugs.python.org  Mon Oct 21 22:01:15 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Oct 2013 20:01:15 +0000
Subject: [New-bugs-announce] [issue19339] telnetlib: time.monotonic() should
	be used instead of	time.time() for timeout
Message-ID: <1382385675.07.0.888544622289.issue19339@psf.upfronthosting.co.za>


New submission from STINNER Victor:

While reading the patch attached to #19170, I saw that telnetlib uses time.time() to compute a timeout. This is wrong: the system clock may jump forward or backward (ex: summer/winter time, NTP adjust, manual clock change by the administrator, etc.).

time.monotonic() should be used instead. I will work on a patch when #19170 will be fixed (just to avoid conflicts).

----------
messages: 200834
nosy: haypo, neologix
priority: normal
severity: normal
status: open
title: telnetlib: time.monotonic() should be used instead of time.time() for timeout
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Oct 21 23:22:36 2013
From: report at bugs.python.org (Sunny K)
Date: Mon, 21 Oct 2013 21:22:36 +0000
Subject: [New-bugs-announce] [issue19340] test_sysconfig.test_srcdir fails
	when sys.base_prefix="/"
Message-ID: <1382390556.96.0.439992623328.issue19340@psf.upfronthosting.co.za>


New submission from Sunny K:

While working on issue7757, i noticed that test_srcdir fails when python is built with prefix "".

This is because in Lib/sysconfig.py, _safe_realpath() is called on srcdir which normalises //lib to /lib. In the test case, it is compared directly to the output of get_makefile_filename().


======================================================================
FAIL: test_srcdir (__main__.TestSysConfig)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/lib/python3.4/test/test_sysconfig.py", line 356, in test_srcdir
    srcdir)
AssertionError: '//lib/python3.4/config-3.4dm' != '/lib/python3.4/config-3.4dm'
- //lib/python3.4/config-3.4dm
? -
+ /lib/python3.4/config-3.4dm

~/cpython$ python3.4
Python 3.4.0a3+ (default:dad1debba93c+, Oct 22 2013, 02:32:50)
[GCC 4.4.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.prefix
'/'
>>> sys.base_prefix
'/'
>>>

----------
components: Tests
messages: 200849
nosy: sunfinite
priority: normal
severity: normal
status: open
title: test_sysconfig.test_srcdir fails when sys.base_prefix="/"
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Oct 22 09:27:59 2013
From: report at bugs.python.org (David Planella)
Date: Tue, 22 Oct 2013 07:27:59 +0000
Subject: [New-bugs-announce] [issue19341] locale.getdefaultencoding()
	returns wrong locale and	encoding for ca_ES@valencia
Message-ID: <1382426879.55.0.340515652072.issue19341@psf.upfronthosting.co.za>


New submission from David Planella:

It seems getdefaultlocale does not return the correct encoding when the locale is set to ca_ES at valencia:

>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
'LC_CTYPE=ca_ES.UTF-8 at valencia;LC_NUMERIC=ca_ES.UTF-8;LC_TIME=ca_ES.UTF-8;LC_COLLATE=ca_ES.UTF-8 at valencia;LC_MONETARY=ca_ES.UTF-8;LC_MESSAGES=ca_ES.UTF-8 at valencia;LC_PAPER=ca_ES.UTF-8;LC_NAME=ca_ES.UTF-8;LC_ADDRESS=ca_ES.UTF-8;LC_TELEPHONE=ca_ES.UTF-8;LC_MEASUREMENT=ca_ES.UTF-8;LC_IDENTIFICATION=ca_ES.UTF-8'
>>> locale.getdefaultlocale()
('ca_ES', 'utf_8_valencia')

Instead of 'utf_8_valencia', here I'd expect 'UTF-8' to be returned. The returned locale is also wrong: it should be ca_ES at valencia.

Looking quickly at the locale module's source code, it seems that the following item should be added to the locale_alias dict?

   'ca_es. at valencia':                      'ca_ES at valencia.UTF-8',

----------
components: Library (Lib)
messages: 200886
nosy: dpm
priority: normal
severity: normal
status: open
title: locale.getdefaultencoding() returns wrong locale and encoding for ca_ES at valencia
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Oct 22 10:58:23 2013
From: report at bugs.python.org (Marius Gedminas)
Date: Tue, 22 Oct 2013 08:58:23 +0000
Subject: [New-bugs-announce] [issue19342] Improve grp module docstrings
Message-ID: <1382432303.67.0.186570774383.issue19342@psf.upfronthosting.co.za>


New submission from Marius Gedminas:

This patch gives grp.getgrnam and grp.getgrgid sligtly more useful docstrings, and brings them in line with pwd.getpwnam/pwd.getpwuid.

Compare pydoc pwd.getpwnam:

    pwd.getpwnam = getpwnam(...)
        getpwnam(name) -> (pw_name,pw_passwd,pw_uid,
                            pw_gid,pw_gecos,pw_dir,pw_shell)
        Return the password database entry for the given user name.
        See help(pwd) for more on password database entries.

After looking at it I know that I can convert a name to an UID by doing pwd.getpwnam(name).pw_uid.

Meanwhile pydoc grp.getgrnam:

    grp.getgrnam = getgrnam(...)
        getgrnam(name) -> tuple
        Return the group database entry for the given group name.  If
        name is not valid, raise KeyError.

is rather unfriendly and makes me reach for Google just so that I could find out the names of the namedtuple members.

----------
assignee: docs at python
components: Documentation
files: grpmodule-docstrings.patch
keywords: patch
messages: 200896
nosy: docs at python, mgedmin
priority: normal
severity: normal
status: open
title: Improve grp module docstrings
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32295/grpmodule-docstrings.patch

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

From report at bugs.python.org  Tue Oct 22 11:27:18 2013
From: report at bugs.python.org (koobs)
Date: Tue, 22 Oct 2013 09:27:18 +0000
Subject: [New-bugs-announce] [issue19343] Expose FreeBSD-specific APIs in
	resource module
Message-ID: <1382434038.91.0.920002784924.issue19343@psf.upfronthosting.co.za>


New submission from koobs:

At Christians request:

RLIMIT_SBSIZE
The maximum size (in bytes) of socket buffer usage for
this user.  This limits the amount of network memory, and
hence the amount of mbufs, that this user may hold at any
time.

RLIMIT_SWAP
The maximum size (in bytes) of the swap space that may be
reserved or used by all of this user id's processes.
This limit is enforced only if bit 1 of the vm.overcommit
sysctl is set.  Please see tuning(7) for a complete
description of this sysctl.

RLIMIT_NPTS
The maximum number of pseudo-terminals created by this
user id.

All of the above exists on both FreeBSD 9-stable (9.x) and 10-stable (10.x)

----------
messages: 200903
nosy: koobs
priority: normal
severity: normal
status: open
title: Expose FreeBSD-specific APIs in resource module

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

From report at bugs.python.org  Tue Oct 22 11:53:43 2013
From: report at bugs.python.org (Marius Gedminas)
Date: Tue, 22 Oct 2013 09:53:43 +0000
Subject: [New-bugs-announce] [issue19345] Unclear phrasing in
	whatsnew/3.4.rst
Message-ID: <1382435623.18.0.649588636826.issue19345@psf.upfronthosting.co.za>


New submission from Marius Gedminas:

Quoting http://docs.python.org/dev/whatsnew/3.4.html#deprecated-functions-and-types-of-the-c-api

> The PyThreadState.tick_counter field has been value: its value was meaningless since Python 3.2 (?new GIL?).

I've no idea what "has been value" is supposed to be.  Perhaps "has been deprecated"?

No patch this time since I'm not sure what was meant here.

----------
assignee: docs at python
components: Documentation
messages: 200909
nosy: docs at python, mgedmin
priority: normal
severity: normal
status: open
title: Unclear phrasing in whatsnew/3.4.rst
versions: Python 3.4

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

From report at bugs.python.org  Tue Oct 22 11:47:43 2013
From: report at bugs.python.org (Marius Gedminas)
Date: Tue, 22 Oct 2013 09:47:43 +0000
Subject: [New-bugs-announce] [issue19344] ReStructuredText error in
	whatsnew/3.4.rst
Message-ID: <1382435263.38.0.923957095202.issue19344@psf.upfronthosting.co.za>


New submission from Marius Gedminas:

Trivial syntax fix attached

----------
assignee: docs at python
components: Documentation
files: whatsnew-rst-fix.patch
keywords: patch
messages: 200907
nosy: docs at python, mgedmin
priority: normal
severity: normal
status: open
title: ReStructuredText error in whatsnew/3.4.rst
versions: Python 3.4
Added file: http://bugs.python.org/file32296/whatsnew-rst-fix.patch

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

From report at bugs.python.org  Tue Oct 22 13:47:28 2013
From: report at bugs.python.org (Alan Hourihane)
Date: Tue, 22 Oct 2013 11:47:28 +0000
Subject: [New-bugs-announce] [issue19346] Build fails when there are no
	shared extensions to be	built
Message-ID: <1382442448.32.0.170952369524.issue19346@psf.upfronthosting.co.za>


New submission from Alan Hourihane:

When building python with static extensions and therefore there are no shared extensions to be built the extension list can be NULL, and therefore 0 length.

This results in this error....

running build
running build_ext
INFO: Can't locate Tcl/Tk libs and/or headers
Traceback (most recent call last):
  File "/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/setup.py", line 2017, in <module>
    main()
  File "/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/setup.py", line 2011, in main
    'Lib/smtpd.py']
  File "/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Lib/distutils/core.py", line 152, in setup
    dist.run_commands()
  File "/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Lib/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Lib/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Lib/distutils/command/build.py", line 127, in run
    self.run_command(cmd_name)
  File "/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Lib/distutils/cmd.py", line 326, in run_command
    self.distribution.run_command(command)
  File "/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Lib/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Lib/distutils/command/build_ext.py", line 339, in run
    self.build_extensions()
  File "/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/setup.py", line 266, in build_extensions
    longest = max([len(e.name) for e in self.extensions])
ValueError: max() arg is an empty sequence

To fix I replaced this line in setup.py

        longest = max([len(e.name) for e in self.extensions])

to this...

        longest = 0
        for e in self.extensions:
            longest = max(longest, len(e.name))

----------
components: Build
messages: 200922
nosy: alanh
priority: normal
severity: normal
status: open
title: Build fails when there are no shared extensions to be built
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Tue Oct 22 13:48:34 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 22 Oct 2013 11:48:34 +0000
Subject: [New-bugs-announce] [issue19347] PEP 453 implementation tracking
	issue
Message-ID: <1382442514.8.0.354499850572.issue19347@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

This is the overall tracking issue for the implementation of PEP 453. The following subtasks will be created as separate issues:

- update the Installing Python Modules documentation to reference www.pip-installer.org in Python 2.7, 3.3 and 3.4 (ncoghlan)
- initial implementation of ensurepip (dstufft)
- Python 3.4 documentation updates for ensurepip (dstufft and/or ncoghlan)
- Windows installer updates, including PATH manipulation updates (MvL?)
- Mac OS X installer updates (Ned?)
- venv and pyvenv updates (dstufft? TBC)

----------
assignee: ncoghlan
messages: 200923
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: PEP 453 implementation tracking issue
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Oct 22 13:54:06 2013
From: report at bugs.python.org (Alan Hourihane)
Date: Tue, 22 Oct 2013 11:54:06 +0000
Subject: [New-bugs-announce] [issue19348] Building _testcapimodule as a
	builtin results in compile	error
Message-ID: <1382442846.46.0.759535198419.issue19348@psf.upfronthosting.co.za>


New submission from Alan Hourihane:

When building _testcapimodule.c as a builtin module, the build fails with this error because it doesn't take into account Py_BUILD_CORE from datetime.h.

m68k-atari-mint-gcc -I. -IInclude -I/j/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Include  -I/usr/include -fno-strict-aliasing -O2 -pipe -fwrapv -DNDEBUG    -DPy_BUILD_CORE  -c /j/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/_testcapimodule.c -o Modules/_testcapimodule.o
/j/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/_testcapimodule.c: In function 'test_datetime_capi':
/j/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/_testcapimodule.c:1281:9: error: 'PyDateTimeAPI' undeclared (first use in this function)
/j/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/_testcapimodule.c:1281:9: note: each undeclared identifier is reported only once for each function it appears in
/j/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/_testcapimodule.c:1293:5: error: 'PyDateTime_IMPORT' undeclared (first use in this function)
/j/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/_testcapimodule.c: In function 'test_string_from_format':
/j/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/_testcapimodule.c:1444:5: warning: format '%zd' expects argument of type 'signed size_t', but argument 2 has type 'int' [-Wformat]
make: *** [Modules/_testcapimodule.o] Error 1

I fixed it by adding this around the datetime.h include in _testcapimodule.c but not sure if this is correct....

/* Differentiate between building the core module and building extension
 * modules.
 */
#ifdef Py_BUILD_CORE
#undef Py_BUILD_CORE
#include "datetime.h"
#define Py_BUILD_CORE
#else
#include "datetime.h"
#endif

----------
components: Build
messages: 200926
nosy: alanh
priority: normal
severity: normal
status: open
title: Building _testcapimodule as a builtin results in compile error
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Tue Oct 22 14:37:41 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 22 Oct 2013 12:37:41 +0000
Subject: [New-bugs-announce] [issue19349] Not so correct exception message
	when running venv
Message-ID: <1382445461.71.0.435225941381.issue19349@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

In Lib/venv/__init__.py, line 348:

raise ValueError('This script is only for use with Python 3.3')

But I am running Python 3.4. Attached the patch to make it better.

raise ValueError('This script is only for use with Python >= 3.3')

If you feel it does not feel right, any suggestions? "...Python 3.3 and above", "...at least Python 3.3"?

----------
components: Library (Lib)
files: venv_python_version_3_3_above.patch
keywords: patch
messages: 200935
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Not so correct exception message when running venv
versions: Python 3.4
Added file: http://bugs.python.org/file32300/venv_python_version_3_3_above.patch

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

From report at bugs.python.org  Tue Oct 22 15:34:47 2013
From: report at bugs.python.org (Colin Williams)
Date: Tue, 22 Oct 2013 13:34:47 +0000
Subject: [New-bugs-announce] [issue19350] macurl2path coverage
Message-ID: <1382448887.47.0.0212469471287.issue19350@psf.upfronthosting.co.za>


New submission from Colin Williams:

Ported the tests built into the library requiring manual verification over to the testing framework.  Those tests only provided 77% coverage, so I improved that up to 99%.  Can't get the last line because it's only reachable on older model macs.

----------
components: Tests
files: url2pathname.patch
keywords: patch
messages: 200947
nosy: Colin.Williams
priority: normal
severity: normal
status: open
title: macurl2path coverage
Added file: http://bugs.python.org/file32301/url2pathname.patch

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

From report at bugs.python.org  Tue Oct 22 15:58:52 2013
From: report at bugs.python.org (Jason Bray)
Date: Tue, 22 Oct 2013 13:58:52 +0000
Subject: [New-bugs-announce] [issue19351] python msi installers - silent mode
Message-ID: <1382450332.98.0.946317884841.issue19351@psf.upfronthosting.co.za>


New submission from Jason Bray:

Hello, I am working in an IT group, attempting to automate our management of python. This issue applies to both Python 3.4 and Python 2.7.5 and Python 2.7.4

On a Windows machine (both 7 and 8.1 have been tested) when python msi's are installed from the command line using a quiet or passive mode, they do not appear in the "Programs and Features" panel. This leads me to believe that there are missing registry entries when installed in this mode.

When the same msi is used, but in interactive mode, everything appears to install correctly. While I am able to install and uninstall normally using the command line, this creates issues for manual uninstallation of python, as well as for managing it with automation tools like puppet.

----------
components: Installation
messages: 200955
nosy: Jason.Bray
priority: normal
severity: normal
status: open
title: python msi installers - silent mode
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Tue Oct 22 16:32:55 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Oct 2013 14:32:55 +0000
Subject: [New-bugs-announce] [issue19352] unittest loader barfs on symlinks
Message-ID: <1382452375.52.0.637202424401.issue19352@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

unittest.loader has the following snippet:

                    if realpath.lower() != fullpath_noext.lower():
                        module_dir = os.path.dirname(realpath)
                        mod_name = os.path.splitext(os.path.basename(full_path))[0]
                        expected_dir = os.path.dirname(full_path)
                        msg = ("%r module incorrectly imported from %r. Expected %r. "
                               "Is this module globally installed?")


Unfortunately, this will break with virtualenv on Ubuntu, which creates
a "local" directory full of symlinks. You end with this kind of error message:

======================================================================
ERROR: __main__ (unittest.loader.LoadTestsFailure)
----------------------------------------------------------------------
ImportError: 'test_asyncagi' module incorrectly imported from '/home/antoine/obelus/.tox/py27/local/lib/python2.7/site-packages/obelus/test'. Expected '/home/antoine/obelus/.tox/py27/lib/python2.7/site-packages/obelus/test'. Is this module globally installed?


Instead of (rather stupidly) calling lower(), realpath() and normcase()
should be called instead, to make sure the canonical paths are compared.

----------
components: Library (Lib)
messages: 200964
nosy: barry, michael.foord, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: unittest loader barfs on symlinks
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Oct 22 19:14:26 2013
From: report at bugs.python.org (Matej Cepl)
Date: Tue, 22 Oct 2013 17:14:26 +0000
Subject: [New-bugs-announce] [issue19353] on RHEL6 simple build fails with
	test_linux_constants	(test.test_resource.ResourceTest)
Message-ID: <1382462066.11.0.516691894777.issue19353@psf.upfronthosting.co.za>


New submission from Matej Cepl:

With pure clone of https://github.com/python/cpython.git (no patches applied whatsoever, and the last commit is https://github.com/python/cpython/commit/650406fe7373f31b595b381d4f2f02065607386a) and pure

./configure && make -j2 && make -j2 test I get one failed test:

======================================================================
ERROR: test_linux_constants (test.test_resource.ResourceTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/matej/Repos/cpython/Lib/test/test_resource.py", line 139, in test_linux_constants
    self.assertIsInstance(resource.RLIMIT_RTTIME, int)
AttributeError: 'module' object has no attribute 'RLIMIT_RTTIME'

----------------------------------------------------------------------
Ran 9 tests in 0.468s

FAILED (errors=1, skipped=1)
test test_resource failed
make: *** [test] Error 1

----------
messages: 200973
nosy: mcepl
priority: normal
severity: normal
status: open
title: on RHEL6 simple build fails with test_linux_constants (test.test_resource.ResourceTest)

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

From report at bugs.python.org  Tue Oct 22 20:36:30 2013
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 22 Oct 2013 18:36:30 +0000
Subject: [New-bugs-announce] [issue19354] test_format fails on RHEL-6
Message-ID: <1382466990.37.0.806335115025.issue19354@psf.upfronthosting.co.za>


New submission from Stefan Krah:

Lifting this from #7442:

"Very plain checkout of git and ./configure && make && make test leads to
another failed test, but not this one (issue #19353). So either we do
something wrong in all those Fedora patches, or this has been fixed
since 3.3.2."

If there was a bug, it's quite likely that it has been fixed in 3.4.
In that case it would probably also have been fixed in the development
3.3 branch, so you could check that, too (in mercurial: hg up 3.3).

----------
components: Tests
messages: 200978
nosy: mcepl, skrah
priority: normal
severity: normal
status: open
title: test_format fails on RHEL-6
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Oct 23 03:13:27 2013
From: report at bugs.python.org (Jeffrey Armstrong)
Date: Wed, 23 Oct 2013 01:13:27 +0000
Subject: [New-bugs-announce] [issue19355] Initial modernization of
	OpenWatcom support
Message-ID: <1382490807.69.0.90112979514.issue19355@psf.upfronthosting.co.za>


New submission from Jeffrey Armstrong:

In an attempt to overhaul the existing Open-Watcom-specific portions of CPython, I encountered a number of issues related mostly to preprocessor directives surrounding support for the Open Watcom toolchain on Windows.  Specifically, there were a number of places where #defined(MS_WINDOWS) should be checked prior to checking #defined(__WATCOMC__).  

Additionally, there are some minor differences in the Open Watcom headers from the usual Microsoft headers that lead to problems.  Open Watcom, for example, internally defines PATH_MAX, whereas MSVC does not.  Open Watcom provides a few additional POSIX-y functions on the Windows platform that, again, MSVC does not.

The included patch fixes these minor problems.  The changes should not effect compilation with any other compilers.

I realize Open Watcom probably isn't directly supported at the moment.  I currently have project files, however, that are building CPython with the Open Watcom toolchain with these patches (and a few additional patches - separate issues, though).

----------
components: Build, Windows
files: openwatcom.3.3.2.patch
keywords: patch
messages: 200991
nosy: Jeffrey.Armstrong
priority: normal
severity: normal
status: open
title: Initial modernization of OpenWatcom support
versions: Python 3.3
Added file: http://bugs.python.org/file32307/openwatcom.3.3.2.patch

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

From report at bugs.python.org  Wed Oct 23 04:05:01 2013
From: report at bugs.python.org (Jeffrey Armstrong)
Date: Wed, 23 Oct 2013 02:05:01 +0000
Subject: [New-bugs-announce] [issue19356] Change argument _self in
	_io/textio.c
Message-ID: <1382493901.92.0.326370616383.issue19356@psf.upfronthosting.co.za>


New submission from Jeffrey Armstrong:

At Modules/_io/textio.c:285, one argument to _PyIncrementalNewlineDecoder_decode is named "_self."  The name "_self," however is a keyword on older Microsoft C compilers and certain other compilers attempting to maintain compatibility with Microsoft.  Renaming the argument to "myself" would fix the problem with certain compilers (Microsoft C, Open Watcom, possibly more).

Please note that this is not an issue with MSVC.

----------
components: Build, IO
files: _self.3.3.2.patch
keywords: patch
messages: 200992
nosy: Jeffrey.Armstrong
priority: normal
severity: normal
status: open
title: Change argument _self in _io/textio.c
versions: Python 3.3
Added file: http://bugs.python.org/file32308/_self.3.3.2.patch

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

From report at bugs.python.org  Wed Oct 23 07:27:17 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 23 Oct 2013 05:27:17 +0000
Subject: [New-bugs-announce] [issue19357] Module does not get pulled from
	sys.modules during	importlib testing
Message-ID: <1382506037.35.0.510357174656.issue19357@psf.upfronthosting.co.za>


New submission from Eric Snow:

In Lib/test/test_importlib/import_/test_caching.py, UseCache.test_using_cache "uncaches" "module_to_use", which it really ought to be yanking "some_module".

----------
assignee: eric.snow
components: Tests
messages: 200997
nosy: brett.cannon, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Module does not get pulled from sys.modules during importlib testing
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Oct 23 08:12:31 2013
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 23 Oct 2013 06:12:31 +0000
Subject: [New-bugs-announce] [issue19358] Integrate "Argument Clinic" into
	CPython build
Message-ID: <1382508751.78.0.556655688797.issue19358@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Somebody needs to figure out how to best integrate Argument Clinic into the build.  Antoine, I think you said it sounded like... "fun"?  Maybe?  Anyway, I'm hoping you're willing to take a stab at it.  If not please assign the issue back to nobody, and sorry the intrusion.

----------
assignee: pitrou
components: Build
messages: 201000
nosy: larry, pitrou
priority: normal
severity: normal
status: open
title: Integrate "Argument Clinic" into CPython build
versions: Python 3.4

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

From report at bugs.python.org  Wed Oct 23 09:00:08 2013
From: report at bugs.python.org (Austin Bingham)
Date: Wed, 23 Oct 2013 07:00:08 +0000
Subject: [New-bugs-announce] [issue19359] reversed() does not work with
	weakref.proxy of sequences
Message-ID: <1382511608.51.0.706468574715.issue19359@psf.upfronthosting.co.za>


New submission from Austin Bingham:

When passed a weakref.proxy to a legitimate sequence, reversed() throws a TypeError complaining that its argument isn't a sequence. Perhaps this is the expected behavior, but it's surprising to at least me and the few others I've spoken with about it.

----------
components: Library (Lib)
files: reversed_proxy_failure.py
messages: 201002
nosy: abingham
priority: normal
severity: normal
status: open
title: reversed() does not work with weakref.proxy of sequences
type: behavior
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file32309/reversed_proxy_failure.py

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

From report at bugs.python.org  Wed Oct 23 11:35:31 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Oct 2013 09:35:31 +0000
Subject: [New-bugs-announce] [issue19360] test_site fails when installed
	into $HOME/.local
Message-ID: <1382520931.01.0.426696322436.issue19360@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

If I configure Python with "$HOME/.local" as a prefix, test_site fails:

======================================================================
FAIL: test_s_option (test.test_site.HelperFunctionsTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/opt/Lib/test/test_site.py", line 182, in test_s_option
    self.assertEqual(rc, 0)
AssertionError: 1 != 0

This is because the user site then falls in the same place as the "main" site-packages:

>>> site.getsitepackages()
['/home/antoine/.local/lib/python3.4/site-packages', '/home/antoine/.local/lib/site-python']
>>> site.getusersitepackages()
'/home/antoine/.local/lib/python3.4/site-packages'

(what is "site-python" btw??)

----------
components: Tests
messages: 201011
nosy: christian.heimes, pitrou
priority: low
severity: normal
stage: needs patch
status: open
title: test_site fails when installed into $HOME/.local
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Oct 23 13:22:14 2013
From: report at bugs.python.org (Utkarsh Upadhyay)
Date: Wed, 23 Oct 2013 11:22:14 +0000
Subject: [New-bugs-announce] [issue19361] Specialize exceptions thrown by
	JSON parser
Message-ID: <1382527334.08.0.362620105205.issue19361@psf.upfronthosting.co.za>


New submission from Utkarsh Upadhyay:

The JSON parser currently throws exceptions which contain information about where the error happened but this information is encoded in a string and not available to the programmer. This leads to issues like this: http://stackoverflow.com/questions/19519409/how-to-get-error-location-from-json-loads-in-python

Would it be a problem if the errors thrown were specialized exceptions, e.g. JSONParsingError, which has ValueError as a base class with these details (line number, char number, etc.) exposed as public members? The changes required seem to be limited to changing http://hg.python.org/cpython/file/4c4f31a1b706/Lib/json/decoder.py and the related documentation.

----------
components: Extension Modules
messages: 201015
nosy: musically_ut
priority: normal
severity: normal
status: open
title: Specialize exceptions thrown by JSON parser
type: enhancement

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

From report at bugs.python.org  Wed Oct 23 14:22:08 2013
From: report at bugs.python.org (Gareth Rees)
Date: Wed, 23 Oct 2013 12:22:08 +0000
Subject: [New-bugs-announce] [issue19362] Documentation for len() fails to
	mention that it works	on sets
Message-ID: <1382530928.74.0.685857253341.issue19362@psf.upfronthosting.co.za>


New submission from Gareth Rees:

The help text for the len() built-in function says:

    Return the number of items of a sequence or mapping.

This omits to mention that len() works on sets too. I suggest this be changed to:

    Return the number of items of a sequence, mapping, or set.

Similarly, the documentation for len() says:

    The argument may be a sequence (string, tuple or list) or a mapping (dictionary).

I suggest this be changed to

    The argument may be a sequence (string, tuple or list), a mapping (dictionary), or a set.

(Of course, strictly speaking, len() accepts any object with a __len__ method, but sequences, mappings and sets are the ones that are built-in to the Python core, and so these are the ones it is important to mention in the help and the documentation.)

----------
assignee: docs at python
components: Documentation
files: len-set.patch
keywords: patch
messages: 201019
nosy: Gareth.Rees, docs at python
priority: normal
severity: normal
status: open
title: Documentation for len() fails to mention that it works on sets
type: enhancement
Added file: http://bugs.python.org/file32313/len-set.patch

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

From report at bugs.python.org  Wed Oct 23 15:16:29 2013
From: report at bugs.python.org (Gareth Rees)
Date: Wed, 23 Oct 2013 13:16:29 +0000
Subject: [New-bugs-announce] [issue19363] Python 2.7's future_builtins.map
	is not compatible with	Python 3's map
Message-ID: <1382534189.14.0.63787411181.issue19363@psf.upfronthosting.co.za>


New submission from Gareth Rees:

In Python 2.7, future_builtins.map accepts None as its first (function) argument:

    Python 2.7.5 (default, Aug  1 2013, 01:01:17) 
    >>> from future_builtins import map
    >>> list(map(None, range(3), 'ABC'))
    [(0, 'A'), (1, 'B'), (2, 'C')]

But in Python 3.x, map does not accept None as its first argument:

    Python 3.3.2 (default, May 21 2013, 11:50:47) 
    >>> list(map(None, range(3), 'ABC'))
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: 'NoneType' object is not callable

The documentation says, "if you want to write code compatible with Python 3 builtins, import them from this module," so this incompatibility may give Python 2.7 programmers the false impression that a program which uses map(None, ...) is portable to Python 3.

I suggest that future_builtins.map in Python 2.7 should behave the same as map in Python 3: that is, it should raise a TypeError if None was passed as the first argument.

----------
components: Library (Lib)
messages: 201020
nosy: Gareth.Rees
priority: normal
severity: normal
status: open
title: Python 2.7's future_builtins.map is not compatible with Python 3's map
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Oct 23 15:49:43 2013
From: report at bugs.python.org (Kassym Dorsel)
Date: Wed, 23 Oct 2013 13:49:43 +0000
Subject: [New-bugs-announce] [issue19364] Implementing __getattr__ breaks
	copy and deepcopy
Message-ID: <1382536183.12.0.651276140754.issue19364@psf.upfronthosting.co.za>


New submission from Kassym Dorsel:

When __getattr__ is implemented without also implementing __copy__ and __deepcopy__ trying to (deep)copy the class fails.

>>> import copy
>>> class foo():
...   def __getattr__(self, attr):
...     return None
...
>>> f = foo()
>>> copy(f)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'module' object is not callable

The copy module checks if a class has implemented __copy__ using hasattr:

if hasattr(x, '__copy__'):
  ...

An easy fix would be to use:

if getattr(x, '__copy__', None):
  ...

In Python 3 this change has already been made.

----------
components: Library (Lib)
messages: 201024
nosy: Kassym.Dorsel, alexandre.vassalotti
priority: normal
severity: normal
status: open
title: Implementing __getattr__ breaks copy and deepcopy
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Oct 23 16:36:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 23 Oct 2013 14:36:02 +0000
Subject: [New-bugs-announce] [issue19365] Quadratic complexity in the
	parsing of re replacement	string
Message-ID: <1382538962.45.0.421817949827.issue19365@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

sre_parse.parse_template uses string concatenation to accumulate characters.

    def literal(literal, p=p, pappend=a):
        if p and p[-1][0] is LITERAL:
            p[-1] = LITERAL, p[-1][1] + literal
        else:
            pappend((LITERAL, literal))

This operation have quadratic calculation complexity for long replacement strings.

$ ./python -m timeit -n1 -r1 -s "from sre_parse import parse_template; repl = 'x'*100000"  "parse_template(repl, '')"
1 loops, best of 1: 3.38 sec per loop
$ ./python -m timeit -n1 -r1 -s "from sre_parse import parse_template; repl = 'x'*200000"  "parse_template(repl, '')"
1 loops, best of 1: 18.2 sec per loop

The proposed patch change amortized complexity to be linear. It also speeds up parsing shorter strings.

$ ./python -m timeit -n1 -r1 -s "from sre_parse import parse_template; repl = 'x'*100000"  "parse_template(repl, '')"
1 loops, best of 1: 915 msec per loop
$ ./python -m timeit -n1 -r1 -s "from sre_parse import parse_template; repl = 'x'*200000"  "parse_template(repl, '')"
1 loops, best of 1: 1.79 sec per loop

----------
components: Library (Lib), Regular Expressions
files: re_parse_template.patch
keywords: patch
messages: 201032
nosy: ezio.melotti, mrabarnett, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Quadratic complexity in the parsing of re replacement string
type: performance
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32315/re_parse_template.patch

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

From report at bugs.python.org  Wed Oct 23 18:29:22 2013
From: report at bugs.python.org (George King)
Date: Wed, 23 Oct 2013 16:29:22 +0000
Subject: [New-bugs-announce] [issue19366] Segfault in REPL due to escaped
	tab.
Message-ID: <1382545762.91.0.129230016295.issue19366@psf.upfronthosting.co.za>


New submission from George King:

I can crash python2.7.5 python3.3.2 from the REPL consistently:

$ python3
Python 3.3.2 (v3.3.2:d047928ae3f6, May 13 2013, 13:52:24) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> s = '\\t'
>>> s
Segmentation fault: 11
$ 

the same goes for:
Python 2.7.5 (v2.7.5:ab05e7dd2788, May 13 2013, 13:18:45) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin

both of these python builds are the mac binaries from python.org.

----------
components: Interpreter Core
messages: 201037
nosy: George.King
priority: normal
severity: normal
status: open
title: Segfault in REPL due to escaped tab.
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Wed Oct 23 19:35:43 2013
From: report at bugs.python.org (MrE Merry)
Date: Wed, 23 Oct 2013 17:35:43 +0000
Subject: [New-bugs-announce] [issue19367] IDLE wont open
Message-ID: <1382549743.62.0.543177432072.issue19367@psf.upfronthosting.co.za>


New submission from MrE Merry:

Python IDLE won't open - just get firewall error message, yet no firewalls are present.  Tried both on school laptop (I'm a teacher) and pupil work station (logged on as myself).  Students are able to open IDLE without issues.

----------
components: IDLE
files: Error.gif
messages: 201051
nosy: MrE.Merry
priority: normal
severity: normal
status: open
title: IDLE wont open
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file32316/Error.gif

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

From report at bugs.python.org  Wed Oct 23 21:36:51 2013
From: report at bugs.python.org (Matt Dodge)
Date: Wed, 23 Oct 2013 19:36:51 +0000
Subject: [New-bugs-announce] [issue19368] Seg Fault after upgrading to OS X
	Mavericks
Message-ID: <1382557011.89.0.0764735802945.issue19368@psf.upfronthosting.co.za>


New submission from Matt Dodge:

Upgraded to OS X Mavericks (not sure if this is what caused it or not).

Running Python 2.7.5 (v2.7.5:ab05e7dd2788, May 13 2013, 13:18:45)

Python will seg fault when trying to evaluate the expression bool('False')

To reproduce, from terminal, launch Python, enter "bool('False')" without quotes and press enter.

----------
assignee: ronaldoussoren
components: Macintosh
files: debug.out
messages: 201059
nosy: Matt.Dodge, ronaldoussoren
priority: normal
severity: normal
status: open
title: Seg Fault after upgrading to OS X Mavericks
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file32317/debug.out

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

From report at bugs.python.org  Wed Oct 23 21:38:27 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Oct 2013 19:38:27 +0000
Subject: [New-bugs-announce] [issue19369] PyObject_LengthHint is slow
Message-ID: <1382557107.61.0.118222715036.issue19369@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

PyObject_LengthHint is in the critical patch for many operations (such as list constructor, or list.extend), but it's quite unoptimized.

----------
components: Interpreter Core
messages: 201060
nosy: benjamin.peterson, pitrou, rhettinger
priority: normal
severity: normal
status: open
title: PyObject_LengthHint is slow
type: performance
versions: Python 3.4

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

From report at bugs.python.org  Wed Oct 23 23:45:49 2013
From: report at bugs.python.org (Henry Corrigan-Gibbs)
Date: Wed, 23 Oct 2013 21:45:49 +0000
Subject: [New-bugs-announce] [issue19370] Entering integers in python
	interpreter causes segfault
Message-ID: <1382564749.14.0.874044280359.issue19370@psf.upfronthosting.co.za>


New submission from Henry Corrigan-Gibbs:

Since upgrading to Mac OS X 10.9 (13A603), the interactive python interpreter crashes after I enter two lines of code, no matter how simple they are. The trace below shows that the shell segfaults after entering the integer "1" followed by the integer "1" (on separate lines).

The computer is a Macbook Pro, but I was able to reproduce the bug on a Macbook Air as well.

#########
### Trace of session
###

$ python
Python 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011, 15:22:34) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 1
1
>>> 1
Segmentation fault: 11


#########
### Apple crash report data
###

Process:         Python [1664]
Path:            /Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
Identifier:      Python
Version:         2.7.2 (2.7.2)
Code Type:       X86-64 (Native)
Parent Process:  bash [1661]
Responsible:     Terminal [1658]
User ID:         501

Date/Time:       2013-10-23 14:38:46.854 -0700
OS Version:      Mac OS X 10.9 (13A603)
Report Version:  11
Anonymous UUID:  7AFE5583-559F-1AF6-8F53-1AB95063B98E

Sleep/Wake UUID: 0112A8E8-BB6F-4797-A38D-DA6F40F06329

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000

VM Regions Near 0:
--> 
    __TEXT                 0000000100000000-0000000100001000 [    4K] r-x/rwx SM=COW  /Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   readline.so                   	0x00000001002edf97 call_readline + 647
1   org.python.python             	0x0000000100008ad2 PyOS_Readline + 274
2   org.python.python             	0x000000010000a328 tok_nextc + 104
3   org.python.python             	0x000000010000aad3 PyTokenizer_Get + 147
4   org.python.python             	0x00000001000056ca parsetok + 218
5   org.python.python             	0x00000001000e63b2 PyParser_ASTFromFile + 146
6   org.python.python             	0x00000001000e7613 PyRun_InteractiveOneFlags + 243
7   org.python.python             	0x00000001000e78fe PyRun_InteractiveLoopFlags + 78
8   org.python.python             	0x00000001000e80e1 PyRun_AnyFileExFlags + 161
9   org.python.python             	0x00000001000fe77c Py_Main + 2940
10  org.python.python             	0x0000000100000f14 0x100000000 + 3860

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000  rbx: 0x000000010035c140  rcx: 0x00000000000fc080  rdx: 0x0000000000087db0
  rdi: 0x0000000000000000  rsi: 0x00000001002ee254  rbp: 0x00007fff5fbff660  rsp: 0x00007fff5fbff590
   r8: 0x000000010035e700   r9: 0x000000010035e750  r10: 0x000000003500e0a1  r11: 0x0000000000000001
  r12: 0x0000000000000001  r13: 0x0000000000000001  r14: 0x00007fff5fbff620  r15: 0x00007fff5fbff5a0
  rip: 0x00000001002edf97  rfl: 0x0000000000010202  cr2: 0x0000000000000000
  
Logical CPU:     1
Error Code:      0x00000004
Trap Number:     14


Binary Images:
       0x100000000 -        0x100000fff +org.python.python (2.7.2 - 2.7.2) <639E72E4-F205-C034-8E34-E59DE9C46369> /Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
       0x100003000 -        0x10016cfef +org.python.python (2.7.2, [c] 2004-2011 Python Software Foundation. - 2.7.2) <49D18B1A-C92D-E32E-A7C1-086D0B14BD76> /Library/Frameworks/Python.framework/Versions/2.7/Python
       0x1002ec000 -        0x1002eefff +readline.so (???) <25AB2CA6-C3CC-9F24-F619-C85D51AD8A38> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/readline.so
       0x1004b0000 -        0x1004ceffb  libedit.2.dylib (39) <1B0596DB-F336-32E7-BB9F-51BF70DB5305> /usr/lib/libedit.2.dylib
    0x7fff6cc9f000 -     0x7fff6ccd2817  dyld (239.3) <D1DFCF3F-0B0C-332A-BCC0-87A851B570FF> /usr/lib/dyld
    0x7fff885e1000 -     0x7fff8860aff7  libc++abi.dylib (48) <8C16158F-CBF8-3BD7-BEF4-022704B2A326> /usr/lib/libc++abi.dylib
    0x7fff8860b000 -     0x7fff88659fff  libcorecrypto.dylib (161.1) <F3973C28-14B6-3006-BB2B-00DD7F09ABC7> /usr/lib/system/libcorecrypto.dylib
    0x7fff88d06000 -     0x7fff88d17ff7  libz.1.dylib (53) <42E0C8C6-CA38-3CA4-8619-D24ED5DD492E> /usr/lib/libz.1.dylib
    0x7fff88d6e000 -     0x7fff88d77ff3  libsystem_notify.dylib (121) <52571EC3-6894-37E4-946E-064B021ED44E> /usr/lib/system/libsystem_notify.dylib
    0x7fff896da000 -     0x7fff896dbff7  libDiagnosticMessagesClient.dylib (100) <4CDB0F7B-C0AF-3424-BC39-495696F0DB1E> /usr/lib/libDiagnosticMessagesClient.dylib
    0x7fff89a9b000 -     0x7fff89a9eff7  libdyld.dylib (239.3) <62F4D752-4089-31A8-8B73-B95A68893B3C> /usr/lib/system/libdyld.dylib
    0x7fff8a059000 -     0x7fff8a05dfff  libsystem_stats.dylib (93.1.26) <B9E26A9E-FBBC-3938-B8B7-6CF7CA8C99AD> /usr/lib/system/libsystem_stats.dylib
    0x7fff8a181000 -     0x7fff8a1a5fff  libxpc.dylib (300.1.17) <4554927A-9467-365C-91F1-5A116989DD7F> /usr/lib/system/libxpc.dylib
    0x7fff8a291000 -     0x7fff8a2c1fff  libncurses.5.4.dylib (42) <BF763D62-9149-37CB-B1D2-F66A2510E6DD> /usr/lib/libncurses.5.4.dylib
    0x7fff8ae52000 -     0x7fff8ae54ff3  libsystem_configuration.dylib (596.12) <C4F633D9-94C8-35D9-BB2D-84C5122533C7> /usr/lib/system/libsystem_configuration.dylib
    0x7fff8aeca000 -     0x7fff8aed0ff7  libsystem_platform.dylib (24.1.4) <331BA4A5-55CE-3B95-99EB-44E0C89D7FB8> /usr/lib/system/libsystem_platform.dylib
    0x7fff8b0a4000 -     0x7fff8b0a4ff7  libkeymgr.dylib (28) <3AA8D85D-CF00-3BD3-A5A0-E28E1A32A6D8> /usr/lib/system/libkeymgr.dylib
    0x7fff8b7ee000 -     0x7fff8b7ffff7  libsystem_asl.dylib (217.1.4) <655FB343-52CF-3E2F-B14D-BEBF5AAEF94D> /usr/lib/system/libsystem_asl.dylib
    0x7fff8b800000 -     0x7fff8b81cff7  libsystem_kernel.dylib (2422.1.72) <D14913DB-47F1-3591-8DAF-D4B4EF5F8818> /usr/lib/system/libsystem_kernel.dylib
    0x7fff8b81d000 -     0x7fff8b84cfd2  libsystem_m.dylib (3047.16) <B7F0E2E4-2777-33FC-A787-D6430B630D54> /usr/lib/system/libsystem_m.dylib
    0x7fff8b852000 -     0x7fff8b853ffb  libremovefile.dylib (33) <3543F917-928E-3DB2-A2F4-7AB73B4970EF> /usr/lib/system/libremovefile.dylib
    0x7fff8bad5000 -     0x7fff8baf0ff7  libsystem_malloc.dylib (23.1.10) <FFE5C472-B23A-318A-85BF-77CDE61900D1> /usr/lib/system/libsystem_malloc.dylib
    0x7fff8bc58000 -     0x7fff8bc59ff7  libsystem_sandbox.dylib (278.10) <A47E7E11-3C76-318E-B67D-98972B86F094> /usr/lib/system/libsystem_sandbox.dylib
    0x7fff8bc8c000 -     0x7fff8bc96fff  libcommonCrypto.dylib (60049) <8C4F0CA0-389C-3EDC-B155-E62DD2187E1D> /usr/lib/system/libcommonCrypto.dylib
    0x7fff8c2ae000 -     0x7fff8c2afff7  libSystem.B.dylib (1197.1.1) <BFC0DC97-46C6-3BE0-9983-54A98734897A> /usr/lib/libSystem.B.dylib
    0x7fff8cf18000 -     0x7fff8cf3fffb  libsystem_info.dylib (449.1.3) <7D41A156-D285-3849-A2C3-C04ADE797D98> /usr/lib/system/libsystem_info.dylib
    0x7fff8d07f000 -     0x7fff8d264ff7  com.apple.CoreFoundation (6.9 - 855.11) <E22C6A1F-8996-349C-905E-96C3BBE07C2F> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fff8df72000 -     0x7fff8df79fff  libcompiler_rt.dylib (35) <4CD916B2-1B17-362A-B403-EF24A1DAC141> /usr/lib/system/libcompiler_rt.dylib
    0x7fff8e4fe000 -     0x7fff8e4ffff7  libsystem_blocks.dylib (63) <FB856CD1-2AEA-3907-8E9B-1E54B6827F82> /usr/lib/system/libsystem_blocks.dylib
    0x7fff8e530000 -     0x7fff8e535fff  libmacho.dylib (845) <1D2910DF-C036-3A82-A3FD-44FF73B5FF9B> /usr/lib/system/libmacho.dylib
    0x7fff8ea55000 -     0x7fff8ea5dfff  libsystem_dnssd.dylib (522.1.11) <270DCF6C-502D-389A-AA9F-DE4624A36FF7> /usr/lib/system/libsystem_dnssd.dylib
    0x7fff8eaca000 -     0x7fff8ead1ff7  liblaunch.dylib (842.1.4) <FCBF0A02-0B06-3F97-9248-5062A9DEB32C> /usr/lib/system/liblaunch.dylib
    0x7fff8ecc0000 -     0x7fff8ecc7ff3  libcopyfile.dylib (103) <5A881779-D0D6-3029-B371-E3021C2DDA5E> /usr/lib/system/libcopyfile.dylib
    0x7fff8f632000 -     0x7fff8f684fff  libc++.1.dylib (120) <4F68DFC5-2077-39A8-A449-CAC5FDEE7BDE> /usr/lib/libc++.1.dylib
    0x7fff8f719000 -     0x7fff8f7a2ff7  libsystem_c.dylib (997.1.1) <61833FAA-7281-3FF9-937F-686B6F20427C> /usr/lib/system/libsystem_c.dylib
    0x7fff90489000 -     0x7fff90636f27  libobjc.A.dylib (551.1) <AD7FD984-271E-30F4-A361-6B20319EC73B> /usr/lib/libobjc.A.dylib
    0x7fff9063d000 -     0x7fff90642ff7  libunwind.dylib (35.3) <78DCC358-2FC1-302E-B395-0155B47CB547> /usr/lib/system/libunwind.dylib
    0x7fff90e17000 -     0x7fff90fcfff3  libicucore.A.dylib (511.25) <3ED7B656-416E-3071-AEC8-E85C90232F78> /usr/lib/libicucore.A.dylib
    0x7fff92bbc000 -     0x7fff92bc0ff7  libcache.dylib (62) <BDC1E65B-72A1-3DA3-A57C-B23159CAAD0B> /usr/lib/system/libcache.dylib
    0x7fff92e8e000 -     0x7fff92e90ff7  libquarantine.dylib (71) <7A1A2BCB-C03D-3A25-BFA4-3E569B2D2C38> /usr/lib/system/libquarantine.dylib
    0x7fff93b1f000 -     0x7fff93b20fff  libunc.dylib (28) <62682455-1862-36FE-8A04-7A6B91256438> /usr/lib/system/libunc.dylib
    0x7fff9406b000 -     0x7fff94072ff7  libsystem_pthread.dylib (53.1.4) <AB498556-B555-310E-9041-F67EC9E00E2C> /usr/lib/system/libsystem_pthread.dylib
    0x7fff94257000 -     0x7fff9427eff7  libsystem_network.dylib (241.3) <8B1E1F1D-A5CC-3BAE-8B1E-ABC84337A364> /usr/lib/system/libsystem_network.dylib
    0x7fff944b7000 -     0x7fff944f9ff7  libauto.dylib (185.5) <F45C36E8-B606-3886-B5B1-B6745E757CA8> /usr/lib/libauto.dylib
    0x7fff94cd8000 -     0x7fff94cf2fff  libdispatch.dylib (339.1.9) <46878A5B-4248-3057-962C-6D4A235EEF31> /usr/lib/system/libdispatch.dylib

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 8241
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=76.3M resident=13.9M(18%) swapped_out_or_unallocated=62.4M(82%)
Writable regions: Total=27.7M written=1864K(7%) resident=2436K(9%) swapped_out=0K(0%) unallocated=25.3M(91%)
 
REGION TYPE                      VIRTUAL
===========                      =======
Kernel Alloc Once                     4K
MALLOC                             19.4M
MALLOC (admin)                       16K
STACK GUARD                        56.0M
Stack                              8192K
VM_ALLOCATE                           8K
__DATA                             1412K
__LINKEDIT                         65.9M
__TEXT                             10.4M
__UNICODE                           544K
shared memory                         4K
===========                      =======
TOTAL                             161.7M

Model: MacBookPro5,5, BootROM MBP55.00AC.B03, 2 processors, Intel Core 2 Duo, 2.53 GHz, 4 GB, SMC 1.47f2
Graphics: NVIDIA GeForce 9400M, NVIDIA GeForce 9400M, PCI, 256 MB
Memory Module: BANK 0/DIMM0, 2 GB, DDR3, 1067 MHz, 0x802C, 0x31364A53463235363634485A2D3147314631
Memory Module: BANK 1/DIMM0, 2 GB, DDR3, 1067 MHz, 0x802C, 0x31364A53463235363634485A2D3147314631
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x8D), Broadcom BCM43xx 1.0 (5.106.98.100.22)
Bluetooth: Version 4.2.0f6 12982, 3 services, 15 devices, 1 incoming serial ports
Network Service: AirPort, AirPort, en1
Serial ATA Device: FUJITSU MJA2500BH FFS G1, 500.11 GB
Serial ATA Device: HL-DT-ST DVDRW  GS23N
USB Device: Built-in iSight
USB Device: Internal Memory Card Reader
USB Device: Apple Internal Keyboard / Trackpad
USB Device: IR Receiver
USB Device: BRCM2046 Hub
USB Device: Bluetooth USB Host Controller
Thunderbolt Bus:

----------
assignee: ronaldoussoren
components: Interpreter Core, Macintosh
messages: 201072
nosy: henrycg at stanford.edu, ronaldoussoren
priority: normal
severity: normal
status: open
title: Entering integers in python interpreter causes segfault
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct 24 00:20:01 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Oct 2013 22:20:01 +0000
Subject: [New-bugs-announce] [issue19371] timing test too tight
Message-ID: <1382566801.77.0.760747140726.issue19371@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Looks like test_asyncio still has rather tight timing expectations:

http://buildbot.python.org/all/builders/x86%20Windows%20Server%202008%20%5BSB%5D%203.x/builds/1495/steps/test/logs/stdio

======================================================================
FAIL: test__run_once (test.test_asyncio.test_base_events.BaseEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\home\cpython\buildslave\x86\3.x.snakebite-win2k8r2sp1-x86\build\lib\test\test_asyncio\test_base_events.py", line 182, in test__run_once
    self.assertTrue(9.99 < t < 10.1, t)
AssertionError: False is not true : 9.98499999998603

----------
components: Library (Lib), Tests
messages: 201077
nosy: pitrou
priority: normal
severity: normal
status: open
title: timing test too tight
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Oct 24 05:34:09 2013
From: report at bugs.python.org (Daniel)
Date: Thu, 24 Oct 2013 03:34:09 +0000
Subject: [New-bugs-announce] [issue19372] getaddrinfo() bug
Message-ID: <1382585649.75.0.66347191102.issue19372@psf.upfronthosting.co.za>


New submission from Daniel:

I have two systems, one is CentOS 5.9 with kernel 2.6.18-348, 
the other is CentOS 6.4 with kernel 2.6.32-358. 
Python ver is 2.7.5. 
both configure ok if no other option give, 
But if I want configure with --enable-shared, CentOS 6.4 get a 
You must get working getaddrinfo() function.
       or you can specify "--disable-ipv6".

while the other system 5.9 is ok.

I try to use --disable-ipv6, then it configure ok, but make
got a lot of error , such as must define PY_FORMAT_LONG_LONG 
int pyconfig.h .

----------
components: Build
messages: 201088
nosy: Daniel
priority: normal
severity: normal
status: open
title: getaddrinfo() bug
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct 24 08:32:31 2013
From: report at bugs.python.org (Ned Deily)
Date: Thu, 24 Oct 2013 06:32:31 +0000
Subject: [New-bugs-announce] [issue19373] Tkinter apps including IDLE may
	not display properly on	OS X 10.9 Mavericks
Message-ID: <1382596351.85.0.389017245767.issue19373@psf.upfronthosting.co.za>


New submission from Ned Deily:

On OS X 10.9 Mavericks, there is a problem with Aqua Cocoa Tk 8.5 (8.5.15 or earlier) when run in 64-bit mode, the default for most applications.  The symptoms are that Tk widgets may not be properly drawn or updated on the screen unless some HID activity takes place, like mousing over the widget or by entering text via the keyboard.  Since the problem can also be reproduced using the Tk wish shell, it is not a Python problem but it can have an impact on Tkinter-based applications, like IDLE.  The problem is being tracked by the Tk project here:

https://core.tcl.tk/tk/tktview?name=53f7a1b553

The problem affects current and recent third-party Tk 8.5.x releases, such as the ActiveTcl 8.5.15 recommended for use with current python.org 3.3.2 and 2.7.5 installers. It also affects the Built-in 8.5.x Tcl/Tk included with pre-release python.org 3.4.x installers.  It appears that the problem does not affect the Apple Tk 8.5.9 shipped with OS X 10.9, which is used by the system Pythons included in OS X 10.9.  However, as in recent previous OS X releases, the Apple 8.5.9 Tk has serious problems so its use is not recommended: see http://www.python.org/download/mac/tcltk/ for more information.

This issue will be updated as solutions become available.  In the meantime, there are some workarounds:

1. Run Tkinter applications in 32-bit mode.  If you are using Python 2.7.x, 3.2.x, 3.3.x, or 3.4.x from one of the python.org "Mac OS X 64-bit/32-bit x86-64/i386 Installers", the easiest way to do this is to append "-32" to the python command name:

/usr/local/bin/python3.4   ->  /usr/local/bin/python3.4-32
/usr/local/bin/python3.3   ->  /usr/local/bin/python3.3-32
/usr/local/bin/python2.7   ->  /usr/local/bin/python2.7-32

If you are using a Python from a python.org "Mac OS X 32-bit i386/PPC Installer", you will not see this problem; but keep in mind that those Pythons are linked with Tcl/Tk 8.4 for compatibility with older OS X releases.

2. If you launch IDLE from a 64-bit-capable installation by double-clicking on its icon in the 10.9 Finder, you may see this problem. (Due to a quirk, IDLE 2.7 launched this way may not be affected.)  You can force IDLE 3.x to run in 32-bit mode by launching it from a Terminal window instead of double-clicking.  For Python 3.x, try

/usr/local/bin/python3.3-32 -m idlelib

/usr/local/bin/python3.4-32 -m idlelib

For Python 2.7.x, if you need to launch from the command line rather than double-clicking, try:

/usr/local/bin/python2.7-32 /usr/local/bin/idle2.7

----------
assignee: ned.deily
components: IDLE, Macintosh, Tkinter
messages: 201093
nosy: ned.deily
priority: normal
severity: normal
status: open
title: Tkinter apps including IDLE may not display properly on OS X 10.9 Mavericks
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Oct 24 09:01:40 2013
From: report at bugs.python.org (Bugra Cakir)
Date: Thu, 24 Oct 2013 07:01:40 +0000
Subject: [New-bugs-announce] [issue19374] Segmentation fault: 11 with
	String.split
Message-ID: <1382598100.42.0.343975997852.issue19374@psf.upfronthosting.co.za>


New submission from Bugra Cakir:

Can be reproduced on Mac OS X. Stock Python 2.7.5 setup has been installed on a Mac OS X.

Python 2.7.5 (v2.7.5:ab05e7dd2788, May 13 2013, 13:18:45)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> s = "$RMC;12;234;523"
>>> s.split("$")

Segmentation fault: 11

----------
components: Interpreter Core
files: segfault11.rtf
messages: 201094
nosy: xentnex
priority: normal
severity: normal
status: open
title: Segmentation fault: 11 with String.split
versions: Python 2.7
Added file: http://bugs.python.org/file32325/segfault11.rtf

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

From report at bugs.python.org  Thu Oct 24 11:11:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Oct 2013 09:11:11 +0000
Subject: [New-bugs-announce] [issue19375] Deprecate site-python in site.py
Message-ID: <1382605871.26.0.0916867662711.issue19375@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

I suggest deprecating the "site-python" feature from site.py, as proposed by Guido on python-dev:
https://mail.python.org/pipermail/python-dev/2013-October/129820.html

- if a "site-python" directory is detected and added from site.py, a DeprecationWarning should be emitted
- the site.py docs should mention the deprecation

----------
components: Library (Lib)
messages: 201103
nosy: christian.heimes, loewis, pitrou
priority: normal
severity: normal
status: open
title: Deprecate site-python in site.py
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Oct 24 12:02:17 2013
From: report at bugs.python.org (Matthew Earl)
Date: Thu, 24 Oct 2013 10:02:17 +0000
Subject: [New-bugs-announce] [issue19376] datetime.datetime.strptime without
	a year fails on Feb 29
Message-ID: <1382608937.44.0.992947795428.issue19376@psf.upfronthosting.co.za>


New submission from Matthew Earl:

datetime.datetime.strptime() without a year fails on Feb 29 with:

>>> datetime.datetime.strptime("Feb 29", "%b %d")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/auto/ensoft-sjc/thirdparty/lib/python3.3/_strptime.py", line 511, in _strptime_datetime
    return cls(*args)
ValueError: day is out of range for month

This is because without a year specified the year is assumed to be 1900, which is not a leap year. The underlying _strptime._strptime() function has some munging such that it doesn't itself fail (see #14157):

>>> _strptime._strptime("Feb 29", "%b %d")
((1900, 2, 29, 0, 0, 0, 0, 60, -1, None, None), 0)

...however datetime.datetime.__init__() is called with this tuple as *args, causing the validation failure.

----------
components: Library (Lib)
messages: 201108
nosy: Arfrever, Martin.Morrison, Matthew.Earl, belopolsky, haypo, hynek, pconnell, pitrou, swalker
priority: normal
severity: normal
status: open
title: datetime.datetime.strptime without a year fails on Feb 29
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Oct 24 15:44:11 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 24 Oct 2013 13:44:11 +0000
Subject: [New-bugs-announce] [issue19377] Backport SVG mime type to Python 2
Message-ID: <1382622251.64.0.363936372729.issue19377@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

A request to backport issue10730 commit to Python 2.x
Why? Google Client API uses mimetype module to detect file types when uploading to Google Drive, and because SVG is missing, it can not be edited after uploading.

----------
components: Library (Lib)
messages: 201130
nosy: techtonik
priority: normal
severity: normal
status: open
title: Backport SVG mime type to Python 2
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Thu Oct 24 15:44:36 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 24 Oct 2013 13:44:36 +0000
Subject: [New-bugs-announce] [issue19378] Rename "line_offset" parameter in
	dis.get_instructions	to "first_line"
Message-ID: <1382622276.63.0.652986128148.issue19378@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

The "line_offset" parameter in dis.get_instructions is the line number of the first line in the source file: http://docs.python.org/dev/library/dis#dis.get_instructions

Calling this an offset is a little confusing, since "offset" in the dis docs almost always refers to an instruction offset. Issue 17916 is likely to make this worse, since that will probably involve new "last_offset" and "current_offset" parameters to other APIs.

Renaming the parameter to "first_line" (since it sets the line number reported for the first line in the code object when iterating) should help make this less confusing.

----------
messages: 201131
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Rename "line_offset" parameter in dis.get_instructions to "first_line"

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

From report at bugs.python.org  Thu Oct 24 22:09:10 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Oct 2013 20:09:10 +0000
Subject: [New-bugs-announce] [issue19379] Don't import linecache at warnings
	toplevel
Message-ID: <1382645350.53.0.967299758483.issue19379@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Importing warnings pulls linecache at the top-level, while it's only necessary when printing warnings. The reason why it wasn't done lazily is obsolete, since Python now has per-module import locks. Attached patch makes the linecache imports lazy.

This is desirable for issue #19375.

----------
components: Library (Lib)
files: warnings_lazy.patch
keywords: patch
messages: 201174
nosy: brett.cannon, christian.heimes, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Don't import linecache at warnings toplevel
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file32340/warnings_lazy.patch

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

From report at bugs.python.org  Thu Oct 24 22:14:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 24 Oct 2013 20:14:19 +0000
Subject: [New-bugs-announce] [issue19380] Optimize parsing of regular
	expressions
Message-ID: <1382645659.73.0.868235602026.issue19380@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch optimizes parsing of regular expressions. Total time of re unittests decreased by 10%.

----------
assignee: serhiy.storchaka
components: Library (Lib), Regular Expressions
files: re_parse.patch
keywords: patch
messages: 201177
nosy: ezio.melotti, mrabarnett, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Optimize parsing of regular expressions
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file32341/re_parse.patch

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

From report at bugs.python.org  Thu Oct 24 23:17:22 2013
From: report at bugs.python.org (Manish Raghavan)
Date: Thu, 24 Oct 2013 21:17:22 +0000
Subject: [New-bugs-announce] [issue19381] Seg Fault with complex numbers
Message-ID: <1382649442.62.0.379719453472.issue19381@psf.upfronthosting.co.za>


New submission from Manish Raghavan:

Python 3.3.2 (v3.3.2:d047928ae3f6, May 13 2013, 13:52:24)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 1+1j
(1+1j)
>>> 1+1j
Segmentation fault: 11

----------
assignee: ronaldoussoren
components: Macintosh
messages: 201190
nosy: Manish.Raghavan, ronaldoussoren
priority: normal
severity: normal
status: open
title: Seg Fault with complex numbers
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Fri Oct 25 00:58:45 2013
From: report at bugs.python.org (Colin Williams)
Date: Thu, 24 Oct 2013 22:58:45 +0000
Subject: [New-bugs-announce] [issue19382] tabnanny unit tests
Message-ID: <1382655525.74.0.119259261788.issue19382@psf.upfronthosting.co.za>


New submission from Colin Williams:

I didn't test the stdout and stderr stuff, but I got the module up to 74% coverage.

----------
files: tabnanny.patch
keywords: patch
messages: 201194
nosy: Colin.Williams
priority: normal
severity: normal
status: open
title: tabnanny unit tests
Added file: http://bugs.python.org/file32344/tabnanny.patch

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

From report at bugs.python.org  Fri Oct 25 01:33:34 2013
From: report at bugs.python.org (Colin Williams)
Date: Thu, 24 Oct 2013 23:33:34 +0000
Subject: [New-bugs-announce] [issue19383] nturl2path test coverage
Message-ID: <1382657614.74.0.213729784079.issue19383@psf.upfronthosting.co.za>


New submission from Colin Williams:

Full coverage on this module

----------
files: nturl2path.patch
keywords: patch
messages: 201197
nosy: Colin.Williams
priority: normal
severity: normal
status: open
title: nturl2path test coverage
Added file: http://bugs.python.org/file32345/nturl2path.patch

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

From report at bugs.python.org  Fri Oct 25 07:33:48 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Fri, 25 Oct 2013 05:33:48 +0000
Subject: [New-bugs-announce] [issue19384] test_py_compile fails with OSError
	on FreeBSD for root	user
Message-ID: <1382679228.36.0.603807320652.issue19384@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

The actual error:

======================================================================
FAIL: test_exceptions_propagate (test.test_py_compile.PyCompileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tank/libs/cpython/Lib/test/test_py_compile.py", line 88, in test_exceptions_propagate
    py_compile.compile(self.source_path, self.pyc_path)
AssertionError: OSError not raised

----------------------------------------------------------------------
Ran 7 tests in 0.007s

FAILED (failures=1)
test test_py_compile failed
1 test failed:
    test_py_compile

os.chmod(self.directory, stat.S_IREAD) doesn't do what it is expected on FreeBSD for root user, the attached patch skips this test if the current user is root.

----------
components: Tests
files: test_py_compile.patch
keywords: patch
messages: 201204
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: test_py_compile fails with OSError on FreeBSD for root user
versions: Python 3.4
Added file: http://bugs.python.org/file32346/test_py_compile.patch

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

From report at bugs.python.org  Fri Oct 25 08:38:41 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Fri, 25 Oct 2013 06:38:41 +0000
Subject: [New-bugs-announce] [issue19385] dbm.dumb should be consistent when
	the database is closed
Message-ID: <1382683121.03.0.174486602388.issue19385@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

This problem occurred in issue19282. Basicly, dbm.dumb is not consistent with dbm.gnu and dbm.ndbm when the database is closed, as seen in the following:


>>> import dbm.dumb as d
>>> db = d.open('test.dat', 'c')
>>> db.close()
>>> db.keys()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/tank/libs/cpython/Lib/dbm/dumb.py", line 212, in keys
    return list(self._index.keys())
AttributeError: 'NoneType' object has no attribute 'keys'
>>>

vs

>>> import dbm.gnu as g
>>> db = g.open('test.dat', 'c')
>>> db.close()
>>> db.keys()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
_gdbm.error: GDBM object has already been closed
>>>

Attaching a patch.

----------
components: Library (Lib)
messages: 201209
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: dbm.dumb should be consistent when the database is closed
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Oct 25 10:06:31 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 25 Oct 2013 08:06:31 +0000
Subject: [New-bugs-announce] [issue19386] selectors test_interrupted_retry
	is flaky
Message-ID: <1382688391.49.0.741915274953.issue19386@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The test seems to be unstable on some build bots:

http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/5271/steps/test/logs/stdio

======================================================================
FAIL: test_interrupted_retry (test.test_selectors.EpollSelectorTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/test_selectors.py", line 299, in test_interrupted_retry
    self.assertLess(time() - t, 2.5)
AssertionError: 105.86884237639606 not less than 2.5

----------------------------------------------------------------------
Ran 58 tests in 127.113s

----------
assignee: neologix
components: Tests
messages: 201225
nosy: christian.heimes, neologix
priority: normal
severity: normal
stage: needs patch
status: open
title: selectors test_interrupted_retry is flaky
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Oct 25 14:38:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Oct 2013 12:38:59 +0000
Subject: [New-bugs-announce] [issue19387] Explain and test the sre overlap
	table
Message-ID: <1382704739.58.0.812617552923.issue19387@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Since I had to understand this while reviewing code, here is a patch making things clearer.
(I tried to get the docstring right :-))

----------
components: Library (Lib), Tests
files: overlap.patch
keywords: patch
messages: 201232
nosy: pitrou, serhiy.storchaka, tim.peters
priority: low
severity: normal
stage: patch review
status: open
title: Explain and test the sre overlap table
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32350/overlap.patch

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

From report at bugs.python.org  Fri Oct 25 14:53:33 2013
From: report at bugs.python.org (Dustin Oprea)
Date: Fri, 25 Oct 2013 12:53:33 +0000
Subject: [New-bugs-announce] [issue19388] Inflated download counts
Message-ID: <1382705613.84.0.405953640561.issue19388@psf.upfronthosting.co.za>


New submission from Dustin Oprea:

Noah recommended that I approach the distutils mailing list to report a potential PyPI problem. I can't seem to find a webpage for the distutils list, so I'm posting an official bug.

I have a few packages on PyPI, and I often find my counts immediately taking hold, and, for the more useful projects, skyrocketing. However, I recently started a service that requires membership. In the last month, PyPI reports 3000 downloads of the client, yet Google Analytics only reports a handful of visits to the website. I have even less membership signups (as expected, so soon after launch). Why are the download counts so inflated? Obviously, they're very misleading and limited if they don't ignore spurious visitors (like robots).

What has to be done to get this to be accurate?

I've included two screenshots of PyPI and GA.

----------
assignee: eric.araujo
components: Distutils
messages: 201234
nosy: dsoprea, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Inflated download counts
type: enhancement
Added file: http://bugs.python.org/file32351/inflated_counts.zip

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

From report at bugs.python.org  Fri Oct 25 17:49:46 2013
From: report at bugs.python.org (Mathieu Virbel)
Date: Fri, 25 Oct 2013 15:49:46 +0000
Subject: [New-bugs-announce] [issue19389] find_file might return a different
	directory than the	tested file
Message-ID: <1382716186.29.0.0404891043563.issue19389@psf.upfronthosting.co.za>


New submission from Mathieu Virbel:

With Maverick OSX (latest version), there is no /usr/include/zlib.h anymore. If you try to compile Python with -sysroot, it trigger a error message:

error: /usr/include/zlib.h: No such file or directory

The issue is in setup.py, where find_file is checking the existence of a filename, but if the filename has been found in a sysroot, it will return the path _without_ the sysroot.

In this case (zlib), find_file correctly find the zlib.h in /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/usr/include/zlib.h, but return "/usr/include",  and then the setup.py open '/usr/include/zlib.h', which fail.

----------
components: Build
files: fix-setup-find-file-path.patch
keywords: patch
messages: 201245
nosy: Mathieu.Virbel
priority: normal
severity: normal
status: open
title: find_file might return a different directory than the tested file
type: behavior
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/file32352/fix-setup-find-file-path.patch

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

From report at bugs.python.org  Fri Oct 25 17:51:51 2013
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 25 Oct 2013 15:51:51 +0000
Subject: [New-bugs-announce] [issue19390] clinic.py: unhandled syntax error
Message-ID: <1382716311.99.0.339644055005.issue19390@psf.upfronthosting.co.za>


New submission from Stefan Krah:

The attached syntax error should probably be handled by clinic.py.

----------
components: Demos and Tools
files: syntax-err-1.patch
keywords: patch
messages: 201246
nosy: skrah
priority: normal
severity: normal
status: open
title: clinic.py: unhandled syntax error
versions: Python 3.4
Added file: http://bugs.python.org/file32353/syntax-err-1.patch

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

From report at bugs.python.org  Fri Oct 25 18:34:30 2013
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 25 Oct 2013 16:34:30 +0000
Subject: [New-bugs-announce] [issue19391] Fix PCbuild/readme.txt in 2.7 and
	3.3
Message-ID: <1382718870.17.0.951198917656.issue19391@psf.upfronthosting.co.za>


New submission from Zachary Ware:

As discussed in issue19273, here are a pair of patches that correct factual errors in PCbuild/readme.txt in both 2.7 and 3.3.

The 3.3 patch makes the following changes:
- Remove Win2k mentions, it is not supported (Tcl nmake command also adjusted)
- MSVCRT9 -> MSVCRT10
- SQLite 3.7.4 -> 3.7.12, remove "(see below)" with nothing to see
- .vcproj -> .vcxproj, all occurrences 
- _bz2.vcxproj isn't as magical as it was made out to be, and it can clean itself
- nasmw -> nasm
- Remove untrue part of Building for Itanium section
- Update msdn link
- .vsprops -> .props
- Trim trailing space

Due to the large number of lines in the diff due to trailing space, I'll also be attaching a patch created by `hg diff -w` for ease of review.

----------
assignee: docs at python
components: Documentation, Windows
files: pcbuild_readme-3.3.diff
keywords: patch
messages: 201253
nosy: brian.curtin, christian.heimes, docs at python, ezio.melotti, loewis, python-dev, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Fix PCbuild/readme.txt in 2.7 and 3.3
type: enhancement
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file32354/pcbuild_readme-3.3.diff

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

From report at bugs.python.org  Fri Oct 25 19:00:54 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 25 Oct 2013 17:00:54 +0000
Subject: [New-bugs-announce] [issue19392] document importlib.reload()
	requires __loader__ to be	defined
Message-ID: <1382720454.45.0.30306791962.issue19392@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Make sure importlib.reload() (and by extension imp.reload()) mention that __loader__ must be defined as well as __name__.

----------
assignee: docs at python
components: Documentation
messages: 201259
nosy: brett.cannon, docs at python
priority: normal
severity: normal
status: open
title: document importlib.reload() requires __loader__ to be defined
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Oct 25 19:49:56 2013
From: report at bugs.python.org (Steven Winfield)
Date: Fri, 25 Oct 2013 17:49:56 +0000
Subject: [New-bugs-announce] [issue19393] symtable.symtable can return the
	wrong "top" SymbolTable
Message-ID: <1382723396.02.0.356788344876.issue19393@psf.upfronthosting.co.za>


New submission from Steven Winfield:

The attached script creates calls symtable.symtable many times on a code snippet that contains a single class with a method called "top", and some other important (to trigger the behaviour) properties:
  * a class variable
  * at least three other methods

The symtable module is reloaded each time, which seems to exacerbate the problem, but it not necessary.

The return value of symtable.symtable is sometimes a SymbolTable object, as expected, and sometimes a symtable.Function object.

Here is some example output from the script:

c:\Python27>python.exe C:\Temp\symtable_weirdness.py
Counter({'SymbolTable': 59, 'Function': 41})

c:\Python33>python.exe C:\Temp\symtable_weirdness.py
Counter({'SymbolTable': 89, 'Function': 11})

The values are consistent between runs, but can be changed by altering PYTHONHASHSEED between runs.

----------
components: Library (Lib)
files: symtable_weirdness.py
messages: 201265
nosy: Steven.Winfield
priority: normal
severity: normal
status: open
title: symtable.symtable can return the wrong "top" SymbolTable
type: behavior
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file32359/symtable_weirdness.py

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

From report at bugs.python.org  Fri Oct 25 20:00:28 2013
From: report at bugs.python.org (robotron)
Date: Fri, 25 Oct 2013 18:00:28 +0000
Subject: [New-bugs-announce] [issue19394] distutils.core.Extension: empty
	strings in library_dirs	and include_dirs should not be allowed
Message-ID: <1382724028.67.0.461727040571.issue19394@psf.upfronthosting.co.za>


New submission from robotron:

When empty string element is passed in include_dirs or library_dirs (e.g. include_dirs = [""]) param of distutils.core.Extension constructor, it is propagated to compiler/linker params and in the case of gcc it eats subsequent command line option.

setup.py excerpt:

---
extensions = [
    Extension("test_extension", ["test_extension.cpp"],
        include_dirs = [""],
        libraries = ["rt"],
        library_dirs = [""],
        )
]
---

$ python setup.py build
...
gcc ... -I -I/usr/include/python2.7 -c test_extension.cpp ...

Standard include dir "/usr/include/python2.7" is ommited now. The same is valid for library_dirs.

Example scripts attached.

----------
assignee: eric.araujo
components: Distutils
files: bug_test_case.zip
messages: 201269
nosy: eric.araujo, robotron, tarek
priority: normal
severity: normal
status: open
title: distutils.core.Extension: empty strings in library_dirs and include_dirs should not be allowed
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file32361/bug_test_case.zip

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

From report at bugs.python.org  Fri Oct 25 21:20:43 2013
From: report at bugs.python.org (cantor)
Date: Fri, 25 Oct 2013 19:20:43 +0000
Subject: [New-bugs-announce] [issue19395] lzma hangs for a very long time
	when run in parallel	using python's muptiprocessing module?
Message-ID: <1382728843.86.0.270938771254.issue19395@psf.upfronthosting.co.za>


New submission from cantor:

import lzma
from functools import partial
import multiprocessing


def run_lzma(data,c):
    return c.compress(data)


def split_len(seq, length):
    return [str.encode(seq[i:i+length]) for i in range(0, len(seq), length)]



def lzma_mp(sequence,threads=3):
  lzc = lzma.LZMACompressor()
  blocksize = int(round(len(sequence)/threads))
  strings = split_len(sequence, blocksize)
  lzc_partial = partial(run_lzma,c=lzc)
  pool=multiprocessing.Pool()
  lzc_pool = list(pool.map(lzc_partial,strings))
  pool.close()
  pool.join()
  out_flush = lzc.flush()
  return b"".join(lzc_pool + [out_flush])

sequence = 'AAAAAJKDDDDDDDDDDDDDDDDDDDDDDDDDDDDGJFKSHFKLHALWEHAIHWEOIAH IOAHIOWEHIOHEIOFEAFEASFEAFWEWWWWWWWWWWWWWWWWWWWWWWWWWWWWWEWFQWEWQWQGEWQFEWFDWEWEGEFGWEG'


lzma_mp(sequence,threads=3)

----------
components: ctypes
messages: 201278
nosy: cantor
priority: normal
severity: normal
status: open
title: lzma hangs for a very long time when run in parallel using python's muptiprocessing module?
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Oct 25 21:42:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Oct 2013 19:42:28 +0000
Subject: [New-bugs-announce] [issue19396] test_contextlib fails with -S
Message-ID: <1382730148.19.0.17792113903.issue19396@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

$ ./python -S -m test test_contextlib
[1/1] test_contextlib
test test_contextlib failed -- Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/test/test_contextlib.py", line 640, in test_redirect_to_string_io
    help(pow)
NameError: name 'help' is not defined

----------
assignee: ncoghlan
components: Tests
messages: 201284
nosy: ncoghlan, pitrou
priority: low
severity: normal
status: open
title: test_contextlib fails with -S
versions: Python 3.4

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

From report at bugs.python.org  Fri Oct 25 21:43:23 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Oct 2013 19:43:23 +0000
Subject: [New-bugs-announce] [issue19397] test_pydoc fails with -S
Message-ID: <1382730203.09.0.761692334901.issue19397@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

$ ./python -S -m test test_pydoc
[1/1] test_pydoc
test test_pydoc failed -- Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/test/test_pydoc.py", line 473, in test_namedtuple_public_underscore
    help(NT)
NameError: name 'help' is not defined

----------
components: Tests
messages: 201285
nosy: pitrou
priority: low
severity: normal
status: open
title: test_pydoc fails with -S
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Oct 25 21:43:53 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Oct 2013 19:43:53 +0000
Subject: [New-bugs-announce] [issue19398] test_trace fails with -S
Message-ID: <1382730233.11.0.30990585871.issue19398@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

$ ./python -S -m test test_trace
[1/1] test_trace
test test_trace failed -- Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/test/test_trace.py", line 313, in test_coverage
    self.assertTrue("pprint.cover" in files)
AssertionError: False is not true

----------
components: Tests
messages: 201286
nosy: pitrou
priority: low
severity: normal
status: open
title: test_trace fails with -S
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Oct 25 23:23:25 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Oct 2013 21:23:25 +0000
Subject: [New-bugs-announce] [issue19399] sporadic test_subprocess failure
Message-ID: <1382736205.96.0.919532282342.issue19399@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

It looks like this may be the symptom of a buglet in Thread.join:

======================================================================
ERROR: test_communicate_timeout (test.test_subprocess.ProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\home\cpython\buildslave\x86\3.x.snakebite-win2k8r2sp1-x86\build\lib\test\test_subprocess.py", line 672, in test_communicate_timeout
    timeout=0.3)
  File "E:\home\cpython\buildslave\x86\3.x.snakebite-win2k8r2sp1-x86\build\lib\unittest\case.py", line 689, in assertRaises
    return context.handle('assertRaises', callableObj, args, kwargs)
  File "E:\home\cpython\buildslave\x86\3.x.snakebite-win2k8r2sp1-x86\build\lib\unittest\case.py", line 158, in handle
    callable_obj(*args, **kwargs)
  File "E:\home\cpython\buildslave\x86\3.x.snakebite-win2k8r2sp1-x86\build\lib\subprocess.py", line 947, in communicate
    stdout, stderr = self._communicate(input, endtime, timeout)
  File "E:\home\cpython\buildslave\x86\3.x.snakebite-win2k8r2sp1-x86\build\lib\subprocess.py", line 1193, in _communicate
    self.stdout_thread.join(self._remaining_time(endtime))
  File "E:\home\cpython\buildslave\x86\3.x.snakebite-win2k8r2sp1-x86\build\lib\threading.py", line 1062, in join
    self._wait_for_tstate_lock(timeout=timeout)
  File "E:\home\cpython\buildslave\x86\3.x.snakebite-win2k8r2sp1-x86\build\lib\threading.py", line 1074, in _wait_for_tstate_lock
    elif lock.acquire(block, timeout):
ValueError: timeout value must be strictly positive

----------
components: Library (Lib)
messages: 201296
nosy: pitrou, tim.peters
priority: normal
severity: normal
status: open
title: sporadic test_subprocess failure
versions: Python 3.4

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

From report at bugs.python.org  Sat Oct 26 00:55:59 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 25 Oct 2013 22:55:59 +0000
Subject: [New-bugs-announce] [issue19400] Extension module builds can fail
	with Xcode 5 on OS X	10.8+
Message-ID: <1382741759.73.0.518874272846.issue19400@psf.upfronthosting.co.za>


New submission from Ned Deily:

On OS X 10.8 or 10.9 when using Xcode 5 and attempting to build an extension module using a universal Python that includes a PPC architecture (such as from one of the python.org 32-bit-only installers), the extension module build can fail with numerous compiler errors.  Recent python.org 32-bit-only installers attempt to remove unavailable PPC architectures when building extension modules.  Unfortunately, due to changes between Xcode 4 and Xcode 5, the test in Distutils does not work with Xcode 5 compilers.

The problem affects the current OS X 32-bit-only python.org installers for Python 3.3.2 and 2.7.5.  It is not a problem for OS X 64-bit/32-bit installers for 10.6+.

A workaround for the problem is to override the Distutils defaults by setting the ARCHFLAGS environment variable to the desired architectures, for example:

ARCHFLAGS="-arch i386" /usr/local/bin/python2.7 -m pip install ...

----------
assignee: ned.deily
components: Distutils, Extension Modules, Macintosh
messages: 201299
nosy: ned.deily, tarek
priority: normal
severity: normal
status: open
title: Extension module builds can fail with Xcode 5 on OS X 10.8+
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Oct 26 02:30:14 2013
From: report at bugs.python.org (Brian Zhou)
Date: Sat, 26 Oct 2013 00:30:14 +0000
Subject: [New-bugs-announce] [issue19401] Segmentation fault with float
	arithmatics on OS X	Mavericks
Message-ID: <1382747414.16.0.56673583782.issue19401@psf.upfronthosting.co.za>


New submission from Brian Zhou:

$ uname -a
Darwin foobar 13.0.0 Darwin Kernel Version 13.0.0: Thu Sep 19 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64

$ python
Python 2.7.5 (v2.7.5:ab05e7dd2788, May 13 2013, 13:18:45)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 11 * 1.1
12.100000000000001
>>> 11 * 1.2
Segmentation fault: 11

This is python.org build installed with the Mac installer.

----------
messages: 201306
nosy: Brian.Zhou
priority: normal
severity: normal
status: open
title: Segmentation fault with float arithmatics on OS X Mavericks
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Sat Oct 26 03:50:04 2013
From: report at bugs.python.org (Perry Lorier)
Date: Sat, 26 Oct 2013 01:50:04 +0000
Subject: [New-bugs-announce] [issue19402] AbstractBasicAuthHandler
Message-ID: <1382752204.16.0.0164222061045.issue19402@psf.upfronthosting.co.za>


New submission from Perry Lorier:

Similar to Issue8797, if the first 5 requests result in exception (eg 404), then AbstractBasicAuthHandler.retried is not reset, meaning authentication will fail on all subsequent attempts.

The logic in AbstractBasicAuthHandler.http_error_401 calling self.reset_retry_count() needs to be fixed, possibly moving it up before the call to http_error_auth_reqed()

----------
messages: 201309
nosy: Perry.Lorier
priority: normal
severity: normal
status: open
title: AbstractBasicAuthHandler
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Oct 26 08:43:50 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 26 Oct 2013 06:43:50 +0000
Subject: [New-bugs-announce] [issue19403] Make contextlib.redirect_stdout
	reentrant
Message-ID: <1382769830.57.0.0645984337848.issue19403@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

I realised making contextlib.redirect_stdout reentrant was actually fairly easy (thread safety is inherently impossible due to the process global side effect). Since making it reentrant makes it more user-friendly, I'll tweak the implementation to work that way.

Need to resolve issue 19330 first, though.

As part of this change, the reusable-but-not-reentrant example in the docs needs to be updated to use contextlib.ExitStack rather than this (that's inherently not reentrant, since all the context managers in the stack would be triggered when the innermost context ends).

----------
assignee: ncoghlan
messages: 201318
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Make contextlib.redirect_stdout reentrant
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Oct 26 09:22:18 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 26 Oct 2013 07:22:18 +0000
Subject: [New-bugs-announce] [issue19404] Simplify per-instance control of
	help() output
Message-ID: <1382772138.17.0.267743568288.issue19404@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

While working on issue 19330, I also took a look at whether or not I could fix the @contextmanager decorator to also provide useful help information on the resulting objects. This turned out to be difficult, since calling decorated functions produces instances of contextlib._GeneratorContextManager, and help() insists on showing the docs for that rather than a __doc__ attribute set on the context manager instance itself.

This behaviour appears to be ultimately due to "pydoc.render_doc()", which has a hardcoded list of conditions it checks to decide whether to document the instance directly or to provide the class documentation instead:
http://hg.python.org/cpython/file/2b904290b3b9/Lib/pydoc.py#l1544

This first idea that comes to mind is to simply add the additional condition that if "obj.__doc__ != type(obj).__doc__", then help() shouldn't replace the object with it's type. The simple trick that I originally explored was simply setting the __doc__ attribute on the _GeneratorContextManager instance based on the docstring of the decorated function, and I believe that approach might work for property instances, too (rather than needing to hardcode the isinstance check into render_doc()). It may even handle some of the other currently hardcoded conditions in that list.

----------
components: Library (Lib)
messages: 201322
nosy: ethan.furman, ncoghlan
priority: normal
severity: normal
status: open
title: Simplify per-instance control of help() output
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Oct 26 10:40:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Oct 2013 08:40:19 +0000
Subject: [New-bugs-announce] [issue19405] Fix outdated comments in the _sre
	module
Message-ID: <1382776819.97.0.0101067680791.issue19405@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The _sre module contains comments which refers to 16-bit SRE_CODE. Now SRE_CODE is 32-bit.

Antoine partially reviewed this change in issue19329.

----------
assignee: docs at python
components: Documentation, Regular Expressions
files: sre_comments.patch
keywords: patch
messages: 201330
nosy: docs at python, ezio.melotti, mrabarnett, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix outdated comments in the _sre module
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32368/sre_comments.patch

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

From report at bugs.python.org  Sat Oct 26 14:42:33 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 26 Oct 2013 12:42:33 +0000
Subject: [New-bugs-announce] [issue19406] PEP 453: add the ensurepip module
Message-ID: <1382791353.58.0.0832819187688.issue19406@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Adding the initial ensurepip implementation and module docs

(the "Installing Python Modules" updates will be handled in a separate issue)

----------
assignee: dstufft
components: Library (Lib)
messages: 201342
nosy: dstufft, larry, ncoghlan
priority: release blocker
severity: normal
status: open
title: PEP 453: add the ensurepip module
versions: Python 3.4

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

From report at bugs.python.org  Sat Oct 26 14:44:35 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 26 Oct 2013 12:44:35 +0000
Subject: [New-bugs-announce] [issue19407] PEP 453: update the "Installing
	Python Modules"	documentation
Message-ID: <1382791475.83.0.387983167617.issue19407@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Updating the "Installing Python Modules" docs in 2.7, 3.3 and default to recommend pip as the default cross-platform installer.

----------
assignee: ncoghlan
components: Documentation
messages: 201343
nosy: benjamin.peterson, georg.brandl, larry, ncoghlan
priority: release blocker
severity: normal
status: open
title: PEP 453: update the "Installing Python Modules" documentation
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Oct 26 14:53:41 2013
From: report at bugs.python.org (Isis Binder)
Date: Sat, 26 Oct 2013 12:53:41 +0000
Subject: [New-bugs-announce] [issue19408] Regex with set of characters and
	groups raises error
Message-ID: <1382792021.59.0.192003336174.issue19408@psf.upfronthosting.co.za>


New submission from Isis Binder:

I was working on some SPOJ exercises when the regex module hit me with an error related to '*' being used inside the character set operator.

I looked in the module docs but it says: Special characters lose their special meaning inside sets. For example, [(+*)] will match any of the literal characters '(', '+', '*', or ')'.

Traceback attached.

Offending code (inside IDLE):
import re
a = '73479*5152'
re.match(r'(\d+)([+-*])(\d+)', a).groups()

NOTE: if I write r'(\d+)([*])(\d+)', r'(\d+)([*+-])(\d+)' or r'(\d+)([+*-])(\d+)' it works. Shouldn't it simply work as described in the docs or should the docs be updated with an entry about proper character ordering in the character class?

----------
components: Regular Expressions
files: traceback.txt
messages: 201351
nosy: Isis.Binder, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Regex with set of characters and groups raises error
type: crash
versions: Python 3.3
Added file: http://bugs.python.org/file32372/traceback.txt

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

From report at bugs.python.org  Sat Oct 26 15:57:29 2013
From: report at bugs.python.org (Donald Stufft)
Date: Sat, 26 Oct 2013 13:57:29 +0000
Subject: [New-bugs-announce] [issue19409] pkgutil isn't importable from a
	file or the REPL
Message-ID: <1382795849.54.0.132790969201.issue19409@psf.upfronthosting.co.za>


New submission from Donald Stufft:

Currently pkgutil cannot be imported unless you first import importlib.machinery. This means ./python.exe -m pkgutil works, but doing ``import pkgutil`` in the REPL does not.

----------
messages: 201355
nosy: dstufft, larry
priority: release blocker
severity: normal
status: open
title: pkgutil isn't importable from a file or the REPL
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Oct 26 17:38:30 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 26 Oct 2013 15:38:30 +0000
Subject: [New-bugs-announce] [issue19410] Restore empty string special
	casing in	importlib.machinery.FileFinder
Message-ID: <1382801910.68.0.88492101144.issue19410@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

As noted on python-dev, while changing PathFinder to expand the empty string to the current working directory is a good idea, removing the '' special case handling in FileFinder may break subclasses and other custom metapath hooks that expect the current behaviour.

Just creating this to make sure it is resolved before 3.4 is released (it is simply a matter of reverting a patch, since we want to keep *most* of the change that implemented absolute paths in __file__ attributes, just not all of it)

----------
assignee: brett.cannon
messages: 201367
nosy: brett.cannon, larry, ncoghlan
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Restore empty string special casing in importlib.machinery.FileFinder
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Oct 26 19:18:30 2013
From: report at bugs.python.org (Devin Jeanpierre)
Date: Sat, 26 Oct 2013 17:18:30 +0000
Subject: [New-bugs-announce] [issue19411] binascii.hexlify docs say it
	returns a string (it	returns bytes)
Message-ID: <1382807910.82.0.748740374727.issue19411@psf.upfronthosting.co.za>


New submission from Devin Jeanpierre:

http://docs.python.org/3.4/library/binascii.html#binascii.hexlify

----------
assignee: docs at python
components: Documentation
messages: 201376
nosy: Devin Jeanpierre, docs at python
priority: normal
severity: normal
status: open
title: binascii.hexlify docs say it returns a string (it returns bytes)
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Oct 26 19:41:07 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 26 Oct 2013 17:41:07 +0000
Subject: [New-bugs-announce] [issue19412] Add a test.support decorator for
	tests that require C	level docstrings
Message-ID: <1382809267.31.0.380635405032.issue19412@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

It is *not* OK to have a "test.support.HAVE_DOCSTRINGS" flag that is true under -OO, nor a requires_docstrings decorator that still attempts to run the test under those conditions.

Issue 19330 updated them so their meaning matched their names and the surrounding comments, but they were apparently being used instead to refer to a specific kind of CPython build.

A more logical name for such a feature would be HAVE_C_DOCSTRINGS and requires_c_docstrings.

----------
components: Tests
messages: 201379
nosy: ncoghlan, serhiy.storchaka, skrah
priority: normal
severity: normal
status: open
title: Add a test.support decorator for tests that require C level docstrings
versions: Python 3.4

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

From report at bugs.python.org  Sun Oct 27 04:16:31 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 27 Oct 2013 03:16:31 +0000
Subject: [New-bugs-announce] [issue19413] Reload semantics changed
	unexpectedly in Python 3.3
Message-ID: <1382843791.56.0.901507046365.issue19413@psf.upfronthosting.co.za>


New submission from Eric Snow:

PJE brought up concerns on python-dev regarding PEP 451 and module reloading. [1]  However, the issue isn't with the PEP changing reload semantics (mostly).  Those actually changed with the switch to importlib (and a pure Python reload function) in the 3.3 release.

Nick sounded positive on fixing it, while Brett did not sound convinced it is worth it.  I'm +1 as long as it isn't too complicated to fix.  While we hash that out, here's a patch that hopefully demonstrates it isn't too complicated. :)

[1] https://mail.python.org/pipermail/python-dev/2013-October/129863.html

----------
components: Library (Lib)
files: reload-semantics.diff
keywords: patch
messages: 201407
nosy: brett.cannon, eric.snow, ncoghlan, pje
priority: normal
severity: normal
stage: patch review
status: open
title: Reload semantics changed unexpectedly in Python 3.3
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32385/reload-semantics.diff

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

From report at bugs.python.org  Sun Oct 27 04:27:54 2013
From: report at bugs.python.org (Nikolaus Rath)
Date: Sun, 27 Oct 2013 03:27:54 +0000
Subject: [New-bugs-announce] [issue19414] OrderedDict.values() behavior for
	modified instance
Message-ID: <1382844474.66.0.775956254592.issue19414@psf.upfronthosting.co.za>


New submission from Nikolaus Rath:

The documentation says the following about modifying a dict while
iterating through its view:

| Iterating views while adding or deleting entries in the dictionary may
| raise a RuntimeError or fail to iterate over all entries.
(http://docs.python.org/3/library/stdtypes.html#dict-views)

The OrderedDict documentation doesn't have anything to say on the
subject. In practice, its implementation actually mostly correponds to
naive expectations:

>>> from collections import OrderedDict
>>> d = OrderedDict()
>>> for i in range(5):
...    d[i] = i
... 
>>> i = iter(d.values())
>>> next(i)
0
>>> del d[0]
>>> next(i)
1
>>> del d[2]
>>> next(i)
3
>>> d.move_to_end(1)
>>> next(i)
4
>>> next(i)
1
>>> 

etc.

However, there is one case that results in a rather confusing error:

>>> a = OrderedDict()
>>> a[0] = 0
>>> a[1] = 1
>>> a[2] = 2
>>> i = iter(a.values())
>>> next(i)
0
>>> del a[0]
>>> del a[1]
>>> next(i)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.3/collections/abc.py", line 495, in __iter__
    yield self._mapping[key]
KeyError: 1


What happens here is that a[0] is returned from the linked list, but it
still contains links to a[1]. When a[1] is deleted, the links of its
predecessor and successor are updated, but a[0] still points to
a[1]. The OrderedList then hands a non-existing key to the values()
implementation in collections.abc.

The result is not only mightily confusing, but it is also not covered by
the documentation (KeyError isn't a RuntimeError). 

I would very much like to see this fixed, but I'm not sure if there's a
good way to do that.

I see the following options:

(a) When deleting an element from an OrderedList, update the pointers in
    the corresponding linked list element to the end of the list. Then
    removing the currently "active" element during the iteration would
    automatically end the iteration.

    For that, we'd just have to add two lines to __delitem__:

    def __delitem__(self, key, dict_delitem=dict.__delitem__):
        dict_delitem(self, key)
        link = self.__map.pop(key)
        link_prev = link.prev
        link_next = link.next
        link_prev.next = link_next
        link_next.prev = link_prev

        link.prev = root # new 
        link.next = root # new
    

    The new behavior is explicitly covered by the documentation
    (changing the dict may result in incomplete iteration), but it's a
    change to what happened before.

(b) When iterating through an OrderedDict, check that the next element
    is actually still in the hash, i.e. change

    def __iter__(self):
        root = self.__root
        curr = root.next
        while curr is not root:
            yield curr.key
            curr = curr.next
    to

    def __iter__(self):
        root = self.__root
        curr = root.next
        while curr is not root and curr.key in self:
            yield curr.key
            curr = curr.next

    that would terminate the iteration only in the special case, but
    incur an extra dict lookup at every iteration.

    Alternatively, one could try very hard to not stop the iteration:
    
        while curr is not root:
            yield curr.key
            while curr is not root:
                curr = curr.next
                if curr.key in self:
                    break

(c) Catch the KeyError in values(), and re-raise the proper exception in
    class ValuesView:

    def __iter__(self):
        for key in self._mapping:
            try:
                yield self._mapping[key]
            except KeyError:
                raise RuntimeError("underlying Mapping instance modified during iteration")


    I consider this a bit ugly, because it may mask other problems in a
    custom Mapping implementation (that may raise a KeyError because of
    a bug in the Mapping implementation itself).
    
(d) Extend the OrderedDict documentation to explicity document this
    case.

    This has the drawback that it would probably be nicer to just have
    the behavior be consistent and correspond to intuitive expectations.

    
Would any of those fixes be acceptable? Or is there an even better option?

----------
components: Library (Lib)
messages: 201408
nosy: Nikratio
priority: normal
severity: normal
status: open
title: OrderedDict.values() behavior for modified instance
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sun Oct 27 06:31:39 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 27 Oct 2013 05:31:39 +0000
Subject: [New-bugs-announce] [issue19415] test_gdb fails when using
	--without-doc-strings on	Fedora 19
Message-ID: <1382851899.25.0.924998884504.issue19415@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

(after a "make clobber" to ensure there weren't any stale artifacts lying around)

$ ./configure --without-doc-strings && make && ./python -m test -v test_gdb

<snip>

======================================================================
FAIL: test_lists (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of lists
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ncoghlan/devel/py3k/Lib/test/test_gdb.py", line 257, in test_lists
    self.assertGdbRepr(list(range(5)))
  File "/home/ncoghlan/devel/py3k/Lib/test/test_gdb.py", line 226, in assertGdbRepr
    cmds_after_breakpoint)
  File "/home/ncoghlan/devel/py3k/Lib/test/test_gdb.py", line 194, in get_gdb_repr
    import_site=import_site)
  File "/home/ncoghlan/devel/py3k/Lib/test/test_gdb.py", line 177, in get_stack_trace
    self.assertEqual(unexpected_errlines, [])
AssertionError: Lists differ: ["Python Exception <type 'exceptions.Unico[215 chars]e: "] != []

First list contains 2 additional elements.
First extra element 0:
Python Exception <type 'exceptions.UnicodeDecodeError'> 'utf8' codec can't decode byte 0x80 in position 0: invalid start byte: 

+ []
- ["Python Exception <type 'exceptions.UnicodeDecodeError'> 'utf8' codec can't "
-  'decode byte 0x80 in position 0: invalid start byte: ',
-  "Python Exception <type 'exceptions.UnicodeDecodeError'> 'utf8' codec can't "
-  'decode byte 0x80 in position 0: invalid start byte: ']

======================================================================
FAIL: test_selfreferential_list (test.test_gdb.PrettyPrintTests)
Ensure that a reference loop involving a list doesn't lead proxyval
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ncoghlan/devel/py3k/Lib/test/test_gdb.py", line 473, in test_selfreferential_list
    self.get_gdb_repr("a = [3, 4, 5] ; a.append(a) ; id(a)")
  File "/home/ncoghlan/devel/py3k/Lib/test/test_gdb.py", line 194, in get_gdb_repr
    import_site=import_site)
  File "/home/ncoghlan/devel/py3k/Lib/test/test_gdb.py", line 177, in get_stack_trace
    self.assertEqual(unexpected_errlines, [])
AssertionError: Lists differ: ["Python Exception <type 'exceptions.Unico[229 chars]e: "] != []

First list contains 2 additional elements.
First extra element 0:
Python Exception <type 'exceptions.UnicodeDecodeError'> 'utf8' codec can't decode byte 0xe0 in position 0: invalid continuation byte: 

+ []
- ["Python Exception <type 'exceptions.UnicodeDecodeError'> 'utf8' codec can't "
-  'decode byte 0xe0 in position 0: invalid continuation byte: ',
-  "Python Exception <type 'exceptions.UnicodeDecodeError'> 'utf8' codec can't "
-  'decode byte 0xe0 in position 0: invalid continuation byte: ']

======================================================================
FAIL: test_subclassing_list (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of an instance of a list subclass
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ncoghlan/devel/py3k/Lib/test/test_gdb.py", line 376, in test_subclassing_list
    id(foo)''')
  File "/home/ncoghlan/devel/py3k/Lib/test/test_gdb.py", line 194, in get_gdb_repr
    import_site=import_site)
  File "/home/ncoghlan/devel/py3k/Lib/test/test_gdb.py", line 177, in get_stack_trace
    self.assertEqual(unexpected_errlines, [])
AssertionError: Lists differ: ["Python Exception <type 'exceptions.Unico[215 chars]e: "] != []

First list contains 2 additional elements.
First extra element 0:
Python Exception <type 'exceptions.UnicodeDecodeError'> 'utf8' codec can't decode byte 0xa0 in position 0: invalid start byte: 

+ []
- ["Python Exception <type 'exceptions.UnicodeDecodeError'> 'utf8' codec can't "
-  'decode byte 0xa0 in position 0: invalid start byte: ',
-  "Python Exception <type 'exceptions.UnicodeDecodeError'> 'utf8' codec can't "
-  'decode byte 0xa0 in position 0: invalid start byte: ']

======================================================================
FAIL: test_truncation (test.test_gdb.PrettyPrintTests)
Verify that very long output is truncated
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ncoghlan/devel/py3k/Lib/test/test_gdb.py", line 530, in test_truncation
    gdb_repr, gdb_output = self.get_gdb_repr('id(list(range(1000)))')
  File "/home/ncoghlan/devel/py3k/Lib/test/test_gdb.py", line 194, in get_gdb_repr
    import_site=import_site)
  File "/home/ncoghlan/devel/py3k/Lib/test/test_gdb.py", line 177, in get_stack_trace
    self.assertEqual(unexpected_errlines, [])
AssertionError: Lists differ: ["Python Exception <type 'exceptions.Unico[215 chars]e: "] != []

First list contains 2 additional elements.
First extra element 0:
Python Exception <type 'exceptions.UnicodeDecodeError'> 'utf8' codec can't decode byte 0x80 in position 0: invalid start byte: 

+ []
- ["Python Exception <type 'exceptions.UnicodeDecodeError'> 'utf8' codec can't "
-  'decode byte 0x80 in position 0: invalid start byte: ',
-  "Python Exception <type 'exceptions.UnicodeDecodeError'> 'utf8' codec can't "
-  'decode byte 0x80 in position 0: invalid start byte: ']

======================================================================
FAIL: test_tuples (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of tuples
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ncoghlan/devel/py3k/Lib/test/test_gdb.py", line 307, in test_tuples
    self.assertGdbRepr(tuple())
  File "/home/ncoghlan/devel/py3k/Lib/test/test_gdb.py", line 226, in assertGdbRepr
    cmds_after_breakpoint)
  File "/home/ncoghlan/devel/py3k/Lib/test/test_gdb.py", line 194, in get_gdb_repr
    import_site=import_site)
  File "/home/ncoghlan/devel/py3k/Lib/test/test_gdb.py", line 177, in get_stack_trace
    self.assertEqual(unexpected_errlines, [])
AssertionError: Lists differ: ["Python Exception <type 'exceptions.Unico[215 chars]e: "] != []

First list contains 2 additional elements.
First extra element 0:
Python Exception <type 'exceptions.UnicodeDecodeError'> 'utf8' codec can't decode byte 0xb0 in position 0: invalid start byte: 

+ []
- ["Python Exception <type 'exceptions.UnicodeDecodeError'> 'utf8' codec can't "
-  'decode byte 0xb0 in position 0: invalid start byte: ',
-  "Python Exception <type 'exceptions.UnicodeDecodeError'> 'utf8' codec can't "
-  'decode byte 0xb0 in position 0: invalid start byte: ']

----------------------------------------------------------------------
Ran 45 tests in 12.146s

FAILED (failures=5, skipped=15)
test test_gdb failed
1 test failed:
    test_gdb

----------
components: Build
messages: 201414
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: test_gdb fails when using --without-doc-strings on Fedora 19
versions: Python 3.4

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

From report at bugs.python.org  Sun Oct 27 14:18:25 2013
From: report at bugs.python.org (Roy Smith)
Date: Sun, 27 Oct 2013 13:18:25 +0000
Subject: [New-bugs-announce] [issue19416] NNTP page has incorrect links
Message-ID: <1382879905.74.0.020204746466.issue19416@psf.upfronthosting.co.za>


New submission from Roy Smith:

http://docs.python.org/2/library/nntplib.html contains intra-page references such as:

NNTP.next()
Send a NEXT command. Return as for stat().

The problem is that the link for "stat" points to the stat module (i.e. http://docs.python.org/2/library/stat.html#module-stat).  It should be pointing to the NNTP.stat() entry on this page.

The problem exists for :

NNTP.next()
NNTP.last()
NNTP.head(id)
NNTP.body(id[, file])
NNTP.article(id)

and maybe some others I missed.

----------
assignee: docs at python
components: Documentation
messages: 201456
nosy: docs at python, roysmith
priority: normal
severity: normal
status: open
title: NNTP page has incorrect links
versions: Python 2.7

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

From report at bugs.python.org  Sun Oct 27 18:51:48 2013
From: report at bugs.python.org (Colin Williams)
Date: Sun, 27 Oct 2013 17:51:48 +0000
Subject: [New-bugs-announce] [issue19417] bdb test coverage
Message-ID: <1382896308.72.0.45441786626.issue19417@psf.upfronthosting.co.za>


New submission from Colin Williams:

This one is pretty involved.  The tests might reach into the guts of the modules a bit too much, I'd be open to less invasive suggestions.

----------
files: bdb.patch
keywords: patch
messages: 201481
nosy: Colin.Williams
priority: normal
severity: normal
status: open
title: bdb test coverage
Added file: http://bugs.python.org/file32389/bdb.patch

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

From report at bugs.python.org  Sun Oct 27 20:44:38 2013
From: report at bugs.python.org (Tim Golden)
Date: Sun, 27 Oct 2013 19:44:38 +0000
Subject: [New-bugs-announce] [issue19418] audioop.c giving signed/unsigned
	warnings on Windows
Message-ID: <1382903078.0.0.055907083151.issue19418@psf.upfronthosting.co.za>


New submission from Tim Golden:

Modules/audioop.c is giving compile warnings on Windows against lines 18 & 437.

..\Modules\audioop.c(18): warning C4146: unary minus operator applied to unsigned type, result still unsigned
..\Modules\audioop.c(437): warning C4146: unary minus operator applied to unsigned type, result still unsigned

----------
components: Build
messages: 201485
nosy: serhiy.storchaka, tim.golden
priority: normal
severity: normal
status: open
title: audioop.c giving signed/unsigned warnings on Windows
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Sun Oct 27 22:04:56 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 27 Oct 2013 21:04:56 +0000
Subject: [New-bugs-announce] [issue19419] Use abc.ABC in the collections ABC
Message-ID: <1382907896.33.0.659909240184.issue19419@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Minor clean-up to the collections ABCs.  Use the Django style that inherits the metaclass rather than specifying the metaclass directly.

The rationale is that it makes the ABCs cleaner looking and less intimidating.

----------
files: abc_meta.diff
keywords: patch
messages: 201500
nosy: rhettinger
priority: low
severity: normal
status: open
title: Use abc.ABC in the collections ABC
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32393/abc_meta.diff

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

From report at bugs.python.org  Mon Oct 28 12:53:18 2013
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 28 Oct 2013 11:53:18 +0000
Subject: [New-bugs-announce] [issue19420] Leak in _hashopenssl.c
Message-ID: <1382961198.75.0.11599120872.issue19420@psf.upfronthosting.co.za>


New submission from Stefan Krah:

There's a leak in _hashopenssl.c. Patch attached.

----------
files: _hashopenssl.patch
keywords: patch
messages: 201527
nosy: skrah
priority: normal
severity: normal
status: open
title: Leak in _hashopenssl.c
Added file: http://bugs.python.org/file32394/_hashopenssl.patch

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

From report at bugs.python.org  Mon Oct 28 13:49:55 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Oct 2013 12:49:55 +0000
Subject: [New-bugs-announce] [issue19421] FileIO destructor imports
	indirectly the io module at	exit
Message-ID: <1382964595.86.0.735733174732.issue19421@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Since Python 3.3, when an unclosed file is destroyed, a warning is emitted. Good.

The problem is when the warning is emitted after the io has been unloaded: in this case, the warning will try to reload the io module to display the Python line where the warning occurred. _Py_DisplaySourceLine() starts with:

   io = PyImport_ImportModuleNoBlock("io");

For example, I got the issue while the warning was emitted during PyImport_Cleanup(), see the full gdb backtrace below (the assertion failure was caused by a local modification, it's unrelated to this issue).

show_warning() and/or _Py_DisplaySourceLine() should not try to display the Python line while Python is exiting. There is for example the flag _Py_Finalizing.

If we really want to display the Python line/traceback, the io module should be kept alive until all warnings are emitted. But I don't think that it is possible. Or Python should try to unload other modules before the io module?


(gdb) where
#0  0x00000037f4835ba5 in raise () from /lib64/libc.so.6
#1  0x00000037f4837358 in abort () from /lib64/libc.so.6
#2  0x00000037f482e972 in __assert_fail_base () from /lib64/libc.so.6
#3  0x00000037f482ea22 in __assert_fail () from /lib64/libc.so.6
#4  0x00000000004bddbd in PyObject_Repr (v='builtins') at Objects/object.c:457
#5  0x0000000000506161 in unicode_fromformat_arg (writer=0x7fffffffb780, f=0x68b073 "R halted; None in sys.modules", vargs=0x7fffffffb7c0)
    at Objects/unicodeobject.c:2669
#6  0x00000000005065ca in PyUnicode_FromFormatV (format=0x68b068 "import of %R halted; None in sys.modules", vargs=0x7fffffffb810)
    at Objects/unicodeobject.c:2734
#7  0x000000000050679f in PyUnicode_FromFormat (format=0x68b068 "import of %R halted; None in sys.modules") at Objects/unicodeobject.c:2785
#8  0x00000000005c8a9a in PyImport_ImportModuleLevelObject (name='builtins', given_globals=0x0, locals=0x0, given_fromlist=0x0, level=0)
    at Python/import.c:1410
#9  0x00000000005c98eb in PyImport_ImportModuleLevel (name=0x68aa45 "builtins", globals=0x0, locals=0x0, fromlist=0x0, level=0) at Python/import.c:1560
#10 0x00000000005c9ba7 in PyImport_Import (module_name='io') at Python/import.c:1639
#11 0x00000000005c7e00 in PyImport_ImportModule (name=0x65084a "io") at Python/import.c:1141
#12 0x00000000005c7e8e in PyImport_ImportModuleNoBlock (name=0x65084a "io") at Python/import.c:1158
#13 0x0000000000432f85 in _Py_DisplaySourceLine (f=<_io.TextIOWrapper at remote 0x7ffff1b97898>, filename='sys', lineno=1, indent=2)
    at Python/traceback.c:243
#14 0x00000000005542fa in show_warning (filename='sys', lineno=1, text="unclosed file <_io.TextIOWrapper name='x.py' mode='r' encoding='UTF-8'>", category=
    <type at remote 0x8f60a0>, sourceline=0x0) at Python/_warnings.c:287
#15 0x000000000055487a in warn_explicit (category=<type at remote 0x8f60a0>, message=
    ResourceWarning("unclosed file <_io.TextIOWrapper name='x.py' mode='r' encoding='UTF-8'>",), filename='sys', lineno=1, module='sys', registry={}, 
    sourceline=0x0) at Python/_warnings.c:409
#16 0x0000000000555b88 in do_warn (message="unclosed file <_io.TextIOWrapper name='x.py' mode='r' encoding='UTF-8'>", category=<type at remote 0x8f60a0>, 
    stack_level=1) at Python/_warnings.c:614
#17 0x00000000005561dd in warn_unicode (category=<type at remote 0x8f60a0>, message=
    "unclosed file <_io.TextIOWrapper name='x.py' mode='r' encoding='UTF-8'>", stack_level=1) at Python/_warnings.c:732
#18 0x0000000000556336 in PyErr_WarnFormat (category=<type at remote 0x8f60a0>, stack_level=1, format=0x6a3e8b "unclosed file %R") at Python/_warnings.c:755
#19 0x000000000061cff5 in fileio_dealloc_warn (self=0x7ffff1a04368, source=<_io.TextIOWrapper at remote 0x7ffff1b97dc0>) at ./Modules/_io/fileio.c:79
#20 0x00000000004b961d in PyCFunction_Call (func=<built-in method _dealloc_warn of _io.FileIO object at remote 0x7ffff1a04368>, arg=
    (<_io.TextIOWrapper at remote 0x7ffff1b97dc0>,), kw=0x0) at Objects/methodobject.c:120
#21 0x000000000045b5d3 in PyObject_Call (func=<built-in method _dealloc_warn of _io.FileIO object at remote 0x7ffff1a04368>, arg=
    (<_io.TextIOWrapper at remote 0x7ffff1b97dc0>,), kw=0x0) at Objects/abstract.c:2085
#22 0x000000000045b76d in call_function_tail (callable=<built-in method _dealloc_warn of _io.FileIO object at remote 0x7ffff1a04368>, args=
    (<_io.TextIOWrapper at remote 0x7ffff1b97dc0>,)) at Objects/abstract.c:2122
#23 0x000000000045ba90 in callmethod (func=<built-in method _dealloc_warn of _io.FileIO object at remote 0x7ffff1a04368>, format=0x6a4af1 "O", va=
    0x7fffffffd288, is_size_t=1) at Objects/abstract.c:2189
#24 0x000000000045bf63 in _PyObject_CallMethodId_SizeT (o=<_io.FileIO at remote 0x7ffff1a04368>, name=0x936e80 <PyId__dealloc_warn>, format=0x6a4af1 "O")
    at Objects/abstract.c:2278
#25 0x0000000000621e4e in buffered_dealloc_warn (self=0x7ffff1ae4838, source=<_io.TextIOWrapper at remote 0x7ffff1b97dc0>) at ./Modules/_io/bufferedio.c:456
#26 0x00000000004b961d in PyCFunction_Call (func=<built-in method _dealloc_warn of _io.BufferedReader object at remote 0x7ffff1ae4838>, arg=
    (<_io.TextIOWrapper at remote 0x7ffff1b97dc0>,), kw=0x0) at Objects/methodobject.c:120
#27 0x000000000045b5d3 in PyObject_Call (func=<built-in method _dealloc_warn of _io.BufferedReader object at remote 0x7ffff1ae4838>, arg=
    (<_io.TextIOWrapper at remote 0x7ffff1b97dc0>,), kw=0x0) at Objects/abstract.c:2085
#28 0x000000000045b76d in call_function_tail (callable=<built-in method _dealloc_warn of _io.BufferedReader object at remote 0x7ffff1ae4838>, args=
    (<_io.TextIOWrapper at remote 0x7ffff1b97dc0>,)) at Objects/abstract.c:2122
#29 0x000000000045ba90 in callmethod (func=<built-in method _dealloc_warn of _io.BufferedReader object at remote 0x7ffff1ae4838>, format=0x6a57e5 "O", va=
    0x7fffffffd4f8, is_size_t=1) at Objects/abstract.c:2189
#30 0x000000000045bf63 in _PyObject_CallMethodId_SizeT (o=<_io.BufferedReader at remote 0x7ffff1ae4838>, name=0x938fe0 <PyId__dealloc_warn>, format=
    0x6a57e5 "O") at Objects/abstract.c:2278
#31 0x000000000063446c in textiowrapper_close (self=0x7ffff1b97dc0, args=0x0) at ./Modules/_io/textio.c:2581
#32 0x00000000004b956d in PyCFunction_Call (func=<built-in method close of _io.TextIOWrapper object at remote 0x7ffff1b97dc0>, arg=(), kw=0x0)
    at Objects/methodobject.c:106
#33 0x000000000045b5d3 in PyObject_Call (func=<built-in method close of _io.TextIOWrapper object at remote 0x7ffff1b97dc0>, arg=(), kw=0x0)
    at Objects/abstract.c:2085
#34 0x000000000045c254 in PyObject_CallMethodObjArgs (callable=<built-in method close of _io.TextIOWrapper object at remote 0x7ffff1b97dc0>, name='close')
    at Objects/abstract.c:2326
#35 0x000000000061abdf in iobase_finalize (self=<_io.TextIOWrapper at remote 0x7ffff1b97dc0>) at ./Modules/_io/iobase.c:228
#36 0x00000000004bd715 in PyObject_CallFinalizer (self=<_io.TextIOWrapper at remote 0x7ffff1b97dc0>) at Objects/object.c:272
#37 0x00000000004bd789 in PyObject_CallFinalizerFromDealloc (self=<_io.TextIOWrapper at remote 0x7ffff1b97dc0>) at Objects/object.c:289
#38 0x000000000061aca8 in _PyIOBase_finalize (self=<_io.TextIOWrapper at remote 0x7ffff1b97dc0>) at ./Modules/_io/iobase.c:252
#39 0x000000000062d116 in textiowrapper_dealloc (self=0x7ffff1b97dc0) at ./Modules/_io/textio.c:1138
---Type <return> to continue, or q <return> to quit---
#40 0x00000000004c12b3 in _Py_Dealloc (op=<_io.TextIOWrapper at remote 0x7ffff1b97dc0>) at Objects/object.c:1876
#41 0x00000000004a86d4 in free_keys_object (keys=0xa13980) at Objects/dictobject.c:364
#42 0x00000000004ab8b4 in dict_dealloc (mp=0x7ffff1b582f8) at Objects/dictobject.c:1386
#43 0x00000000004c12b3 in _Py_Dealloc (op=
    {'f': <_io.TextIOWrapper at remote 0x7ffff1b97dc0>, '__loader__': <SourceFileLoader(name='__main__', path='x.py') at remote 0x7ffff19ffa18>, '__doc__': None, '__cached__': None, '__package__': None, '__name__': '__main__', '__builtins__': <module at remote 0x7ffff1b6b358>}) at Objects/object.c:1876
#44 0x00000000004bc067 in module_dealloc (m=0x7ffff1aff7d8) at Objects/moduleobject.c:391
#45 0x00000000004c12b3 in _Py_Dealloc (op=<module at remote 0x7ffff1aff7d8>) at Objects/object.c:1876
#46 0x00000000004a9ea2 in insertdict (mp=0x7ffff1be77c8, key='__main__', hash=-7010304633138094468, value=None) at Objects/dictobject.c:818
#47 0x00000000004aafaf in PyDict_SetItem (op=
    {'_weakrefset': None, 'marshal': None, 'sysconfig': None, '_sitebuiltins': None, 'io': None, 'encodings.utf_8': None, 'sys': None, 'encodings.latin_1': None, '_sysconfigdata': None, 'encodings.aliases': None, 'os': None, 'codecs': None, 'errno': None, '_collections_abc': None, '_weakref': None, 'site': None, 'zipimport': None, 'posixpath': None, '_io': None, 'abc': None, '_locale': None, 'encodings': None, 'builtins': None, 'os.path': None, '_warnings': None, '_stat': None, '_bootlocale': None, 'signal': None, '_frozen_importlib': None, 'stat': None, '_imp': None, 'posix': None, '__main__': None, 'genericpath': <module at remote 0x7ffff1a922d8>, '_codecs': <module at remote 0x7ffff1b20b58>, '_thread': <module at remote 0x7ffff1aff658>}, key='__main__', value=None)
    at Objects/dictobject.c:1202
#48 0x00000000005c5b33 in PyImport_Cleanup () at Python/import.c:369
#49 0x000000000041dd8e in Py_Finalize () at Python/pythonrun.c:592
#50 0x0000000000439854 in Py_Main (argc=2, argv=0x95d020) at Modules/main.c:800
#51 0x0000000000419f25 in main (argc=2, argv=0x7fffffffdf28) at ./Modules/python.c:69

----------
messages: 201532
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: FileIO destructor imports indirectly the io module at exit
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Oct 28 13:56:51 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 28 Oct 2013 12:56:51 +0000
Subject: [New-bugs-announce] [issue19422] Neither DTLS nor error for
	SSLSocket.sendto() of UDP	socket
Message-ID: <1382965011.03.0.394041339056.issue19422@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Python's SSL module doesn't support DTLS (datagram TLS for UDP). The SSL code doesn't complain when an UDP socket is wrapped in a SSL socket. It happily sends the bytes unprotected and not encrypted over the wire:

>>> import ssl, socket
>>> sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
>>> ssock = ssl.wrap_socket(sock)
>>> ssock.sendto(b"data", ("localhost", 12345))
4

TCP sockets at least complain that the connection hasn't been established yet.

>>> sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> ssock = ssl.wrap_socket(sock)
>>> ssock.sendto(b"data", ("localhost", 12345))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 517, in sendto
    return socket.sendto(self, data, flags_or_addr)
BrokenPipeError: [Errno 32] Broken pipe

----------
components: Extension Modules
messages: 201535
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Neither DTLS nor error for SSLSocket.sendto() of UDP socket
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Oct 28 18:16:58 2013
From: report at bugs.python.org (Evgeny Luttsev)
Date: Mon, 28 Oct 2013 17:16:58 +0000
Subject: [New-bugs-announce] [issue19423] permutations len issue
Message-ID: <1382980618.03.0.867834998977.issue19423@psf.upfronthosting.co.za>


New submission from Evgeny Luttsev:

Code:
n = 2
perms = permutations(range(n), n)
if list(perms) == [(0, 1), (1, 0)]:
	print("==")
	print("len(list(perms)):", len(list(perms)))

Result:
==
len(list(perms)): 0 # SHOULD BE 2

----------
components: Library (Lib)
messages: 201556
nosy: DSblizzard
priority: normal
severity: normal
status: open
title: permutations len issue
type: behavior
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Mon Oct 28 18:43:22 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Oct 2013 17:43:22 +0000
Subject: [New-bugs-announce] [issue19424] _warnings: patch to avoid
	conversions from/to UTF-8
Message-ID: <1382982202.33.0.652166752386.issue19424@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch removes usage of _PyUnicode_AsString() to not convert strings from/to UTF-8.

----------
components: Unicode
files: warnings.patch
keywords: patch
messages: 201558
nosy: ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: _warnings: patch to avoid conversions from/to UTF-8
versions: Python 3.4
Added file: http://bugs.python.org/file32395/warnings.patch

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

From report at bugs.python.org  Mon Oct 28 21:53:20 2013
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 28 Oct 2013 20:53:20 +0000
Subject: [New-bugs-announce] [issue19425] multiprocessing.Pool.map hangs if
	pickling argument	raises an exception
Message-ID: <1382993600.07.0.457043884455.issue19425@psf.upfronthosting.co.za>


New submission from Nadeem Vawda:

[Split off from issue 19395]

The following code hangs after hitting a TypeError trying to pickle one
of the TextIOWrapper objects:

    import multiprocessing

    def read(f): return f.read()

    files = [open(path) for path in 3 * ['/dev/null']]
    pool = multiprocessing.Pool()
    results = pool.map(read, files)
    print(results)

This issue is present in 3.2, 3.3 and 3.4, but not in 2.7.

----------
components: Library (Lib)
messages: 201580
nosy: cantor, jnoller, nadeem.vawda, pitrou, python-dev, sbt, tim.peters
priority: normal
severity: normal
stage: needs patch
status: open
title: multiprocessing.Pool.map hangs if pickling argument raises an exception
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Oct 28 23:29:31 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 28 Oct 2013 22:29:31 +0000
Subject: [New-bugs-announce] [issue19426] Opening a file in IDLE causes a
	crash or hang
Message-ID: <1382999371.02.0.697524502707.issue19426@psf.upfronthosting.co.za>


New submission from Ned Deily:

Using current IDLE in 2.7 tip (as in 2.7.6rc1), selecting a file to open in the IDLE menu or on the command line cause IDLE to either (depending on the platform and invocation) crash or hang due to an uncaught exception in idlelib/IOBinding.py:

/usr/local/bin/idle2.7 a.py
Exception in Tkinter callback
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/Tkinter.py", line 1470, in __call__
    return self.func(*args)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/IOBinding.py", line 222, in open
    flist.open(filename)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/FileList.py", line 36, in open
    return self.EditorWindow(self, filename, key)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/PyShell.py", line 131, in __init__
    EditorWindow.__init__(self, *args)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 323, in __init__
    io.loadfile(filename)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/IOBinding.py", line 258, in loadfile
    chars = self.decode(chars)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/IOBinding.py", line 296, in decode
    enc = coding_spec(chars)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/IOBinding.py", line 129, in coding_spec
    for line in lst:
NameError: global name 'lst' is not defined

The culprit is 3d46ef0c62c5 for Issue18873 which did a faulty backport of a change from the 3.x branches.

----------
assignee: serhiy.storchaka
components: IDLE
messages: 201586
nosy: benjamin.peterson, ned.deily, serhiy.storchaka
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Opening a file in IDLE causes a crash or hang
versions: Python 2.7

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

From report at bugs.python.org  Tue Oct 29 00:16:08 2013
From: report at bugs.python.org (Richard Neill)
Date: Mon, 28 Oct 2013 23:16:08 +0000
Subject: [New-bugs-announce] [issue19427] enhancement: dictionary maths
Message-ID: <1383002168.86.0.538679547353.issue19427@psf.upfronthosting.co.za>


New submission from Richard Neill:

It would be really nice if python supported mathematical operations on dictionaries. This is widely requested (eg lots of stackoverflow queries), but there's currently no simple way to do it.

I propose that this should work in the "obvious" way, i.e. for every key in common between the dicts, apply the operator to the set of values.  If the dicts have some keys that are not in common, then create the missing keys, with a value of zero (which does sensible things for +,-,* and will throw an error if missing element is a divisor). 

It should also allow a dict to be added/multiplied etc with a scalar.

If the dict contains anything other than key:value pairs (i.e. the values are non-scalar types), then this should throw an error.

For example:

>>> d1 = { 'a':1, 'b':2, 'c':3}
>>> d2 = { 'a':4, 'b':5, 'c':6}
>>> d3 = d1 + d2
>>> d3
{'a': 5, 'b': 7, 'c': 9}

>>> d4 = d1 + 17
>>> d4 
{'a': 18, 'b': 19, 'c': 20}

>>> d5 = { 'a':4, 'b':5, 'x':6}
>>> d6 = d1 + d5
>>> d6
{'a': 5, 'b': 7, 'c': 3, 'x': 6}

Perhaps this might need an "import dictionarymath" to enable the behaviour.

Thanks for your consideration of my idea.

----------
components: Interpreter Core
messages: 201587
nosy: Richard.Neill
priority: normal
severity: normal
status: open
title: enhancement: dictionary maths
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Oct 29 01:41:28 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Oct 2013 00:41:28 +0000
Subject: [New-bugs-announce] [issue19428] marshal: error cases are not
	documented
Message-ID: <1383007288.06.0.856513082934.issue19428@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Since changeset 4059e871e74e (issue #19219), it becomes more clear in the source code that reading data from marshal can fail. It was already true in Python 3.3, but less explicit.

Failures are not documented in Doc/c-api/marshal.rst.

Failures are not tested in zipimport.c, maybe also in other files.

----------
messages: 201595
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: marshal: error cases are not documented
versions: Python 3.4

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

From report at bugs.python.org  Tue Oct 29 02:43:26 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Oct 2013 01:43:26 +0000
Subject: [New-bugs-announce] [issue19429] OSError constructor does not
	handle errors correctly
Message-ID: <1383011006.26.0.841503225462.issue19429@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Using failmalloc project to inject MemoryError, I found a reference counter issue in OSError constructor. args parameter passed to OSError_new() becomes invalid when OSError constructor fails.

I don't yet where is the bug exactly.


Traces when the bug occurs in test_urllib:

(gdb) where
...
#2  0x0000000000423f80 in Py_FatalError (msg=0x7ffffffd68e0 "Python/ceval.c:4456 object at 0x7fffed6c4ef8 has negative ref count -1")
    at Python/pythonrun.c:2531
#3  0x00000000004bd47f in _Py_NegativeRefcount (fname=0x686618 "Python/ceval.c", lineno=4456, op=(((0x0,),),)) at Objects/object.c:197
#4  0x00000000005a544d in do_call (func=<type at remote 0xcb0588>, pp_stack=0x7ffffffd6ba8, na=1, nk=0) at Python/ceval.c:4456
#5  0x00000000005a4624 in call_function (pp_stack=0x7ffffffd6ba8, oparg=1) at Python/ceval.c:4252
#6  0x000000000059c96e in PyEval_EvalFrameEx (f=
...

(gdb) frame 4
#4  0x00000000005a544d in do_call (func=<type at remote 0xcb0588>, pp_stack=0x7ffffffd6ba8, na=1, nk=0) at Python/ceval.c:4456
4456	    Py_XDECREF(callargs);
(gdb) print callargs
$12 = (((0x0,),),)

(gdb) print _PyObject_Dump(func)
object  : <class 'urllib.error.URLError'>
type    : type
refcount: 16
address : 0xcb0728
$10 = void

----------
messages: 201598
nosy: haypo
priority: normal
severity: normal
status: open
title: OSError constructor does not handle errors correctly
versions: Python 3.4

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

From report at bugs.python.org  Tue Oct 29 10:43:13 2013
From: report at bugs.python.org (telmich)
Date: Tue, 29 Oct 2013 09:43:13 +0000
Subject: [New-bugs-announce] [issue19430] argparse replaces \$ to is passed
Message-ID: <1383039793.25.0.714624843985.issue19430@psf.upfronthosting.co.za>


New submission from telmich:

When using argparse and the string \$ occurs on the commandline, it is converted to $. This as definitely wrong and renders argparse useless, if the input needs to be trusted (i.e. defitinely the same as given into it)'

Example code:

import sys 
import argparse

parser = argparse.ArgumentParser()
parser.add_argument('test', nargs='*')
result = parser.parse_args(sys.argv[1:])

print("args = %s" % " ".join(sys.argv))
print("result = %s" % result)

Reproduce problem:

[10:41] bento:~% python3 argparse-test.py ps1  "PS1='[\t] \[\033[1m\]\h\[\033[0m\]:\w\$ '"
] \[\]\h\[\]:\w\$ '"args = argparse-test.py ps1 PS1='[\t] \[\033[1m\]\h\[\033[0m\]:\w$ '
result = Namespace(test=['ps1', "PS1='[\\t] \\[\\033[1m\\]\\h\\[\\033[0m\\]:\\w$ '"])

[10:40] bento:cdist% python --version
Python 3.3.2

----------
components: Library (Lib)
messages: 201614
nosy: telmich
priority: normal
severity: normal
status: open
title: argparse replaces  \$ to is passed
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Oct 29 10:55:35 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Oct 2013 09:55:35 +0000
Subject: [New-bugs-announce] [issue19431] Document PyFrame_FastToLocals()
	and	PyFrame_FastToLocalsWithError()
Message-ID: <1383040535.91.0.284405039579.issue19431@psf.upfronthosting.co.za>


New submission from STINNER Victor:

(Copy of an email) Georg Brandl via python.org 
	
Am 29.10.2013 01:19, schrieb victor.stinner:
> http://hg.python.org/cpython/rev/4ef4578db38a
> changeset:   86715:4ef4578db38a
> user:        Victor Stinner <victor.stinner at gmail.com>
> date:        Tue Oct 29 01:19:37 2013 +0100
> summary:
>   Issue #18408: Add a new PyFrame_FastToLocalsWithError() function to handle
> exceptions when merging fast locals into f_locals of a frame.
> PyEval_GetLocals() now raises an exception and return NULL on failure.

You'll have to either make this private or document it.

----------
assignee: docs at python
components: Documentation
messages: 201618
nosy: docs at python, georg.brandl, haypo, pitrou
priority: normal
severity: normal
status: open
title: Document PyFrame_FastToLocals() and PyFrame_FastToLocalsWithError()
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Oct 29 13:00:44 2013
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 29 Oct 2013 12:00:44 +0000
Subject: [New-bugs-announce] [issue19432] test_multiprocessing_fork failures
Message-ID: <1383048044.1.0.269867620739.issue19432@psf.upfronthosting.co.za>


New submission from Stefan Krah:

I'm getting the following test_multiprocessing_fork failures on Debian
Wheezy.  Perhaps this is related to #19227:


test_default_timeout (test.test_multiprocessing_fork.WithThreadsTestBarrier) ... Exception in thread Thread-344:
Traceback (most recent call last):
  File "/home/stefan/hg/master3/Lib/threading.py", line 921, in _bootstrap_inner
    self.run()
  File "/home/stefan/hg/master3/Lib/threading.py", line 869, in run
    self._target(*self._args, **self._kwargs)
  File "/home/stefan/hg/master3/Lib/test/_test_multiprocessing.py", line 1152, in task
    self.f(*self.args)
  File "/home/stefan/hg/master3/Lib/test/_test_multiprocessing.py", line 1382, in _test_default_timeout_f
    barrier.wait()
  File "/home/stefan/hg/master3/Lib/threading.py", line 616, in wait
    self._wait(timeout)
  File "/home/stefan/hg/master3/Lib/threading.py", line 653, in _wait
    self._break()
  File "/home/stefan/hg/master3/Lib/threading.py", line 702, in _break
    self._cond.notify_all()
  File "/home/stefan/hg/master3/Lib/threading.py", line 359, in notify_all
    self.notify(len(self._waiters))
  File "/home/stefan/hg/master3/Lib/threading.py", line 342, in notify
    waiters_to_notify = _deque(_islice(all_waiters, n))
RuntimeError: deque mutated during iteration

FAIL


======================================================================
FAIL: test_default_timeout (test.test_multiprocessing_fork.WithThreadsTestBarrier)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/stefan/hg/master3/Lib/test/_test_multiprocessing.py", line 1393, in test_default_timeout
    self.assertEqual(len(results), barrier.parties)
AssertionError: 4 != 5

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

----------
messages: 201624
nosy: skrah
priority: normal
severity: normal
status: open
title: test_multiprocessing_fork failures

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

From report at bugs.python.org  Tue Oct 29 14:50:22 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 29 Oct 2013 13:50:22 +0000
Subject: [New-bugs-announce] [issue19433] Define PY_UINT64_T on Windows 32bit
Message-ID: <1383054622.8.0.294038814234.issue19433@psf.upfronthosting.co.za>


New submission from Christian Heimes:

For PEP 456 it would be useful to have PY_UINT64_T on 32bit Windows. Does anybody see a problem with Victor's idea? I like it.

Victor wrote in http://bugs.python.org/issue19183#msg201629:

To support Windows 32 bit, the following code in PC/pyconfig.h can be modified to use __int64 or _W64: see ssize_t definition below in the same file.

#ifndef PY_UINT64_T
#if SIZEOF_LONG_LONG == 8
#define HAVE_UINT64_T 1
#define PY_UINT64_T unsigned PY_LONG_LONG
#endif
#endif

----------
components: Interpreter Core, Windows
messages: 201635
nosy: brian.curtin, christian.heimes, haypo, loewis, ncoghlan, tim.golden
priority: normal
severity: normal
stage: needs patch
status: open
title: Define PY_UINT64_T on Windows 32bit
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Oct 29 16:51:30 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 29 Oct 2013 15:51:30 +0000
Subject: [New-bugs-announce] [issue19434] Wrong documentation of
	MIMENonMultipart class
Message-ID: <1383061890.83.0.167475194564.issue19434@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

>>> from email.mime.nonmultipart import MIMENonMultipart
>>> MIMENonMultipart.__doc__
'Base class for MIME multipart/* type messages.'
>>>

Attached the patch to fix the doc of MIMENonMultipart class.

----------
assignee: docs at python
components: Documentation
files: fix_doc_for_mime_non_multipart.patch
keywords: patch
messages: 201643
nosy: docs at python, r.david.murray, vajrasky
priority: normal
severity: normal
status: open
title: Wrong documentation of MIMENonMultipart class
versions: Python 3.4
Added file: http://bugs.python.org/file32410/fix_doc_for_mime_non_multipart.patch

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

From report at bugs.python.org  Tue Oct 29 17:34:01 2013
From: report at bugs.python.org (Alexander Kruppa)
Date: Tue, 29 Oct 2013 16:34:01 +0000
Subject: [New-bugs-announce] [issue19435] Directory traversal attack for
	CGIHTTPRequestHandler
Message-ID: <1383064441.57.0.197155402259.issue19435@psf.upfronthosting.co.za>


New submission from Alexander Kruppa:

An error in separating the path and filename of the CGI script to run in http.server.CGIHTTPRequestHandler allows running arbitrary executables in the directory under which the server was started.

The problem is that in CGIHTTPRequestHandler we have:

  def run_cgi(self):    
      """Execute a CGI script."""    
      path = self.path    
      dir, rest = self.cgi_info    
  
      i = path.find('/', len(dir) + 1)    

where path is the uncollapsed path in the URL, but cgi_info contains the first path segment and the rest from the *collapsed* path as filled in by is_cgi(), so indexing into path via len(dir) is incorrect.

An example exploit is giving the request path:

///////////badscript.sh/../cgi-bin/cgi.sh

Note that Firefox and wget at least simplify the path in the request; to make sure this exact path is used, do for example:

  (echo "GET ///////////badscript.sh/../cgi-bin/cgi.sh HTTP/1.1"; echo) | telnet localhost 4443

This causes the CGIHTTPRequestHandler to execute the badscript.sh file in the directory in which the server was started, so script execution is not restricted to the cgi-bin/ or htbin/ subdirectories.

----------
components: Library (Lib)
messages: 201645
nosy: Alexander.Kruppa
priority: normal
severity: normal
status: open
title: Directory traversal attack for CGIHTTPRequestHandler
type: security
versions: Python 3.2

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

From report at bugs.python.org  Tue Oct 29 17:46:58 2013
From: report at bugs.python.org (lagoon7)
Date: Tue, 29 Oct 2013 16:46:58 +0000
Subject: [New-bugs-announce] [issue19436] Python 2.7 on MAC OSX Mavericks
	crashes on the	help('modules') command
Message-ID: <1383065218.44.0.057777022242.issue19436@psf.upfronthosting.co.za>


New submission from lagoon7:

/usr/lib/python2.7/dist-packages/gobject/constants.py:24: Warning: g_boxed_type_register_static: assertion `g_type_from_name (name) == 0' failed
  import gobject._gobject
/usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:40: Warning: g_boxed_type_register_static: assertion `g_type_from_name (name) == 0' failed
  from gtk import _gtk

** (python:23199): CRITICAL **: pyg_register_boxed: assertion `boxed_type != 0' failed
/usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:40: Warning: cannot register existing type `GdkDevice'
  from gtk import _gtk
/usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:40: Warning: g_type_get_qdata: assertion `node != NULL' failed
  from gtk import _gtk
Segmentation fault (core dumped)

----------
assignee: ronaldoussoren
components: Macintosh
messages: 201646
nosy: lagoon7, ronaldoussoren
priority: normal
severity: normal
status: open
title: Python 2.7 on MAC OSX Mavericks crashes on the help('modules') command
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Tue Oct 29 19:24:07 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Oct 2013 18:24:07 +0000
Subject: [New-bugs-announce] [issue19437] More failures found by pyfailmalloc
Message-ID: <1383071047.38.0.937526854844.issue19437@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Using pyfailamlloc, I found various bugs: see issue #18048. Because this issue has been closed, I'm opening a new issue for new bugs.

https://bitbucket.org/haypo/pyfailmalloc

----------
messages: 201649
nosy: haypo
priority: normal
severity: normal
status: open
title: More failures found by pyfailmalloc
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Tue Oct 29 21:31:31 2013
From: report at bugs.python.org (mpb)
Date: Tue, 29 Oct 2013 20:31:31 +0000
Subject: [New-bugs-announce] [issue19438] Where is NoneType in Python 3?
Message-ID: <1383078691.36.0.6145513581.issue19438@psf.upfronthosting.co.za>


New submission from mpb:

types.NoneType seems to have disappeared in Python 3.  This is probably intentional, but I cannot figure out how to test if a variable is of type NoneType in Python 3.

Specifically, I want to write:
assert  type (v) in ( bytes, types.NoneType )

Yes, I could write:
assert  v is None or type (v) is bytes

But the first assert statement is easier to read (IMO).

Here are links to various Python 3 documentation about None:

[1] http://docs.python.org/3/library/stdtypes.html#index-2

[2] http://docs.python.org/3/library/constants.html#None

Link [2] says: "None  The sole value of the type NoneType."  However, NoneType is not listed in the Python 3 documentation index.  (As compared with the Python 2 index, where NoneType is listed.)

[3] http://docs.python.org/3/library/types.html

If NoneType is gone in Python 3, mention of NoneType should probably be removed from link [2].  If NoneType is present in Python 3, the docs (presumably at least one of the above links, and hopefully also the index) should tell me how to use it.

Here is another link:

[4] http://docs.python.org/3/library/stdtypes.html#bltin-type-objects

"The standard module types defines names for all standard built-in types."  (Except <class 'NoneType'> ???)

None is a built-in constant.  It has a type.  If None's type is not considered to be a "standard built-in type", then IMO this is surprising(!!) and should be documented somewhere (for example, at link [4], and possibly elsewhere as well.)

Thanks!

----------
assignee: docs at python
components: Documentation
messages: 201666
nosy: docs at python, mpb
priority: normal
severity: normal
status: open
title: Where is NoneType in Python 3?
versions: Python 3.3

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

From report at bugs.python.org  Tue Oct 29 21:58:13 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 29 Oct 2013 20:58:13 +0000
Subject: [New-bugs-announce] [issue19439] Build _testembed on Windows
Message-ID: <1383080293.2.0.31204430631.issue19439@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Here's a patch that builds _testembed on Windows and adjusts test_capi to not skip EmbeddingTests on Windows.  The .vcxproj is based on _freeze_importlib, with "when to build" settings lifted from _testimportmultiple.

The patch also adjusts test_capi.EmbeddingTests.test_forced_io_encoding such that it doesn't blow up completely on Windows (and should still pass anywhere it does currently, though I haven't been able to test anywhere but on Windows yet).  The test still fails, though; here's the relevant output I get:

"""
======================================================================
FAIL: test_forced_io_encoding (test.test_capi.EmbeddingTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "P:\Projects\OSS\Python\_cpython\lib\test\test_capi.py", line 298, in test_forced_io_encoding
    self.assertEqual(out.strip(), expected_output)
AssertionError: '--- [106 chars]t: cp1252:strict\r\nstderr: cp1252:backslashre[575 chars]lace' != '--- [106 chars]t: cp437:strict\r\nstderr:
 cp437:backslashrepl[571 chars]lace'
  --- Use defaults ---
  Expected encoding: default
  Expected errors: default
  stdin: cp437:strict
- stdout: cp1252:strict
?           ^^^^
+ stdout: cp437:strict
?           ^^^
- stderr: cp1252:backslashreplace
?           ^^^^
+ stderr: cp437:backslashreplace
?           ^^^
  --- Set errors only ---
  Expected encoding: default
  Expected errors: surrogateescape
  stdin: cp437:surrogateescape
- stdout: cp1252:surrogateescape
?           ^^^^
+ stdout: cp437:surrogateescape
?           ^^^
- stderr: cp1252:backslashreplace
?           ^^^^
+ stderr: cp437:backslashreplace
?           ^^^
  --- Set encoding only ---
  Expected encoding: latin-1
  Expected errors: default
  stdin: latin-1:strict
  stdout: latin-1:strict
  stderr: latin-1:backslashreplace
  --- Set encoding and errors ---
  Expected encoding: latin-1
  Expected errors: surrogateescape
  stdin: latin-1:surrogateescape
  stdout: latin-1:surrogateescape
  stderr: latin-1:backslashreplace

----------------------------------------------------------------------
"""

I'm not sure whether this is a bug in the way _testembed is built or otherwise.  EmbeddingTests.test_subinterps passes, though.

Due to my ongoing inability to get a 64-bit build to work, this has only been tested on 32-bit Windows 7.

----------
components: Tests, Windows
files: windows_testembed.diff
keywords: patch
messages: 201671
nosy: brian.curtin, loewis, ncoghlan, pitrou, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Build _testembed on Windows
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32412/windows_testembed.diff

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

From report at bugs.python.org  Tue Oct 29 22:21:52 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 29 Oct 2013 21:21:52 +0000
Subject: [New-bugs-announce] [issue19440] Clean up test_capi
Message-ID: <1383081712.17.0.162713378456.issue19440@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Here's a patch to clean up test_capi a little bit; it removes a __future__ import, converts from test_main to unittest.main, and makes use of subtests to run each _testcapi function.

I'll post a separate patch for 3.3; there's just enough difference between branches to make a single patch impossible and merging slightly hairy.

----------
components: Tests
files: test_capi_cleanup.diff
keywords: patch
messages: 201676
nosy: ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Clean up test_capi
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32415/test_capi_cleanup.diff

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

From report at bugs.python.org  Tue Oct 29 23:55:33 2013
From: report at bugs.python.org (Alan Cristhian)
Date: Tue, 29 Oct 2013 22:55:33 +0000
Subject: [New-bugs-announce] [issue19441] itertools.tee improve documentation
Message-ID: <1383087333.66.0.191656186181.issue19441@psf.upfronthosting.co.za>


New submission from Alan Cristhian:

I had some problems using itertools.tee function. Fortunately I found the following advice on the PEP-323:

"Currently, the copied iterators remaintied to the original iterator. If the original advances, then so do all of the copies. Good practice is to overwrite the original So THAT anamolies do result: a, b = t (a)."

I believe that such advice should be in the documentation as well:

"Currently, the copied iterators remaintied to the original iterator. If the original advances, then so do all of the copies and vice versa. Good practice is to overwrite the original So THAT anamolies do result: a, b = t (a ). "

Note that I added "and vice versa".

----------
assignee: docs at python
components: Documentation
messages: 201693
nosy: Alan.Cristhian, docs at python
priority: normal
severity: normal
status: open
title: itertools.tee improve documentation
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Wed Oct 30 00:31:53 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Oct 2013 23:31:53 +0000
Subject: [New-bugs-announce] [issue19442] Python crashs when a warning is
	emitted during shutdown
Message-ID: <1383089513.19.0.894432052121.issue19442@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Because of a bug, warnings were not emitted during Python shutdown. I fixed the bug in issue #19424, and now Python crashs when a warning is emitted during shutdown.

See also issue #19421: "FileIO destructor imports indirectly the io module at exit".

The warnings module uses globals()['__name__'] to get the name of the current module. The bug was the during Python shutdown, the module is None and _PyUnicode_AsString(None) was raising an exception (in setup_context() of _warnings.c) and so the warning was not emitted. For example, FileIO destructor emits a warning when a unclosed file is destroyed. The destructor removes the exception raised the warning module.

----------
messages: 201695
nosy: haypo
priority: normal
severity: normal
status: open
title: Python crashs when a warning is emitted during shutdown
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Wed Oct 30 05:43:03 2013
From: report at bugs.python.org (Milton Mobley)
Date: Wed, 30 Oct 2013 04:43:03 +0000
Subject: [New-bugs-announce] [issue19443] add to dict fails after 1, 000,
	000 items on py 2.7.5
Message-ID: <1383108183.39.0.692249653807.issue19443@psf.upfronthosting.co.za>


New submission from Milton Mobley:

d, i = {}, 0
while (i < 10000000):
    n =  i + 1
    d[n] = n
    i += 1

On Py 2.7.5 (windows7, x64, 4GB ram) this program slowed down obviously after passing 1,000,000 adds and never completed or raised an exception.
Windows performance monitor showed it was only claiming about 1 MB memory per second, and stopped claiming more memory at about 646MB. The only other large memory consumer in the system was JRE using about 550 MB on behalf of Eclipse.

----------
components: Interpreter Core
messages: 201705
nosy: miltmobley
priority: normal
severity: normal
status: open
title: add to dict fails after 1,000,000 items on py 2.7.5
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Oct 30 06:19:09 2013
From: report at bugs.python.org (Robert Merrill)
Date: Wed, 30 Oct 2013 05:19:09 +0000
Subject: [New-bugs-announce] [issue19444] mmap.mmap() allocates a file
	descriptor that isn't	CLOEXEC
Message-ID: <1383110349.25.0.857290073089.issue19444@psf.upfronthosting.co.za>


New submission from Robert Merrill:

Same code but different problem as this issue: http://bugs.python.org/issue10897

The above-linked issue was closed as WONTFIX, but there is a secondary problem: the file descriptor that mmap.mmap() allocates is not set to close-on-exec.

This means that any process you spawn using os.system() and the like, its children, its children's children etc will inherit this file descriptor.

This is unexpected, unnecessary behavior, and potentially a huge pain if you mmap() a file and then spawn, say, inetd or something that does similar stuff, because now you have to kill every process that spawned from that in order to unmount filesystems or remove kernel modules that are being blocked as a result of the fds being open.

----------
components: Library (Lib)
messages: 201709
nosy: rfm
priority: normal
severity: normal
status: open
title: mmap.mmap() allocates a file descriptor that isn't CLOEXEC
type: resource usage
versions: Python 2.7

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

From report at bugs.python.org  Wed Oct 30 07:01:21 2013
From: report at bugs.python.org (Blaise Gassend)
Date: Wed, 30 Oct 2013 06:01:21 +0000
Subject: [New-bugs-announce] [issue19445] heapq.heapify is n log(n),
	not linear
Message-ID: <1383112881.24.0.0958145237124.issue19445@psf.upfronthosting.co.za>


New submission from Blaise Gassend:

The documentation for heapq.heapify indicates that it runs in linear time. I believe that this is incorrect, and that it runs in worst case n * log(n) time. I checked the implementation, and there are indeed n _siftup operations, which each appear to be worst case log(n).

One example of the documentation pages that are wrong.
http://docs.python.org/3.4/library/heapq.html#heapq.heappush

----------
assignee: docs at python
components: Documentation
messages: 201712
nosy: Blaise.Gassend, docs at python
priority: normal
severity: normal
status: open
title: heapq.heapify is n log(n), not linear
versions: Python 2.6, 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/issue19445>
_______________________________________

From report at bugs.python.org  Wed Oct 30 08:18:16 2013
From: report at bugs.python.org (Nitin Kumar)
Date: Wed, 30 Oct 2013 07:18:16 +0000
Subject: [New-bugs-announce] [issue19446] Integer division for negative
	numbers
Message-ID: <1383117496.94.0.70226236706.issue19446@psf.upfronthosting.co.za>


New submission from Nitin Kumar:

Mathematically python is not giving correct output for integer division for negative number, e.g. :  -7//2= -3 but python is giving output -4.

----------
components: IDLE
files: Integer_division.py
messages: 201715
nosy: Nitin.Kumar
priority: normal
severity: normal
status: open
title: Integer division for negative numbers
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file32420/Integer_division.py

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

From report at bugs.python.org  Wed Oct 30 10:42:07 2013
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Wed, 30 Oct 2013 09:42:07 +0000
Subject: [New-bugs-announce] [issue19447] py_compile.compile raises if a
	file has bad encoding
Message-ID: <1383126127.06.0.0829407086057.issue19447@psf.upfronthosting.co.za>


New submission from Bohuslav "Slavek" Kabrda:

If py_compile.compile is used on a file with bad encoding (e.g. Lib/test/bad_coding2.py), the function raises even if doraise=False is passed. I'm attaching a patch that fixes this in 3.3 - I haven't tried on 3.4 yet and the code has changed, so I'm not sure it's problem there.

(Background: During RPM build of Python 3 in Fedora, we use py_compile.compile to make sure all files are properly compiled and have newer timestamps. We use 'find' to get all *.py files under 'python3.3/' and then xargs to pass the files to Python script that compiles them. If one of the files causes py_compile.compile to raise, the rest doesn't get compiled.)

----------
components: Build
files: 00186-dont-raise-from-py_compile.patch
keywords: patch
messages: 201721
nosy: bkabrda
priority: normal
severity: normal
status: open
title: py_compile.compile raises if a file has bad encoding
versions: Python 3.3
Added file: http://bugs.python.org/file32422/00186-dont-raise-from-py_compile.patch

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

From report at bugs.python.org  Wed Oct 30 10:55:08 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 30 Oct 2013 09:55:08 +0000
Subject: [New-bugs-announce] [issue19448] SSL: add OID / NID lookup
Message-ID: <1383126908.52.0.345026933499.issue19448@psf.upfronthosting.co.za>


New submission from Christian Heimes:

For #17134 I need a decent way to map OIDs to human readable strings and vice versa. OpenSSL has a couple of method for the task, e.g. http://www.openssl.org/docs/crypto/OBJ_nid2obj.html

The patch implements three ways to lookup NID, SN, LN and OID: by OpenSSL's internal numeric id (NID), by OID or by name:

>>> ssl.txt2obj("MD5", name=True)
ASN1Object(nid=4, shortname='MD5', longname='md5', oid='1.2.840.113549.2.5')
>>> ssl.txt2obj("clientAuth", name=True)
ASN1Object(nid=130, shortname='clientAuth', longname='TLS Web Client Authentication', oid='1.3.6.1.5.5.7.3.2')
>>> ssl.txt2obj("1.3.6.1.5.5.7.3.1")
ASN1Object(nid=129, shortname='serverAuth', longname='TLS Web Server Authentication', oid='1.3.6.1.5.5.7.3.1')

----------
files: ssl_asn1obj.patch
keywords: patch
messages: 201724
nosy: christian.heimes, giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: SSL: add OID / NID lookup
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32423/ssl_asn1obj.patch

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

From report at bugs.python.org  Wed Oct 30 11:59:32 2013
From: report at bugs.python.org (Tomas Grahn)
Date: Wed, 30 Oct 2013 10:59:32 +0000
Subject: [New-bugs-announce] [issue19449] csv.DictWriter can't handle extra
	non-string fields
Message-ID: <1383130772.27.0.178945173135.issue19449@psf.upfronthosting.co.za>


New submission from Tomas Grahn:

When csv.DictWriter.writerow is fed a dict with extra fieldnames (and extrasaction='raise') and any of those extra fieldnames aren't strings, a TypeError-exception is thrown. To fix the issue; in csv.py, edit the line:
raise ValueError("dict contains fields not in fieldnames: " + ", ".join(wrong_fields))

to:
raise ValueError("dict contains fields not in fieldnames: " + ", ".join(repr(wrong_field) for wrong_field in wrong_fields))

Attached is a patch that fixes the problem (works in both 2.6 and 2.7, I haven't tried anything else).

Here is a simple test to demonstrate the problem:

import cStringIO, csv

sio=cStringIO.StringIO()
writer=csv.DictWriter(sio, ["foo", "bar"])
writer.writerow({1:"hello", 2:"world"})

----------
files: csv-patch.diff
keywords: patch
messages: 201727
nosy: tomas_grahn
priority: normal
severity: normal
status: open
title: csv.DictWriter can't handle extra non-string fields
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file32425/csv-patch.diff

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

From report at bugs.python.org  Wed Oct 30 12:12:38 2013
From: report at bugs.python.org (Marc Schlaich)
Date: Wed, 30 Oct 2013 11:12:38 +0000
Subject: [New-bugs-announce] [issue19450] Bug in sqlite in Windows binaries
Message-ID: <1383131558.55.0.853606379194.issue19450@psf.upfronthosting.co.za>


New submission from Marc Schlaich:

My System:

$ python
Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> sqlite3.version
'2.6.0'
>>> sqlite3.sqlite_version
'3.6.21'

Test Script:

import sqlite3
conn = sqlite3.connect(':memory:')
conn.execute('PRAGMA foreign_keys = ON')
fk = (conn.execute("PRAGMA foreign_keys").fetchone()[0])
print 'version = %s, foreign keys = %r' % (sqlite3.sqlite_version, bool(fk))
if not fk:
  raise Exception('No foreign keys!?')

c = conn.cursor()
c.executescript('''
create table if not exists main.one (resource_id TEXT PRIMARY KEY, data TEXT);
create table if not exists main.two (node_id INTEGER PRIMARY KEY, data TEXT);
create table if not exists main.mapping (node_id INTEGER REFERENCES two, resource_id TEXT REFERENCES one);
insert into main.one(resource_id, data) values('A', 'A one thing');
insert into main.two(node_id, data) values(1, 'A two thing');
insert into main.mapping(resource_id, node_id) values('A', 1);
insert into main.one(resource_id, data) values('B', 'Another one thing');
insert into main.two(node_id, data) values(2, 'Another two thing');
insert into main.mapping(resource_id, node_id) values('B', 2);
insert into main.one(resource_id, data) values('C', 'Yet another one thing');
''')
for tbl in 'one', 'two', 'mapping':
  print 'TABLE main.%s:\n%s\n' % (tbl, '\n'.join(repr(r) for r in c.execute('select * from main.%s' % tbl).fetchall()))

del_cmd = """delete from main.one where resource_id='B'"""
print 'Attempting: %s' % (del_cmd,)
try:
  c.execute(del_cmd)
except Exception, e:
  print 'Failed to delete: %s' % e

cmd = """delete from main.one where resource_id='C'"""
print 'Attempting: %s' % (cmd,)
c.execute(cmd)

cmd = """delete from main.mapping where resource_id='B' AND node_id=2"""
print '\nAttempting: %s' % (cmd,)
c.execute(cmd)

for tbl in 'one', 'two', 'mapping':
  print 'TABLE main.%s:\n%s\n' % (tbl, '\n'.join(repr(r) for r in c.execute('select * from main.%s' % tbl).fetchall()))

print 'Attempting: %s' % (del_cmd,)
c.execute(del_cmd)


This fails with "sqlite3.IntegrityError: foreign key constraint failed".  Original report comes from SO: http://stackoverflow.com/questions/9342763/sqlite3-foreign-keys-remembered 

The proposed solution (to upgrade sqlite) is not possible on Windows as it comes bundled with Python. 
So please update the bundled sqlite version where this bug is solved.

----------
components: Extension Modules
messages: 201728
nosy: schlamar
priority: normal
severity: normal
status: open
title: Bug in sqlite in Windows binaries
versions: Python 2.7

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

From report at bugs.python.org  Wed Oct 30 14:16:02 2013
From: report at bugs.python.org (Daniele Sluijters)
Date: Wed, 30 Oct 2013 13:16:02 +0000
Subject: [New-bugs-announce] [issue19451] urlparse accepts invalid hostnames
Message-ID: <1383138962.68.0.105445419369.issue19451@psf.upfronthosting.co.za>


New submission from Daniele Sluijters:

Python 2's urlparse.urlparse() and Python 3's urllib.parse.urlparse() accept URI/URL's with underscores in the host/domain/subdomain. I believe this behaviour to be incorrect.

A distinction needs to be made between DNS names and Uniform Resource Locators and Identifiers, urlparse is supposed to deal with the latter (correct me if I'm wrong).

According to RFC 2181 section 11 on the syntax of DNS names the use of the underscore is allowed and in use around the internet, especially in TXT and SRV records.

However, RFC 1738 on Uniform Resource Locators section 3.1 (and its updates) always define the 'hostname' part of the URL as being:
Such a name consists of a sequence of domain labels separated by ".",
each domain label starting and ending with an alphanumeric character
and possibly also containing "-" characters.

On top of that, RFC 2396 on URI's section 3.2.2:
Hostnames take the form described in Section 3 of [RFC1034] and
Section 2.1 of [RFC1123]: a sequence of domain labels separated by
".", each domain label starting and ending with an alphanumeric
character and possibly also containing "-" characters.  

The underscore is never mentioned as being a valid character nor do any of the references in the RFC's as far as I've been able to see. 

Languages implementations vary:
 * Ruby URI.parse does not allow for underscores in domain labels.
 * Perl URI and URI::URL allow for underscores.
 * java.net.uri treats the underscore as an illegal character in the domain part.
 * org.apache.http.httphost since 4.2.3 treats the underscore as an illegal character in the domain part.

Httpd's:
 * Apache: Seems to tolerate underscores but there's been a whole discussion about this on the mailing lists.
 * nginx: Matches a server_name of '_' to 'any invalid domain name'. It seems to accept server_names with underscores in them but the behaviour is currently unknown to me.

Browsers:
 * IE cannot write cookies since IE 5.5 if host or subdomain part includes an underscore.
 * Just about every other browser is fine with it.

Please note that I'm only talking about the host/domain/subdomain part of URI's and URL's, something like http://en.wikipedia.org/wiki/12-hour_clock is perfectly valid and should parse.

----------
components: Library (Lib)
messages: 201730
nosy: daenney, orsenthil
priority: normal
severity: normal
status: open
title: urlparse accepts invalid hostnames
type: behavior
versions: Python 2.6, 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/issue19451>
_______________________________________

From report at bugs.python.org  Wed Oct 30 14:57:26 2013
From: report at bugs.python.org (Peter Harris)
Date: Wed, 30 Oct 2013 13:57:26 +0000
Subject: [New-bugs-announce] [issue19452] ElementTree iterparse documentation
Message-ID: <1383141446.52.0.417040462191.issue19452@psf.upfronthosting.co.za>


New submission from Peter Harris:

Documentation on python website says:

    xml.etree.ElementTree.iterparse(source, events=None, parser=None)
Parses an XML section into an element tree incrementally, and reports what?s going on to the user. source is a filename or file object containing XML data. events is a list of events to report back.

But 'events' must be a *tuple* or iterparse raises "TypeError: invalid event tuple"

Possibly also worth explaining that "start-ns" event is accompanied by a tuple of (namespace, url) rather than an element from the XML document. Currently the description just says "ns events are used to get detailed namespace information" but doesn't say how or give an example.

----------
assignee: docs at python
components: Documentation
messages: 201734
nosy: Peter.Harris, docs at python
priority: normal
severity: normal
status: open
title: ElementTree iterparse documentation
versions: Python 3.3

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

From report at bugs.python.org  Wed Oct 30 18:15:13 2013
From: report at bugs.python.org (David Evans)
Date: Wed, 30 Oct 2013 17:15:13 +0000
Subject: [New-bugs-announce] [issue19453] pydoc.py doesn't detect IronPython,
	help(foo) can hang
Message-ID: <1383153313.2.0.219850254586.issue19453@psf.upfronthosting.co.za>


New submission from David Evans:

The pager functions used by help() in StdLib's pydoc.py don't detect IronPython correctly and the result is a lack of functionality or in some cases a hang. This is similar to issue 8110 in that the code attempts to detect windows with a check for "win32" from sys.platform and needs to check for "cli" as well to detect IronPython running on mono on linux/mac os or on windows.

My naive change to workaround the problem was to add the two line test for "cli" amidst getpager() here:

    if sys.platform == 'win32' or sys.platform.startswith('os2'):
        return lambda text: tempfilepager(plain(text), 'more <')
    if sys.platform == 'cli':
        return plainpager # IronPython
    if hasattr(os, 'system') and os.system('(less) 2>/dev/null') == 0:
        return lambda text: pipepager(text, 'less')

That two line addition allowed basic function and prevents the hang though maybe there is a better pager type that would work on IronPython. In our linux and windows tests though neither the tempfilepager nor pipepager would function on either platform.

I submitted the report to the IronPython issues tracker and someone there suggested posting the patch here.

----------
components: Windows
messages: 201750
nosy: owlmonkey
priority: normal
severity: normal
status: open
title: pydoc.py doesn't detect IronPython, help(foo) can hang
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Wed Oct 30 19:51:56 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 30 Oct 2013 18:51:56 +0000
Subject: [New-bugs-announce] [issue19454] devguide: Document what a
	"platform support" is
Message-ID: <1383159116.46.0.184690879028.issue19454@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

As a followup to issue19377 it would be nice if devguide contained a paragraph to resolve the conflicting point provided by http://bugs.python.org/msg187373 and http://bugs.python.org/msg201141 arguments.

----------
assignee: docs at python
components: Devguide, Documentation
messages: 201762
nosy: docs at python, ezio.melotti, techtonik
priority: normal
severity: normal
status: open
title: devguide: Document what a "platform support" is

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

From report at bugs.python.org  Wed Oct 30 23:52:55 2013
From: report at bugs.python.org (Eric Hanchrow)
Date: Wed, 30 Oct 2013 22:52:55 +0000
Subject: [New-bugs-announce] [issue19455] LoggerAdapter class lacks
	documented "setLevel" method
Message-ID: <1383173575.67.0.414384177388.issue19455@psf.upfronthosting.co.za>


Changes by Eric Hanchrow <eric.hanchrow at gmail.com>:


----------
components: Library (Lib)
nosy: Eric.Hanchrow
priority: normal
severity: normal
status: open
title: LoggerAdapter class lacks documented "setLevel" method
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct 31 00:12:37 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 30 Oct 2013 23:12:37 +0000
Subject: [New-bugs-announce] [issue19456] ntpath doesn't join paths
	correctly when a drive is	present
Message-ID: <1383174757.86.0.861423882665.issue19456@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

(Bruce Leban, on python-ideas:)

"""
ntpath still gets drive-relative paths wrong on Windows:

>>> ntpath.join(r'\\a\b\c\d', r'\e\f')
'\\e\\f'  
# should be r'\\a\b\e\f'

>>> ntpath.join(r'C:\a\b\c\d', r'\e\f')
'\\e\\f'
# should be r'C:\e\f'

(same behavior in Python 2.7 and 3.3)
"""

(Let's also make sure PEP 428 / pathlib fixes this.)

----------
components: Library (Lib)
keywords: easy
messages: 201784
nosy: gvanrossum, pitrou
priority: normal
severity: normal
status: open
title: ntpath doesn't join paths correctly when a drive is present
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Oct 31 00:33:42 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 30 Oct 2013 23:33:42 +0000
Subject: [New-bugs-announce]
	[issue19457]	test.test_codeccallbacks.CodecCallbackTest.test_xmlcharrefreplace_with_surrogates()	and	test.test_unicode.UnicodeTest.test_encode_decimal_with_surrogates()	loaded
	from *.pyc files fail with Python supporting wide unicode
Message-ID: <1383176022.37.0.747916589963.issue19457@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

test.test_codeccallbacks.CodecCallbackTest.test_xmlcharrefreplace_with_surrogates() and test.test_unicode.UnicodeTest.test_encode_decimal_with_surrogates() fail with Python supporting wide unicode, when they have been loaded from *.pyc files (test_codeccallbacks.pyc, test_unicode.pyc).
(This bug can be reproduced when running `make test`, which runs test suite twice, firstly with *.pyc files initially absent.)

This bug is a regression in 2.7.6rc1. These tests are absent in 2.7.5. These tests were added in 719ee60fc5e2.

$ ./configure --enable-unicode=ucs4
...
$ make
...
$ LD_LIBRARY_PATH="$(pwd)" ./python Lib/test/regrtest.py -v test_codeccallbacks
...
$ LD_LIBRARY_PATH="$(pwd)" ./python Lib/test/regrtest.py -v test_codeccallbacks
== CPython 2.7.6rc1 (2.7:dd12639b82bf, Oct 30 2013, 23:53:21) [GCC 4.8.1]
==   Linux-3.11.6
==   /tmp/cpython/build/test_python_6715
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_codeccallbacks
test_backslashescape (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_badandgoodbackslashreplaceexceptions (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_badandgoodignoreexceptions (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_badandgoodreplaceexceptions (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_badandgoodstrictexceptions (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_badandgoodxmlcharrefreplaceexceptions (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_badhandlerresults (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_badlookupcall (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_badregistercall (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_bug828737 (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_callbacks (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_charmapencode (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_decodehelper (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_decodeunicodeinternal (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_decoding_callbacks (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_encodehelper (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_longstrings (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_lookup (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_translatehelper (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_unencodablereplacement (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_unicodedecodeerror (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_unicodeencodeerror (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_unicodetranslateerror (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_uninamereplace (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_unknownhandler (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_xmlcharnamereplace (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_xmlcharrefreplace (test.test_codeccallbacks.CodecCallbackTest) ... ok
test_xmlcharrefreplace_with_surrogates (test.test_codeccallbacks.CodecCallbackTest) ... FAIL
test_xmlcharrefvalues (test.test_codeccallbacks.CodecCallbackTest) ... ok

======================================================================
FAIL: test_xmlcharrefreplace_with_surrogates (test.test_codeccallbacks.CodecCallbackTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/cpython/Lib/test/test_codeccallbacks.py", line 93, in test_xmlcharrefreplace_with_surrogates
    exp, msg='%r.encode(%r)' % (s, encoding))
AssertionError: u'\U0001f49d'.encode('ascii')

----------------------------------------------------------------------
Ran 29 tests in 0.071s

FAILED (failures=1)
test test_codeccallbacks failed -- Traceback (most recent call last):
  File "/tmp/cpython/Lib/test/test_codeccallbacks.py", line 93, in test_xmlcharrefreplace_with_surrogates
    exp, msg='%r.encode(%r)' % (s, encoding))
AssertionError: u'\U0001f49d'.encode('ascii')

1 test failed:
    test_codeccallbacks
$ LD_LIBRARY_PATH="$(pwd)" ./python Lib/test/regrtest.py -v test_unicode
...
$ LD_LIBRARY_PATH="$(pwd)" ./python Lib/test/regrtest.py -v test_unicode
== CPython 2.7.6rc1 (2.7:dd12639b82bf, Oct 30 2013, 23:53:21) [GCC 4.8.1]
==   Linux-3.11.6
==   /tmp/cpython/build/test_python_7518
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_unicode
test___contains__ (test.test_unicode.UnicodeTest) ... ok
test__format__ (test.test_unicode.UnicodeTest) ... ok
test_bug1001011 (test.test_unicode.UnicodeTest) ... ok
test_capitalize (test.test_unicode.UnicodeTest) ... ok
test_center (test.test_unicode.UnicodeTest) ... ok
test_codecs (test.test_unicode.UnicodeTest) ... ok
test_codecs_charmap (test.test_unicode.UnicodeTest) ... ok
test_codecs_errors (test.test_unicode.UnicodeTest) ... ok
test_codecs_idna (test.test_unicode.UnicodeTest) ... ok
test_codecs_utf7 (test.test_unicode.UnicodeTest) ... ok
test_codecs_utf8 (test.test_unicode.UnicodeTest) ... ok
test_comparison (test.test_unicode.UnicodeTest) ... ok
test_concatenation (test.test_unicode.UnicodeTest) ... ok
test_constructor (test.test_unicode.UnicodeTest) ... ok
test_contains (test.test_unicode.UnicodeTest) ... ok
test_conversion (test.test_unicode.UnicodeTest) ... ok
test_count (test.test_unicode.UnicodeTest) ... ok
test_encode_decimal (test.test_unicode.UnicodeTest) ... ok
test_encode_decimal_with_surrogates (test.test_unicode.UnicodeTest) ... FAIL
test_endswith (test.test_unicode.UnicodeTest) ... ok
test_expandtabs (test.test_unicode.UnicodeTest) ... ok
test_expandtabs_overflows_gracefully (test.test_unicode.UnicodeTest) ... ok
test_extended_getslice (test.test_unicode.UnicodeTest) ... ok
test_find (test.test_unicode.UnicodeTest) ... ok
test_find_etc_raise_correct_error_messages (test.test_unicode.UnicodeTest) ... ok
test_floatformatting (test.test_unicode.UnicodeTest) ... ok
test_format (test.test_unicode.UnicodeTest) ... ok
test_format_auto_numbering (test.test_unicode.UnicodeTest) ... ok
test_format_float (test.test_unicode.UnicodeTest) ... ok
test_format_huge_item_number (test.test_unicode.UnicodeTest) ... ok
test_format_huge_precision (test.test_unicode.UnicodeTest) ... ok
test_format_huge_width (test.test_unicode.UnicodeTest) ... ok
test_format_subclass (test.test_unicode.UnicodeTest) ... ok
test_formatting (test.test_unicode.UnicodeTest) ... ok
test_formatting_huge_precision (test.test_unicode.UnicodeTest) ... ok
test_formatting_huge_width (test.test_unicode.UnicodeTest) ... ok
test_hash (test.test_unicode.UnicodeTest) ... ok
test_index (test.test_unicode.UnicodeTest) ... ok
test_inplace_rewrites (test.test_unicode.UnicodeTest) ... ok
test_isalnum (test.test_unicode.UnicodeTest) ... ok
test_isalnum_non_bmp (test.test_unicode.UnicodeTest) ... ok
test_isalpha (test.test_unicode.UnicodeTest) ... ok
test_isalpha_non_bmp (test.test_unicode.UnicodeTest) ... ok
test_isdecimal (test.test_unicode.UnicodeTest) ... ok
test_isdecimal_non_bmp (test.test_unicode.UnicodeTest) ... ok
test_isdigit (test.test_unicode.UnicodeTest) ... ok
test_isdigit_non_bmp (test.test_unicode.UnicodeTest) ... ok
test_islower (test.test_unicode.UnicodeTest) ... ok
test_islower_non_bmp (test.test_unicode.UnicodeTest) ... ok
test_isnumeric (test.test_unicode.UnicodeTest) ... ok
test_isnumeric_non_bmp (test.test_unicode.UnicodeTest) ... ok
test_isspace (test.test_unicode.UnicodeTest) ... ok
test_isspace_non_bmp (test.test_unicode.UnicodeTest) ... ok
test_issue8271 (test.test_unicode.UnicodeTest) ... ok
test_istitle (test.test_unicode.UnicodeTest) ... ok
test_istitle_non_bmp (test.test_unicode.UnicodeTest) ... ok
test_isupper (test.test_unicode.UnicodeTest) ... ok
test_isupper_non_bmp (test.test_unicode.UnicodeTest) ... ok
test_join (test.test_unicode.UnicodeTest) ... ok
test_literals (test.test_unicode.UnicodeTest) ... ok
test_ljust (test.test_unicode.UnicodeTest) ... ok
test_lower (test.test_unicode.UnicodeTest) ... ok
test_mul (test.test_unicode.UnicodeTest) ... ok
test_none_arguments (test.test_unicode.UnicodeTest) ... ok
test_partition (test.test_unicode.UnicodeTest) ... ok
test_printing (test.test_unicode.UnicodeTest) ... ok
test_raiseMemError (test.test_unicode.UnicodeTest) ... ok
test_replace (test.test_unicode.UnicodeTest) ... ok
test_replace_overflow (test.test_unicode.UnicodeTest) ... ok
test_repr (test.test_unicode.UnicodeTest) ... ok
test_rfind (test.test_unicode.UnicodeTest) ... ok
test_rindex (test.test_unicode.UnicodeTest) ... ok
test_rjust (test.test_unicode.UnicodeTest) ... ok
test_rpartition (test.test_unicode.UnicodeTest) ... ok
test_rsplit (test.test_unicode.UnicodeTest) ... ok
test_slice (test.test_unicode.UnicodeTest) ... ok
test_split (test.test_unicode.UnicodeTest) ... ok
test_splitlines (test.test_unicode.UnicodeTest) ... ok
test_startswith (test.test_unicode.UnicodeTest) ... ok
test_startswith_endswith_errors (test.test_unicode.UnicodeTest) ... ok
test_strip (test.test_unicode.UnicodeTest) ... ok
test_subscript (test.test_unicode.UnicodeTest) ... ok
test_surrogates (test.test_unicode.UnicodeTest) ... ok
test_swapcase (test.test_unicode.UnicodeTest) ... ok
test_title (test.test_unicode.UnicodeTest) ... ok
test_translate (test.test_unicode.UnicodeTest) ... ok
test_ucs4 (test.test_unicode.UnicodeTest) ... ok
test_unicode_repr (test.test_unicode.UnicodeTest) ... ok
test_upper (test.test_unicode.UnicodeTest) ... ok
test_utf8_decode_invalid_sequences (test.test_unicode.UnicodeTest) ... ok
test_utf8_decode_valid_sequences (test.test_unicode.UnicodeTest) ... ok
test_zfill (test.test_unicode.UnicodeTest) ... ok

======================================================================
FAIL: test_encode_decimal_with_surrogates (test.test_unicode.UnicodeTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/cpython/Lib/test/test_unicode.py", line 1672, in test_encode_decimal_with_surrogates
    '123' + exp)
  File "/tmp/cpython/Lib/test/test_unicode.py", line 45, in assertEqual
    super(UnicodeTest, self).assertEqual(first, second, msg)
AssertionError: '123&#128157;' != '123&#55357;&#56477;'

----------------------------------------------------------------------
Ran 92 tests in 16.002s

FAILED (failures=1)
test test_unicode failed -- Traceback (most recent call last):
  File "/tmp/cpython/Lib/test/test_unicode.py", line 1672, in test_encode_decimal_with_surrogates
    '123' + exp)
  File "/tmp/cpython/Lib/test/test_unicode.py", line 45, in assertEqual
    super(UnicodeTest, self).assertEqual(first, second, msg)
AssertionError: '123&#128157;' != '123&#55357;&#56477;'

1 test failed:
    test_unicode

----------
assignee: serhiy.storchaka
messages: 201786
nosy: Arfrever, benjamin.peterson, ezio.melotti, haypo, lemburg, serhiy.storchaka
priority: release blocker
severity: normal
status: open
title: test.test_codeccallbacks.CodecCallbackTest.test_xmlcharrefreplace_with_surrogates() and test.test_unicode.UnicodeTest.test_encode_decimal_with_surrogates() loaded from *.pyc files fail with Python supporting wide unicode
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct 31 03:47:18 2013
From: report at bugs.python.org (Hank Christian)
Date: Thu, 31 Oct 2013 02:47:18 +0000
Subject: [New-bugs-announce] [issue19458] Invitation to connect on LinkedIn
Message-ID: <1503784651.35972534.1383187566785.JavaMail.app@ela4-bed80.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-hnfe5x2a-17/isd/10674146693/f8KKDSuG/?hs=false&tok=1ZDH7D-C56MRY1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-3qcne3-hnfe5x2a-17/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I5845690646_1/?hs=false&tok=1LjfL2tR56MRY1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

----------
messages: 201791
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/issue19458>
_______________________________________

From report at bugs.python.org  Thu Oct 31 11:52:59 2013
From: report at bugs.python.org (=?utf-8?q?Caol=C3=A1n_McNamara?=)
Date: Thu, 31 Oct 2013 10:52:59 +0000
Subject: [New-bugs-announce] [issue19459] Fatal Python error: Py_Initialize:
	Unable to get the	locale encoding: GEORGIAN-PS
Message-ID: <1383216779.28.0.251946690468.issue19459@psf.upfronthosting.co.za>


New submission from Caol?n McNamara:

LANG=ka_GE.georgianps /usr/bin/python3
Fatal Python error: Py_Initialize: Unable to get the locale encoding
LookupError: unknown encoding: GEORGIAN-PS
Aborted (core dumped)

but with python-2.7.5 no crash...
LANG=ka_GE.georgianps /usr/bin/python2
Python 2.7.5 (default, Oct  8 2013, 12:19:40) 
[GCC 4.8.1 20130603 (Red Hat 4.8.1-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>

(fedora 19)

----------
components: Unicode
messages: 201800
nosy: Caol?n.McNamara, ezio.melotti
priority: normal
severity: normal
status: open
title: Fatal Python error: Py_Initialize: Unable to get the locale encoding: GEORGIAN-PS
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Thu Oct 31 16:59:31 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 31 Oct 2013 15:59:31 +0000
Subject: [New-bugs-announce] [issue19460] Add test for MIMENonMultipart
Message-ID: <1383235171.21.0.576245026541.issue19460@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Apparently there is no test for MIMENonMultipart.

[sky at localhost cpython]$ grep -R MIMENonMultipart Lib/test/*
[sky at localhost cpython]$

Attached the patch to add test for MIMENonMultipart.

----------
components: Tests
files: add_test_non_multipart.patch
keywords: patch
messages: 201827
nosy: r.david.murray, vajrasky
priority: normal
severity: normal
status: open
title: Add test for MIMENonMultipart
versions: Python 3.4
Added file: http://bugs.python.org/file32438/add_test_non_multipart.patch

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

From report at bugs.python.org  Thu Oct 31 18:24:06 2013
From: report at bugs.python.org (=?utf-8?q?Nacsa_Krist=C3=B3f?=)
Date: Thu, 31 Oct 2013 17:24:06 +0000
Subject: [New-bugs-announce] [issue19461] RawConfigParser modifies empty
	strings unconditionally
Message-ID: <1383240246.91.0.876276014549.issue19461@psf.upfronthosting.co.za>


New submission from Nacsa Krist?f:

http://hg.python.org/cpython/file/8d5df9602a72/Lib/ConfigParser.py#l529

RawConfigParser has a special case of replacing '""' with '' in reader.
However the writer does not do the same.

This may cause problems, for example if you merge multiple ini files into one and the 3rd party program that should use the output segfaults on an ini that has `key=` instead of `key=value`, as it is in my case. :)

I think that the reasoning with the reader maybe was that an empty string must be an empty python string. 
However there is no option to control how it gets written back to the output. One can of course walkaround it by replacing the '' values with '""', but I think the standard library is ought to be consistent, walkarounds are unpythonic, a raw parser should be transparent either way, and there should preferrably be one obvious way to do it.

I think this is not just unintuitive (especially in a parser called "raw"), but goes against the philosophy of "refusing the temptation to guess". 

As I know, the syntax of .ini files is not exactly well-defined, so the best option in my opinion would be allowing to configure the parser how to treat these values.

Whether or not adding this option is viable, I think the problem still remains that the writer now works inconsistently of the reader.

----------
components: Library (Lib)
messages: 201829
nosy: Nacsa.Krist?f
priority: normal
severity: normal
status: open
title: RawConfigParser modifies empty strings unconditionally
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct 31 18:32:58 2013
From: report at bugs.python.org (Artem Ustinov)
Date: Thu, 31 Oct 2013 17:32:58 +0000
Subject: [New-bugs-announce] [issue19462] Add remove_argument() method to
	argparse.ArgumentParser
Message-ID: <1383240778.45.0.779487488351.issue19462@psf.upfronthosting.co.za>


New submission from Artem Ustinov:

In order to migrate from optparse to argparse we need to have an ability to substitute anguments, e.g. remove and then create.

In our framework we use the command line utility base class and then inherit the particular tools from it. The parser in base class uses add_argument() to populate the general argument list but for some tools it is needed to modify the inherited arguments set and make some arguments to have the modified meaning.

With optparse we've just used remove_option() and then added the modified one with add_option() but argparse currently does not have this functionality.

For the purpose above we just need to have remove_argument() or modify_argument() methods in orgparse

----------
components: Library (Lib)
messages: 201832
nosy: ustinov
priority: normal
severity: normal
status: open
title: Add remove_argument() method to argparse.ArgumentParser
type: enhancement
versions: Python 3.2

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

From report at bugs.python.org  Thu Oct 31 19:53:22 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 31 Oct 2013 18:53:22 +0000
Subject: [New-bugs-announce] [issue19463] assertGdbRepr depends on hash
	randomization / endianess
Message-ID: <1383245602.59.0.0634998131847.issue19463@psf.upfronthosting.co.za>


New submission from Christian Heimes:

I'm seeing some unrelated test failures on PPC Linux (big endian) in my PEP-456 branch.

http://buildbot.python.org/all/builders/PPC64%20PowerLinux%20custom/builds/17/steps/test/logs/stdio

======================================================================
FAIL: test_frozensets (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of frozensets
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/custom.edelsohn-powerlinux-ppc64/build/Lib/test/test_gdb.py", line 331, in test_frozensets
    self.assertGdbRepr(frozenset(['a', 'b']), "frozenset({'a', 'b'})")
  File "/home/shager/cpython-buildarea/custom.edelsohn-powerlinux-ppc64/build/Lib/test/test_gdb.py", line 231, in assertGdbRepr
    % (gdb_repr, exp_repr, gdb_output)))
AssertionError: "frozenset({'b', 'a'})" != "frozenset({'a', 'b'})"
- frozenset({'b', 'a'})
?             ^    ^
+ frozenset({'a', 'b'})
?             ^    ^


======================================================================
FAIL: test_sets (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of sets
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/custom.edelsohn-powerlinux-ppc64/build/Lib/test/test_gdb.py", line 316, in test_sets
    self.assertGdbRepr(set(['a', 'b']), "{'a', 'b'}")
  File "/home/shager/cpython-buildarea/custom.edelsohn-powerlinux-ppc64/build/Lib/test/test_gdb.py", line 231, in assertGdbRepr
    % (gdb_repr, exp_repr, gdb_output)))
AssertionError: "{'b', 'a'}" != "{'a', 'b'}"
- {'b', 'a'}
+ {'a', 'b'}

----------
components: Tests
messages: 201841
nosy: christian.heimes
priority: low
severity: normal
stage: needs patch
status: open
title: assertGdbRepr depends on hash randomization / endianess
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Oct 31 20:15:34 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 31 Oct 2013 19:15:34 +0000
Subject: [New-bugs-announce] [issue19464] Remove warnings from Windows
	buildbot "clean" script
Message-ID: <1383246934.8.0.971910154804.issue19464@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Here's a patch to remove the compiler warning raised during the "clean" step on the Windows buildbots.  The warning is about the fact that ssl.vcxproj doesn't have an NMakeCleanCommandLine command; the patch adds such a command that simply echos "OpenSSL must be cleaned manually if you want to rebuild it."

Since Tools/buildbot/clean.bat is also called by Tools/buildbot/build.bat, this also removes 4 warnings from the "compile" step as well.

----------
components: Build, Windows
files: mask_ssl_clean_warnings.diff
keywords: patch
messages: 201844
nosy: brian.curtin, pitrou, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Remove warnings from Windows buildbot "clean" script
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32439/mask_ssl_clean_warnings.diff

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

From report at bugs.python.org  Thu Oct 31 23:36:21 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 31 Oct 2013 22:36:21 +0000
Subject: [New-bugs-announce] [issue19465] selectors: provide a helper to
	choose a selector using	constraints
Message-ID: <1383258981.48.0.274242938687.issue19465@psf.upfronthosting.co.za>


New submission from STINNER Victor:

multiprocess, telnetlib (and subprocess in a near future, see #18923) use the following code to select the best selector:

# poll/select have the advantage of not requiring any extra file descriptor,
# contrarily to epoll/kqueue (also, they require a single syscall).
if hasattr(selectors, 'PollSelector'):
    _TelnetSelector = selectors.PollSelector
else:
    _TelnetSelector = selectors.SelectSelector

I don't like the principle of "a default selector", selectors.DefaultSelector should be removed in my opinion.

I would prefer a function returning the best selector using constraints. Example:

def get_selector(use_fd=True) -> BaseSelector:
  ...

By default, it would return the same than the current DefaultSelector. But if you set use_fd=False, the choice would be restricted to select() or poll().

I don't want to duplicate code like telnetlib uses in each module, it's harder to maintain. The selectors module may get new selectors in the future, see for example #18931.

Except use_fd, I don't have other ideas of constraints. I read somewhere that differenet selectors may have different limits on the number of file descriptors. I don't know if it's useful to use such constraint?

----------
messages: 201855
nosy: gvanrossum, haypo, neologix
priority: normal
severity: normal
status: open
title: selectors: provide a helper to choose a selector using constraints
versions: Python 3.4

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