From report at bugs.python.org  Wed Jan  1 12:21:17 2014
From: report at bugs.python.org (Peter Santoro)
Date: Wed, 01 Jan 2014 11:21:17 +0000
Subject: [New-bugs-announce] [issue20102] shutil._make_zipfile possible
	resource leak
Message-ID: <1388575277.51.0.394331001558.issue20102@psf.upfronthosting.co.za>


New submission from Peter Santoro:

Now that zipfile.ZipFile supports the context manager protocol, shouldn't
shutil._make_zipfile make use of it to avoid the possibility of the archive file not being closed properly if an exception occurs?  It should be noted that shutil._unpack_zipfile does use try/finally to ensure that files are closed.

----------
components: Library (Lib)
files: shutil.diff
keywords: patch
messages: 207132
nosy: peter at psantoro.net
priority: normal
severity: normal
status: open
title: shutil._make_zipfile possible resource leak
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file33291/shutil.diff

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

From report at bugs.python.org  Wed Jan  1 17:12:00 2014
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 01 Jan 2014 16:12:00 +0000
Subject: [New-bugs-announce] [issue20103] Documentation of
	itertools.accumulate is confused
Message-ID: <1388592720.87.0.970906154406.issue20103@psf.upfronthosting.co.za>


New submission from Mitchell Model:

The documentation of itertools.accumulate (10.1) starts out with 2 misleading sentences: "Make an iterator that returns accumulated sums. Elements may be any addable type..." It then goes on to show examples of using the func parameter added in 3.3 that are not additions. It should be changed to something like: "Make an iterator that returns accumulated values. Elements may be any type that can be an argument to func. Func defaults to addition, so by default elements can be any addable types, ..." My wording is awkward, but you get the idea. I think this is a significant documentation issue, not just a nit.

----------
assignee: docs at python
components: Documentation
messages: 207135
nosy: MLModel, docs at python
priority: normal
severity: normal
status: open
title: Documentation of itertools.accumulate is confused
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Jan  1 19:13:20 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 01 Jan 2014 18:13:20 +0000
Subject: [New-bugs-announce] [issue20104] expose posix_spawn(p)
Message-ID: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

posix_spawn is a nice, efficient replacement for fork()/exec(). We should expose it and possibly use it in subprocess where possible.

----------
components: Extension Modules
messages: 207137
nosy: benjamin.peterson
priority: normal
severity: normal
stage: needs patch
status: open
title: expose posix_spawn(p)
type: performance
versions: Python 3.5

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

From report at bugs.python.org  Thu Jan  2 03:23:33 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 02 Jan 2014 02:23:33 +0000
Subject: [New-bugs-announce] [issue20105] Codec exception chaining is losing
	traceback details
Message-ID: <1388629413.58.0.988087871801.issue20105@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

The exception chaining in the codecs subsystem is currently losing the details of the original traceback.

Compare this traceback from Python 3.3:

>>> codecs.decode(b"abcdefgh", "hex_codec")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.3/encodings/hex_codec.py", line 20, in hex_decode
    return (binascii.a2b_hex(input), len(input))
binascii.Error: Non-hexadecimal digit found

With the current behaviour of Python 3.4:

>>> codecs.decode(b"abcdefgh", "hex")
binascii.Error: Non-hexadecimal digit found

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
binascii.Error: decoding with 'hex' codec failed (Error: Non-hexadecimal digit found)

The original traceback header and details are missing in the latter. It should look more like the following:

>>> try:
...     1/0
... except Exception as e:
...     raise Exception("Explicit chaining") from e
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
ZeroDivisionError: division by zero

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
Exception: Explicit chaining

----------
assignee: ncoghlan
components: Interpreter Core
keywords: 3.4regression
messages: 207142
nosy: ncoghlan
priority: deferred blocker
severity: normal
stage: test needed
status: open
title: Codec exception chaining is losing traceback details
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Jan  2 11:19:39 2014
From: report at bugs.python.org (Tabrez Mohammed)
Date: Thu, 02 Jan 2014 10:19:39 +0000
Subject: [New-bugs-announce] [issue20106] warn_dir is always true for
	install_data, even if an install_dir is specified
Message-ID: <1388657979.45.0.323765356952.issue20106@psf.upfronthosting.co.za>


New submission from Tabrez Mohammed:

In run(), there is a warning message printed to the console if warn_dir is '1':
  if self.warn_dir:
    self.warn("setup script did not provide a directory for "
              "'%s' -- installing right in '%s'" %
             (f, self.install_dir))

warn_dir should be unset in run to suppress the warning if an install_dir is specified.

----------
components: Distutils
messages: 207148
nosy: tabrezm
priority: normal
severity: normal
status: open
title: warn_dir is always true for install_data, even if an install_dir is specified
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Jan  2 11:22:23 2014
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 02 Jan 2014 10:22:23 +0000
Subject: [New-bugs-announce] [issue20107] Revert PEP 453 integration
Message-ID: <1388658143.96.0.201779546814.issue20107@psf.upfronthosting.co.za>


New submission from Martin v. L?wis:

According to PEP 453, the integration of pip must be reverted if PIP 1.5 was not released by December 29. AFAICT, this hasn't happened. So is it ok that I revert the PIP integration by Saturday?

----------
messages: 207149
nosy: dstufft, larry, loewis, ncoghlan
priority: release blocker
severity: normal
status: open
title: Revert PEP 453 integration
versions: Python 3.4

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

From report at bugs.python.org  Thu Jan  2 18:29:15 2014
From: report at bugs.python.org (Joost van Zwieten)
Date: Thu, 02 Jan 2014 17:29:15 +0000
Subject: [New-bugs-announce] [issue20108] cannot pass kwarg `func` to
	`inspect.getcallargs`
Message-ID: <1388683755.05.0.409989472701.issue20108@psf.upfronthosting.co.za>


New submission from Joost van Zwieten:

Consider the following example.

    import inspect
    inspect.getcallargs(lambda **kwargs: None, func=1)

IMHO `getcallargs` should return

    {'kwargs': {'func': 1}}

however, Python (versions 3.3 and 3.4) throws the following exception instead:

    TypeError: getcallargs() got multiple values for argument 'func'

This can be easily solved in `lib/inspect.py` by changing

    def getcallargs(func, *positional, **named):

into

    def getcallargs(*func_and_positional, **named):
        func, *positional = func_and_positional

Best regards,

Joost van Zwieten

----------
components: Library (Lib)
messages: 207177
nosy: joostvanzwieten
priority: normal
severity: normal
status: open
title: cannot pass kwarg `func` to `inspect.getcallargs`
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Jan  2 19:01:47 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 02 Jan 2014 18:01:47 +0000
Subject: [New-bugs-announce] [issue20109] TestProgram is mentioned in the
	unittest docs but is not	documented
Message-ID: <1388685707.72.0.688331916968.issue20109@psf.upfronthosting.co.za>


New submission from R. David Murray:

IMO, TestProgram should either be made anonymous in the docs ('main returns an object that has a results attribute...') or its external API should be formally documented.  If results is the only external API other than its init (which is documented as unittest.main), then I would suggest the former.  In either case exactly what 'results' contains should be clarified.

----------
assignee: docs at python
components: Documentation
messages: 207178
nosy: docs at python, r.david.murray
priority: normal
severity: normal
status: open
title: TestProgram is mentioned in the unittest docs but is not documented
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Jan  2 20:41:53 2014
From: report at bugs.python.org (Claudiu.Popa)
Date: Thu, 02 Jan 2014 19:41:53 +0000
Subject: [New-bugs-announce] [issue20110] Misleading word used for
	__annotations__
Message-ID: <1388691713.84.0.436758245185.issue20110@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

The documentation for `__annotations__` specify that the dict contains the parameter names ``or`` the return, but this is misleading, because `return` exists even if the parameter keys are present.

----------
assignee: docs at python
components: Documentation
files: doc_annotation.patch
keywords: patch
messages: 207183
nosy: Claudiu.Popa, docs at python
priority: normal
severity: normal
status: open
title: Misleading word used for __annotations__
versions: Python 3.4
Added file: http://bugs.python.org/file33297/doc_annotation.patch

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

From report at bugs.python.org  Thu Jan  2 21:29:00 2014
From: report at bugs.python.org (July Tikhonov)
Date: Thu, 02 Jan 2014 20:29:00 +0000
Subject: [New-bugs-announce] [issue20111] pathlib.PurePath.with_suffix()
	allows creation of	otherwise impossible paths
Message-ID: <1388694540.82.0.701601871731.issue20111@psf.upfronthosting.co.za>


New submission from July Tikhonov:

This is not a real-world example, but it brokes some invariant (part of path must not contain separator):

>>> pathlib.PurePath('/a/b.c.d').with_suffix('///')
PurePosixPath('/a/b.c///')
>>> pathlib.PurePath('/a/b.c.d').with_suffix('/not/split/into/parts').parts
('/', 'a', 'b.c/not/split/into/parts')

I think these cases should raise an error.

I would also like to consider the following to be an error, since the argument of with_suffix() is not exactly a suffix:

>>> PurePath('/a/b.c.d').with_suffix('e')
PurePosixPath('/a/b.ce')

but I'm far less sure in this case.

----------
components: Library (Lib)
messages: 207185
nosy: july, pitrou
priority: normal
severity: normal
status: open
title: pathlib.PurePath.with_suffix() allows creation of otherwise impossible paths
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jan  2 23:32:32 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 02 Jan 2014 22:32:32 +0000
Subject: [New-bugs-announce] [issue20112] The documentation for http.server
	error_message_format	is inadequate.
Message-ID: <1388701952.2.0.132957137739.issue20112@psf.upfronthosting.co.za>


New submission from R. David Murray:

The description of error_message_format does not give enough information to use it.  The description should talk about how it is used (ie: using % formatting) and the fact that when filled in it should form a complete html document because it will be sent as the error response body.  It should not talk about what "the code key should be", etc, but should instead say what they *will* be, and cross reference the send_error method as the thing that uses it.

----------
assignee: docs at python
components: Documentation
messages: 207194
nosy: docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: The documentation for http.server error_message_format is inadequate.
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Jan  3 12:19:28 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Jan 2014 11:19:28 +0000
Subject: [New-bugs-announce] [issue20113] os.readv() and os.writev() don't
	raise an OSError on	readv()/writev() failure
Message-ID: <1388747968.16.0.893473617326.issue20113@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Example:

$ python3
Python 3.3.2 (default, Nov  8 2013, 13:38:57) 
[GCC 4.8.2 20131017 (Red Hat 4.8.2-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.fstat(19)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 9] Bad file descriptor
>>> buf=bytearray(10)
>>> os.readv(19, [buf])
-1

I would expect an OSError on os.readv() instead of -1.

Moreover, empty list of buffers are not handled correctly:

$ python3
Python 3.3.2 (default, Nov  8 2013, 13:38:57) 
[GCC 4.8.2 20131017 (Red Hat 4.8.2-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.readv(0, [])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: error return without exception set

Attached patch should fix both issues.

----------
messages: 207220
nosy: haypo
priority: normal
severity: normal
status: open
title: os.readv() and os.writev() don't raise an OSError on readv()/writev() failure
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Jan  3 13:17:44 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Jan 2014 12:17:44 +0000
Subject: [New-bugs-announce] [issue20114] Sporadic failure of
	test_semaphore_tracker() of	test_multiprocessing_forkserver
	on FreeBSD 9 buildbot
Message-ID: <1388751464.62.0.0417954391884.issue20114@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%203.x/builds/6085/steps/test/logs/stdio

======================================================================
FAIL: test_semaphore_tracker (test.test_multiprocessing_forkserver.TestSemaphoreTracker)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/_test_multiprocessing.py", line 3661, in test_semaphore_tracker
    _multiprocessing.sem_unlink(name2)
AssertionError: OSError not raised

----------
keywords: buildbot
messages: 207223
nosy: haypo, sbt
priority: normal
severity: normal
status: open
title: Sporadic failure of test_semaphore_tracker() of test_multiprocessing_forkserver on FreeBSD 9 buildbot
versions: Python 3.4

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

From report at bugs.python.org  Fri Jan  3 18:59:13 2014
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 03 Jan 2014 17:59:13 +0000
Subject: [New-bugs-announce] [issue20115] NUL bytes in commented lines
Message-ID: <1388771953.42.0.332804570753.issue20115@psf.upfronthosting.co.za>


New submission from Armin Rigo:

This is probably the smallest example of a .py file that behaves differently in CPython vs PyPy, and for once, I'd argue that the CPython behavior is unexpected:

   # make the file:
   >>> open('x.py', 'wb').write('#\x00\na')

   # run it:
   python x.py

Expected: either some SyntaxError, or "NameError: global name 'a' is not defined".  Got: nothing.  It seems that CPython completely ignores the line that is immediately after a line with a '#' and a following '\x00'.

----------
components: Interpreter Core
messages: 207232
nosy: arigo
priority: low
severity: normal
status: open
title: NUL bytes in commented lines
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Fri Jan  3 20:39:19 2014
From: report at bugs.python.org (Ruben D. Orduz)
Date: Fri, 03 Jan 2014 19:39:19 +0000
Subject: [New-bugs-announce] [issue20116] urlparse.parse_qs should take
	argument for query	separator
Message-ID: <1388777959.1.0.144368039339.issue20116@psf.upfronthosting.co.za>


New submission from Ruben D. Orduz:

Currently urlparse.parse_qs (http://hg.python.org/cpython/file/2.7/Lib/urlparse.py#l150) assumes and uses ';' as a query string separator with no way to overwrite that. There are several web service APIs out there that use ';' as list separator (e.g. [URL]?fruits=lemon;lime&family=citrus). Although ';' seems like a sensible choice for a default, there should be a way to overwrite it.

----------
messages: 207237
nosy: ruben.orduz
priority: normal
severity: normal
status: open
title: urlparse.parse_qs should take argument for query separator
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Jan  3 23:20:39 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 03 Jan 2014 22:20:39 +0000
Subject: [New-bugs-announce] [issue20117] subprocess on Windows: wrong
	return code with shell=True
Message-ID: <1388787639.9.0.977617126521.issue20117@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

A little birdie told me:

"""
Bug in Python subprocess doesn't allow to detect if
command executed through Windows system shell
exists.

If command doesn't exist, windows shell returns 9009
exit code (127 on Linux):
---[a.bat]---
@echo off
nonex
echo %ERRORLEVEL%

> a.bat
'nonex' is not recognized as an internal or external command,
operable program or batch file.
9009

However, when executed with Python, the return code
is different on Python 2.7/3.3:
---[x.py]---
import subprocess
p = subprocess.Popen("nonex", shell=True)
print(p.wait())

> python x.py
'nonex' is not recognized as an internal or external command,
operable program or batch file.
1

The same script executed on Linux gives correct result:
# python x.py
/bin/sh: non-existent: command not found
127

---[a.sh]---
nonex
echo $?
"""

There's some more research at http://goo.gl/xEg2b1

Seems the culprit is cmd.exe, which is executed by Python internally.
It looks like it fails to return corresponding code 9009.

Possibly all that needs to be done is documenting this wart, if we can't do anything about it?

----------
messages: 207251
nosy: ezio.melotti, gvanrossum
priority: low
severity: normal
stage: needs patch
status: open
title: subprocess on Windows: wrong return code with shell=True
type: behavior

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

From report at bugs.python.org  Fri Jan  3 23:22:59 2014
From: report at bugs.python.org (R. David Murray)
Date: Fri, 03 Jan 2014 22:22:59 +0000
Subject: [New-bugs-announce] [issue20118] test_imaplib test_linetoolong
	fails on 2.7 in SSL test	on some buildbots
Message-ID: <1388787779.06.0.335033013809.issue20118@psf.upfronthosting.co.za>


New submission from R. David Murray:

test.test_imaplib.ThreadedNetworkedTestsSSL.test_linetoolong, added as part of the fix for security (DOS attack) issue 16039, is failing on 2.7 on some buildbots (FreeBSD, OpenIndia, Windows).  On some platforms (FreeBSD at least) the failure seems to be intermittent.  Running the tests with the same randseed on linux does not reproduce the problem.  Running the test under -F on linux does not produce any failures.

Since this is a DOS security issue, and since the failure is that the exception comes from the ssl module instead of being an imaplib error but it nevertheless blocks the attack, I've left the patch in.  But the reason for the failure should be determined and either the test or the code fixed.  (In the meantime I'll mark the test to be skipped).

----------
components: Library (Lib)
messages: 207252
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: test_imaplib test_linetoolong fails on 2.7 in SSL test on some buildbots
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Jan  4 05:13:31 2014
From: report at bugs.python.org (nlevitt@gmail.com)
Date: Sat, 04 Jan 2014 04:13:31 +0000
Subject: [New-bugs-announce] [issue20119] pdb c(ont(inue)) optional
	one-time-only breakpoint (like	perl debugger)
Message-ID: <1388808811.19.0.853662131976.issue20119@psf.upfronthosting.co.za>


New submission from nlevitt at gmail.com:

The continue command in perl's debugger (perl -d) supports setting a one-time-only breakpoint. IMHO this is incredibly useful. For instance when stepping through a program, if you get stuck in a loop, you can move past it with a simple one line command "c [line-after-loop]".

pdb could have the same thing!

----------
files: pdb-continue-onetime-bp-00.diff
keywords: patch
messages: 207266
nosy: nlevitt at gmail.com
priority: normal
severity: normal
status: open
title: pdb c(ont(inue)) optional one-time-only breakpoint (like perl debugger)
type: enhancement
Added file: http://bugs.python.org/file33306/pdb-continue-onetime-bp-00.diff

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

From report at bugs.python.org  Sat Jan  4 09:54:35 2014
From: report at bugs.python.org (Thomas Levine)
Date: Sat, 04 Jan 2014 08:54:35 +0000
Subject: [New-bugs-announce] [issue20120] Percent-signs (%) in .pypirc
	should not be interpolated
Message-ID: <1388825675.42.0.435893533792.issue20120@psf.upfronthosting.co.za>


New submission from Thomas Levine:

This works fine in Python 2.7, but it fails in Python 3.3.

[tlevine at wildebeest mailfest-scoreboard]$ python3 --version
Python 3.3.3
[tlevine at wildebeest mailfest-scoreboard]$ python3 setup.py register sdist
running register
Traceback (most recent call last):
  File "setup.py", line 11, in <module>
    scripts=['scoreboard']
  File "/usr/lib/python3.3/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/usr/lib/python3.3/distutils/dist.py", line 929, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python3.3/distutils/dist.py", line 948, in run_command
    cmd_obj.run()
  File "/usr/lib/python3.3/distutils/command/register.py", line 45, in run
    self._set_config()
  File "/usr/lib/python3.3/distutils/command/register.py", line 71, in _set_config
    config = self._read_pypirc()
  File "/usr/lib/python3.3/distutils/config.py", line 83, in _read_pypirc
    current[key] = config.get(server, key)
  File "/usr/lib/python3.3/configparser.py", line 790, in get
    d)
  File "/usr/lib/python3.3/configparser.py", line 391, in before_get
    self._interpolate_some(parser, option, L, value, section, defaults, 1)
  File "/usr/lib/python3.3/configparser.py", line 440, in _interpolate_some
    "found: %r" % (rest,))
configparser.InterpolationSyntaxError: '%' must be followed by '%' or '(', found: '%rest-of-my-password'



Here are the relevant files.



[tlevine at wildebeest mailfest-scoreboard]$ cat ~/.pypirc 
[distutils]
index-servers =
    pypi

[pypi]
username:tlevine
password:yh^%#rest-of-my-password
[tlevine at wildebeest mailfest-scoreboard]$ cat setup.py 
#!/usr/bin/env python3

from distutils.core import setup

setup(name='mailfest-scoreboard',
      version='0.0.1',
      description='Score mailfest participants',
      author='Thomas Levine',
      author_email='_ at thomaslevine.com',
      url='https://github.com/tlevine/mailfest-scoreboard',
      scripts=['scoreboard']
     )

----------
components: Distutils
messages: 207275
nosy: tlevine
priority: normal
severity: normal
status: open
title: Percent-signs (%) in .pypirc should not be interpolated
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Jan  4 12:54:50 2014
From: report at bugs.python.org (Fred Stober)
Date: Sat, 04 Jan 2014 11:54:50 +0000
Subject: [New-bugs-announce] [issue20121] quopri_codec newline handling
Message-ID: <1388836490.83.0.337537980753.issue20121@psf.upfronthosting.co.za>


New submission from Fred Stober:

While trying to encode some binary data, I encountered this behaviour of the quopri_codec:

>>> '\r\n\n'.encode('quopri_codec').decode('quopri_codec')
'\r\n\r\n'
>>> '\n\r\n'.encode('quopri_codec').decode('quopri_codec')
'\n\n'

If this behaviour is really intended, it should be mentioned in the documentation that this coded is not bijective.

----------
components: Library (Lib)
messages: 207281
nosy: fredstober
priority: normal
severity: normal
status: open
title: quopri_codec newline handling
versions: Python 2.7

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

From report at bugs.python.org  Sat Jan  4 17:24:58 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Jan 2014 16:24:58 +0000
Subject: [New-bugs-announce] [issue20122] Move CallTips tests to idle_tests
Message-ID: <1388852698.51.0.14863260737.issue20122@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch moves CallTips tests from Lib/idlelib/CallTips.py to Lib/idlelib/idle_test/test_calltips.py and converts them to unittests.

Private keyword-only parameter _namespace was added to fetch_tip() and get_entity().

----------
components: IDLE, Tests
files: test_calltips.patch
keywords: patch
messages: 207291
nosy: kbk, roger.serwy, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Move CallTips tests to idle_tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33308/test_calltips.patch

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

From report at bugs.python.org  Sat Jan  4 23:27:05 2014
From: report at bugs.python.org (Eric Snow)
Date: Sat, 04 Jan 2014 22:27:05 +0000
Subject: [New-bugs-announce] [issue20123] pydoc.synopsis fails to load
	binary modules
Message-ID: <1388874425.94.0.221860493391.issue20123@psf.upfronthosting.co.za>


New submission from Eric Snow:

I'm guessing this is a very seldom (never?) used code path.  I've included a patch to test and fix the problem.  The patch includes several related tests for pydoc.

$ py3 -c 'import pydoc; pydoc.synopsis("/opt/python3.4/lib/python3.4/lib-dynload/time.cpython-34m.so")'
Traceback (most recent call last):
  File "/opt/python3.4/lib/python3.4/tokenize.py", line 368, in find_cookie
    line_string = line.decode('utf-8')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf4 in position 96: invalid continuation byte

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/opt/python3.4/lib/python3.4/pydoc.py", line 229, in synopsis
    file = tokenize.open(filename)
  File "/opt/python3.4/lib/python3.4/tokenize.py", line 429, in open
    encoding, lines = detect_encoding(buffer.readline)
  File "/opt/python3.4/lib/python3.4/tokenize.py", line 409, in detect_encoding
    encoding = find_cookie(first)
  File "/opt/python3.4/lib/python3.4/tokenize.py", line 373, in find_cookie
    raise SyntaxError(msg)
SyntaxError: invalid or missing encoding declaration for '/opt/python3.4/lib/python3.4/lib-dynload/time.cpython-34m.so'

----------
messages: 207319
nosy: eric.snow, larry
priority: normal
severity: normal
stage: patch review
status: open
title: pydoc.synopsis fails to load binary modules
type: behavior

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

From report at bugs.python.org  Sun Jan  5 00:48:56 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 04 Jan 2014 23:48:56 +0000
Subject: [New-bugs-announce] [issue20124] The documentation for the atTime
	parameter of	TimedRotatimeFileHandler is confusing
Message-ID: <1388879336.03.0.25076651665.issue20124@psf.upfronthosting.co.za>


New submission from R. David Murray:

The docs say that you can specify 'atTime' with a 'when' of 'midnight', but that makes no sense on the face of it.  atTime with a weekday specification makes sense, but it would also make sense to use atTime with a when of D (and an interval), which is not mentioned as a possibility.  It could also make sense to use it with other intervals (in other words, use the atTime as the starting point for the rotation calculation, instead of the last mod time or 'now').  If that doesn't work it should be stated that atTime will be ignored in those cases.  

Probably all the time related entries should be rewritten with the existence of atTime in mind, in order to clarify all the possible (and not possible) interactions.

----------
assignee: docs at python
components: Documentation
messages: 207323
nosy: docs at python, r.david.murray, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: The documentation for the atTime parameter of TimedRotatimeFileHandler is confusing
versions: Python 3.4

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

From report at bugs.python.org  Sun Jan  5 03:17:52 2014
From: report at bugs.python.org (Eric Snow)
Date: Sun, 05 Jan 2014 02:17:52 +0000
Subject: [New-bugs-announce] [issue20125] We need a good replacement for
	direct use of	load_module(), post-PEP 451
Message-ID: <1388888272.45.0.255353824658.issue20125@psf.upfronthosting.co.za>


New submission from Eric Snow:

In issue #19713, it came up that while PEP 451 deprecated Loader.load_module(), it did not provide a suitable replacement for calling it directly.  We've worked around this in the stdlib by making calls to private APIs, but that won't work so well for the community at large.

The importlib._bootstrap._SpecMethods class is one we had considered making public, but decided to defer that decision until people demonstrated an interest/need.

At this point in the 3.4 release cycle I'm not sure how much we can do about it.  Adding something like the following would be easy, but then we'd be stuck indefinitely with an API that we may just deprecate in 3.5 (a one-hit wonder), though that might be the lesser evil.

def load_from_spec(spec):
    _spec = importlib._bootstrap._SpecMethods(spec)
    return _spec.load()

Adding that as a recipe to the load_module() docs wouldn't work too well either, since we'd still be advocating the use of a private API as a workaround.

To be honest, I'll have to defer to Brett, Nick, et al. on this one.  They have the experience to know the best approach to take here.  I just haven't been in the majors long enough.

(Where'd Guido put the keys to that time machine?)

----------
components: Library (Lib)
messages: 207326
nosy: Arfrever, brett.cannon, eric.snow, ncoghlan
priority: high
severity: normal
status: open
title: We need a good replacement for direct use of load_module(), post-PEP 451
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Jan  5 04:00:23 2014
From: report at bugs.python.org (lotus@blossomhillranch.com)
Date: Sun, 05 Jan 2014 03:00:23 +0000
Subject: [New-bugs-announce] [issue20126] sched doesn't handle events added
	after scheduler starts
Message-ID: <1388890823.36.0.322424274213.issue20126@psf.upfronthosting.co.za>


New submission from lotus at blossomhillranch.com:

Events added after the scheduler is running, with a delay value before the next event, do not run at the correct time.

import sched
import time
import threading

def event( eventNum ):
	print( 'event', eventNum, time.time() )

s = sched.scheduler()
s.enter( 0,1,event, (0,) )
s.enter(10,1,event, (1,) )
t = threading.Thread( target = s.run )
t.start()
s.enter( 5,1,event, (2,) )


OUTPUT
event 0 1388890197.7716181
event 2 1388890207.7340584
event 1 1388890207.7347224

----------
messages: 207336
nosy: lotus at blossomhillranch.com
priority: normal
severity: normal
status: open
title: sched doesn't handle events added after scheduler starts
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Jan  5 04:18:14 2014
From: report at bugs.python.org (Eric Snow)
Date: Sun, 05 Jan 2014 03:18:14 +0000
Subject: [New-bugs-announce] [issue20127] Race condition in
	test_threaded_import.task()?
Message-ID: <1388891894.47.0.893825432716.issue20127@psf.upfronthosting.co.za>


New submission from Eric Snow:

While looking at the logs of a buildbot failure [1], I took a look at Lib/test/test_threaded_import.py.  In ThreadedImportTests.check_parallel_module_init() it makes a bunch of threaded calls to the module-level "task()" function.  There may be a race condition in the finally clause of that function.  I don't have a lot of time to investigate further right now, but I'll take a closer look when I get the chance.

[1] http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/7800

----------
components: Tests
messages: 207338
nosy: eric.snow
priority: normal
severity: normal
status: open
title: Race condition in test_threaded_import.task()?
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Jan  5 08:10:27 2014
From: report at bugs.python.org (Eric Snow)
Date: Sun, 05 Jan 2014 07:10:27 +0000
Subject: [New-bugs-announce] [issue20128] Re-enable
	test_modules_search_builtin() in test_pydoc
Message-ID: <1388905827.82.0.948519018287.issue20128@psf.upfronthosting.co.za>


New submission from Eric Snow:

The test (added in issue #20123) broke one of the stable FreeBSD buildbots:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%203.x/builds/6102

The log for that test run indicates the traceback and the test can be found in Lib/test/test_pydoc.py (PydocImportTest.test_modules_search_builtin).

The problem could be one (or more) of several possibilities:

* the test is broken in an esoteric way
* the buildbot has issues
* the platform has issues
* the test exposes some other underlying bug elsewhere

The test itself is not critical but I hope to re-enable it before beta 2 ends in a couple weeks.

Stefan: any insight you could offer on the problem, particularly relative to the platform and buildbot, would be greatly appreciated.

----------
assignee: eric.snow
components: Tests
messages: 207353
nosy: eric.snow, skrah
priority: high
severity: normal
stage: needs patch
status: open
title: Re-enable test_modules_search_builtin() in test_pydoc
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Jan  5 08:45:32 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 05 Jan 2014 07:45:32 +0000
Subject: [New-bugs-announce] [issue20129] 3.4 on windows 7 can't import
	IntEnum
Message-ID: <1388907932.96.0.334255876283.issue20129@psf.upfronthosting.co.za>


New submission from Mark Lawrence:

c:\Users\Mark\CrossCode>py -3.4 -c "from enum import IntEnum"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: cannot import name 'IntEnum'

I had earlier tried to install the complete 3.4 setup on Windows 7 but, for the first time that I'd ever seen, the installation rolled back.  So I installed without pip and then ran this command "py -3.4 -m ensurepip" which gave me this:-

Traceback (most recent call last):
  File "C:\Python34\lib\runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "C:\Python34\lib\runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "C:\Python34\lib\ensurepip\__main__.py", line 66, in <module>
    main()
  File "C:\Python34\lib\ensurepip\__main__.py", line 61, in main
    default_pip=args.default_pip,
  File "C:\Python34\lib\ensurepip\__init__.py", line 92, in bootstrap
    _run_pip(args + [p[0] for p in _PROJECTS], additional_paths)
  File "C:\Python34\lib\ensurepip\__init__.py", line 28, in _run_pip
    import pip
  File "C:\Users\Mark\AppData\Local\Temp\tmpysmgllcx\pip-1.5.rc1-py2.py3-none-any.whl\pip\__init__.py", line 9, in <module
  File "C:\Users\Mark\AppData\Local\Temp\tmpysmgllcx\pip-1.5.rc1-py2.py3-none-any.whl\pip\log.py", line 10, in <module>
  File "C:\Users\Mark\AppData\Local\Temp\tmpysmgllcx\pip-1.5.rc1-py2.py3-none-any.whl\pip\backwardcompat\__init__.py", lin
  File "C:\Python34\lib\urllib\request.py", line 88, in <module>
    import http.client
  File "C:\Python34\lib\http\client.py", line 69, in <module>
    import email.parser
  File "C:\Python34\lib\email\parser.py", line 13, in <module>
    from email.feedparser import FeedParser, BytesFeedParser
  File "C:\Python34\lib\email\feedparser.py", line 27, in <module>
    from email import message
  File "C:\Python34\lib\email\message.py", line 14, in <module>
    from email import utils
  File "C:\Python34\lib\email\utils.py", line 30, in <module>
    import socket
  File "C:\Python34\lib\socket.py", line 51, in <module>
    from enum import IntEnum
ImportError: cannot import name 'IntEnum' 

I suspect my installation is corrupt somehow but thought it safer to flag this just in case.

----------
components: Library (Lib)
messages: 207362
nosy: BreamoreBoy
priority: normal
severity: normal
status: open
title: 3.4 on windows 7 can't import IntEnum
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Jan  5 11:22:35 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 05 Jan 2014 10:22:35 +0000
Subject: [New-bugs-announce] [issue20130] asyncio: implement a synchronous
	executor if	concurrent.futures is missing
Message-ID: <1388917355.05.0.21952188677.issue20130@psf.upfronthosting.co.za>


New submission from STINNER Victor:

On old FreeBSD platforms (FreeBSD 6), concurrent.futures cannot be used and fail with an ImportError because of a limit on POSIX semaphores: see issue #10798. (See also maybe issue #10348 "multiprocessing: use SysV semaphores on FreeBSD" closed as WONTFIX.)

For asyncio, the test is currently skipped on this platform: see issue #19635.

(See also maybe issue #19295 "Make asyncio work without threads" closed as WONTFIX.)

I propose to implement a simple fallback using an synchronous executor (block until we get the result) which would be used by getaddrinfo() and getnameinfo() methods of EventLoop.

This issue is also motivated by my Trollius project, a backport of asyncio for Python 2.7, where concurrent.futures is not available. An optional backport, the "futures" project, can be used:
https://pypi.python.org/pypi/futures

Attached patch is a work-in-progress, it removes the dependency to concurrent.futures but doesn't implement the synchronous executor yet. It's the changes I wrote in Trollius 0.1.
https://pypi.python.org/pypi/trollius

----------
files: asyncio_sync.patch
keywords: patch
messages: 207368
nosy: gvanrossum, haypo
priority: normal
severity: normal
status: open
title: asyncio: implement a synchronous executor if concurrent.futures is missing
versions: Python 3.4
Added file: http://bugs.python.org/file33317/asyncio_sync.patch

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

From report at bugs.python.org  Sun Jan  5 13:39:29 2014
From: report at bugs.python.org (Andreas Kloeckner)
Date: Sun, 05 Jan 2014 12:39:29 +0000
Subject: [New-bugs-announce] [issue20131] warnings module offers no
	documented, programmatic way to reset "seen-warning" flag
Message-ID: <1388925569.4.0.616104920228.issue20131@psf.upfronthosting.co.za>


New submission from Andreas Kloeckner:

For tests and doctests, it is often desirable to show or verify that a certain warning occurs. Unfortunately, if the warning has been hit previously, it will not be issued again. It would be great if there were a documented, unified way to reset this 'seen' flag.

Related stackoverflow posts showing that I'm not the first person to have this need:

* https://stackoverflow.com/questions/19428761/python-showing-once-warnings-again-resetting-all-warning-registries
* https://stackoverflow.com/questions/2418570/testing-warnings-with-doctest

Neither of these has a satisfactory solution.

----------
components: Library (Lib)
messages: 207372
nosy: inducer
priority: normal
severity: normal
status: open
title: warnings module offers no documented, programmatic way to reset "seen-warning" flag
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Sun Jan  5 14:48:58 2014
From: report at bugs.python.org (Martin Panter)
Date: Sun, 05 Jan 2014 13:48:58 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue20132=5D_Many_incremental_c?=
 =?utf-8?q?odecs_don=E2=80=99t_handle_fragmented_data?=
Message-ID: <1388929738.44.0.851837204966.issue20132@psf.upfronthosting.co.za>


New submission from Martin Panter:

Many of the incremental codecs do not handle fragmented data very well. In the past I think I was interested in using the Base-64 and Quoted-printable codecs, and playing with other codecs today reveals many more issues. A lot of the issues reflect missing functionality, so maybe the simplest solution would be to document the codecs that don?t work.

Incremental decoding issues:

>>> str().join(codecs.iterdecode(iter((b"\\", b"u2013")), "unicode-escape"))
UnicodeDecodeError: 'unicodeescape' codec can't decode byte 0x5c in position 0: \ at end of string
# Same deal for raw-unicode-escape.

>>> bytes().join(codecs.iterdecode(iter((b"3", b"3")), "hex-codec"))
binascii.Error: Odd-length string

>>> bytes().join(codecs.iterdecode(iter((b"A", b"A==")), "base64-codec"))
binascii.Error: Incorrect padding

>>> bytes().join(codecs.iterdecode(iter((b"=", b"3D")), "quopri-codec"))
b'3D'  # Should return b"="

>>> codecs.getincrementaldecoder("uu-codec")().decode(b"begin ")
ValueError: Truncated input data

Incremental encoding issues:

>>> e = codecs.getincrementalencoder("base64-codec")(); codecs.decode(e.encode(b"1") + e.encode(b"2", final=True), "base64-codec")
b'1'  # Should be b"12"

>>> e = codecs.getincrementalencoder("quopri-codec")(); e.encode(b"1" * 50) + e.encode(b"2" * 50, final=True)
b'1111111111111111111111111111111111111111111111111122222222222222222222222222222222222222222222222222'
# I suspect the line should have been split in two

>>> e = codecs.getincrementalencoder("uu-codec")(); codecs.decode(e.encode(b"1") + e.encode(b"2", final=True), "uu-codec")
b'1'  # Should be b"12"

I also noticed iterdecode() does not work with ?uu-codec?:

>>> bytes().join(codecs.iterdecode(iter((b"begin 666 <data>\n \nend\n",)), "uu-codec"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.3/codecs.py", line 1032, in iterdecode
    output = decoder.decode(b"", True)
  File "/usr/lib/python3.3/encodings/uu_codec.py", line 80, in decode
    return uu_decode(input, self.errors)[0]
  File "/usr/lib/python3.3/encodings/uu_codec.py", line 45, in uu_decode
    raise ValueError('Missing "begin" line in input data')
ValueError: Missing "begin" line in input data

And iterencode() does not work with any of the byte encoders, because it does not know what kind of empty string to pass to IncrementalEncoder.encode(final=True):

>>> bytes().join(codecs.iterencode(iter(()), "base64-codec"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.3/codecs.py", line 1014, in iterencode
    output = encoder.encode("", True)
  File "/usr/lib/python3.3/encodings/base64_codec.py", line 31, in encode
    return base64.encodebytes(input)
  File "/usr/lib/python3.3/base64.py", line 343, in encodebytes
    raise TypeError("expected bytes, not %s" % s.__class__.__name__)
TypeError: expected bytes, not str

Finally, incremental UTF-7 encoding is suboptimal, and the decoder seems to buffer unlimited data, both defeating the purpose of using an incremental codec:

>>> bytes().join(codecs.iterencode("\xA9" * 2, "utf-7"))
b'+AKk-+AKk-'  # b"+AKkAqQ-" would be better

>>> d = codecs.getincrementaldecoder("utf-7")()
>>> d.decode(b"+")
b''
>>> any(d.decode(b"AAAAAAAA" * 100000) for _ in range(10))
False  # No data returned: everything must be buffered
>>> d.decode(b"-") == "\x00" * 3000000
True  # Returned all buffered data in one go

----------
components: Library (Lib)
messages: 207374
nosy: vadmium
priority: normal
severity: normal
status: open
title: Many incremental codecs don?t handle fragmented data
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Jan  5 22:21:04 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 05 Jan 2014 21:21:04 +0000
Subject: [New-bugs-announce] [issue20133] Convert the audioop module to use
	Argument Clinic
Message-ID: <1388956864.17.0.114751586443.issue20133@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which converts the audioop module to use Argument Clinic. 26 functions are converted. Also it adds docstrings for audioop functions.

There are two problems:

* Test test_string crashes. Perhaps here is a bug in Argument Clinic (Py_buffer arguments are not initialized).

* Pydoc for ratecv (and only for this function) returns:

    ratecv = <built-in function ratecv>

----------
components: Extension Modules
files: audioop_clinic.patch
keywords: patch
messages: 207401
nosy: larry, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Convert the audioop module to use Argument Clinic
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33320/audioop_clinic.patch

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

From report at bugs.python.org  Mon Jan  6 03:47:59 2014
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 06 Jan 2014 02:47:59 +0000
Subject: [New-bugs-announce] [issue20134] typo: s/coping/copying/
Message-ID: <1388976479.8.0.729846608286.issue20134@psf.upfronthosting.co.za>


New submission from INADA Naoki:

http://docs.python.org/3.3/library/unittest.mock-examples.html#coping-with-mutable-arguments
"coping" should be "copying"?

----------
assignee: docs at python
components: Documentation
messages: 207409
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: typo: s/coping/copying/
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Jan  6 04:37:24 2014
From: report at bugs.python.org (Xiaoqing Rong)
Date: Mon, 06 Jan 2014 03:37:24 +0000
Subject: [New-bugs-announce] [issue20135] mutate list
Message-ID: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za>


New submission from Xiaoqing Rong:

I was using IDLE (Python GUI) for Python 3.3.3. I don't know if this is a bug or you guys intend it to be this way:

>>> x=[1,2]
>>> y=x
>>> y.append(3)
>>> x
[1, 2, 3]

personally i'd prefer x stays as [1,2] when i'm trying to mutate y

also:
>>> def f1(m,n=['haha']):
	if m==n:
		print('m==n')
	else:
		print('m!=n')
	n.append('yaya')
	
>>> f1(['haha'])
m==n
>>> f1(['haha'])
m!=n

I'd prefer getting consistent results when calling functions like f1

----------
messages: 207410
nosy: m123orning
priority: normal
severity: normal
status: open
title: mutate list
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Jan  6 10:02:49 2014
From: report at bugs.python.org (A. Libotean)
Date: Mon, 06 Jan 2014 09:02:49 +0000
Subject: [New-bugs-announce] [issue20136] Logging: StreamHandler does not
	use OS line separator.
Message-ID: <1388998969.13.0.29066681056.issue20136@psf.upfronthosting.co.za>


New submission from A. Libotean:

The StreamHandler implementation uses hardcoded Unix/Linux line separators. This generates inconveniences when running on Windows as the file viewers expect DOS line terminators.

I've attached a fix that will use os.linesep as the line terminator thus making the log files usable with Windows utilities.

Please revise the fix and consider including it.

----------
components: Library (Lib)
files: streamhandler.py
messages: 207416
nosy: alibotean
priority: normal
severity: normal
status: open
title: Logging: StreamHandler does not use OS line separator.
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file33321/streamhandler.py

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

From report at bugs.python.org  Mon Jan  6 10:19:31 2014
From: report at bugs.python.org (A. Libotean)
Date: Mon, 06 Jan 2014 09:19:31 +0000
Subject: [New-bugs-announce] [issue20137] Logging: RotatingFileHandler
	computes string length	instead of byte representation length.
Message-ID: <1388999971.66.0.938288838593.issue20137@psf.upfronthosting.co.za>


New submission from A. Libotean:

Current implementation of RotatingFileHandler ignores the encoding when computing the entry byte length.

I've attached a modified version that will compute the entry lenght in bytes.

----------
components: Library (Lib)
files: rotatingfilehandler.py
messages: 207417
nosy: alibotean
priority: normal
severity: normal
status: open
title: Logging: RotatingFileHandler computes string length instead of byte representation length.
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file33322/rotatingfilehandler.py

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

From report at bugs.python.org  Mon Jan  6 10:46:59 2014
From: report at bugs.python.org (Armin Ronacher)
Date: Mon, 06 Jan 2014 09:46:59 +0000
Subject: [New-bugs-announce] [issue20138] wsgiref on Python 3.x incorrectly
	implements URL	handling causing mangled Unicode
Message-ID: <1389001619.16.0.909145148031.issue20138@psf.upfronthosting.co.za>


New submission from Armin Ronacher:

I just noticed through looking through someone else's WSGI framework that wsgiref is incorrectly handling URL handling.  It does not go through the WSGI coding dance in the wsgiref.utils.request_uri function.

Testcase through werkzeug:

>>> from wsgiref.util import request_uri
>>> from werkzeug.test import create_environ
>>> from werkzeug.urls import url_parse, url_unquote
>>> env = create_environ('/\N{SNOWMAN}')
>>> url_parse(request_uri(env)).path
'/%C3%A2%C2%98%C2%83'
>>> url_unquote(url_parse(request_uri(env)).path)
'/?\x98\x83'
>>> _ == '/\N{SNOWMAN}'
False

If this passes tests then I'm assuming that wsgiref is doing the inverse bug somewhere else.  I will look into it later, but this behavior is definitely broken.

----------
messages: 207418
nosy: aronacher
priority: normal
severity: normal
status: open
title: wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode

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

From report at bugs.python.org  Mon Jan  6 11:36:35 2014
From: report at bugs.python.org (Paul Moore)
Date: Mon, 06 Jan 2014 10:36:35 +0000
Subject: [New-bugs-announce] [issue20139] Python installer does not install
	a "pip" command (just	"pip3" and "pip3.4")
Message-ID: <1389004595.51.0.303248047302.issue20139@psf.upfronthosting.co.za>


New submission from Paul Moore:

The Python 3.4b2 installer for Windows does not install a "pip.exe" wrapper when the default options are selected. Only the "pip3.exe" and "pip3.4.exe" commands are provided.

The documentation for ensurepip makes it clear that this is the default behaviour, but there is no comment in either the PEP or in "Python Setup and Usage" stating that this is what happens. Also, I imagine that people will expect a "pip" command to be available by default, so an explanation of *why* only the versioned commands are installed should be added.

(It may be that having the unversioned command as well is actually the correct thing to do, on Windows if not on Unix - I can't recall the details of the discussion. If so, maybe the correct thing to do is to change the Windows installer behaviour).

----------
assignee: dstufft
components: Documentation
messages: 207423
nosy: dstufft, ncoghlan, pmoore
priority: normal
severity: normal
status: open
title: Python installer does not install a "pip" command (just "pip3" and "pip3.4")
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Jan  6 11:43:51 2014
From: report at bugs.python.org (=?utf-8?q?Jarek_=C5=9Amiejczak?=)
Date: Mon, 06 Jan 2014 10:43:51 +0000
Subject: [New-bugs-announce] [issue20140] UnicodeDecodeError in ntpath.py
	when home dir contains	non-ascii signs
Message-ID: <1389005031.99.0.692658963376.issue20140@psf.upfronthosting.co.za>


New submission from Jarek ?miejczak:

Full traceback:
https://gist.github.com/jarekps/2729ee1917ea372e6642

Error's starts in pip but after investigation of traceback it looks like it is python's issue (version 2.7.5).
Windows version: 8.1 Enterprise x64 with Polish language pack.
Feel free to ask if any additional information is necessary.

----------
components: Windows
messages: 207424
nosy: Jarek.?miejczak
priority: normal
severity: normal
status: open
title: UnicodeDecodeError in ntpath.py when home dir contains non-ascii signs
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Jan  6 14:12:14 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 06 Jan 2014 13:12:14 +0000
Subject: [New-bugs-announce] [issue20141] Argument Clinic: broken support
	for 'O!'
Message-ID: <1389013934.21.0.28397308089.issue20141@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

First, the documentation says that syntax for 'O!' conversion is
object(type='name_of_Python_type'), but actually the type argument should be the name of C structure which represents Python type. I.e. object(type='list') is rejected, and object(type='PyList_Type') is accepted.

Second, from this declaration

/*[clinic]
module spam
spam.ham

    items: object(type='PyList_Type')
    /

[clinic]*/

Argument Clinic generates following parsing code:

    if (!PyArg_ParseTuple(args,
        "O!:ham",
        PyList_Type, &items))
        goto exit;

It is wrong, should be &PyList_Type.

----------
assignee: docs at python
components: Build, Documentation
messages: 207430
nosy: docs at python, larry, serhiy.storchaka
priority: release blocker
severity: normal
status: open
title: Argument Clinic: broken support for 'O!'
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Mon Jan  6 15:05:53 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 06 Jan 2014 14:05:53 +0000
Subject: [New-bugs-announce] [issue20142] Argument Clinic: Py_buffer
	parameters are not initialized
Message-ID: <1389017153.04.0.847004275231.issue20142@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Argument Clinic doesn't initialize Py_buffer parameters. It generates cleanup code:

    /* Cleanup for data */
    if (data.buf)
       PyBuffer_Release(&data);

And if PyArg_ParseTuple() is failed, the buf attribute can contains arbitrary (non-NULL) data. This causes crash in PyBuffer_Release(). See issue20133 for working example.

----------
components: Build
files: spammodule.c
messages: 207433
nosy: larry, serhiy.storchaka
priority: release blocker
severity: normal
status: open
title: Argument Clinic: Py_buffer parameters are not initialized
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file33326/spammodule.c

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

From report at bugs.python.org  Mon Jan  6 15:19:53 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 06 Jan 2014 14:19:53 +0000
Subject: [New-bugs-announce] [issue20143] Argument Clinic: negative line
	numbers
Message-ID: <1389017993.56.0.244329561856.issue20143@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In case of error Argument Clinic sometimes reports negative line numbers.

----------
messages: 207434
nosy: larry, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Argument Clinic: negative line numbers
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Jan  6 15:23:13 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 06 Jan 2014 14:23:13 +0000
Subject: [New-bugs-announce] [issue20144] Argument Clinic doesn't support
	named constants as	default values
Message-ID: <1389018193.74.0.0273889485321.issue20144@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

For example it doesn't support PY_SSIZE_T_MAX as default value for Py_ssize_t argument. Is there any way to specify it? This is required for converting the _sre module.

----------
components: Build
messages: 207435
nosy: larry, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Argument Clinic doesn't support named constants as default values
versions: Python 3.4

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

From report at bugs.python.org  Mon Jan  6 15:28:17 2014
From: report at bugs.python.org (the mulhern)
Date: Mon, 06 Jan 2014 14:28:17 +0000
Subject: [New-bugs-announce] [issue20145] unittest.assert*Regex functions
	should verify that	expected_regex has a valid type
Message-ID: <1389018497.06.0.693451933582.issue20145@psf.upfronthosting.co.za>


New submission from the mulhern:

A normal thing for a developer to do is to convert a use of an assert* function to a use of an assert*Regex function and foolishly forget to actually specify the expected regular expression.

If they do this, the test will always pass because the callable expression will be in the place of the expected regular expression and the callable expression will, therefore, be None. It would be nice if in the constructor in AssertRaisesBaseContext (for 3.5) not only was the expected regex converted to a regex (if actually a string or bytes) but if it's not if it were checked if it were a valid regular expression object and an exception raised if this is not the case.

In the current version of AssertRaisesBaseContext.handle the comments say that if the callable object is None then the function is being used as a context manager. Not always the case, alas, perhaps the developer just forgot to add that necessary regular expression before the callable object.

----------
messages: 207436
nosy: the.mulhern
priority: normal
severity: normal
status: open
title: unittest.assert*Regex functions should verify that expected_regex has a valid type
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Jan  6 16:19:43 2014
From: report at bugs.python.org (Alexandru Gheorghe)
Date: Mon, 06 Jan 2014 15:19:43 +0000
Subject: [New-bugs-announce] [issue20146] UserDict module docs link is
	obsolete
Message-ID: <1389021583.36.0.157919967896.issue20146@psf.upfronthosting.co.za>


New submission from Alexandru Gheorghe:

FILE
    /usr/lib/python2.7/UserDict.py

MODULE DOCS
    http://docs.python.org/library/UserDict



Reference link to online documentation is invalid. (Probably) Should be: http://docs.python.org/library/userdict.html


Happens on Debian 7 Wheezy x86_64: 
Python 2.7.3 , [GCC 4.7.2] on linux2

----------
assignee: docs at python
components: Documentation
messages: 207441
nosy: docs at python, drunax
priority: normal
severity: normal
status: open
title: UserDict module docs link is obsolete
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Mon Jan  6 16:30:10 2014
From: report at bugs.python.org (Torsten Landschoff)
Date: Mon, 06 Jan 2014 15:30:10 +0000
Subject: [New-bugs-announce] [issue20147] multiprocessing.Queue.get() raises
	queue.Empty exception	if even if an item is available
Message-ID: <1389022210.55.0.898891193549.issue20147@psf.upfronthosting.co.za>


New submission from Torsten Landschoff:

The behaviour of multiprocessing.Queue surprised me today in that Queue.get() may raise an exception even if an item is immediately available. I tried to flush entries without blocking by using the timeout=0 keyword argument:
$ /opt/python3/bin/python3
Python 3.4.0b1 (default:247f12fecf2b, Jan  6 2014, 14:50:23) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from multiprocessing import Queue
>>> q = Queue()
>>> q.put("hi")
>>> q.get(timeout=0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/python3/lib/python3.4/multiprocessing/queues.py", line 107, in get
    raise Empty
queue.Empty

Actually even passing a small non-zero timeout will not give me my queue entry:
>>> q.get(timeout=1e-6)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/torsten/opensrc/cpython/Lib/multiprocessing/queues.py", line 107, in get
    raise Empty
queue.Empty

Expected behaviour for me would be to return the item that is in the queue. I know that there is a kwarg *block* which gives me the desired behaviour:
>>> q.get(block=False)
'hi'
In my case the get call is embedded in my own module which does not currently expose the block parameter. My local solution is of course to update the wrapper:

if timeout == 0:
    timeout = None
    block = False

However I see a few smells here in the python standard library. First, everything else seems to accept timeout=0 as nonblocking:

>>> import threading
>>> lock = threading.Lock()
>>> lock.acquire(timeout=0)
True
>>> from queue import Queue
>>> q = Queue()
>>> q.put("hi")
>>> q.get(timeout=0)
'hi'
Of special note is that queue.Queue behaves as I would have expected. IMHO it should be consistent with multiprocessing.Queue.

Also note that queue.Queue.get() and queue.Queue.put() name their blocking flag "block", while everybody else uses "blocking".

As a side note, I think the current approach is flawed in computing the deadline. Basically it does the following:

    deadline = time.time() + timeout
    if not self._rlock.acquire(block, timeout):
        raise Empty
    timeout = deadline - time.time()
    if timeout < 0 or not self._poll(timeout):
        raise Empty

On my system, just taking the time twice and computing the delta takes 2 microseconds:

>>> import time
>>> t0 = time.time(); time.time() - t0
2.384185791015625e-06

Therefore calling Queue.get(block, timeout) with 0 < timeout < 2e-6 will never return anything from the queue even though Queue.get(block=False) would do that. This contradicts the idea that Queue.get(block=False) will return faster than with block=True with any timeout > 0.

Apart from that, as Python does not currently support waiting on multiple sources, we currently often check a queue with a small timeout concurrently with doing other stuff. In case the system get really loaded, I would expect this to cause problems because the updated timeout may fall below zero.

Suggested patch attached.

----------
components: Library (Lib)
files: queue_timeout_0.diff
keywords: patch
messages: 207443
nosy: torsten
priority: normal
severity: normal
status: open
title: multiprocessing.Queue.get() raises queue.Empty exception if even if an item is available
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/file33327/queue_timeout_0.diff

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

From report at bugs.python.org  Mon Jan  6 17:04:28 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 06 Jan 2014 16:04:28 +0000
Subject: [New-bugs-announce] [issue20148] Convert the _sre module to use
	Argument Clinic
Message-ID: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is preliminary patch which converts the _sre module to use Argument Clinic. 22 functions are converted.

There are thre problems:

* Issue20141. The code was manually edited after Argument Clinic (and should be edited again for next run of Argument Clinic).

* Issue20144. Literal 1000000000 is temporary used instead of PY_SSIZE_T_MAX.

* Pydoc for _sre.compile (and only for this function) returns:

    _sre.compile = <built-in function compile>

----------
components: Extension Modules, Regular Expressions
messages: 207448
nosy: ezio.melotti, larry, mrabarnett, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Convert the _sre module to use Argument Clinic
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Jan  6 18:42:24 2014
From: report at bugs.python.org (Daniel Grace)
Date: Mon, 06 Jan 2014 17:42:24 +0000
Subject: [New-bugs-announce] [issue20149] 'with instance' references class's
	__enter__ attribute	rather than instance's
Message-ID: <1389030144.11.0.294634334929.issue20149@psf.upfronthosting.co.za>


New submission from Daniel Grace:

I was writing code for a class that uses one threading.RLock per object.  For convenience, I wanted to be able to use that lock's context manager and acquire/release methods without referencing the lock directly, so I opted to take a shortcut by assigning self.__enter__ = self.lock.__enter__ and so forth.

This fails in Python 3.3.1 (self-compiled on Debian) and both "3.3.2+" and "2.7.5+" (currently available Ubuntu packages).  Judging by the error messages, it looks 'with' is examining the __enter__ and __exit__ attributes defined on the instance's class, rather than those defined on the instance itself.

The workaround here is simple enough, but I'm under the impression that it shouldn't be needed anyways.

Test case follows:

import threading

class Foo(object):
#       Uncommenting these yields "NoneType is not callable" rather than an AttributeError
#       __enter__ = None
#       __exit__ = None
#       acquire = None
#       release = None
#       lock = None

        def __init__(self):
                self.lock = threading.RLock()
                print(repr(self.lock))
                self.__enter__ = self.lock.__enter__
                self.__exit__ = self.lock.__exit__
                self.acquire = self.lock.acquire
                self.release = self.lock.release

foo = Foo()
# These all function as expected.  The fourth line fails (correctly) on 2.7.5.
print(repr(foo.__enter__))
print(repr(foo.__exit__))
print(foo.__enter__())
print(foo.__exit__())

# This does not
with foo:
        pass

----------
components: Interpreter Core
messages: 207457
nosy: dewin
priority: normal
severity: normal
status: open
title: 'with instance' references class's __enter__ attribute rather than instance's
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon Jan  6 19:16:01 2014
From: report at bugs.python.org (Thomas Robitaille)
Date: Mon, 06 Jan 2014 18:16:01 +0000
Subject: [New-bugs-announce] [issue20150] API breakage in string formatting
	with :s option
Message-ID: <1389032161.42.0.577933973443.issue20150@psf.upfronthosting.co.za>


New submission from Thomas Robitaille:

The following code:

>>> "{0:s}".format([1,2,3])

no longer works in Python 3.4b1, and gives the following exception:

>>> "{0:s}".format([1,2,3])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: non-empty format string passed to object.__format__

This worked previously in Python 2.6-3.3:

>>> "{0:s}".format([1,2,3])
'[1, 2, 3]'

If this is a deliberate change, it should be included in the 'What's new in Python 3.4'

----------
components: Interpreter Core
messages: 207459
nosy: Thomas.Robitaille
priority: normal
severity: normal
status: open
title: API breakage in string formatting with :s option
versions: Python 3.4

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

From report at bugs.python.org  Mon Jan  6 20:49:08 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 06 Jan 2014 19:49:08 +0000
Subject: [New-bugs-announce] [issue20151] Convert the binascii module to use
	Argument Clinic
Message-ID: <1389037748.15.0.70999359123.issue20151@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which converts the binascii module to use Argument Clinic. 14 functions are converted.

There is one known issue. Pydoc doesn't show signature and docstring for several functions: a2b_qp, b2a_qp, crc32.

----------
components: Extension Modules
files: binascii_clinic.patch
keywords: patch
messages: 207473
nosy: larry, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Convert the binascii module to use Argument Clinic
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33332/binascii_clinic.patch

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

From report at bugs.python.org  Mon Jan  6 21:18:13 2014
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 06 Jan 2014 20:18:13 +0000
Subject: [New-bugs-announce] [issue20152] Use Argument Clinic with _imp
Message-ID: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Since _imp isn't directly exposed it isn't a priority to do the conversion, but for maintenance and such it should still occur.

----------
assignee: brett.cannon
messages: 207474
nosy: brett.cannon, larry
priority: low
severity: normal
stage: needs patch
status: open
title: Use Argument Clinic with _imp
versions: Python 3.4

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

From report at bugs.python.org  Mon Jan  6 22:58:43 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Jan 2014 21:58:43 +0000
Subject: [New-bugs-announce] [issue20153] New-in-3.4 weakref finalizer doc
	section is already out	of date.
Message-ID: <1389045523.36.0.692306072283.issue20153@psf.upfronthosting.co.za>


New submission from R. David Murray:

The following discussion section in the weakref docs:

http://docs.python.org/dev/library/weakref.html#comparing-finalizers-with-del-methods

which was added in 3.4, is out of date because of the GC improvements.  It should be tweaked to match the new reality.

(I've already deleted the Note under __callback__.)

----------
assignee: docs at python
components: Documentation
messages: 207489
nosy: docs at python, pitrou, r.david.murray, sbt
priority: normal
severity: normal
stage: needs patch
status: open
title: New-in-3.4 weakref finalizer doc section is already out of date.
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Jan  7 01:07:48 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 07 Jan 2014 00:07:48 +0000
Subject: [New-bugs-announce] [issue20154] Deadlock in
	asyncio.StreamReader.readexactly()
Message-ID: <1389053268.48.0.216080788193.issue20154@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

There's currently a deadlock in StreamReader.readexactly() -- if the requested size is larger than the buffer limit for pause, the transport may be paused with no way to unpause it.

See http://code.google.com/p/tulip/issues/detail?id=99 in the Tulip tracker.

----------
assignee: gvanrossum
messages: 207494
nosy: gvanrossum
priority: high
severity: normal
stage: test needed
status: open
title: Deadlock in asyncio.StreamReader.readexactly()
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Jan  7 01:19:11 2014
From: report at bugs.python.org (Jeff Allen)
Date: Tue, 07 Jan 2014 00:19:11 +0000
Subject: [New-bugs-announce] [issue20155] Regression test test_httpservers
	fails, hangs on Windows
Message-ID: <1389053951.39.0.997653737297.issue20155@psf.upfronthosting.co.za>


New submission from Jeff Allen:

When I run:
    start python -m test.test_httpservers

test_request_line_trimming reports ERROR, and the test hangs at test_version_none. If I run a copy of the test in which the latter test is skipped with @unittest.skipIf(sys.platform == "win32", "..."), the error report is:

======================================================================
ERROR: test_request_line_trimming (__main__.BaseHTTPServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_httpservers.py", line 122, in test_request_line_trimming
    res = self.con.getresponse()
  File "C:\Python33\lib\http\client.py", line 1131, in getresponse
    response.begin()
  File "C:\Python33\lib\http\client.py", line 354, in begin
    version, status, reason = self._read_status()
  File "C:\Python33\lib\http\client.py", line 316, in _read_status
    line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
  File "C:\Python33\lib\socket.py", line 297, in readinto
    return self._sock.recv_into(b)
ConnectionResetError: [WinError 10054] An existing connection was forcibly closed by the remote host

This is essentially the same for Python 2.7.6 and for the current development tip of Jython 2.7b1+, which is actually where the problem first manifested.

My machine is running 64-bit Windows 7 SP1, recently re-installed to a new, empty disk.

Careful testing, elaborating the failing tests, shows that what is sent in PUT and GET operations is not quite what is received. Something tampers with the connection between the client and the server. (Identical traffic where the verbs are not PUT and GET arrives as sent.) Something fiddles with the forward message, for example "correcting" the spurious \n in test_request_line_trimming to a full \r\n, and holding back the payload of a PUT even when it was in the first packet. On the reverse path, it appears to act on the error response itself by closing the connection, without passing it to the client.

Disabling the firewall (Windows Firewall and a commercial one), with the network cable unplugged, makes no difference. Nor does stopping anti-virus, anti-phishing, parental controls, etc.. However, stopping the Windows Basic Filtering Engine (BFE), makes the regression test run without error. Stopping the BFE takes out several dependent services, including Windows Firewall, but it seems likely the BFE itself is the culprit.

Although the cause lies in the platform, not in Python, it seems to me still an "issue" for Python that the tests fail on a common platform practically out of the box. I'll work on this in the context of the Jython test and report back here.

----------
components: Library (Lib), Windows
messages: 207497
nosy: jeff.allen
priority: normal
severity: normal
status: open
title: Regression test test_httpservers fails, hangs on Windows
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Tue Jan  7 05:04:43 2014
From: report at bugs.python.org (Joshua Chia)
Date: Tue, 07 Jan 2014 04:04:43 +0000
Subject: [New-bugs-announce] [issue20156] bz2.BZ2File.read() does not treat
	growing input file	properly
Message-ID: <1389067483.09.0.426788772717.issue20156@psf.upfronthosting.co.za>


New submission from Joshua Chia:

When using bz2.BZ2File to read an input file that is growing slowly, repeated read()ing eventually catches up to the end and subsequently fails to produce any more data while the input file continues growing.

In 2.7, the symptom is that read() keeps returning no data even after the file grows. In 3.3, the symptom is "EOFError: Compressed file ended before the end-of-stream marker was reached".

The correct behavior is to not consume partial compressed data during read() and be able to read() properly later after the input file grows. The EOFError should not be raised until close() is called and the file is found to not ending at an end-of-stream marker.

While some existing software may depend on the current behavior, the new behavior may break the existing software. However, predicating the new behavior on constructor parameter buffer being non-zero may mitigate incompatibility problems as using buffer during reading currently doesn't seem to make much sense.

To repro the problem, use the attached slow-copy.py to slowly copy a large-enough source bz2 file to a destination bz2 file. Then run the following script on the slowly-growing destination bz2 file:

import bz2
import sys
import time

if len(sys.argv) != 2:
    exit(1)

total = 0
with bz2.BZ2File(sys.argv[1], 'r', buffering=8192) as input:
    while True:
        bytes = input.read(8192)
        bytes = len(bytes)
        total += bytes
        print('{} {}'.format(total, bytes))
        if bytes < 8192:
            time.sleep(0.5)

----------
components: Library (Lib)
files: slow-copy.py
messages: 207506
nosy: Joshua.Chia
priority: normal
severity: normal
status: open
title: bz2.BZ2File.read() does not treat growing input file properly
type: behavior
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file33335/slow-copy.py

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

From report at bugs.python.org  Tue Jan  7 10:08:52 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 07 Jan 2014 09:08:52 +0000
Subject: [New-bugs-announce] [issue20157] Argument Clinic generates wrong
	keyword parameter name	for "default"
Message-ID: <1389085732.24.0.553020879492.issue20157@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

For the "default" keyword parameter Argument Clinic generates wrong name "default_value" in the _keywords array.

/*[clinic]
module spam
spam.ham

    default: int = 1

[clinic]*/

...

static PyObject *
spam_ham(PyModuleDef *module, PyObject *args, PyObject *kwargs)
{
    PyObject *return_value = NULL;
    static char *_keywords[] = {"default_value", NULL};
    int default_value = 1;

    if (!PyArg_ParseTupleAndKeywords(args, kwargs,
        "|i:ham", _keywords,
        &default_value))
        goto exit;
...

----------
components: Build
files: spammodule.c
messages: 207513
nosy: larry, serhiy.storchaka
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Argument Clinic generates wrong keyword parameter name for "default"
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33337/spammodule.c

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

From report at bugs.python.org  Tue Jan  7 10:12:09 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 07 Jan 2014 09:12:09 +0000
Subject: [New-bugs-announce] [issue20158] Argument Clinic: add --clean option
Message-ID: <1389085929.13.0.245678018197.issue20158@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

It will be helpful to add the --clean option for the clinic tool, which removes all Argument Clinic generated code.

----------
messages: 207515
nosy: larry, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Argument Clinic: add --clean option
type: enhancement

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

From report at bugs.python.org  Tue Jan  7 10:29:26 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 07 Jan 2014 09:29:26 +0000
Subject: [New-bugs-announce] [issue20159] Convert the ElementTree module to
	use Argument Clinic
Message-ID: <1389086966.47.0.33615845784.issue20159@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which converts xml.etree.ElementTree accelerator module to use Argument Clinic. 34 methods are converted. Not converted __init__ methods (is Argument Clinic support it?) and the SubElement function which seems can't be converted.

----------
components: Extension Modules, XML
files: etree_clinic.patch
keywords: patch
messages: 207518
nosy: eli.bendersky, larry, scoder, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Convert the ElementTree module to use Argument Clinic
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33338/etree_clinic.patch

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

From report at bugs.python.org  Tue Jan  7 10:37:54 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 07 Jan 2014 09:37:54 +0000
Subject: [New-bugs-announce] [issue20160] broken ctypes calling convention
	on MSVC / 64-bit	Windows (large structs)
Message-ID: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

The argument-passing code for passing structs larger than 8 bytes is broken on 64-bit Windows, leading to potential segmentation faults or other unpredictable behaviour.  According to 

   http://msdn.microsoft.com/en-us/library/zthk2dkh.aspx

structs not of size 1, 2, 4 or 8 bytes should be passed by pointer.  ctypes instead puts sizeof(struct) bytes onto the stack.  The offending code is in ffi_prep_args in /Modules/_ctypes/libffi_msvc/ffi.c, which apparently hasn't been kept up to date with the /Modules/_ctypes/libffi/src/x86/ffi.c.  The latter module works correctly: it has an extra #ifdef X86_WIN64 block (shown below) to take care of structs not of size 1, 2, 4 or 8. That block is missing in the libffi_msvc version.

      z = (*p_arg)->size;
#ifdef X86_WIN64
      if (z > sizeof(ffi_arg)
          || ((*p_arg)->type == FFI_TYPE_STRUCT
              && (z != 1 && z != 2 && z != 4 && z != 8))
#if FFI_TYPE_DOUBLE != FFI_TYPE_LONGDOUBLE
          || ((*p_arg)->type == FFI_TYPE_LONGDOUBLE)
#endif
          )
        {
          z = sizeof(ffi_arg);
          *(void **)argp = *p_argv;
        }
      else if ((*p_arg)->type == FFI_TYPE_FLOAT)
        {
          memcpy(argp, *p_argv, z);
        }
      else
#endif


It looks to me as though issue 17310 may be related.

Credit for this discovery should go to Freek Mank.

----------
components: ctypes
messages: 207520
nosy: mark.dickinson
priority: high
severity: normal
status: open
title: broken ctypes calling convention on MSVC / 64-bit Windows (large structs)
type: crash
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Jan  7 10:38:39 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 07 Jan 2014 09:38:39 +0000
Subject: [New-bugs-announce] [issue20161] inspect.signature fails on some
	functions which use	Argument Clinic
Message-ID: <1389087519.42.0.859376106795.issue20161@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

inspect.signature fails on some functions which use Argument Clinic. For example after applying issue20133 or issue20151 it fails for audioop.ratecv and binascii.a2b_qp.

>>> inspect.signature(audioop.ratecv)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 1468, in signature
    return Signature.from_builtin(obj)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 1989, in from_builtin
    p(name, default)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 1982, in p
    default = default.n
AttributeError: type object '_empty' has no attribute 'n'

----------
messages: 207521
nosy: larry, serhiy.storchaka
priority: release blocker
severity: normal
status: open
title: inspect.signature fails on some functions which use Argument Clinic
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Jan  7 14:22:35 2014
From: report at bugs.python.org (Yury V. Zaytsev)
Date: Tue, 07 Jan 2014 13:22:35 +0000
Subject: [New-bugs-announce] [issue20162] Test test_hash_distribution fails
	on RHEL 6.5 / ppc64
Message-ID: <1389100955.98.0.880527340764.issue20162@psf.upfronthosting.co.za>


New submission from Yury V. Zaytsev:

Hi,

When I try the following:

    ./python -m test -v test_hash

on a self-compiled Python 3.4.0b2 on RHEL 6.5 / ppc64, it fails. Please let me know which additional information I can supply to diagnose the problem.

The complete traceback below:

== CPython 3.4.0b2 (default, Jan 6 2014, 15:23:43) [GCC 4.4.7 20120313 (Red Hat 4.4.7-4)]
==   Linux-2.6.32-431.el6.ppc64-ppc64-with-redhat-6.5-Santiago big-endian
==   hash algorithm: siphash24 64bit
==   /XXX/build/test_python_13082
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
[1/1] test_hash
test_empty_string (test.test_hash.BytesHashRandomizationTests) ... ok
test_fixed_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_long_fixed_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_null_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_randomized_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_randomized_hash (test.test_hash.DatetimeDateTests) ... ok
test_randomized_hash (test.test_hash.DatetimeDatetimeTests) ... ok
test_randomized_hash (test.test_hash.DatetimeTimeTests) ... ok
test_hashes (test.test_hash.HashBuiltinsTestCase) ... ok
test_hash_distribution (test.test_hash.HashDistributionTestCase) ... FAIL
test_coerced_floats (test.test_hash.HashEqualityTestCase) ... ok
test_coerced_integers (test.test_hash.HashEqualityTestCase) ... ok
test_numeric_literals (test.test_hash.HashEqualityTestCase) ... ok
test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... ok
test_default_hash (test.test_hash.HashInheritanceTestCase) ... ok
test_error_hash (test.test_hash.HashInheritanceTestCase) ... ok
test_fixed_hash (test.test_hash.HashInheritanceTestCase) ... ok
test_hashable (test.test_hash.HashInheritanceTestCase) ... ok
test_not_hashable (test.test_hash.HashInheritanceTestCase) ... ok
test_empty_string (test.test_hash.MemoryviewHashRandomizationTests) ... ok
test_fixed_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok
test_long_fixed_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok
test_null_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok
test_randomized_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok
test_empty_string (test.test_hash.StrHashRandomizationTests) ... ok
test_fixed_hash (test.test_hash.StrHashRandomizationTests) ... ok
test_long_fixed_hash (test.test_hash.StrHashRandomizationTests) ... ok
test_null_hash (test.test_hash.StrHashRandomizationTests) ... ok
test_randomized_hash (test.test_hash.StrHashRandomizationTests) ... ok
test_ucs2_string (test.test_hash.StrHashRandomizationTests) ... ok

======================================================================
FAIL: test_hash_distribution (test.test_hash.HashDistributionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/XXX/Lib/test/test_hash.py", line 340, in test_hash_distribution
    self.assertGreater(len(s15), 8, prefix)
AssertionError: 1 not greater than 8 : abc

----------------------------------------------------------------------
Ran 30 tests in 0.694s

FAILED (failures=1)
1 test failed:
    test_hash

Thanks!

----------
components: Tests
messages: 207533
nosy: zaytsev
priority: normal
severity: normal
status: open
title: Test test_hash_distribution fails on RHEL 6.5 / ppc64
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Tue Jan  7 15:45:13 2014
From: report at bugs.python.org (dellair jie)
Date: Tue, 07 Jan 2014 14:45:13 +0000
Subject: [New-bugs-announce] [issue20163] ValueError: time data does not
	match format
Message-ID: <1389105913.13.0.195664624668.issue20163@psf.upfronthosting.co.za>


New submission from dellair jie:

Hello,

We are using Python 3.3.2 for HPUX11.31.

The following error happens only on HPUX, works on SunOS, RHEL, AIX.

python
Python 3.3.2 (default, Dec  9 2013, 14:04:25) [C] on hp-ux11
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import datetime
>>> datetime.strptime ("10-Dec-13.20:07:49", "%d-%b-%y.%H:%M:%S")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/python/lib/python3.3/_strptime.py", line 500, in _strptime_datetime
    tt, fraction = _strptime(data_string, format)
  File "/python/lib/python3.3/_strptime.py", line 337, in _strptime
    (data_string, format))
ValueError: time data '10-Dec-13.20:07:49' does not match format '%d-%b-%y.%H:%M:%S'

It looks like a bug. Could you please shed some lights?

Thanks in advance,

Br,
Li

----------
components: Library (Lib)
messages: 207542
nosy: dellair.jie
priority: normal
severity: normal
status: open
title: ValueError: time data does not match format
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Jan  7 17:15:27 2014
From: report at bugs.python.org (Chris Adams)
Date: Tue, 07 Jan 2014 16:15:27 +0000
Subject: [New-bugs-announce] [issue20164] Undocumented KeyError from
	os.path.expanduser
Message-ID: <1389111327.1.0.12442170212.issue20164@psf.upfronthosting.co.za>


New submission from Chris Adams:

This is a more general version of #10496: os.path.expanduser is documented as returning the unmodified string if it cannot be expanded (http://docs.python.org/3/library/os.path.html#os.path.expanduser) but there's one edge case where this can fail: when running without HOME in the environment:

https://github.com/python/cpython/blob/3.3/Lib/posixpath.py#L259-L263

In this case, pwd.getpwuid is called and although it's not documented as such, it raises a KeyError anytime the underlying POSIX getpwuid() call fails:

https://github.com/python/cpython/blob/3.3/Modules/pwdmodule.c#L119-L120

Reproducing this deliberately:

cadams at Io:~ $ sudo -H python
Python 2.7.5 (default, Aug 25 2013, 00:04:04) 
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import posix
>>> posix.setuid(1001)
>>> posix.seteuid(1001)
>>> os.environ.pop('HOME')
'/var/root'
>>> os.path.expanduser("~")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/posixpath.py", line 269, in expanduser
    userhome = pwd.getpwuid(os.getuid()).pw_dir
KeyError: 'getpwuid(): uid not found: 1001'

Context:
* https://github.com/toastdriven/django-haystack/issues/924
* https://github.com/kennethreitz/requests/issues/1846.

----------
components: Library (Lib)
messages: 207552
nosy: acdha
priority: normal
severity: normal
status: open
title: Undocumented KeyError from os.path.expanduser
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Tue Jan  7 20:25:21 2014
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 07 Jan 2014 19:25:21 +0000
Subject: [New-bugs-announce] [issue20165] unittest TestResult wasSuccessful
	returns True when	there are unexpected successes
Message-ID: <1389122721.74.0.155844601606.issue20165@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

Python 3.3.3+ (3.3:28337a8fb502+, Jan  7 2014, 01:32:44)
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import unittest
>>> r = unittest.result.TestResult()
>>> r.wasSuccessful()
True
>>> r.addUnexpectedSuccess("weird!")
>>> r.wasSuccessful()
True

An unexpected success is not a good thing and indicates a problem.

the wasSuccessful() method should include a check for len(self.unexpectedSuccesses) == 0 as part of its condition.

----------
assignee: gregory.p.smith
messages: 207582
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: unittest TestResult wasSuccessful returns True when there are unexpected successes
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Jan  7 20:48:38 2014
From: report at bugs.python.org (jarod)
Date: Tue, 07 Jan 2014 19:48:38 +0000
Subject: [New-bugs-announce] [issue20166] window x64 c-extensions not works
	on python3.4.0b2
Message-ID: <1389124118.85.0.0740185864803.issue20166@psf.upfronthosting.co.za>


New submission from jarod:

After installing python3.4.0b2.amd64 and rebuild modules, most of them stoped works. List of modules is [psutil, ujson].
Exception occurs on importing module:

import error: dynamic module does not define init function PyInit_<module_name>

and I found solution (workaround) - need change declaration of init function:

Line:
PyObject *PyInit_<module_name>(void)

was changed to:
PyMODINIT_FUNC PyInit_<module_name>(void)

and module works fine after rebuild.


All works fine with 3.4.0b1 and all alpha versions.
I have windows8.1 x64.

----------
components: Build, Windows
messages: 207584
nosy: jarod
priority: normal
severity: normal
status: open
title: window x64 c-extensions not works on python3.4.0b2
versions: Python 3.4

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

From report at bugs.python.org  Tue Jan  7 21:57:38 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 07 Jan 2014 20:57:38 +0000
Subject: [New-bugs-announce] [issue20167] Exception on IDLE closing
Message-ID: <1389128258.47.0.666257212012.issue20167@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

When run IDLE with file name as agument

$ ./python -m idlelib.idle Lib/decimal.py

and then close or exit it, following traceback is printed:

Exception ignored in: <bound method _ComplexBinder.__del__ of <idlelib.MultiCall._ComplexBinder object at 0xb5ead62c>>
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/idlelib/MultiCall.py", line 230, in __del__
  File "/home/serhiy/py/cpython/Lib/tkinter/__init__.py", line 1043, in unbind
_tkinter.TclError: can't invoke "bind" command:  application has been destroyed
Exception ignored in: <bound method _ComplexBinder.__del__ of <idlelib.MultiCall._ComplexBinder object at 0xb5eab92c>>
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/idlelib/MultiCall.py", line 230, in __del__
  File "/home/serhiy/py/cpython/Lib/tkinter/__init__.py", line 1043, in unbind
_tkinter.TclError: can't invoke "bind" command:  application has been destroyed
Exception ignored in: <bound method _ComplexBinder.__del__ of <idlelib.MultiCall._ComplexBinder object at 0xb5ea4e4c>>
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/idlelib/MultiCall.py", line 230, in __del__
  File "/home/serhiy/py/cpython/Lib/tkinter/__init__.py", line 1043, in unbind
_tkinter.TclError: can't invoke "bind" command:  application has been destroyed
Exception ignored in: <bound method _ComplexBinder.__del__ of <idlelib.MultiCall._ComplexBinder object at 0xb5ea46ec>>
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/idlelib/MultiCall.py", line 230, in __del__
  File "/home/serhiy/py/cpython/Lib/tkinter/__init__.py", line 1043, in unbind
_tkinter.TclError: can't invoke "bind" command:  application has been destroyed

This is occurred only in 3.4.

----------
components: IDLE
keywords: 3.4regression
messages: 207599
nosy: kbk, roger.serwy, serhiy.storchaka, terry.reedy
priority: high
severity: normal
status: open
title: Exception on IDLE closing
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Jan  7 22:03:59 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 07 Jan 2014 21:03:59 +0000
Subject: [New-bugs-announce] [issue20168] Derby: Convert the _tkinter module
	to use Argument Clinic
Message-ID: <1389128639.57.0.613370502446.issue20168@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In progress. Actually many functions are not very suitable for Argument Clinic.

----------
components: Extension Modules, Tkinter
messages: 207600
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Derby: Convert the _tkinter module to use Argument Clinic
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Jan  7 23:53:10 2014
From: report at bugs.python.org (Roy Smith)
Date: Tue, 07 Jan 2014 22:53:10 +0000
Subject: [New-bugs-announce] [issue20169] random module doc page has broken
	links
Message-ID: <1389135190.46.0.595431802912.issue20169@psf.upfronthosting.co.za>


New submission from Roy Smith:

On http://docs.python.org/2/library/random.html, the links to random() go to the module, not the function.  Thus:

Almost all module functions depend on the basic function random(),

If you lick on random(), you get to http://docs.python.org/2/library/random.html#module-random

This looks like the same problem as issue19416.

----------
assignee: docs at python
components: Documentation
messages: 207612
nosy: docs at python, roysmith
priority: normal
severity: normal
status: open
title: random module doc page has broken links
versions: Python 2.7

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

From report at bugs.python.org  Wed Jan  8 00:43:05 2014
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 07 Jan 2014 23:43:05 +0000
Subject: [New-bugs-announce] [issue20170] Derby #1: Convert 137 sites to
	Argument Clinic in	Modules/posixmodule.c
Message-ID: <1389138185.8.0.104398826507.issue20170@psf.upfronthosting.co.za>


New submission from Larry Hastings:

This issue is part of the Great Argument Clinic Conversion Derby,
where we're trying to convert as much of Python 3.4 to use
Argument Clinic as we can before Release Candidate 1 on January 19.

This issue asks you to change the following bundle of files:
    Modules/posixmodule.c: 137 sites

Talk to me (larry) if you only want to attack part of a bundle.

For instructions on how to convert a function to work with Argument
Clinic, read the "howto":
    http://docs.python.org/dev/howto/clinic.html

----------
assignee: larry
components: Library (Lib)
keywords: easy
messages: 207615
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Derby #1: Convert 137 sites to Argument Clinic in Modules/posixmodule.c
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan  8 00:43:56 2014
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 07 Jan 2014 23:43:56 +0000
Subject: [New-bugs-announce] [issue20171] Derby #2: Convert 115 sites to
	Argument Clinic in	Modules/_cursesmodule.c
Message-ID: <1389138236.79.0.916600121015.issue20171@psf.upfronthosting.co.za>


New submission from Larry Hastings:

This issue is part of the Great Argument Clinic Conversion Derby,
where we're trying to convert as much of Python 3.4 to use
Argument Clinic as we can before Release Candidate 1 on January 19.

This issue asks you to change the following bundle of files:
    Modules/_cursesmodule.c: 115 sites

Talk to me (larry) if you only want to attack part of a bundle.

For instructions on how to convert a function to work with Argument
Clinic, read the "howto":
    http://docs.python.org/dev/howto/clinic.html

----------
components: Library (Lib)
messages: 207616
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Derby #2: Convert 115 sites to Argument Clinic in Modules/_cursesmodule.c
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan  8 00:45:08 2014
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 07 Jan 2014 23:45:08 +0000
Subject: [New-bugs-announce] [issue20172] Derby #3: Convert 67 sites to
	Argument Clinic across 4	files (Windows)
Message-ID: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za>


New submission from Larry Hastings:

This issue is part of the Great Argument Clinic Conversion Derby,
where we're trying to convert as much of Python 3.4 to use
Argument Clinic as we can before Release Candidate 1 on January 19.

This issue asks you to change the following bundle of files:
    PC/msvcrtmodule.c: 18 sites
    PC/winreg.c: 24 sites
    PC/winsound.c: 3 sites
    Modules/_winapi.c: 22 sites

Talk to me (larry) if you only want to attack part of a bundle.

For instructions on how to convert a function to work with Argument
Clinic, read the "howto":
    http://docs.python.org/dev/howto/clinic.html

----------
components: Extension Modules
messages: 207617
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows)
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan  8 00:46:33 2014
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 07 Jan 2014 23:46:33 +0000
Subject: [New-bugs-announce] [issue20173] Derby #4: Convert 53 sites to
	Argument Clinic across 5	files
Message-ID: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za>


New submission from Larry Hastings:

This issue is part of the Great Argument Clinic Conversion Derby,
where we're trying to convert as much of Python 3.4 to use
Argument Clinic as we can before Release Candidate 1 on January 19.

This issue asks you to change the following bundle of files:
    Modules/_codecsmodule.c: 43 sites
    Modules/sha1module.c: 2 sites
    Modules/sha256module.c: 3 sites
    Modules/sha512module.c: 3 sites
    Modules/md5module.c: 2 sites

Talk to me (larry) if you only want to attack part of a bundle.

For instructions on how to convert a function to work with Argument
Clinic, read the "howto":
    http://docs.python.org/dev/howto/clinic.html

----------
components: Extension Modules
messages: 207618
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Derby #4: Convert 53 sites to Argument Clinic across 5 files
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan  8 00:47:41 2014
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 07 Jan 2014 23:47:41 +0000
Subject: [New-bugs-announce] [issue20174] Derby #5: Convert 50 sites to
	Argument Clinic across 3	files
Message-ID: <1389138461.92.0.709656306175.issue20174@psf.upfronthosting.co.za>


New submission from Larry Hastings:

This issue is part of the Great Argument Clinic Conversion Derby,
where we're trying to convert as much of Python 3.4 to use
Argument Clinic as we can before Release Candidate 1 on January 19.

This issue asks you to change the following bundle of files:
    Modules/socketmodule.c: 47 sites
    Modules/socketmodule.h: 1 sites
    Modules/_functoolsmodule.c: 2 sites

Talk to me (larry) if you only want to attack part of a bundle.

For instructions on how to convert a function to work with Argument
Clinic, read the "howto":
    http://docs.python.org/dev/howto/clinic.html

----------
components: Extension Modules
messages: 207619
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Derby #5: Convert 50 sites to Argument Clinic across 3 files
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan  8 00:48:19 2014
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 07 Jan 2014 23:48:19 +0000
Subject: [New-bugs-announce] [issue20175] Derby #6: Convert 50 sites to
	Argument Clinic across 8	files
Message-ID: <1389138499.96.0.517173661563.issue20175@psf.upfronthosting.co.za>


New submission from Larry Hastings:

This issue is part of the Great Argument Clinic Conversion Derby,
where we're trying to convert as much of Python 3.4 to use
Argument Clinic as we can before Release Candidate 1 on January 19.

This issue asks you to change the following bundle of files:
    Modules/_io/bufferedio.c: 13 sites
    Modules/_io/bytesio.c: 6 sites
    Modules/_io/fileio.c: 6 sites
    Modules/_io/iobase.c: 4 sites
    Modules/_io/stringio.c: 5 sites
    Modules/_io/textio.c: 8 sites
    Modules/_multiprocessing/multiprocessing.c: 3 sites
    Modules/_multiprocessing/semaphore.c: 5 sites

Talk to me (larry) if you only want to attack part of a bundle.

For instructions on how to convert a function to work with Argument
Clinic, read the "howto":
    http://docs.python.org/dev/howto/clinic.html

----------
components: Extension Modules
messages: 207620
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Derby #6: Convert 50 sites to Argument Clinic across 8 files
type: behavior

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

From report at bugs.python.org  Wed Jan  8 00:48:54 2014
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 07 Jan 2014 23:48:54 +0000
Subject: [New-bugs-announce] [issue20176] Derby #7: Convert 51 sites to
	Argument Clinic across 3	files
Message-ID: <1389138534.56.0.00725638903782.issue20176@psf.upfronthosting.co.za>


New submission from Larry Hastings:

This issue is part of the Great Argument Clinic Conversion Derby,
where we're trying to convert as much of Python 3.4 to use
Argument Clinic as we can before Release Candidate 1 on January 19.

This issue asks you to change the following bundle of files:
    Modules/_elementtree.c: 31 sites
    PC/_msi.c: 15 sites
    PC/bdist_wininst/install.c: 5 sites

Talk to me (larry) if you only want to attack part of a bundle.

For instructions on how to convert a function to work with Argument
Clinic, read the "howto":
    http://docs.python.org/dev/howto/clinic.html

----------
components: Extension Modules
messages: 207621
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Derby #7: Convert 51 sites to Argument Clinic across 3 files
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan  8 00:49:34 2014
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 07 Jan 2014 23:49:34 +0000
Subject: [New-bugs-announce] [issue20177] Derby #8: Convert 52 sites to
	Argument Clinic across 3	files
Message-ID: <1389138574.32.0.892814928986.issue20177@psf.upfronthosting.co.za>


New submission from Larry Hastings:

This issue is part of the Great Argument Clinic Conversion Derby,
where we're trying to convert as much of Python 3.4 to use
Argument Clinic as we can before Release Candidate 1 on January 19.

This issue asks you to change the following bundle of files:
    Modules/_datetimemodule.c: 20 sites
    Modules/timemodule.c: 8 sites
    Modules/_decimal/_decimal.c: 24 sites

Talk to me (larry) if you only want to attack part of a bundle.

For instructions on how to convert a function to work with Argument
Clinic, read the "howto":
    http://docs.python.org/dev/howto/clinic.html

----------
components: Extension Modules
messages: 207622
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Derby #8: Convert 52 sites to Argument Clinic across 3 files
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan  8 01:14:38 2014
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 08 Jan 2014 00:14:38 +0000
Subject: [New-bugs-announce] [issue20178] Derby #9: Convert 52 sites to
	Argument Clinic across 11	files
Message-ID: <1389140078.91.0.720761635456.issue20178@psf.upfronthosting.co.za>


New submission from Larry Hastings:

This issue is part of the Great Argument Clinic Conversion Derby,
where we're trying to convert as much of Python 3.4 to use
Argument Clinic as we can before Release Candidate 1 on January 19.

This issue asks you to change the following bundle of files:
    Modules/_ctypes/_ctypes.c: 8 sites
    Modules/_ctypes/_ctypes_test.c: 1 sites
    Modules/_ctypes/callproc.c: 14 sites
    Modules/_ctypes/stgdict.c: 0 sites
    Modules/_curses_panel.c: 3 sites
    Modules/_sqlite/cache.c: 1 sites
    Modules/_sqlite/connection.c: 12 sites
    Modules/_sqlite/cursor.c: 5 sites
    Modules/_sqlite/microprotocols.c: 1 sites
    Modules/_sqlite/module.c: 6 sites
    Modules/_sqlite/row.c: 1 sites

Talk to me (larry) if you only want to attack part of a bundle.

For instructions on how to convert a function to work with Argument
Clinic, read the "howto":
    http://docs.python.org/dev/howto/clinic.html

----------
components: Extension Modules
messages: 207634
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Derby #9: Convert 52 sites to Argument Clinic across 11 files
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan  8 01:15:20 2014
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 08 Jan 2014 00:15:20 +0000
Subject: [New-bugs-announce] [issue20179] Derby #10: Convert 50 sites to
	Argument Clinic across 4	files
Message-ID: <1389140120.63.0.492860390436.issue20179@psf.upfronthosting.co.za>


New submission from Larry Hastings:

This issue is part of the Great Argument Clinic Conversion Derby,
where we're trying to convert as much of Python 3.4 to use
Argument Clinic as we can before Release Candidate 1 on January 19.

This issue asks you to change the following bundle of files:
    Modules/overlapped.c: 21 sites
    Modules/_ssl.c: 20 sites
    Objects/bytes_methods.c: 1 sites
    Objects/bytesobject.c: 8 sites

Talk to me (larry) if you only want to attack part of a bundle.

For instructions on how to convert a function to work with Argument
Clinic, read the "howto":
    http://docs.python.org/dev/howto/clinic.html

----------
components: Extension Modules
messages: 207635
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Derby #10: Convert 50 sites to Argument Clinic across 4 files
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan  8 01:16:02 2014
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 08 Jan 2014 00:16:02 +0000
Subject: [New-bugs-announce] [issue20180] Derby #11: Convert 50 sites to
	Argument Clinic across 9	files
Message-ID: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za>


New submission from Larry Hastings:

This issue is part of the Great Argument Clinic Conversion Derby,
where we're trying to convert as much of Python 3.4 to use
Argument Clinic as we can before Release Candidate 1 on January 19.

This issue asks you to change the following bundle of files:
    Modules/_collectionsmodule.c: 4 sites
    Modules/itertoolsmodule.c: 11 sites
    Modules/_randommodule.c: 1 sites
    Objects/unicodeobject.c: 14 sites
    Modules/xxlimited.c: 4 sites
    Modules/xxmodule.c: 5 sites
    Modules/xxsubtype.c: 5 sites
    Objects/stringlib/find.h: 1 sites
    Objects/stringlib/transmogrify.h: 5 sites

Talk to me (larry) if you only want to attack part of a bundle.

For instructions on how to convert a function to work with Argument
Clinic, read the "howto":
    http://docs.python.org/dev/howto/clinic.html

----------
components: Extension Modules
messages: 207636
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Derby #11: Convert 50 sites to Argument Clinic across 9 files
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan  8 01:16:43 2014
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 08 Jan 2014 00:16:43 +0000
Subject: [New-bugs-announce] [issue20181] Derby #12: Convert 50 sites to
	Argument Clinic across 4	files
Message-ID: <1389140203.53.0.198441160626.issue20181@psf.upfronthosting.co.za>


New submission from Larry Hastings:

This issue is part of the Great Argument Clinic Conversion Derby,
where we're trying to convert as much of Python 3.4 to use
Argument Clinic as we can before Release Candidate 1 on January 19.

This issue asks you to change the following bundle of files:
    Objects/bytearrayobject.c: 13 sites
    Modules/parsermodule.c: 13 sites
    Modules/unicodedata.c: 12 sites
    Modules/readline.c: 12 sites

Talk to me (larry) if you only want to attack part of a bundle.

For instructions on how to convert a function to work with Argument
Clinic, read the "howto":
    http://docs.python.org/dev/howto/clinic.html

----------
components: Extension Modules
messages: 207637
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Derby #12: Convert 50 sites to Argument Clinic across 4 files
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan  8 01:17:37 2014
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 08 Jan 2014 00:17:37 +0000
Subject: [New-bugs-announce] [issue20182] Derby #13: Convert 50 sites to
	Argument Clinic across 5	files
Message-ID: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za>


New submission from Larry Hastings:

This issue is part of the Great Argument Clinic Conversion Derby,
where we're trying to convert as much of Python 3.4 to use
Argument Clinic as we can before Release Candidate 1 on January 19.

This issue asks you to change the following bundle of files:
    Modules/signalmodule.c: 12 sites
    Modules/selectmodule.c: 12 sites
    Modules/zlibmodule.c: 11 sites
    Python/sysmodule.c: 10 sites
    Modules/_hashopenssl.c: 5 sites

Talk to me (larry) if you only want to attack part of a bundle.

For instructions on how to convert a function to work with Argument
Clinic, read the "howto":
    http://docs.python.org/dev/howto/clinic.html

----------
components: Extension Modules
messages: 207639
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Derby #13: Convert 50 sites to Argument Clinic across 5 files
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan  8 01:18:09 2014
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 08 Jan 2014 00:18:09 +0000
Subject: [New-bugs-announce] [issue20183] Derby #14: Convert 50 sites to
	Argument Clinic across 6	files
Message-ID: <1389140289.9.0.366061884326.issue20183@psf.upfronthosting.co.za>


New submission from Larry Hastings:

This issue is part of the Great Argument Clinic Conversion Derby,
where we're trying to convert as much of Python 3.4 to use
Argument Clinic as we can before Release Candidate 1 on January 19.

This issue asks you to change the following bundle of files:
    Modules/mmapmodule.c: 10 sites
    Modules/_localemodule.c: 10 sites
    Modules/zipimport.c: 9 sites
    Modules/ossaudiodev.c: 9 sites
    Modules/_testbuffer.c: 9 sites
    Modules/_struct.c: 3 sites

Talk to me (larry) if you only want to attack part of a bundle.

For instructions on how to convert a function to work with Argument
Clinic, read the "howto":
    http://docs.python.org/dev/howto/clinic.html

----------
components: Extension Modules
messages: 207640
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Derby #14: Convert 50 sites to Argument Clinic across 6 files
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan  8 01:21:44 2014
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 08 Jan 2014 00:21:44 +0000
Subject: [New-bugs-announce] [issue20184] Derby #16: Convert 50 sites to
	Argument Clinic across 9	files
Message-ID: <1389140504.71.0.617730511292.issue20184@psf.upfronthosting.co.za>


New submission from Larry Hastings:

This issue is part of the Great Argument Clinic Conversion Derby,
where we're trying to convert as much of Python 3.4 to use
Argument Clinic as we can before Release Candidate 1 on January 19.

This issue asks you to change the following bundle of files:
    Modules/faulthandler.c: 7 sites
    Modules/_pickle.c: 7 sites
    Modules/_lzmamodule.c: 7 sites
    Python/bltinmodule.c: 6 sites
    Modules/termios.c: 6 sites
    Modules/syslogmodule.c: 6 sites
    Modules/_dbmmodule.c: 4 sites
    Modules/_gdbmmodule.c: 2 sites
    Modules/_json.c: 5 sites

Talk to me (larry) if you only want to attack part of a bundle.

For instructions on how to convert a function to work with Argument
Clinic, read the "howto":
    http://docs.python.org/dev/howto/clinic.html

----------
components: Extension Modules
messages: 207642
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Derby #16: Convert 50 sites to Argument Clinic across 9 files
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan  8 01:22:19 2014
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 08 Jan 2014 00:22:19 +0000
Subject: [New-bugs-announce] [issue20185] Derby #17: Convert 50 sites to
	Argument Clinic across 14	files
Message-ID: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za>


New submission from Larry Hastings:

This issue is part of the Great Argument Clinic Conversion Derby,
where we're trying to convert as much of Python 3.4 to use
Argument Clinic as we can before Release Candidate 1 on January 19.

This issue asks you to change the following bundle of files:
    Objects/typeobject.c: 5 sites
    Objects/longobject.c: 5 sites
    Objects/listobject.c: 5 sites
    Objects/floatobject.c: 4 sites
    Modules/resource.c: 4 sites
    Modules/_threadmodule.c: 4 sites
    Modules/_bz2module.c: 4 sites
    Modules/_bisectmodule.c: 4 sites
    Python/marshal.c: 3 sites
    Objects/exceptions.c: 3 sites
    Modules/nismodule.c: 3 sites
    Modules/gcmodule.c: 3 sites
    Python/_warnings.c: 2 sites
    Modules/_cryptmodule.c: 1 sites

Talk to me (larry) if you only want to attack part of a bundle.

For instructions on how to convert a function to work with Argument
Clinic, read the "howto":
    http://docs.python.org/dev/howto/clinic.html

----------
components: Extension Modules
messages: 207643
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Derby #17: Convert 50 sites to Argument Clinic across 14 files
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan  8 01:23:06 2014
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 08 Jan 2014 00:23:06 +0000
Subject: [New-bugs-announce] [issue20186] Derby #18: Convert 31 sites to
	Argument Clinic across 23	files
Message-ID: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za>


New submission from Larry Hastings:

This issue is part of the Great Argument Clinic Conversion Derby,
where we're trying to convert as much of Python 3.4 to use
Argument Clinic as we can before Release Candidate 1 on January 19.

This issue asks you to change the following bundle of files:
    Objects/tupleobject.c: 2 sites
    Objects/memoryobject.c: 2 sites
    Objects/descrobject.c: 2 sites
    Objects/complexobject.c: 2 sites
    Modules/_operator.c: 2 sites
    Modules/_opcode.c: 2 sites
    Modules/_lsprof.c: 2 sites
    Modules/_heapqmodule.c: 2 sites
    Objects/weakrefobject.c: 1 sites
    Objects/structseq.c: 1 sites
    Objects/rangeobject.c: 1 sites
    Objects/object.c: 1 sites
    Objects/moduleobject.c: 1 sites
    Objects/funcobject.c: 1 sites
    Objects/fileobject.c: 1 sites
    Objects/enumobject.c: 1 sites
    Objects/codeobject.c: 1 sites
    Objects/boolobject.c: 1 sites
    Modules/symtablemodule.c: 1 sites
    Modules/mathmodule.c: 1 sites
    Modules/_tracemalloc.c: 1 sites
    Modules/_io/_iomodule.c: 1 sites
    Modules/_csv.c: 1 sites

Talk to me (larry) if you only want to attack part of a bundle.

For instructions on how to convert a function to work with Argument
Clinic, read the "howto":
    http://docs.python.org/dev/howto/clinic.html

----------
components: Extension Modules
messages: 207644
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Derby #18: Convert 31 sites to Argument Clinic across 23 files
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan  8 01:31:45 2014
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 08 Jan 2014 00:31:45 +0000
Subject: [New-bugs-announce] [issue20187] The Great Argument Clinic
	Conversion Derby Meta-Issue
Message-ID: <1389141105.5.0.459903580868.issue20187@psf.upfronthosting.co.za>


New submission from Larry Hastings:

This is a meta-issue tracking all the Argument Clinic Derby sub-issues.

----------
assignee: larry
components: email
messages: 207649
nosy: barry, larry, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: The Great Argument Clinic Conversion Derby Meta-Issue
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan  8 04:52:59 2014
From: report at bugs.python.org (Mark Nottingham)
Date: Wed, 08 Jan 2014 03:52:59 +0000
Subject: [New-bugs-announce] [issue20188] ALPN support for TLS
Message-ID: <1389153179.88.0.510995543218.issue20188@psf.upfronthosting.co.za>


New submission from Mark Nottingham:

In #14204, support for NPN was added. Subsequently, NPN has been superseded by ALPN in the IETF, and support for it is coming in OpenSSL 1.0.2.

http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg
http://rt.openssl.org/Ticket/Display.html?id=3073
http://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=NEWS

----------
components: Extension Modules
messages: 207660
nosy: mnot
priority: normal
severity: normal
status: open
title: ALPN support for TLS
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Jan  8 13:47:40 2014
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 08 Jan 2014 12:47:40 +0000
Subject: [New-bugs-announce] [issue20189] inspect.Signature doesn't
	recognize all builtin types
Message-ID: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Stefan added some docstring text signatures by hand, only to discover that inspect.Signature still didn't recognize them.  Specifically, decimal.Decimal.compare was unrecognized.  This is a method_descriptor object, which is a type that isn't even exposed in types.

Rather than go on a search-and-destroy mission for all these different builtin types, I'm going to change inspect.Signature so as a fallback at the end it says "if it has a __call__ and a valid __text_signature__, just use that".

----------
assignee: larry
components: Library (Lib)
messages: 207681
nosy: larry, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: inspect.Signature doesn't recognize all builtin types
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan  8 14:35:00 2014
From: report at bugs.python.org (=?utf-8?q?Martin_H=C3=A4cker?=)
Date: Wed, 08 Jan 2014 13:35:00 +0000
Subject: [New-bugs-announce] [issue20190] dict() in dict(foo='bar') raises
Message-ID: <1389188100.33.0.555885401078.issue20190@psf.upfronthosting.co.za>


New submission from Martin H?cker:

I was quite surprised by this behavior:

>>> dict() in [dict()]
True
>>> dict() in []
False
>>> dict() in dict(foo='bar').keys()
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'dict'
>>> dict() in list(dict(foo='bar').keys())
False

I think it should change. Calling dict.keys() one expects to get list like behavior and not having to ensure that everything that is checked for inclusion there has to be hasheable.

If it helps, this is also a regression from python 2.6/7 where this works as expected.

----------
messages: 207683
nosy: dwt
priority: normal
severity: normal
status: open
title: dict() in dict(foo='bar') raises
versions: Python 3.2

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

From report at bugs.python.org  Wed Jan  8 15:33:42 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jan 2014 14:33:42 +0000
Subject: [New-bugs-announce] [issue20191] resource.prlimit(int, int,
	str) crashs
Message-ID: <1389191622.9.0.0763750909735.issue20191@psf.upfronthosting.co.za>


New submission from STINNER Victor:

$ ./python -c 'import resource; resource.prlimit(-3, 11, "\udbff\udfff")'
Erreur de segmentation (core dumped)

The problem is a generic problem with PyArg_Parse functions and "(O)" format. With this format, the caller does not hold a reference to the object nor the tuple. If arbitrary Python code is executed before the object is used, the object pointer becomes a dangling pointer.

resource.prlimit() uses:

    if (!PyArg_ParseTuple(args, _Py_PARSE_PID "i|(OO):prlimit",
                          &pid, &resource, &curobj, &maxobj))
        return NULL;

In this issue, it's worse: the string is casted to a sequence, and each string character becomes a temporary substring of 1 character. The problem is that PyArg_ParseTuple() nor resource_prlimit() hold the reference, and so the curobj and maxobj are dangling pointer.

Options:

- raise an error if the second parameter is not a tuple: implement the check in prlimit() or i PyArg_ParseTuple()?
- hold a reference to the sequence, to curobj and to maxobj instead of using borrowed references

----------
messages: 207686
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: resource.prlimit(int, int, str) crashs
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan  8 18:37:11 2014
From: report at bugs.python.org (Joseph Bylund)
Date: Wed, 08 Jan 2014 17:37:11 +0000
Subject: [New-bugs-announce] [issue20192] pprint chokes on set containing
	frozenset
Message-ID: <1389202631.98.0.662803177988.issue20192@psf.upfronthosting.co.za>


New submission from Joseph Bylund:

Expected: pprint the object
Observed: crash with:
set([Traceback (most recent call last):
  File "./test.py", line 7, in <module>
    pp.pprint(myset)
  File "/usr/lib/python2.7/pprint.py", line 117, in pprint
    self._format(object, self._stream, 0, 0, {}, 0)
  File "/usr/lib/python2.7/pprint.py", line 194, in _format
    object = _sorted(object)
  File "/usr/lib/python2.7/pprint.py", line 82, in _sorted
    return sorted(iterable)
TypeError: can only compare to a set


Steps to repro:
#!/usr/bin/python
import pprint
pp = pprint.PrettyPrinter(indent=4)

myset = set(xrange(3))
myset.add(frozenset(xrange(10)))
pp.pprint(myset)

----------
messages: 207693
nosy: jbylund
priority: normal
severity: normal
status: open
title: pprint chokes on set containing frozenset
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Wed Jan  8 20:03:31 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 08 Jan 2014 19:03:31 +0000
Subject: [New-bugs-announce] [issue20193] Derby: Convert the zlib,
	_bz2 and _lzma modules to use Argument Clinic
Message-ID: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In progress. These modules have similar interfaces and common maintainer.

----------
assignee: serhiy.storchaka
components: Extension Modules
messages: 207696
nosy: nadeem.vawda, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan  8 20:58:31 2014
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 08 Jan 2014 19:58:31 +0000
Subject: [New-bugs-announce] [issue20194] Add :deprecated: marker to
	formatter docs
Message-ID: <1389211111.33.0.543249498103.issue20194@psf.upfronthosting.co.za>


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


----------
assignee: brett.cannon
components: Documentation
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Add :deprecated: marker to formatter docs
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan  8 20:58:47 2014
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 08 Jan 2014 19:58:47 +0000
Subject: [New-bugs-announce] [issue20195] Add :deprecated: marker to imp docs
Message-ID: <1389211127.27.0.285308920291.issue20195@psf.upfronthosting.co.za>


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


----------
assignee: brett.cannon
components: Documentation
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Add :deprecated: marker to imp docs
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan  8 22:17:00 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 08 Jan 2014 21:17:00 +0000
Subject: [New-bugs-announce] [issue20196] Argument Clinic generates invalid
	code for optional	parameter
Message-ID: <1389215820.54.0.23969623905.issue20196@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Argument Clinic generates invalid code for optional parameter if there are no mandatory parameters except self. Example:

/*[clinic input]
zlib.Decompress.flush

    self: self(type="compobject *")
    [
    length: uint
        the initial size of the output buffer.
    ]
    /

Return a bytes object containing any remaining decompressed data.
[clinic start generated code]*/

Generates:

...
    switch (PyTuple_Size(args)) {
        case 0:
            if (!PyArg_ParseTuple(args, ":flush", ))
                return NULL;
            break;
...

Note a comma in PyArg_ParseTuple.

----------
components: Build
messages: 207700
nosy: larry, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Argument Clinic generates invalid code for optional parameter
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan  8 22:38:19 2014
From: report at bugs.python.org (Fabrice Aneche)
Date: Wed, 08 Jan 2014 21:38:19 +0000
Subject: [New-bugs-announce] [issue20197] Support WebP image format
	detection in imghdr module
Message-ID: <1389217099.41.0.299916311184.issue20197@psf.upfronthosting.co.za>


New submission from Fabrice Aneche:

Detect the webp file format (RIFF container + WEBP), return webp as format detected.

----------
components: Library (Lib)
files: imghdr_webp.patch
keywords: patch
messages: 207702
nosy: akhenakh, gregory.p.smith
priority: normal
severity: normal
status: open
title: Support WebP image format detection in imghdr module
type: enhancement
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file33366/imghdr_webp.patch

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

From report at bugs.python.org  Thu Jan  9 02:35:08 2014
From: report at bugs.python.org (bagrat lazaryan)
Date: Thu, 09 Jan 2014 01:35:08 +0000
Subject: [New-bugs-announce] [issue20198]
	xml.etree.ElementTree.ElementTree.write attribute sorting
Message-ID: <1389231308.67.0.0933451284696.issue20198@psf.upfronthosting.co.za>


New submission from bagrat lazaryan:

xml.etree.ElementTree.ElementTree.write method (and, as a derivative, xml.etree.ElementTree.tostring function) sorts attributes in lexical order. while an admissible behavior instead of the randomness inherited from ordinary dict, this prevents a picky user to have her own custom ordering by passing an OrderedDict to Element, SubElement and the like (i guess there are none). that is to say:

if
-----------------------------------
e = Element("tag", OrderedDict([("a", "a"), ("c", "c"), ("b", "b")]))
-----------------------------------
then both
-----------------------------------
tostring(e)
ElementTree(e).write("xml.xml")
-----------------------------------
will result in
-----------------------------------
<tag a="a" b="b" c="c" />
-----------------------------------
while the intention of the user was
-----------------------------------
<tag a="a" c="c" b="b" />

----------
components: Library (Lib)
messages: 207721
nosy: bagratte
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree.ElementTree.write attribute sorting
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu Jan  9 03:07:02 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Jan 2014 02:07:02 +0000
Subject: [New-bugs-announce] [issue20199] status of module_for_loader and
	utils._module_to_load
Message-ID: <1389233222.57.0.373422642128.issue20199@psf.upfronthosting.co.za>


New submission from R. David Murray:

The whatsnew currently says that module_for_loader is pending deprecation in favor of utils.module_to_load, but there is no such function.  Instead there is a private function utils._module_to_load...even though there is a news entry that claimed that the non-private name was added (but there are no docs for it, nor any associated issue number).

So, importlib experts, can you clean up the docs and/or code please? :)

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 207723
nosy: brett.cannon, docs at python, eric.snow, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: status of module_for_loader and utils._module_to_load
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Jan  9 03:17:50 2014
From: report at bugs.python.org (Ryan Smith-Roberts)
Date: Thu, 09 Jan 2014 02:17:50 +0000
Subject: [New-bugs-announce] [issue20200] Argument Clinic howto: custom
	self_converter example	broken
Message-ID: <1389233870.77.0.302352935939.issue20200@psf.upfronthosting.co.za>


New submission from Ryan Smith-Roberts:

The custom converter declaration is wrapped with [clinic input] when it should be [python input].

Patch attached.

----------
files: argument_clinic_docfix.patch
keywords: patch
messages: 207724
nosy: rmsr
priority: normal
severity: normal
status: open
title: Argument Clinic howto: custom self_converter example broken
Added file: http://bugs.python.org/file33371/argument_clinic_docfix.patch

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

From report at bugs.python.org  Thu Jan  9 05:39:56 2014
From: report at bugs.python.org (Ryan Smith-Roberts)
Date: Thu, 09 Jan 2014 04:39:56 +0000
Subject: [New-bugs-announce] [issue20201] Argument Clinic: rwbuffer support
	broken
Message-ID: <1389242396.52.0.166931579233.issue20201@psf.upfronthosting.co.za>


New submission from Ryan Smith-Roberts:

Following the howto's instructions on the new syntax for the 'w*' argument, one gets an exception:

...
  File "Tools/clinic/clinic.py", line 1780, in converter_init
    elif types == (bytearray_type | rwuffer_type):
NameError: global name 'rwuffer_type' is not defined

Easy fix, patch attached.

----------
files: argument_clinic_rwbuffer.patch
keywords: patch
messages: 207726
nosy: rmsr
priority: normal
severity: normal
status: open
title: Argument Clinic: rwbuffer support broken
Added file: http://bugs.python.org/file33373/argument_clinic_rwbuffer.patch

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

From report at bugs.python.org  Thu Jan  9 07:47:42 2014
From: report at bugs.python.org (Ryan Smith-Roberts)
Date: Thu, 09 Jan 2014 06:47:42 +0000
Subject: [New-bugs-announce] [issue20202] ArgumentClinic howto: document
	change in Py_buffer	lifecycle management
Message-ID: <1389250062.45.0.978565094508.issue20202@psf.upfronthosting.co.za>


New submission from Ryan Smith-Roberts:

Almost didn't catch that PyBuffer_Release isn't needed. Also we need a verb/adjective for applying AC. Cure?

"zlibmodule has already been cured."

----------
assignee: docs at python
components: Documentation
messages: 207728
nosy: docs at python, larry, rmsr
priority: normal
severity: normal
status: open
title: ArgumentClinic howto: document change in Py_buffer lifecycle management
versions: Python 3.4

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

From report at bugs.python.org  Thu Jan  9 09:03:20 2014
From: report at bugs.python.org (Ryan Smith-Roberts)
Date: Thu, 09 Jan 2014 08:03:20 +0000
Subject: [New-bugs-announce] [issue20203] ArgumentClinic: support middle
	optional argument
Message-ID: <1389254600.21.0.692966775904.issue20203@psf.upfronthosting.co.za>


New submission from Ryan Smith-Roberts:

socket.sendto is apparently even weirder than addch or range: the optional argument is in the *middle*. Attempting this configuration gets me:

Function sendto has an unsupported group configuration. (Unexpected state 5)

An expected unexpected configuration? :)

----------
components: Build
messages: 207731
nosy: larry, rmsr
priority: normal
severity: normal
status: open
title: ArgumentClinic: support middle optional argument
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Jan  9 13:47:35 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 09 Jan 2014 12:47:35 +0000
Subject: [New-bugs-announce] [issue20204] pydocs fails for some C
	implemented classes
Message-ID: <1389271655.86.0.224685657695.issue20204@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In 3.4 pydoc fails for the TkappType and TkttType names in the _tkinter module.

$ ./python -m pydoc _tkinter.TkappType
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/runpy.py", line 189, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/serhiy/py/cpython/Lib/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 2593, in <module>
    cli()
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 2558, in cli
    help.help(arg)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1840, in help
    elif request: doc(request, 'Help on %s:', output=self._output)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1578, in doc
    pager(render_doc(thing, title, forceload))
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1555, in render_doc
    module = inspect.getmodule(object)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 610, in getmodule
    file = getabsfile(object, _filename)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 593, in getabsfile
    _filename = getsourcefile(object) or getfile(object)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 569, in getsourcefile
    filename = getfile(object)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 519, in getfile
    object = sys.modules.get(object.__module__)
AttributeError: __module__

And same for _tkinter.TkttType.

This issue can be easy fixed for the _tkinter module, but general solution is needed, because pydoc in 3.4 still can be broken for third-party code.

----------
files: tkinter_typespecs.patch
keywords: 3.4regression, patch
messages: 207733
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: pydocs fails for some C implemented classes
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33375/tkinter_typespecs.patch

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

From report at bugs.python.org  Thu Jan  9 14:18:49 2014
From: report at bugs.python.org (=?utf-8?q?Stefan_M=C3=BCller?=)
Date: Thu, 09 Jan 2014 13:18:49 +0000
Subject: [New-bugs-announce] [issue20205] inspect.getsource(),
	P302 loader and '<..>' filenames
Message-ID: <1389273529.73.0.188399599981.issue20205@psf.upfronthosting.co.za>


New submission from Stefan M?ller:

Following situation

* python 2.7.6

* module loaded via a PEP302 loader.

* the loader has get_source(fullname)

* assigns a dummy string as a file: module.__file__ == "<mymodule>"

Then

inspect.getsource(module)

throws

IOError: could not get source code

I tired to track this down, and it seems to be caused by  linecache.updatecache(..) with has

    if not filename or (filename.startswith('<') and filename.endswith('>')):
        return []

at the beginning.

This seems too restrictive me. Without the 'if' it would try to read the file from disk, and if that fails check if there is a loader, without a loader it returns [], so there would not be any behaviour change for non-loader modules if the 'if' was removed, only an additional disk access.

I suggest to remove the 'if'.

Workaround: Don't use '<>' for the dummy file name, but I've read somewhere that those '<>' are a convention for such use-cases.

----------
components: Library (Lib)
messages: 207736
nosy: stefan.mueller
priority: normal
severity: normal
status: open
title: inspect.getsource(), P302 loader and '<..>' filenames
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Jan  9 15:21:58 2014
From: report at bugs.python.org (Andras Timar)
Date: Thu, 09 Jan 2014 14:21:58 +0000
Subject: [New-bugs-announce] [issue20206] email quoted-printable encoding
	issue
Message-ID: <1389277318.78.0.594676720592.issue20206@psf.upfronthosting.co.za>


New submission from Andras Timar:

Try this sample script:

# coding=utf-8
import email
import email.charset
import email.message

c = email.charset.Charset('utf-8')
c.body_encoding = email.charset.QP
m = email.message.Message()
m.set_payload("This is a Greek letter upsilon: ?", c)
print(m.as_string())

Actual result: "This is a Greek letter upsilon: =CF" 
Expected result: "This is a Greek letter upsilon: =CF=85"

----------
components: Library (Lib)
messages: 207737
nosy: timar
priority: normal
severity: normal
status: open
title: email quoted-printable encoding issue
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Jan  9 17:48:05 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Thu, 09 Jan 2014 16:48:05 +0000
Subject: [New-bugs-announce] [issue20207] Disable SSLv2 in Python 2.x
Message-ID: <1389286085.44.0.640334918111.issue20207@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

SSLv2 has numerous security issues, and thus is in limited use on the web. Continuing to allow SSLv2 handshakes only serves to limit security.

----------
components: Library (Lib)
messages: 207748
nosy: alex
priority: normal
severity: normal
status: open
title: Disable SSLv2 in Python 2.x
versions: Python 2.7

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

From report at bugs.python.org  Thu Jan  9 18:10:37 2014
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 09 Jan 2014 17:10:37 +0000
Subject: [New-bugs-announce] [issue20208] Clarify some things in porting
	HOWTO
Message-ID: <1389287437.04.0.882737818643.issue20208@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Reported on my G+ share of the latest reworking:

"""
The only part I found confusing is when you first introduce "from _future_ import unicode_literals" --- it looks like you forgot to explain what it does. It turns out that you explain it somewhat two paragraphs below it, so maybe you can just move this down a bit?

Maybe "bytes literals" section should be called "Bytes and unicode literals" or something and move the "unicode_literals" line in there.
"""

"""
The only issue I noticed is that "Eliminate -3 Warnings" section still mentions 2to3 before it's even introduced.?
"""

----------
assignee: brett.cannon
components: Documentation
messages: 207756
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Clarify some things in porting HOWTO
versions: Python 3.4

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

From report at bugs.python.org  Thu Jan  9 18:23:59 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 09 Jan 2014 17:23:59 +0000
Subject: [New-bugs-announce] [issue20209] Deprecate PROTOCOL_SSLv2
Message-ID: <1389288239.29.0.63100261927.issue20209@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

It sounds like we may deprecate PROTOCOL_SSLv2 in 3.5.

----------
components: Library (Lib)
messages: 207762
nosy: christian.heimes, giampaolo.rodola, janssen, pitrou
priority: low
severity: normal
status: open
title: Deprecate PROTOCOL_SSLv2
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Thu Jan  9 23:52:42 2014
From: report at bugs.python.org (Thomas Petazzoni)
Date: Thu, 09 Jan 2014 22:52:42 +0000
Subject: [New-bugs-announce] [issue20210] Provide configure options to
	enable/disable Python	modules and extensions
Message-ID: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za>


New submission from Thomas Petazzoni:

In the context of space-constrained embedded Linux systems, installing the entire set of Python modules and extensions is not necessarily desirable. For example, all the test modules, as well as certain extensions requiring third-parties libraries are often unnecessary, and uselessly consume precious storage on the embedded Linux system.

While we could certainly remove these undesired modules and extensions manually, it is much more convenient to have configuration options to selectively enable and disable them. Another very strong benefit of having configuration options is that we can actually *disable* the build of these unneeded modules and extensions, therefore saving a lot of build time, which is very nice when you're repeatedly cross-compiling an entire embedded Linux system.

The proposed set of patches add several --enable-<foo>/--disable-<foo> options to enable/disable certain Python modules and extensions. These patches have been part of Buildroot, an embedded Linux build system (used for example by Google, and many embedded processor vendors, as well as a huge number of embedded system makers) for a while, and are useful to all our users using Python on their embedded Linux systems. Instead of carrying them around, we would like to have them merged in upstream Python.

Of course, we are definitely open to discussion on the approach to take to implement this configurability, and I'm ready to rework the patches according to the comments received here.

Thanks!

----------
components: Build
messages: 207802
nosy: thomas-petazzoni
priority: normal
severity: normal
status: open
title: Provide configure options to enable/disable Python modules and extensions
versions: Python 3.5

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

From report at bugs.python.org  Fri Jan 10 00:02:08 2014
From: report at bugs.python.org (Thomas Petazzoni)
Date: Thu, 09 Jan 2014 23:02:08 +0000
Subject: [New-bugs-announce] [issue20211] setup.py: do not add invalid
	header locations
Message-ID: <1389308528.92.0.403642458985.issue20211@psf.upfronthosting.co.za>


New submission from Thomas Petazzoni:

In the cross-compilation case, setup.py incorrectly adds /usr/include to self.compiler.include_dirs, and results in the following invalid compilation line:

/home/thomas/projets/buildroot/output/host/usr/bin/arm-none-linux-gnueabi-gcc
  -fPIC -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g
  -O3 -Wall -Wstrict-prototypes -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
  -D_FILE_OFFSET_BITS=64 -pipe -Os
  -I./Include -I/usr/include -I. -IInclude
  -I/home/thomas/projets/buildroot/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include
  -I/home/thomas/projets/buildroot/output/build/python3-3.4.0b1/Include
  -I/home/thomas/projets/buildroot/output/build/python3-3.4.0b1
  -c /home/thomas/projets/buildroot/output/build/python3-3.4.0b1/Modules/_struct.c
  -o build/temp.linux-arm-3.4/home/thomas/projets/buildroot/output/build/python3-3.4.0b1/Modules/_struct.o
cc1: warning: include location "/usr/include" is unsafe for cross-compilation [-Wpoison-system-directories]

The -I/usr/include is wrong when cross compiling, so we disable adding INCLUDEDIR and LIBDIR from the host when cross compiling.

----------
components: Cross-Build
files: 0001-setup.py-do-not-add-invalid-header-locations.patch
keywords: patch
messages: 207805
nosy: thomas-petazzoni
priority: normal
severity: normal
status: open
title: setup.py: do not add invalid header locations
type: compile error
versions: Python 3.4
Added file: http://bugs.python.org/file33393/0001-setup.py-do-not-add-invalid-header-locations.patch

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

From report at bugs.python.org  Fri Jan 10 00:03:07 2014
From: report at bugs.python.org (Thomas Petazzoni)
Date: Thu, 09 Jan 2014 23:03:07 +0000
Subject: [New-bugs-announce] [issue20212] distutils: fix build_ext check to
	find whether we're	building Python or not
Message-ID: <1389308587.95.0.49928374838.issue20212@psf.upfronthosting.co.za>


New submission from Thomas Petazzoni:

The build_ext logic uses sys.executable.startswith(os.path.join(sys.exec_prefix, "bin")) to determine whether we're building a third-party Python extension, or a built-in Python extension. However, this check is wrong in cross-compilation mode, because the host Python interpreter might very well be installed in its prefix, when it is used to cross-compile the target modules and extensions. The current check would mis-detect this as we're building third-party Python modules, while we are in fact building the internal Python modules of the target Python.

Therefore, use the existing sysconfig.python_build variable, which provides the information of whether we're building Python itself or not in a correct way.

----------
components: Cross-Build
files: 0002-distutils-fix-build_ext-check-to-find-whether-we-re-.patch
keywords: patch
messages: 207806
nosy: thomas-petazzoni
priority: normal
severity: normal
status: open
title: distutils: fix build_ext check to find whether we're building Python or not
type: compile error
versions: Python 3.4
Added file: http://bugs.python.org/file33394/0002-distutils-fix-build_ext-check-to-find-whether-we-re-.patch

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

From report at bugs.python.org  Fri Jan 10 00:03:48 2014
From: report at bugs.python.org (Thomas Petazzoni)
Date: Thu, 09 Jan 2014 23:03:48 +0000
Subject: [New-bugs-announce] [issue20213] Change the install location of
	_sysconfigdata.py
Message-ID: <1389308628.19.0.703903245548.issue20213@psf.upfronthosting.co.za>


New submission from Thomas Petazzoni:

The _sysconfigdata.py module contains definitions that are needed when building Python modules. In cross-compilation mode, when building Python extensions for the target, we need to use the _sysconfigdata.py of the target Python while executing the host Python.

However until now, the _sysconfigdata.py module was installed in build/lib.<arch>-<version> directory, together with a number of architecture-specific shared objects, which cannot be used with the host Python.

To solve this problem, this patch moves _sysconfigdata.py to a separate location, build/sysconfigdata.<arch>-<version>/, and only this directory gets added to the PYTHONPATH of the host Python interpreter when building Python modules for the target.

----------
components: Cross-Build
files: 0003-Change-the-install-location-of-_sysconfigdata.py.patch
keywords: patch
messages: 207807
nosy: thomas-petazzoni
priority: normal
severity: normal
status: open
title: Change the install location of _sysconfigdata.py
type: compile error
versions: Python 3.4
Added file: http://bugs.python.org/file33395/0003-Change-the-install-location-of-_sysconfigdata.py.patch

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

From report at bugs.python.org  Fri Jan 10 02:25:38 2014
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 10 Jan 2014 01:25:38 +0000
Subject: [New-bugs-announce] [issue20214] Argument Clinic rollup fixes
Message-ID: <1389317138.57.0.101674386167.issue20214@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Miscellaneous Argument Clinic fixes:
  * Added default value type verification for almost all return converters.
  * Added return converters for float, dobule, unsigned long,
    unsigned int, short, and unsigned short.
  * Py_buffer converter improvements:
      * Now allow exactly one value as a default value: None.
      * The default value in C only needs two fields initialized.
      * The cleanup call to PyBuffer_Release should be based on
        ".obj", not ".buf".
As well as a bunch of documentation fixes.

I'd love a review, but I'm pretty confident it's all okay so I may just check it in.  (The only code changes are in clinic.py so it's not going to break the world.)

----------
assignee: larry
files: larry.argument.clinic.misc.fixes.patch.1.txt
messages: 207811
nosy: larry
priority: normal
severity: normal
stage: patch review
status: open
title: Argument Clinic rollup fixes
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33396/larry.argument.clinic.misc.fixes.patch.1.txt

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

From report at bugs.python.org  Fri Jan 10 03:03:02 2014
From: report at bugs.python.org (dzyu)
Date: Fri, 10 Jan 2014 02:03:02 +0000
Subject: [New-bugs-announce] [issue20215] Python2.7 socketserver can not
	listen IPv6 address
Message-ID: <1389319382.42.0.481013787618.issue20215@psf.upfronthosting.co.za>


New submission from dzyu:

I see, in python 2.7, in SocketServer.py the TCPServer implementation is hard-coded to use ipv4, can not handle IPv6 case. it hard-coded set address_family as socket.AF_INET. so when binding IPv6 host, it will throw "gaierror: [Errno -9] Address family for hostname not supported".

The code should to judge the provided host is IPv4 or IPv6, and base on the host type to set address_family as socket.AF_INET or  socket.AF_INET6

----------
components: Library (Lib)
messages: 207818
nosy: dazhaoyu
priority: normal
severity: normal
status: open
title: Python2.7 socketserver can not listen IPv6 address
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jan 10 03:21:30 2014
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 10 Jan 2014 02:21:30 +0000
Subject: [New-bugs-announce] [issue20216] Misleading docs for sha1, sha256,
	sha512 modules
Message-ID: <1389320490.58.0.128009418019.issue20216@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Misleading doc number 1:

>>> import _sha1
>>> _sha1.sha1.__doc__
'Return a new SHA1 hash object; optionally initialized with a string.'
>>> _sha1.sha1('cutecat')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Unicode-objects must be encoded before hashing
>>> _sha1.sha1(b'cutecat')
<_sha1.sha1 object at 0x7f800f669e00>
>>> _sha1.sha1(string=b'cutecat')
<_sha1.sha1 object at 0x7f800f669e00>

I don't think we can change the unfortunate keyword 'string'. But at least we must fix the doc.

Misleading doc number 2:

>>> import _sha1
>>> cutecat = _sha1.sha1(b'cutecat')
>>> cutecat.update.__doc__
"Update this hash object's state with the provided string."
>>> cutecat.update('bonobo')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Unicode-objects must be encoded before hashing
>>> cutecat.update(b'bonobo')

Misleading doc number 3:

>>> cutecat.hexdigest()
'a5fbd19140a72992224b2469c4f4d8d6d4aff3e7'
>>> cutecat.hexdigest.__doc__
'Return the digest value as a string of hexadecimal digits.'
>>> cutecat.digest()
b'\xa5\xfb\xd1\x91@\xa7)\x92"K$i\xc4\xf4\xd8\xd6\xd4\xaf\xf3\xe7'
>>> cutecat.digest.__doc__
'Return the digest value as a string of binary data.'

"a string of binary data" in my mind is something like this: '\xa5\xfb\xd1\x91@\xa7)\x92"K$i\xc4\xf4\xd8\xd6\xd4\xaf\xf3\xe7' not b'\xa5\xfb\xd1\x91@\xa7)\x92"K$i\xc4\xf4\xd8\xd6\xd4\xaf\xf3\xe7'.

Provided the patch to fix the doc.

----------
components: Extension Modules
files: fix_doc_sha_module.patch
keywords: patch
messages: 207822
nosy: christian.heimes, vajrasky
priority: normal
severity: normal
status: open
title: Misleading docs for sha1, sha256, sha512 modules
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33398/fix_doc_sha_module.patch

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

From report at bugs.python.org  Fri Jan 10 15:54:54 2014
From: report at bugs.python.org (Phil Connell)
Date: Fri, 10 Jan 2014 14:54:54 +0000
Subject: [New-bugs-announce] [issue20217] Build failure in posixmodule.c
	with SCHED_SPORADIC	available
Message-ID: <1389365694.87.0.154432824669.issue20217@psf.upfronthosting.co.za>


New submission from Phil Connell:

Typo in revision 71704 that causes build failures on systems with SCHED_SPORADIC available. See attached patch.

(Can reproduce by #defining SCHED_SPORADIC just above where it's used in posixmodule.c)

----------
components: Extension Modules
files: sched_sporadic_build.diff
keywords: patch
messages: 207865
nosy: benjamin.peterson, isoschiz, pconnell
priority: normal
severity: normal
status: open
title: Build failure in posixmodule.c with SCHED_SPORADIC available
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33409/sched_sporadic_build.diff

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

From report at bugs.python.org  Fri Jan 10 20:04:53 2014
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 10 Jan 2014 19:04:53 +0000
Subject: [New-bugs-announce] [issue20218] Add `pathlib.Path.write` and
	`pathlib.Path.read`
Message-ID: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za>


New submission from Ram Rachum:

I'd really like to have methods `pathlib.Path.write` and `pathlib.Path.read`. Untested implementation:

def read(self, binary=False):
    with self.open('br' is binary else 'r') as file:
        return file.read()

def write(self, data. binary=False):
    with self.open('bw' is binary else 'w') as file:
        file.write(data)

This will be super useful to me. Many files actions are one liners like that, and avoiding putting the `with` clause in user code would be wonderful.

Antoine suggests that `binary` shouldn't be an argument, that there should be separate methods for reading/writing text and binary contents, and that the text one would require passing in encoding and other parameters. I'll be happy to add these to the implementation and create a patch, once people can define which parameters should be used.

----------
components: Library (Lib)
messages: 207874
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Add `pathlib.Path.write` and `pathlib.Path.read`
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jan 10 20:55:57 2014
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 10 Jan 2014 19:55:57 +0000
Subject: [New-bugs-announce] [issue20219] ElementTree: allow passing
	XMLPullParser instance into	iterparse()
Message-ID: <1389383757.8.0.892188011748.issue20219@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

in the XMLPullParser ticket

http://bugs.python.org/issue17741

specifically here:

http://bugs.python.org/msg196177

it says:

"""
* [The pull parser] will *not* accept a "parser" argument in the constructor.
Rationale: the parser argument of iterparse is broken anyway. This will
make it much easier to modify the implementation of EventParser in the
future when the C internals are fixed w.r.t problems mentioned in this issue.

* iterparse's "parser" argument will be deprecated, and the documentation
will be more detailed w.r.t to the limitations on its current "parser"
argument (the limitations are there in the code, but they're not fully
documented).
"""

And the "parser" argument to iterparse is now deprecated, according to the
docs:

http://docs.python.org/3.4/library/xml.etree.elementtree.html#xml.etree.ElementTree.iterparse

In lxml, however, I'm noticing that it would be really helpful to pass a
pull parser into iterparse(). Essentially, iterparse() is now stripped down
to a wrapper around the pull parser(s: XML/HTML in lxml) that simply serves
the feeding side of the interface for the user's convenience.

Note that lxml's iterparse() never had a "parser" argument. That's for
historical reasons, because it originally *was* a parser itself, but it
no longer is now.

I'd like to allow passing pull parsers into iterparse(), so that users can
configure them on their own. Currently, iterparse() must duplicate
basically all of the parser configuration arguments. I'd like to deprecate
that in lxml and replace it with the same simple interface as in ET, i.e.
pass in *either* a set of events *or* a readily configured pull parser.
Preferably raising an error if users pass both.

Could we change the deprecation from "argument is deprecated" to "passing a
normal (non-pull) parser into iterparse is deprecated", and then allow
passing a pull parser in the future?

----------
components: Library (Lib), XML
messages: 207877
nosy: eli.bendersky, scoder
priority: normal
severity: normal
status: open
title: ElementTree: allow passing XMLPullParser instance into iterparse()
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Fri Jan 10 21:04:33 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 10 Jan 2014 20:04:33 +0000
Subject: [New-bugs-announce] [issue20220] TarFile.list() outputs wrong time
Message-ID: <1389384273.4.0.330615086279.issue20220@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

TarFile.list() outputs a time exactly 6 hours back from expected.

http://buildbot.python.org/all/builders/System%20Z%20Linux%203.x/builds/1023/steps/test/logs/stdio

======================================================================
FAIL: test_list_command_verbose (test.test_tarfile.CommandLineTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/test/test_tarfile.py", line 1797, in test_list_command_verbose
    self.assertEqual(out, expected)
AssertionError: b'?rw[36 chars]-22 12:34:43 tokenize_tests.txt \n?rw------- d[96 chars]t \n' != b'?rw[36 chars]-22 18:34:43 tokenize_tests.txt \n?rw------- d[96 chars]t \n'

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

----------
components: Library (Lib)
messages: 207878
nosy: lars.gustaebel, serhiy.storchaka
priority: normal
severity: normal
status: open
title: TarFile.list() outputs wrong time
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Jan 11 04:09:28 2014
From: report at bugs.python.org (Tabrez Mohammed)
Date: Sat, 11 Jan 2014 03:09:28 +0000
Subject: [New-bugs-announce] [issue20221] #define hypot _hypot conflicts
	with existing definition
Message-ID: <1389409768.81.0.962130999427.issue20221@psf.upfronthosting.co.za>


New submission from Tabrez Mohammed:

In pyconfig.h (line 216), there is this line:
#define hypot _hypot

This conflicts with the definition of _hypot that ships with VS2010 (math.h, line 161):
static __inline double __CRTDECL hypot(_In_ double _X, _In_ double _Y)

The result of the redefinition is that the following warning occurs during compilation:
1>c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\math.h(162): warning C4211: nonstandard extension used : redefined extern to static

When compiling with warnings being treated as errors, this will obviously result in failed builds.

The recommendation from Microsoft (see http://connect.microsoft.com/VisualStudio/feedback/details/633988/warning-in-math-h-line-162-re-nonstandard-extensions-used) is to change the definition to:
#if _MSC_VER < 1600
#define hypot _hypot
#endif

----------
components: Windows
messages: 207894
nosy: tabrezm
priority: normal
severity: normal
status: open
title: #define hypot _hypot conflicts with existing definition
type: compile error
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Jan 11 19:25:49 2014
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 11 Jan 2014 18:25:49 +0000
Subject: [New-bugs-announce] [issue20222] unittest.mock-examples doc uses
	builtin file which is	removed in Python 3
Message-ID: <1389464749.27.0.908623013872.issue20222@psf.upfronthosting.co.za>


New submission from INADA Naoki:

http://docs.python.org/3.3/library/unittest.mock-examples.html#mocking-chained-calls

> Let?s assume the object it returns is ?file-like?, so we?ll ensure that our response object uses the builtin file as its spec.

and

> >>> mock_response = Mock(spec=file)

----------
assignee: docs at python
components: Documentation
messages: 207908
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: unittest.mock-examples doc uses builtin file which is removed in Python 3
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Jan 11 22:22:59 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 11 Jan 2014 21:22:59 +0000
Subject: [New-bugs-announce] [issue20223] inspect.signature does not support
	new	functools.partialmethod
Message-ID: <1389475379.56.0.443397984378.issue20223@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

new and handy functools.partialmethod doesn't fully support inspect.signature.

For instance, for the following code:

    class Spam:
        def say(self, a, b=1):
            print(a)
        hello = functools.partialmethod(say, 'hello')

the 'signature(Spam.hello)' will always return '(*args, **keywords)'

I'm attaching a patch that fixes that, so the signature for the above example will be '(self, b=1)'.

----------
components: Library (Lib)
files: signature_partialmeth_01.patch
keywords: patch
messages: 207915
nosy: brett.cannon, larry, ncoghlan, yselivanov
priority: normal
severity: normal
status: open
title: inspect.signature does not support new functools.partialmethod
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33418/signature_partialmeth_01.patch

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

From report at bugs.python.org  Sun Jan 12 07:25:11 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 12 Jan 2014 06:25:11 +0000
Subject: [New-bugs-announce] [issue20224] C API docs need a clear "defining
	custom extension	types" section
Message-ID: <1389507911.71.0.277009038491.issue20224@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

The main C API docs don't clearly explain how to define new types, so people almost always cargo cult an existing legacy type definition instead (I know I do).

The extending and embedding docs have a guide (http://docs.python.org/3/extending/newtypes.html), but that describes the old legacy method based on static type declarations. New code should instead use the dynamic mechanism defined in PEP 384 (http://www.python.org/dev/peps/pep-0384/#type-objects).

See also http://docs.python.org/3/c-api/type.html#PyType_FromSpec

Note that PyType_Spec isn't defined in the C API docs *at all*.

----------
assignee: docs at python
components: Documentation
messages: 207927
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: C API docs need a clear "defining custom extension types" section
type: enhancement
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Jan 12 11:20:28 2014
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 12 Jan 2014 10:20:28 +0000
Subject: [New-bugs-announce] [issue20225] Argument Clinic: simplify
	METH_NOARGS generated code
Message-ID: <1389522028.26.0.505702329352.issue20225@psf.upfronthosting.co.za>


New submission from Georg Brandl:

For METH_NOARGS, you can get rid of the separate _impl function.  This makes the generated code much smaller.

----------
messages: 207943
nosy: georg.brandl
priority: normal
severity: normal
status: open
title: Argument Clinic: simplify METH_NOARGS generated code

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

From report at bugs.python.org  Sun Jan 12 11:29:49 2014
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 12 Jan 2014 10:29:49 +0000
Subject: [New-bugs-announce] [issue20226] Argument Clinic: support for
	simple expressions?
Message-ID: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za>


New submission from Georg Brandl:

Take for example select.epoll.__new__():

static PyObject *
pyepoll_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
{
    int flags = 0, sizehint = FD_SETSIZE - 1;
    static char *kwlist[] = {"sizehint", "flags", NULL};

    if (!PyArg_ParseTupleAndKeywords(args, kwds, "|ii:epoll", kwlist,
                                     &sizehint, &flags))
        return NULL;

How should that be handled?  Currently I can't specify ``FD_SETSIZE - 1`` as the default value, but I don't want a magic ``-909`` either :)

----------
messages: 207946
nosy: georg.brandl
priority: normal
severity: normal
status: open
title: Argument Clinic: support for simple expressions?

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

From report at bugs.python.org  Sun Jan 12 12:05:36 2014
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 12 Jan 2014 11:05:36 +0000
Subject: [New-bugs-announce] [issue20227] Argument Clinic: rename arguments
	in generated C?
Message-ID: <1389524736.75.0.620647933805.issue20227@psf.upfronthosting.co.za>


New submission from Georg Brandl:

This is a request to be able to name C arguments differently from Python arguments.

Two reasons:

* like for function renaming, some Python argument names are reserved in C ("default" for example, used in sys.getsizeof())

* sometimes the function uses 'O' in PyArg_ParseTuple and then converts the object itself with a nontrivial process.  Usually the converted variable has the name of the Python argument, while the temporary object is named "obj_foo" or "foo_obj".  When converting to Argument Clinic, we have to name the object "foo" and find a new name for the converted "foo", which leads to code churn and less beautiful code.

----------
assignee: larry
messages: 207948
nosy: georg.brandl, larry
priority: normal
severity: normal
status: open
title: Argument Clinic: rename arguments in generated C?

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

From report at bugs.python.org  Sun Jan 12 22:11:48 2014
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 12 Jan 2014 21:11:48 +0000
Subject: [New-bugs-announce] [issue20228] Argument Clinic should understand
	Python special methods
Message-ID: <1389561108.74.0.0249800725928.issue20228@psf.upfronthosting.co.za>


New submission from Larry Hastings:

As per Georg's request (and hacks in other places), Argument Clinic should have support for special methods.  To wit:

__init__ should be required to be an instance method.  Clinic should suppress its methoddef #define.

__new__ should be required to be a class method.  Its C function name should have the __new__ stripped off, and by convention its first argument should be "PyTypeObject *type".  Clinic should suppress its methoddef #define.

All other dunder-methods which have special slots in the PyTypeObject structure should be rejected by Argument Clinic.  (Their arguments are pre-parsed, and they don't have docstrings... what would Clinic do for them?)  Obviously generic dunder-methods ("__getstate__", "__sizeof__") are still fine.

----------
assignee: larry
components: Demos and Tools
files: larry.special.methods.support.patch.1.txt
messages: 207980
nosy: georg.brandl, larry
priority: normal
severity: normal
stage: patch review
status: open
title: Argument Clinic should understand Python special methods
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33433/larry.special.methods.support.patch.1.txt

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

From report at bugs.python.org  Mon Jan 13 01:03:50 2014
From: report at bugs.python.org (Marc Tamlyn)
Date: Mon, 13 Jan 2014 00:03:50 +0000
Subject: [New-bugs-announce] [issue20229] platform.py uses deprecated
	feature of plistlib
Message-ID: <1389571430.72.0.704873561263.issue20229@psf.upfronthosting.co.za>


New submission from Marc Tamlyn:

platform.mac_ver() triggers the following deprecation warning:

python3.4 -Wall
Python 3.4.0b2 (v3.4.0b2:ba32913eb13e, Jan  5 2014, 11:02:52)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.mac_ver()
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/platform.py:652: DeprecationWarning: The readPlist function is deprecated, use load() instead
  pl = plistlib.readPlist(fn)
('10.9.1', ('', '', ''), 'x86_64')

----------
assignee: ronaldoussoren
components: Macintosh
messages: 207987
nosy: Marc.Tamlyn, ronaldoussoren
priority: normal
severity: normal
status: open
title: platform.py uses deprecated feature of plistlib
versions: Python 3.4

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

From report at bugs.python.org  Mon Jan 13 02:12:54 2014
From: report at bugs.python.org (Andrew Barnert)
Date: Mon, 13 Jan 2014 01:12:54 +0000
Subject: [New-bugs-announce] [issue20230] structseq types should expose
	_fields
Message-ID: <1389575574.46.0.402404595733.issue20230@psf.upfronthosting.co.za>


New submission from Andrew Barnert:

A PyStructSequence type doesn't expose its field names in any way to Python code (except indirectly, via the repr, which you could parse if you really wanted to?).

The docs claim that "Struct sequence objects are the C equivalent of namedtuple() objects", so it seems like the obvious way to expose them is the exact same way namedtuple types do?as a class attribute named "_fields".

Also, in #7796, and in a recent thread on python-ideas, multiple people suggested that "named tuple" is a protocol, not a type, and duck typing on _fields is the obvious way to detect types matching that protocol.

Only the "sequence fields" need to be exposed?fields that don't match up to sequence indices aren't named tuple fields, they're just extra instance attributes (that don't even show up in the repr).

Patch included. For the tests, I tested the fields in struct_time and stat_result in effectively the same way test_repr tests their repr, so it should pass on all the same platforms/builds.

----------
files: structseq.diff
keywords: patch
messages: 207991
nosy: abarnert
priority: normal
severity: normal
status: open
title: structseq types should expose _fields
type: enhancement
Added file: http://bugs.python.org/file33436/structseq.diff

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

From report at bugs.python.org  Mon Jan 13 03:31:55 2014
From: report at bugs.python.org (Ryan Smith-Roberts)
Date: Mon, 13 Jan 2014 02:31:55 +0000
Subject: [New-bugs-announce] [issue20231] Argument Clinic accepts no-default
	args after default	args
Message-ID: <1389580315.91.0.810075963733.issue20231@psf.upfronthosting.co.za>


New submission from Ryan Smith-Roberts:

A signature of the form

a: object = None
b: object

results in b being uninitialized in the generated C code prior to the PyArgs_ParseTuple call. If ParseTuple does not set a value for b (as it is an optional argument), b then contains a garbage pointer and the interpreter may segfault.

AC should reject this configuration.

----------
components: Build
messages: 207997
nosy: larry, rmsr
priority: normal
severity: normal
status: open
title: Argument Clinic accepts no-default args after default args
versions: Python 3.4

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

From report at bugs.python.org  Mon Jan 13 03:53:18 2014
From: report at bugs.python.org (Ryan Smith-Roberts)
Date: Mon, 13 Jan 2014 02:53:18 +0000
Subject: [New-bugs-announce] [issue20232] Argument Clinic NULL default
	falsely implies None	acceptability
Message-ID: <1389581598.8.0.840632015553.issue20232@psf.upfronthosting.co.za>


New submission from Ryan Smith-Roberts:

When one specifies a default of NULL, the generated signature doc indicates a default of None. However, if the user actually supplies None, perhaps as a placeholder in a positional-only call, C code which only checks for NULL will fail inappropriately.

The solution may be to convert a None object to a null pointer in the wrapper.

----------
components: Build
messages: 207998
nosy: larry, rmsr
priority: normal
severity: normal
status: open
title: Argument Clinic NULL default falsely implies None acceptability
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Jan 13 04:46:55 2014
From: report at bugs.python.org (Benno Rice)
Date: Mon, 13 Jan 2014 03:46:55 +0000
Subject: [New-bugs-announce] [issue20233] Re-enable buffer API slots for
	heap types
Message-ID: <1389584815.64.0.0171986621456.issue20233@psf.upfronthosting.co.za>


New submission from Benno Rice:

The API slots for bf_getbuffer and bf_releasebuffer are still disabled despite the bug referenced (issue 10181) being marked as fixed. These should be re-enabled if the stable ABI is to be used for types that use buffers.

----------
components: Extension Modules
messages: 208002
nosy: Benno.Rice
priority: normal
severity: normal
status: open
title: Re-enable buffer API slots for heap types
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Jan 13 07:56:42 2014
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 13 Jan 2014 06:56:42 +0000
Subject: [New-bugs-announce] [issue20234] Argument Clinic: use
	PyTuple_GET_SIZE?
Message-ID: <1389596202.96.0.0154982234114.issue20234@psf.upfronthosting.co.za>


New submission from Georg Brandl:

In the presence of [ ] , clinic generates PyTuple_Size() calls.

Since argument tuples always are tuples, you can use the macro form PyTuple_GET_SIZE() to speed it up.

----------
assignee: larry
messages: 208007
nosy: georg.brandl, larry
priority: normal
severity: normal
status: open
title: Argument Clinic: use PyTuple_GET_SIZE?

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

From report at bugs.python.org  Mon Jan 13 08:02:27 2014
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 13 Jan 2014 07:02:27 +0000
Subject: [New-bugs-announce] [issue20235] Argument Clinic: recover a bit
	more gracefully from	exceptions
Message-ID: <1389596547.42.0.103155756972.issue20235@psf.upfronthosting.co.za>


New submission from Georg Brandl:

I had specified c_default=-1 (note missing quotes) somewhere, and it raises an exception during the clinic --make run; there was no indication which file/line this was on.

Suggested patch attached.

----------
assignee: larry
files: clinic_exception_reporting.patch
keywords: patch
messages: 208008
nosy: georg.brandl, larry
priority: normal
severity: normal
status: open
title: Argument Clinic: recover a bit more gracefully from exceptions
Added file: http://bugs.python.org/file33440/clinic_exception_reporting.patch

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

From report at bugs.python.org  Mon Jan 13 08:16:44 2014
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 13 Jan 2014 07:16:44 +0000
Subject: [New-bugs-announce] [issue20236] Invalid inline markup in xml
	document.
Message-ID: <1389597404.75.0.92024373365.issue20236@psf.upfronthosting.co.za>


New submission from INADA Naoki:

http://docs.python.org/3.3/library/xml.html#xml-vulnerabilities

> DTD retrieval
>     Some XML libraries like Python?s mod:?xml.dom.pulldom? retrieve document

mod: should be :mod:

----------
assignee: docs at python
components: Documentation
messages: 208012
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Invalid inline markup in xml document.
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Jan 13 11:13:46 2014
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 13 Jan 2014 10:13:46 +0000
Subject: [New-bugs-announce] [issue20237] Ambiguous sentence in document of
	xml package.
Message-ID: <1389608026.69.0.492339232238.issue20237@psf.upfronthosting.co.za>


New submission from INADA Naoki:

http://docs.python.org/3.3/library/xml.html#defused-packages

"The courses of action are recommended for any server code that parses untrusted XML data."

What this sentence means?
What "The courses" is?

----------
assignee: docs at python
components: Documentation
messages: 208015
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Ambiguous sentence in document of xml package.
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Jan 13 11:24:43 2014
From: report at bugs.python.org (Martin Panter)
Date: Mon, 13 Jan 2014 10:24:43 +0000
Subject: [New-bugs-announce] [issue20238] Incomplete gzip output with
	tarfile.open(fileobj=..., mode="w:gz")
Message-ID: <1389608683.35.0.244495356969.issue20238@psf.upfronthosting.co.za>


New submission from Martin Panter:

I am trying to create a tar file after opening it as a temporary file, and it seems to be writing truncated output when I use mode="w:gz". My workaround looks like it will be to use mode="w|gz" instead. It?s not clear what the difference is: am I losing anything practical by disallowing ?random? seeking?

Simplified demonstration:

>>> from io import BytesIO; b = BytesIO()
>>> import tarfile; t = tarfile.open(fileobj=b, mode="w:gz")
>>> t._extfileobj
True
>>> type(t.fileobj)
<class 'gzip.GzipFile'>
>>> t.close()
>>> b.getvalue()
b'\x1f\x8b\x08\x00]\xb8\xd3R\x02\xff'
>>> del t
>>> b.getvalue()
b"\x1f\x8b\x08\x00]\xb8\xd3R\x02\xff\xed\xc1\x01\r\x00\x00\x00\xc2\xa0\xf7Om\x0e7\xa0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x807\x03\x9a\xde\x1d'\x00(\x00\x00"

Looking at the code, the TarFile.close() method would not be closing the GzipFile object because of this condition:

if not self._extfileobj:
    self.fileobj.close()

Perhaps it needs to also check if file compression is being used or something; I?m not familiar with the internals.

I did notice that the bug happens with Python 3.3.3 and 3.2.3, but not 2.7.5. Also, I do not see the issue when a file name is passed to tarfile.open() rather than a file object, nor do I see it with the bzip or XZ compressors, uncompressed tar creation, or the ?special purposes? w|gz mode.

----------
components: Library (Lib)
messages: 208017
nosy: vadmium
priority: normal
severity: normal
status: open
title: Incomplete gzip output with tarfile.open(fileobj=..., mode="w:gz")
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Jan 13 12:15:01 2014
From: report at bugs.python.org (Michael Foord)
Date: Mon, 13 Jan 2014 11:15:01 +0000
Subject: [New-bugs-announce] [issue20239] Allow repeated deletion of
	unittest.mock.Mock attributes
Message-ID: <1389611701.97.0.048361560176.issue20239@psf.upfronthosting.co.za>


New submission from Michael Foord:

Reported as mock issue 221: http://code.google.com/p/mock/issues/detail?id=221

>>> from unittest.mock import Mock
>>> m = Mock()
>>> m.foo = 3
>>> del m.foo
>>> m.foo = 4
>>> del m.foo
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/compile/py3k-cpython/Lib/unittest/mock.py", line 687, in __delattr__
    raise AttributeError(name)
AttributeError: foo

Suggested change:

Previous:

   def __delattr__(self, name):
       if name in _all_magics and name in type(self).__dict__:
           delattr(type(self), name)
           if name not in self.__dict__:
               # for magic methods that are still MagicProxy objects and
               # not set on the instance itself
               return

       if name in self.__dict__:
           object.__delattr__(self, name)

       obj = self._mock_children.get(name, _missing)
       if obj is _deleted:
           raise AttributeError(name)
       if obj is not _missing:
           del self._mock_children[name]
       self._mock_children[name] = _deleted


Change:

   def __delattr__(self, name):
       if name in _all_magics and name in type(self).__dict__:
           delattr(type(self), name)
           if name not in self.__dict__:
               # for magic methods that are still MagicProxy objects and
               # not set on the instance itself
               return

       obj = self._mock_children.get(name, _missing)
       if name in self.__dict__:
           object.__delattr__(self, name)
       elif obj is _deleted:
           raise AttributeError(name)
       if obj is not _missing:
           del self._mock_children[name]
       self._mock_children[name] = _deleted


Incidentally the if ?obj is not _missing? line seems superfluous.

----------
assignee: michael.foord
messages: 208019
nosy: michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: Allow repeated deletion of unittest.mock.Mock attributes
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Jan 13 12:33:32 2014
From: report at bugs.python.org (Jacek Szpot)
Date: Mon, 13 Jan 2014 11:33:32 +0000
Subject: [New-bugs-announce] [issue20240] Whitespace ignored in relative
	imports: from.package	import something is valid syntax
Message-ID: <1389612812.75.0.909355414267.issue20240@psf.upfronthosting.co.za>


New submission from Jacek Szpot:

Just wanted to let you know that missing whitespace between "from" and a dot-prefixed name is not considered invalid:

from.foo import bar 

.. does not raise an error. Perhaps it should?

----------
messages: 208022
nosy: maligree
priority: normal
severity: normal
status: open
title: Whitespace ignored in relative imports: from.package import something is valid syntax
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jan 13 16:25:19 2014
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 13 Jan 2014 15:25:19 +0000
Subject: [New-bugs-announce] [issue20241] Bad reference to RFC in document
	of ipaddress?
Message-ID: <1389626719.4.0.511378840941.issue20241@psf.upfronthosting.co.za>


New submission from INADA Naoki:

http://docs.python.org/3.3/library/ipaddress.html#ipaddress.IPv4Address.is_unspecified

>     True if the address is unspecified. See RFC 5375 (for IPv4) or RFC 2373 (for IPv6).

RFC 5375 is "IPv6 Unicast Address Assignment Considerations".

----------
assignee: docs at python
components: Documentation
messages: 208027
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Bad reference to RFC in document of ipaddress?
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Jan 13 19:41:50 2014
From: report at bugs.python.org (kespindler)
Date: Mon, 13 Jan 2014 18:41:50 +0000
Subject: [New-bugs-announce] [issue20242] logging style parameter does not
	work correctly
Message-ID: <1389638510.54.0.587733308543.issue20242@psf.upfronthosting.co.za>


New submission from kespindler:

In Python 3.3, 3.4beta2, and bleeding edge (88411:e7d922d8ee03), the following occurs 

>>> import logging
>>> logging.basicConfig(style="{")
>>> logging.error("hello")
%(levelname)s:%(name)s:%(message)s


Of course, I would expect

ERROR:root:hello

to be output instead.

----------
components: Library (Lib)
messages: 208035
nosy: kespindler
priority: normal
severity: normal
status: open
title: logging style parameter does not work correctly
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Jan 13 20:59:44 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 13 Jan 2014 19:59:44 +0000
Subject: [New-bugs-announce] [issue20243] ReadError when open a tarfile for
	writing
Message-ID: <1389643184.53.0.894735644102.issue20243@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

ReadError can be raised when open a tarfile in write mode (e.g. 'w:gz'). Here is a patch wish a test. In additional it rewrites the handling errors in gzopen() which is too complicated now. This complication is possible the cause of bugs #11513 and #20238.

----------
assignee: serhiy.storchaka
components: Library (Lib)
files: tarfile_readerror_write_mode.patch
keywords: patch
messages: 208044
nosy: georg.brandl, lars.gustaebel, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: ReadError when open a tarfile for writing
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33449/tarfile_readerror_write_mode.patch

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

From report at bugs.python.org  Mon Jan 13 21:26:34 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 13 Jan 2014 20:26:34 +0000
Subject: [New-bugs-announce] [issue20244] Possible resources leak in
	tarfile.open()
Message-ID: <1389644794.57.0.468405626854.issue20244@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There are possible opened file leaks when unexpected error is occurred in tarfile.open for bzip2- or xz-compressed files (and gzip2-compressed in 2.7). Here is a patch. Unfortunately I have no tests.

----------
assignee: serhiy.storchaka
components: Library (Lib)
files: tarfile_file_leak.patch
keywords: patch
messages: 208046
nosy: lars.gustaebel, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Possible resources leak in tarfile.open()
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33450/tarfile_file_leak.patch

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

From report at bugs.python.org  Mon Jan 13 23:18:44 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 13 Jan 2014 22:18:44 +0000
Subject: [New-bugs-announce] [issue20245] Check empty mode in TarFile.*open()
Message-ID: <1389651524.31.0.708867421732.issue20245@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

TarFile's *open() class methods checks the mode argument to raise helpful error:

>>> t = tarfile.TarFile.taropen('xxx.tar', 'q')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1589, in taropen
    raise ValueError("mode must be 'r', 'a' or 'w'")
ValueError: mode must be 'r', 'a' or 'w'

But often this check doesn't catch empty mode.

>>> t = tarfile.TarFile.taropen('xxx.tar', '')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1590, in taropen
    return cls(name, mode, fileobj, **kwargs)
  File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1411, in __init__
    self._mode = {"r": "rb", "a": "r+b", "w": "wb"}[mode]
KeyError: ''
>>> t = tarfile.TarFile.gzopen('xxx.tar', '')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1608, in gzopen
    fileobj = gzip.GzipFile(name, mode + "b", compresslevel, fileobj)
  File "/home/serhiy/py/cpython/Lib/gzip.py", line 181, in __init__
    fileobj = self.myfileobj = builtins.open(filename, mode or 'rb')
ValueError: Must have exactly one of create/read/write/append mode and at most one plus
>>> t = tarfile.TarFile.bz2open('xxx.tar', '')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1640, in bz2open
    t = cls.taropen(name, mode, fileobj, **kwargs)
  File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1590, in taropen
    return cls(name, mode, fileobj, **kwargs)
  File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1411, in __init__
    self._mode = {"r": "rb", "a": "r+b", "w": "wb"}[mode]
KeyError: ''

Only xzopen() works correctly.

>>> t = tarfile.TarFile.xzopen('xxx.tar', '')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1653, in xzopen
    raise ValueError("mode must be 'r' or 'w'")
ValueError: mode must be 'r' or 'w'

Here is a patch which fixes the mode argument checking.

----------
assignee: serhiy.storchaka
components: Library (Lib)
files: tarfile_empty_mode.patch
keywords: patch
messages: 208057
nosy: lars.gustaebel, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Check empty mode in TarFile.*open()
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33451/tarfile_empty_mode.patch

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

From report at bugs.python.org  Tue Jan 14 01:43:59 2014
From: report at bugs.python.org (Ryan Smith-Roberts)
Date: Tue, 14 Jan 2014 00:43:59 +0000
Subject: [New-bugs-announce] [issue20246] buffer overflow in
	socket.recvfrom_into
Message-ID: <1389660239.25.0.341393063834.issue20246@psf.upfronthosting.co.za>


New submission from Ryan Smith-Roberts:

recvfrom_into fails to check that the supplied buffer object is big enough for the requested read and so will happily write off the end.

I will attach patches for 3.4 and 2.7, I'm not familiar with the backporting procedure to go further but all versions since 2.5 have this bug and while very highly unlikely it's technically remotely exploitable.

Quickie trigger script, crash on interpreter exit:

--------- BEGIN SEGFAULT ---------

import socket
r, w = socket.socketpair()
w.send(b'X' * 1024)
r.recvfrom_into(bytearray(), 1024)

----------
components: Extension Modules
messages: 208062
nosy: rmsr
priority: normal
severity: normal
status: open
title: buffer overflow in socket.recvfrom_into
type: crash
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/issue20246>
_______________________________________

From report at bugs.python.org  Tue Jan 14 01:55:21 2014
From: report at bugs.python.org (Antony Lee)
Date: Tue, 14 Jan 2014 00:55:21 +0000
Subject: [New-bugs-announce] [issue20247] Condition._is_owned is wrong
Message-ID: <1389660921.49.0.651163897864.issue20247@psf.upfronthosting.co.za>


New submission from Antony Lee:

I believe that the implementation of Condition._is_owned is wrong, as mentioned here: https://mail.python.org/pipermail/python-list/2012-October/632682.html.  Specifically, the two return values (True and False) should be inverted.

I guess this slipped through as this private function would only be called if one passed to a Condition object a (R)Lock-like object that doesn't define _is_owned.  (I noticed this when I tried to pass a custom-written reader-writer lock to a Condition object.)  Technically, the docs says that "If the lock argument is given and not None, it must be a Lock or RLock object", but in practice anything that defines acquire(), release() (and possibly _is_owned()) should work.

----------
components: Library (Lib)
messages: 208063
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Condition._is_owned is wrong

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

From report at bugs.python.org  Tue Jan 14 04:14:05 2014
From: report at bugs.python.org (Ryan Smith-Roberts)
Date: Tue, 14 Jan 2014 03:14:05 +0000
Subject: [New-bugs-announce] [issue20248] docs: socket.recvmsg{,
	_into} are keword-compatible
Message-ID: <1389669245.17.0.020040143215.issue20248@psf.upfronthosting.co.za>


New submission from Ryan Smith-Roberts:

The docs indicate their arguments are positional-only. Trivial patch attached.

----------
assignee: docs at python
components: Documentation
files: docs_socket_recvmsg_args.patch
keywords: patch
messages: 208067
nosy: docs at python, rmsr
priority: normal
severity: normal
status: open
title: docs: socket.recvmsg{,_into} are keword-compatible
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33454/docs_socket_recvmsg_args.patch

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

From report at bugs.python.org  Tue Jan 14 05:07:37 2014
From: report at bugs.python.org (Chris Angelico)
Date: Tue, 14 Jan 2014 04:07:37 +0000
Subject: [New-bugs-announce] [issue20249] test_posix.test_initgroups fails
	when running with no	supplementary groups
Message-ID: <1389672457.74.0.34815423536.issue20249@psf.upfronthosting.co.za>


New submission from Chris Angelico:

When tests are run from an Upstart job in a minimal environment, test_posix.test_initgroups fails as it attempts to find the max() of an empty list of supplementary groups.

Problem sighted with 2.7, 3.3, and 3.x branches. Patch derived from 3.x (default branch), applies cleanly to 2.7 and 3.3 as well.

----------
components: Tests
files: test_posix.patch
keywords: patch
messages: 208069
nosy: Rosuav
priority: normal
severity: normal
status: open
title: test_posix.test_initgroups fails when running with no supplementary groups
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33455/test_posix.patch

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

From report at bugs.python.org  Tue Jan 14 05:27:43 2014
From: report at bugs.python.org (Andrew Barnert)
Date: Tue, 14 Jan 2014 04:27:43 +0000
Subject: [New-bugs-announce] [issue20250] defaultdict docstring neglects the
	*args
Message-ID: <1389673663.73.0.267088084088.issue20250@psf.upfronthosting.co.za>


New submission from Andrew Barnert:

The docstring for defaultdict shows only a single argument, default_factory, and gives no clue that you can pass additional arguments:

    |  defaultdict(default_factory) --> dict with default factory
    |
    |  The default factory is called without arguments to produce
    |  a new value when a key is not present, in __getitem__ only.
    |  A defaultdict compares equal to a dict with the same items.

The docs, by contrast, say:

> class collections.defaultdict([default_factory[, ...]])

> ? The first argument provides the initial value for the default_factory attribute; it defaults to None. All remaining arguments are treated the same as if they were passed to the dict constructor, including keyword arguments.

I think the docstring should have the same information?or at least have the correct signature, which would hopefully be enough to prompt people to look at the docs.

I'm not sure whether the correct signature is (default_factory, *args, **kwargs), like OrderedDict, or (default_factory[, ...]), like deque, but I don't think either one would confuse anyone.

----------
components: Library (Lib)
files: collectionsmodule.diff
keywords: patch
messages: 208071
nosy: abarnert
priority: normal
severity: normal
status: open
title: defaultdict docstring neglects the *args
type: enhancement
Added file: http://bugs.python.org/file33456/collectionsmodule.diff

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

From report at bugs.python.org  Tue Jan 14 06:18:58 2014
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 14 Jan 2014 05:18:58 +0000
Subject: [New-bugs-announce] [issue20251] socket.recvfrom_into crash with
	empty buffer
Message-ID: <1389676738.57.0.767136106555.issue20251@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

>>> import socket
>>> r, w = socket.socketpair()
>>> w.send(b'X' * 1024)
1024
>>> buffer = bytearray()
>>> r.recvfrom_into(buffer)
python: /home/sky/Code/python/cpython3.4/Modules/socketmodule.c:2867: sock_recvfrom_into: Assertion `buf != 0 && buflen > 0' failed.
Aborted (core dumped)

Attached the fix to handle the empty bytearray gracefully. The fix is for Python 3.4.

----------
components: Extension Modules
files: recv_from_into_empty_byte_array.patch
keywords: patch
messages: 208073
nosy: benjamin.peterson, vajrasky
priority: normal
severity: normal
status: open
title: socket.recvfrom_into crash with empty buffer
type: crash
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33457/recv_from_into_empty_byte_array.patch

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

From report at bugs.python.org  Tue Jan 14 06:45:29 2014
From: report at bugs.python.org (Ryan Smith-Roberts)
Date: Tue, 14 Jan 2014 05:45:29 +0000
Subject: [New-bugs-announce] [issue20252] Argument Clinic howto: small typo
	in y# translation
Message-ID: <1389678329.15.0.528814981218.issue20252@psf.upfronthosting.co.za>


New submission from Ryan Smith-Roberts:

type -> types

----------
assignee: docs at python
components: Documentation
files: argument_clinic_howto_y-hash.patch
keywords: patch
messages: 208076
nosy: docs at python, larry, rmsr
priority: normal
severity: normal
status: open
title: Argument Clinic howto: small typo in y# translation
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33458/argument_clinic_howto_y-hash.patch

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

From report at bugs.python.org  Tue Jan 14 07:29:21 2014
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 14 Jan 2014 06:29:21 +0000
Subject: [New-bugs-announce] [issue20253] Typo in ipaddress document
Message-ID: <1389680961.29.0.254286053987.issue20253@psf.upfronthosting.co.za>


New submission from INADA Naoki:

> http://docs.python.org/3.3/library/ipaddress.html#ipaddress.IPv4Network.broadcast_address

Wrong attribute name: s/host mask/hostmask/

----------
assignee: docs at python
components: Documentation
messages: 208078
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Typo in ipaddress document
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Jan 14 08:30:47 2014
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 14 Jan 2014 07:30:47 +0000
Subject: [New-bugs-announce] [issue20254] Duplicate bytearray test on
	test_socket.py
Message-ID: <1389684647.88.0.881886101386.issue20254@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

testRecvIntoArray is same as testRecvIntoBytearray.
testRecvFromIntoArray  is same as testRecvFromIntoBytearray.

Attached the patch to fix the tests.

----------
components: Tests
files: fix_recv_from_into_array_test_socket.patch
keywords: patch
messages: 208079
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Duplicate bytearray test on test_socket.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33459/fix_recv_from_into_array_test_socket.patch

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

From report at bugs.python.org  Tue Jan 14 08:59:47 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 14 Jan 2014 07:59:47 +0000
Subject: [New-bugs-announce] [issue20255] Doc/about: update a bit
Message-ID: <1389686387.52.0.386182355157.issue20255@psf.upfronthosting.co.za>


New submission from Georg Brandl:

What do you think about this patch?

----------
assignee: zach.ware
components: Documentation
files: about.diff
keywords: patch
messages: 208081
nosy: georg.brandl, zach.ware
priority: normal
severity: normal
status: open
title: Doc/about: update a bit
Added file: http://bugs.python.org/file33460/about.diff

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

From report at bugs.python.org  Tue Jan 14 09:35:49 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 14 Jan 2014 08:35:49 +0000
Subject: [New-bugs-announce] [issue20256] Argument Clinic: compare signed
	and unsigned ints
Message-ID: <1389688549.54.0.106907827652.issue20256@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

For unsigned_int, unsigned_long and size_t return converters Argument Clinic generates a code which compares unsigned integer return_value with signed -1.

----------
components: Demos and Tools
messages: 208083
nosy: larry, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Argument Clinic: compare signed and unsigned ints
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Jan 14 10:39:22 2014
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 14 Jan 2014 09:39:22 +0000
Subject: [New-bugs-announce] [issue20257] test_socket fails if using tipc
	module and SELinux	enabled
Message-ID: <1389692362.24.0.80510230142.issue20257@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Enable SELinux (by default it is already enabled). Then load tipc module.

# modprobe tipc

Then using whatever account, execute Lib/test/test_socket.py. You'll get:
FAILED (errors=1, skipped=4)
Traceback (most recent call last):
  File "Lib/test/test_socket.py", line 1740, in <module>
    test_main()
  File "Lib/test/test_socket.py", line 1736, in test_main
    test_support.run_unittest(*tests)
  File "/home/sky/Code/python/cpython2.7/Lib/test/test_support.py", line 1251, in run_unittest
    _run_suite(suite)
  File "/home/sky/Code/python/cpython2.7/Lib/test/test_support.py", line 1234, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_socket.py", line 1705, in testStream
    msg = self.conn.recv(1024)
error: [Errno 13] Permission denied

Attached the patch to skip the test if we don't have sufficient permission to execute the test.

----------
components: Tests
files: skip_test_if_selinux_tipc.patch
keywords: patch
messages: 208088
nosy: vajrasky
priority: normal
severity: normal
status: open
title: test_socket fails if using tipc module and SELinux enabled
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33462/skip_test_if_selinux_tipc.patch

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

From report at bugs.python.org  Tue Jan 14 11:05:13 2014
From: report at bugs.python.org (Ned Deily)
Date: Tue, 14 Jan 2014 10:05:13 +0000
Subject: [New-bugs-announce] [issue20258] Python documentation build fails
	with "markupsafe module	cannot be found"
Message-ID: <1389693913.29.0.73084450646.issue20258@psf.upfronthosting.co.za>


New submission from Ned Deily:

With the updates to the Sphinx toolchain for 3.3 (05e84d3ecd1e) and 3.4 (90cd87f64632), the documentation build for the OS X installer now fails with:
  
Error: The markupsafe module cannot be found. Did you install Sphinx and its dependencies correctly?

It appears that the updated version of jinja2 now requires MarkupSafe.

Also, the updated version of jinja2 now requires at least Python 2.6. Prior to these toolchain updates it was possible to build the Python documentation (and all of Python 2.x or 3.x) with Python 2.5.  Perhaps this change should be documented somewhere since it does cause some breakage.  For example, the current Python 32-bit-only installers are built on OS X 10.5; up until now, the Apple-supplied system Python 2.5 could be used to bootstrap the build and build the documentation.  Now we'll have to supply a newer local Python to do that.

----------
assignee: georg.brandl
components: Build, Documentation
messages: 208089
nosy: georg.brandl, larry, ned.deily
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Python documentation build fails with "markupsafe module cannot be found"
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Jan 14 16:57:58 2014
From: report at bugs.python.org (Shelby Spencer)
Date: Tue, 14 Jan 2014 15:57:58 +0000
Subject: [New-bugs-announce] [issue20259] os.walk conflicts with os.listdir
Message-ID: <1389715078.64.0.968291006177.issue20259@psf.upfronthosting.co.za>


New submission from Shelby Spencer:

The problem occurs when you attempt to perform an os.listdir on a directory that you don't have access to.  You should get an exception thrown.  Normally this occurs, however, if you run the following code:

folder = <some parent folder that has a child folder you don't have read access to>
for currentDir, subDirs, files = os.walk(folder):
    temp = os.listdir(currentDir)

temp will hold an empty list on the subdirectory you don't have access to and no exception is thrown.  This appears to be some sort of conflict between os.walk and os.listdir.  Near as I can tell python is caching the subdirectory listing for subDirs (os.walk doesn't throw an error on attempting to read a directory is doesn't have access to, obviously) and returning those results when os.listdir is called.

----------
components: IO
messages: 208100
nosy: shellster
priority: normal
severity: normal
status: open
title: os.walk conflicts with os.listdir
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jan 14 18:31:58 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 14 Jan 2014 17:31:58 +0000
Subject: [New-bugs-announce] [issue20260] Argument Clinic: add unsigned
	integers converters
Message-ID: <1389720718.78.0.860738296491.issue20260@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch adds support for non-bitwise unsigned integer arguments in Argument Clinic. I.e. now unsigned_int(bitwise=False) (or just unsigned_int) converts Python int in range from 0 to UINT_MAX to C unsigned int. Added support for unsigned_short, unsigned_int, unsigned_long, unsigned_PY_LONG_LONG, and size_t.

Also added global private functions _Py_UnsignedShort_Converter(), _Py_UnsignedInt_Converter(), _Py_UnsignedLong_Converter(), _Py_UnsignedLongLong_Converter(), and _Py_Size_t_Converter(), which are used by Argument Clinic and in C code still not converted to Argument Clinic.

----------
components: Demos and Tools, Interpreter Core
files: clinic_unsigned_converters.patch
keywords: patch
messages: 208102
nosy: georg.brandl, larry, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Argument Clinic: add unsigned integers converters
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33464/clinic_unsigned_converters.patch

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

From report at bugs.python.org  Tue Jan 14 20:46:07 2014
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 14 Jan 2014 19:46:07 +0000
Subject: [New-bugs-announce] [issue20261] Cannot pickle some objects that
	have a __getattr__()
Message-ID: <1389728767.16.0.141259686696.issue20261@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

I've been debugging a crash in nose 1.3.0, the root cause of which turned out to be an instance containing an attribute which itself was an instance of the following class (boiled down):

class Picky:
    def __getstate__(self):
        return {}
    def __getattr__(self, attr):
        return None

This crashes with a TypeError in Python 2.7 and Python 3 (albeit with slightly different tracebacks; and Python 3 is more difficult to debug because the TypeError doesn't include any useful information).

TypeError: 'NoneType' object is not callable

The culprit is __getattr__() returning None.  In Python 3 for example, pickle tries to get the object's __reduce_ex__() function and then call it.

The problem is the (IMHO) bogus __getattr__() and I'm not sure why nose has this.  But I wonder if the pickle documentation should warn against this kind of thing.

This isn't a bug in Python - the crash makes sense when you understand the implications, but perhaps a warning in the docs would have helped prevent this nose bug in the first place.  I suppose I could also see improving _pickle.c to provide some additional feedback on the offending attribute, but that's probably more difficult.

It's okay to close this as won't fix if we can't think of appropriate wording.  It's enough that there's a record of this issue for search engines now.

----------
assignee: docs at python
components: Documentation
messages: 208108
nosy: barry, docs at python
priority: normal
severity: normal
status: open
title: Cannot pickle some objects that have a __getattr__()
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/issue20261>
_______________________________________

From report at bugs.python.org  Tue Jan 14 21:56:35 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 14 Jan 2014 20:56:35 +0000
Subject: [New-bugs-announce] [issue20262] Convert some debugging prints in
	zipfile to warnings
Message-ID: <1389732995.51.0.822070396354.issue20262@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

When ZipFile.debug is not zero, some debugging messages are printed to stdout. Some of them are for debugging the zipfile module itself. But some are warnings about user's operation which perhaps make not what the user is expected -- truncating long archive comment or adding a file with duplicated name. These cases cases can be considered as logic error, they can be prevented by external checks (check that comment's length does not excite the limit and that specified name is not in the ZIP file). So it will be sane and helpful to convert these prints to regular warnings, which are controlled in same way as all other warnings.

See also issue2824. It have a patch which looks too excessive to me.

Here is a patch. I don't sure to which version it should be targeted.

----------
components: Library (Lib)
files: zipfile_warnings.patch
keywords: patch
messages: 208112
nosy: alanmcintyre, georg.brandl, larry, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Convert some debugging prints in zipfile to warnings
Added file: http://bugs.python.org/file33468/zipfile_warnings.patch

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

From report at bugs.python.org  Wed Jan 15 01:40:07 2014
From: report at bugs.python.org (Ozy)
Date: Wed, 15 Jan 2014 00:40:07 +0000
Subject: [New-bugs-announce] [issue20263] Function print definable as
	variables?
Message-ID: <1389746407.11.0.333794410769.issue20263@psf.upfronthosting.co.za>


New submission from Ozy:

Not sure if this is a bug. We're experiencing it in v3.3.2 and was discovered by accident.

It seems to be possible to define python functions (like print or input) as variables, as if they're not reserved. If you do that, the command functionality is lost until Python is reseted.

For example try this in IDLE:

>>> print = 10
>>> print
10
>>> print(print)
TypeError: int object is not callable
>>> print(10)
TypeError: int object is not callable

Here is a screenshot >

http://imgur.com/IpjELhp

We tested it, and this doesn't happen in v2.

Sorry if this has been reported previously.

Best regards.

----------
messages: 208125
nosy: ozy
priority: normal
severity: normal
status: open
title: Function print definable as variables?
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Jan 15 04:12:39 2014
From: report at bugs.python.org (Meador Inge)
Date: Wed, 15 Jan 2014 03:12:39 +0000
Subject: [New-bugs-announce] [issue20264] Update patchcheck to looks for
	files with clinic comments
Message-ID: <1389755559.69.0.925028805372.issue20264@psf.upfronthosting.co.za>


New submission from Meador Inge:

It has been noted a few times that someone might forget to re-run
clinic.py after updating the argument clinic comments.  The attached
patch adds a new check to patchcheck.py to note when files containing
argument clinic comments have been changed.  You could take it a step
further and deduce if the lines ranges within the comments were actually
changed, but let's start out simple.

----------
assignee: meador.inge
components: Build
files: patchcheck-clinic.patch
keywords: patch
messages: 208132
nosy: larry, meador.inge
priority: normal
severity: normal
stage: patch review
status: open
title: Update patchcheck to looks for files with clinic comments
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33471/patchcheck-clinic.patch

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

From report at bugs.python.org  Wed Jan 15 04:41:05 2014
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 15 Jan 2014 03:41:05 +0000
Subject: [New-bugs-announce] [issue20265] Bring Doc/using/windows up to date
Message-ID: <1389757265.26.0.116885263001.issue20265@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Doc/using/windows still mentions DOS, Windows 3.x, and Python 2.1, and that's just in the first short section.  This is a catch-all issue for making sure that page is up to date.

----------
assignee: docs at python
components: Documentation, Windows
keywords: easy
messages: 208136
nosy: docs at python, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Bring Doc/using/windows up to date
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Jan 15 05:00:49 2014
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 15 Jan 2014 04:00:49 +0000
Subject: [New-bugs-announce] [issue20266] Bring Doc/faq/windows up to date
Message-ID: <1389758449.02.0.48240700444.issue20266@psf.upfronthosting.co.za>


New submission from Zachary Ware:

The Python on Windows faq could use some TLC.  For instance, cx_Freeze should be mentioned in the faq about creating an executable (and py2exe should either mention that it doesn't quite support 3.x yet, or just be removed until it does), and the embedding faq should be cleaned up with proper voice and formatting (and the "undocumented facts" should be documented).

----------
assignee: docs at python
components: Documentation, Windows
keywords: easy
messages: 208138
nosy: docs at python, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Bring Doc/faq/windows up to date
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Jan 15 05:48:28 2014
From: report at bugs.python.org (Antony Lee)
Date: Wed, 15 Jan 2014 04:48:28 +0000
Subject: [New-bugs-announce] [issue20267] TemporaryDirectory does not
	resolve path when created	using a relative path
Message-ID: <1389761308.4.0.00958902784577.issue20267@psf.upfronthosting.co.za>


New submission from Antony Lee:

Essentially, the following fails:

t = tempfile.TemporaryDirectory(dir=".")
os.chdir(some_other_dir)
t.cleanup()

because t.name is a relative path.  Resolving the "dir" argument when the directory is created should(?) fix the issue.

----------
components: Library (Lib)
messages: 208141
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: TemporaryDirectory does not resolve path when created using a relative path
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan 15 06:49:19 2014
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 15 Jan 2014 05:49:19 +0000
Subject: [New-bugs-announce] [issue20268] Argument Clinic: support cloning
	existing functions
Message-ID: <1389764959.28.0.222102740928.issue20268@psf.upfronthosting.co.za>


New submission from Larry Hastings:

It was a quick hack: Clinic now has a syntax for cloning an existing
function!  The first line of the function block should be 

    module.class.new_function [as c_basename] = module.class.existing_fn

Hurry up and give me a LGTM so you can use it everywhere! :D

----------
assignee: larry
files: larry.clinic.clone.functions.diff.1.txt
messages: 208143
nosy: georg.brandl, larry, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Argument Clinic: support cloning existing functions
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33476/larry.clinic.clone.functions.diff.1.txt

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

From report at bugs.python.org  Wed Jan 15 10:28:52 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 15 Jan 2014 09:28:52 +0000
Subject: [New-bugs-announce] [issue20269] Inconsistent behavior in pdb when
	pressing Ctrl-C
Message-ID: <1389778132.96.0.0363637857633.issue20269@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

With this script:
# START
def foo():
    while 1:
        pass

import pdb; pdb.set_trace()
foo()
# END

The following sequence of pdb commands aborts the script with a KeyboardInterrupt exception:
  next
  Ctrl-C
  continue

While the equivalent following sequence of commands allows the debugging session to continue as
expected:
  continue
  Ctrl-C
  continue

The first sequence of commands should behave as the second one.

A related problem is that the original SIGINT handler (named _previous_sigint_handler in the code)
is not restored when the program being debugged is stopped at a breakpoint that has been reached
after 'continue'.  _previous_sigint_handler is lost forever in this case when the user hits
'continue' after stopping at that breakpoint, which is quite common. This is annoying. For example,
trying to extend pdb with a 'detach' command that enables the debuggee to run freely after the
debugging session is terminated: the program cannot be killed anymore with SIGINT when the above
case occurs.

The attached patch attempts to fix these problems.
After applying the attached patch, the behavior of the 'next, Ctrl-C, continue' sequence of commands
is still wrong: this is another bug logged at issue 14788 with a patch and a test. Applying patch
14788 fixes this.

----------
components: Library (Lib)
files: sigint.patch
keywords: patch
messages: 208151
nosy: georg.brandl, xdegaye
priority: normal
severity: normal
status: open
title: Inconsistent behavior in pdb when pressing Ctrl-C
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file33478/sigint.patch

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

From report at bugs.python.org  Wed Jan 15 13:26:25 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 15 Jan 2014 12:26:25 +0000
Subject: [New-bugs-announce] [issue20270] urllib.parse doesn't work with
	empty port
Message-ID: <1389788785.56.0.178405230158.issue20270@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

According to RFC 3986 the port subcomponent is defined as zero or more decimal digits delimited from the host by a single colon. I.e. 'python.org:' is valid (but not normalized) form. Empty port is equivalent to absent port.

>>> import urllib.parse
>>> p = urllib.parse.urlparse('http://python.org:')
>>> p.hostname
'python.org'
>>> p.port  # should return None
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython-3.3/Lib/urllib/parse.py", line 156, in port
    port = int(port, 10)
ValueError: invalid literal for int() with base 10: ''
>>> urllib.parse.splitport('python.org:')  # should return ('python.org', None)
('python.org:', None)
>>> urllib.parse.splitnport('python.org:')  # should return ('python.org', -1)
('python.org', None)
>>> urllib.parse.splitnport('python.org:', 80)  # should return ('python.org', 80)
('python.org', None)

Proposed patch fixes this. It also adds tests for urllib.parse.splitport().

----------
components: Library (Lib)
files: urllib_parse_empty_port.patch
keywords: patch
messages: 208155
nosy: orsenthil, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: urllib.parse doesn't work with empty port
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33480/urllib_parse_empty_port.patch

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

From report at bugs.python.org  Wed Jan 15 13:32:09 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 15 Jan 2014 12:32:09 +0000
Subject: [New-bugs-announce] [issue20271] urllib.parse.urlparse() accepts
	wrong URLs
Message-ID: <1389789129.93.0.775761654638.issue20271@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

>>> import urllib.parse
>>> p = urllib.parse.urlparse('http://[::1]spam:80')
>>> p
ParseResult(scheme='http', netloc='[::1]spam:80', path='', params='', query='', fragment='')
>>> p.hostname
'::1'
>>> p.port
80

'http://[::1]spam:80' is invalid URL, but urllib.parse.urlparse() accepts it and just ignore the spam part.

----------
components: Library (Lib)
messages: 208156
nosy: orsenthil, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: urllib.parse.urlparse() accepts wrong URLs
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Jan 15 20:59:37 2014
From: report at bugs.python.org (SilentGhost)
Date: Wed, 15 Jan 2014 19:59:37 +0000
Subject: [New-bugs-announce] [issue20272] chain.from_iterable in the
	overview table not linking to	the function
Message-ID: <1389815977.04.0.427053880301.issue20272@psf.upfronthosting.co.za>


New submission from SilentGhost:

chain.from_iterable is not linkified in the overview table at the top of the itertools docs. The patch requires reformat of the table.

----------
assignee: docs at python
components: Documentation
files: linkify.diff
keywords: patch
messages: 208184
nosy: SilentGhost, docs at python, rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: chain.from_iterable in the overview table not linking to the function
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file33484/linkify.diff

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

From report at bugs.python.org  Wed Jan 15 21:17:32 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 15 Jan 2014 20:17:32 +0000
Subject: [New-bugs-announce] [issue20273] Argument Clinic: unhelpful crashes
Message-ID: <1389817052.38.0.962470958288.issue20273@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Sometimes when Argument Clinic see something wrong, it raises exception and exit with printed traceback, instead of output helpful error message which points on line with illegal syntax.

I open this issue to report about such problems.

$ ./python Tools/clinic/clinic.py -f Modules/zlibmodule.c
Traceback (most recent call last):
  File "Tools/clinic/clinic.py", line 3032, in <module>
    sys.exit(main(sys.argv[1:]))
  File "Tools/clinic/clinic.py", line 3028, in main
    parse_file(filename, output=ns.output, verify=not ns.force)
  File "Tools/clinic/clinic.py", line 1135, in parse_file
    cooked = clinic.parse(raw)
  File "Tools/clinic/clinic.py", line 1085, in parse
    parser.parse(block)
  File "Tools/clinic/clinic.py", line 2262, in parse
    self.state(line)
  File "Tools/clinic/clinic.py", line 2582, in state_parameter
    value = eval(py_default)
  File "<string>", line 1, in <module>
NameError: name 'zlib' is not defined

zlibmodule.c is almost same as after applying patch from issue20193 (with several clinic bugs already fixed).

----------
components: Demos and Tools
messages: 208188
nosy: larry, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Argument Clinic: unhelpful crashes
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan 15 21:24:43 2014
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 15 Jan 2014 20:24:43 +0000
Subject: [New-bugs-announce] [issue20274] sqlite module has bad argument
	parsing code, including undefined behavior in C
Message-ID: <1389817483.8.0.407525727046.issue20274@psf.upfronthosting.co.za>


New submission from Larry Hastings:

The code in Modules/_sqlite/connection.c is sloppy.

The functions pysqlite_connection_execute, pysqlite_connection_executemany, and pysqlite_connection_executescript accept a third "PyObject *kwargs".  However none of these functions are marked METH_KEYWORD.  This only works because the kwargs parameter is actually ignored--the functions only support positional-only arguments.  Obviously the "PyObject *kwargs" parameters should be removed for these three functions.

A slightly more advanced problem: pysqlite_connection_call, which implements sqlite3.Connection.__call__(), ignores its kwargs parameter completely.  If it doesn't accept keyword parameters it should at least complain if any are passed in.

Georg: you want this fixed in 3.3?  3.2?
Benjamin: you want this fixed in 2.7?

----------
messages: 208189
nosy: benjamin.peterson, georg.brandl, larry
priority: normal
severity: normal
stage: needs patch
status: open
title: sqlite module has bad argument parsing code, including undefined behavior in C
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan 15 23:11:04 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 15 Jan 2014 22:11:04 +0000
Subject: [New-bugs-announce] [issue20275] asyncio: remove debug code from
	BaseEventLoop
Message-ID: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

Can we remove debug timing around "self._selector.select(timeout)"
(or at least make it configurable) from BaseEventLoop?

Right now the code is:

        # TODO: Instrumentation only in debug mode?
        t0 = self.time()
        event_list = self._selector.select(timeout)
        t1 = self.time()
        argstr = '' if timeout is None else ' {:.3f}'.format(timeout)
        if t1-t0 >= 1:
            level = logging.INFO
        else:
            level = logging.DEBUG
        logger.log(level, 'poll%s took %.3f seconds', argstr, t1-t0)

So it makes two 'time.time()' calls per loop iteration, plus
one "logging.log" call.

The only non-intrusive solution that I can suggest is to add a
class attribute '_debug' to BaseEventLoop, set to False by default
(unittests can set it to True in their setUp methods).

----------
components: Library (Lib)
messages: 208199
nosy: gvanrossum, pitrou, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: remove debug code from BaseEventLoop
type: performance
versions: Python 3.5

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

From report at bugs.python.org  Thu Jan 16 02:20:50 2014
From: report at bugs.python.org (Albert Zeyer)
Date: Thu, 16 Jan 2014 01:20:50 +0000
Subject: [New-bugs-announce] [issue20276] ctypes._dlopen should not force
	RTLD_NOW
Message-ID: <1389835250.18.0.994187095124.issue20276@psf.upfronthosting.co.za>


New submission from Albert Zeyer:

On MacOSX, when you build an ARC-enabled Dylib with backward compatibility for e.g. MacOSX 10.6, some unresolved functions like `_objc_retainAutoreleaseReturnValue` might end up in your Dylib.

Some reference about the issue:
1. http://stackoverflow.com/q/21119425/133374>.
2. http://osdir.com/ml/python.ctypes/2006-10/msg00029.html
3. https://groups.google.com/forum/#!topic/comp.lang.python/DKmNGwyLl3w

Thus, RTLD_NOW is often not an option for MacOSX.

This affects mostly `py_dl_open()` from ctypes.
But it is also related how you set `dlopenflags` in `PyInterpreterState_New()`.

I suggest to make RTLD_LAZY the default on MacOSX (or is there a good reason not to do?).
Also, ctypes should have options for both RTLD_NOW and RTLD_LAZY so that both can be used.

This is also consistent with the behavior of the [dl module](http://docs.python.org/2/library/dl.html).

----------
components: ctypes
messages: 208226
nosy: Albert.Zeyer
priority: normal
severity: normal
status: open
title: ctypes._dlopen should not force RTLD_NOW
versions: Python 2.7

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

From report at bugs.python.org  Thu Jan 16 09:23:25 2014
From: report at bugs.python.org (xwild)
Date: Thu, 16 Jan 2014 08:23:25 +0000
Subject: [New-bugs-announce] [issue20277] default __debug__ value and asserts
Message-ID: <1389860605.32.0.0951203390882.issue20277@psf.upfronthosting.co.za>


New submission from xwild:

Why the python sets the "__debug__" builtin = True by default?
It causes that people never use the "assert" construction 
by their programms in a regular way.

it's too hard to explain everyone that "-O" is required by a script.
It's very usefull instruction and actually it's blocked by default.

----------
components: Interpreter Core, Tests
messages: 208256
nosy: xwild
priority: normal
severity: normal
status: open
title: default __debug__ value and asserts
type: behavior
versions: 3rd party, 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/issue20277>
_______________________________________

From report at bugs.python.org  Thu Jan 16 10:11:32 2014
From: report at bugs.python.org (Richard Philips)
Date: Thu, 16 Jan 2014 09:11:32 +0000
Subject: [New-bugs-announce] [issue20278] Wrong URL to the pysqlite web page
Message-ID: <1389863492.56.0.743244372152.issue20278@psf.upfronthosting.co.za>


New submission from Richard Philips:

The reference to the pysqlite web page on:

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

should be:

    https://github.com/ghaering/pysqlite

----------
assignee: docs at python
components: Documentation
messages: 208261
nosy: Richard.Philips, docs at python
priority: normal
severity: normal
status: open
title: Wrong URL to the pysqlite web page
versions: Python 3.4

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

From report at bugs.python.org  Thu Jan 16 12:33:15 2014
From: report at bugs.python.org (Anatoly Belikov)
Date: Thu, 16 Jan 2014 11:33:15 +0000
Subject: [New-bugs-announce] [issue20279] bytearray.fromhex does not work
	with some hexes	generated by hex
Message-ID: <1389871995.67.0.0459502890615.issue20279@psf.upfronthosting.co.za>


New submission from Anatoly Belikov:

bytearray.fromhex(hex(434)[2:]) 

throws ValueError: non-hexadecimal number found in fromhex() arg at position 2

Strangely it works with leading zero:

bytearray.fromhex('0' + hex(438)[2:])

----------
components: Library (Lib)
messages: 208273
nosy: Anatoly Belikov
priority: normal
severity: normal
status: open
title: bytearray.fromhex does not work with some hexes generated by hex
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Jan 16 14:25:50 2014
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 16 Jan 2014 13:25:50 +0000
Subject: [New-bugs-announce] [issue20280] add "predicate" to the glossary
Message-ID: <1389878750.92.0.454847187289.issue20280@psf.upfronthosting.co.za>


New submission from Florent Xicluna:

This term is used in various places in the documentation.
http://docs.python.org/dev/search.html?q=predicate

Probably it deserves an entry in the glossary, even if it is not specific to Python:
http://en.wikipedia.org/wiki/Predicate_%28mathematical_logic%29

----------
assignee: docs at python
components: Documentation
messages: 208277
nosy: docs at python, flox
priority: low
severity: normal
status: open
title: add "predicate" to the glossary
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jan 16 19:35:42 2014
From: report at bugs.python.org (Mike Owens)
Date: Thu, 16 Jan 2014 18:35:42 +0000
Subject: [New-bugs-announce] [issue20281] time.strftime %z format specifier
	is the same as %Z
Message-ID: <1389897342.88.0.737767593135.issue20281@psf.upfronthosting.co.za>


New submission from Mike Owens:

When using strftime from the time module on 64bit Python for Windows the format specifier %z gives the time zone name instead of the time zone offset as stated in the documentation.

eg
>>> strftime("%z")
'US Mountain Standard Time'
>>> strftime("%Z")
'US Mountain Standard Time'

The expected output for my time zone is -7:00.

----------
components: Library (Lib)
messages: 208295
nosy: Mike.Owens
priority: normal
severity: normal
status: open
title: time.strftime %z format specifier is the same as %Z
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Jan 16 21:18:38 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 16 Jan 2014 20:18:38 +0000
Subject: [New-bugs-announce] [issue20282] Argument Clinic: int with boolean
	default
Message-ID: <1389903518.09.0.378571732154.issue20282@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently in many functions boolean argument parsed as int, with 'i' code. When converting this to Argument Clinic we can't write just

    interactive: int = False

because C default becomes "Py_False".

Instead we need explicitly specify c_default.

    interactive: int(c_default="0") = False

It would be good if True/False default values be converted to 1/0 C default values for the int type.

I think this is enough common situation.

----------
components: Demos and Tools
messages: 208304
nosy: georg.brandl, larry, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Argument Clinic: int with boolean default
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Jan 16 21:44:27 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 16 Jan 2014 20:44:27 +0000
Subject: [New-bugs-announce] [issue20283] Wrong keyword parameter name in
	regex pattern methods
Message-ID: <1389905067.44.0.489524795145.issue20283@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Documented (in docstring and in ReST documentation) signatures of the match, search and (since 3.4) fullmatch methods of regex pattern object are:

match(string[, pos[, endpos]])
search(string[, pos[, endpos]])
fullmatch(string[, pos[, endpos]])

However in implementation the first keyword argument by mistake named "pattern". This looks as nonsense. The pattern is object itself, and first argument is a string. First arguments in other methods (split, findall, etc) named "string", and module-level functions have both "pattern" and "string" parameters:

match(pattern, string, flags=0)
search(pattern, string, flags=0)

I think we should fix this mistake. The "pattern" name is obviously wrong and is not match the documentation.

----------
components: Library (Lib)
messages: 208311
nosy: ezio.melotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Wrong keyword parameter name in regex pattern methods
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Jan 16 22:33:09 2014
From: report at bugs.python.org (Neil Schemenauer)
Date: Thu, 16 Jan 2014 21:33:09 +0000
Subject: [New-bugs-announce] [issue20284] proof for concept patch for bytes
	formatting methods
Message-ID: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za>


New submission from Neil Schemenauer:

This is a very rough, proof of concept patch that implements %-style formatting for bytes objects.  Currently it calls __format__ with a bytes argument and expects a bytes result.  I've only implemented 
support for bytes formatting for the 'long' object.

Expected behavior:

>>> b'%s' % b'hello'
b'hello'
>>> b'%s' % 'hello'
TypeError is raised
>>> b'%s' % 123
b'123'
>>> b'%d' % 123
b'123'

Some issues:

- %s support is incomplete, needs to handle width and padding.  I think it should be done in formatbytes().

- PyBytes_Format function very likely has bugs, I copied it mostly from Python 2 and quickly made it run, I did very little testing.

- long__format__ with a bytes argument is inefficient.  It creates temporary Python objects that could be avoided.  %-style formatting on bytes will be much less efficient than str in Python 2.  We could inline the handling of certain types in PyBytes_Format, maybe longs only would be sufficent.

- I'm not sure overloading __format__ is the best approach.  Maybe we should introduce a new method, say __ascii__ instead and have PyBytes_Format call that.

----------
components: Interpreter Core
files: bytes_mod.patch
keywords: patch
messages: 208313
nosy: nascheme
priority: normal
severity: normal
stage: patch review
status: open
title: proof for concept patch for bytes formatting methods
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file33501/bytes_mod.patch

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

From report at bugs.python.org  Fri Jan 17 01:59:11 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Jan 2014 00:59:11 +0000
Subject: [New-bugs-announce] [issue20285] Improve object.__doc__ and
	help(object) output
Message-ID: <1389920351.63.0.12805701843.issue20285@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

>>> object.__doc__
'The most base type'

Since 'most base' can be interpreted as 'least desireable', several people on Python list (2013 Dec, "interactive help on the base object") agree that this should be improved. Even is 'most base' is interpreted as a value-free 'bottommost', there is the direction issue. Whether the root of a tree or DAG is at top or bottom or side depends on how the graph is drawn. I suggest

"The superclass for all Python classes."

===
>>> help(object)
Help on class object in module builtins:

class object
 |  The most base type
===

I think help(object) should display the methods defined on the object class just as it does on all the other classes. The apparent problem is that help(subclass) supresses the object methods, but it should not for object itself.

----------
messages: 208317
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Improve object.__doc__ and help(object) output
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Jan 17 02:35:19 2014
From: report at bugs.python.org (Ali Ebrahim)
Date: Fri, 17 Jan 2014 01:35:19 +0000
Subject: [New-bugs-announce] [issue20286] Segfault when using internal
	DictProxy
Message-ID: <1389922519.38.0.20276094539.issue20286@psf.upfronthosting.co.za>


New submission from Ali Ebrahim:

Demonstration in this gist: https://gist.github.com/aebrahim/8466660
Crash info in this gist: https://gist.github.com/aebrahim/8466749

The code runs without issue on Ubuntu 12.04 (Python 2.7.3), and Windows 7 (Python 2.7.6).

It also ran fine on MacOS X 10.8 (Python 2.7.2). However, it failed with MacOX X 10.9 for both 2.7.5 (version shipped by Apple) and 2.7.6

Python version information details:
2.7.2
Python 2.7.2 (default, Oct 11 2012, 20:14:37) [GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin

2.7.5
Python 2.7.5 (default, Aug 25 2013, 00:04:04) 
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin

2.7.6
Python 2.7.6 (v2.7.6:3a1db0d2747e, Nov 10 2013, 00:42:54) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin

----------
assignee: ronaldoussoren
components: Macintosh
messages: 208318
nosy: Ali.Ebrahim, ronaldoussoren
priority: normal
severity: normal
status: open
title: Segfault when using internal DictProxy
versions: Python 2.7

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

From report at bugs.python.org  Fri Jan 17 08:35:58 2014
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 17 Jan 2014 07:35:58 +0000
Subject: [New-bugs-announce] [issue20287] Argument Clinic: support diverting
	output to buffer, external file, etc
Message-ID: <1389944158.18.0.307156648296.issue20287@psf.upfronthosting.co.za>


New submission from Larry Hastings:

The long-awaited, highly desirable "buffer" patch is here!  With features I figured would never see the light of day.

Changes in this patch:

* New directive "output":
    output <field> <destination>
  redirects a "field" (subsection of Clinic's generated code)
  to an alternate "destination" (someplace besides the output block)
  predefined destinations: block buffer file two-pass suppress

* Alternate use of "output":
    output preset <name>
  redirects all destinations en mass based on a precreated scenario
  predefined presets: original file buffer partial-buffer two-pass

* New directive "destination":
    destination <name> <type> [<filename>]
  creates new destinations for use with "output"
  valid types: buffer file two-pass suppress

* New directive "dump":
    dump <destination>
  dumps the contents of a destination into the current file

* New directive "preserve":
    preserve
  preserves the current output in an output block (used by "file"
  destinations)

* New directive "set":
   set line_prefix <prefix>
   set line_suffix <suffix>

* New output template, uses PyArg_UnpackTuple

* New compact output template, for simple METH_O, only one line

* "args" and "kwargs" variables in C renamed to "_args" and "_kwargs"

Patch is not ready for checkin, as it still needs documentation.  But it's ready for code review!

There's a lot of churn in the C files.  That's due to the following
changes, in order of frequency:

  * "args" -> "_args"
  * "kwargs" -> "_kwargs"
  * new concise METH_O template
  * PyArg_UnpackTuple generator

----------
assignee: larry
files: larry.clinic.buffer.patch.1.txt
messages: 208325
nosy: georg.brandl, larry, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Argument Clinic: support diverting output to buffer, external file, etc
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33503/larry.clinic.buffer.patch.1.txt

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

From report at bugs.python.org  Fri Jan 17 15:06:13 2014
From: report at bugs.python.org (Anders Hammarquist)
Date: Fri, 17 Jan 2014 14:06:13 +0000
Subject: [New-bugs-announce] [issue20288] HTMLParse handing of non-numeric
	charrefs broken
Message-ID: <1389967573.45.0.115549710544.issue20288@psf.upfronthosting.co.za>


New submission from Anders Hammarquist:

Python 2.7 HTMLParse.py lines 185-199 (similar lines still exist in Python 3.4)
                match = charref.match(rawdata, i)
                if match:
                    ...
                else:
                    if ";" in rawdata[i:]: #bail by consuming &#
                        self.handle_data(rawdata[0:2])
                        i = self.updatepos(i, 2)
                    break

if you feed a broken charref, that is non-numeric, it will pass whatever random string that happened to be at the start of rawdata to handle_data(). Eg:

p = HTMLParser()
p.handle_data = lambda x: sys.stdout.write(x)
p.feed('<p>&#foo;</p>')

will print '<p' which is clearly wrong. I think the intention of the code is to pass '&#', which seems saner.

----------
components: Library (Lib)
messages: 208336
nosy: iko
priority: normal
severity: normal
status: open
title: HTMLParse handing of non-numeric charrefs broken
type: behavior

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

From report at bugs.python.org  Fri Jan 17 15:47:25 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 17 Jan 2014 14:47:25 +0000
Subject: [New-bugs-announce] [issue20289] Make cgi.FieldStorage a context
	manager
Message-ID: <1389970045.35.0.547540590752.issue20289@psf.upfronthosting.co.za>


New submission from Brett Cannon:

It has a file attribute which contains a file, so making it so it can be closed faster than cgi.FieldStorage.__del__ would be good.

----------
components: Library (Lib)
messages: 208338
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Make cgi.FieldStorage a context manager
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Jan 17 22:08:16 2014
From: report at bugs.python.org (cqxz)
Date: Fri, 17 Jan 2014 21:08:16 +0000
Subject: [New-bugs-announce] [issue20290] inspect module bug for modules
	with same filename
Message-ID: <1389992896.56.0.367733971337.issue20290@psf.upfronthosting.co.za>


New submission from cqxz:

When two files have the same name and the first changes directory to the second, the inspect module can retrieve the source code for the latter incorrectly, so a simple call to inspect.stack() can be incorrect, and will fail if there are less lines in the nested module (foo/bar/mod.py) than in the calling module (foo/mod.py)

foo/mod.py
foo/bar/mod.py

(the foo/bar/mod.py need only contain a single line, e.g. print "hello")

----------
components: Extension Modules
files: mod.py
messages: 208362
nosy: Nick.Rhinehart
priority: normal
severity: normal
status: open
title: inspect module bug for modules with same filename
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file33519/mod.py

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

From report at bugs.python.org  Sat Jan 18 02:55:25 2014
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 18 Jan 2014 01:55:25 +0000
Subject: [New-bugs-announce] [issue20291] Argument Clinic should understand
	*args and **kwargs	parameters
Message-ID: <1390010125.91.0.58212727704.issue20291@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Argument Clinic currently prevents the "impl" function from ever seeing the "args" tuple or the "kwargs" dict.  There should be a way to ask it to pass those values in to the "impl" function.

----------
assignee: larry
messages: 208380
nosy: larry, meador.inge
priority: normal
severity: normal
stage: needs patch
status: open
title: Argument Clinic should understand *args and **kwargs parameters
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Jan 18 05:50:51 2014
From: report at bugs.python.org (Ryan Smith-Roberts)
Date: Sat, 18 Jan 2014 04:50:51 +0000
Subject: [New-bugs-announce] [issue20292] clinic.py str_converter with
	encoding throws exception
Message-ID: <1390020651.69.0.606009700331.issue20292@psf.upfronthosting.co.za>


New submission from Ryan Smith-Roberts:

Find test file attached. The exception:

Exception raised during parsing:
Traceback (most recent call last):
...
  File "proj/python/trunk.hg/Tools/clinic/clinic.py", line 1535, in render
    self.parse_argument(data.parse_arguments)
  File "proj/python/trunk.hg/Tools/clinic/clinic.py", line 1563, in parse_argument
    list.append(c_repr(self.encoding))
NameError: global name 'c_repr' is not defined

----------
components: Build
files: clinic_encoding_exception.c
messages: 208384
nosy: larry, rmsr
priority: normal
severity: normal
status: open
title: clinic.py str_converter with encoding throws exception
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file33522/clinic_encoding_exception.c

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

From report at bugs.python.org  Sat Jan 18 12:43:18 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Jan 2014 11:43:18 +0000
Subject: [New-bugs-announce] [issue20293] pydoc fails with the "unspecified"
	default value
Message-ID: <1390045398.5.0.236293557583.issue20293@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

With patch for the zlib module (issue20193) which uses the "unspecified" default value:

$ ./python -m pydoc zlib
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 1997, in wrap_value
    value = eval(s, module_dict)
  File "<string>", line 1, in <module>
NameError: name 'unspecified' is not defined

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 2000, in wrap_value
    value = eval(s, sys_module_dict)
  File "<string>", line 1, in <module>
NameError: name 'unspecified' is not defined

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/runpy.py", line 189, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/serhiy/py/cpython/Lib/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 2593, in <module>
    cli()
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 2558, in cli
    help.help(arg)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1840, in help
    elif request: doc(request, 'Help on %s:', output=self._output)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1578, in doc
    pager(render_doc(thing, title, forceload))
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1571, in render_doc
    return title % desc + '\n\n' + renderer.document(object, name)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 356, in document
    if inspect.ismodule(object): return self.docmodule(*args)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1142, in docmodule
    contents.append(self.document(value, key, name))
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 358, in document
    if inspect.isroutine(object): return self.docroutine(*args)
  File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1323, in docroutine
    signature = inspect.signature(object)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 1468, in signature
    return Signature.from_builtin(obj)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 2052, in from_builtin
    p(name, default)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 2038, in p
    default_node = RewriteSymbolics().visit(default_node)
  File "/home/serhiy/py/cpython/Lib/ast.py", line 245, in visit
    return visitor(node)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 2030, in visit_Name
    return wrap_value(node.id)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 2002, in wrap_value
    raise RuntimeError()
RuntimeError

----------
messages: 208394
nosy: larry, serhiy.storchaka
priority: normal
severity: normal
status: open
title: pydoc fails with the "unspecified" default value
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Jan 18 12:43:26 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Jan 2014 11:43:26 +0000
Subject: [New-bugs-announce] [issue20294] Argument Clinic: add support for
	__init__
Message-ID: <1390045406.06.0.938757132567.issue20294@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently Argument Clinic doesn't support the __init__ methods, mainly because the C implementation of this method should return int, not PyObject *. In some cases it is possible to wrap a function generated by Argument Clinic (as in Modules/_pickle.c). But not always, because the __init__ method is called with the self, args, and kwargs arguments, while Argument Clinic can generate function without kwargs.

----------
components: Demos and Tools
messages: 208395
nosy: larry, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Argument Clinic: add support for __init__
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Jan 18 19:45:46 2014
From: report at bugs.python.org (Martin Vignali)
Date: Sat, 18 Jan 2014 18:45:46 +0000
Subject: [New-bugs-announce] [issue20295] imghdr add openexr support
Message-ID: <1390070746.18.0.632580086157.issue20295@psf.upfronthosting.co.za>


New submission from Martin Vignali:

Add support for detect openexr file (http://www.openexr.com/)
Based on information provided by :  http://www.openexr.com/ReadingAndWritingImageFiles.pdf

I make some tests, on different kind of exr file, to check, the new function.

----------
components: Library (Lib)
files: img_hdr_exr.patch
keywords: patch
messages: 208409
nosy: mvignali
priority: normal
severity: normal
status: open
title: imghdr add openexr support
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33531/img_hdr_exr.patch

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

From report at bugs.python.org  Sat Jan 18 20:22:50 2014
From: report at bugs.python.org (Rob Browning)
Date: Sat, 18 Jan 2014 19:22:50 +0000
Subject: [New-bugs-announce] [issue20296] PyArg_ParseTuple 2.X docs mention
	int for "t#", but "Py_ssize_t" for "w#", etc.
Message-ID: <1390072970.58.0.165278841581.issue20296@psf.upfronthosting.co.za>


New submission from Rob Browning:

Here (http://docs.python.org/2/c-api/arg.html), the documentation for "t#" says:

  t# (read-only character buffer) [char *, int]...

while the documentation for "w#" says:

  w# (read-write character buffer) [char *, Py_ssize_t]...

However, from getargs.c, it looks like they're handled the same with respect to the size type.

At a minimum, it seems like it might make sense to change these docs to match, and if "w#" and "t#" are actually handled similarly to "s#", it would be even better to just change their docs to match (or refer to) "s#"'s which are more detailed, i.e. they mention the PY_SSIZE_T_CLEAN issues, etc.

Thanks

----------
assignee: docs at python
components: Documentation
messages: 208410
nosy: docs at python, rlb
priority: normal
severity: normal
status: open
title: PyArg_ParseTuple 2.X docs mention int for "t#", but "Py_ssize_t" for "w#", etc.
versions: Python 2.7

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

From report at bugs.python.org  Sat Jan 18 22:19:35 2014
From: report at bugs.python.org (Glenn Langford)
Date: Sat, 18 Jan 2014 21:19:35 +0000
Subject: [New-bugs-announce] [issue20297] concurrent.futures.as_completed()
	installs waiters for	already completed Futures
Message-ID: <1390079975.89.0.167689725202.issue20297@psf.upfronthosting.co.za>


New submission from Glenn Langford:

as_completed() calls _create_and_install_waiters() over all given Futures, even if some (or all) of the Futures have already completed.

The following fragment of the as_completed code (from 3.3.3):

with _AcquireFutures(fs):
        finished = set(
                f for f in fs
                if f._state in [CANCELLED_AND_NOTIFIED, FINISHED])
        pending = set(fs) - finished
        waiter = _create_and_install_waiters(fs, _AS_COMPLETED)

installs waiters into Futures contained in fs, rather than pending. 

A more efficient approach might be to only install waiters on the pending subset if necessary. This would be faster and would also result in less dwell time with all of the Future conditions locked via the _AcquireFutures context manager.

Also: waiters are appended with the Future condition lock acquired, but are removed (at the conclusion of as_completed) without the _AcquireFutures condition lock. Is this correct?

----------
components: Library (Lib)
messages: 208418
nosy: glangford
priority: normal
severity: normal
status: open
title: concurrent.futures.as_completed() installs waiters for already completed Futures
type: performance
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Jan 19 03:19:14 2014
From: report at bugs.python.org (David Barnett)
Date: Sun, 19 Jan 2014 02:19:14 +0000
Subject: [New-bugs-announce] [issue20298] json library needs a non-strict
	option to decode	single-quoted strings
Message-ID: <1390097954.47.0.6743273993.issue20298@psf.upfronthosting.co.za>


New submission from David Barnett:

Many sloppy JSON APIs return data with poorly-encoded strings, either with single-quotes as delimiters:
  {'foo': 'bar'}
or with no delimiters at all on keys:
  {foo: 'bar'}

The json library is useless for making sense of this data, because all it will tell you is "No JSON object could be decoded".

It would be incredibly helpful if the json library had some special non-strict decoding mode that could interpret these common misspellings of JSON strings. Or, more generally, it could accept another decoder hook to reformat the remaining string, something like:
  def malformed_hook(remaining, parent):
      if remaining.startswith("'"):
          # We know this is a string, regex it to find the end.
          m = re.match(pyparsing.quotedString.reString, remaining)
          if m is not None:
              # Use json.dumps to add quotes around string literal.
              return json.dumps(eval(m.group(0))) + remaining[m.end():]
      # If we're inside an object, this could be a naked object key.
      if isinstance(parent, dict):
          m = re.match(r'([a-zA-Z_]\w*):', remaining)
          if m is not None:
              return json.dumps(m.group(1)) + remaining[len(m.group(1)):]
  print(json.loads("['foo', null, {a: 'b'}]", malformed_hook=malformed_hook))
  ['foo', None, {'a': 'b'}]

This would at least save you having to write a parser/tokenizer from scratch.

----------
components: Library (Lib)
messages: 208430
nosy: mu_mind
priority: normal
severity: normal
status: open
title: json library needs a non-strict option to decode single-quoted strings
type: enhancement

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

From report at bugs.python.org  Sun Jan 19 06:39:40 2014
From: report at bugs.python.org (Ryan Smith-Roberts)
Date: Sun, 19 Jan 2014 05:39:40 +0000
Subject: [New-bugs-announce] [issue20299] Argument Clinic
	CConverter.__init__() overrides	c_default and py_default
Message-ID: <1390109980.95.0.0734854690372.issue20299@psf.upfronthosting.co.za>


New submission from Ryan Smith-Roberts:

The docs indicate that you can do:

class foo_converter(CConverter):
    ...
    c_default = 'bar()'
    py_default = 'Bar'

except that CConverter.__init__() unconditionally overwrites these values. Patch attached.

----------
components: Build
files: ac_overwritten_defaults.patch
keywords: patch
messages: 208447
nosy: larry, rmsr
priority: normal
severity: normal
status: open
title: Argument Clinic CConverter.__init__() overrides c_default and py_default
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33540/ac_overwritten_defaults.patch

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

From report at bugs.python.org  Sun Jan 19 06:46:48 2014
From: report at bugs.python.org (Ryan Smith-Roberts)
Date: Sun, 19 Jan 2014 05:46:48 +0000
Subject: [New-bugs-announce] [issue20300] Argument Clinic raises exception
	for custom converter	with default
Message-ID: <1390110408.19.0.159719739162.issue20300@psf.upfronthosting.co.za>


New submission from Ryan Smith-Roberts:

If a custom converter declares both default and converter class attributes, you get this exception (test file attached):

Exception raised during parsing:
Traceback (most recent call last):
  File "Tools/clinic/clinic.py", line 1445, in parse
    parser.parse(block)
  File "Tools/clinic/clinic.py", line 2738, in parse
    self.state(None)
  File "Tools/clinic/clinic.py", line 3468, in state_terminal
    self.function.docstring = self.format_docstring()
  File "Tools/clinic/clinic.py", line 3344, in format_docstring
    s += "".join(a)
TypeError: sequence item 2: expected str instance, NoneType found

----------
files: ac_converter_test.c
messages: 208448
nosy: Nikratio, larry, rmsr
priority: normal
severity: normal
status: open
title: Argument Clinic raises exception for custom converter with default
Added file: http://bugs.python.org/file33541/ac_converter_test.c

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

From report at bugs.python.org  Sun Jan 19 09:06:03 2014
From: report at bugs.python.org (Justin Foo)
Date: Sun, 19 Jan 2014 08:06:03 +0000
Subject: [New-bugs-announce] [issue20301] Correct docs for default access
	argument for DeleteKeyEx
Message-ID: <1390118763.24.0.151649669148.issue20301@psf.upfronthosting.co.za>


New submission from Justin Foo:

The default access for winreg.DeleteKeyEx is winreg.KEY_WOW64_64KEY (as per the function signature). This the documentation for Python 2.7 has this correct.

Reference: http://hg.python.org/cpython/file/2e32462e4832/PC/winreg.c#l1089

----------
assignee: docs at python
components: Documentation
files: winreg.DeleteKeyEx.docs.patch
keywords: patch
messages: 208462
nosy: docs at python, jfoo
priority: normal
severity: normal
status: open
title: Correct docs for default access argument for DeleteKeyEx
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33544/winreg.DeleteKeyEx.docs.patch

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

From report at bugs.python.org  Sun Jan 19 14:11:53 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Jan 2014 13:11:53 +0000
Subject: [New-bugs-announce] [issue20302] Argument Clinic: meaningful names
	for group flags
Message-ID: <1390137113.2.0.816137026514.issue20302@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently flags for optional groups are named as group_left_N and  group_right_N. It will be better if they have names use_param, use_param1_param2, etc. E.g. following declaration:

/*[clinic input]
curses.window.addstr

    self: self(type="PyCursesWindowObject *")
    [
    y: int
        Y-coordinate.
    x: int
        X-coordinate.
    ]

    str: object
        String to add.

    [
    attr: long
        Attributes for the character.
    ]
    /

[clinic start generated code]*/

Should produce signature:

static PyObject *
curses_window_addstr_impl(PyCursesWindowObject *self, int use_x_y, int y, int x, PyObject *str, int use_attr, long attr)

(Existing non-clinicalized code use use_xy and use_attr flags).
This will make the code a little cleaner.

----------
components: Build, Demos and Tools
messages: 208476
nosy: larry, serhiy.storchaka
priority: low
severity: normal
stage: needs patch
status: open
title: Argument Clinic: meaningful names for group flags
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Jan 19 14:29:40 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Jan 2014 13:29:40 +0000
Subject: [New-bugs-announce] [issue20303] Argument Clinic: optional groups
Message-ID: <1390138180.16.0.400473002032.issue20303@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

This is very very low priority issue. Currently Argument Clinic can't process following declaration:
/*[clinic input]
curses.window.chgat

    self: self(type="PyCursesWindowObject *")
    [
    y: int
        Y-coordinate.
    x: int
        X-coordinate.
    ]

    [
    num: int
        Number of characters.
    ]

    attr: long
        Attributes for the character.
    /

[clinic start generated code]*/

This stops three methods in the curse module to be converted to Argument Clinic.

----------
components: Build, Demos and Tools
messages: 208478
nosy: larry, serhiy.storchaka
priority: low
severity: normal
status: open
title: Argument Clinic: optional groups
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Jan 19 16:51:05 2014
From: report at bugs.python.org (Tal Einat)
Date: Sun, 19 Jan 2014 15:51:05 +0000
Subject: [New-bugs-announce] [issue20304] Argument Clinic: char convertor
	should use default	values of type bytes
Message-ID: <1390146665.62.0.375243979235.issue20304@psf.upfronthosting.co.za>


New submission from Tal Einat:

For example, in `Object/stringlib/transmogrify.h`, the methods `ljust` and `rjust` have an argument named `fillchar` of type char. It's Python default value should be b' ', but the only way I've found to do that is by setting `py_default = b' '`.

----------
components: Build, Demos and Tools
messages: 208481
nosy: larry, taleinat
priority: normal
severity: normal
status: open
title: Argument Clinic: char convertor should use default values of type bytes
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Jan 19 19:13:22 2014
From: report at bugs.python.org (Shiz)
Date: Sun, 19 Jan 2014 18:13:22 +0000
Subject: [New-bugs-announce] [issue20305] Android's incomplete locale.h
	implementation prevents	compilation
Message-ID: <1390155202.76.0.360148898057.issue20305@psf.upfronthosting.co.za>


New submission from Shiz:

As a result of Android's relatively incomplete locale.h implementation[1], some functions are not defined and some standard structs are lacking fields (e.g. decimal_point, thousand_sep).
This prevents proper cross-compilation using the Android NDK[2] from succeeding.

Attached is a patch which works around the various issues posed by Android's locale.h implementation, mainly involving falling back to default locale values, causing compilation in that department for the author to succeed.

[1]: https://groups.google.com/forum/#!topic/android-ndk/PBK4KkRpDoU
[2]: https://developer.android.com/tools/sdk/ndk/index.html

----------
components: Cross-Build
files: Python-3.4.0tip-workaround-android-locale-issues.patch
keywords: patch
messages: 208486
nosy: shiz
priority: normal
severity: normal
status: open
title: Android's incomplete locale.h implementation prevents compilation
type: compile error
versions: Python 3.4
Added file: http://bugs.python.org/file33549/Python-3.4.0tip-workaround-android-locale-issues.patch

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

From report at bugs.python.org  Sun Jan 19 19:23:41 2014
From: report at bugs.python.org (Shiz)
Date: Sun, 19 Jan 2014 18:23:41 +0000
Subject: [New-bugs-announce] [issue20306] Lack of pw_gecos field in
	Android's struct passwd causes	cross-compilation for the pwd
	module to fail
Message-ID: <1390155821.88.0.335321844624.issue20306@psf.upfronthosting.co.za>


New submission from Shiz:

As the title states, mkpwent() in pwdmodule.c accesses `pw_gecos`, which is not defined for struct passwd in Bionic, Android's C library.

Attached is a patch that works around the issue by setting the field to None on Android.

----------
components: Cross-Build
files: Python-3.4.0tip-workaround-android-missing-pw_gecos-field.patch
keywords: patch
messages: 208487
nosy: shiz
priority: normal
severity: normal
status: open
title: Lack of pw_gecos field in Android's struct passwd causes cross-compilation for the pwd module to fail
type: compile error
versions: Python 3.4
Added file: http://bugs.python.org/file33550/Python-3.4.0tip-workaround-android-missing-pw_gecos-field.patch

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

From report at bugs.python.org  Sun Jan 19 19:27:50 2014
From: report at bugs.python.org (Shiz)
Date: Sun, 19 Jan 2014 18:27:50 +0000
Subject: [New-bugs-announce] [issue20307] Android's failure to expose SYS_*
	system call constants	causes _posixsubprocess
	cross-compilation to fail
Message-ID: <1390156070.61.0.536992358716.issue20307@psf.upfronthosting.co.za>


New submission from Shiz:

Bionic, Android's C library, fails to expose the SYS_* constants used for the syscall(1) interface, which causes compilation of the _posixsubprocess module to fail as it directly attempts to call SYS_getdents64.

Attached is an experimental patch that manually defines SYS_getdents64 from Bionic's internals.

----------
components: Cross-Build
files: Python-3.4.0tip-expose-SYS_getdents64-on-android.patch
keywords: patch
messages: 208488
nosy: shiz
priority: normal
severity: normal
status: open
title: Android's failure to expose SYS_* system call constants causes _posixsubprocess cross-compilation to fail
type: compile error
versions: Python 3.4
Added file: http://bugs.python.org/file33551/Python-3.4.0tip-expose-SYS_getdents64-on-android.patch

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

From report at bugs.python.org  Sun Jan 19 22:52:39 2014
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 19 Jan 2014 21:52:39 +0000
Subject: [New-bugs-announce] [issue20308] inspect.Signature doesn't support
	user classes without	__init__ or __new__
Message-ID: <1390168359.82.0.306015564457.issue20308@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Boy was I surprised by this:

>>> class C: pass
... 
>>> import inspect
>>> inspect.signature(C)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/larry/src/python/clinic_c_types_hacking/Lib/inspect.py", line 1557, in signature
    raise ValueError('callable {!r} is not supported by signature'.format(obj))
ValueError: callable <class '__main__.C'> is not supported by signature

Why not?  C is a callable object.  If you can't find a __new__ or an __init__ in the class, its signature should be pretty predictable.

(It returns a signature if you add either a __new__, an __init__, or both.)

----------
components: Library (Lib)
messages: 208502
nosy: brett.cannon, larry, ncoghlan, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: inspect.Signature doesn't support user classes without __init__ or __new__
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Jan 20 07:43:38 2014
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 20 Jan 2014 06:43:38 +0000
Subject: [New-bugs-announce] [issue20309] Class method descriptors are
	different between builtin	and user classes
Message-ID: <1390200218.06.0.45732778516.issue20309@psf.upfronthosting.co.za>


New submission from Larry Hastings:

I found something curious while experimenting with types tonight.

Everybody knows, if you access a descriptor in a class through the normal attribute-getting methods, you actually get the result of calling its '__get__' method.  If you want to get your hands on the descriptor itself, you can be sneaky and pull it out through the class's __dict__.

I did an experiment tonight, accessing a bunch of methods in a bunch of different ways.

The methods I tried were
  * an instance method,
  * a class method, and
  * a static method.

I accessed them
  * as an instance attribute,
  * as a class attribute, and
  * through the class __dict__.

And for each of the above, I tried
  * one user method and
  * one built-in method.

That's a total of eighteen methods tried (3x3x2).

For each one, I printed out whether or not it was callable.  I found the results startling: fifteen were, but three (!) were not.

All three that weren't were accessed through the class dict.  They were:
  * Class method, from builtin class ( dict.__dict__['fromkeys'] )
  * Static method, from user class
  * Static method, from builtin class ( str.__dict__['maketrans'] )

I find it strange that the static method descriptors aren't callable.
I find it *even stranger* that *one* of the class method descriptors isn't callable, but the other one is.

I guess a foolish consistency is the hobgoblin of my small mind, but... shouldn't all eighteen of these objects be callable?

Attached is the test harness I wrote.

(p.s. I attached you guys as nosy because I thought you might be interested.)

----------
components: Interpreter Core
files: curious.py
messages: 208524
nosy: arigo, larry, ncoghlan, pitrou
priority: low
severity: normal
stage: needs patch
status: open
title: Class method descriptors are different between builtin and user classes
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33559/curious.py

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

From report at bugs.python.org  Mon Jan 20 08:19:58 2014
From: report at bugs.python.org (Charles-Axel Dein)
Date: Mon, 20 Jan 2014 07:19:58 +0000
Subject: [New-bugs-announce] [issue20310] Recommend using pprint for
	deterministic doctest
Message-ID: <1390202398.87.0.516795026978.issue20310@psf.upfronthosting.co.za>


New submission from Charles-Axel Dein:

I just thought that using pprint.pprint was an elegant solution to the non-deterministic order of repr(dict) in doctest. See for instance http://bugs.python.org/issue3332

Contrary to sorted(foo().items()):

- It provides a nice output that is exactly like a dict.
- It supports any number of nested dicts.
- It can be used in other cases as well to make doctests elegant.

----------
assignee: docs at python
components: Documentation
files: pprint_doctest.patch
keywords: patch
messages: 208526
nosy: charlax, docs at python
priority: normal
severity: normal
status: open
title: Recommend using pprint for deterministic doctest
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33560/pprint_doctest.patch

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

From report at bugs.python.org  Mon Jan 20 11:33:28 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jan 2014 10:33:28 +0000
Subject: [New-bugs-announce] [issue20311] epoll.poll(timeout) must round the
	timeout to the upper	bound
Message-ID: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Hi, while comparing performances of Tulip and Trollius projects (asyncio module), I found a bug. The event loop is called too many times when a callback is scheduled with a timeout and the epoll selector is used, especially for timeout close to one millisecond.

In my opinion, it's a bug in epoll.poll(): it should wait *at least* timeout seconds if no event is received, not shorter.

Pseudo-code of Tulip:
---
timeout = scheduled[0].when - time.monotonic()
events = selector.select(timeout)
process_events(events)
while scheduled:
   if scheduled[0].when > time.monotonic():
      break
   ...
---

The problem is that "scheduled[0].when > time.monotonic()" test fails because epoll.poll() returns in less than timeout seconds.

The difference between the timeout and elapsed time is very small, less than 1 millisecond.

Attached patch fixes this issue by rounding the timeout to the upper bound.

The rounding is different than datetime.timedelta constructor for example, because the usecase is different. epoll.poll(0.0001) calls epoll_wait() with a timemout of 1 millisecond (1e-4 rounded to 1e-3).

epoll.poll(0.0) still calls epoll_wait() with a timeout of 0 millisecond. I don't think that it's possible to write a reliable unit test for that on our slow buildbots.

----------
files: epoll_timeout.patch
keywords: patch
messages: 208532
nosy: gvanrossum, haypo, neologix, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: epoll.poll(timeout) must round the timeout to the upper bound
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33563/epoll_timeout.patch

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

From report at bugs.python.org  Mon Jan 20 16:51:41 2014
From: report at bugs.python.org (Marco Buttu)
Date: Mon, 20 Jan 2014 15:51:41 +0000
Subject: [New-bugs-announce] [issue20312] A missing link to
	Python-3.4.0b2.tar.bz2 in the download	page.
Message-ID: <1390233101.81.0.508449799289.issue20312@psf.upfronthosting.co.za>


New submission from Marco Buttu:

At the page:

http://www.python.org/getit/releases/3.4.0/

the link:

http://www.python.org/ftp/python/3.4.0/Python-3.4.0b2.tar.bz2

does not work.

----------
assignee: docs at python
components: Documentation
messages: 208545
nosy: docs at python, marco.buttu
priority: normal
severity: normal
status: open
title: A missing link to Python-3.4.0b2.tar.bz2 in the download page.
versions: Python 3.4

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

From report at bugs.python.org  Mon Jan 20 17:56:33 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 20 Jan 2014 16:56:33 +0000
Subject: [New-bugs-announce] [issue20313] inspect.signature should raise
	ValueError for builtins	with no signature info
Message-ID: <1390236993.79.0.241444273763.issue20313@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

'inspect.signature' currently returns 'None' for builtins with no signature information. However, the protocol is that it raises a "ValueError(callable is not supported by signature)" if object is callable, but a signature can not be provided.

Attached patch fixes this, as well as updates the relevant section in the inspect.signature documentation.

----------
components: Library (Lib)
files: sig_builtin_01.patch
keywords: patch
messages: 208548
nosy: brett.cannon, larry, ncoghlan, yselivanov
priority: normal
severity: normal
status: open
title: inspect.signature should raise ValueError for builtins with no signature info
versions: Python 3.4
Added file: http://bugs.python.org/file33566/sig_builtin_01.patch

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

From report at bugs.python.org  Mon Jan 20 18:10:53 2014
From: report at bugs.python.org (Gerrit Holl)
Date: Mon, 20 Jan 2014 17:10:53 +0000
Subject: [New-bugs-announce] [issue20314] Potentially confusing formulation
	in 6.1.4. Template	strings
Message-ID: <1390237853.97.0.751678212058.issue20314@psf.upfronthosting.co.za>


New submission from Gerrit Holl:

The standard library documentation ?6.1. string ? Common string operations? describes string formatting through the `.format` method and the corresponding mini-language, and the `Template` class.  In the part describing the `Template` class (6.1.4) is the text:

> Instead of the normal %-based substitutions, Templates support $-based substitutions, using the following rules:

This is potentially confusing.  The documentation in this section has not made any mention of %-based substitutions.  Rather, a novel reader may, at this point, think that {}-based substitution is normal.  I would suggest to resolve this issue by simply not mentioning %-based substitutions, replacing the sentence above by:

> Templates support $-based substitutions, using the following rules:

----------
assignee: docs at python
components: Documentation
messages: 208553
nosy: Gerrit.Holl, docs at python
priority: normal
severity: normal
status: open
title: Potentially confusing formulation in 6.1.4. Template strings
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Mon Jan 20 20:01:13 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Jan 2014 19:01:13 +0000
Subject: [New-bugs-announce] [issue20315] Remove old compatibility code
Message-ID: <1390244473.81.0.0418963805033.issue20315@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch removes the code which supports compatibility with old Python 2.x versions. As far as these files are never used with Python 2.x (and the compatibility was broken by other differences between 2.x and 3.x), this code can be removed from 3.x.

----------
files: py2_compat.patch
keywords: patch
messages: 208559
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Remove old compatibility code
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33568/py2_compat.patch

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

From report at bugs.python.org  Mon Jan 20 20:13:21 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 20 Jan 2014 19:13:21 +0000
Subject: [New-bugs-announce] [issue20316] Byte-compiled files should be
	absent in tarballs
Message-ID: <1390245201.82.0.892939520121.issue20316@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

Tarballs of 3.3.2 (and all previous versions tested by me) do not contain any *.py[co] files.
Tarballs of 3.3.3 contain 1 .pyc file, which is even generated for wrong Python version:

$ find -name "*.py[co]"
./Tools/hg/hgtouch.pyc
$ file Tools/hg/hgtouch.pyc
Tools/hg/hgtouch.pyc: python 2.7 byte-compiled

Please ensure that this problem will not occur with future tarballs.

----------
messages: 208562
nosy: Arfrever, georg.brandl
priority: normal
severity: normal
status: open
title: Byte-compiled files should be absent in tarballs
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Jan 20 21:08:09 2014
From: report at bugs.python.org (jcflack)
Date: Mon, 20 Jan 2014 20:08:09 +0000
Subject: [New-bugs-announce] [issue20317] ExitStack hang if enough nested
	exceptions
Message-ID: <1390248489.02.0.0980821300277.issue20317@psf.upfronthosting.co.za>


New submission from jcflack:

Python 3.3.2 (default, Dec  4 2013, 20:19:27) 
[GCC 4.7.3] on linux (gentoo)

Suppose we create a context manager that will fail during exit because of a simple coding error:

@contextmanager
def f():
 try:
  yield 6
 finally:
  throdbog() # woops, forgot to define this

Now let's stack up a few of these:

with ExitStack() as stack:
 i = stack.enter_context(f())
 i = stack.enter_context(f())
 i = stack.enter_context(f())
 print(i)

... prints 6, then hangs, won't respond to ^C, can be killed.

Three levels on the stack seems to be the magic number. With one or two it works as expected ("During handling of the above exception, another exception occurred", etc.).

Is the ExitStack code somehow creating a circularly-linked exception structure when there are three levels?

----------
components: Library (Lib)
messages: 208574
nosy: jcflack
priority: normal
severity: normal
status: open
title: ExitStack hang if enough nested exceptions
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Mon Jan 20 21:30:19 2014
From: report at bugs.python.org (Andrew Lutomirski)
Date: Mon, 20 Jan 2014 20:30:19 +0000
Subject: [New-bugs-announce] [issue20318] subprocess.Popen can hang in
	threaded applications
Message-ID: <1390249819.03.0.991344131396.issue20318@psf.upfronthosting.co.za>


New submission from Andrew Lutomirski:

Running python python_thread_bug.py -j4 often results in one of the threads failing to start until another thread finishes.

The bug appears to be that subprocess's pipe_cloexec function is racy: if another thread forks between os.pipe() and _set_cloexec_flag, then the resulting process could hang on to the write end of the pipe.  That will cause the Popen call that got rudely interrupted to wait until the whole resulting process tree dies.

----------
components: Library (Lib)
files: python_thread_bug.py
messages: 208577
nosy: Andrew.Lutomirski
priority: normal
severity: normal
status: open
title: subprocess.Popen can hang in threaded applications
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file33571/python_thread_bug.py

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

From report at bugs.python.org  Tue Jan 21 01:18:39 2014
From: report at bugs.python.org (Glenn Langford)
Date: Tue, 21 Jan 2014 00:18:39 +0000
Subject: [New-bugs-announce] [issue20319] concurrent.futures.wait() can
	block forever even if	Futures have completed
Message-ID: <1390263519.32.0.357208079457.issue20319@psf.upfronthosting.co.za>


New submission from Glenn Langford:

concurrent.futures.wait() can get into a state where it blocks forever on waiter.event.wait(), even when the underlying Futures have completed.

This is demonstrated in a stress test where a large number of wait() calls are run in multiple threads, contending for the same Futures.

The cause is believed to be waiter removal, which is done without locking the Future. 

A suggested fix which appears to work is to change the following code in wait():

for f in fs:
    f._waiters.remove(waiter)

to:

for f in fs:
    with f._condition:
        f._waiters.remove(waiter)

----------
components: Library (Lib)
files: stress_wait.py
messages: 208592
nosy: glangford
priority: normal
severity: normal
status: open
title: concurrent.futures.wait() can block forever even if Futures have completed
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33580/stress_wait.py

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

From report at bugs.python.org  Tue Jan 21 01:34:16 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2014 00:34:16 +0000
Subject: [New-bugs-announce] [issue20320] select.select(timeout)
	and	select.kqueue.control(timeout) must round the timeout to
	the	upper bound
Message-ID: <1390264456.23.0.80941463403.issue20320@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Rounding issue causes performance bug in asyncio, see issue #20311 for the rationale. This issue address bugs for select and kqueue because their implementation is different.

OS multiplexer:

- select: microsecond resolution (10^-6), timeout converted by _PyTime_ObjectToTimeval() which converts 1e-7 to zero => BUG!
- kqueue: nanosecond resolution (10^-9), timeout converted by _PyTime_ObjectToTimespec() which converts 1e-10 to zero => BUG!

_PyTime_ObjectToTimeval() is used in various places:

- datetime.datetime.fromtimestamp(), datetime.datetime.utcfromtimestamp()
- select.select(), 

_PyTime_ObjectToTimespec() is used in various places:

- posix.utime()
- signal.sigtimedwait()
- select.kqueue.control()
- time.clock_settime()

Attached patch adds a new round parameter to _PyTime_ObjectToTimeval() and _PyTime_ObjectToTimespec() to choose the rounding method:

* _PyTime_ROUND_DOWN: Round towards zero. (current implementation)
* _PyTime_ROUND_UP: Round away from zero. (new rounding method)

The patch changes the rounding method for select, kqueue but also for sigtimedwait().

----------
files: time_rouding.patch
keywords: patch
messages: 208594
nosy: belopolsky, haypo, neologix, pitrou, serhiy.storchaka, skrah
priority: normal
severity: normal
status: open
title: select.select(timeout) and select.kqueue.control(timeout) must round the timeout to the upper bound
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33581/time_rouding.patch

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

From report at bugs.python.org  Tue Jan 21 05:03:08 2014
From: report at bugs.python.org (berdario)
Date: Tue, 21 Jan 2014 04:03:08 +0000
Subject: [New-bugs-announce] [issue20321] ImportError when a module is
	created after a catched	ImportError
Message-ID: <1390276988.86.0.176640087742.issue20321@psf.upfronthosting.co.za>


New submission from berdario:

This small script errors on both Python2.7, Python3.3 and Pypy2.0

(I just reduced the test case supplied to me by ezio)

----------
components: Interpreter Core
files: bbug.py
messages: 208608
nosy: berdario, ezio.melotti
priority: normal
severity: normal
status: open
title: ImportError when a module is created after a catched ImportError
versions: 3rd party, Python 2.7, Python 3.3
Added file: http://bugs.python.org/file33582/bbug.py

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

From report at bugs.python.org  Tue Jan 21 05:23:01 2014
From: report at bugs.python.org (Donald Stufft)
Date: Tue, 21 Jan 2014 04:23:01 +0000
Subject: [New-bugs-announce] [issue20322] Upgrade ensurepip's pip and
	setuptools
Message-ID: <1390278181.02.0.46118340261.issue20322@psf.upfronthosting.co.za>


New submission from Donald Stufft:

Pip 1.5.1 and setuptools 2.1 are out which both fix some bugs that are likely to affect some people. They both should be fairly innocuous as far as issues go so there shouldn't be any harm in upgrading in 3.4.

----------
assignee: dstufft
messages: 208610
nosy: dstufft, larry
priority: release blocker
severity: normal
status: open
title: Upgrade ensurepip's pip and setuptools
versions: Python 3.4

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

From report at bugs.python.org  Tue Jan 21 07:05:43 2014
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 21 Jan 2014 06:05:43 +0000
Subject: [New-bugs-announce] [issue20323] Argument Clinic:
	docstring_prototype output causes build	failure on Windows
Message-ID: <1390284343.93.0.69163024688.issue20323@psf.upfronthosting.co.za>


New submission from Zachary Ware:

The current two-pass output for the two-pass preset causes compile errors on Windows.  A sample:

..\PC\winsound.c(71): error C2133: 'winsound_PlaySound__doc__' : unknown size

Line 71 (clinic-generated docstring_prototype):

PyDoc_VAR(winsound_PlaySound__doc__);

Here's a bit more info on the error: http://msdn.microsoft.com/en-us/library/c13wk277%28v=vs.100%29.aspx

There are a few viable alternatives that I can see.

1) Give PyDoc_VAR a reasonable default size.  I don't like this; it seems fragile.

2) Remove docstring_prototype as an outputtable entity.  I don't like this much either, it should be a reasonable thing to do.

3) Add a new PyDoc_SIZEDVAR macro, taking name and size.  Argument Clinic will know the needed size and can fill it in, but it would be largely useless for manual usage.  I think this is my preferred route.

4) Instead of reusing PyDoc_VAR (or a new PyDoc_SIZEDVAR), just have Clinic output the whole expanded macro, with size; e.g. "static char winsound_PlaySound__doc__[195]".  This does have the downside that any future change to docstrings that would have been a simple change to the macro would have to be done in Argument Clinic, with lots of churn in every clinicized file.

Here's a patch that implements option 3.

----------
files: pydoc_sizedvar.diff
keywords: patch
messages: 208616
nosy: larry, zach.ware
priority: normal
severity: normal
status: open
title: Argument Clinic: docstring_prototype output causes build failure on Windows
type: compile error
Added file: http://bugs.python.org/file33585/pydoc_sizedvar.diff

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

From report at bugs.python.org  Tue Jan 21 09:21:24 2014
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Tue, 21 Jan 2014 08:21:24 +0000
Subject: [New-bugs-announce] [issue20324] gcc-4.3 support on python-3.3
	(libmpdec)
Message-ID: <1390292484.35.0.247229309669.issue20324@psf.upfronthosting.co.za>


New submission from Dirkjan Ochtman:

See https://bugs.gentoo.org/show_bug.cgi?id=498640:

What compiler versions are supported for 3.3? We noticed an issue when compiling 3.3.3 with gcc 4.3:

/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../x86_64-pc-linux-gnu/bin/ld: build/temp.linux-x86_64-3.3/var/tmp/portage/dev-lang/python-3.3.3/work/Python-3.3.3/Modules/_decimal/libmpdec/mpdecimal.o: warning: relocation against `mprime_rdx' in readonly section `.text'.
/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../x86_64-pc-linux-gnu/bin/ld: build/temp.linux-x86_64-3.3/var/tmp/portage/dev-lang/python-3.3.3/work/Python-3.3.3/Modules/_decimal/libmpdec/basearith.o: relocation R_X86_64_PC32 against symbol `mprime_rdx' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value

Ruud Koolen <redlizard at gentoo.org> came up with a patch:

diff -r f7cebf727bc6 Modules/_decimal/libmpdec/constants.c
--- a/Modules/_decimal/libmpdec/constants.c	Mon Jan 20 21:59:33 2014 +0200
+++ b/Modules/_decimal/libmpdec/constants.c	Mon Jan 20 22:12:50 2014 +0100
@@ -71,6 +71,9 @@
   };
 
   /* magic number for constant division by MPD_RADIX */
+#if defined(__GNUC__) && (__GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 3))
+ __attribute__((visibility("hidden")))
+#endif
   const mpd_uint_t mprime_rdx = 15581492618384294730ULL;
 
 #elif defined(CONFIG_32)

----------
components: Library (Lib)
keywords: 3.3regression
messages: 208630
nosy: djc, skrah
priority: normal
severity: normal
status: open
title: gcc-4.3 support on python-3.3 (libmpdec)
versions: Python 3.3

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

From report at bugs.python.org  Tue Jan 21 11:01:26 2014
From: report at bugs.python.org (Tal Einat)
Date: Tue, 21 Jan 2014 10:01:26 +0000
Subject: [New-bugs-announce] [issue20325] Argument Clinic: self converters
	are not preserved when	clonig functions
Message-ID: <1390298486.22.0.452185457734.issue20325@psf.upfronthosting.co.za>


New submission from Tal Einat:

In Objects/bytes.c, the strip methods need a "self converter" so that
they get a PyBytesObject* instead of PyObject*. However, having set
this in bytes.strip and "cloning" that clinic definition for
bytes.lstrip and bytes.rstrip, it appears that the self converter
wasn't set on lstrip and rstrip. Removing the cloning and copying the
argument definitions resolved the issue.

Is this a bug?

----------
components: Build, Demos and Tools
messages: 208633
nosy: larry, taleinat
priority: normal
severity: normal
status: open
title: Argument Clinic: self converters are not preserved when clonig functions
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Jan 21 11:05:49 2014
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 21 Jan 2014 10:05:49 +0000
Subject: [New-bugs-announce] [issue20326] Argument Clinic should use a
	non-error-prone syntax to	mark text signatures
Message-ID: <1390298749.1.0.12762219489.issue20326@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Sorry this is so long--but I wanted to make my point.  Here's the tl;dr summary.

The problem: The syntax used for Argument-Clinic-generated text
signatures for builtins means CPython mistakenly identifies
hand-written, unparsable pseudo-signatures as legitimate
signatures.  This causes real, non-hypothetical problems.

I think we should change the syntax to something people would
never write by accident.  Here are some suggestions:

"*("
"*clinic*("
"\01 clinic("

--

A quick recap on how signature information for builtins works.

The builtin's docstring contains the signature, encoded as text using
a special syntax on the first line.  CPython callables always have
getters for their __doc__ member; the doc getter function examines
the first line, and if it detects a signature it skips past it and
returns the rest.  CPython's new getter on callables __text_signature__
also look at the internal docstring.  If it detects a signature it
returns it, otherwise it returns None.

inspect.signature then retrieves __text_signature__, and if ast.parse()
parses it, it populates the appropriate Signature and returns that.
And then pydoc uses the Signature object to print the first line of
help().


In #19674 there was some discussion on what this syntax should be.
Guido suggested they look like this:

   functionname(args, etc)\n    

He felt it was a good choice, and pointed out that Sphinx autodoc
uses this syntax.  (Not because using this syntax would help
Sphinx--it won't.  Just as a "here's how someone else solved
the problem" data point.)


__doc__ and __text_signature_ aren't very smart about detecting
signatures.  Here's their test in pseudo-code:
    if the first N bytes match the name of the function,
    and the N+1th byte is a left parenthesis,
    then it's assumed to be a valid signature.

--

First, consider: this signature syntax is the convention docstrings
already use.  Nearly every builtin callable in Python has a hand-written
docstring that starts with "functionname(".

Great!, you might think, we get signatures for free, even on functions
that haven't been converted to Argument Clinic!

The problem is, many of these pseudo-signatures aren't proper Python.
Consider the first line of the docstring for os.lstat():

"lstat(path, *, dir_fd=None) -> stat result\n"

This line passes the "is it a text signature test?", so __doc__
skips past it and __text_signature__ returns it.  But it isn't
valid actually valid.  ast.parse() rejects it, so inspect.signature
returns nothing.  pydoc doesn't get a valid signature, so it prints
"lstat(...)", and the user is deprived of the helpful line
handwritten by lstat's author.

That's bad enough.  Now consider the first *two* lines of the
docstring for builtin open():

"open(file, mode='r', buffering=-1, encoding=None,\n"
"     errors=None, newline=None, closefd=True, opener=None) -> file object\n"

__doc__ clips the first line but retains the second.  pydoc prints
"open(...)", followed by the second line!  Now we have the problem
reported in #20075: "help(open) eats first line".


Both of these problems go away if I add one more check to the
signature-detecting code: does the line end with ')'?  But that's
only a band-aid on the problem.  Consider socket.accept's
docstring:

"_accept() -> (integer, address info)\n"

Okay, so __doc__ and __text_signature__ could count parentheses
and require them to balance.  But then they'd have to handle strings
that contain parentheses, which means they'd also have to understand
string quoting.

And there would *still* be handwritten docstrings that would pass
that test but wouldn't parse properly.  Consider bisect.insort_right:

"insort_right(a, x[, lo[, hi]])\n"

We could only be *certain* if we gave up on having two parsers.
Write the signature-recognizer code only once, in C, then call that
in __doc__ and __text_signature__ and inspect.signature().  But that
seems unreasonable.

Okay, so we could attack the problem from the other end.  Clean
up all the docstrings in CPython, either by converting to Argument
Clinic or just fixing them by hand.  But that means that
*third-party modules* will still have the mysterious problem.

Therefore I strongly suggest we switch to a syntax that nobody will
ever use by accident.

Have I convinced you?

----------
assignee: larry
messages: 208634
nosy: barry, brett.cannon, gennad, gvanrossum, larry, ncoghlan, skrah, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Argument Clinic should use a non-error-prone syntax to mark text signatures
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Jan 21 12:28:14 2014
From: report at bugs.python.org (Tal Einat)
Date: Tue, 21 Jan 2014 11:28:14 +0000
Subject: [New-bugs-announce] [issue20327] Argument Clinic: setting internal
	variable names for	parsed arguments
Message-ID: <1390303694.96.0.387244097814.issue20327@psf.upfronthosting.co.za>


New submission from Tal Einat:

It would be useful for conversion of existing function to be able to set the name of the C variable for arguments which is different than the Python argument name.

For example, not being able to do so makes converting bytes.translate much harder. In the existing code, the first argument is called 'table' in the docs but 'tableobj' in the code. Furthermore, a different variable named 'table' is used rather extensively in the function. If clinic could be told to name the C variable 'tableobj', then that would be that. Otherwise renaming two variables in the code is unaviodable.

----------
components: Build, Demos and Tools
messages: 208641
nosy: taleinat
priority: normal
severity: normal
status: open
title: Argument Clinic: setting internal variable names for parsed arguments
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Jan 21 12:40:58 2014
From: report at bugs.python.org (Jonathan Dowland)
Date: Tue, 21 Jan 2014 11:40:58 +0000
Subject: [New-bugs-announce] [issue20328] mailbox:
Message-ID: <1390304458.71.0.378928457479.issue20328@psf.upfronthosting.co.za>


New submission from Jonathan Dowland:

It would be great if the 'mailbox' library supported a 'remove' or 'delete' operation for the mailbox itself as part of its abstract interface. It does support removing messages, and the sub-classes for Maildir, MH etc. support removing sub-folders (their interface is common but they don't inherit a common interface); but removing the actual parent mailbox itself is not yet supported.

----------
components: Library (Lib)
messages: 208642
nosy: jmtd
priority: normal
severity: normal
status: open
title: mailbox:
versions: Python 2.7

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

From report at bugs.python.org  Tue Jan 21 16:05:53 2014
From: report at bugs.python.org (Laurent Mazuel)
Date: Tue, 21 Jan 2014 15:05:53 +0000
Subject: [New-bugs-announce] [issue20329] zipfile.extractall fails in Posix
	shell with utf-8	filename
Message-ID: <1390316753.93.0.767122614569.issue20329@psf.upfronthosting.co.za>


New submission from Laurent Mazuel:

Hello,

Considering a zip file which contains utf-8 filenames (as uploaded zip file), the following code fails if launched in a Posix shell.

>>> with zipfile.ZipFile("test_ut8.zip") as fd:
...     fd.extractall()
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "/opt/python/3.3/lib/python3.3/zipfile.py", line 1225, in extractall
    self.extract(zipinfo, path, pwd)
  File "/opt/python/3.3/lib/python3.3/zipfile.py", line 1213, in extract
    return self._extract_member(member, path, pwd)
  File "/opt/python/3.3/lib/python3.3/zipfile.py", line 1276, in _extract_member
    open(targetpath, "wb") as target:
UnicodeEncodeError: 'ascii' codec can't encode characters in position 10-14: ordinal not in range(128)

With shell:
$ locale
LANG=POSIX
...

But filesystem is not encoding dependant. On a Unix system, filename are only bytes, there is no reason to refuse to unzip a zip file (in fact, "unzip" command line don't fail to unzip the file in a Posix shell).

Since "open" can take "bytes" filename, changing the line 1276 from
> open(targetpath)
to:
> open(targetpath.encode("utf-8"))

fixes the problem.

zipfile should not care about the encoding of the filename and should use the bytes sequence filename extracted directly from the bytes sequence of the zipfile. Having "ZipInfo.filename" as a string (and not bytes) is great for an API, but is not needed to open/write a file on the disk. Then, ZipInfo should store the direct bytes sequences of filename as a "bytes_filename" field and use it in the "open" of "extract".

In addition, considering the patch of bug 10614, the right patch could use the new "ZipInfo.encoding" field:
> open(targetpath.encode(member.encoding))

----------
components: Extension Modules
files: test_ut8.zip
messages: 208648
nosy: Laurent.Mazuel
priority: normal
severity: normal
status: open
title: zipfile.extractall fails in Posix shell with utf-8 filename
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file33589/test_ut8.zip

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

From report at bugs.python.org  Tue Jan 21 16:08:12 2014
From: report at bugs.python.org (Masami HIRATA)
Date: Tue, 21 Jan 2014 15:08:12 +0000
Subject: [New-bugs-announce] [issue20330] PEP 342 is outdated
Message-ID: <1390316892.04.0.132074086139.issue20330@psf.upfronthosting.co.za>


New submission from Masami HIRATA:

Although PEP 342 says foo(yield 42) is legal, Lib/test/test_grammar.py says:
>        # Requires parentheses as call argument
>        def g(): f((yield 1))
>        check_syntax_error(self, "def g(): f(yield 1)")

BTW, It seems that foo(yield 42) written in ECMAScript 6 is OK.

----------
assignee: docs at python
components: Documentation
messages: 208650
nosy: docs at python, msmhrt
priority: normal
severity: normal
status: open
title: PEP 342 is outdated
versions: Python 3.3

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

From report at bugs.python.org  Tue Jan 21 17:17:54 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jan 2014 16:17:54 +0000
Subject: [New-bugs-announce] [issue20331] Fix various fd leaks
Message-ID: <1390321074.97.0.506126100474.issue20331@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch fixes potential fd leaks in various modules.

----------
components: Library (Lib)
files: fd_leaks.patch
keywords: patch
messages: 208664
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix various fd leaks
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33593/fd_leaks.patch

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

From report at bugs.python.org  Tue Jan 21 17:32:04 2014
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 21 Jan 2014 16:32:04 +0000
Subject: [New-bugs-announce] [issue20332] Argument Clinic does not support
	the 'l' format
Message-ID: <1390321924.51.0.108900260665.issue20332@psf.upfronthosting.co.za>


New submission from Brett Cannon:

'l' is long for PyArg_ParseTuple().

----------
assignee: larry
components: Build
messages: 208667
nosy: brett.cannon, larry
priority: normal
severity: normal
status: open
title: Argument Clinic does not support the 'l' format
versions: Python 3.4

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

From report at bugs.python.org  Tue Jan 21 17:46:08 2014
From: report at bugs.python.org (Martin d'Anjou)
Date: Tue, 21 Jan 2014 16:46:08 +0000
Subject: [New-bugs-announce] [issue20333] argparse subparser usage message
	hides main parser usage
Message-ID: <1390322768.82.0.0490461606421.issue20333@psf.upfronthosting.co.za>


New submission from Martin d'Anjou:

Consider the following code:

#!/usr/bin/env python3
import argparse

# create the top-level parser
parser = argparse.ArgumentParser(prog='PROG')
parser.add_argument('--file', help='A filename', required=True)
subparsers = parser.add_subparsers(help='sub-command help')

# create the parser for the "a" command
parser_a = subparsers.add_parser('a', help='a help')
parser_a.add_argument('bar', type=int, help='bar help')

# create the parser for the "b" command
parser_b = subparsers.add_parser('b', help='b help')
parser_b.add_argument('--baz', choices='XYZ', help='baz help')

The help for subparser a is obtained with: parser.parse_args(["a","--help"])

usage: PROG a [-h] bar

positional arguments:
  bar         bar help

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

When the user follows the help, the user gets it wrong:
parser.parse_args(["a","10"])

usage: PROG [-h] --file FILE {a,b} ...
PROG: error: argument --file is required

The correct way to use the subparser is:
parser.parse_args(["--file","file","a","10"])

But the problem is that the original help message is not telling the user that this is the correct way. When asking for the "a" subparser help, the usage message should also reveal the main parser arguments. Continuing with the example, something like this should be appropriate:

usage: PROG [-h] --file FILE a [-h] bar

This is how the argparse Java port works.

----------
components: Library (Lib)
messages: 208670
nosy: Martin.d'Anjou
priority: normal
severity: normal
status: open
title: argparse subparser usage message hides main parser usage
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Tue Jan 21 17:50:24 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 21 Jan 2014 16:50:24 +0000
Subject: [New-bugs-announce] [issue20334] make inspect Signature hashable
Message-ID: <1390323024.99.0.45103178025.issue20334@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

inspect.Signature and inspect.Parameter are immutable structures, and it makes sense to make them hashable too.

Patch is attached.

----------
components: Library (Lib)
files: hashable_signature_01.patch
keywords: patch
messages: 208671
nosy: brett.cannon, larry, ncoghlan, yselivanov
priority: normal
severity: normal
status: open
title: make inspect Signature hashable
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33595/hashable_signature_01.patch

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

From report at bugs.python.org  Tue Jan 21 22:45:37 2014
From: report at bugs.python.org (Renaud Blanch)
Date: Tue, 21 Jan 2014 21:45:37 +0000
Subject: [New-bugs-announce] [issue20335] bytes constructor accepts more
	than one argument even of	the first one is not a string
Message-ID: <1390340737.95.0.677221459573.issue20335@psf.upfronthosting.co.za>


New submission from Renaud Blanch:

% 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.
>>> help(bytes)
bytes constructor accepts more than one argument even of the first one is not a string (and then the other arguments are checked to be strings):

    >>> bytes(2, "foo", "bar")
    b'\x00\x00'
    >>> bytes(2, "foo")
    b'\x00\x00'

but:

    >>> bytes(2, 1)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: bytes() argument 2 must be str, not int

----------
components: Interpreter Core
messages: 208707
nosy: rndblnch
priority: normal
severity: normal
status: open
title: bytes constructor accepts more than one argument even of the first one is not a string
versions: Python 3.3

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

From report at bugs.python.org  Tue Jan 21 23:29:51 2014
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 21 Jan 2014 22:29:51 +0000
Subject: [New-bugs-announce] [issue20336] test_asyncio: relax timings even
	more
Message-ID: <1390343391.65.0.626852689754.issue20336@psf.upfronthosting.co.za>


New submission from Stefan Krah:

It seems that the relaxed timings in some tests are still not
sufficient:

http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/7417/steps/test/logs/stdio

======================================================================
FAIL: test_time_and_call_at (test.test_asyncio.test_base_events.BaseEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_asyncio/test_base_events.py", line 127, in test_time_and_call_at
    self.assertTrue(0.09 <= t1-t0 <= 0.9, t1-t0)
AssertionError: False is not true : 2.06036564335227

----------
components: Tests
keywords: buildbot
messages: 208714
nosy: gvanrossum, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: test_asyncio: relax timings even more
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Jan 21 23:36:52 2014
From: report at bugs.python.org (KV)
Date: Tue, 21 Jan 2014 22:36:52 +0000
Subject: [New-bugs-announce] [issue20337] bdist_rpm should support
	%config(noreplace)
Message-ID: <1390343812.97.0.521102464448.issue20337@psf.upfronthosting.co.za>


New submission from KV:

bdist_rpm should support handling %config(noreplace) to help with packaging.

Patch attached.

----------
components: Build
files: bdist_rpm-add-config-file.diff
keywords: patch
messages: 208715
nosy: kv
priority: normal
severity: normal
status: open
title: bdist_rpm should support %config(noreplace)
versions: Python 2.7
Added file: http://bugs.python.org/file33602/bdist_rpm-add-config-file.diff

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

From report at bugs.python.org  Tue Jan 21 23:41:42 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 21 Jan 2014 22:41:42 +0000
Subject: [New-bugs-announce] [issue20338] Idle: increase max calltip width
Message-ID: <1390344102.42.0.241411598779.issue20338@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Idle calltips are currently limited to 75 (signature) or 70 (doc line) chars. This is insufficient for some stdlib signatures. Example:

>>> from http.client import HTTPConnection
>>> import inspect
>>> fob=HTTPConnection.__init__
>>> line=inspect.formatargspec(*inspect.getfullargspec(fob))
>>> line, len(line)
('(self, host, port=None, strict=<object object at 0x03125148>, timeout=<object object at 0x01FF7408>, source_address=None)', 121)

The truncated tip displayed is "(self, host, port=None, strict=<object object at 0x03125148>, timeout=<object obj ..."

Given that Idle is a graphics application, not a 80-char text console application, there is no obvious reason for the particular restriction other that esthetics. The tip is in a popup window that is separate from the shell or editor window where '(' was typed. On my widescreen monitor, there is room for, say, 200 chars. If I move the underlying window to the far right, so there is not enough room for even the truncated "HTTPConnection(" tip, Windows just truncates it further, as with any other window.

Serhiy, if you have a *nix machine, can you verify that there is no problem with that either?

The limits appear in multiple places in CallTipWindow.showtip and CallTips.get_argspec. Since get_argspec truncates a docstring line to less that showtip allows, there is no ' ...' added and showtip only affects inspect signatures. Get_argspec could leave length enforcement, whatever we decide it should be, to showtip.

I think the first thing to do is replace the multiple hard-coded numbers with one named constant.

----------
assignee: terry.reedy
messages: 208716
nosy: serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Idle: increase max calltip width
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Jan 22 01:40:29 2014
From: report at bugs.python.org (Neil Schemenauer)
Date: Wed, 22 Jan 2014 00:40:29 +0000
Subject: [New-bugs-announce] [issue20339] Make bytes() use tp_as_buffer for
	cmp
Message-ID: <1390351229.22.0.995411790956.issue20339@psf.upfronthosting.co.za>


New submission from Neil Schemenauer:

While poking around at bytes() related things, I noticed that the               
tp_richcompare method for bytes does not use the tp_as_buffer                   
interface.  Making it use it is quite easy, probably even makes the             
code simpler and faster.                                                        
                                                                                
However, using it would mean that you could compare by bytes() and              
bytearray() to any object that implemented tp_as_buffer.  I'm not               
sure about the whole implications of that.                                      
                                                                                
I tried changing it and found that a test failed for memoryview.                
The unit test expects TypeError from memoryview if you try to order             
them, e.g.                                                                      
                                                                                
    >>> memoryview(b'a') < b'b'                                                 
    ...                                                                         
    TypeError: unorderable types: memoryview() > bytes()                        
                                                                                
    >>> memoryview(b'a') < memoryview(b'b')                                     
    ...                                                                         
    TypeError: unorderable types: memoryview() > memoryview()                   
                                                                                
That's inconsistent though, since bytearray does use tp_as_buffer:              
                                                                                
    >>> memoryview(b'a') < bytearray(b'b')                                      
    True                                                                        
                                                                                
I think we should make bytes() use tp_as_buffer.  Attached is a patch that
implements the idea. Needs some thought and review yet.

----------
files: cmp_buffer.patch
keywords: patch
messages: 208726
nosy: nascheme
priority: low
severity: normal
stage: patch review
status: open
title: Make bytes() use tp_as_buffer for cmp
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file33603/cmp_buffer.patch

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

From report at bugs.python.org  Wed Jan 22 03:41:59 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 22 Jan 2014 02:41:59 +0000
Subject: [New-bugs-announce] [issue20340] -bb option does not have different
	behavior than -b	option
Message-ID: <1390358519.86.0.0114384663119.issue20340@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

-bb option does not have different behavior than -b option since Python 3.2.

http://docs.python.org/3.4/using/cmdline.html#cmdoption-b says:
"Issue a warning when comparing str and bytes. Issue an error when the option is given twice (-bb)."

(http://docs.python.org/3.4/howto/pyporting.html#deal-with-the-bytes-string-dichotomy also documents behavior present in Python 3.1.)

$ python3.1 -b -c 'print("" == b""); print("Program still running")'
-c:1: BytesWarning: Comparison between bytes and string
False
Program still running
$ python3.1 -bb -c 'print("" == b""); print("Program still running")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
BytesWarning: Comparison between bytes and string
$ python3.2 -b -c 'print("" == b""); print("Program still running")'
-c:1: BytesWarning: Comparison between bytes and string
False
Program still running
$ python3.2 -bb -c 'print("" == b""); print("Program still running")'
-c:1: BytesWarning: Comparison between bytes and string
False
Program still running
$ python3.3 -b -c 'print("" == b""); print("Program still running")'
-c:1: BytesWarning: Comparison between bytes and string
False
Program still running
$ python3.3 -bb -c 'print("" == b""); print("Program still running")'
-c:1: BytesWarning: Comparison between bytes and string
False
Program still running
$ python3.4 -b -c 'print("" == b""); print("Program still running")'
-c:1: BytesWarning: Comparison between bytes and string
False
Program still running
$ python3.4 -bb -c 'print("" == b""); print("Program still running")'
-c:1: BytesWarning: Comparison between bytes and string
False
Program still running
$

----------
components: Interpreter Core
keywords: 3.2regression
messages: 208736
nosy: Arfrever
priority: normal
severity: normal
status: open
title: -bb option does not have different behavior than -b option
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Jan 22 04:18:01 2014
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 22 Jan 2014 03:18:01 +0000
Subject: [New-bugs-announce] [issue20341] Argument Clinic: add "nullable
	ints"
Message-ID: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Attached is a *preliminary* patch for Argument Clinic that adds nullable ints.  If you use the converter "int(nullable=True), then:

* The type you get back is not int but "nullable_int_t", a structure
  containing three fields: "error", "is_null", and "i".  "error" is 1 if
  there was an error in parsing, else 0.  "is_null" is 1 if None was
  passed in, else 0.  "i" is the integer value if an integer was
  passed in, else undefined.
* You may now use a default value of None.  If you do, "is_null" is 1.
* You may still use a default integer.  If you do, "i" will be set
  to that.
* If you use neither then obviously it's a required argument.


I'd appreciate just a preliminary review, saying something like
"this is a good idea, keep going," or
"you should change your approach," or
"this is a bad idea and should not be committed," or
"you look very handsome today Larry".

I don't remember who specifically needed the nullable ints, so I just added a bunch of Derby contestants.

Serhiy: I also added a fix for the bug you mentioned in #20294 after it was closed: the docstring for __new__ and __init__ methods now uses the class name instead of the name of the method.  Note that this fix doesn't matter much; once I commit a fix for #20189, that signature will always be hidden.

----------
assignee: larry
components: Extension Modules
files: larry.nullable.ints.draft
messages: 208740
nosy: Yury.Selivanov, brett.cannon, georg.brandl, larry, serhiy.storchaka, vajrasky, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Argument Clinic: add "nullable ints"
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33605/larry.nullable.ints.draft

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

From report at bugs.python.org  Wed Jan 22 09:44:31 2014
From: report at bugs.python.org (Yury V. Zaytsev)
Date: Wed, 22 Jan 2014 08:44:31 +0000
Subject: [New-bugs-announce] [issue20342] Float rounding issues on Red Hat
	6.4 / PPC64 / GCC 4.4.6
Message-ID: <1390380271.48.0.67555288445.issue20342@psf.upfronthosting.co.za>


New submission from Yury V. Zaytsev:

Hi,

I've managed to get the test suite of Python to run on Python 3.4.0b2 version cross-compiled for a specialized POWER chip. I get a number of failures that seem to have the same nature. I'm under impression, that actually the tests might need to be adjusted, but I'm not sure about it. I'm happy to provide any additional information to diagnose this issue. Please let me know if I've grouped them wrong and have to file a different issue for some tests. Thanks!

== CPython 3.4.0b2 (default, Jan 7 2014, 10:01:53) [GCC 4.4.6]
==   Linux-2.6.32-358.11.1.bgq.el6.bgas_20131217.ppc64-ppc64-with-redhat-6.4-Santiago big-endian
==   hash algorithm: fnv 64bit
==   /tmp/test_python_11312
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)

======================================================================
FAIL: fromhex (builtins.float)
Doctest: builtins.float.fromhex
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/doctest.py", line 2187, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for builtins.float.fromhex
  File "builtins", line unknown line number, in fromhex

----------------------------------------------------------------------
File "builtins", line ?, in builtins.float.fromhex
Failed example:
    float.fromhex('-0x1p-1074')
Expected:
    -5e-324
Got:
    -4.9406564584124654e-324


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

======================================================================
FAIL: test_float__format__ (test.test_types.TypesTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/test/test_types.py", line 467, in test_float__format__
    test(1e200, '+', '+1e+200')
  File "/XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/test/test_types.py", line 403, in test
    self.assertEqual(f.__format__(format_spec), result)
AssertionError: '+9.9999999999999997e+199' != '+1e+200'
- +9.9999999999999997e+199
+ +1e+200


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

======================================================================
FAIL: SequenceMatcher (difflib)
Doctest: difflib.SequenceMatcher
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/doctest.py", line 2187, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for difflib.SequenceMatcher
  File "/XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/difflib.py", line 47, in SequenceMatcher

----------------------------------------------------------------------
File "/XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/difflib.py", line 83, in difflib.SequenceMatcher
Failed example:
    print(round(s.ratio(), 3))
Expected:
    0.866
Got:
    0.86599999999999999


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

======================================================================
FAIL: test_format_testfile (test.test_float.FormatTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/test/test_float.py", line 592, in test_format_testfile
    self.assertEqual(fmt % float(arg), rhs)
AssertionError: '0.029999999999999999' != '0.03'
- 0.029999999999999999
+ 0.03


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

======================================================================
FAIL: test_non_ascii (test.test_format.FormatTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/test/test_format.py", line 272, in test_non_ascii
    self.assertEqual(format(12.3, "\u2007<6"), "12.3\u2007\u2007")
AssertionError: '12.300000000000001' != '12.3\u2007\u2007'
- 12.300000000000001
+ 12.3\u2007\u2007


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

======================================================================
FAIL: test_float_default (test.test_optparse.TestExpandDefaults)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/test/test_optparse.py", line 619, in test_float_default
    self.assertHelp(self.parser, expected_help)
  File "/XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/test/test_optparse.py", line 189, in assertHelp
    actual_help + '"\n')
AssertionError: help text failure; expected:
"Usage: test [options]

Options:
  -h, --help            show this help message and exit
  -p PROB, --prob=PROB  blow up with probability PROB [default: 0.43]
"; got:
"Usage: test [options]

Options:
  -h, --help            show this help message and exit
  -p PROB, --prob=PROB  blow up with probability PROB [default:
                        0.42999999999999999]
"


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

test_doc_tests (test.test_statistics.DocTests) ... **********************************************************************
File "/XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/statistics.py", line 290, in statistics.mean
Failed example:
    mean([1, 2, 3, 4, 4])
Expected:
    2.8
Got:
    2.7999999999999998
**********************************************************************
File "/XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/statistics.py", line 380, in statistics.median_grouped
Failed example:
    median_grouped([1, 2, 2, 3, 4, 4, 4, 4, 4, 5])
Expected:
    3.7
Got:
    3.7000000000000002
**********************************************************************
File "/XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/statistics.py", line 602, in statistics.pstdev
Failed example:
    pstdev([1.5, 2.5, 2.5, 2.75, 3.25, 4.75])
Expected:
    0.986893273527251
Got:
    0.98689327352725098
**********************************************************************
3 items had failures:
   1 of   5 in statistics.mean
   1 of   4 in statistics.median_grouped
   1 of   1 in statistics.pstdev
***Test Failed*** 3 failures.

----------
components: Interpreter Core
messages: 208760
nosy: zaytsev
priority: normal
severity: normal
status: open
title: Float rounding issues on Red Hat 6.4 / PPC64 / GCC 4.4.6
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan 22 12:05:09 2014
From: report at bugs.python.org (=?utf-8?q?Christian_P=C3=A9rez?=)
Date: Wed, 22 Jan 2014 11:05:09 +0000
Subject: [New-bugs-announce] [issue20343] zipfile truncates extracted files
Message-ID: <1390388709.51.0.241436659403.issue20343@psf.upfronthosting.co.za>


New submission from Christian P?rez:

To reproduce the error:

$ wget http://dbnsfp.houstonbioinformatics.org/dbNSFPzip/dbNSFP2.0.zip

$ python
Python 2.7.4 (default, Sep 26 2013, 03:20:26) 
[GCC 4.7.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from zipfile import ZipFile
>>> 
>>> with ZipFile("dbNSFP2.0.zip", "r") as zf:
...   with zf.open("dbNSFP2.0_variant.chr20", "U") as f:
...     count = 0
...     for line in f:
...       count += 1
... 

>>> print count
964352

$ unzip -p dbNSFP2.0.zip dbNSFP2.0_variant.chr20 | wc -l
2161277

may it be related to issue 6759 ?

----------
components: Library (Lib)
messages: 208779
nosy: Christian.P?rez
priority: normal
severity: normal
status: open
title: zipfile truncates extracted files
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Jan 22 15:25:05 2014
From: report at bugs.python.org (Tobias Klausmann)
Date: Wed, 22 Jan 2014 14:25:05 +0000
Subject: [New-bugs-announce] [issue20344] subprocess.check_output() docs
	misrepresent what	shell=True does
Message-ID: <1390400705.04.0.503333173013.issue20344@psf.upfronthosting.co.za>


New submission from Tobias Klausmann:

The subprocess docs state that the first argument can be either a string or an iterable that contains the program and arguments to run. It also points out that using shell=True allows for shell constructs. It does not mention a subtlety that is introduced by Python's use of sh -c (on Unix):

Using a string that contains the full command line with args and shell=False breaks as expected:

>>> subprocess.check_output("ls foo", shell=False)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.3/subprocess.py", line 576, in check_output
    with Popen(*popenargs, stdout=PIPE, **kwargs) as process:
  File "/usr/lib64/python3.3/subprocess.py", line 824, in __init__
    restore_signals, start_new_session)
  File "/usr/lib64/python3.3/subprocess.py", line 1448, in _execute_child
    raise child_exception_type(errno_num, err_msg)
FileNotFoundError: [Errno 2] No such file or directory: 'ls foo'

Using shell=True instead works as expected (since foo does not exist, ls exits with non-0 and a different Exception is raised. This, too is to spec and exactly what the docs describe.

>>> subprocess.check_output("ls foo", shell=True)
ls: cannot access foo: No such file or directory
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.3/subprocess.py", line 589, in check_output
    raise CalledProcessError(retcode, process.args, output=output)
subprocess.CalledProcessError: Command 'ls foo' returned non-zero exit status 2

Using shell=False and making the command a list of command and args does the same thing:

>>> subprocess.check_output(["ls", "foo"], shell=False)
ls: cannot access foo: No such file or directory
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.3/subprocess.py", line 589, in check_output
    raise CalledProcessError(retcode, process.args, output=output)
subprocess.CalledProcessError: Command '['ls', 'foo']' returned non-zero exit status 2

But using an iterable _and_ requesting a shell results in something very broken:

>>> subprocess.check_output(["ls", "foo"], shell=True)
[contents of my homedir are returned]
>>>

Note that the argument "foo" completely disappears, apparently. strace() reveals that "foo" is never added to the call to "ls". Instead, it becomes $0 in the shell that ls runs in. This is exactly to spec (i.e. bash is not broken). "bash -c foo bar baz" will start a shell that sets $0 to "bar", $1 to "baz" and then executes "foo". Whereas "bash -c 'foo bar baz'" will run 'foo bar baz'.

I think there are three possible fixes here:
1- Make check_output(list, shell=True) run something like "bash -c '%s'" % " ".join(list)
2- Change the docs to warn of the unintended consequences of combining lists with shell=True
3- Make check_output() throw an Exception if the first argument is a list and shell=True

The first option would make it easiest for people to "just use it", but I fear the string manipulation may become the source of bugs with security implications in the future.

The second option keeps the status quo, but people tend to not read docs, so it may not be as effective as one would like, especially since shell-True already has warnings and people tend to go "yeah I know about unverified input, but it's not a problem for me" and then ignore both warnings.

Option 3 has the disadvantage that existing scripts that _expect_ the behavior may break.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 208811
nosy: docs at python, klausman
priority: normal
severity: normal
status: open
title: subprocess.check_output() docs misrepresent what shell=True does
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Jan 22 15:25:20 2014
From: report at bugs.python.org (Arne Babenhauserheide)
Date: Wed, 22 Jan 2014 14:25:20 +0000
Subject: [New-bugs-announce] [issue20345] Better logging defaults
Message-ID: <1390400720.32.0.906733284392.issue20345@psf.upfronthosting.co.za>


New submission from Arne Babenhauserheide:

Currently the default operation of logging prints messages like the following:

INFO:root: Milk found.

This is close to a print-call, but not much more useful - especially not in small scripts. To make the default settings more useful to quick scripts, I would suggest adding the filename and linenumber by default. This would be equivalent to the following setup:

logging.basicConfig(
    level=logging.INFO, 
    format="%(levelname)s (%(filename)s::%(lineno)s): %(message)s")

With that setup, the above message would look like this:

INFO (move.py::23): Milk found.

----------
components: Library (Lib)
messages: 208812
nosy: ArneBab
priority: normal
severity: normal
status: open
title: Better logging defaults

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

From report at bugs.python.org  Wed Jan 22 16:47:01 2014
From: report at bugs.python.org (Tal Einat)
Date: Wed, 22 Jan 2014 15:47:01 +0000
Subject: [New-bugs-announce] [issue20346] Argument Clinic: missing entry in
	table mapping legacy	convertors to real AC converters
Message-ID: <1390405621.79.0.727900748758.issue20346@psf.upfronthosting.co.za>


New submission from Tal Einat:

There is no entry for 'l', which maps to 'long' according to 'long_converter' in clinic.py.

Patch attached for Doc/howto/clinic.rst.

----------
files: missing_long_legacy_converter.clinic.rst.patch
keywords: patch
messages: 208818
nosy: larry, taleinat
priority: normal
severity: normal
status: open
title: Argument Clinic: missing entry in table mapping legacy convertors  to real AC converters
Added file: http://bugs.python.org/file33624/missing_long_legacy_converter.clinic.rst.patch

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

From report at bugs.python.org  Wed Jan 22 16:57:30 2014
From: report at bugs.python.org (Christopher the Magnificent)
Date: Wed, 22 Jan 2014 15:57:30 +0000
Subject: [New-bugs-announce] [issue20347] dir(__future__) gives segfault on
	OS X in 3.2 and 3.3
Message-ID: <1390406250.64.0.787562266918.issue20347@psf.upfronthosting.co.za>


New submission from Christopher the Magnificent:

On OS X 10.9.1
This works:

Python 2.7.5 (default, Aug 25 2013, 00:04:04) 
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import __future__
>>> dir(__future__)
['CO_FUTURE_ABSOLUTE_IMPORT', 'CO_FUTURE_DIVISION', 'CO_FUTURE_PRINT_FUNCTION', 'CO_FUTURE_UNICODE_LITERALS', 'CO_FUTURE_WITH_STATEMENT', 'CO_GENERATOR_ALLOWED', 'CO_NESTED', '_Feature', '__all__', '__builtins__', '__doc__', '__file__', '__name__', '__package__', 'absolute_import', 'all_feature_names', 'division', 'generators', 'nested_scopes', 'print_function', 'unicode_literals', 'with_statement']

This also works:

Python 3.1 (r31:73578, Jun 27 2009, 21:49:46) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import __future__
>>> dir(__future__)
['CO_FUTURE_ABSOLUTE_IMPORT', 'CO_FUTURE_BARRY_AS_BDFL', 'CO_FUTURE_DIVISION', 'CO_FUTURE_PRINT_FUNCTION', 'CO_FUTURE_UNICODE_LITERALS', 'CO_FUTURE_WITH_STATEMENT', 'CO_GENERATOR_ALLOWED', 'CO_NESTED', '_Feature', '__all__', '__builtins__', '__doc__', '__file__', '__name__', '__package__', 'absolute_import', 'all_feature_names', 'barry_as_FLUFL', 'division', 'generators', 'nested_scopes', 'print_function', 'unicode_literals', 'with_statement']


In Python 3.2 and 3.3 it appears broken.

Python 3.2.2 (v3.2.2:137e45f15c0b, Sep  3 2011, 17:28:59) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import __future__
>>> dir(__future__)
Segmentation fault: 11

also

Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 01:25:11) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import __future__
>>> dir(__future__)
Segmentation fault: 11

----------
assignee: ronaldoussoren
components: Macintosh
messages: 208819
nosy: christopherthemagnificent, ronaldoussoren
priority: normal
severity: normal
status: open
title: dir(__future__) gives segfault on OS X in 3.2 and 3.3
type: crash
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jan 22 17:39:07 2014
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 22 Jan 2014 16:39:07 +0000
Subject: [New-bugs-announce] [issue20348] Argument Clinic HOWTO listed
	multiple times in HOWTO	index
Message-ID: <1390408747.92.0.288062862329.issue20348@psf.upfronthosting.co.za>


New submission from Brett Cannon:

http://docs.python.org/3.4/howto/

Seems several sections are listed on their own in the index.

----------
assignee: larry
components: Documentation
messages: 208824
nosy: brett.cannon, larry
priority: normal
severity: normal
status: open
title: Argument Clinic HOWTO listed multiple times in HOWTO index
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan 22 17:42:02 2014
From: report at bugs.python.org (Tal Einat)
Date: Wed, 22 Jan 2014 16:42:02 +0000
Subject: [New-bugs-announce] [issue20349] Argument Clinic: error on __new__
	or __init__ with no	arguments
Message-ID: <1390408922.24.0.609938123562.issue20349@psf.upfronthosting.co.za>


New submission from Tal Einat:

This is caused by the code "fields = list(parser_body_fields)" under
"if new_or_init:" in CLanguage.output_templates().

'parser_body_fields' is initialized to None and may not be set before the
above mentioned code.

Attached is a patch which replaces the line with:

fields = list(parser_body_fields) if parser_body_fields is not None else []

----------
components: Build, Demos and Tools
files: fix_new_or_init_without_arguments.clinic.py.patch
keywords: patch
messages: 208826
nosy: larry, taleinat
priority: normal
severity: normal
status: open
title: Argument Clinic: error on __new__ or __init__ with no arguments
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33626/fix_new_or_init_without_arguments.clinic.py.patch

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

From report at bugs.python.org  Wed Jan 22 18:25:22 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 22 Jan 2014 17:25:22 +0000
Subject: [New-bugs-announce] [issue20350] Replace tkapp.split() to
	tkapp.splitlist()
Message-ID: <1390411522.89.0.349086871577.issue20350@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch replaces errorprone uses of tkapp.split() to tkapp.splitlist().

* Variable.trace_vinfo(). Actually there are no difference between split() and splitlist(), because "trace vinfo" always returns a list of 2-element tuple of strings and none of these can't contain spaces, '\\', or '{' (at least this can't be created from Tkinter).

* Misc.winfo_visualsavailable() already has a workaround for split() peculiarity. With splitlist() the code is more straightforward.

* tix.ListNoteBook.pages() and tix.NoteBook.pages() with split() can fail when there is only one page or when page names contain spaces or special characters.

* tix.CheckList.getselection() already has a workaround for split() peculiarity. It calls splitlist() for result of split(). split() call is redundant.

* In tix.Grid.size_column() and tix.Grid.size_row() there are no significant differences in behavior between split() and splitlist().

After these changes tkapp.split() no longer be used in the stdlib and can be deprecated.

----------
components: Library (Lib), Tkinter
files: tkinter_use_splitlist.patch
keywords: patch
messages: 208831
nosy: gpolo, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Replace tkapp.split() to tkapp.splitlist()
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33628/tkinter_use_splitlist.patch

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

From report at bugs.python.org  Wed Jan 22 19:07:57 2014
From: report at bugs.python.org (Charles-Axel Dein)
Date: Wed, 22 Jan 2014 18:07:57 +0000
Subject: [New-bugs-announce] [issue20351] Add doc examples for DictReader
	and DictWriter
Message-ID: <1390414077.91.0.281809568509.issue20351@psf.upfronthosting.co.za>


New submission from Charles-Axel Dein:

IMO csv.DictWriter and csv.DictReader provides a nicer interface for complex CSV file. I see some people reinventing the DictReader and DictWriter pretty frequently, because when they rapidly scan the documentation all examples are about csv.reader and csv.writer.

This patch adds examples.

----------
assignee: docs at python
components: Documentation
files: add_csvdict_examples.patch
keywords: patch
messages: 208835
nosy: charlax, docs at python
priority: normal
severity: normal
status: open
title: Add doc examples for DictReader and DictWriter
Added file: http://bugs.python.org/file33629/add_csvdict_examples.patch

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

From report at bugs.python.org  Wed Jan 22 19:17:39 2014
From: report at bugs.python.org (=?utf-8?q?Dani=C3=ABl_van_Eeden?=)
Date: Wed, 22 Jan 2014 18:17:39 +0000
Subject: [New-bugs-announce] [issue20352] Add support for AUTH command to
	poplib
Message-ID: <1390414659.94.0.817881856376.issue20352@psf.upfronthosting.co.za>


New submission from Dani?l van Eeden:

I use 'AUTH PLAIN <secret>' to login to a POP3 server with a proxy user. I can't use 'pass_()' as I need to supply a admin user and the user to proxy into.

class adminpopserver(poplib.POP3):
    def auth(self, method, secret):
        return self._shortcmd('AUTH %s %s' % (method, secret))

secret = "{user}\0{adminuser}\0{password}".format(
    user=user, 
    adminuser=adminuser, 
    password=password)
secret = secret.encode('base64').strip('\n')

----------
components: Library (Lib)
messages: 208837
nosy: dveeden
priority: normal
severity: normal
status: open
title: Add support for AUTH command to poplib
versions: Python 2.7

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

From report at bugs.python.org  Wed Jan 22 19:24:27 2014
From: report at bugs.python.org (Craig Silverstein)
Date: Wed, 22 Jan 2014 18:24:27 +0000
Subject: [New-bugs-announce] [issue20353] Hanging bug with multiprocessing +
	sqlite3 + tkinter (OS	X 10.9 only)
Message-ID: <1390415067.55.0.719190169135.issue20353@psf.upfronthosting.co.za>


New submission from Craig Silverstein:

Don't ask me how, but our code managed to combine multiprocessing, sqlite, and tkinter all in one app, and got a hanging behavior, though only on a particular OS.  Removing any of these removes the hang.  I filed this under tkinter, but the fault could well be elsewhere.

This happens for us only when run under OS X 10.9 (Mavericks).  We are using python 2.7.5; I don't know if other versions are affected.

----------
components: Tkinter
files: hang.py
messages: 208838
nosy: Craig.Silverstein
priority: normal
severity: normal
status: open
title: Hanging bug with multiprocessing + sqlite3 + tkinter (OS X 10.9 only)
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file33631/hang.py

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

From report at bugs.python.org  Wed Jan 22 19:59:07 2014
From: report at bugs.python.org (jan matejek)
Date: Wed, 22 Jan 2014 18:59:07 +0000
Subject: [New-bugs-announce] [issue20354] tracemalloc causes segfault in
	"make profile-opt"
Message-ID: <1390417147.04.0.258721573187.issue20354@psf.upfronthosting.co.za>


New submission from jan matejek:

When compiling "make profile-opt", the instrumented python executable segfaults upon exit, even though it appears to run fine.

This breaks the build process, because make evaluates the segfault as if the respective compilation step failed.

GDB yields the following backtrace for the crash:

#0  gcov_exit () at ../../../libgcc/libgcov.c:397
#1  0x00007ffff69b875f in __cxa_finalize (d=0x7ffff7c38a60) at cxa_finalize.c:56
#2  0x00007ffff771b983 in __do_global_dtors_aux () from ./libpython3.4m.so.1.0
#3  0x00007fffffffdd60 in ?? ()
#4  0x00007ffff7debe6a in _dl_fini () at dl-fini.c:252
Backtrace stopped: frame did not save the PC


This problem first appears with changeset 6e2089dbc5ad [1] that introduced tracemalloc. It is still reproducible on today's tip.

AFAICT, the mere presence of tracemalloc in the compiled executable causes this crash; I tried commenting out _PyTraceMalloc_Init from pythonrun.c and it did not help.

To reproduce:
./configure --enable-shared
make profile-opt

i'm on x86_64 SUSE Linux, gcc version is 4.8.1

[1] hg.python.org/cpython/rev/6e2089dbc5ad

----------
messages: 208842
nosy: matejcik
priority: normal
severity: normal
status: open
title: tracemalloc causes segfault in "make profile-opt"
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan 22 22:41:46 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 22 Jan 2014 21:41:46 +0000
Subject: [New-bugs-announce] [issue20355] -W command line options should
	have higher priority than	PYTHONWARNINGS environmental variable
Message-ID: <1390426906.93.0.692922610327.issue20355@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

Currently Python has non-intuitive behavior such that PYTHONWARNINGS environmental variable has higher priority than -W command line options.

$ python3.4 -c '__import__("warnings").warn("xxx", DeprecationWarning)'
$ python3.4 -Wd -c '__import__("warnings").warn("xxx", DeprecationWarning)'
-c:1: DeprecationWarning: xxx
$ python3.4 -We -c '__import__("warnings").warn("xxx", DeprecationWarning)'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
DeprecationWarning: xxx
$ PYTHONWARNINGS="e" python3.4 -Wd -c '__import__("warnings").warn("xxx", DeprecationWarning)'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
DeprecationWarning: xxx
$ PYTHONWARNINGS="d" python3.4 -We -c '__import__("warnings").warn("xxx", DeprecationWarning)'
-c:1: DeprecationWarning: xxx
$


I think that settings from -W command line options should have higher priority than PYTHONWARNINGS environmental variable.

(Adding people from issue #7301 to nosy list.)

----------
components: Interpreter Core
messages: 208854
nosy: Arfrever, barry, brian.curtin, eric.araujo, pitrou, pjenvey, skrah
priority: normal
severity: normal
status: open
title: -W command line options should have higher priority than PYTHONWARNINGS environmental variable
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Jan 22 23:52:06 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 22 Jan 2014 22:52:06 +0000
Subject: [New-bugs-announce] [issue20356] fix formatting of positional-only
	parameters in	inspect.Signature
Message-ID: <1390431126.48.0.863526301324.issue20356@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

Fix formatting of positional-only parameters to use '/' as a separator
for them from other kinds.

This patch also makes 'Parameter.name' required, as well as being a 
valid identifier (as per discussion with Larry, Nick and Brett).

----------
components: Library (Lib)
files: pos_only_format_01.patch
keywords: patch
messages: 208860
nosy: brett.cannon, larry, ncoghlan, yselivanov
priority: normal
severity: normal
status: open
title: fix formatting of positional-only parameters in inspect.Signature
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33636/pos_only_format_01.patch

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

From report at bugs.python.org  Thu Jan 23 04:18:17 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 23 Jan 2014 03:18:17 +0000
Subject: [New-bugs-announce] [issue20357] Mention buildbots in the core dev
	section of the devguide
Message-ID: <1390447097.09.0.000203036921559.issue20357@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Just a note to myself to fix this omission :)

----------
assignee: ncoghlan
messages: 208876
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Mention buildbots in the core dev section of the devguide

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

From report at bugs.python.org  Thu Jan 23 10:00:19 2014
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 23 Jan 2014 09:00:19 +0000
Subject: [New-bugs-announce] [issue20358] test_curses is failing
Message-ID: <1390467619.0.0.459315516203.issue20358@psf.upfronthosting.co.za>


New submission from Larry Hastings:

If I build current trunk on my workstation (Linux 64-bit, Ubuntu 13.10) then run

  % ./python -m test -u all test_curses

I get a traceback.  Here's the interesting part:

      File "/home/larry/src/python/buildtrunk/Lib/test/test_curses.py",
        line 118, in window_funcs

        win2.overlay(win, 1, 2, 3, 3, 2, 1)

      _curses.error: copywin() returned ERR

Zach: I just saw you had a patch specifically against test_curses.py, can you take a look?

----------
components: Library (Lib)
messages: 208887
nosy: larry, zach.ware
priority: high
severity: normal
stage: needs patch
status: open
title: test_curses is failing
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Jan 23 10:09:10 2014
From: report at bugs.python.org (Steve)
Date: Thu, 23 Jan 2014 09:09:10 +0000
Subject: [New-bugs-announce] [issue20359] Having escape sequences (like
	color codes) in the	sys.ps1 messes up readline's input line
	calculations
Message-ID: <1390468150.14.0.430221265473.issue20359@psf.upfronthosting.co.za>


New submission from Steve:

If you change the sys.ps1 to have some color, you end up messing up readline's input line calculations and the characters in the line you are typing might not get displayed properly. This behaviour is easier to demonstrate/reporduce than explain ...:

On a python promt with readline enabled (for instance, on any linux box):

[steve at localhost ~]$ python
Python 2.7.5 (default, Nov 12 2013, 16:18:42) 
[GCC 4.8.2 20131017 (Red Hat 4.8.2-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.ps1 = '\033[31m>>> \033[0m'
>>> # doing a reverse-i-search (Ctrl+r) on the next line will mess up the prompt display
... 
>>> h)`sys': sys.ps1 = '\033[31m>>> \033[0m'
(...press Ctrl-L to clear...)
(reverse-i-search)`': (press enter)
>>> arch)`':

I did some (amateur) investigation and the root cause might be similar to what's reported at:
http://trac.haskell.org/haskeline/ticket/78
https://groups.google.com/forum/#!topic/gnu.bash.bug/5P0gWzzLVOU

FWIW, I bumped into this issue while customizing my .pythonrc[1] and although it might be a silly small annoyance, it would be really nice if this bug could be fixed.

[1] https://gist.github.com/lonetwin/5902720

----------
components: Library (Lib)
messages: 208890
nosy: lonetwin
priority: normal
severity: normal
status: open
title: Having escape sequences (like color codes) in the sys.ps1 messes up readline's input line calculations
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Thu Jan 23 10:12:36 2014
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 23 Jan 2014 09:12:36 +0000
Subject: [New-bugs-announce] [issue20360] inspect.Signature could provide
	readable expressions for	default values for builtins
Message-ID: <1390468356.52.0.474182438326.issue20360@psf.upfronthosting.co.za>


New submission from Larry Hastings:

The signatures for builtins are stored as text and interpreted at runtime on demand.  inspect.Signature gets the default value for a parameter as a text string, which it evaluates (by hand, in a highly constrained way) to produce the parameter's value member.

Serhiy cleverly suggested that it'd be nice if Signature objects could also make this string available, as it's often more readable than the value.  For example, there's a parameter in zlib with the default "MAX_DECOMPRESSION - 1"; that turns into 7 I think.  Which would you prefer?

Right now there's no place to store this in the parameter object, so it can't happen for 3.4.  But perhaps in 3.5 we could add it, and figure out how to present it to the user.  For example __str__ could use it.


Thinking a little laterally: we *could* hide it in a *private* member on the Parameter object, then only use it for calculating __str__.  That would look so fancy!  Should we consider doing that for 3.4?

----------
messages: 208892
nosy: brett.cannon, larry, ncoghlan, serhiy.storchaka, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: inspect.Signature could provide readable expressions for default values for builtins
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu Jan 23 10:19:49 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 23 Jan 2014 09:19:49 +0000
Subject: [New-bugs-announce] [issue20361] -W command line options and
	PYTHONWARNINGS environmental	variable should not override -b
	/ -bb command line options
Message-ID: <1390468789.64.0.236388970509.issue20361@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

Currently -W command line options and PYTHONWARNINGS environmental variable non-intuitively override settings specified by -b / -bb command line options.

$ python3.4 -c 'print("" == b"")'
False
$ python3.4 -b -c 'print("" == b"")'
-c:1: BytesWarning: Comparison between bytes and string
False
$ python3.4 -bb -c 'print("" == b"")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
BytesWarning: Comparison between bytes and string
$ python3.4 -We -b -c 'print("" == b"")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
BytesWarning: Comparison between bytes and string
$ python3.4 -Wd -bb -c 'print("" == b"")'
-c:1: BytesWarning: Comparison between bytes and string
False
$ python3.4 -Wi -b -c 'print("" == b"")'
False
$ python3.4 -Wi -bb -c 'print("" == b"")'
False
$


I suggest to increase priority of -b / -bb command line options.
The attached patch should be applied after patch from issue #20355.

(Test suite of Python triggers some BytesWarnings, so firstly they will have to be fixed.)

----------
components: Interpreter Core
files: python-bytes_warnings.patch
keywords: patch
messages: 208894
nosy: Arfrever, barry, brett.cannon, brian.curtin, eric.araujo, larry, pitrou, pjenvey, skrah
priority: normal
severity: normal
status: open
title: -W command line options and PYTHONWARNINGS environmental variable should not override -b / -bb command line options
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33648/python-bytes_warnings.patch

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

From report at bugs.python.org  Thu Jan 23 10:39:37 2014
From: report at bugs.python.org (Dhara)
Date: Thu, 23 Jan 2014 09:39:37 +0000
Subject: [New-bugs-announce] [issue20362] longMessage attribute is ignored
	in	unittest.TestCase.assertRegexpMatches etc
Message-ID: <1390469977.33.0.983072297482.issue20362@psf.upfronthosting.co.za>


New submission from Dhara:

Various assert methods added in version 2.7 ignore the longMessage attribute:
http://docs.python.org/2.7/library/unittest.html#unittest.TestCase.longMessage

For example when matching regular expressions using unittest.TestCase.assertRegexpMatches, the following error is generated:

AssertionError: <custom short message>: '<regexp>' not found in '<text>'

Since longMessage is ignored, and the text to be matched can be pages long, the error messages are impossibly long.

[See also: http://stackoverflow.com/questions/21157905/suppress-supplementary-error-message-from-unit-test]

----------
components: Library (Lib)
messages: 208899
nosy: Dhara
priority: normal
severity: normal
status: open
title: longMessage attribute is ignored in unittest.TestCase.assertRegexpMatches etc
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Jan 23 10:47:31 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 23 Jan 2014 09:47:31 +0000
Subject: [New-bugs-announce] [issue20363] BytesWarnings triggerred by test
	suite
Message-ID: <1390470451.71.0.00122717133798.issue20363@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

[194/388] test_base64
/tmp/cpython/Lib/base64.py:365: BytesWarning: str() on a bytes instance
  "by {} and {}".format(_A85START, _A85END))
...
[204/388] test_hash
/tmp/cpython/Lib/test/test_hash.py:175: BytesWarning: str() on a bytes instance
  return 'print(hash(eval(%s.decode("utf-8"))))' % repr_.encode("utf-8")
...
[234/388] test_configparser
/tmp/cpython/Lib/configparser.py:289: BytesWarning: str() on a bytes instance
  Error.__init__(self, 'Source contains parsing errors: %s' % source)
/tmp/cpython/Lib/configparser.py:326: BytesWarning: str() on a bytes instance
  (filename, lineno, line))
...
[332/388/1] test_distutils
/tmp/cpython/Lib/distutils/command/register.py:303: BytesWarning: str() on a bytes instance
  self.announce('%s%s%s' % (dashes, data, dashes))

----------
components: Library (Lib)
messages: 208903
nosy: Arfrever, eric.araujo, lukasz.langa, tarek
priority: normal
severity: normal
status: open
title: BytesWarnings triggerred by test suite
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Jan 23 11:42:59 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Jan 2014 10:42:59 +0000
Subject: [New-bugs-announce] [issue20364] Rename & explain
	sqlite3.Cursor.execute 'parameters'	param
Message-ID: <1390473779.26.0.463818219743.issue20364@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

"execute(sql[, parameters])
    Executes an SQL statement. The SQL statement may be parametrized (i. e. placeholders instead of SQL literals). The sqlite3 module supports two kinds of placeholders: question marks (qmark style) and named placeholders (named style)."

Experimental facts based on experiments with the code example in the doc, using 3.4.b2: 'parameters' is a single subscriptable collection parameter, sequence or dict, that might be called seq_dict. It is positional only, so whatever name is used is a dummy. Only one placeholder style can be used in a given SQL statement string. If question marks are used, seq_dict must be a sequence. If names are used, seq_dict can be either a sequence or dict or subclass thereof. A UserDict is treated as a sequence and raises KeyError(0).

Possible text that encompasses the above, replacing the last sentence:

"A statement may use one of two kinds of placeholders: question marks (qmark style) or named placeholders (named style). For qmark style, seq_dict must be a sequence. For named style, it can be either a sequence or dict instance. Len(seq_dict) must match the number of placeholders."

After cleaning up the test file, I will verify on 2.7 and upload.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 208908
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Rename & explain sqlite3.Cursor.execute 'parameters'  param
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Jan 23 15:33:19 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Jan 2014 14:33:19 +0000
Subject: [New-bugs-announce] [issue20365]
	test_asyncio.test_read_pty_output() fails on "AMD64 Snow	Leop
	3.x" buildbot
Message-ID: <1390487599.93.0.989391561311.issue20365@psf.upfronthosting.co.za>


New submission from STINNER Victor:

kqueue doesn't support character devices like PTY before Mac OS 10.9. This issue is discussion on Tulip mailing list, no decision was taken yet how to fix this issue.

http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/1071/steps/test/logs/stdio

======================================================================
ERROR: test_read_pty_output (test.test_asyncio.test_events.KqueueEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/asyncio/selector_events.py", line 135, in add_reader
    key = self._selector.get_key(fd)
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/selectors.py", line 181, in get_key
    raise KeyError("{!r} is not registered".format(fileobj)) from None
KeyError: '7 is not registered'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_asyncio/test_events.py", line 980, in test_read_pty_output
    self.loop.run_until_complete(connect())
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/asyncio/base_events.py", line 177, in run_until_complete
    return future.result()
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/asyncio/futures.py", line 236, in result
    raise self._exception
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/asyncio/tasks.py", line 281, in _step
    result = next(coro)
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_asyncio/test_events.py", line 974, in connect
    master_read_obj)
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/asyncio/base_events.py", line 537, in connect_read_pipe
    transport = self._make_read_pipe_transport(pipe, protocol, waiter)
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/asyncio/unix_events.py", line 149, in _make_read_pipe_transport
    return _UnixReadPipeTransport(self, pipe, protocol, waiter, extra)
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/asyncio/unix_events.py", line 200, in __init__
    self._loop.add_reader(self._fileno, self._read_ready)
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/asyncio/selector_events.py", line 138, in add_reader
    (handle, None))
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/selectors.py", line 462, in register
    self._kqueue.control([kev], 0, 0)
OSError: [Errno 22] Invalid argument

----------
components: Tests
keywords: buildbot
messages: 208941
nosy: gvanrossum, haypo
priority: normal
severity: normal
status: open
title: test_asyncio.test_read_pty_output() fails on "AMD64 Snow Leop 3.x" buildbot
versions: Python 3.4

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

From report at bugs.python.org  Thu Jan 23 15:39:10 2014
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 23 Jan 2014 14:39:10 +0000
Subject: [New-bugs-announce] [issue20366] SQLite FTS (full text search)
Message-ID: <1390487950.26.0.724740577433.issue20366@psf.upfronthosting.co.za>


New submission from Mark Summerfield:

This is a feature request that future versions of SQLite 3 that are bundled with Python 3 in the Windows binary packages (.msi files) has been build with the FTS4 (full text search version 4) enabled.

----------
components: Extension Modules
messages: 208946
nosy: mark
priority: normal
severity: normal
status: open
title: SQLite FTS (full text search)
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jan 23 16:00:48 2014
From: report at bugs.python.org (Glenn Langford)
Date: Thu, 23 Jan 2014 15:00:48 +0000
Subject: [New-bugs-announce] [issue20367] concurrent.futures.as_completed()
	fails when given	duplicate Futures
Message-ID: <1390489248.24.0.751917808957.issue20367@psf.upfronthosting.co.za>


New submission from Glenn Langford:

concurrent.futures.as_completed([f,f]) will yield f twice, then fail with a KeyError for a Future f which is not completed.

If the Future has already completed, as_completed([f,f]) will yield f once and does not trigger an exception.

What is the correct behaviour?
   as_completed( [f,f] ) -> yield f twice ?
   wait( [f,f], return_when=ALL_COMPLETED ) -> yield f twice ?

----------
components: Library (Lib)
files: test_dupfuture.py
messages: 208952
nosy: glangford
priority: normal
severity: normal
status: open
title: concurrent.futures.as_completed() fails when given duplicate Futures
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33658/test_dupfuture.py

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

From report at bugs.python.org  Thu Jan 23 16:15:02 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 23 Jan 2014 15:15:02 +0000
Subject: [New-bugs-announce] [issue20368] Tkinter: handle the null character
Message-ID: <1390490102.86.0.0317755498486.issue20368@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Tcl/Tk uses modified UTF-8 encoding to represent strings as C strings (char*). Because C strings are NUL-terminated, the null character represented as illegal UTF-8 sequence \xc0\x80.

Current Tkinter code is not very aware about this. It has special handling the "\xc0\x80" string (i.e. encoded single null character) in one place, but doesn't handle encoded null character contained in larger string. As result Tkinter may truncate strings contained the null character, or return wrong result.

The proposed patch fixes many issues with the null character (converting from Tcl to Python strings). NUL is still forbidden in string arguments of many methods.

Also the patch enhances error handling for variable-related commands.

----------
components: Extension Modules, Tkinter
files: tkinter_null_character.patch
keywords: patch
messages: 208954
nosy: gpolo, kbk, loewis, roger.serwy, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Tkinter: handle the null character
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33659/tkinter_null_character.patch

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

From report at bugs.python.org  Thu Jan 23 16:33:51 2014
From: report at bugs.python.org (Glenn Langford)
Date: Thu, 23 Jan 2014 15:33:51 +0000
Subject: [New-bugs-announce] [issue20369] concurrent.futures.wait() blocks
	forever when given	duplicate Futures
Message-ID: <1390491231.67.0.503348563079.issue20369@psf.upfronthosting.co.za>


New submission from Glenn Langford:

For a Future f which has already completed, 
  wait( [f,f], return_when=ALL_COMPLETED ) 
blocks forever.

This is because the test in wait():

  if len(done) == len(fs)

is comparing the length of a set to the length of a list. 

If f has not completed, wait( [f,f] ) will yield f once. The behaviour should be consistent with as_completed() - see issue #20367.

----------
files: test_dupfuture_wait.py
messages: 208960
nosy: glangford, haypo, mark.dickinson, tim.peters
priority: normal
severity: normal
status: open
title: concurrent.futures.wait() blocks forever when given duplicate Futures
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33660/test_dupfuture_wait.py

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

From report at bugs.python.org  Thu Jan 23 16:55:03 2014
From: report at bugs.python.org (July)
Date: Thu, 23 Jan 2014 15:55:03 +0000
Subject: [New-bugs-announce] [issue20370] Docs error in Library
	reference-17.1.3	threading.Lock.acquire()
Message-ID: <1390492503.52.0.179791157222.issue20370@psf.upfronthosting.co.za>


New submission from July:

In docs of Library reference-17.1.3 :
threading.Lock.acquire(blocking=True,timeout=-1):
line3 said: If a call with blocking set to True would block, return False immediately

Here I suspect the blocking argument ought to be False as described subsequently.
If it's set to True,it would block but return False immediately.


P.S. first try of a non-native English speaker,do not care if any syntax error was made up there,please

----------
assignee: docs at python
components: Documentation
messages: 208962
nosy: docs at python, yonoho
priority: normal
severity: normal
status: open
title: Docs error in Library reference-17.1.3 threading.Lock.acquire()
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu Jan 23 20:47:24 2014
From: report at bugs.python.org (Andrew Lutomirski)
Date: Thu, 23 Jan 2014 19:47:24 +0000
Subject: [New-bugs-announce] [issue20371] datetime.datetime.replace bypasses
	a subclass's __new__
Message-ID: <1390506444.15.0.286575412745.issue20371@psf.upfronthosting.co.za>


New submission from Andrew Lutomirski:

I'll admit that what I'm doing is possibly unhealthy.  Nonetheless, I find this behavior *extremely* surprising.  This code:

--- start code ---

import datetime

class my_dt(datetime.datetime):
    def __new__(cls, *args, **kwargs):
        print('In my_dt.__new__')
        return datetime.datetime.__new__(cls, *args, **kwargs)

    def __init__(self, *args, **kwargs):
        print('In my_dt.__init__')
        super(my_dt, self).__init__()

dt = datetime.datetime.now()

print('Create a my_dt')
t = my_dt(dt.year, dt.month, dt.day, dt.hour, dt.minute, dt.second, dt.microsecond, dt.tzinfo)


print('Calling replace')
t2 = t.replace(tzinfo=None)
print('Got a %r' % type(t2))

--- end code ---

results in:

Create a my_dt
In my_dt.__new__
In my_dt.__init__
Calling replace
Got a <class '__main__.my_dt'>

So datetime.datetime.replace will create an object of type my_dt *without calling __new__ or __init__*.  This should (AFAIK) be impossible.

I think that datetime.datetime.replace should either return an actual datetime object or that it should invoke __new__ and probably __init__.

----------
components: Library (Lib)
messages: 208980
nosy: Andrew.Lutomirski
priority: normal
severity: normal
status: open
title: datetime.datetime.replace bypasses a subclass's __new__
versions: Python 3.3

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

From report at bugs.python.org  Thu Jan 23 21:26:09 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 23 Jan 2014 20:26:09 +0000
Subject: [New-bugs-announce] [issue20372] inspect.getfile should raise a
	TypeError if C object	does not have __module__
Message-ID: <1390508769.95.0.155655534379.issue20372@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

I'm not sure if it is right to fix the inspect module, instead of making all C objects to have the '__module__' attribute (is it even possible?), but if it is, the patch is attached.

----------
files: getfile_patch_01.patch
keywords: patch
messages: 208988
nosy: ncoghlan, serhiy.storchaka, yselivanov
priority: high
severity: normal
status: open
title: inspect.getfile should raise a TypeError if C object does not have __module__
Added file: http://bugs.python.org/file33667/getfile_patch_01.patch

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

From report at bugs.python.org  Fri Jan 24 03:49:19 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 24 Jan 2014 02:49:19 +0000
Subject: [New-bugs-announce] [issue20373] Use
	test.script_helper.assert_python_ok() instead of	subprocess.*
	in test.test_warnings
Message-ID: <1390531759.42.0.533556896595.issue20373@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

These patches make test.test_warnings use test.script_helper.assert_python_ok() instead of subprocess.*, as suggested by Antoine in msg209022.

----------
assignee: pitrou
components: Tests
files: python-2.7-test_warnings.py_use_assert_python_ok.patch
keywords: patch
messages: 209030
nosy: Arfrever, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Use test.script_helper.assert_python_ok() instead of subprocess.* in test.test_warnings
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33671/python-2.7-test_warnings.py_use_assert_python_ok.patch

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

From report at bugs.python.org  Fri Jan 24 05:26:50 2014
From: report at bugs.python.org (jhl)
Date: Fri, 24 Jan 2014 04:26:50 +0000
Subject: [New-bugs-announce] [issue20374] Failure to compile with
	readline-6.3-rc1
Message-ID: <1390537610.1.0.747015129006.issue20374@psf.upfronthosting.co.za>


New submission from jhl:

Python 2.7.6 does not compile with readline 6.3 (rc1).
It looks like the RL_FUNCTION_TYPEDEF support in Modules/readline.c is not quite complete.

The following patch works for me, both for 2.7.6 and 3.3.3.

--- a/Modules/readline.c	2013-11-10 18:36:41.000000000 +1100
+++ b/Modules/readline.c	2014-01-24 15:11:04.182417214 +1100
@@ -911,12 +911,27 @@
     rl_bind_key_in_map ('\t', rl_complete, emacs_meta_keymap);
     rl_bind_key_in_map ('\033', rl_complete, emacs_meta_keymap);
     /* Set our hook functions */
-    rl_startup_hook = (Function *)on_startup_hook;
+    rl_startup_hook =
+#if defined(_RL_FUNCTION_TYPEDEF)
+        (rl_hook_func_t *)on_startup_hook;
+#else
+        (Function *)on_startup_hook;
+#endif
 #ifdef HAVE_RL_PRE_INPUT_HOOK
-    rl_pre_input_hook = (Function *)on_pre_input_hook;
+    rl_pre_input_hook = 
+#if defined(_RL_FUNCTION_TYPEDEF)
+        (rl_hook_func_t *)on_pre_input_hook;
+#else
+        (Function *)on_pre_input_hook;
+#endif
 #endif
     /* Set our completion function */
-    rl_attempted_completion_function = (CPPFunction *)flex_complete;
+    rl_attempted_completion_function =
+#if defined(_RL_FUNCTION_TYPEDEF)
+        (rl_completion_func_t *)flex_complete;
+#else
+        (CPPFunction *)flex_complete;
+#endif
     /* Set Python word break characters */
     completer_word_break_characters =
         rl_completer_word_break_characters =

----------
components: Extension Modules
messages: 209035
nosy: jhl
priority: normal
severity: normal
status: open
title: Failure to compile with readline-6.3-rc1
versions: Python 2.7

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

From report at bugs.python.org  Fri Jan 24 05:53:36 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Fri, 24 Jan 2014 04:53:36 +0000
Subject: [New-bugs-announce] [issue20375] ElementTree: Document handling
	processing instructions
Message-ID: <1390539216.23.0.0362813865609.issue20375@psf.upfronthosting.co.za>


New submission from Nikolaus Rath:

(This issue was branched of from #9521).

When parsing XML, etree currently skips over all processing instructions and comments. However, both can be represented in the tree and are also written out when generating XML.

The attached patch documents this (IMO surprising) behavior.

----------
assignee: docs at python
components: Documentation
files: xml.etree_r1.patch
keywords: patch
messages: 209036
nosy: docs at python, eli.bendersky, eric.araujo, ezio.melotti, georg.brandl, nikolaus.rath, scoder
priority: normal
severity: normal
status: open
title: ElementTree: Document handling processing instructions
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33675/xml.etree_r1.patch

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

From report at bugs.python.org  Fri Jan 24 09:21:59 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jan 2014 08:21:59 +0000
Subject: [New-bugs-announce] [issue20376] Argument Clinic: backslashes in
	docstrings are not	escaped
Message-ID: <1390551719.55.0.676646267319.issue20376@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Argument Clinic copies backslashes in docstrings as is. This can produce wrong or even invalid C string. Either backslashes should be escaped, or current behavior should be documented.

----------
components: Demos and Tools
messages: 209044
nosy: larry, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Argument Clinic: backslashes in docstrings are not escaped
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Jan 24 09:30:37 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jan 2014 08:30:37 +0000
Subject: [New-bugs-announce] [issue20377] Argument Clinic: get rid of the
	"_impl" suffix
Message-ID: <1390552237.96.0.0267615751895.issue20377@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

For now most hand-written functions which use Argument Clinic have the "_impl" suffix and generated wrapper functions without the "_impl" suffix are less interested and visible to developer (generated *_METHODDEF macros are used in method list). I propose to revert things and name implementation functions without the "_impl" suffix, but add the "_wrapper" (or "_method"?) suffix to generated wrapper functions.

----------
components: Demos and Tools
messages: 209045
nosy: larry, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Argument Clinic: get rid of the "_impl" suffix
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Jan 24 15:05:52 2014
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 24 Jan 2014 14:05:52 +0000
Subject: [New-bugs-announce] [issue20378] Implement `Signature.__repr__`
Message-ID: <1390572352.73.0.323073863277.issue20378@psf.upfronthosting.co.za>


Changes by Ram Rachum <ram at rachum.com>:


----------
components: Library (Lib)
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Implement `Signature.__repr__`
versions: Python 3.5

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

From report at bugs.python.org  Fri Jan 24 15:06:42 2014
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 24 Jan 2014 14:06:42 +0000
Subject: [New-bugs-announce] [issue20379] help(bound_builtin_class) does not
	display self
Message-ID: <1390572402.09.0.311482588548.issue20379@psf.upfronthosting.co.za>


New submission from Larry Hastings:

For an object O that are bound to something (either a class or an instance), help(O) traditionally shows the bound argument.  For this code:

    class C:
        def foo(self, a):  pass

    c = C()

help(c.foo) would show the signature as "(self, a)", even though self has been bound.

My recent changes to Python's type system (#20189), to add inspect.Signature support for builtins, broke this.  The previous behavior should be restored.

----------
assignee: larry
messages: 209078
nosy: larry, zach.ware
priority: deferred blocker
severity: normal
stage: needs patch
status: open
title: help(bound_builtin_class) does not display self
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Jan 24 15:32:59 2014
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 24 Jan 2014 14:32:59 +0000
Subject: [New-bugs-announce] [issue20380] __defaults__ changed by *args
Message-ID: <1390573979.83.0.371857256149.issue20380@psf.upfronthosting.co.za>


New submission from Ram Rachum:

Check the following example out. Putting *args in a function makes its __defaults__ be empty.

    Python 3.4.0b2 (v3.4.0b2:ba32913eb13e, Jan  5 2014, 16:13:26) [MSC v.1600 64 bit (AMD64)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> def f(x, *args, y='meow'): pass
    ...
    >>> f.__defaults__
    >>> def g(x, y='meow'): pass
    ...
    >>> g.__defaults__
    ('meow',)
    >

----------
components: Interpreter Core
messages: 209085
nosy: cool-RR
priority: normal
severity: normal
status: open
title: __defaults__ changed by *args
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jan 24 17:02:57 2014
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 24 Jan 2014 16:02:57 +0000
Subject: [New-bugs-announce] [issue20381] Argument Clinic: expression
	default arguments broken
Message-ID: <1390579377.01.0.888294922653.issue20381@psf.upfronthosting.co.za>


New submission from Zachary Ware:

The fix for #20189 broke simple expression defaults.  Specifically, with the latest #20172 patch applied, Clinic fails on winreg.c at winreg line 1351 with this traceback:

Error in file "PC\winreg.c" on line 1351:
Exception raised during parsing:
Traceback (most recent call last):
  File "Tools\clinic\clinic.py", line 1541, in parse
    parser.parse(block)
  File "Tools\clinic\clinic.py", line 2942, in parse
    self.state(line)
  File "Tools\clinic\clinic.py", line 3482, in state_parameter_docstring
    return self.next(self.state_parameter, line)
  File "Tools\clinic\clinic.py", line 2975, in next
    self.state(line)
  File "Tools\clinic\clinic.py", line 3321, in state_parameter
    bad = default != repr(eval(default))
  File "<string>", line 1, in <module>
NameError: name 'winreg' is not defined

In this case, 'default' is 'winreg.KEY_WRITE'.  The 'default != repr(eval(default))' check cannot succeed with such a default even if winreg were defined, as it will return an int, 131078.

----------
assignee: larry
components: Demos and Tools
messages: 209094
nosy: larry, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Argument Clinic: expression default arguments broken
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Jan 24 18:11:01 2014
From: report at bugs.python.org (mailination)
Date: Fri, 24 Jan 2014 17:11:01 +0000
Subject: [New-bugs-announce] [issue20382] Typo in cStringIO tp_name
Message-ID: <1390583461.72.0.218990367859.issue20382@psf.upfronthosting.co.za>


New submission from mailination:

python/Modules/cStringIO.c:648

  "cStringIO.StringI",                        /*tp_name*/

maybe Should be

  "cStringIO.StringIO",                        /*tp_name*/

----------
components: Library (Lib)
messages: 209099
nosy: mailination
priority: normal
severity: normal
status: open
title: Typo in cStringIO tp_name
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jan 24 18:11:47 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Jan 2014 17:11:47 +0000
Subject: [New-bugs-announce] [issue20383] Add a keyword-only spec argument
	to types.ModuleType
Message-ID: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Would allow for the name attribute to be optional since it can be grabbed from the spec. Since having module.__spec__ set is now expected we should help ensure that by supporting it in the constructor.

----------
components: Library (Lib)
messages: 209100
nosy: brett.cannon, eric.snow, ncoghlan
priority: low
severity: normal
stage: test needed
status: open
title: Add a keyword-only spec argument to types.ModuleType
versions: Python 3.5

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

From report at bugs.python.org  Fri Jan 24 20:34:39 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jan 2014 19:34:39 +0000
Subject: [New-bugs-announce] [issue20384] open() exception doesn't contain
	file name on Windows
Message-ID: <1390592079.62.0.820816905232.issue20384@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

On Linux for 2.7, 3.3 and 3.4 the open of non-existing file raises an exception which contains file name.

Python 2.7:

>>> open('non-existing', 'rb')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 2] No such file or directory: 'non-existing'
>>> import io
>>> io.open('non-existing', 'rb')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 2] No such file or directory: 'non-existing'

Python 3.3 and 3.4:

>>> open('non-existing', 'rb')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
FileNotFoundError: [Errno 2] No such file or directory: 'non-existing'

On Windows for 2.7 and 3.4 raised exception also contains file name. But on 3.3 error message is only "[Errno 2] No such file or directory" and doesn't contains file name.

This change affects tests. test_tarfile failed on all Windows buildbots for 3.3.

http://buildbot.python.org/all/builders/x86%20Windows7%203.3/builds/1252/steps/test/logs/stdio

I suppose this is 3.3 bug.

----------
components: IO
messages: 209109
nosy: benjamin.peterson, hynek, pitrou, serhiy.storchaka, stutzbach
priority: normal
severity: normal
status: open
title: open() exception doesn't contain file name on Windows
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Jan 24 22:35:41 2014
From: report at bugs.python.org (Tal Einat)
Date: Fri, 24 Jan 2014 21:35:41 +0000
Subject: [New-bugs-announce] [issue20385] Argument Clinic: Support for
	__new__ not checking	_PyArg_NoKeywords for sub-classes
Message-ID: <1390599341.47.0.747419262521.issue20385@psf.upfronthosting.co.za>


New submission from Tal Einat:

To quote issue20294 where Larry Hastings added AC support for __new__ and __init__:

"
* __init__ and __new__ always take kwargs.
  * if the function signature doesn't accept keyword arguments,
    it calls _PyArg_NoKeywords().
"

However, due to issue1486663, many classes only do a _PyArg_NoKeywords if the type is the original class, but not for sub-classses. Examples are _random.Random (in which case I found a workaround) and many itertools classes, for which there are also tests that check this.

One possibility is to simply allow these classes to also accept keyword arguments. It doesn't break backwards compatibility, and once there are proper argument names and doc-strings, why not?

Otherwise, currently I have to make generated __new__ functions accept keyword arguments, and then wrap them with a function that checks _PyArg_NoKeywords only if the the type is the original class.

----------
components: Build, Demos and Tools
messages: 209122
nosy: larry, taleinat
priority: normal
severity: normal
status: open
title: Argument Clinic: Support for __new__ not checking _PyArg_NoKeywords for sub-classes
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Jan 24 23:48:21 2014
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 24 Jan 2014 22:48:21 +0000
Subject: [New-bugs-announce] [issue20386] socket.SocketType is different in
	Python 3.4
Message-ID: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

Python 2.7

>>> import socket
>>> socket.SocketType
<class 'socket._socketobject'>
>>> s = socket.socket()
>>> isinstance(s, socket.SocketType)
True
>>> 


Python 3.4

>>> socket.SocketType
<enum 'SocketType'>
>>> s = socket.socket()
>>> isinstance(s, socket.SocketType)
False
>>> 

SocketType was already present and documented in Python 2 so it should be preserved: http://docs.python.org/2/library/socket.html#socket.SocketType

Also, socket.SocketType and socket.AddressFamily names suggest they should be public but they're not mentioned in the doc.  I think they should just be private though (frankly I fail to understand why a set of constants such as AF_* and SOCK_* should be grouped in a common "container" in the first place).

----------
messages: 209134
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: socket.SocketType is different in Python 3.4
versions: Python 3.4

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

From report at bugs.python.org  Fri Jan 24 23:51:15 2014
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 24 Jan 2014 22:51:15 +0000
Subject: [New-bugs-announce] [issue20387] tokenize/untokenize roundtrip
	fails with tabs
Message-ID: <1390603875.19.0.598751073352.issue20387@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

Consider this simple unit test:

def test_tokenize():
    input = "if False:\n\tx=3\n\ty=3\n"
    g = list(generate_tokens(io.StringIO(input).readline))
    assert untokenize(g) == input

According to the docs, untokenize guarantees the output equals the input to tokenize: http://docs.python.org/2/library/tokenize.html#tokenize.untokenize

As this test fails on Python 2 and Python 3 (use io.BytesIO on Python 2), I believe the test illustrates a violation of this guarantee. The second line in the if block gets its tab replaced by a space.

As the input is valid Python Syntax, this behavior is particularly surprising.

----------
messages: 209137
nosy: jason.coombs
priority: normal
severity: normal
status: open
title: tokenize/untokenize roundtrip fails with tabs
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Sat Jan 25 09:53:27 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Jan 2014 08:53:27 +0000
Subject: [New-bugs-announce] [issue20388] Argument Clinic generates wrong
	signature for module	level functions
Message-ID: <1390640007.07.0.491459956475.issue20388@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Argument Clinic generates wrong signature for module level functions.

For example for the following declaration

/*[clinic input]
binascii.a2b_uu

    ascii: ascii_buffer
    /

Decode a line of uuencoded data.
[clinic start generated code]*/

Argument Clinic generates

PyDoc_STRVAR(binascii_a2b_uu__doc__,
"a2b_uu(module, ascii)\n"
"Decode a line of uuencoded data.");

----------
components: Demos and Tools
messages: 209166
nosy: larry, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Argument Clinic generates wrong signature for module level functions
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Jan 25 13:37:20 2014
From: report at bugs.python.org (Julian Taylor)
Date: Sat, 25 Jan 2014 12:37:20 +0000
Subject: [New-bugs-announce] [issue20389] clarify meaning of xbar and mu in
	pvariance/variance of	statistics module
Message-ID: <1390653440.27.0.247965137131.issue20389@psf.upfronthosting.co.za>


New submission from Julian Taylor:

the pvariance and variance functions take the argument mu and xbar to pass the population and sample mean to avoid some recomputation.

I assume the keyword arguments are different because the two means accepted are different, but the docstring does not indicate this directly.
It just says mu or xbar is the mean of the data. The module documentation is a little clearer but only in the grey box right at the end.

I would propose to change the docstring and module documentation to explicitly state that mu is the population mean and xbar is the population mean.
E.g.

- The optional argument mu, if given, should be the mean of
the data.
+ The optional argument mu, if given, should be the population mean of
the data.

etc.

----------
messages: 209192
nosy: jtaylor
priority: normal
severity: normal
status: open
title: clarify meaning of xbar and mu in pvariance/variance of statistics module
versions: Python 3.4

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

From report at bugs.python.org  Sat Jan 25 16:28:46 2014
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 25 Jan 2014 15:28:46 +0000
Subject: [New-bugs-announce] [issue20390] Argument Clinic rollup patch,
	2014/01/25
Message-ID: <1390663726.3.0.8274031742.issue20390@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Rollup patch with a bunch of small fixes in it.  Can I get a quick turnaround review on this?  I'd like it to go in before today's beta is cut.  Definitely the core change has to go in, but that's uncontroversial.

  Core:
  * _PyType_GetDocFromInternalDoc() and
    _PyType_GetTextSignatureFromInternalDoc() are now marked
     Py_LIMITED_API.

  Tools:
  * The default filename for the "file" preset is now:
     "clinic/{filename}.h".

  * The "class" directive syntax has been extended with two new required
    arguments: "typedef" and "type_object".  "typedef" should be the
    equivalent C type for this Python class, presented as a
    pointer-to-type.  "type_object" should be an expression that
    evaluates to a PyTypeObject * for this Python type.  Example:
        class dict "PyDictObject *" "&PyDict_Type"
    This was necessary for the next item.

  * If __new__ or __init__ functions did not use kwargs (or args), the
    PyArg_NoKeywords (or PyArg_NoPositional) calls generated are only
    run if the type object is an exact match.  (Otherwise subclasses
    will not be allowed to start accepting those kinds of arguments.)

  * Argument Clinic now fails if you have required parameters after
    optional parameters.

  * Converters now have a new template they can inject code into:
    it's called "modifiers", and code put there is run in the parsing
    function after argument parsing but before the call to the impl.
    "modifiers" is intended for converters that may want dynamic
    default values.  An example string you might add:
        "if ({name} == NULL)\n    name = time(NULL);"

----------
assignee: larry
components: Demos and Tools
files: larry.clinic.rollup.jan.25.diff.1.txt
messages: 209205
nosy: larry, ncoghlan, serhiy.storchaka, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Argument Clinic rollup patch, 2014/01/25
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33702/larry.clinic.rollup.jan.25.diff.1.txt

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

From report at bugs.python.org  Sat Jan 25 17:18:17 2014
From: report at bugs.python.org (Thomas Heller)
Date: Sat, 25 Jan 2014 16:18:17 +0000
Subject: [New-bugs-announce] [issue20391] windows python launcher should
	support explicit 64-bit	version
Message-ID: <1390666697.34.0.8179359034.issue20391@psf.upfronthosting.co.za>


New submission from Thomas Heller:

The windows python launcher supports the '-3.3' resp. '-3.3-32' command line switches to ask for 'the best 3.3' version resp. 'the 32-bit 3.3' version, but does not support a '-3.3-64' switch to explicitely request the 64-bit version of Python.

I suggest that this support should be added.

----------
messages: 209215
nosy: theller
priority: normal
severity: normal
status: open
title: windows python launcher should support explicit 64-bit version
type: enhancement

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

From report at bugs.python.org  Sat Jan 25 18:17:48 2014
From: report at bugs.python.org (Rodrigo Parra)
Date: Sat, 25 Jan 2014 17:17:48 +0000
Subject: [New-bugs-announce] [issue20392] Inconsistency with uppercase file
	extensions in	MimeTypes.guess_type
Message-ID: <1390670268.05.0.579524422182.issue20392@psf.upfronthosting.co.za>


New submission from Rodrigo Parra:

The functions looks up for the file extension in three maps: types_map, suffix_map and encodings_map.

Lookup in types_map is case insensitive (by calling lower() first).
Lookup in both suffix_map and encodings_map is case sensitive.

These can lead to some seemingly counterintuitive results, like:

a)
guess_type("foo.tar") == ("application/x-tar", None)
guess_type("foo.TAR") == ("application/x-tar", None)

b)
guess_type("foo.tgz") == ("application/x-tar", "gzip")
guess_type("foo.TGZ") == (None, None)

c)
guess_type("foo.tar.gz") == ("application/x-tar", "gzip")
guess_type("foo.TAR.GZ") == (None, None)

Lookup should be case insensitive at least for the suffix_map, in which case (b) would be solved. The submitted patch implements this change.

As for the encodings_map, I am not so sure, in particular because of the tar.Z extension. I found that the compress command expects the uppercase 'Z'. If someone is relying in the results of guess_type to call compress, errors could occur.

----------
components: Library (Lib)
files: case_guess_type.patch
keywords: patch
messages: 209218
nosy: Rodrigo.Parra, tim.golden
priority: normal
severity: normal
status: open
title: Inconsistency with uppercase file extensions in MimeTypes.guess_type
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33703/case_guess_type.patch

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

From report at bugs.python.org  Sat Jan 25 22:29:29 2014
From: report at bugs.python.org (Zearin)
Date: Sat, 25 Jan 2014 21:29:29 +0000
Subject: [New-bugs-announce] [issue20393] Docs: mark deprecated items in the
	TOC
Message-ID: <1390685369.63.0.965002484298.issue20393@psf.upfronthosting.co.za>


New submission from Zearin:

When exploring the docs for the standard library, it?s frustrating to have an idea and look for the answer only to find out that an entire module (or package) has been deprecated _after_ I click on it. 

Can we have links to deprecated items on the Standard Library?s TOC page flagged?  

I see you?re using multiple CSS classes on some links.  I propose: 

- add a CSS class to flag links to deprecated items
- use something like the following CSS


----

/*
 * Example 1: color 
 */
.toctree-wrapper a.deprecated {
    color: #933;
}

/* 
 * Example 2: "badge" 
 */
.toctree-wrapper a.deprecated:after {
	display: inline-block;
    content: "deprecated";
	margin: 0 1em;
	padding: 0 1ex !important;
	border-radius: 			1ex !important;
    
	font-size: x-small;
    
	background-color: #f66;
    color: #933;
}

----

Of course, since the CSS class '.deprecated' already exists, there's 2 options: 

1. the examples above are rewritten to use a different classname, or 
2. add the following CSS:

----

/* "Reset" .deprecated in a toctree context */
.toctree-wrapper a.deprecated {
    background: none;
	border: none;
	padding: 0;
}

/* << insert above example CSS here >> */

----

----------
assignee: docs at python
components: Documentation
messages: 209239
nosy: docs at python, zearin
priority: normal
severity: normal
status: open
title: Docs: mark deprecated items in the TOC
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Jan 26 08:35:21 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Jan 2014 07:35:21 +0000
Subject: [New-bugs-announce] [issue20394] Coverity complains on audioop
Message-ID: <1390721721.09.0.648062700512.issue20394@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Christian Heimes reported (http://permalink.gmane.org/gmane.comp.python.devel/145253) Coverity issue:

"""
** CID 1164423:  Division or modulo by zero  (DIVIDE_BY_ZERO)
/Modules/audioop.c: 1375 in audioop_ratecv_impl()


________________________________________________________________________________________________________
*** CID 1164423:  Division or modulo by zero  (DIVIDE_BY_ZERO)
/Modules/audioop.c: 1375 in audioop_ratecv_impl()
1369                without spurious overflow is the challenge; we can
1370                settle for a reasonable upper bound, though, in this
1371                case ceiling(len/inrate) * outrate. */
1372
1373             /* compute ceiling(len/inrate) without overflow */
1374             Py_ssize_t q = len > 0 ? 1 + (len - 1) / inrate : 0;
>>>     CID 1164423:  Division or modulo by zero  (DIVIDE_BY_ZERO)
>>>     In expression "9223372036854775807L / q", division by expression
"q" which may be zero has undefined behavior.
1375             if (outrate > PY_SSIZE_T_MAX / q / bytes_per_frame)
1376                 str = NULL;
1377             else
1378                 str = PyBytes_FromStringAndSize(NULL,
1379                                                 q * outrate *
bytes_per_frame);
1380         }
"""

This is false positive. len should be non-negative and a case of 0 already checked just several lines before.

Is Coverity aware asserts? Perhaps this patch will silence it.

----------
components: Build
files: audioop_ratecv_coverity_silence.patch
keywords: patch
messages: 209284
nosy: christian.heimes, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Coverity complains on audioop
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33718/audioop_ratecv_coverity_silence.patch

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

From report at bugs.python.org  Sun Jan 26 12:05:39 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Jan 2014 11:05:39 +0000
Subject: [New-bugs-announce] [issue20395] Extract generated clinic code in
	Modules/_pickle.c to	separate file
Message-ID: <1390734339.8.0.0968166670001.issue20395@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Argument Clinic had added about half-thousand lines of code to Modules/_pickle.c. This generated code is mixed with handwritten code. Last 8 changes of Modules/_pickle.c are caused by Argument Clinic evolution, and I afraid that many future Argument Clinic changes will change Modules/_pickle.c too.

The proposed patch extracts generated clinic code in separate file to prevent or decrease code churn in future. It decreases the size of Modules/_pickle.c by 450 lines.

----------
files: pickle_clinic.patch
keywords: patch
messages: 209293
nosy: alexandre.vassalotti, larry, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Extract generated clinic code in Modules/_pickle.c to separate file
versions: Python 3.4
Added file: http://bugs.python.org/file33722/pickle_clinic.patch

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

From report at bugs.python.org  Sun Jan 26 15:02:21 2014
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 26 Jan 2014 14:02:21 +0000
Subject: [New-bugs-announce] [issue20396] Argument Clinic: Touch source file
	if any output file	changed
Message-ID: <1390744941.56.0.0539875742197.issue20396@psf.upfronthosting.co.za>


New submission from Larry Hastings:

A minor bug, but still one that could cause confusion.  It's already bitten me once.

If I change the code generator in clinic.py, then --make everything, files using the "file" destination often won't change.  All the changes to the generated code will go in the generated file.  And since the UNIX build process ignores those generated files, it doesn't rebuild the source file.  I'd have to use "--make -f".

This won't just happen to me though.  If you update your trunk and run "make clinic" this could easily happen to you too.

I propose that Clinic handle this as follows: if the generated file changes, but the source file does not, it "touches" the source file.  (Technically I'll probably just rewrite the source file, as I already have code that does that.)

----------
assignee: larry
messages: 209315
nosy: larry, ncoghlan, serhiy.storchaka, zach.ware
priority: low
severity: normal
stage: needs patch
status: open
title: Argument Clinic: Touch source file if any output file changed
type: enhancement

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

From report at bugs.python.org  Sun Jan 26 15:20:14 2014
From: report at bugs.python.org (Marcus von Appen)
Date: Sun, 26 Jan 2014 14:20:14 +0000
Subject: [New-bugs-announce] [issue20397] distutils --record option does not
	validate existance of	byte-compiled files
Message-ID: <1390746014.88.0.900467086198.issue20397@psf.upfronthosting.co.za>


New submission from Marcus von Appen:

Using the --record argument with distutils' install command currently assumes that all .py files can be compiled (and optimized) successfully. 

If this is not the case for whatever reason, you end up with invalid entries in the record list. install_lib._bytecode_filenames() should verify, if the file could be created successfully (by e.g. checking for its existence) or the util.byte_compile() function should return a value that indicates, if the byte-compiled (or optimized) file could be created, so that the subsequent call to _bytecode_filenames() receives a list with valid entries.

The issue can be recreated with e.g. http://pypi.python.org/pypi/Products.PasswordResetTool, which will create invalid entries for skins/PasswordReset/pwreset_constructURL.py,
which acts as template/fragment.

----------
components: Distutils
messages: 209320
nosy: marcusva
priority: normal
severity: normal
status: open
title: distutils --record option does not validate existance of byte-compiled files
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jan 26 16:13:00 2014
From: report at bugs.python.org (lothar)
Date: Sun, 26 Jan 2014 15:13:00 +0000
Subject: [New-bugs-announce] [issue20398] stem crashes python
Message-ID: <1390749180.01.0.603192717521.issue20398@psf.upfronthosting.co.za>


New submission from lothar:

setup: python 3.2 ; cygwin64 

python crashes with a stackdump, which is attached.

stem is a python controller module for tor.

stem-1.1.1 can be had from here:
https://pypi.python.org/pypi/stem/

the code is in version 2 form, but "python3 setup install" runs 2to3 on it.

this code crashes before the for statement:

#! /usr/bin/env python3

import urllib.request
from stem import Signal
from stem.control import Controller

with Controller.from_port(port=9151) as controller:
  controller.signal(Signal.NEWNYM)

for nn in range(1, 3):
  print("case %02d" % nn)
  proxy_support = urllib.request.ProxyHandler({"socks5" : "127.0.0.1:9150"})
  opener = urllib.request.build_opener(proxy_support)
  urllib.request.install_opener(opener)
  print(urllib.request.urlopen("http://www.ifconfig.me/ip").read())

----------
components: Interpreter Core
files: python3.2m.exe.stackdump
messages: 209328
nosy: lothar
priority: normal
severity: normal
status: open
title: stem crashes python
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file33730/python3.2m.exe.stackdump

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

From report at bugs.python.org  Sun Jan 26 21:37:37 2014
From: report at bugs.python.org (fin swimmer)
Date: Sun, 26 Jan 2014 20:37:37 +0000
Subject: [New-bugs-announce] [issue20399] Comparison of memoryview
Message-ID: <1390768657.21.0.774991286622.issue20399@psf.upfronthosting.co.za>


New submission from fin swimmer:

Comparison by using memoryview seems not to work completely.

This works:
>>> memoryview(bytearray(range(5))) != memoryview(bytearray(range(5)))
False
>>> memoryview(bytearray(range(5))) == memoryview(bytearray(range(5)))
True

But:
>>> memoryview(bytearray(range(5))) < memoryview(bytearray(range(5)))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unorderable types: memoryview() < memoryview()

So memoryview cannot be used as a key-value for sorting

----------
components: Library (Lib)
messages: 209351
nosy: fin.swimmer
priority: normal
severity: normal
status: open
title: Comparison of memoryview
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Jan 27 00:40:11 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 26 Jan 2014 23:40:11 +0000
Subject: [New-bugs-announce] [issue20400] Add
	create_read_pipe_protocol/create_write_pipe_protocol	to
	asyncio.SubprocessProtocol
Message-ID: <1390779611.0.0.029550213682.issue20400@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I reported the issue in Tulip project:
http://code.google.com/p/tulip/issues/detail?id=115

I consider this issue as as serious API flaw and I would like to fix it before Python 3.4 final.

----------
messages: 209366
nosy: gvanrossum, haypo, larry
priority: release blocker
severity: normal
status: open
title: Add create_read_pipe_protocol/create_write_pipe_protocol to asyncio.SubprocessProtocol
versions: Python 3.4

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

From report at bugs.python.org  Mon Jan 27 03:16:33 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 27 Jan 2014 02:16:33 +0000
Subject: [New-bugs-announce] [issue20401] inspect.signature removes initial
	starred method params	(bug)
Message-ID: <1390788993.17.0.660022728639.issue20401@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

>>> import inspect
>>> class C:
	def meth(*args): pass
	
>>> str(inspect.signature(C.meth))
'(*args)'
>>> c=C()
>>> str(s=inspect.signature(c.meth))
'()'

*args should have been left in even for the bound method, as idlelib calltips do.
Since '*' is not a word character,
idlelib.Calltips._first_param = re.compile('(?<=\()\w*\,?\s*')
does not see '*args' as a substring to be deleted with
    argspec = _first_param.sub("", argspec)

The same comment applies to
    def meth2(**kwds): pass
even though calling the bound method would fail.

----------
messages: 209378
nosy: terry.reedy, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: inspect.signature removes initial starred method params (bug)
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Jan 27 04:24:16 2014
From: report at bugs.python.org (Rob Lanphier)
Date: Mon, 27 Jan 2014 03:24:16 +0000
Subject: [New-bugs-announce] [issue20402] List comprehensions should be
	noted in for loop	documentation
Message-ID: <1390793056.66.0.0906291243976.issue20402@psf.upfronthosting.co.za>


New submission from Rob Lanphier:

The current list comprehension documentation is difficult to find for someone who doesn't know what a list comprehension is.  Example of this problem:
http://www.reddit.com/r/learnprogramming/comments/1w6slm/different_kind_of_for_loop_python/

Since list comprehensions are a riff off of "for" loop syntax, they should at least be noted and linked to from section 4.2 ("for statements" section) and quite possibly 5.6 ("Looping constructs")

----------
assignee: docs at python
components: Documentation
messages: 209380
nosy: docs at python, robla
priority: normal
severity: normal
status: open
title: List comprehensions should be noted in for loop documentation
type: enhancement

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

From report at bugs.python.org  Mon Jan 27 04:41:27 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 27 Jan 2014 03:41:27 +0000
Subject: [New-bugs-announce] [issue20403] Idle options dialog: add help
Message-ID: <1390794087.42.0.95323934944.issue20403@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

The Idle options/configuration dialog had a useless Help button that did nothing. #17721 commented out the creation and packing of the button. This issue is about making the Help method work. Perhaps it should open the general help document at the options section. Or perhaps this should be a separate file. Once Help() does something, re-enable the 4 disabled lines.

----------
messages: 209383
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle options dialog: add help
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Jan 27 06:01:16 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 27 Jan 2014 05:01:16 +0000
Subject: [New-bugs-announce] [issue20404] Delayed exception using non-text
	encodings with	TextIOWrapper
Message-ID: <1390798876.83.0.936873438895.issue20404@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

TextIOWrapper doesn't check the codec type early the way the convenience methods now do, so the open() method currently still suffers from the problems Victor described in issue 19619 for str.encode() and bytes.decode():

>>> with open("hex.txt", 'w') as f:
...     f.write("aabbccddeeff")
... 
12
>>> print(open('hex.txt').read())
aabbccddeeff
>>> print(open('hex.txt', encoding='hex').read())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: decoder should return a string result, not 'bytes'

These codecs are never going to work correctly with TextIOWrapper, so we should add the appropriate compatibility check in the constructor.

----------
assignee: ncoghlan
messages: 209396
nosy: haypo, larry, ncoghlan, serhiy.storchaka
priority: release blocker
severity: normal
stage: test needed
status: open
title: Delayed exception using non-text encodings with TextIOWrapper
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Jan 27 06:24:39 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 27 Jan 2014 05:24:39 +0000
Subject: [New-bugs-announce] [issue20405] Add io.BinaryTransformWrapper and
	a "transform"	parameter to open()
Message-ID: <1390800279.91.0.834285021962.issue20405@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Issue 20404 points out that io.TextIOWrapper can't be used with binary transform codecs like bz2 because the types are wrong.

By contrast, codecs.open() still defaults to working in binary mode, and just switches to returning a different type based on the specified encoding (exactly the kind of value-driven output type changes we're trying to eliminate from the core text model):

>>> import codecs
>>> print(codecs.open('hex.txt').read())
b'aabbccddeeff'
>>> print(codecs.open('hex.txt', encoding='hex').read())
b'\xaa\xbb\xcc\xdd\xee\xff'
>>> print(codecs.open('hex.txt', encoding='utf-8').read())
aabbccddeeff

While for 3.4, I plan to just extend the issue 19619 blacklist to also cover TextIOWrapper (and hence open()), it seems to me that there is a valid use case for bytes-to-bytes transform support directly in the IO stack.

A PEP for 3.5 could propose:

- providing a public API that allows codecs to be classified into at least the following groups ("binary" = memorview compatible data exporters, including both bytes and bytearray):
  - text encodings (decodes binary to str, encodes str to bytes)
  - binary transforms (decodes *and* encodes binary to bytes)
  - text transforms (decodes and encodes str to str)
  - hybrid transforms (acts as both a binary transform *and* as a text transform)
  - hybrid encodings (decodes binary and potentially str to str, encodes binary and str to bytes)
  - arbitrary encodings (decodes and encodes object to object, without fitting any of the above categories)

- adding io.BinaryTransformWrapper that applies binary transforms when reading and writing data (similar to the way TextIOWrapper applies text encodings)

- adding a "transform" parameter to open that inserts BinaryTransformWrapper into the stack at the appropriate place (the PEP process would need to decide between supporting just a single transform per stream or multiple). In text mode, TextIOWrapper would be added to the stack after any binary transforms.

Optionally, the idea could also be extended to adding io.TextTransformWrapper and a "text_transform" parameter, but those seem somewhat less useful.

----------
components: IO, Interpreter Core, Library (Lib)
messages: 209398
nosy: benjamin.peterson, ezio.melotti, haypo, hynek, lemburg, ncoghlan, pitrou, serhiy.storchaka, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: Add io.BinaryTransformWrapper and a "transform" parameter to open()
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Jan 27 11:08:10 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 27 Jan 2014 10:08:10 +0000
Subject: [New-bugs-announce] [issue20406] Use application icon for IDLE
Message-ID: <1390817290.68.0.153594821127.issue20406@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently IDLE use default Tk icon. The proposed patch sets special application icon for IDLE.

----------
components: IDLE
files: idle_appicon.patch
keywords: patch
messages: 209428
nosy: kbk, roger.serwy, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Use application icon for IDLE
type: enhancement
Added file: http://bugs.python.org/file33745/idle_appicon.patch

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

From report at bugs.python.org  Mon Jan 27 12:51:33 2014
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 27 Jan 2014 11:51:33 +0000
Subject: [New-bugs-announce] [issue20407] heapq.nsmallest and heapq.nlargest
	don't accept a "key"	parameter
Message-ID: <1390823493.04.0.65431780694.issue20407@psf.upfronthosting.co.za>


New submission from Larry Hastings:

The documentation for heapq.nsmallest and heapq.nlargest:

http://docs.python.org/3.3/library/heapq.html#heapq.nlargest

claim that they accept three arguments: n, iterable, and key=None.  In fact, the implementations of both these functions only accept two parameters: n and iterable.

I assume the right thing to do here is to remove the erroneous documentation, rather than implement this apparently-not-needed feature?

----------
components: Library (Lib)
messages: 209435
nosy: larry
priority: low
severity: normal
stage: needs patch
status: open
title: heapq.nsmallest and heapq.nlargest don't accept a "key" parameter
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Jan 27 12:53:11 2014
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 27 Jan 2014 11:53:11 +0000
Subject: [New-bugs-announce] [issue20408] memoryview() constructor
	documentation error
Message-ID: <1390823591.54.0.904712473888.issue20408@psf.upfronthosting.co.za>


New submission from Larry Hastings:

The documentation for the memoryview constructor says it takes memoryview(obj).  Oddly, memoryview accepts keyword arguments (for its one required value), and the name of the argument is "object", not "obj".

----------
messages: 209436
nosy: georg.brandl, larry
priority: low
severity: normal
stage: needs patch
status: open
title: memoryview() constructor documentation error
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Jan 27 18:11:38 2014
From: report at bugs.python.org (Xiaoqing Rong)
Date: Mon, 27 Jan 2014 17:11:38 +0000
Subject: [New-bugs-announce] [issue20409] .readline() returned garble text
Message-ID: <1390842698.27.0.934297855762.issue20409@psf.upfronthosting.co.za>


New submission from Xiaoqing Rong:

I'm using Windows 8. I created file 'weird1.txt' (attached) from an Excel worksheet using "save as Unicode Text (*.txt)". And this happened when I used Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:19:30) [MSC v.1600 64 bit (AMD64)] on win32:

>>> handle = open('weird1.txt'); handle.readline()
'??>\x00P\x006\x004\x00;\x00Y\x00A\x00L\x000\x000\x001\x00C\x00;\x00T\x00F\x00C\x003\x00;\x00 \x00S\x00G\x00D\x00I\x00D\x00:\x00S\x000\x000\x000\x000\x000\x000\x000\x000\x001\x00,\x00 \x00C\x00h\x00r\x00 \x00I\x00 \x00f\x00r\x00o\x00m\x00 \x001\x005\x001\x000\x000\x006\x00-\x001\x004\x007\x005\x009\x004\x00,\x001\x005\x001\x001\x006\x006\x00-\x001\x005\x001\x000\x009\x007\x00,\x00 \x00r\x00e\x00v\x00e\x00r\x00s\x00e\x00 \x00c\x00o\x00m\x00p\x00l\x00e\x00m\x00e\x00n\x00t\x00,\x00 \x00V\x00e\x00r\x00i\x00f\x00i\x00e\x00d\x00 \x00O\x00R\x00F\x00,\x00 \x00"\x00L\x00a\x00r\x00g\x00e\x00s\x00t\x00 \x00o\x00f\x00 \x00s\x00i\x00x\x00 \x00s\x00u\x00b\x00u\x00n\x00i\x00t\x00s\x00 \x00o\x00f\x00 \x00t\x00h\x00e\x00 \x00R\x00N\x00A\x00 \x00p\x00o\x00l\x00y\x00m\x00e\x00r\x00a\x00s\x00e\x00 \x00I\x00I\x00I\x00 \x00t\x00r\x00a\x00n\x00s\x00c\x00r\x00i\x00p\x00t\x00i\x00o\x00n\x00 \x00i\x00n\x00i\x00t\x00i\x00a\x00t\x00i\x00o\x00n\x00 \x00f\x00a\x00c\x00t\x00o\x00r\x00 \x00c\x00o\x00m\x00p\x00l\x00e\x00x\x00 \x00(\x00T\x00F\x00I\x00I\x00I\x00C\x00)\x00;\x00 \x00p\x00a\x00r\x00t\x00 \x00o\x00f\x00 \x00t\x00h\x00e\x00 \x00T\x00a\x00u\x00B\x00 \x00d\x00o\x00m\x00a\x00i\x00n\x00 \x00o\x00f\x00 \x00T\x00F\x00I\x00I\x00I\x00C\x00 \x00t\x00h\x00a\x00t\x00 \x00b\x00i\x00n\x00d\x00s\x00 \x00D\x00N\x00A\x00 \x00a\x00t\x00 \x00t\x00h\x00e\x00 \x00B\x00o\x00x\x00B\x00 \x00p\x00r\x00o\x00m\x00o\x00t\x00e\x00r\x00 \x00s\x00i\x00t\x00e\x00s\x00 \x00o\x00f\x00 \x00t\x00R\x00N\x00A\x00 \x00a\x00n\x00d\x00 \x00s\x00i\x00m\x00i\x00l\x00a\x00r\x00 \x00g\x00e\x00n\x00e\x00s\x00;\x00 \x00c\x00o\x00o\x00p\x00e\x00\n'

Then I opened 'weird1.txt' in Notepad++ 6.5.2, created file 'weird2.txt' by copying the whole content of 'weird1.txt' into a new file and saved it in Notepad++ 6.5.2 (I wanted to attach 'weird2.txt' but only one attachment is allowed), and this happened:

>>> handle = open('weird2.txt'); handle.readline()
'>P64;YAL001C;TFC3; SGDID:S000000001, Chr I from 151006-147594,151166-151097, reverse complement, Verified ORF, "Largest of six subunits of the RNA polymerase III transcription initiation factor complex (TFIIIC); part of the TauB domain of TFIIIC that binds DNA at the BoxB promoter sites of tRNA and similar genes; coope\n'

I can't see any difference between the contents of 'weird1.txt' and 'weird2.txt' using Notepad++ or the Windows Notepad. Maybe some experts could tell me what's going on here?

----------
components: IDLE
files: weird1.txt
messages: 209452
nosy: m123orning
priority: normal
severity: normal
status: open
title: .readline() returned garble text
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file33750/weird1.txt

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

From report at bugs.python.org  Mon Jan 27 19:30:18 2014
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Jan 2014 18:30:18 +0000
Subject: [New-bugs-announce] [issue20410] Argument Clinic: add 'self' return
	converter
Message-ID: <1390847418.07.0.605398644696.issue20410@psf.upfronthosting.co.za>


New submission from Zachary Ware:

It would be nice to have a 'self' return converter for simple functions like winreg.HKEYType.__enter__ (which is implemented as "Py_XINCREF(self); return self;").  With the typedef and type_object specifications now required for the class directive, 'self' is passed to that function as a PyHKEYObject *, but impl is expected to return a PyObject *.

In this particular instance, I can solve the problem (which is a compiler warning) with a custom self_return_converter that casts _return_value to PyObject *.  I think a generic solution would be better in the long run and useful in more places, though.

----------
messages: 209457
nosy: larry, zach.ware
priority: low
severity: normal
stage: needs patch
status: open
title: Argument Clinic: add 'self' return converter
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Jan 27 21:12:12 2014
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 27 Jan 2014 20:12:12 +0000
Subject: [New-bugs-announce] [issue20411] IndexError in
	sys.__interactivehook__ with pyreadline	installed
Message-ID: <1390853532.56.0.555307973012.issue20411@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

Following the blame history, this appears to be new issue following issue5845.

I'm using Python 3.4b2 64-bit on Windows. I've installed pyreadline 2.0 using Setuptools 2.1. Now, when I start the interactive interpreter, I get this output:

> python
Python 3.4.0b2 (v3.4.0b2:ba32913eb13e, Jan  5 2014, 16:13:26) [MSC v.1600 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
Failed calling sys.__interactivehook__
Traceback (most recent call last):
  File "c:\python\lib\site.py", line 412, in register_readline
    if readline.get_history_item(1) is None:
  File "c:\python\lib\site-packages\pyreadline-2.0-py3.4-win-amd64.egg\pyreadline\rlmain.py", line 154, in get_history_item
  File "c:\python\lib\site-packages\pyreadline-2.0-py3.4-win-amd64.egg\pyreadline\lineeditor\history.py", line 52, in get_history_item
IndexError: list index out of range

It seems I don't yet have any history, and it seems that site.py is expecting get_history_item() to return None when no history is present, but the pyreadline 2.0 implementation does no such thing, but instead tries to index the history array directly, causing the IndexError.

----------
components: Library (Lib)
messages: 209471
nosy: jason.coombs
priority: normal
severity: normal
status: open
title: IndexError in sys.__interactivehook__ with pyreadline installed
versions: Python 3.4

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

From report at bugs.python.org  Mon Jan 27 21:37:46 2014
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 27 Jan 2014 20:37:46 +0000
Subject: [New-bugs-announce] [issue20412] Enum and IntEnum classes are not
	defined in the	documentation
Message-ID: <1390855066.21.0.631218831969.issue20412@psf.upfronthosting.co.za>


New submission from Ethan Furman:

While trying to update the socket documentation it was brought to my attention that Enum and IntEnum are not defined as classes as far as the docs are concerned [1].

[1] http://bugs.python.org/issue20386#msg209473

----------
assignee: ethan.furman
messages: 209476
nosy: ethan.furman
priority: normal
severity: normal
status: open
title: Enum and IntEnum classes are not defined in the documentation
versions: Python 3.4

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

From report at bugs.python.org  Mon Jan 27 21:41:06 2014
From: report at bugs.python.org (RalfM)
Date: Mon, 27 Jan 2014 20:41:06 +0000
Subject: [New-bugs-announce] [issue20413] Errors in documentation of
	standard codec error handlers
Message-ID: <1390855266.06.0.0688884977578.issue20413@psf.upfronthosting.co.za>


New submission from RalfM:

The standard library documentation lists the standard codec error handlers in three places:

(a) 2. Build-in Functions, section open()
(b) 7.2 codecs - Codec registry and base classes
(c) 7.2.1 Codec Base Classes

As far as I can judge these lists, (c) looks ok, but (a) and (b) contain two errors:
1. 'surrogatepass' is not mentioned.
2. 'surrogateescape' is described as: 
   'on decoding, replace with code points in the Unicode Private
   Use Area ranging from U+DC80 to U+DCFF. These private code points
   will ...' 
   This is incorrect in so far as U+DC80 to U+DCFF are not private 
   code points, but (low-)surrogate code points. This is correctly
   explained in (c) and in PEP383 (and, of course, in the Unicode 
   standard, chapter 16).

I suggest to correct (a) and (b) by
* adding 'surrogatepass' with the description given in (c),
* changing the description of 'surrogateescape' to something like: 
  'on decoding, replace with surrogate code points ranging from 
  U+DC80 to U+DCFF. These surrogate code points will ...'.

These errors are present in the documentation (more precisely, the .chm files) of at least 
- Python 3.3.3
- Python 3.3.4rc1
- Python 3.4.0b3.

----------
assignee: docs at python
components: Documentation
messages: 209477
nosy: RalfM, docs at python
priority: normal
severity: normal
status: open
title: Errors in documentation of standard codec error handlers
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Jan 28 02:51:53 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Jan 2014 01:51:53 +0000
Subject: [New-bugs-announce] [issue20414] Python 3.4 has two Overlapped types
Message-ID: <1390873913.58.0.40789965238.issue20414@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Python 3.3 has _winapi.Overlapped. Python 3.4 _winapi.Overlapped but also _overlapped.Overlapped. Why do we have two implementations?

Most code looks to be duplicated.

----------
components: Windows
messages: 209496
nosy: gvanrossum, haypo, pitrou, sbt
priority: normal
severity: normal
status: open
title: Python 3.4 has two Overlapped types
versions: Python 3.4

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

From report at bugs.python.org  Tue Jan 28 10:27:54 2014
From: report at bugs.python.org (Chen ZHANG)
Date: Tue, 28 Jan 2014 09:27:54 +0000
Subject: [New-bugs-announce] [issue20415] Could method "isinstance" take a
	list as parameter?
Message-ID: <1390901274.15.0.0556662587348.issue20415@psf.upfronthosting.co.za>


New submission from Chen ZHANG:

Since the usage of isinstance could be "isinstance(1, (int, float))", I'm wondering why it doesn't accept "[int, float]", if I do so, it would raise TypeError saying "arg 2 must be a type or tuple of types". What's the difference in effect between a tuple and a list here? (I know a tuple is immutable, but I think it doesn't matter when passing some other types of non-string iterables(yielding strings), am I right?

----------
components: Library (Lib)
messages: 209519
nosy: Chen.ZHANG
priority: normal
severity: normal
status: open
title: Could method "isinstance" take a list as parameter?
type: enhancement

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

From report at bugs.python.org  Tue Jan 28 11:10:48 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Jan 2014 10:10:48 +0000
Subject: [New-bugs-announce] [issue20416] Marshal: special case int and
	float, don't use references
Message-ID: <1390903848.78.0.660754858197.issue20416@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patched disables references for int and float types.

----------
files: marshal3_numbers.patch
keywords: patch
messages: 209524
nosy: haypo
priority: normal
severity: normal
status: open
title: Marshal: special case int and float, don't use references
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file33770/marshal3_numbers.patch

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

From report at bugs.python.org  Tue Jan 28 12:54:41 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 28 Jan 2014 11:54:41 +0000
Subject: [New-bugs-announce] [issue20417] ensurepip should not be installed
	with	--without-ensurepip
Message-ID: <1390910081.3.0.794745591099.issue20417@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

ensurepip should not be installed when --without-ensurepip was passed to configure.
I attach the patch.

----------
assignee: dstufft
components: Installation
files: ensurepip_installation.patch
keywords: patch
messages: 209536
nosy: Arfrever, dstufft
priority: normal
severity: normal
stage: patch review
status: open
title: ensurepip should not be installed with --without-ensurepip
versions: Python 3.4
Added file: http://bugs.python.org/file33772/ensurepip_installation.patch

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

From report at bugs.python.org  Tue Jan 28 13:43:06 2014
From: report at bugs.python.org (ariel-wikimedia)
Date: Tue, 28 Jan 2014 12:43:06 +0000
Subject: [New-bugs-announce] [issue20418] socket.getaddrinfo fails for
	hostname that is all digits	0-9
Message-ID: <1390912986.46.0.278419787469.issue20418@psf.upfronthosting.co.za>


New submission from ariel-wikimedia:

With python 2.7.5 (running on fedora 20 with all updates), socket.getaddrinfo for a hostname such as 836937931829 will fail.  Docker produces these sorts of hostnames (really random hex strings, but some hex strings only contain digits 0-9).

How to reproduce:

Add the lines

172.17.10.53    blobber
172.17.10.54    836937931829

to /etc/hosts

run the following:

import socket
print socket.getaddrinfo('172.17.10.53',80,socket.AF_INET,0,socket.SOL_TCP)
print socket.getaddrinfo('blobber',80,socket.AF_INET,0,socket.SOL_TCP)
print socket.getaddrinfo('172.17.10.54',80,socket.AF_INET,0,socket.SOL_TCP)
print socket.getaddrinfo('836937931829',80,socket.AF_INET,0,socket.SOL_TCP)

Expected output:
[(2, 1, 6, '', ('172.17.10.53', 80))]
[(2, 1, 6, '', ('172.17.10.53', 80))]
[(2, 1, 6, '', ('172.17.10.54', 80))]
[(2, 1, 6, '', ('172.17.10.54', 80))]

Actual output:
[(2, 1, 6, '', ('172.17.10.53', 80))]
[(2, 1, 6, '', ('172.17.10.53', 80))]
[(2, 1, 6, '', ('172.17.10.54', 80))]
Traceback (most recent call last):
  File "./test-getaddrinfo.py", line 6, in <module>
    print socket.getaddrinfo('836937931829',80,socket.AF_INET,0,socket.SOL_TCP)
socket.gaierror: [Errno -2] Name or service not known

----------
components: Library (Lib)
messages: 209539
nosy: ariel-wikimedia
priority: normal
severity: normal
status: open
title: socket.getaddrinfo fails for hostname that is all digits 0-9
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jan 28 17:25:16 2014
From: report at bugs.python.org (Michael Gubser)
Date: Tue, 28 Jan 2014 16:25:16 +0000
Subject: [New-bugs-announce] [issue20419] it's not possible to set ECDH
	curve name via	ssl.wrap_socket
Message-ID: <1390926316.58.0.114750274783.issue20419@psf.upfronthosting.co.za>


New submission from Michael Gubser:

One can only set the ECDH curve name via SSLContext.set_ecdh_curve(). ssl.wrap_socket() doesn't have a parameter to use it for the wrapping of the basic socket. Therefore one always has to do the detour over SSLContext.

----------
components: Library (Lib)
messages: 209561
nosy: Michael.Gubser
priority: normal
severity: normal
status: open
title: it's not possible to set ECDH curve name via ssl.wrap_socket
versions: Python 3.3

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

From report at bugs.python.org  Tue Jan 28 17:34:45 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Jan 2014 16:34:45 +0000
Subject: [New-bugs-announce] [issue20420] BufferedIncrementalEncoder
	violates IncrementalEncoder	interface
Message-ID: <1390926885.67.0.351173619746.issue20420@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The documentation of IncrementalEncoder.getstate() says:

"""
Return the current state of the encoder which must be an integer. The implementation should make sure that 0 is the most common state. (States that are more complicated than integers can be converted into an integer by marshaling/pickling the state and encoding the bytes of the resulting string into an integer).
"""

But implementation of BufferedIncrementalEncoder.getstate() is

    def getstate(self):
        return self.buffer or 0

self.buffer is "unencoded input that is kept between calls to encode()", e.g. a string.

----------
messages: 209563
nosy: doerwalter, lemburg, loewis, serhiy.storchaka
priority: normal
severity: normal
status: open
title: BufferedIncrementalEncoder violates IncrementalEncoder interface
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Jan 28 17:36:54 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Jan 2014 16:36:54 +0000
Subject: [New-bugs-announce] [issue20421] expose SSL socket protocol version
Message-ID: <1390927014.41.0.169425093715.issue20421@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

SSL sockets should provide a way to query the current protocol version (e.g. "TLSv1.2"). OpenSSL makes it easy through SSL_get_version().

Open question is whether we return the string returned by SSL_get_version(), or we convert it to one of the constants ssl.PROTOCOL_XXX.

----------
components: Library (Lib)
messages: 209564
nosy: christian.heimes, giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: expose SSL socket protocol version
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Jan 28 18:00:19 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 28 Jan 2014 17:00:19 +0000
Subject: [New-bugs-announce] [issue20422] Signature.from_builtin should
	raise a ValueError when no	signature can be provided
Message-ID: <1390928419.89.0.493774550745.issue20422@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

Right now it may return `None` if no signature can be returned for the given builtin. If we decide to implement #17373 in 3.5, I'd like all three methods -- from_builtin, from_function, from_callable -- to either return a signature or to raise an exception.

----------
messages: 209565
nosy: brett.cannon, larry, ncoghlan, yselivanov
priority: normal
severity: normal
status: open
title: Signature.from_builtin should raise a ValueError when no signature can be provided
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Jan 28 20:24:38 2014
From: report at bugs.python.org (couplewavylines)
Date: Tue, 28 Jan 2014 19:24:38 +0000
Subject: [New-bugs-announce] [issue20423] io.StringIO newline param has
	wrong default
Message-ID: <1390937078.16.0.885697814935.issue20423@psf.upfronthosting.co.za>


New submission from couplewavylines:

In io.StringIO, the newline argument's default is currently documented as "newline=None" in the section header. However, it's described this way:  "The default is to do no newline translation."  The behavior of io.StringIO is consistent with this description (NO newline translation). 
The header should actually read "newline=''".
"newline=None" would mean there IS newline translation by default, which is not the case. Code sample attached as no_translation.py.

----------
assignee: docs at python
components: Documentation
files: no_translation.py
messages: 209577
nosy: couplewavylines, docs at python
priority: normal
severity: normal
status: open
title: io.StringIO newline param has wrong default
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33779/no_translation.py

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

From report at bugs.python.org  Tue Jan 28 21:26:55 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Jan 2014 20:26:55 +0000
Subject: [New-bugs-announce] [issue20424] _pyio.StringIO doesn't work with
	lone surrogates
Message-ID: <1390940815.88.0.957874925248.issue20424@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Unlike to io.StringIO, _pyio.StringIO doesn't work with lone surrogates.

>>> import io, _pyio
>>> io.StringIO('\ud880')
<_io.StringIO object at 0xb71426ec>
>>> _pyio.StringIO('\ud880')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/_pyio.py", line 2065, in __init__
    self.write(initial_value)
  File "/home/serhiy/py/cpython/Lib/_pyio.py", line 1629, in write
    b = encoder.encode(s)
  File "/home/serhiy/py/cpython/Lib/encodings/utf_8.py", line 20, in encode
    return codecs.utf_8_encode(input, self.errors)[0]
UnicodeEncodeError: 'utf-8' codec can't encode character '\ud880' in position 0: surrogates not allowed

Proposed patch adds support of lone surrogates to _pyio.StringIO.

----------
components: IO, Unicode
files: stringio_lone_surrogates.patch
keywords: patch
messages: 209583
nosy: benjamin.peterson, ezio.melotti, haypo, hynek, pitrou, serhiy.storchaka, stutzbach
priority: normal
severity: normal
stage: patch review
status: open
title: _pyio.StringIO doesn't work with lone surrogates
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33781/stringio_lone_surrogates.patch

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

From report at bugs.python.org  Tue Jan 28 22:04:52 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 28 Jan 2014 21:04:52 +0000
Subject: [New-bugs-announce] [issue20425] inspect.Signature should work on
	decorated builtins
Message-ID: <1390943092.94.0.962174944377.issue20425@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

inspect.signature should work with decorated builtins. Suppose I want to create a cached version of 'min' builtin:

   cached_min = functools.lru_cache()(min)

The signature of the 'cached_min' should match the signature of 'min'.

The patch is attached.

----------
assignee: yselivanov
files: decorated_builtins_01.patch
keywords: patch
messages: 209585
nosy: brett.cannon, larry, ncoghlan, yselivanov
priority: high
severity: normal
stage: patch review
status: open
title: inspect.Signature should work on decorated builtins
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33783/decorated_builtins_01.patch

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

From report at bugs.python.org  Tue Jan 28 23:09:38 2014
From: report at bugs.python.org (leewz)
Date: Tue, 28 Jan 2014 22:09:38 +0000
Subject: [New-bugs-announce] [issue20426] Compiling a regex with re.DEBUG
	should force a recompile
Message-ID: <1390946978.37.0.473480948512.issue20426@psf.upfronthosting.co.za>


New submission from leewz:

Compiling a regex with the `re.DEBUG` flag indicates that the user wants to see the debug output. `re.compile` is cached, though, so there is the possibility of no output.

Example:
import re
re.compile('1',re.DEBUG) #expected output
re.compile('1',re.DEBUG) #no output
re.compile('',re.DEBUG)  #no output (empty regex)

The workaround is to call `re.purge()`, which may remove other cached regexes that are still in use.

(Background: I wanted to check for equivalence of regexes, and a StackOverflow answer suggested comparing their `re.DEBUG`. http://stackoverflow.com/a/21398362/2963903)

----------
components: Regular Expressions
messages: 209595
nosy: ezio.melotti, leewz, mrabarnett
priority: normal
severity: normal
status: open
title: Compiling a regex with re.DEBUG should force a recompile
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Jan 29 00:01:06 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 28 Jan 2014 23:01:06 +0000
Subject: [New-bugs-announce] [issue20427] inspect.Signature should ensure
	that non-default params	don't follow default ones
Message-ID: <1390950066.9.0.564159460442.issue20427@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

Right now it's possible to manually create signatures like "(a=1, b)". Patch is attached.

----------
assignee: yselivanov
files: sig_validation_01.patch
keywords: needs review, patch
messages: 209598
nosy: brett.cannon, larry, ncoghlan, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: inspect.Signature should ensure that non-default params don't follow default ones
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file33785/sig_validation_01.patch

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

From report at bugs.python.org  Wed Jan 29 00:45:30 2014
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 28 Jan 2014 23:45:30 +0000
Subject: [New-bugs-announce] [issue20428] _Py_open does not work with O_CREAT
Message-ID: <1390952730.76.0.147272441759.issue20428@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti:

The _Py_open function in Python/fileutils.c cannot be given correctly the flag O_CREAT. According to the POSIX spec, open(2) _must_ be given an additional mode argument when O_CREAT is used.

_Py_open should be fixed to either to use a reasonable default value for the mode argument (e.g., O666) or to refuse the O_CREAT flag.

----------
components: Interpreter Core
messages: 209600
nosy: alexandre.vassalotti, haypo
priority: normal
severity: normal
stage: needs patch
status: open
title: _Py_open does not work with O_CREAT
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan 29 01:19:01 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 29 Jan 2014 00:19:01 +0000
Subject: [New-bugs-announce] [issue20429] 3.3.4rc1 install deleted Windows
	taskbar icons
Message-ID: <1390954741.59.0.823038471265.issue20429@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

When I installed 3.3.4rc1, it unpinned all the icons from my Win 7 taskbar. Since I have about 15, is took several minutes to recreate by setup. Unless this is a unique glitch, this should be a release blocker until fixed.

This happened after the install paused because 3.3.3 was running. After I closed that, it paused for an 'application' it called '3330'. I have seen this 'name' before, but I have no idea what it refers to. With task manager, I deleted one conhost process (there were about 10, and 10 of some other process), then thought better of continuing along that line, and clicked [Retry]. All icons for closed programs immediately disappeared. When I rebooted to see if the deletion was permanent, the rest were gone.

----------
components: Installation, Windows
messages: 209605
nosy: georg.brandl, loewis, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: 3.3.4rc1 install deleted Windows taskbar icons
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Jan 29 03:52:34 2014
From: report at bugs.python.org (jzwinck)
Date: Wed, 29 Jan 2014 02:52:34 +0000
Subject: [New-bugs-announce] [issue20430] argparse.SUPPRESS
Message-ID: <1390963954.16.0.426686215118.issue20430@psf.upfronthosting.co.za>


New submission from jzwinck:

argparse.SUPPRESS is a special object which can be used in various parts of argparse to say "do nothing."  One place where it does not seem to work is in an argument's "dest".  This is despite some of the plumbing using "dest=SUPPRESS" internally.  It can be made to work by patching argparse._StoreAction.__call__, like this:

 def __call__(self, parser, namespace, values, option_string=None):
-    setattr(namespace, self.dest, values)
+    if self.dest is not argparse.SUPPRESS:
+        setattr(namespace, self.dest, values)

Once that's done, this works as one might expect:

parser.add_argument('--foo', dest=argparse.SUPPRESS)

With the patch, 'foo' will not appear if you parse args containing "--foo bar".  Without the patch, args looks like this, which is not really useful:

Namespace(==SUPPRESS==='bar')

Note that the _SubParsersAction.__call__ code has something like the above patch already.

----------
components: Library (Lib)
messages: 209611
nosy: jzwinck
priority: normal
severity: normal
status: open
title: argparse.SUPPRESS
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Jan 29 04:48:20 2014
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 29 Jan 2014 03:48:20 +0000
Subject: [New-bugs-announce] [issue20431] Should posix functions that accept
	fd also accept	objects with .fileno()?
Message-ID: <1390967300.86.0.244728862469.issue20431@psf.upfronthosting.co.za>


New submission from Larry Hastings:

While working on posixmodule.c today I noticed that some functions that accept file descriptors call PyObject_AsFileDescriptor().  This function accepts ints.  It *also* accepts objects that expose a .fileno() attribute, calling that attribute and using the integer it returns.

There are *other* functions in posixmodule.c that accept file descriptors that call _fd_converter(), which just looks for an int with a proper value.

I figure it should be one way or the other.  Should everything in posix that accepts file descriptor ints accept the .fileno() convention too?

----------
messages: 209613
nosy: larry
priority: low
severity: normal
stage: needs patch
status: open
title: Should posix functions that accept fd also accept objects with .fileno()?
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Jan 29 06:26:03 2014
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 29 Jan 2014 05:26:03 +0000
Subject: [New-bugs-announce] [issue20432] Argument Clinic: when cloning
	functions with path_t, path_t retains the old name
Message-ID: <1390973163.52.0.0655010569883.issue20432@psf.upfronthosting.co.za>


New submission from Larry Hastings:

If you have:

    module.f1
       path: path_t

    ...

    module.f2 = module.f1

Then the initializer for "path" in module_f2 will supply "f1" as the function name for error messages.

----------
assignee: larry
messages: 209615
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Argument Clinic: when cloning functions with path_t, path_t retains the old name
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan 29 08:42:35 2014
From: report at bugs.python.org (Shriramana Sharma)
Date: Wed, 29 Jan 2014 07:42:35 +0000
Subject: [New-bugs-announce] [issue20433] add aliasedname() and
	namedaliases() methods to	unicodedata module
Message-ID: <1390981355.06.0.989685125573.issue20433@psf.upfronthosting.co.za>


New submission from Shriramana Sharma:

Currently we have unicodedata.name() which returns the formal character name of the character chr as per the second column in UnicodeData.txt from http://www.unicode.org/Public/UNIDATA/.

However, there are a few characters where the formal character name has spelling mistakes. Also, the control characters in the Basic Latin and Latin-1 blocks aren't really given meaningful character names. In one case, that of FEFF, the formal name ZERO WIDTH NO-BREAK SPACE refers to a deprecated usage of the character (and the alternate name BYTE ORDER MARK refers to the recommended usage).

In all these cases, improved names are provided as stable aliases in NameAliases.txt from the same UNIDATA source. These are also part of the stable standard and are intended to alleviate the naming situation w.r.t. the above issues. For the stability, see: http://www.unicode.org/policies/stability_policy.html#Formal_Name_Alias

Hence it would be most useful if the unicodedata module would add an aliasedname() method with the same signature as name() to provide the official aliased name in the case of characters with aliases, and when a character does not have an alias, to provide the same output as name().

As of Py 3.3, unicodedata.lookup() already uses/supports NameAliases.txt for returning the character given the name. The present requirement is to use it for returning the name given the character.

Note that NameAliases.txt has abbreviated names for some characters (where the third column reads "abbreviation"). While these would be useful for lookup(), they would not be useful to be returned for aliasedname(). For instance, one would prefer to see "SPACE" returned for 0020 rather than "SP". So these entries should be disregarded for aliasedname().

Also, NameAliases.txt has multiple entries for some characters even after discarding the abbreviation entries. In these cases, the first entry should be used (for want of a better rule). It is presumed that these are provided in some order of preference.

It should be noted that discussion on this topic on the "unicore" (Unicode members) mailing list (on the thread "When normative aliases exist..." started 2014-01-21) indicates that the order of entries is subject to change although the entries themselves will not be removed. In this case, the first non-abbreviation entry may change. This is acceptable for the behaviour of aliasedname(). Also note that aliases may be defined in future. Thus the string returned by aliasedname() for a given character is not guaranteed to be the same, but whatever is returned by it will surely be valid to use with lookup(). Those who desire a single immutable name and do not require the improvements provided by the aliases should use name() and not aliasedname().

Finally, for extended support, a namealiases() function should return all the aliases together with their types, allowing the user full choice of the desired but official alias.

The attached code should clarify the required behaviour. (It is not a patch, just an illustration.)

----------
components: Unicode
files: aliasedname.py
messages: 209618
nosy: ezio.melotti, haypo, jamadagni
priority: normal
severity: normal
status: open
title: add aliasedname() and namedaliases() methods to unicodedata module
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file33788/aliasedname.py

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

From report at bugs.python.org  Wed Jan 29 09:36:40 2014
From: report at bugs.python.org (Vladimir Kerimov)
Date: Wed, 29 Jan 2014 08:36:40 +0000
Subject: [New-bugs-announce] [issue20434] Process crashes if not enough
	memory to import module
Message-ID: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za>


New submission from Vladimir Kerimov:

In the file _io\fileio.c in function 

static PyObject *
fileio_readall(fileio *self)

this code is incorrect and crashes the process of Python:

 if (_PyBytes_Resize(&result, newsize) < 0) {
                if (total == 0) {
                    Py_DECREF(result);
                    return NULL;
                }
                PyErr_Clear();
                break;
            }

In the call of _PyBytes_Resize there the result variable passed by reference and changes value to NULL-pointer when function fails and return < 0. So on the line Py_DECREF(result); the Python process crashes.

----------
components: Interpreter Core
messages: 209624
nosy: asvetlov, qualab
priority: normal
severity: normal
status: open
title: Process crashes if not enough memory to import module
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Wed Jan 29 10:16:06 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 29 Jan 2014 09:16:06 +0000
Subject: [New-bugs-announce] [issue20435] Discrepancy between io.StringIO
	and _pyio.StringIO with	univeral newlines
Message-ID: <1390986966.7.0.159416133233.issue20435@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

>>> import io, _pyio
>>> io.StringIO('a\nb\r\nc\rd', newline=None)
<_io.StringIO object at 0xb707c734>
>>> io.StringIO('a\nb\r\nc\rd', newline=None).getvalue()
'a\nb\nc\nd'
>>> _pyio.StringIO('a\nb\r\nc\rd', newline=None).getvalue()
'a\nb\r\nc\rd'
>>> s = io.StringIO(newline=None); s.write('a\nb\r\nc\rd'); s.getvalue()
8
'a\nb\nc\nd'
>>> s = _pyio.StringIO(newline=None); s.write('a\nb\r\nc\rd'); s.getvalue()
8
'a\nb\r\nc\rd'

----------
components: IO
messages: 209625
nosy: benjamin.peterson, hynek, pitrou, serhiy.storchaka, stutzbach
priority: normal
severity: normal
status: open
title: Discrepancy between io.StringIO and _pyio.StringIO with univeral newlines
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Jan 29 11:03:11 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 29 Jan 2014 10:03:11 +0000
Subject: [New-bugs-announce] [issue20436] test.regrtest is no more
	importable in 2.7
Message-ID: <1390989791.92.0.676223398517.issue20436@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

$ ./python -m test.regrtest
/home/serhiy/py/cpython-2.7/python: No module named test.regrtest

It worked several days ago.

----------
components: Tests
messages: 209630
nosy: ezio.melotti, michael.foord, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: test.regrtest is no more importable in 2.7
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Jan 29 14:49:54 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 29 Jan 2014 13:49:54 +0000
Subject: [New-bugs-announce] [issue20437] Use Py_CLEAR to safe clear
	attributes
Message-ID: <1391003394.34.0.16321379297.issue20437@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Some time ago Victor proposed in issue16445 a large patch (275 changes) which replaces "Py_DECREF(expr); expr = NULL;" to safer "Py_CLEAR(expr);". That patch contained was so large because it included cases where expr is just a local variable, which are safe in general.

Here are much simpler patches which make replacements only for complex expressions.

These patches (as Victor patch) are generated automatically by the Coccinelle tool (http://coccinelle.lip6.fr/).

----------
components: Extension Modules, Interpreter Core
files: py_clear.spatch
messages: 209640
nosy: asvetlov, haypo, serhiy.storchaka, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Use Py_CLEAR to safe clear attributes
type: crash
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33793/py_clear.spatch

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

From report at bugs.python.org  Wed Jan 29 18:00:13 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 29 Jan 2014 17:00:13 +0000
Subject: [New-bugs-announce] [issue20438] inspect: Deprecate getfullargspec?
Message-ID: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

Should we finally deprecate getfullargspec? With the AC and positional-only parameters support, getfullargspec doesn't provide full information anymore.

By deprecation I mean changing its existing note "Consider using the new Signature Object interface, which provides a better way of introspecting functions." to "Deprecated since version 3.4: Use inspect.signature() instead".

----------
messages: 209658
nosy: brett.cannon, larry, ncoghlan, yselivanov
priority: normal
severity: normal
status: open
title: inspect: Deprecate getfullargspec?
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan 29 18:30:33 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 29 Jan 2014 17:30:33 +0000
Subject: [New-bugs-announce] [issue20439] inspect.Signature: Add
	Signature.format method to match	formatargspec functionality
Message-ID: <1391016633.41.0.856565781171.issue20439@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

The ability to fine-tune formatting of Signature (currently Signature.__str__) might be useful for pydoc and idle.

----------
assignee: yselivanov
messages: 209660
nosy: brett.cannon, larry, ncoghlan, terry.reedy, yselivanov
priority: normal
severity: normal
status: open
title: inspect.Signature: Add Signature.format method to match formatargspec functionality
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Jan 29 19:14:18 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 29 Jan 2014 18:14:18 +0000
Subject: [New-bugs-announce] [issue20440] Use Py_REPLACE/Py_XREPLACE macros
Message-ID: <1391019258.76.0.341506038923.issue20440@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patches replaced idiomatic code

    Py_DECREF(ptr);
    ptr = new_value;

to "Py_REPLACE(ptr, new_value);" which is expanded to

    {
        PyObject *__tmp__ = ptr;
        ptr = new_value;
        Py_DECREF(__tmp__);
    }

(and same for Py_XDECREF -> Py_XREPLACE).

Victor proposed large patch for issue16447, but this issue was closed after fixing particular bug. Here are updated patches, which Py_REPLACE/Py_XREPLACE macros for cleaner code. They are also generated automatically by the Coccinelle tool (http://coccinelle.lip6.fr/):

spatch --in-place --sp-file py_replace.spatch --dir .

Patch for every version contains about 50 replaces in about 21-24 files.

----------
components: Extension Modules, Interpreter Core
files: py_replace.spatch
messages: 209663
nosy: benjamin.peterson, georg.brandl, haypo, larry, serhiy.storchaka, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Use Py_REPLACE/Py_XREPLACE macros
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33800/py_replace.spatch

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

From report at bugs.python.org  Wed Jan 29 21:14:47 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 29 Jan 2014 20:14:47 +0000
Subject: [New-bugs-announce] [issue20441] Test_tcl.TclTest.test_split(list)
	failures on Windows, 2.7.
Message-ID: <1391026487.97.0.507324999213.issue20441@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

My Win7, AMD64 Win7, Server 2003, but not x86 Win7 buildbot or any others that run test
======================================================================
FAIL: test_split (test.test_tcl.TclTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\2.7.kloth-win64\build\lib\test\test_tcl.py", line 321, in test_split
    self.assertEqual(split(arg), res)
AssertionError: Tuples differ: ('12', u'\u20ac', u'\u20ac', '... != (12, u'\u20ac', u'\u20ac', (3....

First differing element 0:
12
12

- ('12', u'\u20ac', u'\u20ac', '3.4')
?  -  -                        ^   ^

+ (12, u'\u20ac', u'\u20ac', (3.4,))
?                            ^   ^ +


======================================================================
FAIL: test_splitlist (test.test_tcl.TclTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\2.7.kloth-win64\build\lib\test\test_tcl.py", line 281, in test_splitlist
    self.assertEqual(splitlist(arg), res)
AssertionError: Tuples differ: ('1', u'\u20ac', u'\u20ac', '3... != (1, u'\u20ac', u'\u20ac', (3.4...

First differing element 0:
1
1

- ('1', u'\u20ac', u'\u20ac', '3.4')
?  - -                        ^   ^

+ (1, u'\u20ac', u'\u20ac', (3.4,))
?                           ^   ^ +
========================================
I do not know which is correct and which wrong.

----------
components: Tkinter
messages: 209671
nosy: serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Test_tcl.TclTest.test_split(list) failures on Windows, 2.7.
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Jan 29 22:46:48 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 29 Jan 2014 21:46:48 +0000
Subject: [New-bugs-announce] [issue20442] inspect: Document Signature &
	Parameter constructors'	signatures
Message-ID: <1391032008.93.0.17742024038.issue20442@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

inspect.Signature & inspect.Parameter classes lack clear documentation about their constructors. Patch is attached.

----------
files: signature_docs_01.patch
keywords: patch
messages: 209684
nosy: eric.araujo, ezio.melotti, georg.brandl, larry, ncoghlan, yselivanov
priority: normal
severity: normal
status: open
title: inspect: Document Signature & Parameter constructors' signatures
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33807/signature_docs_01.patch

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

From report at bugs.python.org  Thu Jan 30 03:15:15 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 30 Jan 2014 02:15:15 +0000
Subject: [New-bugs-announce] [issue20443] __code__. co_filename should
	always be an absolute path
Message-ID: <1391048115.83.0.412883752117.issue20443@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

There are many issues on tracker related to the relative paths in co_filename. Most of them are about introspection functions in inspect module--which are usually broken after 'os.chdir'. 

Test case: create a file t.py:

   def foo(): pass
   print(foo.__code__.co_filename)

Execute it with '$ python t.py' -> it will print 't.py'.

Ideally, when executing a python file, interpreter should expand all relative paths for __file__ and __code__.co_filename attributes.

----------
messages: 209699
nosy: r.david.murray, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: __code__. co_filename should always be an absolute path
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Thu Jan 30 03:38:07 2014
From: report at bugs.python.org (dongwm)
Date: Thu, 30 Jan 2014 02:38:07 +0000
Subject: [New-bugs-announce] [issue20444] Reduce logging.config.Converting
	duplication of code
Message-ID: <1391049487.07.0.209856527412.issue20444@psf.upfronthosting.co.za>


Changes by dongwm <ciici123 at gmail.com>:


----------
components: Library (Lib)
files: logging_config.patch
keywords: patch
nosy: dongwm
priority: normal
severity: normal
status: open
title: Reduce logging.config.Converting duplication of code
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file33808/logging_config.patch

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

From report at bugs.python.org  Thu Jan 30 13:57:41 2014
From: report at bugs.python.org (George Kouryachy)
Date: Thu, 30 Jan 2014 12:57:41 +0000
Subject: [New-bugs-announce] [issue20445] HAVE_BROKEN_NICE detected
	incorrectly due to	configure.ac typo
Message-ID: <1391086661.44.0.32383692097.issue20445@psf.upfronthosting.co.za>


New submission from George Kouryachy:

It's declared in pyconfig.h that HAVE_BROKEN_NICE is set if nice() returns success/failure instead of the new priority.

But configure checks just opposite (as for http://hg.python.org/cpython/file/03fc7449f204/configure.ac#l4234):

  if (val1 != -1 && val1 == nice(2))
    exit(0);

We need "val1 != nice(2)" instead (to ensure that nicelevel is increased) or "val1 == nice(2)+2" (to check increment is proper; this can be tricky in some cases).

----------
components: Build
messages: 209712
nosy: George.Kouryachy
priority: normal
severity: normal
status: open
title: HAVE_BROKEN_NICE detected incorrectly due to configure.ac typo
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Jan 30 14:02:08 2014
From: report at bugs.python.org (flambda)
Date: Thu, 30 Jan 2014 13:02:08 +0000
Subject: [New-bugs-announce] [issue20446] ipaddress: hash similarities for
	ipv4 and ipv6
Message-ID: <1391086928.1.0.694997709579.issue20446@psf.upfronthosting.co.za>


New submission from flambda:

Hi,

I am a bit unsure if this is a problem but bear with me:

Using ipaddress I noticed that: 
hash(ipaddress.ip_address("0.0.0.1")) == hash(ipaddress.ip_address("::1"))

which makes sense as ipaddress uses this:
(http://hg.python.org/cpython/file/default/Lib/ipaddress.py)
    def __hash__(self):
        return hash(hex(int(self._ip)))
as the hash.

This means that in a mixed environment (ipv4 and ipv6 addresses), hashtables with hash(hex(int(b))), int(b)<2**32 will be filled more then tables with int(b)>2**32 due to the ipv4 and ipv6 address space overlapping in the first 32bits.

If this is intended behaviour, I am sorry to have bothered you.
Have a nice evening.

----------
components: Interpreter Core
messages: 209714
nosy: flambda
priority: normal
severity: normal
status: open
title: ipaddress: hash similarities for ipv4 and ipv6
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Jan 30 15:03:45 2014
From: report at bugs.python.org (Jakub Wilk)
Date: Thu, 30 Jan 2014 14:03:45 +0000
Subject: [New-bugs-announce] [issue20447] doctest.debug_script: insecure use
	of /tmp
Message-ID: <1391090625.54.0.961890812263.issue20447@psf.upfronthosting.co.za>


New submission from Jakub Wilk:

The doctest.debug_script function creates temporary files in an insecure way:

    srcfilename = tempfile.mktemp(".py", "doctestdebug")
    f = open(srcfilename, 'w')

This is already fixed for Python >= 3.2, although for reasons other than security: issue12451

----------
components: Library (Lib)
messages: 209717
nosy: jwilk
priority: normal
severity: normal
status: open
title: doctest.debug_script: insecure use of /tmp
type: security
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Thu Jan 30 15:16:17 2014
From: report at bugs.python.org (Saimadhav Heblikar)
Date: Thu, 30 Jan 2014 14:16:17 +0000
Subject: [New-bugs-announce] [issue20448] Adds missing backslash to devguide
	setup page
Message-ID: <1391091377.95.0.274075734127.issue20448@psf.upfronthosting.co.za>


New submission from Saimadhav Heblikar:

This is a simple typofix.
On line 224 and 225,there were unescaped backslashes,which resulted in the external.bat and external-amd64.bat appeared as Tools\buildbotexternal.bat and Tools\buildbotexternal-amd64.bat respectively.
this patch escapes the two back-slashes,so that the text appears correctly as
Tools\buildbot\external.bat or Tools\buildbot\external-amd64.bat

----------
components: Devguide
files: mywork.patch
keywords: patch
messages: 209718
nosy: ezio.melotti, sahutd
priority: normal
severity: normal
status: open
title: Adds missing backslash to devguide setup page
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33810/mywork.patch

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

From report at bugs.python.org  Thu Jan 30 16:22:29 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2014 15:22:29 +0000
Subject: [New-bugs-announce] [issue20449] _overlapped: read_buffer and
	write_buffer are misused
Message-ID: <1391095349.64.0.498559512626.issue20449@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I found an issue in overlapped.c: read_buffer and write_buffer attributes are defined in an union, but they are sometimes use even if the type is not good. I found this issue while trying to get a BrokenPipeError on Windows when the stdin stream of a subprocess is full but the process exited.

Could you please review attached patch, especially the change in Overlapped_getresult?

Another option would be to use two real attributes (remove the union), but I like the usage of union :-)

All Tulip unit tests of my subprocess_stream pass on Linux and Windows with the patch.

----------
files: overlapped.patch
keywords: patch
messages: 209721
nosy: gvanrossum, haypo, larry, pitrou, sbt
priority: release blocker
severity: normal
status: open
title: _overlapped: read_buffer and write_buffer are misused
versions: Python 3.4
Added file: http://bugs.python.org/file33812/overlapped.patch

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

From report at bugs.python.org  Thu Jan 30 21:29:39 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 30 Jan 2014 20:29:39 +0000
Subject: [New-bugs-announce] [issue20450] hg touch fails on System Z Linux
	buildbot
Message-ID: <1391113779.26.0.124342883313.issue20450@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

"Touching generated files failed" step fails on System Z Linux buildbot (http://buildbot.python.org/all/builders/System%20Z%20Linux%203.x/builds/1157/steps/shell/logs/stdio):

hg --config extensions.touch=Tools/hg/hgtouch.py touch -v
** unknown exception encountered, details follow
** report bug details to http://www.selenic.com/mercurial/bts
** or mercurial at selenic.com
** Mercurial Distributed SCM (version 1.0.2)
Traceback (most recent call last):
  File "/usr/bin/hg", line 20, in <module>
    mercurial.dispatch.run()
  File "/usr/lib64/python2.6/site-packages/mercurial/dispatch.py", line 20, in run
    sys.exit(dispatch(sys.argv[1:]))
  File "/usr/lib64/python2.6/site-packages/mercurial/dispatch.py", line 29, in dispatch
    return _runcatch(u, args)
  File "/usr/lib64/python2.6/site-packages/mercurial/dispatch.py", line 45, in _runcatch
    return _dispatch(ui, args)
  File "/usr/lib64/python2.6/site-packages/mercurial/dispatch.py", line 299, in _dispatch
    cmd, func, args, options, cmdoptions = _parse(lui, args)
  File "/usr/lib64/python2.6/site-packages/mercurial/dispatch.py", line 187, in _parse
    args = fancyopts.fancyopts(args, c, cmdoptions)
  File "/usr/lib64/python2.6/site-packages/mercurial/fancyopts.py", line 29, in fancyopts
    for short, name, default, comment in options:
ValueError: too many values to unpack
make: *** [touch] Error 1

I think upgrading Mercurial should fix this issue.

----------
components: Tests
messages: 209736
nosy: ezio.melotti, michael.foord, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: hg touch fails on System Z Linux buildbot

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

From report at bugs.python.org  Fri Jan 31 08:20:39 2014
From: report at bugs.python.org (Florian Bruhin)
Date: Fri, 31 Jan 2014 07:20:39 +0000
Subject: [New-bugs-announce] [issue20451] os.exec* mangles argv on windows
	(splits on spaces, etc)
Message-ID: <1391152839.26.0.437112268275.issue20451@psf.upfronthosting.co.za>


New submission from Florian Bruhin:

The os.exec* functions seem to mangle arguments on Windows. So far I noticed the supplied argv gets split on spaces, and double-quotes get stripped when not escaped.

Example, on Windows 7:

>>> platform.platform()
'Windows-7-6.1.7601-SP1'
>>> os.execlp('python', 'python', '-c', "sys=__import__('sys');print(sys.argv)", 'Hello World')
['-c', 'Hello', 'World']

Same on Archlinux: ['-c', 'Hello World'] as expected.

Both running Python 3.3.3.

----------
components: Library (Lib), Windows
messages: 209748
nosy: The Compiler
priority: normal
severity: normal
status: open
title: os.exec* mangles argv on windows (splits on spaces, etc)
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Jan 31 09:26:30 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 31 Jan 2014 08:26:30 +0000
Subject: [New-bugs-announce] [issue20452] test_timeout_rounding() of
	test_asyncio fails on "x86	Ubuntu Shared 3.x" buildbot
Message-ID: <1391156790.09.0.38396612237.issue20452@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The failure is minor, it's just a suboptimal code. Calling _run_once() 4 times instead of 3.

http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/9630/steps/test/logs/stdio

======================================================================
FAIL: test_timeout_rounding (test.test_asyncio.test_events.EPollEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_asyncio/test_events.py", line 1180, in test_timeout_rounding
    self.assertEqual(calls, [1, 3, 5, 6])
AssertionError: Lists differ: [1, 4, 6, 7] != [1, 3, 5, 6]

First differing element 1:
4
3

- [1, 4, 6, 7]
+ [1, 3, 5, 6]



I'm unable to reproduce the error on my Linux box. When we had the rounding away from zero in epoll directly, the epoll test failed on the same buildbot:
http://bugs.python.org/issue20311#msg208601

http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.3/builds/1360/steps/test/logs/stdio

======================================================================
FAIL: test_timeout_rounding (test.test_epoll.TestEPoll)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.3.bolen-ubuntu/build/Lib/test/test_epoll.py", line 58, in test_timeout_rounding
    self.assertGreaterEqual(dt, timeout)
AssertionError: 0.009388947859406471 not greater than or equal to 0.01

----------
components: Tests
messages: 209749
nosy: gvanrossum, haypo
priority: normal
severity: normal
status: open
title: test_timeout_rounding() of test_asyncio fails on "x86 Ubuntu Shared 3.x" buildbot
versions: Python 3.4

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

From report at bugs.python.org  Fri Jan 31 11:08:51 2014
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 31 Jan 2014 10:08:51 +0000
Subject: [New-bugs-announce] [issue20453] json.load() error message changed
	in 3.4
Message-ID: <1391162931.99.0.108127691347.issue20453@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

Run the attached file under Python 3.3 and you get:

No JSON object could be decoded

Run the same file under Python 3.4 and you get:

Expecting value: line 1 column 1 (char 0)

So a couple of things:

Since the error message changed, it makes it difficult to test in doctest and other text-based matches.  I'm also not sure the new message is "better".  Objectively speaking, probably both error messages are useful (i.e. that no json object was found, and where the problem was found).  I think the second message by itself is pretty mysterious.

I want to make sure the change was deliberate.  I couldn't find anything in Misc/NEWS which might not be entirely unexpected since specific error messages aren't generally a part of the guaranteed API.  Perhaps at the least, if the change was deliberate, let's document it in Misc/NEWS.

----------
files: foo.py
messages: 209755
nosy: barry
priority: normal
severity: normal
status: open
title: json.load() error message changed in 3.4
versions: Python 3.4
Added file: http://bugs.python.org/file33824/foo.py

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

From report at bugs.python.org  Fri Jan 31 12:02:45 2014
From: report at bugs.python.org (Francis Moreau)
Date: Fri, 31 Jan 2014 11:02:45 +0000
Subject: [New-bugs-announce] [issue20454] platform.linux_distribution()
	returns empty value on	Archlinux and python 2.7
Message-ID: <1391166165.52.0.4413803514.issue20454@psf.upfronthosting.co.za>


New submission from Francis Moreau:

On Archlinux:

$ python2.7 -c 'import platform; print(platform.linux_distribution())'
('', '', '')

This is because Archlinux is not part of the '_supported_dists' list.

Could Archlinux be added to this list ?

Thanks.

----------
components: Library (Lib)
messages: 209764
nosy: fmoreau, lemburg
priority: normal
severity: normal
status: open
title: platform.linux_distribution() returns empty value on Archlinux and python 2.7
versions: Python 2.7

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

From report at bugs.python.org  Fri Jan 31 14:15:00 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 31 Jan 2014 13:15:00 +0000
Subject: [New-bugs-announce] [issue20455] test_asyncio hangs on Windows
Message-ID: <1391174100.63.0.591447461885.issue20455@psf.upfronthosting.co.za>


New submission from STINNER Victor:

It's probably a regression caused by my changeset 73dbb884eb09 which fixed a bug (issue #20449).

Related Tulip issue:
http://code.google.com/p/tulip/issues/detail?id=121

----------
messages: 209783
nosy: gvanrossum, haypo, sbt
priority: normal
severity: normal
status: open
title: test_asyncio hangs on Windows
versions: Python 3.4

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

From report at bugs.python.org  Fri Jan 31 14:18:30 2014
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 31 Jan 2014 13:18:30 +0000
Subject: [New-bugs-announce] [issue20456] Argument Clinic rollup patch,
	2014/01/31
Message-ID: <1391174310.68.0.164884497366.issue20456@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Probably the last rollup patch for a while; I need to move on to code
reviewing.

Here's a list of changes in this patch:

* I added the oft-requested "rename the C variable for a parameter"
  functionality.  That works as follows:

     os.rename
         path as stinky: path_t

  Here the Python name is "path", and the C name is "stinky".
  Internally the "name" of the parameter is the Python name, and
  the "name" of the converter is the C name.  (But the converter
  gets the Python name too, because it needs it sometimes, e.g.
  for the keywords array.)

* Fixed a minor but difficult-to-fix problem: when cloning a function,
  the cloned function would still refer to the original function's
  name.  (You can see this in the PATH_T_INITIALIZE macros in
  os_replace in posixmodule.c.)

* While fixing the above I stumbled over a new problem: rendering
  often changes internal state of a parameter, which could cause
  problems if we clone an already-rendered parameter object.  The
  solution: make a copy of all the Parameter objects before rendering,
  then render from the copies.

* Fixing the above forced me to add a new initalizer to CConverter
  objects: pre_render(), which is called just before rendering.

* This change also means it's pretty important to call up to the super()
  for converter_init() and pre_render().

* Fixing the above also required new semantics for converter_init():
  you are no longer permitted to examine the function object in
  that method.  (I made it fail noisily with a "LandMine".)

* "clinic.py --converters" was broken, I fixed it.  (It was confused
  by object_converter having format_unit=None.)

* I fixed the unit tests too.

* You can now specify blank lines between directives without Clinic
  getting angry at you.

* I redid how I store all those little C code snippet template.
  Originally they were inline, but flush left, and that made
  reading them tiresome--the indent was jumping around on you.
  Changing to a central list removed the jumping around but now
  you had to scroll back and forth to correlate the template with
  where it was used.  The final solution: have them inline again,
  but indented, and simply outdent the text before use.  Go ahead,
  tell me that's *not* an improvement.  :D  (The outdenting function
  uses functools.lru_cache, so processing is really no slower.)

And last but certainly not least...!

Following a suggestion by Serhiy Storchaka, Argument Clinic is now
incredibly sophisticated with respect to #if'd out code.  In less than
200 lines, I wrote a reasonable C preprocessor monitor class.  The
monitor parses C files in parallel to Argument Clinic.  At any time
you can ask the monitor "what's the current preprocessor conditional
state?"  If the current code is potentially if'd out, Argument Clinic
uses the same conditional to potentially #if out the parser function,
the docstring, etc, when writing those to buffer or file.  It even
adds this to the end:

  #ifndef YOUR_FUNCTION_METHODDEF
      #define YOUR_FUNCTION_METHODDEF
  #endif /* !defined(YOUR_FUNCTION_METHODDEF) */

But *only* when necessary.

You can see this in action in the diff for Modules/clinic/zlibmodule.c.h.

I think this is a huge improvement!  (Thanks for the suggestion, Serhiy!)

----------
assignee: larry
files: larry.clinic.rollup.2014.01.31.1.diff
keywords: patch
messages: 209784
nosy: larry, ncoghlan, serhiy.storchaka, taleinat, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Argument Clinic rollup patch, 2014/01/31
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33826/larry.clinic.rollup.2014.01.31.1.diff

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

From report at bugs.python.org  Fri Jan 31 17:16:40 2014
From: report at bugs.python.org (dongwm)
Date: Fri, 31 Jan 2014 16:16:40 +0000
Subject: [New-bugs-announce] [issue20457] Use partition and enumerate make
	getopt easier
Message-ID: <1391185000.25.0.00329512956589.issue20457@psf.upfronthosting.co.za>


Changes by dongwm <ciici123 at gmail.com>:


----------
components: Library (Lib)
files: getopt_2.7_3.X.path
nosy: dongwm
priority: normal
severity: normal
status: open
title: Use partition and enumerate make getopt easier
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file33833/getopt_2.7_3.X.path

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

From report at bugs.python.org  Fri Jan 31 17:17:38 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 31 Jan 2014 16:17:38 +0000
Subject: [New-bugs-announce] [issue20458] ``clinic.py --converters`` raises
	an exception
Message-ID: <1391185058.63.0.464965785881.issue20458@psf.upfronthosting.co.za>


New submission from Brett Cannon:

> ./python.exe Tools/clinic/clinic.py --converters              ~/Repositories/cpython/default

Legacy converters:
Traceback (most recent call last):
  File "Tools/clinic/clinic.py", line 4045, in <module>
    sys.exit(main(sys.argv[1:]))
  File "Tools/clinic/clinic.py", line 3977, in main
    print('    ' + ' '.join(c for c in legacy if c[0].isupper()))
  File "Tools/clinic/clinic.py", line 3977, in <genexpr>
    print('    ' + ' '.join(c for c in legacy if c[0].isupper()))
IndexError: string index out of range

----------
assignee: larry
components: Build
messages: 209802
nosy: brett.cannon, larry
priority: release blocker
severity: normal
stage: needs patch
status: open
title: ``clinic.py --converters`` raises an exception
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Jan 31 17:21:42 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 31 Jan 2014 16:21:42 +0000
Subject: [New-bugs-announce] [issue20459] No Argument Clinic documentation
	on how to specify a	return converter
Message-ID: <1391185302.8.0.888255910236.issue20459@psf.upfronthosting.co.za>


New submission from Brett Cannon:

There's no actual example of using a return converter so it's not obvious how to specify one. Is it specifying an argument of 'return'?

----------
assignee: larry
components: Documentation
messages: 209803
nosy: brett.cannon, larry
priority: normal
severity: normal
stage: needs patch
status: open
title: No Argument Clinic documentation on how to specify a return converter
versions: Python 3.4

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

From report at bugs.python.org  Fri Jan 31 17:51:28 2014
From: report at bugs.python.org (OSAMU NAKAMURA)
Date: Fri, 31 Jan 2014 16:51:28 +0000
Subject: [New-bugs-announce] [issue20460] Wrong markup in c-api/arg.rst
Message-ID: <1391187088.65.0.311524053525.issue20460@psf.upfronthosting.co.za>


New submission from OSAMU NAKAMURA:

":func:`bytes`" in description for ``y`` format 
should be ":class:`bytes`".

----------
assignee: docs at python
components: Documentation
files: mywork.patch
keywords: patch
messages: 209806
nosy: OSAMU.NAKAMURA, docs at python
priority: normal
severity: normal
status: open
title: Wrong markup in c-api/arg.rst
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33835/mywork.patch

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

From report at bugs.python.org  Fri Jan 31 18:28:47 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 31 Jan 2014 17:28:47 +0000
Subject: [New-bugs-announce] [issue20461] Argument Clinic included return
	converters hard code use	of ``_return_value``
Message-ID: <1391189327.05.0.0632329148594.issue20461@psf.upfronthosting.co.za>


New submission from Brett Cannon:

E.g. NoneType_return_converter assumes _return_value is used in render() although CReturnConverter.declare() stores it in data.return_value and it's a parameter to render().

----------
assignee: larry
components: Build
messages: 209808
nosy: brett.cannon, larry
priority: normal
severity: normal
stage: test needed
status: open
title: Argument Clinic included return converters hard code use of ``_return_value``
versions: Python 3.4

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

From report at bugs.python.org  Fri Jan 31 19:36:11 2014
From: report at bugs.python.org (Alessandro Reinoso)
Date: Fri, 31 Jan 2014 18:36:11 +0000
Subject: [New-bugs-announce] [issue20462] Python IDLE auto closed when
	creating a new file or open	existing file
Message-ID: <1391193371.56.0.893226127057.issue20462@psf.upfronthosting.co.za>


New submission from Alessandro Reinoso:

I looked for some online help and i found a question on stackoverflow wich shows my same problem except that i just installed python to get started:

http://stackoverflow.com/questions/20768949/python-idle-auto-closed-when-i-create-a-new-file-or-open-existing-file

when i choose Edit with IDLE, doesn't even bother to open. 

im using windows 7 SP1 64-bit
i tried using both python-3.3.3.msi and python-3.3.3.amd64.msi installers, both with same problem.

Thank You.

----------
messages: 209811
nosy: Bishop
priority: normal
severity: normal
status: open
title: Python IDLE auto closed when creating a new file or open existing file
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Jan 31 20:57:36 2014
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Fri, 31 Jan 2014 19:57:36 +0000
Subject: [New-bugs-announce] [issue20463] sqlite dumpiter dumps invalid
	script when virtual tables	are used
Message-ID: <1391198256.46.0.541752876278.issue20463@psf.upfronthosting.co.za>


New submission from Ronny Pfannschmidt:

when using virtual tables, dumpiter generates a broken db script
virtual table entries must be created as master table entries
the sqlite tools dump does that correctly
however pythons iterdump  seems to do that rather different and wrong

sqlite3 test.db "create virtual table test using fts4(example);"
-------------------------------
sqlite dump
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
PRAGMA writable_schema=ON;
INSERT INTO sqlite_master(type,name,tbl_name,rootpage,sql)VALUES('table','test','test',0,'CREATE VIRTUAL TABLE test using fts4(example)');
CREATE TABLE 'test_content'(docid INTEGER PRIMARY KEY, 'c0example');
CREATE TABLE 'test_segments'(blockid INTEGER PRIMARY KEY, block BLOB);
CREATE TABLE 'test_segdir'(level INTEGER,idx INTEGER,start_block INTEGER,leaves_end_block INTEGER,end_block INTEGER,root BLOB,PRIMARY KEY(level, idx));
CREATE TABLE 'test_docsize'(docid INTEGER PRIMARY KEY, size BLOB);
CREATE TABLE 'test_stat'(id INTEGER PRIMARY KEY, value BLOB);
PRAGMA writable_schema=OFF;
COMMIT;
------------------------------
python iterdump "import sqlite3;
c=sqlite3.connect("test.db");
print("\n".join(c.iterdump()))"
BEGIN TRANSACTION;
CREATE VIRTUAL TABLE test using fts4(example);
CREATE TABLE 'test_content'(docid INTEGER PRIMARY KEY, 'c0example');
CREATE TABLE 'test_docsize'(docid INTEGER PRIMARY KEY, size BLOB);
CREATE TABLE 'test_segdir'(level INTEGER,idx INTEGER,start_block INTEGER,leaves_end_block INTEGER,end_block INTEGER,root BLOB,PRIMARY KEY(level, idx));
CREATE TABLE 'test_segments'(blockid INTEGER PRIMARY KEY, block BLOB);
CREATE TABLE 'test_stat'(id INTEGER PRIMARY KEY, value BLOB);
COMMIT;

----------
messages: 209825
nosy: Ronny.Pfannschmidt
priority: normal
severity: normal
status: open
title: sqlite dumpiter dumps invalid script when virtual tables are used
versions: Python 2.7

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

From report at bugs.python.org  Fri Jan 31 21:55:11 2014
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 31 Jan 2014 20:55:11 +0000
Subject: [New-bugs-announce] [issue20464] Update distutils sample config
	file in	Doc/install/index.rst
Message-ID: <1391201711.97.0.184979826347.issue20464@psf.upfronthosting.co.za>


New submission from Zachary Ware:

>From docs@:

On Thu, Jan 16, 2014 at 2:56 AM, Peter Br?cker <peter.broecker at uni-koeln.de> wrote:
> Hi,
>
> I have tried to set up the distutils config files for a custom module
> installation. Using the suggested snippet  from
>
> http://docs.python.org/2/install/
>
> [install]
> install-base=$HOME/python
> install-purelib=lib
> install-platlib=lib.$PLAT
> install-scripts=scripts
> install-data=data did not work for me.
>
> Instead, I had to add install-headers and additionally modify all paths
> to include $base:
>
> [install]
> install-base=/some/dir
> install-purelib=$base/lib
> install-platlib=$base/lib.$PLAT
> install-scripts=$base/scripts
> install-headers=$base/include
> install-data=$base/data
>
>
> I'm unsure if this is actually a bug, but I could only resolve this with
> the help of this answer on stackoverflow:
> http://stackoverflow.com/a/12768721
>
> Best regards,
> Peter

----------
assignee: docs at python
components: Distutils, Documentation
messages: 209829
nosy: docs at python, zach.ware
priority: normal
severity: normal
stage: test needed
status: open
title: Update distutils sample config file in Doc/install/index.rst
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Jan 31 21:57:25 2014
From: report at bugs.python.org (Ned Deily)
Date: Fri, 31 Jan 2014 20:57:25 +0000
Subject: [New-bugs-announce] [issue20465] Upgrade SQLite to 3.8.3 with 3.4.0
	Windows and OS X	installers
Message-ID: <1391201845.39.0.337535666199.issue20465@psf.upfronthosting.co.za>


New submission from Ned Deily:

The SQLite project has requested that we consider shipping SQLite version 3.8.3 with the Windows and OS X binary installers for Python 3.4.0, primarily to make available support for the new Common Table Expressions feature.  3.8.3 is expected to be officially released 2014-02-03.

----------
components: Build
messages: 209830
nosy: larry, loewis, ned.deily
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Upgrade SQLite to 3.8.3 with 3.4.0 Windows and OS X installers
versions: Python 3.4

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

From report at bugs.python.org  Fri Jan 31 23:14:09 2014
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 31 Jan 2014 22:14:09 +0000
Subject: [New-bugs-announce] [issue20466] Example in
	Doc/extending/embedding.rst fails to compile	cleanly
Message-ID: <1391206449.61.0.838795178148.issue20466@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Reported by Riccardo Rossi on docs@:

The Very High Level Embedding example fails to compile cleanly, due to Py_SetProgramName expecting a wchar_t * argument, while the example passes a char *.

----------
assignee: docs at python
components: Documentation
messages: 209837
nosy: docs at python, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Example in Doc/extending/embedding.rst fails to compile cleanly
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Jan 31 23:41:34 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 31 Jan 2014 22:41:34 +0000
Subject: [New-bugs-announce] [issue20467] Confusing wording about __init__
Message-ID: <1391208094.95.0.178232051767.issue20467@psf.upfronthosting.co.za>


New submission from Mark Lawrence:

I found the wording here http://docs.python.org/3/reference/datamodel.html#object.__init__ very confusing as it implies that __init__ is the class constructor and not the initialiser.  Specifically it says "As a special constraint on constructors, no value may be returned; doing so will cause a TypeError to be raised at runtime".  Can we please have the wording changed so that it states exactly what this method does?  Possibly changes are also needed in the equivalent section for __new__.

----------
assignee: docs at python
components: Documentation
messages: 209843
nosy: BreamoreBoy, docs at python
priority: normal
severity: normal
status: open
title: Confusing wording about __init__
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Jan 31 23:50:41 2014
From: report at bugs.python.org (Kurt Rose)
Date: Fri, 31 Jan 2014 22:50:41 +0000
Subject: [New-bugs-announce] [issue20468] resource module documentation is
	incorrect
Message-ID: <1391208641.83.0.141932054107.issue20468@psf.upfronthosting.co.za>


New submission from Kurt Rose:

The documentation in the resource module for get_page_size() is incorrect.

resource.getpagesize()
Returns the number of bytes in a system page. (This need not be the same as the hardware page size.) This function is useful for determining the number of bytes of memory a process is using. The third element of the tuple returned by getrusage() describes memory usage in pages; multiplying by page size produces number of bytes.

On Linux, the value returned in getrusage().ru_maxrss is in kilobytes.  On OS-X it is in bytes.  Ideally, this could be put into the documentation, but at least remove the inaccurate recommendation to multiply maxrss by page size :-)

----------
assignee: ronaldoussoren
components: Macintosh
messages: 209844
nosy: Kurt.Rose, ronaldoussoren
priority: normal
severity: normal
status: open
title: resource module documentation is incorrect
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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