From report at bugs.python.org  Fri Feb  1 02:45:25 2013
From: report at bugs.python.org (Thomas Grainger)
Date: Fri, 01 Feb 2013 01:45:25 +0000
Subject: [New-bugs-announce] [issue17096] the system keyring should be used
	instead of ~/.pypirc
Message-ID: <1359683125.78.0.593949491252.issue17096@psf.upfronthosting.co.za>


New submission from Thomas Grainger:

Having the password stored in a plain-text configuration file is not great security.

A better choice would be to try to use the OS keyring and then fall back to a plaintext file

An example implementation of a generic keyring python interface is available at: http://pypi.python.org/pypi/keyring/

----------
assignee: eric.araujo
components: Distutils2
messages: 181052
nosy: alexis, eric.araujo, graingert, tarek
priority: normal
severity: normal
status: open
title: the system keyring should be used instead of ~/.pypirc
type: security

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

From report at bugs.python.org  Fri Feb  1 11:43:44 2013
From: report at bugs.python.org (lvroyce)
Date: Fri, 01 Feb 2013 10:43:44 +0000
Subject: [New-bugs-announce] [issue17097] baseManager serve_client() not
	check EINTR when recv	request
Message-ID: <1359715424.77.0.356613938118.issue17097@psf.upfronthosting.co.za>


New submission from lvroyce:

We create our customised manager which will fork child process with baseManager. Because we registered SIGCHLD to reap the zombie for manager, we found this causes baseManager raise RemoteError when called twice.(Test script attached.)

After look at baseManager.py we found recv() in handling the request has been interrupted by comming SIGCHLD, not retry recv(), but raise to client side directly.
try:

                methodname = obj = None

                request = recv()<------------------this line been interrupted by SIGCHLD

                ident, methodname, args, kwds = request

                obj, exposed, gettypeid = id_to_obj[ident]

                if methodname not in exposed:

                    raise AttributeError(

                        'method %r of %r object is not in exposed=%r' %

                        (methodname, type(obj), exposed)

                        )

                function = getattr(obj, methodname)
                try:

                    res = function(*args, **kwds)

                except Exception, e:

                    msg = ('#ERROR', e)

                else:

                    typeid = gettypeid and gettypeid.get(methodname, None)

                    if typeid:

                        rident, rexposed = self.create(conn, typeid, res)

                        token = Token(typeid, self.address, rident)

                        msg = ('#PROXY', (rexposed, token))

                    else:

                        msg = ('#RETURN', res)
            except AttributeError:
                if methodname is None:
                    msg = ('#TRACEBACK', format_exc())
                else:
                    try:
                        fallback_func = self.fallback_mapping[methodname]
                        result = fallback_func(
                            self, conn, ident, obj, *args, **kwds
                            )
                        msg = ('#RETURN', result)
                    except Exception:
                        msg = ('#TRACEBACK', format_exc())

            except EOFError:
                util.debug('got EOF -- exiting thread serving %r',
                           threading.current_thread().name)
                sys.exit(0)

            except Exception:<------does not handle IOError,INTR here should retry recv() 
                msg = ('#TRACEBACK', format_exc())

----------
files: fakesupervdsm.py
messages: 181074
nosy: lvroyce
priority: normal
severity: normal
status: open
title: baseManager serve_client() not check EINTR when recv request
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file28930/fakesupervdsm.py

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

From report at bugs.python.org  Fri Feb  1 14:39:27 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 13:39:27 +0000
Subject: [New-bugs-announce] [issue17098] Set __loader__ on modules imported
	by the C level
Message-ID: <1359725967.87.0.894727021697.issue17098@psf.upfronthosting.co.za>


New submission from Brett Cannon:

E.g. _frozen_importlib, builtins, signal.

----------
components: Interpreter Core
messages: 181078
nosy: brett.cannon, theller
priority: normal
severity: normal
stage: test needed
status: open
title: Set __loader__ on modules imported by the C level
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Feb  1 14:44:37 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 13:44:37 +0000
Subject: [New-bugs-announce] [issue17099] Raise ValueError when __loader__
	not defined for	importlib.find_loader()
Message-ID: <1359726277.47.0.865712090918.issue17099@psf.upfronthosting.co.za>


New submission from Brett Cannon:

If __loader__ is None then ValueError is raised, but if it is not defined then AttributeError is raised instead. Probably should harmonize around ValueError even in the missing attribute case since __loader__ = None is equivalent to the attribute not existing.

I'm on the fence about considering this a bug, though, since the docs say if __loader__ == None then ValueError but does not directly mention what happens if the attribute is missing. Since anyone who has written code for this probably is catching both attributes (if at all since all but three modules coming from Python will have __loader__ defined ATM), it should be fine, but it is still a change in API/semantics that doesn't contradict the docs.

----------
components: Library (Lib)
messages: 181079
nosy: brett.cannon, ncoghlan, theller
priority: normal
severity: normal
stage: test needed
status: open
title: Raise ValueError when __loader__ not defined for importlib.find_loader()
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Feb  1 17:32:03 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Feb 2013 16:32:03 +0000
Subject: [New-bugs-announce] [issue17100] rotating an ordereddict
Message-ID: <1359736323.45.0.953309245292.issue17100@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

It can be useful to rotate an OrderedDict (for example when managing a circular playlist). I haven't found any efficient way to do so from user code, without poking at the internals.

Actually, I envision three methods:

 OrderedDict.rotate(self, n):

   rotate n steps to the right (similarly to deque.rotate())

 OrderedDict.rotate_at(self, key):

   rotate so that the given key ends up in first position

 OrderedDict.rotate_after(self, key):

   rotate so that the given key ends up in last position

(rotate_at, rotate_after could be merged in a single method with a "last" argument, if deemed more elegant)

Note: another solution to the playlist problem would be to have insert_after() and insert_before() methods.

----------
messages: 181086
nosy: pitrou, rhettinger
priority: normal
severity: normal
status: open
title: rotating an ordereddict
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Feb  1 17:54:16 2013
From: report at bugs.python.org (Philip Thiem)
Date: Fri, 01 Feb 2013 16:54:16 +0000
Subject: [New-bugs-announce] [issue17101] Multiprocessing on Windows
Message-ID: <1359737656.57.0.323890943093.issue17101@psf.upfronthosting.co.za>


New submission from Philip Thiem:

http://bugs.python.org/issue10845 also applies to the 2.X series.

this is multiprocessing on windows has issues with __main__.py

----------
components: Windows
messages: 181090
nosy: pthiem
priority: normal
severity: normal
status: open
title: Multiprocessing on Windows
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Sat Feb  2 07:02:27 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 02 Feb 2013 06:02:27 +0000
Subject: [New-bugs-announce] [issue17102] tarfile extract can write files
	outside the destination	path
Message-ID: <1359784947.71.0.187572651427.issue17102@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

Create a malicious .tar file with entries containing absolute or relative paths and the tarfile module happily uses them as is without sanity checking.

filed in response to http://bugs.python.org/issue6972 which fixed the zipfile module for this.

I'm attaching an example tar file to demonstrate this (safely) but much worse things could obviously be done.

----------
files: absolute_path.tar
messages: 181133
nosy: gregory.p.smith
priority: high
severity: normal
status: open
title: tarfile extract can write files outside the destination path
type: security
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28931/absolute_path.tar

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

From report at bugs.python.org  Sat Feb  2 10:22:38 2013
From: report at bugs.python.org (gheorghe mosteoru)
Date: Sat, 02 Feb 2013 09:22:38 +0000
Subject: [New-bugs-announce] [issue17103] ampersand "&" in path prevents
	from compiling pthon
Message-ID: <1359796958.56.0.232245529308.issue17103@psf.upfronthosting.co.za>


New submission from gheorghe mosteoru:

I've be trying to compile python in a folder which had '&' (ampersand) in the path and i couldn't. 

First configure got some weird output:

configure: creating ./config.status
config.status: creating Makefile.pre
sed: -e expression #1, char 435: unknown option to `s'
config.status: creating Modules/Setup.config
sed: -e expression #1, char 447: unknown option to `s'
config.status: creating Misc/python.pc
sed: -e expression #1, char 438: unknown option to `s'
config.status: creating Misc/python-config.sh
sed: -e expression #1, char 452: unknown option to `s'
config.status: creating Modules/ld_so_aix
sed: -e expression #1, char 441: unknown option to `s'
config.status: creating pyconfig.h
creating Modules/Setup
creating Modules/Setup.local
creating Makefile

Then when I've run make I've got:

make: *** No rule to make target `/Modules/posixmodule.c', needed by `Modules/posixmodule.o'.  Stop.

----------
components: Build
messages: 181151
nosy: gheorghe.mosteoru
priority: normal
severity: normal
status: open
title: ampersand "&" in path prevents from compiling pthon
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Sat Feb  2 10:28:36 2013
From: report at bugs.python.org (zephyr)
Date: Sat, 02 Feb 2013 09:28:36 +0000
Subject: [New-bugs-announce] [issue17104] Tk() not defined in Tkinter module
Message-ID: <1359797316.8.0.0796335939383.issue17104@psf.upfronthosting.co.za>


New submission from zephyr:

There are two cases of this issues:

1)Terminal-importing the Tkinter module and creating a Tk() object runs fine for the first instance but exiting the interpreter and trying to create a object for the next instance gives error:'Tk() is not defined'

2)IDE-importing the Tkinter module and creating a Tk() object produces error-'Tk() is not defined'.

----------
components: None
messages: 181153
nosy: zephyr
priority: normal
severity: normal
status: open
title: Tk() not defined in Tkinter module
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Sat Feb  2 19:03:34 2013
From: report at bugs.python.org (Damian)
Date: Sat, 02 Feb 2013 18:03:34 +0000
Subject: [New-bugs-announce] [issue17105] Python 3.2 segfault
Message-ID: <1359828214.1.0.432640165119.issue17105@psf.upfronthosting.co.za>


New submission from Damian:

Hi. While porting a library of mine (https://stem.torproject.org/) to python 3 I've been reliably encountering a python segmentation fault while running its integration tests. After many hours of head scratching I've narrowed the repro to the following script...

========================================

import queue
import socket

class Demo(object):
  def __init__(self, control_socket_file):
    demo_queue = queue.Queue()

    try:
      raise ValueError()
    except ValueError as exc:
      demo_queue.put(exc)

for i in range(20):
  control_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
  control_socket.connect(("www.google.com", 80))
  control_socket_file = control_socket.makefile(mode = "rw", newline = "") 

  Demo(control_socket_file)

========================================

atagar at morrigan:~$ python3 --version
Python 3.2
atagar at morrigan:~$ python3 demo.py 
Segmentation fault

========================================

Yes, I realise that the script is stupidly convoluted but it was the minimal amount of code I could get to in order to reproduce the problem. Some things to note...

* You must have an object that gets a reference to an open socket based file.

* You need to have a try/catch block and enqueue that exception. If you get rid of the try/catch or enqueue something else then no segfault for you.

* The segfault isn't entirely reliable (seems so happen half the time or so), hence the loop.


While this repro script is pointless, it's the last issue preventing me from moving to python 3. At this point I'm out of idea so help would be greatly appreciated.

Thanks! -Damian

Python: Python 3.2 (r32:88445, Oct 20 2012, 14:09:50)
Platform: Ubuntu 11.04

PS. If the advice is 'upgrade python, 3.2 had some segfault bugs' then a pointer to those bugs would be appreciated. I've sunk quite a few hours into this issue so it would be nice to finally figure out what's up.

----------
messages: 181190
nosy: atagar
priority: normal
severity: normal
status: open
title: Python 3.2 segfault
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Sat Feb  2 21:13:44 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 Feb 2013 20:13:44 +0000
Subject: [New-bugs-announce] [issue17106] Crash in IO reading text file as
	binary via email library
Message-ID: <1359836024.9.0.950016138746.issue17106@psf.upfronthosting.co.za>


New submission from R. David Murray:

I came across this by making a mistake, but it shouldn't crash:

rdmurray at hey:~/python/p32>touch temp
rdmurray at hey:~/python/p32>./python  
Python 3.2.3+ (3.2:e6952acd5a55+, Feb  2 2013, 15:04:21) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from email import message_from_binary_file as mb
>>> m = mb(open('temp'))
python: ./Modules/_io/textio.c:1454: textiowrapper_read_chunk: Assertion `((((((PyObject*)(input_chunk))->ob_type))->tp_flags & ((1L<<27))) != 0)' failed.
zsh: abort      ./python


This is a regression relative to 3.2.3:

Python 3.2.3 (default, Sep 16 2012, 16:35:39) 
[GCC 4.5.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from email import message_from_binary_file as mb
>>> m = mb(open('temp'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/email/__init__.py", line 63, in
message_from_binary_file
    return BytesParser(*args, **kws).parse(fp)
  File "/usr/lib/python3.2/email/parser.py", line 124, in parse
    return self.parser.parse(fp, headersonly)
  File "/usr/lib/python3.2/email/parser.py", line 68, in parse
    data = fp.read(8192)
  File "/usr/lib/python3.2/encodings/ascii.py", line 26, in decode
    return codecs.ascii_decode(input, self.errors)[0]
TypeError: 'str' does not support the buffer interface

----------
components: IO
keywords: 3.2regression
messages: 181210
nosy: georg.brandl, pitrou, r.david.murray
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Crash in IO reading text file as binary via email library
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Sat Feb  2 23:15:52 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Feb 2013 22:15:52 +0000
Subject: [New-bugs-announce] [issue17107] test_sni in test_urllib2net could
	be enabled
Message-ID: <1359843352.18.0.227762212958.issue17107@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Right now test_sni in test_urllib2net is skipped with the message "test disabled - test server needed". But the ssl module now has server-side SNI support, and therefore we could implement this test with a local server (and perhaps move it to test_urllib2_localnet).

----------
components: Tests
messages: 181222
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_sni in test_urllib2net could be enabled
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Feb  2 23:41:08 2013
From: report at bugs.python.org (Shai Berger)
Date: Sat, 02 Feb 2013 22:41:08 +0000
Subject: [New-bugs-announce] [issue17108] import silently prefers package
	over module when both	available
Message-ID: <1359844868.64.0.586214844711.issue17108@psf.upfronthosting.co.za>


New submission from Shai Berger:

Consider the following directory structure:

a-\
  __init__.py
  b.py
  b-|
    __init__.py

Now, in Python (I checked 2.7.3 and 3.2.3, haven't seen the issue mentioned anywhere so I suspect it is also in later Pythons), if you import a.b, you always get the package (that is, the b folder), and the module (b.py) is silently ignored. I tested by putting the line """print("I'm a package")""" in a/b/__init__.py and """print("I'm a module")""" in a/b.py.

This becomes a real problem with tools which find modules dynamically, like test harnesses.

I'd expect that in such cases, Python should "avoid the temptation to guess", and raise an ImportError.

Thanks, Shai.

----------
components: Interpreter Core
messages: 181225
nosy: shai
priority: normal
severity: normal
status: open
title: import silently prefers package over module when both available
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Feb  3 00:31:56 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Feb 2013 23:31:56 +0000
Subject: [New-bugs-announce] [issue17109] unittest.mock has wrong heading
	levels
Message-ID: <1359847916.06.0.948059142978.issue17109@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

If you look at http://docs.python.org/dev/library/development.html, you'll see the following outline (stripped for brevity):
     
26.4. unittest.mock ? mock object library

    26.4.1. Quick Guide
    26.4.2. The Mock Class

26.5. The patchers

26.6. MagicMock and magic method support

26.7. Helpers

26.8. unittest.mock ? getting started

26.9. Further Examples

26.10. 2to3 - Automated Python 2 to 3 code translation


Instead, it should be:

26.4. unittest.mock ? mock object library

    26.4.1. Quick Guide
    26.4.2. The Mock Class
    26.4.3. The patchers
    26.4.4. MagicMock and magic method support
    26.4.5. Helpers

26.5. unittest.mock ? getting started

    26.5.1. Further Examples

26.6. 2to3 - Automated Python 2 to 3 code translation


(I'm also not sure the reference document should come before the getting started document)

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 181231
nosy: docs at python, michael.foord, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: unittest.mock has wrong heading levels
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Feb  3 05:01:11 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 03 Feb 2013 04:01:11 +0000
Subject: [New-bugs-announce] [issue17110] sys.argv docs should explaining
	how to handle encoding	issues
Message-ID: <1359864071.69.0.659089821533.issue17110@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

The sys.argv docs [1] currently contain no mention of the fact that they are Unicode strings decoded from bytes provided by the OS. They also don't explain how to correct a decoding error by reversing Python's implicit conversion and redoing it based on the application's knowledge of the correct encoding, as described at [2]

[1] http://docs.python.org/3/library/sys#sys.argv
[2] http://stackoverflow.com/questions/6981594/sys-argv-as-bytes-in-python-3k/

----------
assignee: docs at python
components: Documentation, Unicode
messages: 181239
nosy: docs at python, ezio.melotti, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: sys.argv docs should explaining how to handle encoding issues
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Feb  3 09:46:35 2013
From: report at bugs.python.org (Ned Deily)
Date: Sun, 03 Feb 2013 08:46:35 +0000
Subject: [New-bugs-announce] [issue17111] test_surrogates of test_fileio
	fails sometimes on OS X	10.4
Message-ID: <1359881195.85.0.467111019736.issue17111@psf.upfronthosting.co.za>


New submission from Ned Deily:

Seen on "X86 Tiger 2.7" buildbot (http://buildbot.python.org/all/builders/x86%20Tiger%202.7)

test_surrogates (test.test_fileio.OtherFileTests) ... test test_fileio failed -- Traceback (most recent call last):
  File "/Users/db3l/buildarea/2.7.bolen-tiger/build/Lib/test/test_fileio.py", line 455, in test_surrogates
    self.fail('Bad output: %r' % out)
AssertionError: Bad output: 'Traceback (most recent call last):\n  File "<string>", line 1, in <module>\nIOError: [Errno 22] Invalid argument: \'\\xed\\xb2\\x80.txt\'\n[20282 refs]\n'

Looking into it a bit, the test attempts to open a file with a filename containing surrogates.  On OS X 10.4 (Tiger), an attempt to open such a file on a standard HFS+ file system appears to always fail with the above error 22 (EINVAL), rather than error 2 (ENOENT) "No such file or directory" as the test expects and as more recent versions of OS X do.  So the test should probably be changed to expect either error code.  I'm attaching a patch that should do that.

However, there is another issue.  The test does not always fail on 10.4 as one would expect.  The test on the buildbot sometimes succeeds.  On my own 10.4 system, while I predictably receive an EINVAL when attempting to open the file, running test_fileio in isolation seems to always pass and it's not obvious why it does.  The first part of the test, the local open fails as expected but, without the patch, the test of an open in a subprocess passes when it should be failing.  But I was able to reproduce the Error 22 failure, as seen on the buildbot failures, with the same interpreter build by using a --randseed value from one of the buildbot failures.  So there appears to be a test interaction problem here as well (environment variables?).

/python.exe -Wd -3 -E -tt  -R ./Lib/test/regrtest.py -uall -rwW --randseed=2535964

----------
components: Tests
files: issue_XXXXX_test_fileio.patch
keywords: buildbot, needs review, patch
messages: 181246
nosy: ned.deily
priority: normal
severity: normal
stage: patch review
status: open
title: test_surrogates of test_fileio fails sometimes on OS X 10.4
versions: Python 2.7
Added file: http://bugs.python.org/file28937/issue_XXXXX_test_fileio.patch

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

From report at bugs.python.org  Sun Feb  3 10:27:28 2013
From: report at bugs.python.org (Ned Deily)
Date: Sun, 03 Feb 2013 09:27:28 +0000
Subject: [New-bugs-announce] [issue17112] Some doctest-based tests fail when
	run with python -OO
Message-ID: <1359883648.75.0.520386861217.issue17112@psf.upfronthosting.co.za>


New submission from Ned Deily:

Seen on the AMD64 Mountain Lion Optimized [SB] 2.7 buildbot
(http://buildbot.python.org/all/builders/AMD64%20Mountain%20Lion%20Optimized%20%5BSB%5D%202.7):

test test_doctest crashed -- <type 'exceptions.AssertionError'>: filter ('backquote not supported', SyntaxWarning) did not catch any warning
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 896, in runtest_inner
  File "/Users/cpython/buildslave/optimized/2.7.snakebite-mountainlion-amd64-optimized/build/Lib/test/test_doctest.py", line 2684, in test_main
    test_support.run_doctest(test_doctest, verbosity=True)
  File "/Users/cpython/buildslave/optimized/2.7.snakebite-mountainlion-amd64-optimized/build/Lib/contextlib.py", line 24, in __exit__
    self.gen.next()
  File "/Users/cpython/buildslave/optimized/2.7.snakebite-mountainlion-amd64-optimized/build/Lib/test/test_support.py", line 641, in _filterwarnings
    missing[0])
AssertionError: filter ('backquote not supported', SyntaxWarning) did not catch any warning

The same failure is seen in test_syntax and test_zipimport_support.

That buildbot builds the interpreter --with-pydebug but runs the test suite with -OO:

./python.exe -Wd -3 -E -tt -OO -R ./Lib/test/regrtest.py -uall -rwW

I am able to reproduce the buildbot failures when run as above.  Without "-OO", the tests no longer fail.

----------
components: Tests
keywords: buildbot
messages: 181253
nosy: ned.deily
priority: normal
severity: normal
status: open
title: Some doctest-based tests fail when run with python -OO
versions: Python 2.7

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

From report at bugs.python.org  Sun Feb  3 14:45:40 2013
From: report at bugs.python.org (Roy Smith)
Date: Sun, 03 Feb 2013 13:45:40 +0000
Subject: [New-bugs-announce] [issue17113]
	argparse.RawDescriptionHelpFormatter should not delete	blank lines
Message-ID: <1359899140.94.0.20575006786.issue17113@psf.upfronthosting.co.za>


New submission from Roy Smith:

The following code, when run with "--help", omits the trailing newlines from the epilog.  It should just emit the string verbatim.  If the developer didn't want the extra newlines, he/she wouldn't have put them there.


import argparse
parser = argparse.ArgumentParser(formatter_class=argparse.RawDescriptionHelpFormatter,
                                 epilog="foo\n\n")
parser.parse_args()

----------
components: Library (Lib)
messages: 181267
nosy: roysmith
priority: normal
severity: normal
status: open
title: argparse.RawDescriptionHelpFormatter should not delete blank lines
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Feb  3 15:37:13 2013
From: report at bugs.python.org (Swarnkar Rajesh)
Date: Sun, 03 Feb 2013 14:37:13 +0000
Subject: [New-bugs-announce] [issue17114] Python IDLE GUI does not open in
	Ubuntu 12.04
Message-ID: <1359902233.91.0.660945180349.issue17114@psf.upfronthosting.co.za>


New submission from Swarnkar Rajesh:

[Hello all. Just registered to ask this.]

I insatlled python 3.2 from Ubuntu Software Center. 
It created python Icon in launcher as expected. 

It was working fine until i customized the IDLE theme. I edited the 
config-highlight.cfg found in /home/user/.idlerc (hidden) directory. 
I copy pasted desert color theme into this file and pressed save.(I perfectly edited file with leaving one newline at end. So it is not issue with editing i believe.) 

Then i closed the editor. When i tried running by clicking 'IDLE (Using Python 3.2)' in Ubuntu launcher, it glows for a while then nothing shows up. 
I could see a process name python running in system monitor, but no IDLE window.

I tried these issues : 
4049
15998
8099
7265

But all these issues are related to windows OS. 
I tried follwing the similar instruction but i see three directories in /usr/lib/ as python2.7, python3 and python3.2. I am stuck at this point. So i did not choose to proceed. :S

Can you please see into it? Thank you.

----------
components: IDLE
messages: 181271
nosy: rjs.swarnkar
priority: normal
severity: normal
status: open
title: Python IDLE GUI does not open in Ubuntu 12.04
versions: Python 3.2

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

From report at bugs.python.org  Sun Feb  3 17:47:26 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 03 Feb 2013 16:47:26 +0000
Subject: [New-bugs-announce] [issue17115] __loader__ = None should be fine
Message-ID: <1359910046.95.0.667824237181.issue17115@psf.upfronthosting.co.za>


New submission from Brett Cannon:

There is no reason __loader__ can't be set to None like __package__. That means having xml.parsers.expat.(model|errors) set the attribute to None by default (and thus removing the exemption for those modules from test_importlib.test_api.StartupTests), updating the decorators in importlib.util to set __loader__ when it is None, and make importlib.find_loader() treat None the same as if the attribute isn't set (e.g. unifying the raising of ValueError in both cases).

This will bring __loader__ back in alignment with __package__.

In all honesty I would like to tweak imp.new_module()/PyModule_Create() to set both __package__ and __loader__ to None by default, but I don't know how much code out there relies on the absence of these attributes and not on them being set to None (although fixing all of that code is simply transitioning from hasattr(module, '__loader__') to getattr(module, '__loader__', None)). Luckily PEP 302 was updated a couple versions back to state the loaders **must** set these attributes, so hopefully as time goes on this will be less of a worry.

----------
assignee: brett.cannon
messages: 181279
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: __loader__ = None should be fine
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Feb  3 17:47:37 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 03 Feb 2013 16:47:37 +0000
Subject: [New-bugs-announce] [issue17116] xml.parsers.expat.(errors|model)
	don't set the	__loader__ attribute
Message-ID: <1359910057.05.0.356511738926.issue17116@psf.upfronthosting.co.za>


New submission from Brett Cannon:

A new test in test_importlib is discovering that pyexpat is creating both its errors and model modules by hand in pyexpat's initialization function. Should at least set __loader__ to None there.

----------
assignee: brett.cannon
messages: 181280
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: xml.parsers.expat.(errors|model) don't set the __loader__ attribute
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Feb  3 17:49:34 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 03 Feb 2013 16:49:34 +0000
Subject: [New-bugs-announce] [issue17117] Update
	importlib.util.module_for_loader/set_loader to	set when
	__loader__ = None
Message-ID: <1359910174.55.0.468649614578.issue17117@psf.upfronthosting.co.za>


New submission from Brett Cannon:

The various importlib.util decorators involved with __loader__ should reset the attribute when it is set to None, just like for __package__.

----------
assignee: brett.cannon
components: Library (Lib)
messages: 181281
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Update importlib.util.module_for_loader/set_loader to set when __loader__ = None
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Feb  3 20:10:30 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Feb 2013 19:10:30 +0000
Subject: [New-bugs-announce] [issue17118] Add tests for testing Python-Tcl
	interaction
Message-ID: <1359918630.1.0.399114007008.issue17118@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch adds tests for testing how Python values converted when passed to Tkinter and back. This patch was a part of issue16840, but other issues need this tests.

----------
assignee: serhiy.storchaka
components: Tests, Tkinter
files: tkinter_test_passing_values.patch
keywords: patch
messages: 181286
nosy: gpolo, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add tests for testing Python-Tcl interaction
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28946/tkinter_test_passing_values.patch

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

From report at bugs.python.org  Sun Feb  3 20:35:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Feb 2013 19:35:39 +0000
Subject: [New-bugs-announce] [issue17119] Integer overflow when passing
	large string to Tkinter
Message-ID: <1359920139.05.0.774798858282.issue17119@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Second argument of Tcl_NewUnicodeObj() which specifies a number of characters has type "int". When a large string with more than INT_MAX characters passed to Tkinter this value will overflow. If this parameter is negative, all characters up to the first null character are used (up to the end of string because current string implementation has null character after the end). When string length will be more than UINT_MAX, always only part of string will be converted.

I?propose explicitly check a string length and raise an exception when the length overflows C?int range.

----------
components: Tkinter
messages: 181288
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Integer overflow when passing large string to Tkinter
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Feb  4 06:39:07 2013
From: report at bugs.python.org (RAW)
Date: Mon, 04 Feb 2013 05:39:07 +0000
Subject: [New-bugs-announce] [issue17120] Mishandled _POSIX_C_SOURCE and
	_XOPEN_SOURCE in	pyconfig.h
Message-ID: <1359956347.87.0.611737971795.issue17120@psf.upfronthosting.co.za>


New submission from RAW:

The header file pyconfig.h mishandles the _POSIX_C_SOURCE and _XOPEN_SOURCE preprocessor macros.

For older versions of Python, the pyconfig.h header specifies:

#define _POSIX_C_SOURCE 200112L

and:

#define _XOPEN_SOURCE 600

For newer versions of Python, the pyconfig.h header specifies:

#define _POSIX_C_SOURCE 200809L

and:

#define _XOPEN_SOURCE 700

The Open Group has documentation about these symbols:

http://pubs.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_02.html

In particular, the documentation states:

A POSIX-conforming application should ensure that the feature test macro _POSIX_C_SOURCE is defined before inclusion of any header.

So, having a header file attempting to set _POSIX_C_SOURCE violates this intention.

Yes, I am well aware that the Python documentation says to include Python.h before any standard headers are included.  However, this is still problematic.

In particular, it causes trouble for source code that wishes to include the Python headers and wishes to use declarations that are made visible by setting later values for _POSIX_C_SOURCE and _XOPEN_SOURCE.

I would suggest the pyconfig.h be updated to have something like this:

#if !defined(_POSIX_C_SOURCE) || _POSIX_C_SOURCE < 200112L
#ifdef _POSIX_C_SOURCE
#warning Python expects -D_POSIX_C_SOURCE=200112L or later
#undef _POSIX_C_SOURCE
#endif
#define _POSIX_C_SOURCE 200112L
#endif

and this:

#if !defined(_XOPEN_SOURCE) || _XOPEN_SOURCE < 600
#ifdef _XOPEN_SOURCE
#warning Python expects -D_XOPEN_SOURCE=600 or later
#undef _XOPEN_SOURCE
#endif
#define _XOPEN_SOURCE 600
#endif

----------
components: Library (Lib)
messages: 181309
nosy: RAW
priority: normal
severity: normal
status: open
title: Mishandled _POSIX_C_SOURCE and _XOPEN_SOURCE in pyconfig.h
type: compile error
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Feb  4 11:03:42 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Feb 2013 10:03:42 +0000
Subject: [New-bugs-announce] [issue17121] SSH upload for distutils
Message-ID: <1359972222.78.0.301395503133.issue17121@psf.upfronthosting.co.za>


New submission from Christian Heimes:

In the light of Ruby's recent issues and man in the middle attacks on PyPI (http://www.reddit.com/r/Python/comments/17rfh7/warning_dont_use_pip_in_an_untrusted_network_a/) we should include secure uploads in distutils.

Martin has created a SSH uploader for distutils http://pypi.python.org/pypi/pypissh. I suggest that we include the feature in the next security update for Python 2.6 to 3.3. I'm well aware that this beats the "no new feature" clause but in my opinion "security beats purity".

What do you think?

----------
assignee: eric.araujo
components: Distutils
messages: 181313
nosy: christian.heimes, eric.araujo, gregory.p.smith, gvanrossum, loewis, pitrou, tarek
priority: critical
severity: normal
stage: needs patch
status: open
title: SSH upload for distutils
type: security
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Feb  4 13:29:24 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Feb 2013 12:29:24 +0000
Subject: [New-bugs-announce] [issue17122] Fix and cleanup test_functools
Message-ID: <1359980964.91.0.854026651157.issue17122@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Since changeset fcfaca024160 (issue12428) subclassing of partial actually is not tested (subclassed partial overwritten in setUp() method). The proposed patch fixes this and some other minor issues and cleanup the code.

----------
assignee: serhiy.storchaka
components: Tests
files: test_functools.diff
keywords: patch
messages: 181319
nosy: pitrou, serhiy.storchaka, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Fix and cleanup test_functools
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file28952/test_functools.diff

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

From report at bugs.python.org  Mon Feb  4 17:14:32 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Feb 2013 16:14:32 +0000
Subject: [New-bugs-announce] [issue17123] Add OCSP support to ssl module
Message-ID: <1359994472.8.0.804183286731.issue17123@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Python's ssl module doesn't support OCSP [1]. The example code at [2] doesn't look too complicated. We should consider OCSP at least for 3.4 and may want to backport it to older versions to prevent MITM attacks on PyPI downloads.


[1]http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol)
[2] http://etutorials.org/Programming/secure+programming/Chapter+10.+Public+Key+Infrastructure/10.12+Checking+Revocation+Status+via+OCSP+with+OpenSSL/

----------
components: Extension Modules
messages: 181341
nosy: christian.heimes, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: Add OCSP support to ssl module
type: security
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Feb  4 17:50:54 2013
From: report at bugs.python.org (Dave Jones)
Date: Mon, 04 Feb 2013 16:50:54 +0000
Subject: [New-bugs-announce] [issue17124] import subprocess hangs for ~25
	seconds, 700+ files in dir - py 2.7.3, & 2.6.6
Message-ID: <1359996654.02.0.220330260052.issue17124@psf.upfronthosting.co.za>


New submission from Dave Jones:

import subprocess hangs for ~25 seconds, 700+ files in dir - py 2.7.3, & 2.6.6

I'm running this test from a LiveCD to make sure the environment is relatively clean.

------------------
localhost Desktop # python --version
Python 2.7.3
-------------------  <<<works fine here>>>
localhost Desktop # cat sp.py
#!/usr/bin/python

import subprocess

print "Done......."

-------------------
localhost Desktop # ls -1 | wc -l
7

-------------------
localhost Desktop # time python sp.py 
Done.......

real	0m0.027s
user	0m0.023s
sys	0m0.003s


--- BUT--- <<< This cannot be right>>>
localhost Desktop # mv sp.py  ..
mv: overwrite `../sp.py'? y
localhost Desktop # cd ..
localhost jonesda0 # cat sp.py
#!/usr/bin/python

import subprocess

print "Done......."
localhost jonesda0 # time python sp.py 
100000000
Done.......

real	0m25.336s
user	0m25.270s
sys	0m0.014s
localhost jonesda0 # ls -1 | wc -l
758

Only change is the number of files in the directory.
I have tested this on several different LiveCDs but the results are the same.  Is there some sort of flag I need to know about?

FWIW, I do not see the problem when using python3..

localhost jonesda0 # yum -y install python3
Loaded plugins: fastestmirror, langpacks, presto, refresh-packagekit
...
Installed:
  python3.i686 0:3.1.2-14.fc14                                                                                                         

Dependency Installed:
  python3-libs.i686 0:3.1.2-14.fc14                                                                                                    

Complete!
localhost jonesda0 # time python3 sp.py  ## (print function...duh)
  File "sp.py", line 5
    print "Done......."
                      ^
SyntaxError: invalid syntax

real	0m0.048s
user	0m0.044s
sys	0m0.004s
localhost jonesda0 # vi sp.py 
localhost jonesda0 # time python3 sp.py 
Done.......

real	0m0.091s
user	0m0.084s
sys	0m0.006s

localhost jonesda0 # python3 --version
Python 3.1.2

----------
messages: 181348
nosy: Dave.Jones
priority: normal
severity: normal
status: open
title: import subprocess hangs for ~25 seconds, 700+ files in dir - py 2.7.3, & 2.6.6
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Mon Feb  4 17:51:28 2013
From: report at bugs.python.org (Tyler Crompton)
Date: Mon, 04 Feb 2013 16:51:28 +0000
Subject: [New-bugs-announce] [issue17125] tokenizer.tokenize passes a bytes
	object to	str.startswith
Message-ID: <1359996688.85.0.198838954965.issue17125@psf.upfronthosting.co.za>


New submission from Tyler Crompton:

Line 402 in lib/python3.3/tokenize.py, contains the following line:

    if first.startswith(BOM_UTF8):

BOM_UTF8 is a bytes object. str.startswith does not accept bytes objects. I was able to use tokenize.tokenize only after making the following changes:

Change line 402 to the following:

    if first.startswith(BOM_UTF8.decode()):

Add these two lines at line 374:

        except AttributeError:
            line_string = line

Change line 485 to the following:

            try:
                line = line.decode(encoding)
            except AttributeError:
                pass

I do not know if these changes are correct as I have not fully tested this module after these changes, but it started working for me. This is the meat of my invokation of tokenize.tokenize:

import tokenize

with open('example.py') as file: # opening a file encoded as UTF-8
	for token in tokenize.tokenize(file.readline):
		print(token)

I am not suggesting that these changes are correct, but I do believe that the current implementation is incorrect. I am also unsure as to what other versions of Python are affected by this.

----------
components: Library (Lib)
messages: 181349
nosy: Tyler.Crompton
priority: normal
severity: normal
status: open
title: tokenizer.tokenize passes a bytes object to str.startswith
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Feb  4 18:52:00 2013
From: report at bugs.python.org (ddvento@ucar.edu)
Date: Mon, 04 Feb 2013 17:52:00 +0000
Subject: [New-bugs-announce] [issue17126] test_gdb fails
Message-ID: <1360000320.96.0.343533657729.issue17126@psf.upfronthosting.co.za>


New submission from ddvento at ucar.edu:

Using older versions of gdb failed with the "Unhandled dwarf expression opcode 0xf3" error. Therefore, I am running the latest and greatest gdb v7.5. The first problem is that the tests fail with a:

warning: File "such-and-such" auto-loading has been declined by your `auto-load safe-path\' set to "$debugdir:$datadir/auto-load

Which can be fixed with the creation of the file ~/.gdbinit containing the following line:
set auto-load safe-path / 

After that, many tests are still failing, with more test-dependant issues. To me, at least some these tests seems just making weird assumptions of what the output of gdb should be. See for example test_truncation.



./python Lib/test/regrtest.py -v test_gdb
== CPython 2.7.3 (default, Feb 2 2013, 11:27:13) [GCC 4.7.2]
==   Linux-2.6.32-220.13.1.el6.x86_64-x86_64-with-redhat-6.2-Santiago little-endian
==   /glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/build/test_python_20889
Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0)
test_gdb
test_NULL_instance_dict (test.test_gdb.PrettyPrintTests)
Ensure that a PyInstanceObject with with a NULL in_dict is handled ... FAIL
test_NULL_ob_type (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with NULL ob_type is handled gracefully ... FAIL
test_NULL_ptr (test.test_gdb.PrettyPrintTests)
Ensure that a NULL PyObject* is handled gracefully ... FAIL
test_builtin_function (test.test_gdb.PrettyPrintTests) ... FAIL
test_builtin_method (test.test_gdb.PrettyPrintTests) ... FAIL
test_builtins_help (test.test_gdb.PrettyPrintTests)
Ensure that the new-style class _Helper in site.py can be handled ... FAIL
test_classic_class (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of classic class instances ... FAIL
test_corrupt_ob_type (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a corrupt ob_type is handled gracefully ... FAIL
test_corrupt_tp_flags (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a type with corrupt tp_flags is handled ... FAIL
test_corrupt_tp_name (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a type with corrupt tp_name is handled ... FAIL
test_dicts (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of dictionaries ... FAIL
test_exceptions (test.test_gdb.PrettyPrintTests) ... FAIL
test_frames (test.test_gdb.PrettyPrintTests) ... ok
test_frozensets (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of frozensets ... FAIL
test_getting_backtrace (test.test_gdb.PrettyPrintTests) ... ok
test_int (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of various "int" values ... FAIL
test_lists (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of lists ... FAIL
test_long (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of various "long" values ... FAIL
test_modern_class (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of new-style class instances ... FAIL
test_selfreferential_dict (test.test_gdb.PrettyPrintTests)
Ensure that a reference loop involving a dict doesn't lead proxyval ... FAIL
test_selfreferential_list (test.test_gdb.PrettyPrintTests)
Ensure that a reference loop involving a list doesn't lead proxyval ... FAIL
test_selfreferential_new_style_instance (test.test_gdb.PrettyPrintTests) ... FAIL
test_selfreferential_old_style_instance (test.test_gdb.PrettyPrintTests) ... FAIL
test_sets (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of sets ... FAIL
test_singletons (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of True, False and None ... FAIL
test_strings (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of strings ... FAIL
test_subclassing_list (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of an instance of a list subclass ... FAIL
test_subclassing_tuple (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of an instance of a tuple subclass ... FAIL
test_truncation (test.test_gdb.PrettyPrintTests)
Verify that very long output is truncated ... FAIL
test_tuples (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of tuples ... FAIL
test_unicode (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of unicode values ... FAIL
test_basic_command (test.test_gdb.PyListTests)
Verify that the "py-list" command works ... skipped 'Python was compiled with optimizations'
test_one_abs_arg (test.test_gdb.PyListTests)
Verify the "py-list" command with one absolute argument ... skipped 'Python was compiled with optimizations'
test_two_abs_args (test.test_gdb.PyListTests)
Verify the "py-list" command with two absolute arguments ... skipped 'Python was compiled with optimizations'
test_down_at_bottom (test.test_gdb.StackNavigationTests)
Verify handling of "py-down" at the bottom of the stack ... ok
test_pyup_command (test.test_gdb.StackNavigationTests)
Verify that the "py-up" command works ... skipped 'Python was compiled with optimizations'
test_up_at_top (test.test_gdb.StackNavigationTests)
Verify handling of "py-up" at the top of the stack ... ok
test_up_then_down (test.test_gdb.StackNavigationTests)
Verify "py-up" followed by "py-down" ... skipped 'Python was compiled with optimizations'
test_basic_command (test.test_gdb.PyBtTests)
Verify that the "py-bt" command works ... skipped 'Python was compiled with optimizations'
test_basic_command (test.test_gdb.PyPrintTests)
Verify that the "py-print" command works ... skipped 'Python was compiled with optimizations'
test_print_after_up (test.test_gdb.PyPrintTests) ... skipped 'Python was compiled with optimizations'
test_printing_builtin (test.test_gdb.PyPrintTests) ... skipped 'Python was compiled with optimizations'
test_printing_global (test.test_gdb.PyPrintTests) ... skipped 'Python was compiled with optimizations'
test_basic_command (test.test_gdb.PyLocalsTests) ... skipped 'Python was compiled with optimizations'
test_locals_after_up (test.test_gdb.PyLocalsTests) ... skipped 'Python was compiled with optimizations'

======================================================================
FAIL: test_NULL_instance_dict (test.test_gdb.PrettyPrintTests)
Ensure that a PyInstanceObject with with a NULL in_dict is handled
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 446, in test_NULL_instance_dict
    exptype='Foo')
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 402, in assertSane
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: 'op at entry=<Foo at remote 0x2aaaaaf04560>'
Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=<Foo(an_int=42) at remote 0x2aaaaaf04560>, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=<Foo at remote 0x2aaaaaf04560>, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=<Foo at remote 0x2aaaaaf04560>) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=<Foo at remote 0x2aaaaaf04560>, f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x66a5a0, for file <string>, line 6, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb3bb0, globals=globals at entry={'foo': <Foo at remote 0x2aaaaaf04560>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, locals=locals at entry={'foo': <Foo at remote 0x2aaaaaf04560>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb3bb0, globals=globals at entry={'foo': <Foo at remote 0x2aaaaaf04560>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, locals=locals at entry={'foo': <Foo at remote 0x2aaaaaf04560>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x610410, flags=<optimized out>, locals={'foo': <Foo at remote 0x2aaaaaf04560>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, globals={'foo': <Foo at remote 0x2aaaaaf04560>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "\nclass Foo:\n    pass\nfoo = Foo()\nfoo.an_int = 42\nprint foo\n", start=start at entry=257, globals={'foo': <Foo at remote 0x2aaaaaf04560>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, locals={'foo': <Foo at remote 0x2aaaaaf04560>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, flags=flags at entry=0x7fffffffcab0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "\nclass Foo:\n    pass\nfoo = Foo()\nfoo.an_int = 42\nprint foo\n", flags=flags at entry=0x7fffffffcab0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_NULL_ob_type (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with NULL ob_type is handled gracefully
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 417, in test_NULL_ob_type
    'set op->ob_type=0')
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 402, in assertSane
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: 'op at entry=<unknown at remote 0x61dbc8>'
Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=42, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=<unknown at remote 0x61dbc8>, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=<unknown at remote 0x61dbc8>) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=<unknown at remote 0x61dbc8>, f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print 42\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print 42\n", flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_NULL_ptr (test.test_gdb.PrettyPrintTests)
Ensure that a NULL PyObject* is handled gracefully
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 412, in test_NULL_ptr
    self.assertEqual(gdb_repr, '0x0')
AssertionError: '0x0, op at entry=42' != '0x0'

======================================================================
FAIL: test_builtin_function (test.test_gdb.PrettyPrintTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 549, in test_builtin_function
    self.assertEqual(gdb_repr, '<built-in function len>')
AssertionError: 'op at entry=<built-in function len>' != '<built-in function len>'

======================================================================
FAIL: test_builtin_method (test.test_gdb.PrettyPrintTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 556, in test_builtin_method
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: 'op at entry=<built-in method readlines of file object at remote 0x2aaaaaeba1e0>'
Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=<built-in method readlines of file object at remote 0x2aaaaaeba1e0>, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=<built-in method readlines of file object at remote 0x2aaaaaeba1e0>, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=<built-in method readlines of file object at remote 0x2aaaaaeba1e0>) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=<built-in method readlines of file object at remote 0x2aaaaaeba1e0>, f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a40, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', 'sys': <module at remote 0x2aaaaaea2b78>, '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', 'sys': <module at remote 0x2aaaaaea2b78>, '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', 'sys': <module at remote 0x2aaaaaea2b78>, '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', 'sys': <module at remote 0x2aaaaaea2b78>, '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103f0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', 'sys': <module at remote 0x2aaaaaea2b78>, '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', 'sys': <module at remote 0x2aaaaaea2b78>, '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "import sys; print sys.stdout.readlines\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', 'sys': <module at remote 0x2aaaaaea2b78>, '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', 'sys': <module at remote 0x2aaaaaea2b78>, '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcac0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "import sys; print sys.stdout.readlines\n", flags=flags at entry=0x7fffffffcac0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_builtins_help (test.test_gdb.PrettyPrintTests)
Ensure that the new-style class _Helper in site.py can be handled
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 456, in test_builtins_help
    msg='Unexpected rendering %r' % gdb_repr)
AssertionError: Unexpected rendering 'op at entry=<_Helper at remote 0x2aaaab3ae350>'

======================================================================
FAIL: test_classic_class (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of classic class instances
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 330, in test_classic_class
    msg='Unexpected classic-class rendering %r' % gdb_repr)
AssertionError: Unexpected classic-class rendering 'op at entry=<Foo(an_int=42) at remote 0x2aaaaaf04560>'

======================================================================
FAIL: test_corrupt_ob_type (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a corrupt ob_type is handled gracefully
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 423, in test_corrupt_ob_type
    expvalue=42)
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 402, in assertSane
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: 'op at entry=<unknown at remote 0x61dbc8>'
Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=42, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=<unknown at remote 0x61dbc8>, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=<unknown at remote 0x61dbc8>) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=<unknown at remote 0x61dbc8>, f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print 42\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print 42\n", flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_corrupt_tp_flags (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a type with corrupt tp_flags is handled
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 429, in test_corrupt_tp_flags
    expvalue=42)
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 402, in assertSane
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: 'op at entry=<int at remote 0x61dbc8>'
Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=42, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=<int at remote 0x61dbc8>, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=<int at remote 0x61dbc8>) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=<int at remote 0x61dbc8>, f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print 42\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print 42\n", flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_corrupt_tp_name (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a type with corrupt tp_name is handled
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 435, in test_corrupt_tp_name
    expvalue=42)
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 402, in assertSane
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: 'op at entry=<unknown at remote 0x61dbc8>'
Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=42, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=<unknown at remote 0x61dbc8>, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=<unknown at remote 0x61dbc8>) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=<unknown at remote 0x61dbc8>, f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print 42\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print 42\n", flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_dicts (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of dictionaries
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 221, in test_dicts
    self.assertGdbRepr({})
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 196, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val), gdb_output)
AssertionError: Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry={}, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry={}, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op={}) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry={}, f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print {}\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print {}\n", flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_exceptions (test.test_gdb.PrettyPrintTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 307, in test_exceptions
    "exceptions.RuntimeError('I am an error',)")
AssertionError: "op at entry=exceptions.RuntimeError('I am an error',)" != "exceptions.RuntimeError('I am an error',)"

======================================================================
FAIL: test_frozensets (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of frozensets
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 288, in test_frozensets
    self.assertGdbRepr(frozenset())
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 196, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val), gdb_output)
AssertionError: Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=frozenset([]), fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=frozenset([]), fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=frozenset([])) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=frozenset([]), f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print frozenset([])\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcad0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print frozenset([])\n", flags=flags at entry=0x7fffffffcad0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_int (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of various "int" values
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 200, in test_int
    self.assertGdbRepr(42)
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 196, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val), gdb_output)
AssertionError: Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=42, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=42, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=42) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=42, f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print 42\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print 42\n", flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_lists (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of lists
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 227, in test_lists
    self.assertGdbRepr([])
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 196, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val), gdb_output)
AssertionError: Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=[], fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=[], fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=[]) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=[], f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print []\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print []\n", flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_long (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of various "long" values
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 208, in test_long
    self.assertGdbRepr(0L)
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 196, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val), gdb_output)
AssertionError: Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=0L, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=0L, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=0L) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=0L, f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print 0L\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print 0L\n", flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_modern_class (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of new-style class instances
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 342, in test_modern_class
    msg='Unexpected new-style class rendering %r' % gdb_repr)
AssertionError: Unexpected new-style class rendering 'op at entry=<Foo(an_int=42) at remote 0x2aaaaaee5150>'

======================================================================
FAIL: test_selfreferential_dict (test.test_gdb.PrettyPrintTests)
Ensure that a reference loop involving a dict doesn't lead proxyval
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 477, in test_selfreferential_dict
    self.assertEqual(gdb_repr, "{'foo': {'bar': {...}}}")
AssertionError: "op at entry={'foo': {'bar': {...}}}" != "{'foo': {'bar': {...}}}"

======================================================================
FAIL: test_selfreferential_list (test.test_gdb.PrettyPrintTests)
Ensure that a reference loop involving a list doesn't lead proxyval
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 464, in test_selfreferential_list
    self.assertEqual(gdb_repr, '[3, 4, 5, [...]]')
AssertionError: 'op at entry=[3, 4, 5, [...]]' != '[3, 4, 5, [...]]'

======================================================================
FAIL: test_selfreferential_new_style_instance (test.test_gdb.PrettyPrintTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 503, in test_selfreferential_new_style_instance
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: 'op at entry=<Foo(an_attr=<...>) at remote 0x2aaaaaee5150>'
Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=<Foo(an_attr=<...>) at remote 0x2aaaaaee5150>, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=<Foo(an_attr=<...>) at remote 0x2aaaaaee5150>, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=<Foo(an_attr=<...>) at remote 0x2aaaaaee5150>) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=<Foo(an_attr=<...>) at remote 0x2aaaaaee5150>, f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x66a5a0, for file <string>, line 6, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb3bb0, globals=globals at entry={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaee5150>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <type at remote 0x66a910>, '__doc__': None}, locals=locals at entry={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaee5150>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <type at remote 0x66a910>, '__doc__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb3bb0, globals=globals at entry={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaee5150>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <type at remote 0x66a910>, '__doc__': None}, locals=locals at entry={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaee5150>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <type at remote 0x66a910>, '__doc__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x610410, flags=<optimized out>, locals={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaee5150>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <type at remote 0x66a910>, '__doc__': None}, globals={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaee5150>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <type at remote 0x66a910>, '__doc__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "\nclass Foo(object):\n    pass\nfoo = Foo()\nfoo.an_attr = foo\nprint foo\n", start=start at entry=257, globals={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaee5150>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <type at remote 0x66a910>, '__doc__': None}, locals={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaee5150>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <type at remote 0x66a910>, '__doc__': None}, flags=flags at entry=0x7fffffffcaa0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "\nclass Foo(object):\n    pass\nfoo = Foo()\nfoo.an_attr = foo\nprint foo\n", flags=flags at entry=0x7fffffffcaa0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_selfreferential_old_style_instance (test.test_gdb.PrettyPrintTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 490, in test_selfreferential_old_style_instance
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: 'op at entry=<Foo(an_attr=<...>) at remote 0x2aaaaaf04518>'
Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=<Foo(an_attr=<...>) at remote 0x2aaaaaf04518>, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=<Foo(an_attr=<...>) at remote 0x2aaaaaf04518>, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=<Foo(an_attr=<...>) at remote 0x2aaaaaf04518>) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=<Foo(an_attr=<...>) at remote 0x2aaaaaf04518>, f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x66a5a0, for file <string>, line 6, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb3bb0, globals=globals at entry={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaf04518>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, locals=locals at entry={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaf04518>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb3bb0, globals=globals at entry={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaf04518>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, locals=locals at entry={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaf04518>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x610410, flags=<optimized out>, locals={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaf04518>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, globals={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaf04518>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "\nclass Foo:\n    pass\nfoo = Foo()\nfoo.an_attr = foo\nprint foo\n", start=start at entry=257, globals={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaf04518>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, locals={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaf04518>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, flags=flags at entry=0x7fffffffcab0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "\nclass Foo:\n    pass\nfoo = Foo()\nfoo.an_attr = foo\nprint foo\n", flags=flags at entry=0x7fffffffcab0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_sets (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of sets
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 269, in test_sets
    self.assertGdbRepr(set())
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 196, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val), gdb_output)
AssertionError: Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=set([]), fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=set([]), fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=set([])) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=set([]), f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print set([])\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print set([])\n", flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_singletons (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of True, False and None
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 215, in test_singletons
    self.assertGdbRepr(True)
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 196, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val), gdb_output)
AssertionError: Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=True, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=True, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=True) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=True, f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print True\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print True\n", flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_strings (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of strings
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 232, in test_strings
    self.assertGdbRepr('')
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 196, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val), gdb_output)
AssertionError: Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry='', fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry='', fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op='') at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry='', f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print ''\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print ''\n", flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_subclassing_list (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of an instance of a list subclass
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 355, in test_subclassing_list
    msg='Unexpected new-style class rendering %r' % gdb_repr)
AssertionError: Unexpected new-style class rendering 'op at entry=<Foo(an_int=42) at remote 0x2aaaaaef56d8>'

======================================================================
FAIL: test_subclassing_tuple (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of an instance of a tuple subclass
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 369, in test_subclassing_tuple
    msg='Unexpected new-style class rendering %r' % gdb_repr)
AssertionError: Unexpected new-style class rendering 'op at entry=<Foo(an_int=42) at remote 0x2aaaaaef2530>'

======================================================================
FAIL: test_truncation (test.test_gdb.PrettyPrintTests)
Verify that very long output is truncated
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 523, in test_truncation
    "[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, "
AssertionError: 'op at entry=[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226...(truncated)' != '[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226...(truncated)'

======================================================================
FAIL: test_tuples (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of tuples
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 239, in test_tuples
    self.assertGdbRepr(tuple())
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 196, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val), gdb_output)
AssertionError: Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=(), fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=(), fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=()) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=(), f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print ()\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print ()\n", flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_unicode (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of unicode values
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 246, in test_unicode
    self.assertGdbRepr(u'')
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 196, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val), gdb_output)
AssertionError: Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=u'', fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=u'', fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=u'') at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=u'', f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print u''\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print u''\n", flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


----------------------------------------------------------------------
Ran 45 tests in 5.770s

FAILED (failures=29, skipped=12)
test test_gdb failed -- multiple errors occurred
1 test failed:
    test_gdb

----------
components: Tests
messages: 181358
nosy: ddvento at ucar.edu
priority: normal
severity: normal
status: open
title: test_gdb fails
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb  4 19:28:33 2013
From: report at bugs.python.org (Noah Yetter)
Date: Mon, 04 Feb 2013 18:28:33 +0000
Subject: [New-bugs-announce] [issue17127] multiprocessing.dummy.Pool does
	not accept	maxtasksperchild argument
Message-ID: <1360002513.52.0.4376358205.issue17127@psf.upfronthosting.co.za>


New submission from Noah Yetter:

Python 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)] on win32

Type "help", "copyright", "credits" or "license" for more information.

The docs claim that "multiprocessing.dummy replicates the API of multiprocessing but is no more than a wrapper around the threading module." however dummy's Pool method does not replicate the API of multiprocessing's Pool method:

>>> import inspect
>>> import multiprocessing
>>> inspect.getargspec(multiprocessing.Pool)
ArgSpec(args=['processes', 'initializer', 'initargs', 'maxtasksperchild'], varargs=None, keywords=None, defaults=(None, None, (), None))
>>> import multiprocessing.dummy
>>> inspect.getargspec(multiprocessing.dummy.Pool)
ArgSpec(args=['processes', 'initializer', 'initargs'], varargs=None, keywords=None, defaults=(None, None, ()))

Thus when attempting to downshift from multiprocessing to threading like so...

import multiprocessing.dummy as multiprocessing

...code that supplies the maxtasksperchild argument to Pool() will not run.

----------
components: Library (Lib)
messages: 181365
nosy: Noah.Yetter
priority: normal
severity: normal
status: open
title: multiprocessing.dummy.Pool does not accept maxtasksperchild argument
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon Feb  4 19:31:20 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 04 Feb 2013 18:31:20 +0000
Subject: [New-bugs-announce] [issue17128] OS X system openssl deprecated -
	installer should build	local libssl
Message-ID: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za>


New submission from Ned Deily:

Apple has deprecated use of openssl in OS X due to its unstable API between versions:

"If your app depends on OpenSSL, you should compile OpenSSL yourself and statically link a known version of OpenSSL into your app"

https://developer.apple.com/library/mac/#documentation/security/Conceptual/cryptoservices/GeneralPurposeCrypto/GeneralPurposeCrypto.html

Currently OS X ships with patched versions of libssl 0.9.7 and 0.9.8.  The 32-bit python.org installer links with and dynamically loads 0.9.7 and the 64-/32-bit installer with 0.9.8.

build-installer.py should be enhanced to build and link with its own universal more up-to-date static libssl, as is done for several other OS X-supplied libraries.  Since apparently the openssl upstream builds do not support OS X universal builds, build-installer.py will need to learn how to build each arch separately and lipo them together.

With the current discussion around security issues, are there features in openssl 1.x.x that warrant making this a release blocker for 2.7.4 and 3.2.4?  I should be able to implement and test this over the next few days if so.

Setting to release blocker for release managers' decision.

----------
assignee: ned.deily
components: Build, Macintosh
messages: 181366
nosy: benjamin.peterson, georg.brandl, larry, ned.deily, ronaldoussoren
priority: release blocker
severity: normal
stage: needs patch
status: open
title: OS X system openssl deprecated - installer should build local libssl
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Feb  4 20:32:33 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Feb 2013 19:32:33 +0000
Subject: [New-bugs-announce] [issue17129] Include CA bundle and provide
	access to system's CA
Message-ID: <1360006353.36.0.371711249441.issue17129@psf.upfronthosting.co.za>


New submission from Christian Heimes:

For effective SSL server cert validation a bundle of trustworthy CA certs is required. Most system ship such a bundle but it's not always possible to access the bundle from Python / OpenSSL. Windows and Mac OS X come into my mind. wget and curl ship a copy of Mozilla's CA cert bundle.

The site http://curl.haxx.se/docs/caextract.html explains how to extract the CA certs in PEM format. I suggest that we ship the CA bundle with Python and use a lookup chain:

- user defined path to a cacert directory or cacert.pem file

- cacert directory or PEM file in the user's home directory: 
  cacertdir = os.path.join(site.USER_SITE, os.pardir, "cacert")
  cacertfile = os.path.join(site.USER_SITE, os.pardir, "cacert.pem")

- system's ca cert directory (/etc/ssl/certs on Linux)

- CA cert bundle shipped with the Python installation.

----------
components: Library (Lib)
messages: 181379
nosy: christian.heimes
priority: high
severity: normal
status: open
title: Include CA bundle and provide access to system's CA
type: security
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Feb  5 01:55:00 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Feb 2013 00:55:00 +0000
Subject: [New-bugs-announce] [issue17130] Add runcall() function to
	profile.py and cProfile.py
Message-ID: <1360025700.9.0.591755654441.issue17130@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

The profile module exports convenience functions for run() and runctx(), which wrap the corresponding methods of the Profile object.  But perhaps the most useful method, runcall(), is not wrapped. :-(

----------
messages: 181403
nosy: gvanrossum
priority: normal
severity: normal
stage: needs patch
status: open
title: Add runcall() function to profile.py and cProfile.py
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb  5 10:54:59 2013
From: report at bugs.python.org (S Arrowsmith)
Date: Tue, 05 Feb 2013 09:54:59 +0000
Subject: [New-bugs-announce] [issue17131] subprocess.Popen.terminate can
	raise exception on Posix
Message-ID: <1360058099.4.0.320628892834.issue17131@psf.upfronthosting.co.za>


New submission from S Arrowsmith:

Compare this with the script in #14252:

p = Popen(['/bin/sleep', '1'])
time.sleep(1)
p.terminate()
print p.poll()
p.terminate()

Output is:

0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/subprocess.py", line 1269, in terminate
    self.send_signal(signal.SIGTERM)
  File "/usr/lib/python2.6/subprocess.py", line 1264, in send_signal
    os.kill(self.pid, sig)
OSError: [Errno 3] No such process

The 0 return from poll() indicates that the subprocess ran to completion, rather than being terminated by the first terminate. So the first terminate does nothing, but the second terminate raises an exception. In http://bugs.python.org/issue14252#msg155396 :

"Raising an exception on terminate is a bug."

----------
components: Library (Lib)
messages: 181425
nosy: siona
priority: normal
severity: normal
status: open
title: subprocess.Popen.terminate can raise exception on Posix
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Feb  5 16:08:33 2013
From: report at bugs.python.org (Josh Lee)
Date: Tue, 05 Feb 2013 15:08:33 +0000
Subject: [New-bugs-announce] [issue17132] yield_arg missing from
	symbol.sym_name
Message-ID: <1360076913.18.0.0139666205615.issue17132@psf.upfronthosting.co.za>


New submission from Josh Lee:

>>> symbol.sym_name[337]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 337

It should be 'yield_arg'.

----------
components: Library (Lib)
messages: 181440
nosy: Josh.Lee
priority: normal
severity: normal
status: open
title: yield_arg missing from symbol.sym_name
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb  5 16:14:25 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 05 Feb 2013 15:14:25 +0000
Subject: [New-bugs-announce] [issue17133] ssl.wrap_socket doesn't take
	server_hostname as a kwarg
Message-ID: <1360077265.48.0.644174005672.issue17133@psf.upfronthosting.co.za>


New submission from Vinay Sajip:

The wrap_socket function in ssl.py (unlike the method of the same name in SSLContext) doesn't accept a server_hostname argument, despite the fact that it's a one-liner calling SSLSocket, which does take that argument. It it like this for a reason, or just an oversight?

Unless there is some reason not to do so, I think a server_hostname kwarg should be added to the wrap_socket function.

----------
messages: 181442
nosy: pitrou, vinay.sajip
priority: normal
severity: normal
status: open
title: ssl.wrap_socket doesn't take server_hostname as a kwarg
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb  5 16:29:03 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 05 Feb 2013 15:29:03 +0000
Subject: [New-bugs-announce] [issue17134] Use Windows' certificate store for
	CA certs
Message-ID: <1360078143.8.0.938168290854.issue17134@psf.upfronthosting.co.za>


New submission from Christian Heimes:

I found a recipe how to access the Windows certificate store and dump its content as PEM. The code doesn't look complicated and could be added to _ssl.c

http://fixunix.com/openssl/254866-re-can-openssl-use-windows-certificate-store.html

----------
components: Extension Modules
messages: 181445
nosy: christian.heimes
priority: normal
severity: normal
stage: needs patch
status: open
title: Use Windows' certificate store for CA certs
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb  5 17:09:41 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Feb 2013 16:09:41 +0000
Subject: [New-bugs-announce] [issue17135] imp doc should direct to importlib
Message-ID: <1360080581.61.0.501686856177.issue17135@psf.upfronthosting.co.za>


New submission from ?ric Araujo:

Title says it all.

----------
assignee: docs at python
components: Documentation
messages: 181450
nosy: docs at python, eric.araujo
priority: normal
severity: normal
status: open
title: imp doc should direct to importlib
versions: Python 3.1, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Feb  5 17:24:11 2013
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Tue, 05 Feb 2013 16:24:11 +0000
Subject: [New-bugs-announce] [issue17136] ctypes tests fail with clang on
	non-OS X
Message-ID: <1360081451.14.0.916980822692.issue17136@psf.upfronthosting.co.za>


New submission from Dirkjan Ochtman:

I recently filed http://llvm.org/bugs/show_bug.cgi?id=15153, prompted by https://bugs.gentoo.org/show_bug.cgi?id=427338 (for 2.7, and https://bugs.gentoo.org/show_bug.cgi?id=427330 for 3.2), for which I found http://bugs.python.org/issue9852. Similar issues have subsequently been found in http://bugs.python.org/issue13370. The latter has been fixed in http://hg.python.org/cpython/rev/a425f2697273 (for 2.7 -- other branches were affected as well), but that fix is incorrectly scoped to just OS X.

It looks like clang is actually right here, and gcc is wrong; see their bug at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46942 (clang has a bug for this at http://llvm.org/bugs/show_bug.cgi?id=15153).

----------
components: ctypes
messages: 181454
nosy: djc
priority: normal
severity: normal
status: open
title: ctypes tests fail with clang on non-OS X
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/issue17136>
_______________________________________

From report at bugs.python.org  Tue Feb  5 18:32:22 2013
From: report at bugs.python.org (Jan Lachnitt)
Date: Tue, 05 Feb 2013 17:32:22 +0000
Subject: [New-bugs-announce] [issue17137] Malfunctioning compiled code in
	Python 3.3 x64
Message-ID: <1360085542.96.0.0792349837187.issue17137@psf.upfronthosting.co.za>


New submission from Jan Lachnitt:

Python 3.3 64-bit seems to compile one of my files incorrectly. Specifically, os.path.isdir returns True for a nonexistent folder. The important point is that the code works correctly when it is performed step-by-step in pdb.

Python version:
Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:57:17) [MSC v.1600 64 bit (AMD64)] on win32

OS:
Windows 8 64-bit

The code works fine in Python 3.2.3 32-bit on Windows XP.

My project is quite complex and it interacts with other software packages. I tried to make a reduced test-case but I could not reproduce the problem this way. What files do you need for processing this bug report? Will e.g. the source file in question and the corresponding compiled file (*.pyc) be enough? Or should I upload the whole project here, along with the instructions on how to run it?

----------
messages: 181465
nosy: pepalogik
priority: normal
severity: normal
status: open
title: Malfunctioning compiled code in Python 3.3 x64
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb  5 20:42:25 2013
From: report at bugs.python.org (Gutzwiller)
Date: Tue, 05 Feb 2013 19:42:25 +0000
Subject: [New-bugs-announce] [issue17138] XPath error in
	xml.etree.ElementTree
Message-ID: <1360093345.6.0.651330972741.issue17138@psf.upfronthosting.co.za>


New submission from Gutzwiller:

$ python3
Python 3.3.0 (default, Jan 25 2013, 09:38:18) 
[GCC 4.4.5] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import xml.etree.ElementTree as ET
>>> xml = ET.fromstring("<root><h1>1</h1><p><h1>2</h1></p></root>")
>>> result = xml.find(".//h1[2]")        
>>> print(result)
None

========================================================================
Expected result : "<Element 'h1' at ...>"  (<h1>2</h1>)

----------
components: XML
messages: 181473
nosy: Antoine2008
priority: normal
severity: normal
status: open
title: XPath error in xml.etree.ElementTree
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb  5 22:43:47 2013
From: report at bugs.python.org (Dave)
Date: Tue, 05 Feb 2013 21:43:47 +0000
Subject: [New-bugs-announce] [issue17139] dateTime.now() return format
	missing decimal seconds.
Message-ID: <1360100627.57.0.770779965412.issue17139@psf.upfronthosting.co.za>


New submission from Dave:

Calling datetime.datetime.now() will return only the Date and time to the second w/o the decimal portion when the second increments when also running firefox w/shockwave flash enabled on a windows 7 machine.

  
Example output: 
counter1 is: 23360 time is: 2013-02-05 16:32:24.999000      
counter1 is: 23361 time is: 2013-02-05 16:32:25
counter1 is: 23362 time is: 2013-02-05 16:32:25.002000
Notice the missing decimal value on the middle one.

To reproduce:
Code:
    counter = 0
    while(True):
        counter +=1
            time = datetime.datetime.now()
            numericDateTime = 
            print("counter1 is: " + str(counter) + " time is: " + time)

I can get this to occur every time that firefox is running with Shockwave flash enabled.
datetime.now() works fine w/o firefox running w/shockwave flash enabled.

I believe the datetime.now() should always return the same format.

----------
components: Windows
messages: 181484
nosy: Dave
priority: normal
severity: normal
status: open
title: dateTime.now() return format missing decimal seconds.
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Feb  6 03:08:05 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 06 Feb 2013 02:08:05 +0000
Subject: [New-bugs-announce] [issue17140] Provide a more obvious public
	ThreadPool API
Message-ID: <1360116485.64.0.452267246232.issue17140@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

The multiprocessing module currently provides the "multiprocessing.dummy.ThreadPool" API that exposes the same API as the public multiprocessing.Pool, but is implemented with threads rather than processes. (This is sort of documented - it's existence is implied by the documentation of multiprocessing.dummy, but it doesn't spell out "hey, stdlib ThreadPool implementation!".

Given that this feature is likely useful to many people for parallelising IO bound tasks without migrating to the concurrent.futures API (or where that API doesn't quite fit the use case), it makes sense to make it a more clearly documented feature under a less surprising name.

I haven't looked at the implementation, so I'm not sure how easy it will be to migrate it to a different module, but threading seems like a logical choice given the multiprocessing.ThreadPool vs threading.ThreadPool parallel.

(Honestly, I'd be happier if we moved queue.Queue to threading as well. Having a threading specific data type as a top level module in its own right just makes it harder for people to find for no real reason other than a historical accident)

Alternatively, we could add a "concurrent.pool" module which was little more than:

from multiprocessing import Pool as ProcessPool
from multiprocessing.dummy import ThreadPool

----------
components: Library (Lib)
messages: 181495
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Provide a more obvious public ThreadPool API
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Feb  6 13:38:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 12:38:01 +0000
Subject: [New-bugs-announce] [issue17141] random.vonmisesvariate() hangs for
	large kappa
Message-ID: <1360154281.17.0.94704348847.issue17141@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

random.vonmisesvariate(0, 1e16) hangs.

----------
components: Library (Lib)
messages: 181511
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: random.vonmisesvariate() hangs for large kappa
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Feb  6 15:15:52 2013
From: report at bugs.python.org (Sjoerd Langkemper)
Date: Wed, 06 Feb 2013 14:15:52 +0000
Subject: [New-bugs-announce] [issue17142] test_any calls all() instead of
	any()
Message-ID: <1360160152.63.0.655571539572.issue17142@psf.upfronthosting.co.za>


New submission from Sjoerd Langkemper:

In test_builtin.py, on the fourth in the test_any() function:

self.assertRaises(RuntimeError, all, TestFailingIter())

I think this should be:

self.assertRaises(RuntimeError, any, TestFailingIter())

----------
components: Tests
messages: 181524
nosy: sjoerder
priority: normal
severity: normal
status: open
title: test_any calls all() instead of any()
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Wed Feb  6 16:14:41 2013
From: report at bugs.python.org (Dmitry Jemerov)
Date: Wed, 06 Feb 2013 15:14:41 +0000
Subject: [New-bugs-announce] [issue17143] trace.py uses _warn without
	importing it
Message-ID: <1360163681.51.0.340414481892.issue17143@psf.upfronthosting.co.za>


New submission from Dmitry Jemerov:

trace.py in Python 3.3 standard library uses the _warn function without importing it. As a result, an attempt to use a now-deprecated function fails with a NameError:

> python3
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 trace
>>> trace.modname('')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/trace.py", line 827, in modname
    _warn("The trace.modname() function is deprecated",
NameError: global name '_warn' is not defined

----------
components: Library (Lib)
messages: 181531
nosy: Dmitry.Jemerov
priority: normal
severity: normal
status: open
title: trace.py uses _warn without importing it
versions: Python 3.3

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

From report at bugs.python.org  Wed Feb  6 17:10:32 2013
From: report at bugs.python.org (Danilo Bargen)
Date: Wed, 06 Feb 2013 16:10:32 +0000
Subject: [New-bugs-announce] [issue17144] Distutils: "sdist register upload"
	ignores -r argument
Message-ID: <1360167032.54.0.0794749413911.issue17144@psf.upfronthosting.co.za>


New submission from Danilo Bargen:

Where I work, we use a custom pypi server to upload our internal packages.

With a package that has a setup.py created using setuptools, I can simply issue:

$ python setup.py sdist register upload -r local

...and it will get registered and uploaded to our local server.

If setup.py is using distutils though, this does not work and the -r argument gets ignored. The command above would register and upload the package to pypi.python.org (which can in some situations be a security problem).

As a workaround, this works:

$ python setup.py register -r local
$ python setup.py sdist upload -r local

Tested under Python 2.7...

----------
assignee: eric.araujo
components: Distutils
messages: 181540
nosy: eric.araujo, gwrtheyrn, tarek
priority: normal
severity: normal
status: open
title: Distutils: "sdist register upload" ignores -r argument
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Feb  6 18:12:34 2013
From: report at bugs.python.org (Demian Brecht)
Date: Wed, 06 Feb 2013 17:12:34 +0000
Subject: [New-bugs-announce] [issue17145] memoryview(array.array)
Message-ID: <1360170754.31.0.614797074916.issue17145@psf.upfronthosting.co.za>


New submission from Demian Brecht:

array.array doesn't implement the buffer interface in 2.7, so memoryviews cannot be applied to them. As memoryview has been backported to 2.7, array.array should be updated to support it. Either that, or the 2.7 documentation should be updated to reflect the lack of support for arrays in 2.7 (http://docs.python.org/2.7/c-api/buffer.html).

python3
>>> memoryview(array('I', [1,2,3,4]))
<memory at 0x109e46048>

python
>>> memoryview(array('I', [1,2,3,4]))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot make memory view because object does not have the buffer interface

----------
components: None
messages: 181541
nosy: Demian.Brecht
priority: normal
severity: normal
status: open
title: memoryview(array.array)
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed Feb  6 18:53:27 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 06 Feb 2013 17:53:27 +0000
Subject: [New-bugs-announce] [issue17146] Improve
	test.support.import_fresh_module()
Message-ID: <1360173207.93.0.545038003831.issue17146@psf.upfronthosting.co.za>


New submission from Eric Snow:

(+nosy list from #17037)

In issue 17037 (related to hiding PEP 399 boilerplate), Ezio and Eli recommended improving on the API of import_fresh_module().  I agree that it could be simplified, wrapped, or otherwise improved.

import_fresh_module() is used in the stdlib tests a number of times, primarily to support testing dual-implementations a la PEP 399 (see msg180809).  However, since it is already used for testing at least once module for a non-PEP-399 case (test_bz2), we need to be careful about any changes we'd make.  Changing test_bz2 to not use import_fresh_module() just so we could make it PEP-399 specific doesn't seem right.

Of the test modules that use import_fresh_module(), several pass multiple names for "fresh" and none pass more than one for "blocked".  Presumably a Python module may be accelerated by more than one accelerator module, hence allowing for lists for the two parameters, but none do so *now*.

Consequently, it may be worth doing something like what Eli suggested in msg181515: add another helper function that *is* PEP-399-specific.  Something like this:

def import_pure_and_accelerated_modules(name, *, fresh=(),
                                        accelerated_fresh=None,
                                        accelerators=None):
    if accelerators is None:
        accelerators = ['_' + name]
    if accelerated_fresh is None:
        accelerated_fresh = list(fresh) + list(accelerators)
    py_module = import_fresh_module(name, fresh=fresh, blocked=accelerators)
    acc_module = import_fresh_module(name, fresh=accelerated_fresh)
    return py_module, acc_module

Then you could use it like this:
    
py_module, c_module = import_pure_and_accelerated_modules('module')
py_module, c_module = import_pure_and_accelerated_modules('module', accelerators=['_other'])

Simply refactoring import_fresh_module() to work this way is an option, especially since it is used almost exclusively for PEP 399 compliance.  That way test.support would not grow yet another function.  The new interface would probably look like this:

def import_fresh_module(name, *, fresh=(), accelerated_fresh=None,
                        accelerators=None, blocked=None, deprecated=False):

It would still return a 2-tuple, but the second module would be None.  For the test_bz2 case, the change would be minimal:

bz2, = support.import_fresh_module("bz2", blocked=("threading",))

Why go to all this trouble?  It saves just one line of code.  Well, it also helps with writing and maintenance of dual-implementation tests, which I expect will be a growing segment of the stdlib unit tests as time goes by.

However, ultimately the point it moot if we have a more comprehensive test helper like what's being discussed in issue 17037.

----------
components: Library (Lib)
messages: 181545
nosy: Arfrever, brett.cannon, eli.bendersky, eric.snow, ezio.melotti, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve test.support.import_fresh_module()
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Feb  6 20:14:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 19:14:10 +0000
Subject: [New-bugs-announce] [issue17147] BytesIO should be mentioned in
	SpooledTemporaryFile	documentation
Message-ID: <1360178050.86.0.377232433999.issue17147@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently only StringIO is mentioned (which was inherited from Python 2).

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: SpooledTemporaryFile_document_BytesIO.patch
keywords: patch
messages: 181563
nosy: docs at python, georg.brandl, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: BytesIO should be mentioned in SpooledTemporaryFile documentation
type: compile error
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28983/SpooledTemporaryFile_document_BytesIO.patch

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

From report at bugs.python.org  Wed Feb  6 23:36:10 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 06 Feb 2013 22:36:10 +0000
Subject: [New-bugs-announce] [issue17148] mingw: nt thread model detection
Message-ID: <1360190170.63.0.398498965196.issue17148@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Proposed  patch adds test for NT-threads to configure script . It was part of issue3871 and is related only to threading support.

Unlike previous one new patch avoid changes in code like #if A undef B or similar.
For instance 
- avoid presence of header pthread.h in Python/ceval.c and  Python/thread.c (HAVE_PTHREAD_H dependency)
- avoid detection of function pthread_kill  in Modules/signalmodule.c (HAVE_PTHREAD_KILL)
- avoid sem_open() Modules/_multiprocessing/multiprocessing.c (HAVE_SEM_OPEN)
( see patch for reason to skip those checks at configure time)

----------
components: Build
files: 0001-MINGW-BASE-use-NT-thread-model.patch
keywords: patch
messages: 181576
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: nt thread model detection
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28984/0001-MINGW-BASE-use-NT-thread-model.patch

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

From report at bugs.python.org  Thu Feb  7 10:51:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Feb 2013 09:51:08 +0000
Subject: [New-bugs-announce] [issue17149] random.vonmisesvariate() returns a
	value only on the	half-circle
Message-ID: <1360230668.06.0.640300101338.issue17149@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

random.vonmisesvariate(mu, kappa) returns a value in the range (mu%2pi)-pi/2 to (mu%2pi)+pi/2 for kappa > 1e-6. For kappa <= 1e-6 it returns an uniform random value over the range 0 to 2*pi.

----------
components: Library (Lib)
messages: 181588
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: random.vonmisesvariate() returns a value only on the half-circle
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Feb  7 13:51:07 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Feb 2013 12:51:07 +0000
Subject: [New-bugs-announce] [issue17150] pprint could use line continuation
	for long string	literals
Message-ID: <1360241467.59.0.786252231553.issue17150@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Currently:

>>> pprint.pprint({"a": "xxx " * 50})
{'a': 'xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx '}

It would be nicer if it produced something like:

>>> pprint.pprint({"a": "xxx " * 50})
{'a': 'xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx '
      'xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx '
      'xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx '
      'xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx '
      'xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx '}

(for the record, the real-world use case I encountered was when printing some pyudev data)

----------
components: Library (Lib)
messages: 181599
nosy: fdrake, pitrou
priority: normal
severity: normal
status: open
title: pprint could use line continuation for long string literals
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Feb  7 16:34:19 2013
From: report at bugs.python.org (Franck Michea)
Date: Thu, 07 Feb 2013 15:34:19 +0000
Subject: [New-bugs-announce] [issue17151] Python 3 changement of behavior
	with __ne__:	documentation not updated
Message-ID: <1360251259.3.0.329716783607.issue17151@psf.upfronthosting.co.za>


New submission from Franck Michea:

Hi. As of python 3, behavior of object.__ne__ changed to call (not object.__eq__) if implemented. This changement can be seen in function object_richcompare in file Objects/typeobject.c.

Documentation didn't change though, still saying[1] that "There are no implied relationships among the comparison operators. [...] Accordingly, when defining __eq__(), one should also define __ne__()".

Maybe a paragraph about this new behavior would be fine? I am not sure if last sentence of last paragraph is what it means, but it was already there in python 2 doc so guess no. I am not sure about how to write it so no patch, sorry.

[1] http://docs.python.org/3.3/reference/datamodel.html#object.__eq__

----------
assignee: docs at python
components: Documentation
messages: 181620
nosy: docs at python, kushou
priority: normal
severity: normal
status: open
title: Python 3 changement of behavior with __ne__: documentation not updated
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Feb  7 16:53:40 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 07 Feb 2013 15:53:40 +0000
Subject: [New-bugs-announce] [issue17152] Array module should support
	"boolean" natively
Message-ID: <1360252420.36.0.0246801123884.issue17152@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n:

Array module is used, frequently, as a convenient way of saving a lot of memory. I think we should support "boolean" typeobject natively. Implementation should be trivial and efficient, except methods like "pop()" (a bit convoluted, but doable).

Opinions?.

----------
keywords: easy
messages: 181623
nosy: jcea
priority: normal
severity: normal
status: open
title: Array module should support "boolean" natively
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Feb  7 17:43:21 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 07 Feb 2013 16:43:21 +0000
Subject: [New-bugs-announce] [issue17153] tarfile extract fails when Unicode
	in pathname
Message-ID: <1360255401.83.0.937643629633.issue17153@psf.upfronthosting.co.za>


New submission from Vinay Sajip:

The attached file failing.tar.gz contains a path with UTF-8-encoded Unicode. This causes extractall() to fail, but only when the destination path is Unicode. That's because it leads to a implicit str->unicode conversion using ASCII.

Test script:

import shutil, tarfile, tempfile

tf = tarfile.open('failing.tar.gz', 'r:gz')
workdir = tempfile.mkdtemp()
try:
    # N.B. ensure dest path is Unicode to trigger the failure
    tf.extractall(unicode(workdir))
finally:
    shutil.rmtree(workdir)

Result:

$ python untar.py
Traceback (most recent call last):
  File "untar.py", line 8, in <module>
    tf.extractall(unicode(workdir))
  File "/usr/lib/python2.7/tarfile.py", line 2046, in extractall
    self.extract(tarinfo, path)
  File "/usr/lib/python2.7/tarfile.py", line 2083, in extract
    self._extract_member(tarinfo, os.path.join(path, tarinfo.name))
  File "/usr/lib/python2.7/posixpath.py", line 71, in join
    path += '/' + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 44: ordinal not in range(128)

----------
components: Library (Lib), Unicode
messages: 181631
nosy: ezio.melotti, vinay.sajip
priority: normal
severity: normal
status: open
title: tarfile extract fails when Unicode in pathname
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb  7 18:49:44 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 07 Feb 2013 17:49:44 +0000
Subject: [New-bugs-announce] [issue17154] the 'ignore' pdb command raises
	IndexError
Message-ID: <1360259384.78.0.34764519237.issue17154@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

An 'ignore' pdb command issued without any parameter raises IndexError.

----------
components: Library (Lib)
messages: 181633
nosy: xdegaye
priority: normal
severity: normal
status: open
title: the 'ignore' pdb command raises IndexError
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Feb  7 19:18:25 2013
From: report at bugs.python.org (=?utf-8?q?Germ=C3=A1n_M=2E_Bravo?=)
Date: Thu, 07 Feb 2013 18:18:25 +0000
Subject: [New-bugs-announce] [issue17155] Logging throwing
	UnicodeEncodeError exception
Message-ID: <1360261105.58.0.464994704341.issue17155@psf.upfronthosting.co.za>


New submission from Germ?n M. Bravo:

I've seen *a lot* of people using `logging.exception(exc)` to log exceptions. It all seems okay, until the exc object contains unicode strings, at which point logging throes a UnicodeEncodeError exception.

Example: `exc = Exception(u'operaci\xf3n'); logger.error(exc)` throws an exception, while `exc = Exception(u'operaci\xf3n'); logger.error(u"%s", exc)` does not and works as expected.

The problem for this is in the `_fmt` string in logging being `"%(message)s"`, not `u"%(message)s"`, which ends up getting the string (non-unicode) version of the exception object (returned by `getMessage()`) and failing to apply the formatting since the exception contains unicode.

A solution would be to make the default formatting string a unicode string so the object returned by `getMessage()` (the exception) is converted to unicode by making all formatting strings for logging unicode strings: (could be done for example by changing to `unicode(self._fmt) % record.__dict__` the line logging/__init__.py:467).

Other solution could be to encourage users not to use objects as the first argument to the logging methods, and perhaps even log a warning against it if it's done.

----------
assignee: docs at python
components: Documentation, Unicode
messages: 181640
nosy: Kronuz, docs at python, ezio.melotti
priority: normal
severity: normal
status: open
title: Logging throwing UnicodeEncodeError exception
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb  8 02:31:18 2013
From: report at bugs.python.org (umedoblock)
Date: Fri, 08 Feb 2013 01:31:18 +0000
Subject: [New-bugs-announce] [issue17156] Tools/i18n/pygettext.py doesn't
	parse unicode string.
Message-ID: <1360287078.84.0.489107561293.issue17156@psf.upfronthosting.co.za>


New submission from umedoblock:

I'd like to parse _('?????').
However pygettext.py doesn't parse _('?????').
pygettext.py said me 'IndexError'.
now I attached pygettext.py.patch to fix a bug.
I show you command history.

$ pygettext.py -o - --verbose konnichiha.py
...
#: konnichiha.py:6
msgid "konnichiha"
msgstr ""

#: konnichiha.py:7
Traceback (most recent call last):
  File "/home/umetaro/local/bin/pygettext.py", line 664, in <module>
    main()
  File "/home/umetaro/local/bin/pygettext.py", line 657, in main
    eater.write(fp)
  File "/home/umetaro/local/bin/pygettext.py", line 497, in write
    print('msgid', normalize(k), file=fp)
  File "/home/umetaro/local/bin/pygettext.py", line 250, in normalize
    s = '"' + escape(s) + '"'
  File "/home/umetaro/local/bin/pygettext.py", line 236, in escape
    s[i] = escapes[ord(s[i])]
IndexError: list index out of range

please use pygettext.py.patch.

$ pygettext.py -o - --verbose konnichiha.py
...
#: konnichiha.py:6
msgid "konnichiha"
msgstr ""

#: konnichiha.py:7
msgid "?????"
msgstr ""

----------
components: Demos and Tools
files: konnichiha.py
messages: 181651
nosy: umedoblock
priority: normal
severity: normal
status: open
title: Tools/i18n/pygettext.py doesn't parse unicode string.
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file28991/konnichiha.py

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

From report at bugs.python.org  Fri Feb  8 15:06:31 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 08 Feb 2013 14:06:31 +0000
Subject: [New-bugs-announce] [issue17157] issubclass should accept iterables
Message-ID: <1360332391.97.0.255952166351.issue17157@psf.upfronthosting.co.za>


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


----------
nosy: kushou, ramchandra.apte
priority: normal
severity: normal
status: open
title: issubclass should accept iterables
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Feb  8 15:24:19 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 08 Feb 2013 14:24:19 +0000
Subject: [New-bugs-announce] [issue17158] help() module searcher text
	improvement
Message-ID: <1360333459.38.0.949998343154.issue17158@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

help("modules spam") prints out "Here is a list of matching modules.  Enter any module name to get more help." before it has even found the modules. This gives the impression that it has found the modules yet it hasn't printed the modules yet. I would suggest that it prints "Searching for the matching modules..." without the newline and then once the matching modules have been found prints "done." (End result will have "Searching for the matchine modules... done." Then it should print "Here is a list of matching modules. Enter any ..."

----------
components: Interpreter Core
messages: 181671
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: help() module searcher text improvement
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Feb  8 16:20:30 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 08 Feb 2013 15:20:30 +0000
Subject: [New-bugs-announce] [issue17159] Remove explicit type check
	from	inspect.Signature.from_function()
Message-ID: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

I can't see a reason why Signature.from_function() should explicitly check the type of the object being passed in. As long as the object has all required attributes, it should be accepted.

This is specifically an issue with Cython compiled functions, which are not Python functions but look the same.

----------
components: Library (Lib)
messages: 181674
nosy: scoder
priority: normal
severity: normal
status: open
title: Remove explicit type check from inspect.Signature.from_function()
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Feb  8 17:45:54 2013
From: report at bugs.python.org (ddvento@ucar.edu)
Date: Fri, 08 Feb 2013 16:45:54 +0000
Subject: [New-bugs-announce] [issue17160] test_urllib2net fails
Message-ID: <1360341954.01.0.966595141063.issue17160@psf.upfronthosting.co.za>


New submission from ddvento at ucar.edu:

test_urllib2net fails as follows. Looking at test_urllib2net.py" line 165 does not reveal anything interesting to me

./python Lib/test/regrtest.py -uall -v test_urllib2net
== CPython 2.7.3 (default, Feb 8 2013, 08:28:21) [GCC 4.7.2]
==   Linux-2.6.32-220.13.1.el6.x86_64-x86_64-with-redhat-6.2-Santiago little-endian
==   /glade/scratch/ddvento/build/Python-2.7.3-westmere/build/test_python_7544
Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0)
test_urllib2net
test_custom_headers (test.test_urllib2net.OtherNetworkTests) ... ok
test_file (test.test_urllib2net.OtherNetworkTests) ... ok
test_fileno (test.test_urllib2net.OtherNetworkTests) ... ok
test_ftp (test.test_urllib2net.OtherNetworkTests) ... ok
test_sites_no_connection_close (test.test_urllib2net.OtherNetworkTests) ... ok
test_urlwithfrag (test.test_urllib2net.OtherNetworkTests) ... FAIL
test_close (test.test_urllib2net.CloseSocketTest) ... ok
test_ftp_basic (test.test_urllib2net.TimeoutTest) ... ok
test_ftp_default_timeout (test.test_urllib2net.TimeoutTest) ... ok
test_ftp_no_timeout (test.test_urllib2net.TimeoutTest) ... ok
test_ftp_timeout (test.test_urllib2net.TimeoutTest) ... ok
test_http_basic (test.test_urllib2net.TimeoutTest) ... ok
test_http_default_timeout (test.test_urllib2net.TimeoutTest) ... ok
test_http_no_timeout (test.test_urllib2net.TimeoutTest) ... ok
test_http_timeout (test.test_urllib2net.TimeoutTest) ... ok

======================================================================
FAIL: test_urlwithfrag (test.test_urllib2net.OtherNetworkTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere/Lib/test/test_urllib2net.py", line 165, in test_urlwithfrag
    "http://docs.python.org/glossary.html#glossary")
AssertionError: 'http://docs.python.org/2/glossary.html' != 'http://docs.python.org/glossary.html#glossary'

----------------------------------------------------------------------
Ran 15 tests in 14.684s

FAILED (failures=1)
test test_urllib2net failed -- Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere/Lib/test/test_urllib2net.py", line 165, in test_urlwithfrag
    "http://docs.python.org/glossary.html#glossary")
AssertionError: 'http://docs.python.org/2/glossary.html' != 'http://docs.python.org/glossary.html#glossary'

1 test failed:
    test_urllib2net

----------
components: Tests
messages: 181682
nosy: ddvento at ucar.edu
priority: normal
severity: normal
status: open
title: test_urllib2net fails
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb  8 18:13:21 2013
From: report at bugs.python.org (ddvento@ucar.edu)
Date: Fri, 08 Feb 2013 17:13:21 +0000
Subject: [New-bugs-announce] [issue17161] make install misses the man and
	the static library
Message-ID: <1360343601.69.0.324623766198.issue17161@psf.upfronthosting.co.za>


New submission from ddvento at ucar.edu:

This is for python 2.7.3 built with 

0) ./configure --enable-shared --with-system-expat

1) I need both static and shared object, however libpython2.7.a is not copied in the installation target lib. Is this on purpose, or am I missing a flag in configure?

2) In share/man/man1/ there are two issues:
2a) the manual is for 2.7.1 instead of 2.7.3
2b) the man command looks for a python.1 file, therefore one must issue:
ln -s python2.7.1 python.1

----------
components: Installation
messages: 181684
nosy: ddvento at ucar.edu
priority: normal
severity: normal
status: open
title: make install misses the man and the static library
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb  8 19:27:15 2013
From: report at bugs.python.org (Bradley Froehle)
Date: Fri, 08 Feb 2013 18:27:15 +0000
Subject: [New-bugs-announce] [issue17162] Py_LIMITED_API needs a
	PyType_GenericDealloc
Message-ID: <1360348035.19.0.130949262051.issue17162@psf.upfronthosting.co.za>


New submission from Bradley Froehle:

I tried to implement a custom extension type using PyType_FromSpec and Py_LIMITED_API but couldn't implement tp_dealloc:

static void mytype_dealloc(mytypeobject *self)
{
    // free some fields in mytypeobject
    Py_TYPE(self)->tp_free((PyObject *) self); // XXX
}

The line marked XXX will not compile in Py_LIMITED_API because there is no access to the fields of PyTypeObject.  There doesn't seem to be any function in the API which just calls tp_free.

I suggest the addition of an API function (to be included in Py_LIMITED_API):

void
PyType_GenericDealloc(PyObject *self)
{
    Py_TYPE(self)->tp_free(self);
}

----------
messages: 181689
nosy: bfroehle
priority: normal
severity: normal
status: open
title: Py_LIMITED_API needs a PyType_GenericDealloc
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Feb  8 20:37:33 2013
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 08 Feb 2013 19:37:33 +0000
Subject: [New-bugs-announce] [issue17163] Fix test discovery for test_file.py
Message-ID: <1360352253.75.0.044866485302.issue17163@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Feb  8 22:23:23 2013
From: report at bugs.python.org (Piotr Dobrogost)
Date: Fri, 08 Feb 2013 21:23:23 +0000
Subject: [New-bugs-announce] [issue17164] MozillaCookieJar does not handle
	session cookies
Message-ID: <1360358603.06.0.441613239061.issue17164@psf.upfronthosting.co.za>


New submission from Piotr Dobrogost:

It seems there's no information on how should session cookies be stored in the Netscape/Mozilla's cookies.txt file with regard to expiry time - see http://www.cookiecentral.com/faq/#3.5 Maybe Netscape has not been saving such cookies at all thus this lack of specification? Nevertheless, both wget and curl use 0 as expiry time to denote session cookies; it works both when reading cookies from file and writing to file. However Python's MozillaCookieJar's class uses empty string for the same purpose which makes it incompatible both with wget and curl - see http://hg.python.org/cpython/file/bd8afb90ebf2/Lib/http/cookiejar.py#l2027

I propose to make a change in implementation of MozillaCookieJar class and treat cookies with 0 set as expiry time as session cookies both when reading from a file and writing to a file.

Motivation for this bug report comes from the following question on Stack Overflow - http://stackoverflow.com/q/14742899/95735

----------
components: Library (Lib)
messages: 181703
nosy: piotr.dobrogost
priority: normal
severity: normal
status: open
title: MozillaCookieJar does not handle session cookies
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Feb  9 08:54:38 2013
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 09 Feb 2013 07:54:38 +0000
Subject: [New-bugs-announce] [issue17165] Use "except ImportError" instead
	of bare except in	_strptime.py
Message-ID: <1360396478.11.0.456906472362.issue17165@psf.upfronthosting.co.za>


New submission from Berker Peksag:

See for the source: http://hg.python.org/cpython/file/default/Lib/_strptime.py#l24

and for the reference: http://docs.python.org/dev/library/_dummy_thread.html#module-_dummy_thread

----------
components: Library (Lib)
files: _strptime_importerror.diff
keywords: patch
messages: 181720
nosy: berker.peksag
priority: normal
severity: normal
status: open
title: Use "except ImportError" instead of bare except in _strptime.py
versions: Python 3.4
Added file: http://bugs.python.org/file29014/_strptime_importerror.diff

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

From report at bugs.python.org  Sat Feb  9 09:03:18 2013
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 09 Feb 2013 08:03:18 +0000
Subject: [New-bugs-announce] [issue17166] Fix the suggested usage of
	_dummy_thread module
Message-ID: <1360396998.84.0.582520403426.issue17166@psf.upfronthosting.co.za>


New submission from Berker Peksag:

The "dummy_thread" module has been renamed to "_dummy_thread" in Python 3:

    >>> import dummy_thread
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ImportError: No module named 'dummy_thread'

----------
assignee: docs at python
components: Documentation
files: _dummy_thread-usage.diff
keywords: patch
messages: 181721
nosy: berker.peksag, docs at python
priority: normal
severity: normal
status: open
title: Fix the suggested usage of _dummy_thread module
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29015/_dummy_thread-usage.diff

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

From report at bugs.python.org  Sat Feb  9 10:03:55 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 09 Feb 2013 09:03:55 +0000
Subject: [New-bugs-announce] [issue17167] python man page contains $Date$ in
	page footer
Message-ID: <1360400635.24.0.00924107320182.issue17167@psf.upfronthosting.co.za>


New submission from Ned Deily:

The center footer in the source for the python man page, specifically the .th macro in Misc/python.man, contains an unexpanded $Date$ left over from the days of svn keyword expansions.  Since hg does not support such expansions, either the source should be edited to remove the keyword or the date should be expanded during builds.  One possibility would be to add sed edit steps to the altmaninstall makefile target and to "release.py --export".

----------
components: Build
messages: 181722
nosy: benjamin.peterson, georg.brandl, ned.deily
priority: normal
severity: normal
stage: needs patch
status: open
title: python man page contains $Date$ in page footer
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Feb  9 11:33:53 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sat, 09 Feb 2013 10:33:53 +0000
Subject: [New-bugs-announce] [issue17168] test.support 3.x docs mentions
	stringio.stringio
Message-ID: <1360406033.8.0.21634386544.issue17168@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

StringIO.StringIO has been renamed to io.StringIO in 3.x.
Attached is a patch with the corrected version which mentions io.StringIO.

----------
assignee: docs at python
components: Documentation
files: issue.patch
keywords: patch
messages: 181729
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: test.support 3.x docs mentions stringio.stringio
Added file: http://bugs.python.org/file29016/issue.patch

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

From report at bugs.python.org  Sat Feb  9 15:45:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Feb 2013 14:45:19 +0000
Subject: [New-bugs-announce] [issue17169] Restore errno in tempfile
	exceptions
Message-ID: <1360421119.33.0.506683731542.issue17169@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Before 3.3 if not able to create the name of the temporary file then an OSError with meaninful errno (ENOENT or EEXIST) was raised. Now subclass of OSError raised with errno=None. This is an incompatible change because old user code can catch OSError exception and then test its errno.

Here is a patch which restores errno attribute in these exceptions.

----------
components: Library (Lib)
files: tempfile_errno.patch
keywords: 3.3regression, patch
messages: 181739
nosy: flox, georg.brandl, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Restore errno in tempfile exceptions
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29017/tempfile_errno.patch

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

From report at bugs.python.org  Sat Feb  9 16:59:31 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 09 Feb 2013 15:59:31 +0000
Subject: [New-bugs-announce] [issue17170] string replace is too slow
Message-ID: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

I'm trying to speed up a web template engine and I find that the code needs to do a lot of string replacements of this form:

  name = name.replace('_', '-')

Characteristics of the data: the names are relatively short (1-10 characters usually), and the majority don't contain a '_' at all.

For this combination I've found that the following idiom is significantly faster:

  if '_' in name:
      name = name.replace('_', '-')

I'd hate for that idiom to become popular.  I looked at the code (in the default branch) briefly, but it is already optimized for this case.  So I am at a bit of a loss to explain the speed difference...

Some timeit experiments:

bash-3.2$ ./python.exe -m timeit -s "a = 'hundred'" "'x' in a"
./python.exe -m timeit -s "a = 'hundred'" "'x' in a"

bash-3.2$ ./python.exe -m timeit -s "a = 'hundred'" "a.replace('x', 'y')"
./python.exe -m timeit -s "a = 'hundred'" "a.replace('x', 'y')"

bash-3.2$ ./python.exe -m timeit -s "a = 'hundred'" "if 'x' in a: a.replace('x', 'y')"
./python.exe -m timeit -s "a = 'hundred'" "if 'x' in a: a.replace('x', 'y')"

bash-3.2$ ./python.exe -m timeit -s "a = 'hunxred'" "a.replace('x', 'y')"
./python.exe -m timeit -s "a = 'hunxred'" "a.replace('x', 'y')"

bash-3.2$ ./python.exe -m timeit -s "a = 'hunxred'" "if 'x' in a: a.replace('x', 'y')"
./python.exe -m timeit -s "a = 'hunxred'" "if 'x' in a: a.replace('x', 'y')"

----------
components: Interpreter Core
messages: 181741
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: string replace is too slow
type: performance
versions: Python 3.2

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

From report at bugs.python.org  Sat Feb  9 19:19:45 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 09 Feb 2013 18:19:45 +0000
Subject: [New-bugs-announce] [issue17171] email.encoders.encode7or8bit does
	not work with binary	data
Message-ID: <1360433985.11.0.320523625616.issue17171@psf.upfronthosting.co.za>


New submission from R. David Murray:

Reported by Serhiy in issue 16564:


>>> import io, email
>>> bytesdata = b'\xfa\xfb\xfc\xfd\xfe\xff'
>>> msg = email.mime.application.MIMEApplication(bytesdata, _encoder=encoders.encode_7or8bit)
>>> s = io.BytesIO()
>>> g = email.generator.BytesGenerator(s)
>>> g.flatten(msg)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython3.2/Lib/email/generator.py", line 91, in flatten
    self._write(msg)
  File "/home/serhiy/py/cpython3.2/Lib/email/generator.py", line 137, in _write
    self._dispatch(msg)
  File "/home/serhiy/py/cpython3.2/Lib/email/generator.py", line 163, in _dispatch
    meth(msg)
  File "/home/serhiy/py/cpython3.2/Lib/email/generator.py", line 393, in _handle_text
    if _has_surrogates(msg._payload):
TypeError: can't use a string pattern on a bytes-like object

----------
components: email
messages: 181748
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: email.encoders.encode7or8bit does not work with binary data
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Feb  9 21:32:46 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 09 Feb 2013 20:32:46 +0000
Subject: [New-bugs-announce] [issue17172] Add turtledemo to IDLE menu
Message-ID: <1360441966.18.0.528447885335.issue17172@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The turtledemo is an on-ramp for younger programmers and we should make it easy to launch.

----------
components: IDLE
keywords: easy
messages: 181757
nosy: rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Add turtledemo to IDLE menu
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Feb  9 21:49:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Feb 2013 20:49:59 +0000
Subject: [New-bugs-announce] [issue17173] uses of locale-dependent ctype
	functions
Message-ID: <1360442999.41.0.373385180849.issue17173@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Grepping through the code reveals we are still using a number of locale-dependent C library functions:

Python/mystrtoul.c:102:    while (*str && isspace(Py_CHARMASK(*str)))
Python/mystrtoul.c:141:                while (isspace(Py_CHARMASK(*str)))
Python/mystrtoul.c:269:    while (*str && isspace(Py_CHARMASK(*str)))
Python/formatter_unicode.c:404:    while (pos<end && isdigit(PyUnicode_READ_CHAR(s, pos)))
Python/ast.c:3764:    if (isalpha(quote)) {
Python/dynload_aix.c:144:        while (isdigit(Py_CHARMASK(*message[i]))) message[i]++ ;
Objects/longobject.c:2011:    while (*str != '\0' && isspace(Py_CHARMASK(*str)))
Objects/longobject.c:2255:    while (*str && isspace(Py_CHARMASK(*str)))
Modules/getaddrinfo.c:228:        if (! isdigit(*q))
Modules/_sre.c:153:#define SRE_LOC_IS_DIGIT(ch) (!((ch) & ~255) ? isdigit((ch)) : 0)
Modules/_sre.c:154:#define SRE_LOC_IS_SPACE(ch) (!((ch) & ~255) ? isspace((ch)) : 0)
Modules/_sre.c:156:#define SRE_LOC_IS_ALNUM(ch) (!((ch) & ~255) ? isalnum((ch)) : 0)
Modules/binascii.c:1138:    if (isdigit(c))
Modules/_decimal/libmpdec/io.c:153:            if (!isdigit((uchar)*s))
Modules/_decimal/libmpdec/io.c:157:                    if (!isdigit((uchar)*(s+1)))
Modules/_decimal/libmpdec/io.c:159:                              isdigit((uchar)*(s+2))))
Modules/_decimal/libmpdec/io.c:185:    while (isdigit((uchar)*s))
Modules/_decimal/libmpdec/io.c:825:    if (isdigit((uchar)*cp)) {
Modules/_decimal/libmpdec/io.c:847:        if (!isdigit((uchar)*cp)) {
Modules/_decimal/libmpdec/io.c:1087:    assert(isdigit((uchar)*dp));
Modules/_decimal/libmpdec/io.c:1089:    while (isdigit((uchar)*dp)) {
Modules/_decimal/libmpdec/io.c:1244:    if (isupper((uchar)type)) {
Modules/_struct.c:1273:        if (isspace(Py_CHARMASK(c)))
Modules/_struct.c:1338:        if (isspace(Py_CHARMASK(c)))


Include/pyctype.h has locale-agnostic counterpart (a bit faster probably, too).

----------
components: Extension Modules, Interpreter Core
messages: 181759
nosy: mark.dickinson, pitrou, serhiy.storchaka, skrah
priority: normal
severity: normal
status: open
title: uses of locale-dependent ctype functions
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Feb  9 22:12:37 2013
From: report at bugs.python.org (Thomas Scrace)
Date: Sat, 09 Feb 2013 21:12:37 +0000
Subject: [New-bugs-announce] [issue17174] Posix os.path.join should raise
	TypeError when passed	unusable type
Message-ID: <1360444357.09.0.528759954869.issue17174@psf.upfronthosting.co.za>


New submission from Thomas Scrace:

Currently os.path.join will raise an AttributeError if passed an argument that does not have an endswith() method.

A try/except around the offending line would let us raise a more helpful TypeError:

    except AttributeError as e:
        bad = e.args[0].split()[0]
        raise TypeError("object of type {} is not valid as a path"
        "component".format(type(bad)))

----------
components: Library (Lib)
messages: 181762
nosy: terry.reedy, thomas.scrace
priority: normal
severity: normal
status: open
title: Posix os.path.join should raise TypeError when passed unusable type
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Feb 10 09:38:41 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 10 Feb 2013 08:38:41 +0000
Subject: [New-bugs-announce] [issue17175] update PEP 430
Message-ID: <1360485521.23.0.247947620648.issue17175@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

The issue referred to has since been resolved.

----------
assignee: docs at python
components: Documentation
files: update.diff
keywords: patch
messages: 181778
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: update PEP 430
Added file: http://bugs.python.org/file29025/update.diff

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

From senthil at uthcode.com  Sun Feb 10 20:43:30 2013
From: senthil at uthcode.com (Senthil Kumaran)
Date: Sun, 10 Feb 2013 11:43:30 -0800
Subject: [New-bugs-announce] [issue17158] help() module searcher text
	improvement
In-Reply-To: <1360333459.38.0.949998343154.issue17158@psf.upfronthosting.co.za>
References: <1360333459.38.0.949998343154.issue17158@psf.upfronthosting.co.za>
Message-ID: <CAPOVWOT0jCEHG9FYom3OH5Tf2oQ-p7txYK2khUToWh6cSYc_2A@mail.gmail.com>

You will stumble on that message, only if you give help("module
<somename>") and note that <somename> could be any module in the
PYTHONPATH.
We can change to show the text only if the module is a valid module,
but I think, it is costly do that computation for help text. A better
approach would be:
Modules matching the keyword: <somemodule>

The output can be a list or None.

If you will like to work on a patch, the changes will be in listmodule
function in Lib/pydoc.py

From report at bugs.python.org  Sun Feb 10 20:50:27 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 10 Feb 2013 19:50:27 +0000
Subject: [New-bugs-announce] [issue17176] Document imp.NullImporter is NOT
	used anymore by import
Message-ID: <1360525827.54.0.547409827798.issue17176@psf.upfronthosting.co.za>


New submission from Brett Cannon:

imp.NullImporter should not be claiming that it is still used to fill sys.path_importer_cache on misses.

----------
assignee: brett.cannon
components: Documentation
messages: 181846
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Document imp.NullImporter is NOT used anymore by import
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Feb 10 21:08:31 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 10 Feb 2013 20:08:31 +0000
Subject: [New-bugs-announce] [issue17177] Document/deprecate imp
Message-ID: <1360526911.57.0.856873084515.issue17177@psf.upfronthosting.co.za>


New submission from Brett Cannon:

I need a make a decision as to what (if anything) belongs in imp and then document what stays and deprecate everything else.

Everything in imp falls into one of the following categories:

* From importlib
  - get_magic()
  - source_from_cache()
  - cache_from_source()
* From sys
  - get_tag()
* Platform-implemented
  - lock_held()
  - acquire_lock()
  - release_lock()
  - Undocumented stuff related to builtins, frozen, and load_dynamic()
* Helper
  - reload()

The question is what to keep/expose in imp and what to deprecate. Basically I need to figure out what imp's role is supposed to be in the face of importlib. My gut says either expose platform-dependent stuff and reload() and move the rest to importlib/deprecate, or to completely do away with the module and force people to use the APIs in importlib for consistency (and to stop people from mucking around with import from outside of importlib).

----------
assignee: brett.cannon
components: Library (Lib)
messages: 181849
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Document/deprecate imp
versions: Python 3.4

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

From report at bugs.python.org  Mon Feb 11 06:47:24 2013
From: report at bugs.python.org (py.user)
Date: Mon, 11 Feb 2013 05:47:24 +0000
Subject: [New-bugs-announce] [issue17178] In all.__doc__ and any.__doc__
	need to clarify the	behaviour with an empty iterable like in
	documentation
Message-ID: <1360561644.25.0.289819655691.issue17178@psf.upfronthosting.co.za>


New submission from py.user:

>>> help(all)

"
all(...)
    all(iterable) -> bool
    
    Return True if bool(x) is True for all values x in the iterable.
"

>>> all([])
True
>>> bool()
False
>>>

----------
assignee: docs at python
components: Documentation
messages: 181873
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In all.__doc__ and any.__doc__ need to clarify the behaviour with an empty iterable like in documentation
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Mon Feb 11 09:26:41 2013
From: report at bugs.python.org (Chris Withers)
Date: Mon, 11 Feb 2013 08:26:41 +0000
Subject: [New-bugs-announce] [issue17179] TypeError: type() takes 1 or 3
	arguments
Message-ID: <1360571201.2.0.86006347662.issue17179@psf.upfronthosting.co.za>


New submission from Chris Withers:

>>> from types import new_class
>>> from datetime import datetime
>>> new_class('tdatetime', (datetime, ), kwds={'foo':'bar'})
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/src/Python-3.3.0/Lib/types.py", line 52, in new_class
    return meta(name, bases, ns, **kwds)
TypeError: type() takes 1 or 3 arguments

I'm guessing ns and kwds should be combined before being passed through to meta? (meta is 'type' in this case)

----------
components: Library (Lib)
messages: 181884
nosy: cjw296
priority: normal
severity: normal
status: open
title: TypeError: type() takes 1 or 3 arguments
versions: Python 3.3

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

From report at bugs.python.org  Mon Feb 11 10:10:56 2013
From: report at bugs.python.org (Milko Krachounov)
Date: Mon, 11 Feb 2013 09:10:56 +0000
Subject: [New-bugs-announce] [issue17180] shutil copy* unsafe on POSIX -
	they preserve	setuid/setgit bits
Message-ID: <1360573856.52.0.124531930967.issue17180@psf.upfronthosting.co.za>


New submission from Milko Krachounov:

When copying the mode of a file with copy, copy2, copymode, copystat or copytree, all permission bits are copied (including setuid and setgit), but the owner of the file is not. This can be used for privilege escalation.

An example:

-rwSr--r--  1 milko milko    0 ??? 11 10:53 test1

shutil.copy("test1", "test2")

-rwSr--r--  1 root  root     0 ??? 11 10:53 test2

If test1 contained anything malicious, now the user milko can execute his malicious payload as root.

Potential fixes:
- Strip setuid/setgid bits.
- Copy the owner on POSIX.
- Perform a safety check on the owner.
- Document the security risk.


The behaviour of copymode/copystat in this case is the same as `chmod --reference', and there can be some expectation of unsafety, but copy/copy2/copytree's behaviour differs from that of `cp -p', and this is a non-obvious difference.

----------
components: Library (Lib)
messages: 181885
nosy: milko.krachounov
priority: normal
severity: normal
status: open
title: shutil copy* unsafe on POSIX - they preserve setuid/setgit bits
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Feb 11 11:07:39 2013
From: report at bugs.python.org (Daniel Black)
Date: Mon, 11 Feb 2013 10:07:39 +0000
Subject: [New-bugs-announce] [issue17181] SSLContext.set_servername_callback
	should be able to set	argument
Message-ID: <1360577259.03.0.413727229481.issue17181@psf.upfronthosting.co.za>


New submission from Daniel Black:

I think my original implementation of the SNI callback to see a original sslcontext was wrong. It would be much more useful for the SSLContext.set_servername_callback to take a callable and an object as an argument.

This would allow constructs like the following where self can be used within the callback. Example:

        def cb_sni(ssl_sock, server_name, self):
            self.sniname = server_name

        self.context.set_servername_callback(cb_sni, self)

The original functionality can still occur with:

        self.context.set_servername_callback(cb_sni, self.context)

Agree?

----------
components: Library (Lib)
messages: 181889
nosy: grooverdan, pitrou
priority: normal
severity: normal
status: open
title: SSLContext.set_servername_callback should be able to set argument
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Feb 11 14:59:50 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Feb 2013 13:59:50 +0000
Subject: [New-bugs-announce] [issue17182] signal.default_int_handler should
	set signal number on	the raised exception
Message-ID: <1360591190.95.0.210480467275.issue17182@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Having a dedicated optional attribute on KeyboardInterrupt receiving the signal number would be useful in certain circumstances, for example if you want to propagate the signal to a child process.

----------
components: Extension Modules
messages: 181894
nosy: pitrou
priority: normal
severity: normal
status: open
title: signal.default_int_handler should set signal number on the raised exception
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Feb 11 17:11:08 2013
From: report at bugs.python.org (Guido Reina)
Date: Mon, 11 Feb 2013 16:11:08 +0000
Subject: [New-bugs-announce] [issue17183] Small enhancements to
	Lib/_markupbase.py
Message-ID: <1360599068.18.0.00237006036364.issue17183@psf.upfronthosting.co.za>


New submission from Guido Reina:

In the file: Lib/_markupbase.py, function: "_parse_doctype_element" there is:

if '>' in rawdata[j:]:
    return rawdata.find(">", j) + 1

rawdata[j:] is being scanned twice.

It would be better to do:
pos = rawdata.find(">", j)
if pos != -1:
    return pos + 1


Same thing in the function: "_parse_doctype_attlist":

if ")" in rawdata[j:]:
    j = rawdata.find(")", j) + 1
else:
    return -1

It would be better to do:
pos = rawdata.find(")", j)
if pos != -1:
    j = pos + 1
else:
    return -1

----------
messages: 181903
nosy: guido
priority: normal
severity: normal
status: open
title: Small enhancements to Lib/_markupbase.py
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Feb 11 20:39:08 2013
From: report at bugs.python.org (Roy Smith)
Date: Mon, 11 Feb 2013 19:39:08 +0000
Subject: [New-bugs-announce] [issue17184] re.VERBOSE doesn't respect
	whitespace in '( ?P<foo>...)'
Message-ID: <1360611548.83.0.365452859403.issue17184@psf.upfronthosting.co.za>


New submission from Roy Smith:

# Python 2.7.3
# Ubuntu 12.04

import re
pattern = r"( ?P<phrase>.*)"
regex = re.compile(pattern, re.VERBOSE)

The above raises an exception in re.compile():

Traceback (most recent call last):
  File "./try.py", line 6, in <module>
    regex = re.compile(pattern, re.VERBOSE)
  File "/home/roy/env/python/lib/python2.7/re.py", line 190, in compile
    return _compile(pattern, flags)
  File "/home/roy/env/python/lib/python2.7/re.py", line 242, in _compile
    raise error, v # invalid expression
sre_constants.error: nothing to repeat

The problem appears to be that re.VERBOSE isn't ignoring the space after the "(".

Maybe this is a duplicate of issue15606 ?

----------
components: Library (Lib)
messages: 181927
nosy: roysmith
priority: normal
severity: normal
status: open
title: re.VERBOSE doesn't respect whitespace in '( ?P<foo>...)'
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb 11 23:31:40 2013
From: report at bugs.python.org (Chris Withers)
Date: Mon, 11 Feb 2013 22:31:40 +0000
Subject: [New-bugs-announce] [issue17185] create_autospec
Message-ID: <1360621900.03.0.519438692167.issue17185@psf.upfronthosting.co.za>


New submission from Chris Withers:

Sticking an issue in at Michael's request...

Older versions of mock had a helper called mocksignature.
In newer versions, create_autospec replaces this, but doesn't get it right sometimes:

>>> from inspect import getargspec
>>> from mock import create_autospec
>>> def myfunc(x, y): pass
...
>>> getargspec(myfunc)
ArgSpec(args=['x', 'y'], varargs=None, keywords=None, defaults=None)
>>> getargspec(create_autospec(myfunc))
ArgSpec(args=[], varargs='args', keywords='kwargs', defaults=None)

mocksignature gets it right:

>>> from mock import mocksignature
>>> getargspec(mocksignature(myfunc))
ArgSpec(args=['x', 'y'], varargs=None, keywords=None, defaults=None)

----------
assignee: michael.foord
messages: 181934
nosy: cjw296, michael.foord
priority: normal
severity: normal
status: open
title: create_autospec

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

From report at bugs.python.org  Mon Feb 11 23:35:30 2013
From: report at bugs.python.org (Chris Withers)
Date: Mon, 11 Feb 2013 22:35:30 +0000
Subject: [New-bugs-announce] [issue17186] no way to introspect registered
	atexit handlers
Message-ID: <1360622130.89.0.261803397072.issue17186@psf.upfronthosting.co.za>


New submission from Chris Withers:

Python 2 had a private but usable way of introspecting and manipulating registered atexit handlers by way of the atexit._exithandlers.

In Python 3, registering and unregistering are handled, but there is no longer a way to see what atexit handlers are registered.

Barry suggested filing a bug to have this added as a new feature for Python 3.4. Some kind of read-only sequence would be fine, if the original list can no longer be exposed.

----------
messages: 181935
nosy: cjw296
priority: normal
severity: normal
status: open
title: no way to introspect registered atexit handlers
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb 12 00:54:43 2013
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 11 Feb 2013 23:54:43 +0000
Subject: [New-bugs-announce] [issue17187] Python segfaults from improperly
	formed and called	function
Message-ID: <1360626883.99.0.640748040618.issue17187@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Python 3.3 added a nice new feature: if you don't supply enough positional parameters to a function, it tells you the names of the positional parameters you omitted.

Unfortunately, the code that prints this error message assumes that the function is well-formed.  If I manually create a function using types.CodeType and types.FunctionType, and I don't provide enough entries in the types.CodeType  "varnames" parameter to satisfy all the positional parameters, and I call the resulting function with insufficient parameters, Python crashes.

I've attached a sample script that demonstrates this crash.  I can reproduce it with both 3.3.0 and a recent trunk.  Since this feature wasn't in 3.2 or before, the bug doesn't seem to exist in those versions; I couldn't reproduce with 3.2 or 2.7.

The crash occurs in missing_arguments() in Python/ceval.c, line 3256 in trunk.  The function calls PyTuple_GET_ITEM on the co_varnames tuple without checking that it has sufficient entries.  It gets a crazytown pointer, calls PyObject_Repr on it, and boom.

I've attached a band-aid patch which prevents the crash, but this is almost certainly not the fix we want.  Perhaps types.CodeType should refuse to generate the malformed code object in the first place?

----------
components: Interpreter Core
files: crashy.py
keywords: 3.3regression
messages: 181936
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Python segfaults from improperly formed and called function
type: crash
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29043/crashy.py

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

From report at bugs.python.org  Tue Feb 12 02:19:59 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 12 Feb 2013 01:19:59 +0000
Subject: [New-bugs-announce] [issue17188] Document 'from None' in raise
	statement doc.
Message-ID: <1360631999.8.0.76627095073.issue17188@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Language manual, section 7.8. The raise statement has no mention of the 'from None' option. Indeed it says "if given, the second expression must be another exception class or instance", which would exclude None.

Library manual, Ch 5. Built-in Exceptions, says
'''
When raising a new exception (rather than using a bare raise to re-raise the exception currently being handled), the implicit exception context can be supplemented with an explicit cause by using from with raise:

raise new_exc from original_exc

The expression following from must be an exception or None. It will be set as __cause__ on the raised exception. Setting __cause__ also implicitly sets the __suppress_context__ attribute to True, so that using raise new_exc from None effectively replaces the old exception with the new one for display purposes (e.g. converting KeyError to AttributeError, while leaving the old exception available in __context__ for introspection when debugging.
'''
I am not sure how much should be copied over, but None should be at least mentioned and perhaps there should be a cross-reference.

I am also not sure how much applies to 3.2, but there is no version-added or -changed note with the above.

----------
assignee: docs at python
components: Documentation
messages: 181939
nosy: docs at python, ncoghlan, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Document 'from None' in raise statement doc.
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Feb 12 06:29:24 2013
From: report at bugs.python.org (William Mallard)
Date: Tue, 12 Feb 2013 05:29:24 +0000
Subject: [New-bugs-announce] [issue17189] Add zip64 support to shutil
Message-ID: <1360646964.87.0.900673993367.issue17189@psf.upfronthosting.co.za>


New submission from William Mallard:

This patch enables creation of 64-bit zip files via make_archive().

make_archive uses ZipFile to create zip files. ZipFile already supports creation of 64-bit archives via a kwarg, but make_archive hard-codes it to 32-bit. This patch exposes the option in a backwards compatible way.

----------
components: Library (Lib)
files: shutil_zip64.patch
keywords: patch
messages: 181941
nosy: william.mallard
priority: normal
severity: normal
status: open
title: Add zip64 support to shutil
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file29045/shutil_zip64.patch

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

From report at bugs.python.org  Tue Feb 12 07:14:34 2013
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 12 Feb 2013 06:14:34 +0000
Subject: [New-bugs-announce] [issue17190] _FAST opcodes do no range checking
Message-ID: <1360649674.7.0.74265466328.issue17190@psf.upfronthosting.co.za>


New submission from Larry Hastings:

The implementations for LOAD_FAST, STORE_FAST, and DELETE_FAST don't check that the index is <= the size of fastlocals.  So it's a snap to crash the interpreter with hand-written bytecode, by going past the end of the fastlocals array.  Kaboom!

Attached is a program that demonstrates a crash with each of LOAD_FAST, STORE_FAST, and DELETE_FAST.  These all crashed 2.7, 3.2, 3.3, and a recent trunk.  (Well, two exceptions: LOAD_FAST and DELETE_FAST didn't crash 3.2.  Given the behavior, my suspicion is not that 3.2 is hardened, just that there's something dopey with my thrown-together test.)

It could be that this is not an interesting bug, that policy suggests that anyone who can write their own bytecode is a Consenting Adult.  You tell me.

----------
components: Interpreter Core
files: crashy2.py
messages: 181944
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: _FAST opcodes do no range checking
type: crash
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29046/crashy2.py

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

From report at bugs.python.org  Tue Feb 12 11:47:37 2013
From: report at bugs.python.org (Abram Clark)
Date: Tue, 12 Feb 2013 10:47:37 +0000
Subject: [New-bugs-announce] [issue17191] pdb list shows unexpected code
	when stack frame includes	a try / finally block
Message-ID: <1360666057.12.0.723928905172.issue17191@psf.upfronthosting.co.za>


New submission from Abram Clark:

The list command in pdb shows an unexpected portion of code after an up command enters a try / finally block in the call stack.

To reproduce:

pdb pdb_list_bug_reproduce.py
c
up
list

Expected behavior: Show 11 lines around line 8, "throw_something()", which was the entry point to the lower stack frame.

Actual behavior: Shows code centered around line 10, in the finally block, which is likely cleanup code that has nothing to do with the exception thrown.

----------
files: pdb_list_bug_reproduce.py
messages: 181951
nosy: Abram.Clark
priority: normal
severity: normal
status: open
title: pdb list shows unexpected code when stack frame includes a try / finally block
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file29047/pdb_list_bug_reproduce.py

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

From report at bugs.python.org  Tue Feb 12 14:52:52 2013
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 12 Feb 2013 13:52:52 +0000
Subject: [New-bugs-announce] [issue17192] libffi-3.0.12 import
Message-ID: <1360677172.63.0.353475776128.issue17192@psf.upfronthosting.co.za>


New submission from Matthias Klose:

issue for tracking the libffi-3.0.12 import. checked that builds on x86_64-linux-gnu and arm-linux-gnueabihf do work.

still needs updating/checking the extra copies of:

 - libffi_arm_wince
 - libffi_msvc
 - libffi_osx

----------
components: Extension Modules
messages: 181956
nosy: doko
priority: normal
severity: normal
status: open
title: libffi-3.0.12 import
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb 12 15:54:56 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Feb 2013 14:54:56 +0000
Subject: [New-bugs-announce] [issue17193] Use binary prefixes
Message-ID: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Starting around 1998, a number of standards and trade organizations approved standards and recommendations for a new set of binary prefixes that would refer unambiguously to powers of 1024. According to these, the SI prefixes would only be used in the decimal sense, even when referring to data storage capacities: kilobyte and megabyte would denote one thousand bytes and one million bytes respectively (consistent with SI), while new terms such as kibibyte, mebibyte and gibibyte, abbreviated KiB, MiB, and GiB, would denote 1024 bytes, 1048576 bytes, and 1073741824 bytes respectively.[1]

The proposed patch replaces old terms such as kB or KBytes by new terms such as KiB.

[1] http://en.wikipedia.org/wiki/Binary_prefix

----------
assignee: docs at python
components: Documentation
files: binary_prefixes.patch
keywords: easy, patch
messages: 181961
nosy: docs at python, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use binary prefixes
type: enhancement
Added file: http://bugs.python.org/file29049/binary_prefixes.patch

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

From report at bugs.python.org  Tue Feb 12 17:43:15 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 12 Feb 2013 16:43:15 +0000
Subject: [New-bugs-announce] [issue17194] operator.attrgetter is slow
Message-ID: <1360687395.37.0.294029575872.issue17194@psf.upfronthosting.co.za>


New submission from Florent Xicluna:

When two implementations give the same result, I use to run micro benchmarks to give me an hint.

I just noticed that attrgetter is slower than a lambda here:

$ python3.3 -m timeit -s 'from operator import attrgetter; n1 = attrgetter("__name__"); n2 = lambda s: s.__name__' 'rv = n1(int)'
1000000 loops, best of 3: 0.275 usec per loop
$ python3.3 -m timeit -s 'from operator import attrgetter; n1 = attrgetter("__name__"); n2 = lambda s: s.__name__' 'rv = n2(int)'
1000000 loops, best of 3: 0.347 usec per loop

(verified with 2.6, 2.7 and 3.3. But for 2.5 attrgetter is faster)


The function operator.itemgetter does not have same issue.
$ python3.3 -m timeit -s 'from operator import itemgetter; n1 = itemgetter("foot"); n2 = lambda s: s["foot"]; d = {"foot": 42}' 'rv = n1(d)'
10000000 loops, best of 3: 0.122 usec per loop
$ python3.3 -m timeit -s 'from operator import itemgetter; n1 = itemgetter("foot"); n2 = lambda s: s["foot"]; d = {"foot": 42}' 'rv = n2(d)'
10000000 loops, best of 3: 0.176 usec per loop

----------
messages: 181967
nosy: flox
priority: low
severity: normal
status: open
title: operator.attrgetter is slow
type: performance

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

From report at bugs.python.org  Tue Feb 12 19:16:50 2013
From: report at bugs.python.org (Julian)
Date: Tue, 12 Feb 2013 18:16:50 +0000
Subject: [New-bugs-announce] [issue17195] Reading source code from file on
	exception
Message-ID: <1360693010.27.0.768238405027.issue17195@psf.upfronthosting.co.za>


New submission from Julian:

When an exception occurs and a traceback is printed, the source code is read from the file which leads to confusion when the file has been modified, but the code that produced the exception still had the old code in memory.

----------
components: Interpreter Core
messages: 181971
nosy: Mezgrman
priority: normal
severity: normal
status: open
title: Reading source code from file on exception
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Feb 12 22:33:09 2013
From: report at bugs.python.org (jake)
Date: Tue, 12 Feb 2013 21:33:09 +0000
Subject: [New-bugs-announce] [issue17196] crash
Message-ID: <1360704789.39.0.076255717707.issue17196@psf.upfronthosting.co.za>


New submission from jake:

I have had python 3.3.0 on my mac and have been successfully using it for the past few weeks.  Today in my class I had the program open and it was running fine.  Then suddenly it quit working and shut itself down.  I have restarted my machine multiple times and reinstalled the program over 5 times and it still will not open at all now.  Does anyone know why this might be?  I am currently running OSX 10.8.2 and trying to get the python version 3.3.0 to run.  I am puzzled as to why it would work fine for so long and then suddenly decide to stop and even not open after reinstallation.  I would appreciate it if someone could help me troubleshoot how to get it up and running again.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 181976
nosy: flynn11, ronaldoussoren
priority: normal
severity: normal
status: open
title: crash
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb 12 23:40:09 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 12 Feb 2013 22:40:09 +0000
Subject: [New-bugs-announce] [issue17197] c/profile refactoring
Message-ID: <1360708809.53.0.302633878748.issue17197@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

profile and cProfile modules define the same utility functions (run() and runctx()) which use the same code except the profiler class.
Considering that we're going to add 2 new utility functions (runcall() and runblock(), see issue9285 and issue17130) I think we should refactor the code in order to avoid this code duplication.
Patch in attachment does that.
The approach I came up with looks a bit hackish though so I'd like to get some feedback. Is it acceptable?

----------
files: profile-refactoring.diff
keywords: patch
messages: 181980
nosy: georg.brandl, giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: c/profile refactoring
Added file: http://bugs.python.org/file29053/profile-refactoring.diff

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

From report at bugs.python.org  Wed Feb 13 04:18:18 2013
From: report at bugs.python.org (Philip Jenvey)
Date: Wed, 13 Feb 2013 03:18:18 +0000
Subject: [New-bugs-announce] [issue17198] dbm.whichdbm references
	non-existent 'ndbm'
Message-ID: <1360725498.06.0.499686664826.issue17198@psf.upfronthosting.co.za>


New submission from Philip Jenvey:

There are a couple references to an 'ndbm' variable/module in this function on Python 3.2 and above (and just one reference on default). It appears to be leftover from the 3.x reworking of this module

----------
components: Library (Lib)
messages: 181990
nosy: georg.brandl, pjenvey
priority: normal
severity: normal
stage: needs patch
status: open
title: dbm.whichdbm references non-existent 'ndbm'
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Feb 13 05:47:57 2013
From: report at bugs.python.org (Enrique A Tobis)
Date: Wed, 13 Feb 2013 04:47:57 +0000
Subject: [New-bugs-announce] [issue17199] Slightly wrong behavior
	of	logging.StrFormatStyle.usesTime
Message-ID: <1360730877.2.0.90775500368.issue17199@psf.upfronthosting.co.za>


New submission from Enrique A Tobis:

import logging

f = logging.StrFormatStyle('{asctimer}')
print(f.usesTime())
f = logging.PercentStyle('%(astimer)s')
print(f.usesTime())

prints

True
False

and I think it should print

False
False

----------
components: Library (Lib)
messages: 181992
nosy: etobis
priority: normal
severity: normal
status: open
title: Slightly wrong behavior of logging.StrFormatStyle.usesTime
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Wed Feb 13 06:06:46 2013
From: report at bugs.python.org (Reuben D'Netto)
Date: Wed, 13 Feb 2013 05:06:46 +0000
Subject: [New-bugs-announce] [issue17200] telnetlib.read_until() timeout
	uses the wrong units
Message-ID: <1360732006.1.0.547363663584.issue17200@psf.upfronthosting.co.za>


New submission from Reuben D'Netto:

read_until() takes a value for timeout in seconds, but passes it to poll(), which takes a value in milliseconds.

----------
files: telnetlib.py.patch
keywords: patch
messages: 181993
nosy: Reuben.D'Netto
priority: normal
severity: normal
status: open
title: telnetlib.read_until() timeout uses the wrong units
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file29055/telnetlib.py.patch

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

From report at bugs.python.org  Wed Feb 13 18:04:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Feb 2013 17:04:32 +0000
Subject: [New-bugs-announce] [issue17201] Use allowZip64=True by default
Message-ID: <1360775072.39.0.12779828627.issue17201@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Python supports ZIP64 extension since 2.5 (more 6 years ago). May be it is time to use it by default, leaving the option to disable it by specifying allowZip64=False.

----------
components: Library (Lib)
messages: 182048
nosy: alanmcintyre, loewis, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Use allowZip64=True by default
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Feb 14 07:41:26 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 14 Feb 2013 06:41:26 +0000
Subject: [New-bugs-announce] [issue17202] Add .bat line to .hgeol
Message-ID: <1360824086.93.0.558513852083.issue17202@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Most times (though not all, for some reason) I try to use Doc\make.bat update, it fails with "The system cannot find the batch label specified - update" even though it is obviously there.  The reason for this appears to be the fact that the file uses UNIX line endings[1].  As a fix, I think it would make the most sense to add a "**.bat = CRLF" line to .hgeol.

The attached patch makes that change and includes the changes that that change entails.  The complete list of affected files is as follows:

Doc\make.bat
Lib\ctypes\macholib\fetch_macholib.bat
Lib\idlelib\idle.bat
Modules\_decimal\tests\runall.bat
PCbuild\build.bat
PCbuild\build_env.bat
PCbuild\build_pgo.bat
PCbuild\build_ssl.bat
PCbuild\env.bat
PCbuild\idle.bat
PCbuild\rt.bat
Tools\buildbot\build-amd64.bat
Tools\buildbot\build.bat
Tools\buildbot\buildmsi.bat
Tools\buildbot\clean-amd64.bat
Tools\buildbot\clean.bat
Tools\buildbot\external-amd64.bat
Tools\buildbot\external-common.bat
Tools\buildbot\external.bat
Tools\buildbot\test-amd64.bat
Tools\buildbot\test.bat
Tools\unicode\genwincodecs.bat

As far as I know, there is no reason to believe that the changes to line endings in these files would cause any change to behavior other than possibly avoid strange and random bugs in their execution, particularly in Doc\make.bat.

If we don't want to a blanket rule like this, I think we should at least add a rule for Doc\make.bat to convert it to CRLF line endings to avoid the bug with :update.

Thanks,

Zach

[1] http://stackoverflow.com/questions/232651/why-the-system-cannot-find-the-batch-label-specified-is-thrown-even-if-label-e/232674#232674

----------
components: Windows
files: batch_eol_fix.diff
keywords: patch
messages: 182077
nosy: brian.curtin, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Add .bat line to .hgeol
versions: Python 3.4
Added file: http://bugs.python.org/file29070/batch_eol_fix.diff

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

From report at bugs.python.org  Thu Feb 14 07:47:08 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 14 Feb 2013 06:47:08 +0000
Subject: [New-bugs-announce] [issue17203] add long option names to unittest
	discovery docs
Message-ID: <1360824428.74.0.80014311732.issue17203@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

Currently, unittest's discovery command-line documentation:

http://docs.python.org/dev/library/unittest.html#test-discovery

does not include the long option names (--start-directory, --pattern, and --top-level-directory):

http://hg.python.org/cpython/file/0f827775f7b7/Lib/unittest/main.py#l215

This issue is to add those.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 182078
nosy: chris.jerdonek, docs at python, ezio.melotti, michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: add long option names to unittest discovery docs
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Feb 14 08:01:07 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 14 Feb 2013 07:01:07 +0000
Subject: [New-bugs-announce] [issue17204] argparser's
	subparsers.add_parser() should accept an	ArgumentParser
Message-ID: <1360825267.06.0.240295052102.issue17204@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

Currently, argparser's subparsers.add_parser() method (for adding sub-commands) takes the following input:

"This object has a single method, add_parser(), which takes a command name and any ArgumentParser constructor arguments, and returns an ArgumentParser object that can be modified as usual."

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

It would be nice if one could also pass an ArgumentParser object to add_parser().  This would allow the composition of parsers.  For example, if a library exposed an ArgumentParser command-line API, one could expose that library's commands as a sub-command of the parent project's command-line API using add_parser().

----------
components: Library (Lib)
messages: 182081
nosy: bethard, chris.jerdonek
priority: normal
severity: normal
stage: needs patch
status: open
title: argparser's subparsers.add_parser() should accept an ArgumentParser
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Feb 14 11:56:30 2013
From: report at bugs.python.org (py.user)
Date: Thu, 14 Feb 2013 10:56:30 +0000
Subject: [New-bugs-announce] [issue17205] In the help() function the order
	of methods changes
Message-ID: <1360839390.21.0.289319464698.issue17205@psf.upfronthosting.co.za>


New submission from py.user:

>>> class A:
...   '''class'''
...   def c(self):
...     '''c doc'''
...     pass
...   def b(self):
...     '''b doc'''
...     pass
...   def a(self):
...     '''a doc'''
...     pass
... 
>>> help(A)

class A(builtins.object)
 |  class
 |  
 |  Methods defined here:
 |  
 |  a(self)
 |      a doc
 |  
 |  b(self)
 |      b doc
 |  
 |  c(self)
 |      c doc
 |  
 

When I have many methods ordered in the source in readable order, the help() function is mixing them, so the last method goes to the top and the first method goes to the bottom.

I would like to have an option, whether I want sort them or not.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 182086
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In the help() function the order of methods changes
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu Feb 14 17:07:37 2013
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 14 Feb 2013 16:07:37 +0000
Subject: [New-bugs-announce] [issue17206] Py_XDECREF() expands its argument
	multiple times
Message-ID: <1360858057.09.0.617835061471.issue17206@psf.upfronthosting.co.za>


New submission from Dave Malcolm:

When running my refcount static analyzer [1] on a large corpus of real-world C extension code for Python, I ran into the following construct in various places:

    Py_XDECREF(PyObject_CallObject(callable, args));

This is bogus code: Py_XDECREF expands its argument multiple times, so after this goes through the C preprocessor the callable is actually called invoked up to 4 times, leaking refs to 3 of the results - assuming that none of the calls fail, and a non pydebug build of CPython (which would expand the argument more times).

The raw preprocessor output for an optimized Python 2.7 looks like this:
   do { if ((PyObject_CallObject(callable, args)) == ((void *)0)) ; else do { if ( --((PyObject*)(PyObject_CallObject(callable, args)))->ob_refcnt != 0) ; else ( (*(((PyObject*)((PyObject *)(PyObject_CallObject(callable, args))))->ob_type)->tp_dealloc)((PyObject *)((PyObject *)(PyObject_CallObject(callable, args))))); } while (0); } while (0);

Cleaned up (and removing some of the casts for clarity) it looks like this:
  do { 
    if ((PyObject_CallObject(callable, args)) == ((void *)0))
      ; 
    else 
      do {
        if (--(PyObject_CallObject(callable, args)->ob_refcnt) != 0)
          ;
        else
          (*(PyObject_CallObject(callable, args)->ob_type)->tp_dealloc)
            PyObject_CallObject(callable, args);
      } while (0);
  } while (0);
which is clearly not what the extension author was expecting.

Should we:
  (A) update the macro so that it expands its argument only once, or
  (B) warn people not to write code like the above?

Similar considerations apply to the other macros, I guess, but I've seen the above used "in the wild", I haven't yet seen it for the other macros).

Seen in the wild in:
  python-alsa-1.0.25-1.fc17:
      pyalsa/alsamixer.c:179
    00174 | 	for (i = 0; i < count; i++) { 
    00175 | 		t = PyTuple_New(2); 
    00176 | 		if (t) { 
    00177 | 			PyTuple_SET_ITEM(t, 0, PyInt_FromLong(pfd[i].fd)); 
    00178 | 			PyTuple_SET_ITEM(t, 1, PyInt_FromLong(pfd[i].events)); 
    00179>| 			Py_XDECREF(PyObject_CallObject(reg, t)); 
    00180 | 			Py_DECREF(t); 
    00181 | 		} 
    00182 | 	}	 
    00183 |  
    00184 | 	Py_XDECREF(reg); 

      pyalsa/alsahcontrol.c:190
    00185 | 	for (i = 0; i < count; i++) { 
    00186 | 		t = PyTuple_New(2); 
    00187 | 		if (t) { 
    00188 | 			PyTuple_SET_ITEM(t, 0, PyInt_FromLong(pfd[i].fd)); 
    00189 | 			PyTuple_SET_ITEM(t, 1, PyInt_FromLong(pfd[i].events)); 
    00190>| 			Py_XDECREF(PyObject_CallObject(reg, t)); 
    00191 | 			Py_DECREF(t); 
    00192 | 		} 
    00193 | 	}	 
    00194 |  
    00195 | 	Py_XDECREF(reg); 

      pyalsa/alsaseq.c:3277
    03272 |     for (i = 0; i < count; i++) { 
    03273 |         t = PyTuple_New(2); 
    03274 |         if (t) { 
    03275 |             PyTuple_SET_ITEM(t, 0, PyInt_FromLong(pfd[i].fd)); 
    03276 |             PyTuple_SET_ITEM(t, 1, PyInt_FromLong(pfd[i].events)); 
    03277>|             Py_XDECREF(PyObject_CallObject(reg, t)); 
    03278 |             Py_DECREF(t); 
    03279 |         } 
    03280 |     } 
    03281 |  
    03282 |     Py_XDECREF(reg); 

 python-4Suite-XML-1.0.2-14.fc17:
      Ft/Xml/src/domlette/refcounts.c:80
    00075 |     /* refcount = this */ 
    00076 |     expected = 1; 
    00077 |   } 
    00078 |   else { 
    00079 |     sprintf(buf, "Unexpected object type '%.200s'" ,node->ob_type->tp_name); 
    00080>|     Py_XDECREF(PyObject_CallMethod(tester, "error", "s", buf)); 
    00081 |     return 0; 
    00082 |   } 
    00083 |  
    00084 |   sprintf(buf, "%.200s refcounts", node->ob_type->tp_name); 
    00085 |   return do_test(tester, buf, expected, node->ob_refcnt); 


[Note to self: I actually saw this because it uncovered a traceback in cpychecker, which I fixed as:
http://git.fedorahosted.org/cgit/gcc-python-plugin.git/commit/?id=99fa820487e380b74c2eda1d97facdf2ee6d2f3a ]


[1] https://gcc-python-plugin.readthedocs.org/en/latest/cpychecker.html

----------
components: Interpreter Core
messages: 182107
nosy: dmalcolm
priority: normal
severity: normal
status: open
title: Py_XDECREF() expands its argument multiple times
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/issue17206>
_______________________________________

From brett at python.org  Thu Feb 14 17:32:06 2013
From: brett at python.org (Brett Cannon)
Date: Thu, 14 Feb 2013 11:32:06 -0500
Subject: [New-bugs-announce] [issue17206] Py_XDECREF() expands its
 argument multiple times
In-Reply-To: <1360858057.09.0.617835061471.issue17206@psf.upfronthosting.co.za>
References: <1360858057.09.0.617835061471.issue17206@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W5b2=rraqasTj4tFjfdHRog_DCkHN4iya9p9g04HQS+1g@mail.gmail.com>

On Thu, Feb 14, 2013 at 11:07 AM, Dave Malcolm <report at bugs.python.org>wrote:

>
> New submission from Dave Malcolm:
>
> When running my refcount static analyzer [1] on a large corpus of
> real-world C extension code for Python, I ran into the following construct
> in various places:
>
>     Py_XDECREF(PyObject_CallObject(callable, args));
>

Eww.


>
> This is bogus code: Py_XDECREF expands its argument multiple times, so
> after this goes through the C preprocessor the callable is actually called
> invoked up to 4 times, leaking refs to 3 of the results - assuming that
> none of the calls fail, and a non pydebug build of CPython (which would
> expand the argument more times).
>
> The raw preprocessor output for an optimized Python 2.7 looks like this:
>    do { if ((PyObject_CallObject(callable, args)) == ((void *)0)) ; else
> do { if ( --((PyObject*)(PyObject_CallObject(callable, args)))->ob_refcnt
> != 0) ; else ( (*(((PyObject*)((PyObject *)(PyObject_CallObject(callable,
> args))))->ob_type)->tp_dealloc)((PyObject *)((PyObject
> *)(PyObject_CallObject(callable, args))))); } while (0); } while (0);
>
> Cleaned up (and removing some of the casts for clarity) it looks like this:
>   do {
>     if ((PyObject_CallObject(callable, args)) == ((void *)0))
>       ;
>     else
>       do {
>         if (--(PyObject_CallObject(callable, args)->ob_refcnt) != 0)
>           ;
>         else
>           (*(PyObject_CallObject(callable, args)->ob_type)->tp_dealloc)
>             PyObject_CallObject(callable, args);
>       } while (0);
>   } while (0);
> which is clearly not what the extension author was expecting.
>
> Should we:
>   (A) update the macro so that it expands its argument only once, or
>

How expensive is that going to be? Since there is a 'do' statement using a
temp variable would be easy to introduce, but is a compiler going to be
smart enough to inline it all so it doesn't have to waste an allocation,
etc.?


>   (B) warn people not to write code like the above?
>

Only if (A) is too costly. I would modify a checkout for ALL refcount
macros and run the benchmark suite to see if there is a noticeable
difference. If there isn't then I say change all the macros (can't make one
safe and the rest not as that is just asking for inconsistent usage and
trouble).

-Brett


>
> Similar considerations apply to the other macros, I guess, but I've seen
> the above used "in the wild", I haven't yet seen it for the other macros).
>
> Seen in the wild in:
>   python-alsa-1.0.25-1.fc17:
>       pyalsa/alsamixer.c:179
>     00174 |     for (i = 0; i < count; i++) {
>     00175 |             t = PyTuple_New(2);
>     00176 |             if (t) {
>     00177 |                     PyTuple_SET_ITEM(t, 0,
> PyInt_FromLong(pfd[i].fd));
>     00178 |                     PyTuple_SET_ITEM(t, 1,
> PyInt_FromLong(pfd[i].events));
>     00179>|                     Py_XDECREF(PyObject_CallObject(reg, t));
>     00180 |                     Py_DECREF(t);
>     00181 |             }
>     00182 |     }
>     00183 |
>     00184 |     Py_XDECREF(reg);
>
>       pyalsa/alsahcontrol.c:190
>     00185 |     for (i = 0; i < count; i++) {
>     00186 |             t = PyTuple_New(2);
>     00187 |             if (t) {
>     00188 |                     PyTuple_SET_ITEM(t, 0,
> PyInt_FromLong(pfd[i].fd));
>     00189 |                     PyTuple_SET_ITEM(t, 1,
> PyInt_FromLong(pfd[i].events));
>     00190>|                     Py_XDECREF(PyObject_CallObject(reg, t));
>     00191 |                     Py_DECREF(t);
>     00192 |             }
>     00193 |     }
>     00194 |
>     00195 |     Py_XDECREF(reg);
>
>       pyalsa/alsaseq.c:3277
>     03272 |     for (i = 0; i < count; i++) {
>     03273 |         t = PyTuple_New(2);
>     03274 |         if (t) {
>     03275 |             PyTuple_SET_ITEM(t, 0, PyInt_FromLong(pfd[i].fd));
>     03276 |             PyTuple_SET_ITEM(t, 1,
> PyInt_FromLong(pfd[i].events));
>     03277>|             Py_XDECREF(PyObject_CallObject(reg, t));
>     03278 |             Py_DECREF(t);
>     03279 |         }
>     03280 |     }
>     03281 |
>     03282 |     Py_XDECREF(reg);
>
>  python-4Suite-XML-1.0.2-14.fc17:
>       Ft/Xml/src/domlette/refcounts.c:80
>     00075 |     /* refcount = this */
>     00076 |     expected = 1;
>     00077 |   }
>     00078 |   else {
>     00079 |     sprintf(buf, "Unexpected object type '%.200s'"
> ,node->ob_type->tp_name);
>     00080>|     Py_XDECREF(PyObject_CallMethod(tester, "error", "s", buf));
>     00081 |     return 0;
>     00082 |   }
>     00083 |
>     00084 |   sprintf(buf, "%.200s refcounts", node->ob_type->tp_name);
>     00085 |   return do_test(tester, buf, expected, node->ob_refcnt);
>
>
> [Note to self: I actually saw this because it uncovered a traceback in
> cpychecker, which I fixed as:
>
> http://git.fedorahosted.org/cgit/gcc-python-plugin.git/commit/?id=99fa820487e380b74c2eda1d97facdf2ee6d2f3a]
>
>
> [1] https://gcc-python-plugin.readthedocs.org/en/latest/cpychecker.html
>
> ----------
> components: Interpreter Core
> messages: 182107
> nosy: dmalcolm
> priority: normal
> severity: normal
> status: open
> title: Py_XDECREF() expands its argument multiple times
> 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/issue17206>
> _______________________________________
> _______________________________________________
> New-bugs-announce mailing list
> New-bugs-announce at python.org
> http://mail.python.org/mailman/listinfo/new-bugs-announce
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20130214/e369d34c/attachment.html>

From report at bugs.python.org  Fri Feb 15 00:47:38 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Thu, 14 Feb 2013 23:47:38 +0000
Subject: [New-bugs-announce] [issue17207] string format precision misbehaving
Message-ID: <1360885658.67.0.591874528903.issue17207@psf.upfronthosting.co.za>


New submission from Martin Mokrejs:

Hi,
  I don't know if this is related to issue8040 or not. I find the 2.7 string formatting behavior inconsistent. I found out sometimes I have to divide my number by 100 so that the percentage values get printed correctly. Somehow, when a percent sign appears in the formatting "definition" python magically multiplies the number by 100. But sometimes not. This is not specified in http://docs.python.org/2/library/stdtypes.html#string-formatting so I really do not like this whole thing, sorry to say that.

Some examples, which should have been posted in the Library reference doc above.

$ python
Python 2.7.3 (default, Dec 19 2012, 00:02:12) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> "%s" % 12.7666666667
'12.7666666667'
>>> "%s" % '{:.2%}'.format(12.7666666667)
'1276.67%'
>>> "%s" % '{:.2%}'.format(float(12.7666666667))
'1276.67%'
>>>
>>> "%s" % ( '{:.4%}'.format(12.7666666667) )
'1276.6667%'
>>> "%s" % ( '{:.4}'.format(12.7666666667) )
'12.77'
>>> "%s" % ( '{:.2}'.format(12.7666666667) )
'1.3e+01'
>>> "%s%%" % ( '{:.2}'.format(12.7666666667) )
'1.3e+01%'
>>> "%s%%" % ( '{:.2}'.format('12.7666666667') )
'12%'
>>> "%s%%" % ( '{:.4}'.format(float(12.7666666667)) )
'12.77%'
>>>

>>> "%s" % ( '{:.2%}'.format(1/10) )
'0.00%'
>>> "%s" % ( '{:.2%}'.format(1/10.0) )
'10.00%'
>>> "%s" % ( '{:.2%}'.format(1/10.0 * 100) )
'1000.00%'
>>> "%s" % ( '{:.2%}'.format((1/10.0) * 100) )
'1000.00%'
>>>
>>> "%s" % ( '{:.2}'.format((1/10.0) * 100) )
'1e+01'
>>> "%s" % ( '{:.2%}'.format((1/10.0) * 100) )
'1000.00%'
>>>


1) Would somebody please document the behavior?

2) Would somebody explain how can I print 12.67% (I want precision of 2 places after the decimal dot).

3) Why sometimes using float() fixes the behavior (likely converting int() to float()?

4) But why does the scientific exponential notation sometimes come out?



5) Finally, it would be nice if the python 2.7 docs contained how to format floats to 2 places after the dot using the "old" syntax":

"float=%f" % (12.7666666667)

I would like to get just "12.77" out. I can use round() but that is not what I am asking for. I want to change just the formatting of the output:

>>> round(12.7666666667, 2)
12.77
>>> 


Thank you

----------
components: ctypes
messages: 182125
nosy: mmokrejs
priority: normal
severity: normal
status: open
title: string format precision misbehaving
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb 15 10:24:39 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Feb 2013 09:24:39 +0000
Subject: [New-bugs-announce] [issue17208] add note/warning about daemon
	threads
Message-ID: <1360920279.83.0.716682096448.issue17208@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

People are generally not aware of the properties of daemon threads.
I suggest to add a note such as the following:

? Daemon threads are abruptly stopped at shutdown. Their resources (such as open files, database transactions, etc.) may not be released properly. If you want your threads to stop gracefully, make them non-daemonic and use a suitable signalling mechanism such as an Event. ?

----------
assignee: docs at python
components: Documentation
messages: 182133
nosy: docs at python, pitrou, sbt
priority: normal
severity: normal
status: open
title: add note/warning about daemon threads
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Feb 15 13:34:24 2013
From: report at bugs.python.org (raymontag)
Date: Fri, 15 Feb 2013 12:34:24 +0000
Subject: [New-bugs-announce] [issue17209] get_wch() doesn't handle
	KeyboardInterrupt
Message-ID: <1360931664.77.0.750623076852.issue17209@psf.upfronthosting.co.za>


New submission from raymontag:

If I've initialized a window in curses, try to get a single character with get_wch() and press Ctrl+C, the program crashes even if I handle KeyboardInterrupt. Here's a code example.

import curses

scr = curses.initscr()
try:
    char = scr.get_wch()
except KeyboardInterrupt:
    pass

With getch() instead of get_wch() it works though.

----------
components: Library (Lib)
messages: 182137
nosy: raymontag
priority: normal
severity: normal
status: open
title: get_wch() doesn't handle KeyboardInterrupt
versions: Python 3.3

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

From report at bugs.python.org  Fri Feb 15 14:20:26 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 15 Feb 2013 13:20:26 +0000
Subject: [New-bugs-announce] [issue17210] documentation of
	PyUnicode_Format() states wrong	argument type requirements
Message-ID: <1360934426.3.0.547345278452.issue17210@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

The current documentation says:

"""
PyObject* PyUnicode_Format(PyObject *format, PyObject *args)
    Return value: New reference.

    Return a new string object from format and args; this is analogous to format % args. The args argument must be a tuple.
"""

According to the implementation, however, "args" can be a tuple, a unicode string, or an arbitrary mapping, i.e. everything that Python's "%" operator allows for strings as well.

----------
assignee: docs at python
components: Documentation
messages: 182140
nosy: docs at python, scoder
priority: normal
severity: normal
status: open
title: documentation of PyUnicode_Format() states wrong argument type requirements
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Feb 15 14:40:10 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 15 Feb 2013 13:40:10 +0000
Subject: [New-bugs-announce] [issue17211] pkgutil.iter_modules and
	walk_packages should return a	namedtuple
Message-ID: <1360935610.51.0.788015716935.issue17211@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

Will attach a patch soon.

----------
components: Library (Lib)
messages: 182143
nosy: Ramchandra.Apte
priority: normal
severity: normal
status: open
title: pkgutil.iter_modules and walk_packages should return a namedtuple
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Feb 15 23:49:58 2013
From: report at bugs.python.org (G. Poore)
Date: Fri, 15 Feb 2013 22:49:58 +0000
Subject: [New-bugs-announce] [issue17212] os.path.isfile() in Python 3.3
	sometimes fails
Message-ID: <1360968598.97.0.73683430526.issue17212@psf.upfronthosting.co.za>


New submission from G. Poore:

os.path.isfile() sometimes incorrectly reports that a file does not exist under Python 3.3 (only tested under Windows).  This may be encoding related.  The issue only appears under a very particular set of circumstances; see comments in the attached script.  The attached script demonstrates the issue by testing for an arbitrary file x.txt (you will need to create a file with that name for the test script to work).

----------
components: Library (Lib)
files: os-path-issue-3-3.py
messages: 182188
nosy: gpoore
priority: normal
severity: normal
status: open
title: os.path.isfile() in Python 3.3 sometimes fails
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file29082/os-path-issue-3-3.py

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

From report at bugs.python.org  Sat Feb 16 06:33:20 2013
From: report at bugs.python.org (Daniel Colascione)
Date: Sat, 16 Feb 2013 05:33:20 +0000
Subject: [New-bugs-announce] [issue17213] ctypes loads wrong version of C
	runtime, leading to error message box from system
Message-ID: <1360992800.86.0.617349310494.issue17213@psf.upfronthosting.co.za>


New submission from Daniel Colascione:

Suppose we're running a Python program in an environment where PATH contains a directory that contains msvcr90.dll version A and that python27.exe is manifested to use msvcr90.dll version B, which is available in the SxS store but not on PATH.

Normally, python27.exe's side-by-side (SxS) manifest contains a description of *precisely* the correct version of msvcr90.dll to use, version B, so when python27.exe starts, the NT loader ignores msvcr90.dll version A and loads msvcr90.dll version B.

Everything works fine until somebody calls ctypes.CDLL("c"); uuid.py, which tries to find "uuid_generate_random" in libc on module load, is an example of a component that unexpectedly tries to load libc through ctypes.

Now, when someone tried to load "c", ctypes internally maps "c" to the C runtime library using ctypes.util.find_msvcrt, then calls _ctypes.LoadLibrary, which calls the Win32 API function LoadLibraryA. LoadLibraryA tries to find "msvcr90.dll", but WITHOUT CONSULTING THE SXS ACTIVATION CONTEXT, meaning that LoadLibrary finds msvcr90.dll version A, not version B. msvcr90.dll version A isn't loaded yet, so the NT loader does the usual loading and initialization; msvcr90.dll version A's DllMain runs, notices that it's not being loaded as part of an SxS manifest, and presents the user with an R6034 error message, "an application has made an attempt to laod the C runtime library incorrectly".

The overall result is that users of Python programs see error message popups from "Microsoft Visual C++ Runtime Library" that, in most cases, are completely benign. This problem doesn't occur if the correct version of msvcr90.dll happens to be in PATH.

One solution is to have _ctypes.LoadLibrary use the correct activation context; another is to use GetModuleHandleEx(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS, (LPCTSTR) &fopen, &module) to retrieve a handle to the current C runtime library without having to go through LoadLibrary at all.

----------
components: ctypes
messages: 182212
nosy: dancol
priority: normal
severity: normal
status: open
title: ctypes loads wrong version of C runtime, leading to error message box from system
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sat Feb 16 11:52:39 2013
From: report at bugs.python.org (Mi Zou)
Date: Sat, 16 Feb 2013 10:52:39 +0000
Subject: [New-bugs-announce] [issue17214]
	urllib.client.HTTPConnection.putrequest encode error
Message-ID: <1361011959.8.0.221376430084.issue17214@psf.upfronthosting.co.za>


New submission from Mi Zou:

while urllib following the redirection(302):
urllib.client.HTTPConnection.putrequest raise an error:
#----------------------------------------------------------
  File "D:\Program Files\Python32\lib\http\client.py", line 1004, in _send_request
    self.putrequest(method, url, **skips)
  File "D:\Program Files\Python32\lib\http\client.py", line 868, in putrequest
    self._output(request.encode('ascii'))
UnicodeEncodeError: 'ascii' codec can't encode characters in position 108-111: ordinal not in range(128)
#----------------------------------------------------------
in the sourcode i found that:
at line 811
def putrequest(self, method, url, skip_host=0,skip_accept_encoding=0)...
the argument url may be a unicode,and it was unquoted..

i think we should replace:
request = '%s %s %s' (method,url,self._http_vsn_str)
with:
import urllib.parse
request = '%s %s %s' (method,urllib.parse.quote(url),self._http_vsn_str)

----------
components: Unicode
messages: 182216
nosy: Mi.Zou, ezio.melotti
priority: normal
severity: normal
status: open
title: urllib.client.HTTPConnection.putrequest encode  error
versions: Python 3.2

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

From report at bugs.python.org  Sat Feb 16 13:59:18 2013
From: report at bugs.python.org (July Tikhonov)
Date: Sat, 16 Feb 2013 12:59:18 +0000
Subject: [New-bugs-announce] [issue17215] documentation misprints
Message-ID: <1361019558.88.0.148298585178.issue17215@psf.upfronthosting.co.za>


New submission from July Tikhonov:

library/io.rst
io.open() signature lacks 'opener' argument.

library/importlib.rst
concreate -> concrete

----------
assignee: docs at python
components: Documentation
files: docs-misprint.diff
keywords: patch
messages: 182219
nosy: docs at python, july
priority: normal
severity: normal
status: open
title: documentation misprints
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29086/docs-misprint.diff

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

From report at bugs.python.org  Sat Feb 16 17:02:29 2013
From: report at bugs.python.org (uservorname usernachname)
Date: Sat, 16 Feb 2013 16:02:29 +0000
Subject: [New-bugs-announce] [issue17216] Could not find platform dependent
	libraries <exec_prefix>
Message-ID: <1361030549.85.0.142057307455.issue17216@psf.upfronthosting.co.za>


New submission from uservorname usernachname:

Greetings,

make fails at:
ar rc libpython3.3m.a Objects/abstract.o Objects/accu.o Objects/boolobject.o Objects/bytes_methods.o Objects/bytearrayobject.o Objects/bytesobject.o Objects/cellobject.o Objects/classobject.o Objects/codeobject.o Objects/complexobject.o Objects/descrobject.o Objects/enumobject.o Objects/exceptions.o Objects/genobject.o Objects/fileobject.o Objects/floatobject.o Objects/frameobject.o Objects/funcobject.o Objects/iterobject.o Objects/listobject.o Objects/longobject.o Objects/dictobject.o Objects/memoryobject.o Objects/methodobject.o Objects/moduleobject.o Objects/namespaceobject.o Objects/object.o Objects/obmalloc.o Objects/capsule.o Objects/rangeobject.o Objects/setobject.o Objects/sliceobject.o Objects/structseq.o Objects/tupleobject.o Objects/typeobject.o Objects/unicodeobject.o Objects/unicodectype.o Objects/weakrefobject.o
ar rc libpython3.3m.a Python/_warnings.o Python/Python-ast.o Python/asdl.o Python/ast.o Python/bltinmodule.o Python/ceval.o Python/compile.o Python/codecs.o Python/dynamic_annotations.o Python/errors.o Python/frozenmain.o Python/future.o Python/getargs.o Python/getcompiler.o Python/getcopyright.o Python/getplatform.o Python/getversion.o Python/graminit.o Python/import.o Python/importdl.o Python/marshal.o Python/modsupport.o Python/mystrtoul.o Python/mysnprintf.o Python/peephole.o Python/pyarena.o Python/pyctype.o Python/pyfpe.o Python/pymath.o Python/pystate.o Python/pythonrun.o Python/pytime.o Python/random.o Python/structmember.o Python/symtable.o Python/sysmodule.o Python/traceback.o Python/getopt.o Python/pystrcmp.o Python/pystrtod.o Python/dtoa.o Python/formatter_unicode.o Python/fileutils.o Python/dynload_shlib.o   Python/thread.o Python/frozen.o
ar rc libpython3.3m.a Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o
ar rc libpython3.3m.a Modules/_threadmodule.o  Modules/signalmodule.o  Modules/posixmodule.o  Modules/errnomodule.o  Modules/pwdmodule.o  Modules/_sre.o  Modules/_codecsmodule.o  Modules/_weakref.o  Modules/_functoolsmodule.o  Modules/operator.o  Modules/_collectionsmodule.o  Modules/itertoolsmodule.o  Modules/_localemodule.o  Modules/_iomodule.o Modules/iobase.o Modules/fileio.o Modules/bytesio.o Modules/bufferedio.o Modules/textio.o Modules/stringio.o  Modules/zipimport.o  Modules/faulthandler.o  Modules/symtablemodule.o  Modules/xxsubtype.o
ranlib libpython3.3m.a
gcc -pthread   -Xlinker -export-dynamic -o python Modules/python.o libpython3.3m.a -lpthread -ldl  -lutil   -lm
./python -E -S -m sysconfig --generate-posix-vars
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Could not import runpy module
make: *** [Lib/_sysconfigdata.py] Error 1


What is wrong here? Do you need any other information?

best regards

----------
components: Build
files: config.log
messages: 182232
nosy: uservorname.usernachname
priority: normal
severity: normal
status: open
title: Could not find platform dependent libraries <exec_prefix>
type: compile error
versions: Python 3.3
Added file: http://bugs.python.org/file29089/config.log

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

From report at bugs.python.org  Sun Feb 17 00:02:28 2013
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 16 Feb 2013 23:02:28 +0000
Subject: [New-bugs-announce] [issue17217] Fix test discovery for
	test_format.py on Windows
Message-ID: <1361055748.87.0.775684522637.issue17217@psf.upfronthosting.co.za>


New submission from Zachary Ware:

test_format is an interesting case in the ongoing test discovery conversion.  It already uses unittest.main(), but still has test_main(), and discovery seems to work fine on Linux.  On Windows, however, test_format and test_non_ascii both fail with a UnicodeEncodeError.  Running under regrtest, this doesn't happen because of regrtest's replace_stdout() function.  Thus, running python -m test.test_format with the following patch works:

diff -r 168efd87e051 Lib/test/test_format.py
--- a/Lib/test/test_format.py   Fri Feb 15 23:38:23 2013 +0200
+++ b/Lib/test/test_format.py   Sat Feb 16 15:14:52 2013 -0600
@@ -325,9 +325,7 @@
         self.assertIs("{0:5s}".format(text), text)


-def test_main():
-    support.run_unittest(FormatTest)
-
-
 if __name__ == "__main__":
+    from test.regrtest import replace_stdout
+    replace_stdout()
     unittest.main()


Doing the same in a setUpModule function would work for both running the module and for a unittest discover command, but it would also cause replace_stdout() to be called twice when running under regrtest, which I don't think would be especially good.

The attached patch is one possible solution that I've come up with.  It moves replace_stdout from regrtest to support, and adds a "running_under_regrtest" flag to support that regrtest sets to True.  test_format then checks support.running_under_regrtest in setUpModule to determine whether to run support.replace_stdout.

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

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

From report at bugs.python.org  Sun Feb 17 01:38:22 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 17 Feb 2013 00:38:22 +0000
Subject: [New-bugs-announce] [issue17218] support title and description in
	argparse	add_mutually_exclusive_group
Message-ID: <1361061502.09.0.252084655816.issue17218@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to add to argparse's add_mutually_exclusive_group() method support for passing a title and description.  From the argparse docs:

"Note that currently mutually exclusive argument groups do not support the title and description arguments of add_argument_group()."

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

----------
components: Library (Lib)
messages: 182251
nosy: bethard, chris.jerdonek
priority: normal
severity: normal
stage: test needed
status: open
title: support title and description in argparse add_mutually_exclusive_group
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Feb 17 17:42:40 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 17 Feb 2013 16:42:40 +0000
Subject: [New-bugs-announce] [issue17219] cross add Python's library
	directory when building	python standard extensions
Message-ID: <1361119360.59.0.341690353599.issue17219@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

For native build distutils add current directory to library path. This is not activated in case of cross-build.

Before , as part of issue3871 and issue15483, was updated setup.py , but now I would like to propose a simple more general solution with attached patch.

----------
components: Build
files: 0001-cross-add-current-dir-in-library-path-if-building-py.patch
keywords: patch
messages: 182278
nosy: doko, rpetrov
priority: normal
severity: normal
status: open
title: cross add Python's library directory when building python standard extensions
versions: Python 3.4
Added file: http://bugs.python.org/file29104/0001-cross-add-current-dir-in-library-path-if-building-py.patch

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

From report at bugs.python.org  Sun Feb 17 18:50:23 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Feb 2013 17:50:23 +0000
Subject: [New-bugs-announce] [issue17220] Little enhancements of
	_bootstrap.py
Message-ID: <1361123423.75.0.607342281941.issue17220@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch a little cleans and optimizes some bits of _bootstrap.py.

----------
components: Interpreter Core
files: _bootstrap.diff
keywords: patch
messages: 182280
nosy: brett.cannon, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Little enhancements of _bootstrap.py
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29105/_bootstrap.diff

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

From report at bugs.python.org  Sun Feb 17 22:15:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Feb 2013 21:15:41 +0000
Subject: [New-bugs-announce] [issue17221] Resort Misc/NEWS
Message-ID: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch moves some Misc/NEWS entities to more appropriate sections (IDLE, C-API, Tests, Documentation, Tools/Demos). Please review.

----------
assignee: docs at python
components: Documentation
files: NEWS-3.4.patch
keywords: patch
messages: 182282
nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Resort Misc/NEWS
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29107/NEWS-3.4.patch

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

From report at bugs.python.org  Sun Feb 17 22:23:44 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 17 Feb 2013 21:23:44 +0000
Subject: [New-bugs-announce] [issue17222] py_compile.compile() replaces
	target files, breaking special files and symlinks
Message-ID: <1361136224.16.0.490340842207.issue17222@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

Since d4eb02b6aac9 py_compile.compile() replaces target files, breaking special files and symlinks. Any custom permissions set on target files are also lost. This is a major regression.

# cd /tmp
# touch test.py
# ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Feb 17 21:16 /dev/null
# python3.3 -c 'import py_compile; py_compile.compile("test.py", cfile="/dev/null")'
# ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Feb 17 21:16 /dev/null
# python3.4 -c 'import py_compile; py_compile.compile("test.py", cfile="/dev/null")'
# ls -l /dev/null
-rw-r----- 1 root root 102 Feb 17 21:53 /dev/null

----------
messages: 182283
nosy: Arfrever, brett.cannon, eric.snow, ncoghlan
priority: high
severity: normal
status: open
title: py_compile.compile() replaces target files, breaking special files and symlinks
versions: Python 3.4

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

From report at bugs.python.org  Mon Feb 18 00:45:05 2013
From: report at bugs.python.org (Manuel Jacob)
Date: Sun, 17 Feb 2013 23:45:05 +0000
Subject: [New-bugs-announce] [issue17223] Initializing array.array with
	unicode type code and	buffer segfaults
Message-ID: <1361144705.32.0.225799767897.issue17223@psf.upfronthosting.co.za>


New submission from Manuel Jacob:

>>> from array import array
>>> str(array('u', b'asdf'))
[1]    19411 segmentation fault (core dumped)  python

This error occures with Python 3.3 and hg tip but not with Python 3.2.

----------
components: Library (Lib), Unicode
messages: 182291
nosy: ezio.melotti, mjacob
priority: normal
severity: normal
status: open
title: Initializing array.array with unicode type code and buffer segfaults
type: crash
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Feb 18 09:40:30 2013
From: report at bugs.python.org (william wu)
Date: Mon, 18 Feb 2013 08:40:30 +0000
Subject: [New-bugs-announce] [issue17224] can not open idle in python 2.7.3
Message-ID: <1361176830.93.0.935966223453.issue17224@psf.upfronthosting.co.za>


New submission from william wu:

I install python 2.7 in windows xp 32bit. 
I try to open idle using "C:\Python27>python.exe Lib\idlelib\idle.py", But return error as following:

Traceback (most recent call last):
  File "Lib\idlelib\idle.py", line 11, in <module>
    idlelib.PyShell.main()
  File "C:\Python27\Lib\idlelib\PyShell.py", line 1421, in main
    shell = flist.open_shell()
  File "C:\Python27\Lib\idlelib\PyShell.py", line 289, in open_shell
    if not self.pyshell.begin():
  File "C:\Python27\Lib\idlelib\PyShell.py", line 1009, in begin
    client = self.interp.start_subprocess()
  File "C:\Python27\Lib\idlelib\PyShell.py", line 402, in start_subprocess
    self.port = self.rpcclt.listening_sock.getsockname()[1]
  File "C:\Python27\Lib\socket.py", line 224, in meth
    return getattr(self._sock,name)(*args)
socket.gaierror: [Errno 10104] getaddrinfo failed
it's fine if using "C:\Python27>python.exe Lib\idlelib\idle.py -n". it doesn't work after i try to close firewall.

----------
components: Windows
messages: 182306
nosy: hayeswu
priority: normal
severity: normal
status: open
title: can not open idle in python 2.7.3
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb 18 14:19:26 2013
From: report at bugs.python.org (Ferdinand Beyer)
Date: Mon, 18 Feb 2013 13:19:26 +0000
Subject: [New-bugs-announce] [issue17225] JSON decoder reports wrong column
	number on first line
Message-ID: <1361193566.84.0.658685915007.issue17225@psf.upfronthosting.co.za>


New submission from Ferdinand Beyer:

The linecol() function in json/decoder.py computes the line and column numbers for a byte offset in a string.  Both numbers are expected to start with 1 (as in text editors).

If the position is in the first line, the returned column is off by one (or starting with zero):

    >>> from json.decoder import linecol
    >>> linecol('spam', 0)  # Should be (1, 1)
    (1, 0)
    >>> linecol('\nspam', 1)
    (2, 1)

The problem is the line:

    if lineno == 1:
        colno = pos

that should read

    if lineno == 1:
        colno = pos + 1

----------
components: Library (Lib)
messages: 182320
nosy: fbeyer
priority: normal
severity: normal
status: open
title: JSON decoder reports wrong column number on first line
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Feb 18 17:00:07 2013
From: report at bugs.python.org (Alan Hourihane)
Date: Mon, 18 Feb 2013 16:00:07 +0000
Subject: [New-bugs-announce] [issue17226] libintl should also check for
	libiconv
Message-ID: <1361203207.64.0.112739633546.issue17226@psf.upfronthosting.co.za>


New submission from Alan Hourihane:

The configure.ac script detects libintl but can depend on libiconv.

I added this to force it and to demonstrate, but I think this is not 100% correct and should be massaged into the libintl tests.

--- configure.ac.old    2013-02-16 09:34:55.000000000 +0000
+++ configure.ac        2013-02-16 09:43:22.000000000 +0000
@@ -2122,6 +2122,15 @@
                                                # pthread (first!) on Linux
 fi
 
+# Check iconv
+AC_CHECK_LIB([iconv], [iconv_open], , [ac_found_iconf=no])
+if test "x$ac_found_iconf" = "xno"; then
+  AC_CHECK_LIB([iconv], [libiconv_open], , [ac_found_iconf=no])
+fi
+if test "x$ac_found_iconf" = "xyes"; then
+  LIBS="-liconv $LIBS"
+fi
+
 # check if we need libintl for locale functions
 AC_CHECK_LIB(intl, textdomain,
        [AC_DEFINE(WITH_LIBINTL, 1,

----------
components: Build
messages: 182327
nosy: alanh
priority: normal
severity: normal
status: open
title: libintl should also check for libiconv
versions: Python 3.3

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

From report at bugs.python.org  Mon Feb 18 20:50:02 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Feb 2013 19:50:02 +0000
Subject: [New-bugs-announce] [issue17227] devguide: buggy heading numbers
Message-ID: <1361217002.34.0.936078305401.issue17227@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

If you look e.g. here:
http://docs.python.org/devguide/faq.html#communications

you'll see that all questions are numbered "25", while the upper headings are numbered "25.1", "25.2", etc.

Other places in the devguide seem fine, e.g. http://docs.python.org/devguide/stdlibchanges.html

----------
components: Devguide
messages: 182338
nosy: eric.araujo, ezio.melotti, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: devguide: buggy heading numbers
type: behavior

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

From report at bugs.python.org  Mon Feb 18 21:26:17 2013
From: report at bugs.python.org (Richard Yao)
Date: Mon, 18 Feb 2013 20:26:17 +0000
Subject: [New-bugs-announce] [issue17228] Building without PYMALLOC fails
Message-ID: <1361219177.62.0.296828194519.issue17228@psf.upfronthosting.co.za>


New submission from Richard Yao:

The preprocessor definition for uint is only defined when building with PYMALLOC, which breaks builds without PYMALLOC. There is a Gentoo bug report on this issue:

https://bugs.gentoo.org/show_bug.cgi?id=458168

I have attached a patch that I wrote that resolves this.

----------
components: Build
files: python-3.3.0-rename-uint.patch
keywords: patch
messages: 182340
nosy: ryao
priority: normal
severity: normal
status: open
title: Building without PYMALLOC fails
type: compile error
versions: Python 3.3
Added file: http://bugs.python.org/file29118/python-3.3.0-rename-uint.patch

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

From report at bugs.python.org  Mon Feb 18 22:21:11 2013
From: report at bugs.python.org (Samwyse)
Date: Mon, 18 Feb 2013 21:21:11 +0000
Subject: [New-bugs-announce] [issue17229] unable to discover preferred
	HTTPConnection class
Message-ID: <1361222471.81.0.536204108906.issue17229@psf.upfronthosting.co.za>


New submission from Samwyse:

When a URL is opened, the opener-director is responsible for locating the proper handler for the specified protocol. Frequently, an existing protocol handler will be subclassed and then added to the collection maintained by the director. When urlopen is called, the specified request is immediately handed off to the director's "open" method which finds the correct handler and invokes the protocol-specific XXX_open method. At least in the case of the HTTP protocols, if an error occurs then the director is called again to find and invoke a handler for the error; these handlers generally open a new connection after adding headers to avoid the error going forward. Finally, it is important to note that at the present time, the HTTP handlers in urllib2 are built using a class (infourl) that isn't prepared to deal with a persistent connection, so they always add a "Connection: close" header to the request.
    
Unfortunately, NTLM only certifies the current connection, meaning that a "Connection: keep-alive" header must be used to keep it open throughout the authentication process. Furthermore, because the opener director only provides a do_open method, there is no way to discover the type of connection without also opening it. This means that the HTTPNtlmAuthHandler cannot use the normal HTTPHandler and must therefore must hardcode the HTTPConnection class. If a custom class is required for whatever reason, the only way to cause it to be used is to monkey-patch the code. For an example, see http://code.google.com/p/python-ntlm/source/browse/trunk/python26/ntlm_examples/test_ntlmauth.py

This can be avoided if, instead of putting the instantiation of the desired HTTP connection class inline, the HTTPHandler classes used a class instance variable. Something like the following should work without breaking any existing code:

class HTTPHandler(AbstractHTTPHandler):

    _connection = httplib.HTTPConnection
    
    @property
    def connection(self):
        """Returns the class of connection being handled."""
        return self._connection

    def http_open(self, req):
        return self.do_open(_connection, req)

    http_request = AbstractHTTPHandler.do_request_

----------
components: Library (Lib)
messages: 182343
nosy: samwyse
priority: normal
severity: normal
status: open
title: unable to discover preferred HTTPConnection class
versions: 3rd party, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Feb 19 00:12:53 2013
From: report at bugs.python.org (jort bloem)
Date: Mon, 18 Feb 2013 23:12:53 +0000
Subject: [New-bugs-announce] [issue17230] when forking without tty,
	code is run from start
Message-ID: <1361229173.49.0.760112952716.issue17230@psf.upfronthosting.co.za>


New submission from jort bloem:

When calling os.fork() without a tty, a process reporting the parent's pid runs code BEFORE the fork().

When running on a tty, it behaves as expected: both parent and child continue running from statement immediately after os.fork()

See attached test.py, compare running it with tty vs. without.

to run without tty: ssh localhost `pwd`/test.py

----------
components: None
messages: 182346
nosy: jort.bloem
priority: normal
severity: normal
status: open
title: when forking without tty, code is run from start
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Feb 19 07:22:52 2013
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Tue, 19 Feb 2013 06:22:52 +0000
Subject: [New-bugs-announce] [issue17231] Mark __del__ not being called in
	cycles as an impl detail
Message-ID: <1361254972.69.0.594313111975.issue17231@psf.upfronthosting.co.za>


New submission from Maciej Fijalkowski:

Here: http://docs.python.org/2/reference/datamodel.html, as per python-dev discussion

----------
assignee: docs at python
components: Documentation
messages: 182364
nosy: docs at python, fijall
priority: normal
severity: normal
status: open
title: Mark __del__ not being called in cycles as an impl detail
type: behavior

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

From report at bugs.python.org  Tue Feb 19 07:25:01 2013
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Tue, 19 Feb 2013 06:25:01 +0000
Subject: [New-bugs-announce] [issue17232] Improve -O docs
Message-ID: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>


New submission from Maciej Fijalkowski:

This is what the current documentation says:

-O
Turn on basic optimizations. This changes the filename extension for compiled (bytecode) files from .pyc to .pyo. See also PYTHONOPTIMIZE.

-OO
Discard docstrings in addition to the -O optimizations.

As far as I know, the only "optimization" that's done is removal of __debug__ sections and assert statements and has been like this for years. Maybe it should say so "-O does not do any optimizations, only removes assert statement" or so.

----------
assignee: docs at python
components: Documentation
messages: 182365
nosy: docs at python, fijall
priority: normal
severity: normal
status: open
title: Improve -O docs
type: behavior

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

From report at bugs.python.org  Tue Feb 19 07:52:54 2013
From: report at bugs.python.org (=?utf-8?q?Kim_Gr=C3=A4sman?=)
Date: Tue, 19 Feb 2013 06:52:54 +0000
Subject: [New-bugs-announce] [issue17233] http.client header debug output
	format
Message-ID: <1361256774.67.0.162902666936.issue17233@psf.upfronthosting.co.za>


New submission from Kim Gr?sman:

Python 3.2.3 on 64-bit Windows 7.

When I set debuglevel on HTTPConnection to 1, the output seems jumbled, and I'm having trouble interpreting it.

Attached is a full, anonymized log from a conversation I was troubleshooting.

Here's an excerpt:

 send: b'GET /a HTTP/1.1\r\nHost: localhost:55380\r\nAccept-Encoding: identity\r\n\r\n'
 reply: 'HTTP/1.1 503 Service unavailable\r\n'
 header: Connection header: Content-Length header: Content-Type header: Date send: b'GET /a HTTP/1.1\r\nHost: localhost:55380\r\nAccept-Encoding: identity\r\n\r\n'
 reply: 'HTTP/1.1 503 Service unavailable\r\n'

- Does line 3, starting with header:, show headers for the request or response? I'm guessing response, but it didn't occur to me until just now, after a full day of looking at it.
- It would be nice if the header dump showed both header key and value
- There's a trailing "send:" at the end of the header: line, shouldn't that be on its own line?

Overall, not printing a newline after these debug statements makes it really hard to combine with other print debugging, as unrelated prints show up at the end of every line of httpclient's debug output.

I find "header" a bit confusing as a prefix, as it doesn't say whether it's request or response headers. Maybe change the prefix to "response-headers:" and also add "request-headers:", even if those are visible in the "send:" lines? Alternatively, why not show the response headers in the "reply:" dump?

Would you consider patches to address these concerns?

Thank you!

----------
components: Library (Lib)
files: httpclient.debuglevel.txt
messages: 182367
nosy: Kim.Gr?sman
priority: normal
severity: normal
status: open
title: http.client header debug output format
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file29120/httpclient.debuglevel.txt

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

From report at bugs.python.org  Tue Feb 19 10:35:44 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Tue, 19 Feb 2013 09:35:44 +0000
Subject: [New-bugs-announce] [issue17234] python-2.7.3-r3: crash in
	visit_decref()
Message-ID: <1361266544.85.0.580763984436.issue17234@psf.upfronthosting.co.za>


New submission from Martin Mokrejs:

Hi,
  I do see relatively often a crash in python. Here is one stacktrace from my Gentoo Linux running 3.7.4 kernel:

(gdb) where
#0  0x00007f624f340f08 in visit_decref () from /usr/lib64/libpython2.7.so.1.0
#1  0x00007f624f2a455a in list_traverse () from /usr/lib64/libpython2.7.so.1.0
#2  0x00007f624f3412c7 in collect () from /usr/lib64/libpython2.7.so.1.0
#3  0x00007f624f341f11 in _PyObject_GC_Malloc () from /usr/lib64/libpython2.7.so.1.0
#4  0x00007f624f2cdd59 in PyType_GenericAlloc () from /usr/lib64/libpython2.7.so.1.0
#5  0x00007f624f2d09c3 in type_call () from /usr/lib64/libpython2.7.so.1.0
#6  0x00007f624f27bdc3 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0
#7  0x00007f624f310d76 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#8  0x00007f624f31285e in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#9  0x00007f624f313905 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0
#10 0x00007f624f313a32 in PyEval_EvalCode () from /usr/lib64/libpython2.7.so.1.0
#11 0x00007f624f32d97c in run_mod () from /usr/lib64/libpython2.7.so.1.0
#12 0x00007f624f32e53d in PyRun_StringFlags () from /usr/lib64/libpython2.7.so.1.0
#13 0x00007f624f30a44e in builtin_eval () from /usr/lib64/libpython2.7.so.1.0
#14 0x00007f624f312456 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#15 0x00007f624f313905 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0
#16 0x00007f624f2a104c in function_call () from /usr/lib64/libpython2.7.so.1.0
#17 0x00007f624f27bdc3 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0
#18 0x00007f624f28a82f in instancemethod_call () from /usr/lib64/libpython2.7.so.1.0
#19 0x00007f624f27bdc3 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0
#20 0x00007f624f30c9b7 in PyEval_CallObjectWithKeywords () from /usr/lib64/libpython2.7.so.1.0
#21 0x00007f624612f807 in call_with_frame.isra.9 () from /usr/lib64/python2.7/lib-dynload/pyexpat.so
#22 0x00007f6246132080 in my_StartElementHandler () from /usr/lib64/python2.7/lib-dynload/pyexpat.so
#23 0x00007f6245ed0fb0 in doContent () from /usr/lib64/libexpat.so.1
#24 0x00007f6245ed21b4 in contentProcessor () from /usr/lib64/libexpat.so.1
#25 0x00007f6245ecce2a in XML_ParseBuffer () from /usr/lib64/libexpat.so.1
#26 0x00007f6246132d5b in xmlparse_Parse () from /usr/lib64/python2.7/lib-dynload/pyexpat.so
#27 0x00007f624f312456 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#28 0x00007f624f296379 in gen_send_ex.isra.1 () from /usr/lib64/libpython2.7.so.1.0
#29 0x00007f624f2ce40f in wrap_next () from /usr/lib64/libpython2.7.so.1.0
#30 0x00007f624f27bdc3 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0
#31 0x00007f624f310d76 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#32 0x00007f624f31285e in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#33 0x00007f624f31285e in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#34 0x00007f624f31285e in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#35 0x00007f624f31285e in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#36 0x00007f624f313905 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0
#37 0x00007f624f313a32 in PyEval_EvalCode () from /usr/lib64/libpython2.7.so.1.0
#38 0x00007f624f32d97c in run_mod () from /usr/lib64/libpython2.7.so.1.0
#39 0x00007f624f32e750 in PyRun_FileExFlags () from /usr/lib64/libpython2.7.so.1.0
#40 0x00007f624f32f1cf in PyRun_SimpleFileExFlags () from /usr/lib64/libpython2.7.so.1.0
#41 0x00007f624f3407e2 in Py_Main () from /usr/lib64/libpython2.7.so.1.0
#42 0x00007f624ec8f91d in __libc_start_main () from /lib64/libc.so.6
#43 0x000000000040094d in _start ()
(gdb)

----------
messages: 182371
nosy: mmokrejs
priority: normal
severity: normal
status: open
title: python-2.7.3-r3: crash in visit_decref()
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Tue Feb 19 11:20:25 2013
From: report at bugs.python.org (Michael Kuhn)
Date: Tue, 19 Feb 2013 10:20:25 +0000
Subject: [New-bugs-announce] [issue17235] "make sharedinstall" ignores
	./configure settings
Message-ID: <1361269225.76.0.790784107865.issue17235@psf.upfronthosting.co.za>


New submission from Michael Kuhn:

I need to install Python 2.7 in two architectures, but under one file system. I thus configure:

/home/cellnet/michaelk/SRC/Python-2.7.3> ./configure --prefix=/home/cellnet/michaelk/biocluster --exec-prefix=/home/cellnet/michaelk/biocluster -q

When I compile and then run "make install", it will try to copy libraries to "/home/cellnet/michaelk/lib64/python", i.e. it will try to copy files outside the specified prefixes. The step is "make sharedinstall", which fails because I've temporarily made the lib64 directory read-only: 

[michaelk at biocluster2] /home/cellnet/michaelk/SRC/Python-2.7.3> make sharedinstall
running build
running build_ext
building dbm using bdb

Python build finished, but the necessary bits to build these modules were not found:
bsddb185           dl                 gdbm            
imageop            sunaudiodev                        
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

running build_scripts
./python -E ./setup.py install \
                --prefix=/home/cellnet/michaelk/biocluster \
                --install-scripts=/home/cellnet/michaelk/biocluster/bin \
                --install-platlib=/home/cellnet/michaelk/biocluster/lib/python2.7/lib-dynload \
                --root=/
running install
running build
running build_ext
building dbm using bdb

Python build finished, but the necessary bits to build these modules were not found:
bsddb185           dl                 gdbm            
imageop            sunaudiodev                        
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

running build_scripts
running install_lib
copying build/lib.linux-x86_64-2.7/_ctypes.so -> /home/cellnet/michaelk/lib64/python
error: could not delete '/home/cellnet/michaelk/lib64/python/_ctypes.so': Permission denied
make: *** [sharedinstall] Error 1

----------
components: Build
messages: 182372
nosy: Michael.Kuhn
priority: normal
severity: normal
status: open
title: "make sharedinstall" ignores ./configure settings
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Feb 19 13:40:02 2013
From: report at bugs.python.org (Tobia Conforto)
Date: Tue, 19 Feb 2013 12:40:02 +0000
Subject: [New-bugs-announce] [issue17236] format_spec for sequence joining
Message-ID: <1361277602.96.0.470418082316.issue17236@psf.upfronthosting.co.za>


New submission from Tobia Conforto:

The format specification mini-language (format_spec) supported by format() and str.format() is a feature that allows passing short options to the classes of the values being formatted, to drive their string representation (__format__ method)

The most common operation done to sequences (lists, tuples, sets...) during conversion to string is arguably the string join operation, possibly coupled with a "nested" string formatting of the sequence items.

I propose the addition of a custom format_spec for sequences, that allows to easily specify a string for the join operation and optionally a nested format_spec to be passed along to format the sequence items.

Here is the proposed addition:

  seq_format_spec  ::= join_string [":" item_format_spec] | format_spec
  join_string      ::= '"' join_string_char* '"' | "'" join_string_char* "'"
  join_string_char ::= <any character except "{", "}", newline, or the quote>
  item_format_spec ::= format_spec

In words, if the format_spec for a sequence starts with a single or double quote, it will be interpreted as a join operation, optionally followed by another colon and the format_spec for the sequnce items.

If the format_spec does not start with ' or ", of if the quote is not balanced (does not appear again in the format_spec), then it's assumed to be a generic format string and the implementation would call super(). This ensures backwards compatibility with existing code that may be using object's __format__ implementation on various sequence objects.

Please note I'm NOT proposing a change in the language or in the implementation of format() and str.format(). This is just the addition of a __format__ method to lists, tuples, sets and other sequence classes. The choice of whether to do that in all those sequence classes or as an addition to object's __format__ is an implementation detail.

Examples:

Basic usage: either {0:", "} or {0:', '} when used in a format operation will do this: ", ".join(str(x) for x in argument_0) in a more compact, possibly more efficient, and arguably easier to read syntax.

Nested (regular) format_spec: {0:", ":.1f} will join a list of floats using ", " as the separator and .1f as the format_spec for each float.

Nested join format_spec: {0:"\n":", "} will join a list of lists, using "\n" as the outer separator and ", " as the inner separator. This could go on indefinitely (but will rarely need to do so.)

I do not have a patch ready, but I can work on it and submit it for evaluation, if this enhancement is accepted.

----------
messages: 182376
nosy: tobia
priority: normal
severity: normal
status: open
title: format_spec for sequence joining
type: enhancement

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

From report at bugs.python.org  Tue Feb 19 15:31:48 2013
From: report at bugs.python.org (Alan Hourihane)
Date: Tue, 19 Feb 2013 14:31:48 +0000
Subject: [New-bugs-announce] [issue17237] m68k aligns on 16bit boundaries.
Message-ID: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za>


New submission from Alan Hourihane:

On m68k this assert triggers in Python/unicodeobject.c:4658 because m68k architectures can align on 16bit boundaries.

assert(!((size_t) dest & LONG_PTR_MASK));

I'm not sure of the wider implications in Python as to how to rectify.

----------
components: Build
messages: 182381
nosy: alanh
priority: normal
severity: normal
status: open
title: m68k aligns on 16bit boundaries.
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb 19 16:32:51 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Tue, 19 Feb 2013 15:32:51 +0000
Subject: [New-bugs-announce] [issue17238] Enhance import statement completion
Message-ID: <1361287971.25.0.643782901011.issue17238@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

[patch under development]
I propose to add completions for 
import <tab>
from <tab>
from x import <tab>

Also, if one types imp.<tab> , IDLE should import the module and list dir(module).
(There will be an option to disable/enable the last two completion cases as some users object to it importing modules for completion)

----------
components: IDLE
messages: 182392
nosy: Ramchandra Apte, terry.reedy
priority: normal
severity: normal
status: open
title: Enhance import statement completion
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Feb 19 16:35:41 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 19 Feb 2013 15:35:41 +0000
Subject: [New-bugs-announce] [issue17239] XML vulnerabilities in Python
Message-ID: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Experimental fix for XML vulnerabilities against default. It's NOT ready and needs lots of polishing.

https://pypi.python.org/pypi/defusedxml contains explanations of all issues
https://pypi.python.org/pypi/defusedexpat is a standalone version of part of the patches for Python 2.6 to 3.3

----------
components: Extension Modules, Library (Lib), XML
files: xmlbomb_20130219.patch
keywords: patch
messages: 182393
nosy: barry, benjamin.peterson, christian.heimes, georg.brandl, larry
priority: release blocker
severity: normal
stage: needs patch
status: open
title: XML vulnerabilities in Python
type: security
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29122/xmlbomb_20130219.patch

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

From report at bugs.python.org  Tue Feb 19 17:51:08 2013
From: report at bugs.python.org (Thibault Kruse)
Date: Tue, 19 Feb 2013 16:51:08 +0000
Subject: [New-bugs-announce] [issue17240] argparse: subcommand name and arity
Message-ID: <1361292668.26.0.464460633083.issue17240@psf.upfronthosting.co.za>


New submission from Thibault Kruse:

I realize there have been several suggestions around argparse subcommands. Mine is related to this isse:
http://bugs.python.org/issue9253

In short, I suggest that the add_subparsers() function take an argument like nargs that determines how many times user may or have to use a subcommand. E.g. ?, 1, +, *. The multiples are useful for things like "setup.py build bist upload" or "make build test doc". I notice currently the subparsers object created by add_subparsers() has this:
>>> subparsers.nargs
'A...'
Does anyone know what that notation implies?

The default for nargs can be whatever it currently is, though issue9253 makes me wonder whether there currently is any default behavior over different argparse versions.

Also, I believe subcommands should have a name by which the choice of the subcommands ends up in the arg namespace.

E.g.:
import argparse
argparser = argparse.ArgumentParser()
subparsers = argparser.add_subparsers()
subparser1 = subparsers.add_parser('foo')
subparser1.add_argument('--fooopt')
subparser2 = subparsers.add_parser('bar')
subparser2.add_argument('--baropt')
argparser.parse_args(['foo'])
Namespace(fooopt=None)

This is not satisfactory. I would prefer:
import argparse
argparser = argparse.ArgumentParser()
subparsers = argparser.add_subparsers('cmd1') % name here

subparser1 = subparsers.add_parser('foo')
subparser1.add_argument('--fooopt')
subparser2 = subparsers.add_parser('bar')
subparser2.add_argument('--baropt')
argparser.parse_args(['foo'])
Namespace(fooopt=None, cmd1='foo') % value here


The dest member of subparsers already seems to work as intended:
subparsers.dest='cmd1'; but users should not have to set it like that, to improve early error checking.

----------
components: Library (Lib)
messages: 182395
nosy: Thibault.Kruse
priority: normal
severity: normal
status: open
title: argparse: subcommand name and arity
type: enhancement

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

From report at bugs.python.org  Tue Feb 19 19:42:12 2013
From: report at bugs.python.org (Jeff Mansfield)
Date: Tue, 19 Feb 2013 18:42:12 +0000
Subject: [New-bugs-announce] [issue17241] Python-2.3.5.exe file possibly
	corrupt
Message-ID: <1361299332.57.0.860667306426.issue17241@psf.upfronthosting.co.za>


New submission from Jeff Mansfield:

Python-2.3.5.exe seems to be corrupt.
I?ve tried downloading Python-2.3.5.exe a number of times in the past week, and so have a few of my colleagues. It always transfers in an incomplete manner, resulting in only 4.7 out of 9.1 MB. I have tried from several different Windows 7 boxes, with the same results.

Perhaps something in my environment is messed up, but it may be that the file is corrupt on your server.

----------
messages: 182405
nosy: jeff_mansfield
priority: normal
severity: normal
status: open
title: Python-2.3.5.exe file possibly corrupt

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

From report at bugs.python.org  Tue Feb 19 20:45:41 2013
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 19 Feb 2013 19:45:41 +0000
Subject: [New-bugs-announce] [issue17242] Fix code highlight in
	devguide/docquality.rst
Message-ID: <1361303141.51.0.673359773941.issue17242@psf.upfronthosting.co.za>


New submission from Berker Peksag:

See for the current version:

http://docs.python.org/devguide/docquality.html#helping-with-the-developer-s-guide

----------
components: Devguide
files: devguide-highlight.diff
keywords: patch
messages: 182412
nosy: berker.peksag, ezio.melotti
priority: normal
severity: normal
status: open
title: Fix code highlight in devguide/docquality.rst
Added file: http://bugs.python.org/file29123/devguide-highlight.diff

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

From report at bugs.python.org  Tue Feb 19 21:24:47 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Feb 2013 20:24:47 +0000
Subject: [New-bugs-announce] [issue17243] The changes made for issue 4074
	should be documented
Message-ID: <1361305487.48.0.247163585293.issue17243@psf.upfronthosting.co.za>


New submission from R. David Murray:

The section of the reference on the gc module goes into some detail on what the thresholds control and when collections are run, but does not currently document the backoff algorithm used when deciding whether or not to collect generation 2.  This should presumably be documented.

----------
messages: 182425
nosy: pitrou, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: The changes made for issue 4074 should be documented
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Feb 19 21:47:16 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 19 Feb 2013 20:47:16 +0000
Subject: [New-bugs-announce] [issue17244] py_compile.compile() fails to
	raise exceptions when	writing of target file fails
Message-ID: <1361306836.21.0.240059339462.issue17244@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

Since d4eb02b6aac9 py_compile.compile() fails to raise exceptions when writing of target file fails.

$ cd /tmp
$ touch test.py
$ mkdir dir
$ chmod a-w dir
mode of ?dir? changed from 0755 (rwxr-xr-x) to 0555 (r-xr-xr-x)
$ python3.3 -c 'import py_compile; py_compile.compile("test.py", cfile="/tmp/dir/test.pyc")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib64/python3.3/py_compile.py", line 141, in compile
    with open(cfile, 'wb') as fc:
PermissionError: [Errno 13] Permission denied: '/tmp/dir/test.pyc'
$ python3.4 -c 'import py_compile; py_compile.compile("test.py", cfile="/tmp/dir/test.pyc")'
$ python3.3 -c 'import py_compile; py_compile.compile("test.py", cfile="/tmp/dir")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib64/python3.3/py_compile.py", line 141, in compile
    with open(cfile, 'wb') as fc:
IsADirectoryError: [Errno 21] Is a directory: '/tmp/dir'
$ python3.4 -c 'import py_compile; py_compile.compile("test.py", cfile="/tmp/dir")'
$ ls -l dir
total 0
$

----------
components: Library (Lib)
messages: 182426
nosy: Arfrever, brett.cannon, eric.snow, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: py_compile.compile() fails to raise exceptions when writing of target file fails
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb 19 23:11:10 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 19 Feb 2013 22:11:10 +0000
Subject: [New-bugs-announce] [issue17245] ctypes libffi needs to align the
	x86 stack to 16 bytes
Message-ID: <1361311870.54.0.433200596703.issue17245@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

The problem: without the stack being 16-byte aligned, code generated by modern compilers like recent gcc/g++ or clang assumed that the stack is 16 byte aligned and uses SSE instructions in some circumstances that require this.  Without this fix, any ctypes call into such code will crash.

I mentioned this in the comment on issue17192 which seeks to update our ancient copy of libffi but we may want to do this independently of that.

In 2.7, we're running into the stack being misaligned in 32-bit x86 code which is something a libffi update fixes.  It is a trivial patch:

 http://patchwork.ozlabs.org/patch/58128/

which made it into the official libffi releases in 2010 via https://github.com/atgreen/libffi/commit/3f5b1375ab1e2b8e3d593e21b27097a4a50f9b83#src/x86/sysv.S.

patch against 2.7 attached.  it should apply to any tree easily enough.

----------
assignee: gregory.p.smith
files: fix_libffi_x86_stack_align.gps01.diff
keywords: patch
messages: 182442
nosy: benjamin.peterson, georg.brandl, gregory.p.smith, larry
priority: release blocker
severity: normal
stage: patch review
status: open
title: ctypes libffi needs to align the x86 stack to 16 bytes
type: crash
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29124/fix_libffi_x86_stack_align.gps01.diff

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

From report at bugs.python.org  Tue Feb 19 23:22:36 2013
From: report at bugs.python.org (Andrew Lutomirski)
Date: Tue, 19 Feb 2013 22:22:36 +0000
Subject: [New-bugs-announce] [issue17246] cgitb fails when frame arguments
	are deleted (due to	inspect bug I think)
Message-ID: <1361312556.73.0.83895942435.issue17246@psf.upfronthosting.co.za>


New submission from Andrew Lutomirski:

inspect.formatargvalues assumes (incorrectly) that every argument in args is a key in values.  This isn't very hard to break -- see the attachment for a complete example.

----------
components: Library (Lib)
files: test_cgitb.py
messages: 182446
nosy: Andrew.Lutomirski
priority: normal
severity: normal
status: open
title: cgitb fails when frame arguments are deleted (due to inspect bug I think)
versions: Python 2.7
Added file: http://bugs.python.org/file29125/test_cgitb.py

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

From report at bugs.python.org  Tue Feb 19 23:24:53 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 19 Feb 2013 22:24:53 +0000
Subject: [New-bugs-announce] [issue17247] Decimal doesn't support aligned
	fill
Message-ID: <1361312693.56.0.943767612751.issue17247@psf.upfronthosting.co.za>


New submission from Christian Heimes:

>>> "{:<06}".format(1.2)
'1.2000'
>>> "{:<06}".format(decimal.Decimal(1.2))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid format string

----------
assignee: skrah
messages: 182447
nosy: christian.heimes, skrah
priority: normal
severity: normal
status: open
title: Decimal doesn't support aligned fill
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Feb 20 02:23:11 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Feb 2013 01:23:11 +0000
Subject: [New-bugs-announce] [issue17248] test_posix chown -1,
	0 tests fail if user has group root
Message-ID: <1361323391.07.0.678749400911.issue17248@psf.upfronthosting.co.za>


New submission from R. David Murray:

I'm a member of group root, and the _test_all_chown_common tests that use -1, 0 fail for me, because I'm allowed to set group root on a file.

----------
components: Tests
messages: 182461
nosy: r.david.murray, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: test_posix chown -1, 0 tests fail if user has group root
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Feb 20 04:01:29 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 20 Feb 2013 03:01:29 +0000
Subject: [New-bugs-announce] [issue17249] reap threads in test_capi
Message-ID: <1361329289.06.0.007526267954.issue17249@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

The attached patch fixes the following warning:

$ ./python -m test test_capi
[1/1] test_capi
Warning -- threading._dangling was modified by test_capi
1 test altered the execution environment:
    test_capi

This test was introduced in f7993dc6bf26, and it seems to predate unittest.  Maybe it should be moved outside test_main while we are at it.

----------
components: Tests
files: reap_threads.diff
keywords: patch
messages: 182463
nosy: ezio.melotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: reap threads in test_capi
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29126/reap_threads.diff

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

From report at bugs.python.org  Wed Feb 20 05:58:17 2013
From: report at bugs.python.org (paul j3)
Date: Wed, 20 Feb 2013 04:58:17 +0000
Subject: [New-bugs-announce] [issue17250] argparse: Issue 15906 patch;
	positional with nargs='*' and string default
Message-ID: <1361336297.12.0.955168493515.issue17250@psf.upfronthosting.co.za>


New submission from paul j3:

The production argparse applies the type conversion to a string default whether it is needed or not.  With the 12776 and 15906 patch, that conversion is postponed, so that it is applied only once.  However, for a positional argument with nargs='*', that conversion is never applied.

For example, with:
add_argument('foo', type=FileType('r'), default='anyfile', nargs='*')

the development version, with parse_args([]) produces
Namespace(foo='anyfile')

The previous code tested this default, raising an error if there was an IOError.  But even if it successfully opened the file, the namespace
 would get the string value, not the opened file.

With nargs = '?', the result is an IOError, or an opened file.

It is evident from the code (but not the documentation) that the best
default for the '*' positional is a list of appropriate type of objects.
In the case of FileTypes, about the only choices, without opening a
file, are: [] and [sys.stdin].

----------
components: Library (Lib)
messages: 182469
nosy: paul.j3
priority: normal
severity: normal
status: open
title: argparse: Issue 15906 patch; positional with nargs='*' and string default
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Wed Feb 20 07:48:33 2013
From: report at bugs.python.org (B. Kyven)
Date: Wed, 20 Feb 2013 06:48:33 +0000
Subject: [New-bugs-announce] [issue17251] LWPCookieJar load() set
	domain_specifed wrong
Message-ID: <1361342913.69.0.115494364841.issue17251@psf.upfronthosting.co.za>


New submission from B. Kyven:

Hello,

I am using LWPCookieJar to store cookies. But I am having trouble.
Saving is fine, load is wrong. I use Cookie.domain_specified to judge if domain exist.

save the following to test.lwp
-----------------
#LWP-Cookies-2.0
Set-Cookie3: name=value; path="/ddd/"; domain=".domain.com"; path_spec; domain_dot; secure; expires="2030-05-09 14:25:11Z"; version=0
Set-Cookie3: name=value; path="/ddd/"; domain="www.domain.com"; path_spec; secure; expires="2030-05-09 14:25:11Z"; version=0
-----------------

>cj = LWPCookieJar('test.lwp').load()
>for c in cj:
>    print c.domain, c.domain_specified, c.domain_initial_dot

output:
.domain.com       True      True
www.domain.com  **False**   True

If understood correctly, domain_specified should equal bool(c.domain ="").

This is seen on 2.7 and 2.6.

----------
components: Library (Lib)
messages: 182476
nosy: B. Kyven
priority: normal
severity: normal
status: open
title: LWPCookieJar load() set domain_specifed wrong
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Feb 20 10:14:15 2013
From: report at bugs.python.org (Firat Ozgul)
Date: Wed, 20 Feb 2013 09:14:15 +0000
Subject: [New-bugs-announce] [issue17252] Latin Capital Letter I with Dot
	Above
Message-ID: <1361351655.21.0.204016778248.issue17252@psf.upfronthosting.co.za>


New submission from Firat Ozgul:

lower() method of strings gives different output for 'Latin Capital Letter I with Dot Above' on Python 3.2 and Python 3.3. 

On Python 3.2 (Windows XP):

>>> "\u0130".lower()
'i' #this is correct

On Python 3.3 (Windows XP):

>>> "\u0130".lower()
'i\u0307' #this is wrong

Why is this difference? This breaks code, because 'i' and 'i\u0307' are different letters.

----------
messages: 182485
nosy: firatozgul
priority: normal
severity: normal
status: open
title: Latin Capital Letter I with Dot Above
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Feb 20 12:45:29 2013
From: report at bugs.python.org (Jason R Briggs)
Date: Wed, 20 Feb 2013 11:45:29 +0000
Subject: [New-bugs-announce] [issue17253] stdin.readline behaviour different
	between IDLE and the	console
Message-ID: <1361360729.12.0.267865826707.issue17253@psf.upfronthosting.co.za>


New submission from Jason R Briggs:

The sys.stdin.readline function takes a limit parameter, which limits the number of characters read. If you try using that parameter in IDLE, you get the following error:

Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    sys.stdin.readline(13)
TypeError: readline() takes exactly 1 positional argument (2 given)

I've tried this in a number of different versions and it looks to have been like this for a while. A possible fix looks fairly straightforward. Something vaguely like...

<     def readline(self):
---
>     def readline(self, limit=-1):
993a994,995
>         if limit >= 0:
>             line = line[0:limit]

(with apologies if this is a dup ticket -- there seems to be a number of tickets raised regarding issues with IDLE and its version stdin/stdout, but I couldn't see any which discussed this particular behaviour).

----------
components: IDLE
messages: 182488
nosy: jason.briggs
priority: normal
severity: normal
status: open
title: stdin.readline behaviour different between IDLE and the console
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Feb 20 12:48:44 2013
From: report at bugs.python.org (albertjan)
Date: Wed, 20 Feb 2013 11:48:44 +0000
Subject: [New-bugs-announce] [issue17254] add thai encoding aliases to
	encodings.aliases
Message-ID: <1361360924.27.0.663240022367.issue17254@psf.upfronthosting.co.za>


New submission from albertjan:

This is almost identical to: http://bugs.python.org/issue854511
However, tis602, which is mentioned in the orginal bug report, is not an alias to cp874. Therefore, I propose the following:

import encodings

aliases = encodings.aliases.aliases
more_aliases = {'ibm874'     : 'cp874',
                'iso_8859_11': 'cp874',
                'iso8859_11' : 'cp874',
                'windows_874': 'cp874',
               }
aliases.update(more_aliases)

----------
messages: 182489
nosy: fomcl at yahoo.com
priority: normal
severity: normal
status: open
title: add thai encoding aliases to encodings.aliases

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

From report at bugs.python.org  Wed Feb 20 13:32:03 2013
From: report at bugs.python.org (wim glenn)
Date: Wed, 20 Feb 2013 12:32:03 +0000
Subject: [New-bugs-announce] [issue17255] test_any and test_all should
	validate short-circuiting	behaviour
Message-ID: <1361363523.21.0.389382040162.issue17255@psf.upfronthosting.co.za>


New submission from wim glenn:

The docs http://docs.python.org/2/library/functions.html#all provide some equivalent code for all builtin (and similarly for any):

def all(iterable):
    for element in iterable:
        if not element:
            return False
    return True

The behaviour is clearly documented as short-circuiting, but the cases contained in test_builtin.py are lacking any test coverage for the short-circuiting behaviour.  You could implement any/all in a broken way that still passes the current tests (consuming more of a generator than you want to for example), so it is important to guarantee the short-circuiting.

My patch adds two simple test cases to make this behaviour explicit.

----------
components: Tests
files: mywork.patch
keywords: patch
messages: 182496
nosy: wim.glenn
priority: normal
severity: normal
status: open
title: test_any and test_all should validate short-circuiting behaviour
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file29131/mywork.patch

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

From report at bugs.python.org  Wed Feb 20 15:45:31 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 20 Feb 2013 14:45:31 +0000
Subject: [New-bugs-announce] [issue17256] code example should be highlighted
Message-ID: <1361371531.01.0.624260307676.issue17256@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

in http://docs.python.org/2/extending/embedding.html#linking-requirements
 the code example isn't highlighted

----------
assignee: docs at python
components: Documentation
messages: 182515
nosy: Ramchandra Apte, docs at python
priority: normal
severity: normal
status: open
title: code example should be highlighted

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

From report at bugs.python.org  Wed Feb 20 18:55:44 2013
From: report at bugs.python.org (Hendrik Lemelson)
Date: Wed, 20 Feb 2013 17:55:44 +0000
Subject: [New-bugs-announce] [issue17257] re module shows unexpected
	non-greedy behavior when	using groups
Message-ID: <1361382944.02.0.85313570363.issue17257@psf.upfronthosting.co.za>


New submission from Hendrik Lemelson:

When using the Python 2.7.3 re module, it shows a strange behavior upon the use of quantifiers together with groups:

>>> re.search('(a*)', 'caaaat').groups()
('',)
>>> re.search('(a+)', 'caaaat').groups()
('aaaa',)
>>> re.search('(a{0,5})', 'caaaat').groups()
('',)
>>> re.search('(a{1,5})', 'caaaat').groups()
('aaaa',)

Whenever a quantifier is used that allows also zero occurrences, the quantifier loses its greedy behavior. This in my eyes is a defect in the re module. In the following there is another example with nested groups where the quantifier for the outer group even prevents the inner groups to match:

>>> re.search('(a(b*)a)', 'caabbaat').groups()
('aa', '')
>>> re.search('(a(b+)a)', 'caabbaat').groups()
('abba', 'bb')
>>> re.search('(a(b*)a){0,1}', 'caabbaat').groups()
(None, None)
>>> re.search('(a(b+)a){0,1}', 'caabbaat').groups()
(None, None)

It would be great if you could manage to fix this.
Thank you in advance.

Regards
Hendrik Lemelson

----------
components: Regular Expressions
messages: 182535
nosy: Hendrik.Lemelson, ezio.melotti, mrabarnett, pitrou
priority: normal
severity: normal
status: open
title: re module shows unexpected non-greedy behavior when using groups
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Feb 20 21:11:36 2013
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 20 Feb 2013 20:11:36 +0000
Subject: [New-bugs-announce] [issue17258] multiprocessing.connection
	challenge implicitly uses MD5
Message-ID: <1361391096.59.0.84157337171.issue17258@psf.upfronthosting.co.za>


New submission from Dave Malcolm:

Within multiprocessing.connection, deliver_challenge() and
answer_challenge() use hmac for a challenge/response.

hmac implicitly defaults to using MD5.

MD5 should no longer be used for security purposes.  See e.g. 
http://www.kb.cert.org/vuls/id/836068

This fails in a FIPS-compliant environment (e.g. with the patches I
apply to hashlib in issue 9216).

There's thus a possibility of an attacker defeating the multiprocessing
authenticator.

I'm attaching a patch which changes multiprocessing to use a clearly
identified algorithm (for the day when it needs changing again),
hardcoding it as "sha256"; presumably all processes within a
multiprocess program that share authkey can share the algorithm.

It's not clear to me whether hmac.py should also be changed (this would
seem to have tougher backwards-compat concerns).

[Note to self: I'm tracking this downstream for RHEL as
https://bugzilla.redhat.com/show_bug.cgi?id=879695 (this bug is
currently only visible to RH employees)]

----------
components: Library (Lib)
files: avoid-implicit-usage-of-md5-in-multiprocessing.patch
keywords: patch
messages: 182547
nosy: dmalcolm, sbt
priority: normal
severity: normal
stage: patch review
status: open
title: multiprocessing.connection challenge implicitly uses MD5
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file29134/avoid-implicit-usage-of-md5-in-multiprocessing.patch

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

From report at bugs.python.org  Wed Feb 20 22:21:54 2013
From: report at bugs.python.org (Francis Nimick)
Date: Wed, 20 Feb 2013 21:21:54 +0000
Subject: [New-bugs-announce] [issue17259] locale.format() rounding is not
	reliable for floats
Message-ID: <1361395314.25.0.489128727343.issue17259@psf.upfronthosting.co.za>


New submission from Francis Nimick:

Locale.format() doesn't work correctly with floating point numbers.

locale.format('%.0f', 5.5) -> 6
locale.format('%.0f', 6.5) -> 6
locale.format('%.0f', 7.5) -> 8
locale.format('%.0f', 8.5) -> 8

It seems that if the number before the decimal point is even, it rounds down, else it rounds up.

----------
components: Library (Lib)
messages: 182554
nosy: Francis.Nimick
priority: normal
severity: normal
status: open
title: locale.format() rounding is not reliable for floats
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Feb 20 23:28:36 2013
From: report at bugs.python.org (Johannes)
Date: Wed, 20 Feb 2013 22:28:36 +0000
Subject: [New-bugs-announce] [issue17260] Seg fault when calling unicode()
	on old style class in	virtualenv
Message-ID: <1361399316.25.0.654994591669.issue17260@psf.upfronthosting.co.za>


New submission from Johannes:

Running the code attached causes a segmentation fault.

This only occurs when run from within a virtual environment, and when the class is an old style class.

I've tested on OSX with both 2.7.3 installed via Homebrew, and the default 2.7.2 Python installation.

Also got the same result testing with 2.7.3 on linux ([GCC 4.4.5] on linux2)

I've verified that exactly the same Python installation is being used inside and outside of the virtual env.

Running the same code under 2.5 and 2.6 results in no seg fault.

----------
components: Unicode
files: unicode-bug.py
messages: 182562
nosy: ezio.melotti, johtso
priority: normal
severity: normal
status: open
title: Seg fault when calling unicode() on old style class in virtualenv
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file29136/unicode-bug.py

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

From report at bugs.python.org  Thu Feb 21 00:20:42 2013
From: report at bugs.python.org (Wilson Harron)
Date: Wed, 20 Feb 2013 23:20:42 +0000
Subject: [New-bugs-announce] [issue17261] multiprocessing.manager
	BaseManager cannot return	proxies from proxies remotely (when
	listening on '')
Message-ID: <1361402442.38.0.214511208873.issue17261@psf.upfronthosting.co.za>


New submission from Wilson Harron:

If a manager is running listening to all ports ('0.0.0.0') and the manager has a proxy that returns another proxy the client will not be able to create the resulting proxy. 

This is because the server (manager) returns '0.0.0.0' in the token returned, and the therefore the client cannot connect to the proxy.

----------
components: Library (Lib)
files: proxytest.py
messages: 182567
nosy: Wilson.Harron
priority: normal
severity: normal
status: open
title: multiprocessing.manager BaseManager cannot return proxies from proxies remotely (when listening on '')
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file29137/proxytest.py

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

From report at bugs.python.org  Thu Feb 21 00:34:31 2013
From: report at bugs.python.org (Matthew Porter)
Date: Wed, 20 Feb 2013 23:34:31 +0000
Subject: [New-bugs-announce] [issue17262] OrderedDict not ordering properly
	when int and float	keys are used
Message-ID: <1361403271.7.0.362355753291.issue17262@psf.upfronthosting.co.za>


New submission from Matthew Porter:

I've got two lists:

state_cns_list = [0.001, 1, 2, 5]
state_names_list = [L, S, D, H]

When I try to create an OrderedDict linking each state_cns_list entry with its corresponding state_names_list entry, like so:

states = OrderedDict( {float(state_cns_list[i]): state_names_list[i] for i in range(0, len(state_cns_list) ) } )

rather than maintaining the original order, (0.001, 'L') is placed at the end of the OrderedDict instead of at the beginning. The attached screenshot shows the bug in action.

Although it's not in the screenshot, when I try placing 4 integers into state_cns_list instead of 3 integers and a float, it has no problem correctly ordering them.

----------
components: Library (Lib)
files: OrderedDictBug.png
messages: 182570
nosy: MrDrMcNinja
priority: normal
severity: normal
status: open
title: OrderedDict not ordering properly when int and float keys are used
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file29138/OrderedDictBug.png

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

From report at bugs.python.org  Thu Feb 21 03:37:51 2013
From: report at bugs.python.org (Albert Zeyer)
Date: Thu, 21 Feb 2013 02:37:51 +0000
Subject: [New-bugs-announce] [issue17263] crash when tp_dealloc allows other
	threads
Message-ID: <1361414271.61.0.154662693899.issue17263@psf.upfronthosting.co.za>


New submission from Albert Zeyer:

If you have some Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS in some tp_dealloc and you use such objects in thread local storage, you might get crashes, depending on which thread at what time is trying to cleanup such object.

I haven't fully figured out the details but I have a somewhat reduced testcase. Note that I encountered this in practice because the sqlite connection object does that (while it disconnects, the GIL is released).

This is the C code with some dummy type which has a tp_dealloc which just sleeps for some seconds while the GIL is released: https://github.com/albertz/playground/blob/master/testcrash_python_threadlocal.c

This is the Python code: https://github.com/albertz/playground/blob/master/testcrash_python_threadlocal_py.py

The Python code also contains some code path with a workaround which I'm using currently to avoid such crashes in my application.

----------
components: Interpreter Core
messages: 182577
nosy: Albert.Zeyer
priority: normal
severity: normal
status: open
title: crash when tp_dealloc allows other threads
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb 21 06:31:37 2013
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 21 Feb 2013 05:31:37 +0000
Subject: [New-bugs-announce] [issue17264] Update Building C and C++
	Extensions with distutils	documentation
Message-ID: <1361424697.21.0.435186366661.issue17264@psf.upfronthosting.co.za>


New submission from Berker Peksag:

I have removed all mentions about Python 1.4 and 2.0 from the
Doc/extending/building.rst. The Demo/embed/demo.c file has been removed
in 3.x, so I used "_spammodule.c" convention in the examples. The patch
also fixes all the PEP 8 violations in the setup.py examples.

----------
assignee: docs at python
components: Documentation
files: extending_building.diff
keywords: patch
messages: 182580
nosy: berker.peksag, docs at python
priority: normal
severity: normal
status: open
title: Update Building C and C++ Extensions with distutils documentation
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29139/extending_building.diff

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

From report at bugs.python.org  Thu Feb 21 11:22:53 2013
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 21 Feb 2013 10:22:53 +0000
Subject: [New-bugs-announce] [issue17265] Fix code highlight in the
	string.Template example
Message-ID: <1361442173.54.0.636977932686.issue17265@psf.upfronthosting.co.za>


New submission from Berker Peksag:

See for the current version:

http://docs.python.org/3.4/library/string.html#string.Template.template

----------
assignee: docs at python
components: Documentation
files: string_template_highlight.diff
keywords: patch
messages: 182584
nosy: berker.peksag, docs at python
priority: normal
severity: normal
status: open
title: Fix code highlight in the string.Template example
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29141/string_template_highlight.diff

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

From report at bugs.python.org  Thu Feb 21 12:11:30 2013
From: report at bugs.python.org (Helmut Jarausch)
Date: Thu, 21 Feb 2013 11:11:30 +0000
Subject: [New-bugs-announce] [issue17266] Idle + tcl 8.6.0 Can't convert
	'_tkinter.Tcl_Obj' object	to str implicitly
Message-ID: <1361445090.41.0.645711703675.issue17266@psf.upfronthosting.co.za>


New submission from Helmut Jarausch:

I have tcl/tk 8.6.0 installed here. Both Python versions below
are build from source.

I'm using LANG=en_US.iso88591 here if that matters.

When opening a file in Idle with 
python-3.3.1 revision: c08bcf5302ec

or

python-3.4.0a0 (default:3a110a506d35) (HG version)

I get
Failed to load extension 'CodeContext'
Traceback (most recent call last):
  File "/home/jarausch/GenToo/LOC/TEST/Python/cpython/Lib/idlelib/EditorWindow.py", line 1034, in load_standard_extensions
    self.load_extension(name)
  File "/home/jarausch/GenToo/LOC/TEST/Python/cpython/Lib/idlelib/EditorWindow.py", line 1055, in load_extension
    ins = cls(self)
  File "/home/jarausch/GenToo/LOC/TEST/Python/cpython/Lib/idlelib/CodeContext.py", line 49, in __init__
    self.toggle_code_context_event()
  File "/home/jarausch/GenToo/LOC/TEST/Python/cpython/Lib/idlelib/CodeContext.py", line 66, in toggle_code_context_event
    padx += int(str( widget.pack_info()['padx'] ))
  File "/home/jarausch/GenToo/LOC/TEST/Python/cpython/Lib/tkinter/__init__.py", line 1919, in pack_info
    self.tk.call('pack', 'info', self._w))
TypeError: Can't convert '_tkinter.Tcl_Obj' object to str implicitly

----------
components: IDLE
messages: 182587
nosy: HJarausch
priority: normal
severity: normal
status: open
title: Idle + tcl 8.6.0 Can't convert '_tkinter.Tcl_Obj' object to str implicitly
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Feb 21 13:47:59 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 21 Feb 2013 12:47:59 +0000
Subject: [New-bugs-announce] [issue17267] datetime.time support for '+' and
	'now'
Message-ID: <1361450879.34.0.390010426075.issue17267@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

It would be nice if datetime.time would be possible to add a delta to a datetime.time object, and if datetime.time had a method for returning the current time (just like datetime.date and date time.datetime have 'today' and 'now' methods).

Rationale for the '+' operator: calculating the wall clock time some time after an time on an unspecified date. The easy solution would be:

   tm = datetime.time(13, 20)
   later = tm + datetime.timedelta(hours=5, minutes=44)

That's is currently not possible, but requires more complicated code.

Getting the current time without date information currently requires getting done with 'datetime.datetime.now().time()', a class method of 'datetime.time' would IMHO be nicer. I must admit that I don't have a good suggestion for the name of that method.

----------
components: Library (Lib)
messages: 182592
nosy: ronaldoussoren
priority: normal
severity: normal
stage: test needed
status: open
title: datetime.time support for '+' and 'now'
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Feb 21 17:31:51 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 21 Feb 2013 16:31:51 +0000
Subject: [New-bugs-announce] [issue17268] Context managers written as C
	types no longer work in	Python 2.7
Message-ID: <1361464311.73.0.77004817262.issue17268@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg:

We have implemented the context manager API for connections and cursors in our mxODBC module and this works fine in Python 2.6.

In Python 2.7 we get the following error:

Traceback (most recent call last):
  File "context-manager.py", line 6, in <module>
    with db.cursor() as cursor:
AttributeError: __exit__

Here's the code snippet:

import mx.ODBC.unixODBC as ODBC
connectionString = '...'
db = ODBC.DriverConnect(connectionString)
with db.cursor() as cursor:
    print cursor

The mxODBC cursor is not an instance, it's implemented as Python type in C. It implements the tp_getattr slot, but not the tp_desc_get slot.

Looking at the apparently new API _PyObject_LookupSpecial(), this does not appear to support the tp_getattr slot and goes straight for the tp_desc_get slot.

----------
messages: 182598
nosy: lemburg
priority: normal
severity: normal
status: open
title: Context managers written as C types no longer work in Python 2.7
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb 22 00:31:53 2013
From: report at bugs.python.org (Johan Tibell)
Date: Thu, 21 Feb 2013 23:31:53 +0000
Subject: [New-bugs-announce] [issue17269] getaddrinfo segfaults on OS X when
	provided with invalid	arguments combinations
Message-ID: <1361489513.5.0.894275569557.issue17269@psf.upfronthosting.co.za>


New submission from Johan Tibell:

The following call to getaddrinfo makes Python segfault:

$ python
Python 2.7.2 (default, Jun 20 2012, 16:23:33) 
[GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.getaddrinfo("localhost", None, 0, 0, 0, socket.AI_NUMERICSERV)
Segmentation fault: 11

The combination of no port (None) and socket.AI_NUMERICSERV makes no sense (I used it by mistake) but we probably don't want to segfault anyway.

----------
components: Library (Lib)
messages: 182615
nosy: tibbe
priority: normal
severity: normal
status: open
title: getaddrinfo segfaults on OS X when provided with invalid arguments combinations
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb 22 03:18:03 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 22 Feb 2013 02:18:03 +0000
Subject: [New-bugs-announce] [issue17270] make the section header doc
	convention more clearly	optional
Message-ID: <1361499483.55.0.95674710032.issue17270@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The documentation guidelines in the devguide list a convention for section headers:

http://docs.python.org/devguide/documenting.html#sections

The current wording, however, can be interpreted to mean that this convention is always (and should always) be used.  However, the reality is weaker.  For example, see:

http://bugs.python.org/issue17109#msg181302

This issue is to update the wording so the convention is more clearly a suggestion rather than a requirement.

----------
components: Devguide
files: devguide-section-headers.diff
keywords: easy, patch
messages: 182620
nosy: chris.jerdonek, eric.araujo, ezio.melotti, ncoghlan
priority: normal
severity: normal
stage: patch review
status: open
title: make the section header doc convention more clearly optional
type: enhancement
Added file: http://bugs.python.org/file29153/devguide-section-headers.diff

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

From report at bugs.python.org  Fri Feb 22 06:55:23 2013
From: report at bugs.python.org (Jason S Friedman)
Date: Fri, 22 Feb 2013 05:55:23 +0000
Subject: [New-bugs-announce] [issue17271] NamedTemporaryFile expects bytes,
	not string in documentation for tempfile module
Message-ID: <1361512523.63.0.313343662334.issue17271@psf.upfronthosting.co.za>


New submission from Jason S Friedman:

Page is http://docs.python.org/3/library/tempfile.html#module-tempfile.

The code in question currently reads:
>>> f = NamedTemporaryFile(delete=False)
>>> f
<open file '<fdopen>', mode 'w+b' at 0x384698>
>>> f.name
'/var/folders/5q/5qTPn6xq2RaWqk+1Ytw3-U+++TI/-Tmp-/tmpG7V1Y0'
>>> f.write("Hello World!\n")
>>> f.close()
>>> os.unlink(f.name)
>>> os.path.exists(f.name)
False

It should read:
>>> import os
>>> from tempfile import NamedTemporaryFile
>>> f = NamedTemporaryFile(delete=False)
>>> f
<tempfile._TemporaryFileWrapper object at 0x29bfc50>
>>> f.name
'/tmp/tmpdxd_85'
>>> f.write("Hello World!\n".encode())
13
>>> f.close()
>>> os.unlink(f.name)
>>> os.path.exists(f.name)
False

----------
assignee: docs at python
components: Documentation
messages: 182640
nosy: docs at python, jsf80238 at gmail.com
priority: normal
severity: normal
status: open
title: NamedTemporaryFile expects bytes, not string in documentation for tempfile module
versions: Python 3.2

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

From report at bugs.python.org  Fri Feb 22 06:56:42 2013
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 22 Feb 2013 05:56:42 +0000
Subject: [New-bugs-announce] [issue17272] request.full_url: unexpected
	results on assignment
Message-ID: <1361512602.9.0.97298415685.issue17272@psf.upfronthosting.co.za>


New submission from Demian Brecht:

When assigning a value to an already instantiated Request object's full_url, unexpected results are found as a consequence in the attributes selector, type and fragment. Selector, type and fragment are only assigned to during instantiation. Unless you know to call Request._parse() after assignment to Request.full_url, the other attributes will not be reassigned new values.

The attached patch changes full_url to be a @property, essentially moving what was going on in the constructor into the property method(s). All tests pass.

I ran into this issue when working on an OAuth 2.0 client library when attempting to mutate an already instantiated Request object, injecting the access_token into the query params.

Sandboxed code to repro the issue below:

In [1]: from urllib.request import Request
In [2]: r = Request('https://example.com?foo=bar#baz')

# as expected
In [4]: r.__dict__
Out[4]: 
{'_data': None,
 '_tunnel_host': None,
 'fragment': 'baz',
 'full_url': 'https://example.com?foo=bar',
 'headers': {},
 'host': 'example.com',
 'method': None,
 'origin_req_host': 'example.com',
 'selector': '/?foo=bar',
 'type': 'https',
 'unredirected_hdrs': {},
 'unverifiable': False}

In [5]: r.full_url = 'https://example.com?foo=bar&access_token=token_value#baz'

# unexpected results in selector
In [6]: r.__dict__
Out[6]: 
{'_data': None,
 '_tunnel_host': None,
 'fragment': 'baz',
 'full_url': 'https://example.com?foo=bar&access_token=token_value#baz',
 'headers': {},
 'host': 'example.com',
 'method': None,
 'origin_req_host': 'example.com',
 'selector': '/?foo=bar',
 'type': 'https',
 'unredirected_hdrs': {},
 'unverifiable': False}

In [7]: Request('https://example.com?foo=bar&access_token=token_value#baz')
Out[7]: <urllib.request.Request at 0x10ef6ce90>

# these results should match that of the full_url setter
In [8]: Request('https://example.com?foo=bar&access_token=token_value#baz').__dict__
Out[8]: 
{'_data': None,
 '_tunnel_host': None,
 'fragment': 'baz',
 'full_url': 'https://example.com?foo=bar&access_token=token_value',
 'headers': {},
 'host': 'example.com',
 'method': None,
 'origin_req_host': 'example.com',
 'selector': '/?foo=bar&access_token=token_value',
 'type': 'https',
 'unredirected_hdrs': {},
 'unverifiable': False}

----------
components: Library (Lib)
files: request.patch
keywords: patch
messages: 182642
nosy: dbrecht
priority: normal
severity: normal
status: open
title: request.full_url: unexpected results on assignment
versions: Python 3.4
Added file: http://bugs.python.org/file29156/request.patch

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

From report at bugs.python.org  Fri Feb 22 07:20:53 2013
From: report at bugs.python.org (Arun Babu Neelicattu)
Date: Fri, 22 Feb 2013 06:20:53 +0000
Subject: [New-bugs-announce] [issue17273] multiprocessing.pool.Pool
	task/worker handlers are not	fork safe
Message-ID: <1361514053.16.0.91883779216.issue17273@psf.upfronthosting.co.za>


New submission from Arun Babu Neelicattu:

The task/worker handler threads in the multiprocessing.pool.Pool class are (in accordance to posix standards) not copied over when the process containing the pool is forked.

This leads to a situation where the Pool keeps receiving tasks but the tasks never get handled. This could potentially lead to deadlocks if AsyncResult.wait() is called.

Not sure if this should be considered as a bug, or an invalid use case. However, this becomes a problem when importing modules that use pools and the main code uses multiprocessing too.

[BAD] Workaround:
Reassigning Pool._task_handler to a new instance of threading.Thread after the fork seems to work in the case highlighted in the example.

Environment:
Fedora 18 
Linux 3.7.8-202.fc18.x86_64 #1 SMP Fri Feb 15 17:33:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
python3-3.3.0-1.fc18.x86_64

An example of this issue is shown below:

from multiprocessing import Pool, Process

def t2():
	# We expect the pool to handle this
	print('t2: Hello!')

pool = Pool()
def t1():
	# We assign a task to the pool
	pool.apply_async(t2)
	print('t1: Hello!')

if __name__ == '__main__':
	# Process() forks the main process containing the pool
	Process(target=t1).start()

----------
components: Library (Lib)
files: pool_forking.py
messages: 182647
nosy: abn
priority: normal
severity: normal
status: open
title: multiprocessing.pool.Pool task/worker handlers are not fork safe
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file29157/pool_forking.py

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

From report at bugs.python.org  Fri Feb 22 10:34:13 2013
From: report at bugs.python.org (Florian Berger)
Date: Fri, 22 Feb 2013 09:34:13 +0000
Subject: [New-bugs-announce] [issue17274] distutils silently omits relative
	symlinks
Message-ID: <1361525653.88.0.944877368203.issue17274@psf.upfronthosting.co.za>


New submission from Florian Berger:

This issue is related to #12585, #15205 and #8876.

In `distutils/archive_util.py`, in `make_zipfile()`, the code

    for dirpath, dirnames, filenames in os.walk(base_dir):
        for name in filenames:
            path = os.path.normpath(os.path.join(dirpath, name))
            if os.path.isfile(path):
                zip.write(path, path)
                log.info("adding '%s'" % path)

will silently omit relative symlinks from the archive.

Relative symlinks (`file.dat -> ../../../real_file.dat`) will become invalid when copied as-is into the package directory before compressing.
`os.path.isfile(path)` will evaluate to `False` in this case.

That is a critical condition, as the file has explicitly been specified for inclusion, but the package author is never warned about the fact, rendering the distributed package defunct in worst case.

Actual behaviour: relative symlinks are silently ignored.

Expected behaviour: any file that, for whatever reason, can not be included in the distribution archive should be warned about.

As hinted at in #15205, this might be fixed in `distutils2` / `packaging` in case it always dereferences and copies files.

This issue could be fixed without breaking behaviour if no Exception is raised, but a warning is printed.

With `packaging` available in Python 3.3, this report also serves as documentation of the problem for legacy Python programmers searching the web.

Thanks for considering.

----------
assignee: eric.araujo
components: Distutils
messages: 182658
nosy: eric.araujo, fberger, tarek
priority: normal
severity: normal
status: open
title: distutils silently omits relative symlinks
versions: Python 2.6, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Feb 22 12:51:50 2013
From: report at bugs.python.org (Manuel Jacob)
Date: Fri, 22 Feb 2013 11:51:50 +0000
Subject: [New-bugs-announce] [issue17275] io.BufferedWriter shows wrong type
	in argument error	message
Message-ID: <1361533910.18.0.171514836206.issue17275@psf.upfronthosting.co.za>


New submission from Manuel Jacob:

>>> import io
>>> io.BufferedWriter(io.BytesIO(), 1024, 1024, 1024)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: BufferedReader() takes at most 2 arguments (4 given)

It should be "BufferedWriter()" instead of "BufferedReader()".

----------
messages: 182660
nosy: mjacob
priority: normal
severity: normal
status: open
title: io.BufferedWriter shows wrong type in argument error message
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Feb 22 13:16:42 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 22 Feb 2013 12:16:42 +0000
Subject: [New-bugs-announce] [issue17276] HMAC: deprecate default hash
Message-ID: <1361535402.96.0.618065106631.issue17276@psf.upfronthosting.co.za>


New submission from Christian Heimes:

As of now the hash algorithm for HMAC defaults to MD5. However MD5 is considered broken. HMAC-MD5 is still ok but shall not be used in new code. Applications should slowly migrate away from HMAC-MD5 and use a more modern algorithm like HMAC-SHA256.

Therefore I propose that default digestmod should be deprecated in Python 3.4 and removed in 3.5. Starting with Python 3.5 developer are forced to choose a hash algorithm like SHA256. Our documentation shall suggest it, too.

In addition I would like to enhance the meaning of the `digestmod` argument a bit. Right now it either must be a module or a callable. It should also support a name, e.g. hmac.new("secret", digestmod="sha256")

----------
components: Library (Lib)
messages: 182662
nosy: christian.heimes
priority: normal
severity: normal
stage: needs patch
status: open
title: HMAC: deprecate default hash
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Feb 22 17:42:49 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 22 Feb 2013 16:42:49 +0000
Subject: [New-bugs-announce] [issue17277] incorrect line numbers in
	backtrace after removing a	trace function
Message-ID: <1361551369.14.0.772985934528.issue17277@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

It seems that using f_trace in the f_lineno getter PyFrame_GetLineNumber(), as
the condition to decide when tracing is active, is incorrect.
See the following two examples.

In the backtrace printed by tracer.py running with python 3.3,
the last entry should be line 12 instead of line 10:

$ python3 /tmp/tracer.py
Traceback (most recent call last):
  File "/tmp/tracer.py", line 15, in <module>
    foo()
  File "/tmp/tracer.py", line 10, in foo
    bar()
ZeroDivisionError: division by zero


This simple case does not occur with pdb, because pdb takes care of deleting
the f_trace attribute of all the frames in the call stack when removing the
trace function (see set_continue() in bdb.py). But this is not good enough when
a generator is involved as can be seen when running generator.py. In the
backtrace the last entry should be line 6 instead of line 8:

$ python3 /tmp/generator.py
> /tmp/generator.py(16)<module>()
-> foo()
(Pdb) step
--Call--
> /tmp/generator.py(10)foo()
-> def foo():
(Pdb) step
> /tmp/generator.py(11)foo()
-> it = gen()
(Pdb) step
> /tmp/generator.py(12)foo()
-> next(it)
(Pdb) step
--Call--
> /tmp/generator.py(3)gen()
-> def gen():
(Pdb) return
--Return--
> /tmp/generator.py(8)gen()->0
-> yield i
(Pdb) step
> /tmp/generator.py(13)foo()
-> next(it)
(Pdb) continue
Traceback (most recent call last):
  File "/tmp/generator.py", line 16, in <module>
    foo()
  File "/tmp/generator.py", line 13, in foo
    next(it)
  File "/tmp/generator.py", line 8, in gen
    yield i
ZeroDivisionError: division by zero


It seems that it could be possible to fix this issue by replacing the test for
f->f_trace in PyFrame_GetLineNumber, by a test for f->f_tstate->use_tracing,
and updating accordingly the f_lineno and f_trace setters.

----------
components: Interpreter Core
files: tracer.py
messages: 182672
nosy: xdegaye
priority: normal
severity: normal
status: open
title: incorrect line numbers in backtrace after removing a trace function
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29162/tracer.py

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

From report at bugs.python.org  Fri Feb 22 21:25:39 2013
From: report at bugs.python.org (maxxedev)
Date: Fri, 22 Feb 2013 20:25:39 +0000
Subject: [New-bugs-announce] [issue17278] SIGSEGV in _heapqmodule.c
Message-ID: <1361564739.94.0.652055114597.issue17278@psf.upfronthosting.co.za>


New submission from maxxedev:

I've been getting sporadic SIGSEGV crashes in _heapqmodule.c

I have not be able to reliably reproduce it, but here is a stacktrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2aaaad51d940 (LWP 13976)]
(gdb) where
#0  0x00002aaaab617e8a in _siftdown (heap=0xa1f2d8, startpos=0, pos=46)
    at [...]/Python-2.7.2/Modules/_heapqmodule.c:67
#1  0x00002aaaab617f76 in heappush (self=<value optimized out>, args=<value optimized out>)
    at [...]/Python-2.7.2/Modules/_heapqmodule.c:137
#2  0x000000000049ba34 in call_function (f=0xa565e0, throwflag=<value optimized out>) at Python/ceval.c:4013
#3  PyEval_EvalFrameEx (f=0xa565e0, throwflag=<value optimized out>) at Python/ceval.c:2666
#4  0x000000000049ca8d in call_function (f=0xa60f40, throwflag=<value optimized out>) at Python/ceval.c:4099
#5  PyEval_EvalFrameEx (f=0xa60f40, throwflag=<value optimized out>) at Python/ceval.c:2666
#6  0x000000000049ca8d in call_function (f=0xa5e210, throwflag=<value optimized out>) at Python/ceval.c:4099
#7  PyEval_EvalFrameEx (f=0xa5e210, throwflag=<value optimized out>) at Python/ceval.c:2666
#8  0x000000000049ca8d in call_function (f=0xa5e020, throwflag=<value optimized out>) at Python/ceval.c:4099
#9  PyEval_EvalFrameEx (f=0xa5e020, throwflag=<value optimized out>) at Python/ceval.c:2666
#10 0x000000000049ca8d in call_function (f=0xa5de00, throwflag=<value optimized out>) at Python/ceval.c:4099
#11 PyEval_EvalFrameEx (f=0xa5de00, throwflag=<value optimized out>) at Python/ceval.c:2666
#12 0x000000000049ca8d in call_function (f=0xa5dc30, throwflag=<value optimized out>) at Python/ceval.c:4099
#13 PyEval_EvalFrameEx (f=0xa5dc30, throwflag=<value optimized out>) at Python/ceval.c:2666
#14 0x000000000049d87b in PyEval_EvalCodeEx (co=0x896530, globals=<value optimized out>, locals=<value optimized out>,
    args=0x99dba8, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3253
#15 0x00000000004fbf9f in function_call (func=0x8c30c8, arg=0x99db90, kw=0x0) at Objects/funcobject.c:526
#16 0x000000000041882d in PyObject_Call (func=0x8c30c8, arg=0x99db90, kw=0x0) at Objects/abstract.c:2529
#17 0x000000000041fd3f in instancemethod_call (func=<value optimized out>, arg=0x99db90, kw=0x0)
    at Objects/classobject.c:2578
#18 0x000000000041882d in PyObject_Call (func=0x2aaaaab7e730, arg=0x2aaaaaabc050, kw=0x0) at Objects/abstract.c:2529
#19 0x0000000000494a66 in PyEval_CallObjectWithKeywords (func=0x2aaaaab7e730, arg=0x2aaaaaabc050, kw=0x0)
    at Python/ceval.c:3882
#20 0x00000000004d30d2 in t_bootstrap (boot_raw=0x96d320) at ./Modules/threadmodule.c:614
#21 0x0000003fa780683d in start_thread () from /lib64/libpthread.so.0
#22 0x0000003fa6cd503d in clone () from /lib64/libc.so.6

----------
components: Library (Lib)
messages: 182698
nosy: maxxedev
priority: normal
severity: normal
status: open
title: SIGSEGV in _heapqmodule.c
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb 22 23:09:24 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Feb 2013 22:09:24 +0000
Subject: [New-bugs-announce] [issue17279] Document which named built-in
	classes can be subclassed
Message-ID: <1361570964.09.0.896873756654.issue17279@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

More than once, people have noted on python-list that not all built-in classes can be subclassed and that there seems to be no way to find out which, other than to try each. (Today, Daniel Urban pointed out the CPython-specific 'xx.__flags__ & (1 << 10)'.) If the specifics are a Python feature, rather than CPython specific, I think they should be given in the doc.

There is a recent issue, which I cannot find, about re-organizing the Library built-in functions chapter by groups. If this is done, it would be easy to add, in the introduction to built-in classes, a list of which of the named classes can or cannot be subclassed (whichever list is shorter) and note that those not in builtins cannot be.)

----------
assignee: docs at python
components: Documentation
messages: 182703
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Document which named built-in classes can be subclassed
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Feb 23 14:21:24 2013
From: report at bugs.python.org (Alex)
Date: Sat, 23 Feb 2013 13:21:24 +0000
Subject: [New-bugs-announce] [issue17280] path.basename and ntpath.basename
	functions returns an	incorrect file name in Windows 7
Message-ID: <1361625684.2.0.806923079144.issue17280@psf.upfronthosting.co.za>


New submission from Alex:

1. I created file ("C:\Users\Alkor\Desktop\a3434.raw") on my desktop 
2. Tried to get the file name from the absolute path

Actual result:
C:\Users\Alkor>python
Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> print os.path.basename ("C:\Users\Alkor\Desktop\a3434.raw")
Desktop3434.raw

The same for ntpath module:
>>> import ntpath
>>> print ntpath.basename ("C:\Users\Alkor\Desktop\a3434.raw")
Desktop3434.raw

Expected result:
a3434.raw

Environment:
Windows 7 x64 SP1 Ultimate
python 2.7.3150 (64-bit)

----------
components: Windows
messages: 182739
nosy: Ternovoy, brian.curtin, loewis, tim.golden
priority: normal
severity: normal
status: open
title: path.basename and ntpath.basename functions returns an incorrect file name in Windows 7
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Feb 23 15:43:55 2013
From: report at bugs.python.org (Kevin Lyda)
Date: Sat, 23 Feb 2013 14:43:55 +0000
Subject: [New-bugs-announce] [issue17281] Broken links at pypi
Message-ID: <1361630635.92.0.90935154891.issue17281@psf.upfronthosting.co.za>


New submission from Kevin Lyda:

The pypi entry for distutils2 has a comical set of broken links (docs and contributing): https://pypi.python.org/pypi/Distutils2

The following two paragraphs have broken links. Adding a link checker to your browser isn't the worst idea.

The Distutils2 codebase is a fork of Distutils. It is not backward compatible with Distutils and does not depend on it. It provides more features and implements new packaging standards. In Python 3.3, Distutils2 is included in the standard library under the module name "packaging". Documentation is provided at http://docs.python.org/dev/packaging 404 --for ease of maintenance, it is not duplicated in this repository. You can use the Packaging documentation to use Distutils2; only the package name is different (packaging vs. distutils2), all modules, classes and functions have the same name.

If you want to contribute, please have a look at DEVNOTES.txt or http://wiki.python.org/Distutils2/Contributing 404 .

----------
assignee: eric.araujo
components: Distutils2
messages: 182747
nosy: alexis, eric.araujo, lyda, tarek
priority: normal
severity: normal
status: open
title: Broken links at pypi
type: behavior
versions: 3rd party, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Feb 24 01:14:54 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 24 Feb 2013 00:14:54 +0000
Subject: [New-bugs-announce] [issue17282] document the defaultTest parameter
	to unittest.main()
Message-ID: <1361664894.83.0.085559336561.issue17282@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to document the defaultTest parameter to unittest.main():

http://docs.python.org/dev/library/unittest.html#unittest.main

Note that it is not enough simply to say that *defaultTest* is a "default test name or iterable of test names."  The documentation should also say when *defaultTest* is used based on the value of the *module* and *argv* arguments, etc.

This issue is an offshoot of issue 15132.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 182839
nosy: chris.jerdonek, docs at python, ezio.melotti, michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: document the defaultTest parameter to unittest.main()
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Feb 24 06:57:28 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 24 Feb 2013 05:57:28 +0000
Subject: [New-bugs-announce] [issue17283] Lib/test/__main__.py should share
	code with regrtest.py
Message-ID: <1361685448.23.0.991458523446.issue17283@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

As discussed here:

http://bugs.python.org/issue15305#msg182853

this issue is for Lib/test/__main__.py to share code with Lib/test/regrtest.py to minimize duplication of code:

http://hg.python.org/cpython/file/96f08a22f562/Lib/test/regrtest.py#l1594
http://hg.python.org/cpython/file/96f08a22f562/Lib/test/__main__.py#l12

----------
components: Tests
keywords: easy
messages: 182854
nosy: chris.jerdonek, ezio.melotti, gmwils, michael.foord, petri.lehtinen, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Lib/test/__main__.py should share code with regrtest.py
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Feb 24 09:37:39 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 24 Feb 2013 08:37:39 +0000
Subject: [New-bugs-announce] [issue17284] create mercurial section in
	devguide's committing.rst
Message-ID: <1361695059.15.0.281280075427.issue17284@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

As discussed in issue 14468, this issue is to reorder the sections in the devguide's committing.rst to create a section dedicated to using Mercurial when committing.  The attached patch is adapted from the "2-move_two_sections.diff" patch of that issue.

----------
components: Devguide
files: mercurial-section-1.patch
keywords: easy, patch
messages: 182859
nosy: chris.jerdonek, eric.araujo, ezio.melotti, ncoghlan, pitrou, sandro.tosi, terry.reedy, tshepang
priority: normal
severity: normal
stage: patch review
status: open
title: create mercurial section in devguide's committing.rst
type: enhancement
Added file: http://bugs.python.org/file29217/mercurial-section-1.patch

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

From report at bugs.python.org  Sun Feb 24 12:43:50 2013
From: report at bugs.python.org (Baptiste Lepilleur)
Date: Sun, 24 Feb 2013 11:43:50 +0000
Subject: [New-bugs-announce] [issue17285] subprocess.check_output
	incorrectly state that output is	always bytes
Message-ID: <1361706230.84.0.572016082.issue17285@psf.upfronthosting.co.za>


New submission from Baptiste Lepilleur:

Documentation states:

>>> help( subprocess.check_output )
check_output(*popenargs, timeout=None, **kwargs)
    Run command with arguments and return its output as a byte string.

But the most common usage is:
>>> subprocess.check_output( 'echo test', shell=True, universal_newlines=True )
'test\n'

Which obviously output a text string, not a byte string.

IMHO, one of the example should also be modified to show the existence of this flag, as it is what user want 90% of the times.

----------
assignee: docs at python
components: Documentation
messages: 182868
nosy: Baptiste.Lepilleur, docs at python
priority: normal
severity: normal
status: open
title: subprocess.check_output incorrectly state that output is always bytes
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Feb 24 13:20:55 2013
From: report at bugs.python.org (Baptiste Lepilleur)
Date: Sun, 24 Feb 2013 12:20:55 +0000
Subject: [New-bugs-announce] [issue17286] Make subprocess handling text
	output with	universal_newlines more obious
Message-ID: <1361708455.88.0.426093416103.issue17286@psf.upfronthosting.co.za>


New submission from Baptiste Lepilleur:

It tooks me a while to figure out that using universal_newlines was the solution to "tell" subprocess that I wanted text string output instead of byte string.

A search on stackoverflow shows that this issue is common and the solution nearly unknown (answer is usually to decode the byte string manually)...

Because dealing with text output is IMHO the most common use case, the subprocess documentation should make it easier to "find" the recipe.

I would suggest changing the documentation so that the universal_newlines is made obvious as it is very important:
1) the first /bin/vikings example be modified to show the use of this flag (at the top of the documentation, most people copy/past that):
  >>> p = subprocess.Popen(args, universal_newlines=True) # Success!
  and at a small comment below the example to explain that flag
2) change other example similarly when that make sense, IMHO:
   - ifconfig example
   - one of the subprocess.check_output example
   - subprocess.check_output() example, consider separating the byte string / text string example for increased visibility
3) consider adding a section with an obvious title "Dealing with binary and text input/output", providing examples and pointer to the correct documentation (I would place it after the convenience functions section for visibility). I think this would help attracting "eye" on this large piece of documentation.

----------
assignee: docs at python
components: Documentation
messages: 182872
nosy: Baptiste.Lepilleur, docs at python
priority: normal
severity: normal
status: open
title: Make subprocess handling text output with universal_newlines more obious
type: enhancement
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Feb 24 13:49:20 2013
From: report at bugs.python.org (Elazar Gershuni)
Date: Sun, 24 Feb 2013 12:49:20 +0000
Subject: [New-bugs-announce] [issue17287] slice inconsistency
Message-ID: <1361710160.02.0.405810839131.issue17287@psf.upfronthosting.co.za>


New submission from Elazar Gershuni:

slice behavior is not consistent for negative lower or upper arguments, which could be surprising:

>>> 'hello'[:-2]
'hel'
>>> 'hello'[:-1]
'hell'
>>> 'hello'[:-0]
''

this is obvious when written as literal, but not so obvious when using variables in expressions like 'fullname[:-len(lastname)]'. same goes for 'lower'.

----------
components: None
messages: 182874
nosy: elazar
priority: normal
severity: normal
status: open
title: slice inconsistency
type: enhancement
versions: Python 3.1

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

From report at bugs.python.org  Sun Feb 24 18:26:53 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 24 Feb 2013 17:26:53 +0000
Subject: [New-bugs-announce] [issue17288] cannot jump from a return after
	setting f_lineno
Message-ID: <1361726813.15.0.719765769531.issue17288@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

On python 3.3 and the default branch, the jump from a 'return' fails although
the change to f_lineno is validated, see below.

This problem does not occur with python 2.7.

$ python return.py
> /tmp/return.py(8)<module>()
-> foo()
(Pdb) break 5
Breakpoint 1 at /tmp/return.py:5
(Pdb) continue
> /tmp/return.py(5)foo()
-> lineno = 5
(Pdb) step
--Return--
> /tmp/return.py(5)foo()->None
-> lineno = 5
(Pdb) jump 4
> /tmp/return.py(4)foo()->None
-> lineno = 4
(Pdb) where
  /tmp/return.py(8)<module>()
-> foo()
> /tmp/return.py(4)foo()->None
-> lineno = 4
(Pdb) step
--Return--
> /tmp/return.py(8)<module>()->None
-> foo()
(Pdb)

----------
components: Interpreter Core
files: return.py
messages: 182880
nosy: xdegaye
priority: normal
severity: normal
status: open
title: cannot jump from a return after setting f_lineno
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29223/return.py

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

From report at bugs.python.org  Sun Feb 24 18:32:42 2013
From: report at bugs.python.org (Bradley Froehle)
Date: Sun, 24 Feb 2013 17:32:42 +0000
Subject: [New-bugs-announce] [issue17289] readline.set_completer_delims()
	doesn't play well with	others
Message-ID: <1361727162.6.0.330340271384.issue17289@psf.upfronthosting.co.za>


New submission from Bradley Froehle:

The `readline.set_completer_delims` doesn't play well with others because
it assumes that only it ever allocates or modifies the
rl_completer_word_break_characters buffer.  If other programs modify this
value, for example changing it from heap allocated space to stack
allocated space, the results can be catastrophic.

To remind you, the function essentially works as:

    set_completer_delims(PyObject *self, PyObject *args)
    {
        // ...
        free((void*) rl_completer_word_break_characters;
        rl_completer_word_break_characters = strdup(break_chars);
        // ...
    }

where `break_chars` is the user provided string.

Take, for example, R as another programs which changes the readline
completer strings.  When an embedded R instance is initialized (say, using
`r2py`) something similar to the following takes place::

    static void
    set_rl_completer_word_break_characters(const char *new)
    {
        static char[201] buffer;
        strncpy(buffer, new, 200);
        rl_completer_word_break_characters = buffer;
    }

    static void
    initialize_embedded_R(...)
    {
        // ...
        set_rl_completer_word_break_characters(...);
    }

As you might expect the next trip through `readline.set_completer_delims`
after initializing R will be catastrophic when we attempt to free a stack
allocate buffer.

I think we should consider modifying the `readline.set_completer_delims`
to store the allocated buffers in the module state::

    set_completer_delims(PyObject *self, PyObject *args)
    {
        // ...
        free(_readlinestate_global->break_chars);
        rl_completer_word_break_characters = strdup(break_chars);
        _readlinestate_global->break_chars = rl_completer_word_break_characters;
        // ...
    }

This would prevent the segfault and memory leaks, and would render weird
hacks (like https://bitbucket.org/lgautier/rpy2/commits/408bae913653 in
the r2py code) unnecessary.

----------
components: Extension Modules
messages: 182882
nosy: bfroehle
priority: normal
severity: normal
status: open
title: readline.set_completer_delims() doesn't play well with others
type: crash
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Feb 24 22:34:32 2013
From: report at bugs.python.org (netrick)
Date: Sun, 24 Feb 2013 21:34:32 +0000
Subject: [New-bugs-announce] [issue17290] pythonw - loading cursor bug when
	launching scripts
Message-ID: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>


New submission from netrick:

Firstly, just to mention - the issue that I will describe doesn't exist in python 2.7. It is python3 and windows related (python 3.3 for sure, didn't test previous). I also tested it on 2 different PCs (one fresh windows install, second long running with different hardware), so it's not my OS messed up.

So - the issue appears with every gui script I tried (PySide and tkinter, various codes).  Basically when I have the script saved as "*.py", everything is great but there is unwanted console. So I save the script as "*.pyw" to run it using "pythonw" without console. When I run it  there is indeed no console, but for the first 10-15 seconds no matter what I do the cursor is "loading cursor", everywhere in Windows. (see the screen I uploaded to this issue). I can click everything but the cursor won't return to normal for about 15 secs. Of course, the cursor is normal when using standard python 3.3 (with console) or pythonw 2.7.

The code pasted from 3.3 documentation which reproduces the problem:

#START CODE
import tkinter as tk

class Application(tk.Frame):
    def __init__(self, master=None):
        tk.Frame.__init__(self, master)
        self.pack()
        self.createWidgets()

    def createWidgets(self):
        self.hi_there = tk.Button(self)
        self.hi_there["text"] = "Hello World\n(click me)"
        self.hi_there["command"] = self.say_hi
        self.hi_there.pack(side="top")

        self.QUIT = tk.Button(self, text="QUIT", fg="red",
                                            command=root.destroy)
        self.QUIT.pack(side="bottom")

    def say_hi(self):
        print("hi there, everyone!")

root = tk.Tk()
app = Application(master=root)
app.mainloop()
#END CODE

To sum up, the issue is present with pythonw 3.3 on Windows XP 32 bit.
BUT! When I typed in terminal:

ftype Python.File=C:\Python33\pythonw.exe "%1" %*

then every .py file started to be run using pythonw. What matters is in that case, there is no loading cursor at all! Add to it that in python 2.7 the issue doesn't exist and I think that in recent windows packages something with extensions is messed up. I have no idea what, but this stops me from using python3 for serious GUI development on windows (which is something I really want to do).

I wanted to write some commercial GUI apps using python, but I can't say my customers to type that line in terminal. Also, they won't accept terminal or 15 sec loading cursor. It's just unwanted thing. Right now I have to use python 2.7, but I like python 3 much more. I think it's something with the way ".pyw" extension is handled as something adds that loading cursor.

Python is the best, I hope that you will be able to fix it!

----------
components: Installation, Tkinter, Windows
files: AZb4toA.jpg
messages: 182895
nosy: netrick
priority: normal
severity: normal
status: open
title: pythonw - loading cursor bug when launching scripts
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file29224/AZb4toA.jpg

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

From report at bugs.python.org  Sun Feb 24 22:37:00 2013
From: report at bugs.python.org (Riley)
Date: Sun, 24 Feb 2013 21:37:00 +0000
Subject: [New-bugs-announce] [issue17291] Login-data raising EOFError
Message-ID: <1361741820.39.0.315848674206.issue17291@psf.upfronthosting.co.za>


New submission from Riley:

When running Pywikipediabot and retrieving a password I get the following error:
Password for user RileyBot on wiktionary:en: 
/usr/lib/python2.7/getpass.py:83: GetPassWarning: Can not control echo on the terminal.
  passwd = fallback_getpass(prompt, stream)
Warning: Password input may be echoed.
Traceback (most recent call last):
  File "globalfunc1.py", line 250, in <module>
    main()
  File "globalfunc1.py", line 244, in main
    bot.run()
  File "globalfunc1.py", line 197, in run
    sandboxPage.put(translatedContent, translatedMsg)
  File "/home/riley/pywikipedia/wikipedia.py", line 1990, in put
    sysop=sysop)
  File "/home/riley/pywikipedia/wikipedia.py", line 1863, in _getActionUser
    self.site().forceLogin(sysop = sysop)
  File "/home/riley/pywikipedia/wikipedia.py", line 5861, in forceLogin
    if loginMan.login(retry = True):
  File "/home/riley/pywikipedia/login.py", line 307, in login
    password = True)
  File "/home/riley/pywikipedia/wikipedia.py", line 8927, in input
    data = ui.input(question, password)
  File "/home/riley/pywikipedia/userinterfaces/terminal_interface_base.py", line 129, in input
    text = getpass.getpass('')
  File "/usr/lib/python2.7/getpass.py", line 83, in unix_getpass
    passwd = fallback_getpass(prompt, stream)
  File "/usr/lib/python2.7/getpass.py", line 118, in fallback_getpass
    return _raw_input(prompt, stream)
  File "/usr/lib/python2.7/getpass.py", line 135, in _raw_input
    raise EOFError
EOFError

While this may have something to do with Pywikipediabot, it all comes down to python. Help?

----------
components: None
messages: 182896
nosy: Riley
priority: normal
severity: normal
status: open
title: Login-data raising EOFError
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb 25 05:54:47 2013
From: report at bugs.python.org (Nathan Binkert)
Date: Mon, 25 Feb 2013 04:54:47 +0000
Subject: [New-bugs-announce] [issue17292] Autonumbering in string.Formatter
	doesn't work
Message-ID: <1361768087.85.0.505159219434.issue17292@psf.upfronthosting.co.za>


New submission from Nathan Binkert:

Autonumbering with string.format does not work as it does in str.format:

>>> '{}'.format(1)
'1'
>>> import string
>>> string.Formatter().format('{}', 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/nate/src/python3/Lib/string.py", line 164, in format
    return self.vformat(format_string, args, kwargs)
  File "/Users/nate/src/python3/Lib/string.py", line 168, in vformat
    result = self._vformat(format_string, args, kwargs, used_args, 2)
  File "/Users/nate/src/python3/Lib/string.py", line 190, in _vformat
    obj, arg_used = self.get_field(field_name, args, kwargs)
  File "/Users/nate/src/python3/Lib/string.py", line 253, in get_field
    obj = self.get_value(first, args, kwargs)
  File "/Users/nate/src/python3/Lib/string.py", line 210, in get_value
    return kwargs[key]

----------
components: Library (Lib)
messages: 182916
nosy: binkert
priority: normal
severity: normal
status: open
title: Autonumbering in string.Formatter doesn't work
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon Feb 25 08:29:08 2013
From: report at bugs.python.org (=?utf-8?q?Aivars_Kalv=C4=81ns?=)
Date: Mon, 25 Feb 2013 07:29:08 +0000
Subject: [New-bugs-announce] [issue17293] uuid.getnode() MAC address on AIX
Message-ID: <1361777348.15.0.791534887595.issue17293@psf.upfronthosting.co.za>


New submission from Aivars Kalv?ns:

uuid.getnode() on AIX returned random integer. This patch finds MAC in output of `netstat -ia`.
Tested on AIX 5.2

----------
components: Library (Lib)
files: aix_mac.patch
keywords: patch
messages: 182925
nosy: aivarsk
priority: normal
severity: normal
status: open
title: uuid.getnode() MAC address on AIX
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file29229/aix_mac.patch

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

From report at bugs.python.org  Mon Feb 25 14:11:26 2013
From: report at bugs.python.org (Albert Zeyer)
Date: Mon, 25 Feb 2013 13:11:26 +0000
Subject: [New-bugs-announce] [issue17294] compile-flag for single-execution
	to return value	instead of printing it
Message-ID: <1361797886.48.0.856864897447.issue17294@psf.upfronthosting.co.za>


New submission from Albert Zeyer:

`compile(s, "<interactive>", "single")` would generate a code object which prints the value of the evaluated string if that is an expression. This is what you would normally want in a REPL.

Instead of printing the value, it might make more sense to return it and to leave it to the developer - there are many cases where it shouldn't end up on stdout but somewhere else.

There could be an additional compile-flag which would make a code-object returning the value instead of printing it.

Note that I have come up with a workaround:

def interactive_py_compile(source, filename="<interactive>"):
    c = compile(source, filename, "single")

    # we expect this at the end:
    #   PRINT_EXPR     
    #   LOAD_CONST
    #   RETURN_VALUE    
    import dis
    if ord(c.co_code[-5]) != dis.opmap["PRINT_EXPR"]:
        return c
    assert ord(c.co_code[-4]) == dis.opmap["LOAD_CONST"]
    assert ord(c.co_code[-1]) == dis.opmap["RETURN_VALUE"]

    code = c.co_code[:-5]
    code += chr(dis.opmap["RETURN_VALUE"])

    CodeArgs = [
        "argcount", "nlocals", "stacksize", "flags", "code",
        "consts", "names", "varnames", "filename", "name",
        "firstlineno", "lnotab", "freevars", "cellvars"]
    c_dict = dict([(arg, getattr(c, "co_" + arg)) for arg in CodeArgs])
    c_dict["code"] = code

    import types
    c = types.CodeType(*[c_dict[arg] for arg in CodeArgs])
    return c


My related StackOverflow question:
http://stackoverflow.com/questions/15059372/python-use-of-eval-in-interactive-terminal-how-to-get-return-value-what-compi

----------
components: Interpreter Core
messages: 182934
nosy: Albert.Zeyer
priority: normal
severity: normal
status: open
title: compile-flag for single-execution to return value instead of printing it
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/issue17294>
_______________________________________

From report at bugs.python.org  Mon Feb 25 17:24:22 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 25 Feb 2013 16:24:22 +0000
Subject: [New-bugs-announce] [issue17295] __slots__ on PyVarObject subclass
Message-ID: <1361809462.28.0.456255129432.issue17295@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

Currently a subclass of a PyVarObject (such as 'int') cannot use a non-empty slots, for example:

>>> class L (int):
...    __slots__ = ('a', 'b')
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: nonempty __slots__ not supported for subtype of 'int'
>>> 

However, subclasses that don't use __slots__ do have an implicit slot: the __dict__ value. Wouldn't it be possible to use the trick used for tp_dictoffset for slots as well, that is use negative values for the slot offsets and access them from the end of the object?

The major problem with an implementation is that PyMember_GetOne has a 'char*' argument instead of a 'PyObject*' one, but that's easily changed (PyMember_GetOne is currently only called in Object/descrobject.c and that call casts PyObject* to char*.  This would be an API change, but AFAIK PyMember_GetOne is not documented at the moment (and changing the argument type would be binary compatible).

I hope to work on a patch in the near future.

----------
components: Interpreter Core
messages: 182959
nosy: ronaldoussoren
priority: low
severity: normal
stage: needs patch
status: open
title: __slots__ on PyVarObject subclass
versions: Python 3.4

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

From report at bugs.python.org  Mon Feb 25 18:00:16 2013
From: report at bugs.python.org (Andreas Hausmann)
Date: Mon, 25 Feb 2013 17:00:16 +0000
Subject: [New-bugs-announce] [issue17296] Cannot unpickle classes derived
	from 'Exception'
Message-ID: <1361811616.55.0.878692548703.issue17296@psf.upfronthosting.co.za>


New submission from Andreas Hausmann:

When pickling/unpickling a class that derives from the builtin class Exception, unpickling results in a

TypeError: ('__init__() takes at least 2 arguments (1 given)', <class '__main__.TestException'>, ())

A standard exception like ValueError can be pickled/unpickled without any problem.

This was observed for versions 2.7.3 and 3.2.3. for both pickle and cPickle.

A script (cpickle) that shows that behavior is included.

This is related (but I do not quite understand how) to the closed Issue1692335.

----------
components: Interpreter Core
files: bug_cpickle.py
messages: 182960
nosy: Andreas.Hausmann, alexandre.vassalotti, belopolsky, benjamin.peterson, bpb, brett.cannon, ehuss, facundobatista, fmitha, georg.brandl, gvanrossum, haypo, jafo, jarpa, jason.coombs, kylev, loewis, lukasz.langa, nnorwitz, pitrou, python-dev, sbt, taleinat, tseaver, zbysz, zseil
priority: normal
severity: normal
status: open
title: Cannot unpickle classes derived from 'Exception'
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file29234/bug_cpickle.py

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

From report at bugs.python.org  Mon Feb 25 19:17:37 2013
From: report at bugs.python.org (=?utf-8?q?Luis_L=C3=B3pez_L=C3=A1zaro?=)
Date: Mon, 25 Feb 2013 18:17:37 +0000
Subject: [New-bugs-announce] [issue17297] Issue with return in recursive
	functions
Message-ID: <1361816257.47.0.388689345116.issue17297@psf.upfronthosting.co.za>


New submission from Luis L?pez L?zaro:

Sorry if I am raising something naive as perhaps I am doing something wrong as I am both an amateur programmer and a newcomer to Python, but version 3.3 appears to have an issue with the return statement in the setting of recursive functions.

When implementing a fruitful recursive function in Python 3.3 (specifically Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:57:17) [MSC v.1600 64 bit (AMD64)] on win32) which depends on conditionals it only returns the result value if the conditions are met in the first iteration.

I am attaching a file in which I have implemented the Euclidean algorithm in 2 slightly different ways. The print statements produce the expected results (for instance with 1000,75) and a print statement placed in the if loop where the return statement is shows the indicator sentence but no value is returned by the function. I have also copied an implementation obtained from a website (function Euclid_LP; obtained from the wiki Literate Programs, http://en.literateprograms.org/Euclidean_algorithm_%28Python%29) and it does not work either.

For the tests, initially I run the program with F5 and invoked the functions from the Python shell. Later I have added a main part of the program prompting for the numbers and calling the functions to later display the results, with no change in the outcome

----------
components: Regular Expressions
files: Chapter 6 MCD Euclidean.py
messages: 182966
nosy: ezio.melotti, luislopezlazaro, mrabarnett
priority: normal
severity: normal
status: open
title: Issue with return in recursive functions
versions: Python 3.3
Added file: http://bugs.python.org/file29236/Chapter 6 MCD Euclidean.py

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

From report at bugs.python.org  Mon Feb 25 23:24:54 2013
From: report at bugs.python.org (Glyph Lefkowitz)
Date: Mon, 25 Feb 2013 22:24:54 +0000
Subject: [New-bugs-announce] [issue17298] Twisted test failure triggered by
	change in 2.7 branch
Message-ID: <1361831094.62.0.865591087681.issue17298@psf.upfronthosting.co.za>


New submission from Glyph Lefkowitz:

As reported in Twisted:

https://twistedmatrix.com/trac/ticket/6314

and as seen on the Twisted buildbot: https://buildbot.twistedmatrix.com/builders/lucid32-py2.7maint/builds/2327/steps/trial/logs/problems

The tip of the 2.7 branch is now failing Twisted's test suite.

The nature of the bug is not immediately obvious, but it looks like certain previously-working pickles are now raising MemoryError when we attempt to load them.

----------
components: Library (Lib)
messages: 182993
nosy: benjamin.peterson, glyph
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Twisted test failure triggered by change in 2.7 branch
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Feb 26 09:39:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Feb 2013 08:39:39 +0000
Subject: [New-bugs-announce] [issue17299] Test cPickle with real files
Message-ID: <1361867979.39.0.619834075084.issue17299@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently cPickle module tested only with cStringIO.StringIO. However cPickle uses different code for cStringIO.StringIO, for file objects, and for general IO streams (i.e. io.BytesIO). Last two cases are not covered by tests.

----------
components: Tests
messages: 183028
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Test cPickle with real files
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Tue Feb 26 11:28:15 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Feb 2013 10:28:15 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue17300=5D_=D0=A1rash_when_de?=
 =?utf-8?q?leting_deeply_recursive_islice=28=29?=
Message-ID: <1361874495.09.0.394992661852.issue17300@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

http://permalink.gmane.org/gmane.comp.python.ideas/19669

>>> from itertools import islice, count
>>> it = count()
>>> for i in range(1000000):
...     it = islice(it, 0)
... 
>>> del it
Segmentation fault

This looks very similar to the crash in tee() (issue13454).

----------
assignee: serhiy.storchaka
components: Extension Modules
messages: 183041
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: ?rash when deleting deeply recursive islice()
type: crash
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Feb 26 21:28:43 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 26 Feb 2013 20:28:43 +0000
Subject: [New-bugs-announce] [issue17301] An in-place version of many
	bytearray methods is needed
Message-ID: <1361910523.06.0.491264384267.issue17301@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

bytearray has many methods that return a *new* bytearray object rather than applying the transformation to modify the bytearray in place.  Given that one use of bytearray's is to avoid making extra copies... There should be in-place variants of the following methods:

ljust
lower
lstrip
rjust
rstrip
strip
swapcase
title
translate
upper

especially so for the methods that don't change the length or move data around such as translate, lower, upper, swapcase and title.

----------
components: Interpreter Core
keywords: easy
messages: 183082
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: An in-place version of many bytearray methods is needed
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb 26 21:54:45 2013
From: report at bugs.python.org (karl)
Date: Tue, 26 Feb 2013 20:54:45 +0000
Subject: [New-bugs-announce] [issue17302] HTTP/2.0 - Implementations/Testing
	efforts
Message-ID: <1361912085.4.0.961439299516.issue17302@psf.upfronthosting.co.za>


New submission from karl:

Are there plans to develop an HTTP/2.0 library in parallel of the specification development? It will not be ready before years, but it would be good to have an evolving implementation. Or should it be done outside of python.org?

Reference: https://github.com/http2

----------
components: Library (Lib)
messages: 183086
nosy: karlcow
priority: normal
severity: normal
status: open
title: HTTP/2.0 - Implementations/Testing efforts
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb 26 22:38:25 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 26 Feb 2013 21:38:25 +0000
Subject: [New-bugs-announce] [issue17303] Fix test discovery for test_future*
Message-ID: <1361914705.71.0.738486694226.issue17303@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Here's the fix for test discovery of test_future* (particularly test_future3).  Without the patch, running 'python -m unittest discover Lib/test/ "test_future*"' results in an error in test_future3.py, due to test_future.py's FutureTest.test_future3 removing test_future3 from sys.modules by way of support.unload.  The patch replaces all instances of support.unload with a support.CleanImport context manager.

The patch also replaces test_main() in all test_future*.py modules, just for good measure.

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

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

From report at bugs.python.org  Tue Feb 26 23:06:54 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 26 Feb 2013 22:06:54 +0000
Subject: [New-bugs-announce] [issue17304] Fix test discovery for test_hash.py
Message-ID: <1361916414.01.0.225881852868.issue17304@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Feb 27 02:32:46 2013
From: report at bugs.python.org (Marten Lehmann)
Date: Wed, 27 Feb 2013 01:32:46 +0000
Subject: [New-bugs-announce] [issue17305] IDNA2008 encoding missing
Message-ID: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za>


New submission from Marten Lehmann:

Since Python 2.3 the idna encoding is available for Internationalized Domain Names. But the current encoding doesn't work according to the latest version of the spec.

There is a new IDNA2008 specification (RFCs 5890-5894). Although I'm not very deep into all the changes, I know that at least the nameprep has changed. For example, the German sharp S ('?') isn't replaced by 'ss' any longer.

The attached file shows the difference between the expected translation and the actual translation.

----------
components: Library (Lib)
files: idna_translate.py
messages: 183104
nosy: marten
priority: normal
severity: normal
status: open
title: IDNA2008 encoding missing
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file29256/idna_translate.py

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

From report at bugs.python.org  Wed Feb 27 03:29:09 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 27 Feb 2013 02:29:09 +0000
Subject: [New-bugs-announce] [issue17306] Improve the way abstract base
	classes are shown in help()
Message-ID: <1361932149.15.0.421194254516.issue17306@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Start by adding docstrings to the colletions ABCs.
Look at improving help() to clearly show the required abstract methods.

----------
assignee: rhettinger
components: Documentation
messages: 183107
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Improve the way abstract base classes are shown in help()
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed Feb 27 09:59:47 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 27 Feb 2013 08:59:47 +0000
Subject: [New-bugs-announce] [issue17307] HTTP PUT request Example
Message-ID: <1361955587.38.0.14131170532.issue17307@psf.upfronthosting.co.za>


New submission from Senthil Kumaran:

I think an explicit HTTP put request example in the docs may help. Previously, I thought the POST example was enough as PUT is very similar, but given the folks are looking for it, an example of how to do a PUT request using httplib may be helpful.

Here is patch attached for review.

----------
assignee: orsenthil
files: http_put_example.patch
keywords: patch
messages: 183124
nosy: ezio.melotti, orsenthil, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: HTTP PUT request Example
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29259/http_put_example.patch

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

From report at bugs.python.org  Wed Feb 27 15:52:04 2013
From: report at bugs.python.org (Harsha)
Date: Wed, 27 Feb 2013 14:52:04 +0000
Subject: [New-bugs-announce] [issue17308] Dialog.py crashes when putty
	Window resized
Message-ID: <1361976724.1.0.943033425333.issue17308@psf.upfronthosting.co.za>


New submission from Harsha:

Dialog.py crashes when putty windows is resized. 

    return simple_menu(d, config, "Select an option:", choices)
  File "/log-root/config-ac", line 499, in simple_menu
    code, tag = d.menu(str(text), height=15, width=45, menu_height=min(8, len(SI
	MPLE_MENU_CHOICES)), choices=SIMPLE_MENU_CHOICES, **kwargs)
  File "/usr/lib/python2.6/site-packages/dialog.py", line 1253, in menu
    (code, output) = self._perform(*(cmd,), **kwargs)
  File "/usr/lib/python2.6/site-packages/dialog.py", line 825, in _perform
    child_rfd)
  File "/usr/lib/python2.6/site-packages/dialog.py", line 762, in _wait_for_prog
  ram_termination  "environment variable)" % exit_code)
dialog.DialogError/usr/lib/python2.6/site-packages/dialog.py:87: DeprecationWarn
ing: BaseException.message has been deprecated as of Python 2.6
  return "<%s: %s>" % (self.__class__.__name__, self.message)
: <DialogError: the dialog-like program exited with code 3 (was passed to it as
the DIALOG_ERROR environment variable)>

----------
components: Windows
messages: 183154
nosy: harshaap
priority: normal
severity: normal
status: open
title: Dialog.py crashes when putty Window resized
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Wed Feb 27 16:41:26 2013
From: report at bugs.python.org (Paul Koning)
Date: Wed, 27 Feb 2013 15:41:26 +0000
Subject: [New-bugs-announce] [issue17309] __bytes__ doesn't work in subclass
	of int
Message-ID: <1361979686.07.0.236846670702.issue17309@psf.upfronthosting.co.za>


New submission from Paul Koning:

The __bytes__ special method has no effect in a subclass of "int" because the bytes() builtin checks for int or int subclass before it gets around to looking for that special method.  The attached example shows it.

----------
components: Interpreter Core
files: bytes.py
messages: 183155
nosy: pkoning
priority: normal
severity: normal
status: open
title: __bytes__ doesn't work in subclass of int
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file29264/bytes.py

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

From report at bugs.python.org  Wed Feb 27 16:51:14 2013
From: report at bugs.python.org (Matt Clarke)
Date: Wed, 27 Feb 2013 15:51:14 +0000
Subject: [New-bugs-announce] [issue17310] Ctypes callbacks shows problem on
	Windows Python (64bit)
Message-ID: <1361980274.18.0.791136497364.issue17310@psf.upfronthosting.co.za>


New submission from Matt Clarke:

I have had an issue arise with ctypes callbacks with 64bit Python on Windows.
Note: everything works fine with 32bit Python on Windows and on 32bit and 64bit Linux.

I have created a simple example to illustrate the issue I have (see attachment), but the real-life issue occurs with using Python to interact with the EPICS control software (http://www.aps.anl.gov/epics/) used at many major scientific institutes.

Basically, if I have a C callback that takes a struct (by value) greater than 8 bytes then the callback returns nonsense. 8 bytes or less works fine.

Stepping through with the Windows debugger, if appears that something goes amiss between the callback being called in C and the closure_fcn(ffi_cif *cif, void *resp, void **args, void *userdata) function in ctypes's callback.c file. Unfortunately, the debugger won't let me step in between those two points.

Looking at the memory I can see the original data in memory at some memory address, X, and a copy of the data at X+40 bytes, but the args in the closure_fcn points at X-40 bytes (which is junk).

Using 32bit Python the data copy is at X-40 bytes and the args pointer in the closure_fcn also points at this.

EPICS has some 64bit C/C++ clients that work fine using callbacks on Windows. Likewise, doing the same sort of thing as ctypes does with EPICS from C# using PInvoke works fine.
 
Any help would be much appreciated.

----------
components: ctypes
files: code.txt
messages: 183156
nosy: Matt.Clarke
priority: normal
severity: normal
status: open
title: Ctypes callbacks shows problem on Windows Python (64bit)
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file29265/code.txt

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

From report at bugs.python.org  Wed Feb 27 19:16:17 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 27 Feb 2013 18:16:17 +0000
Subject: [New-bugs-announce] [issue17311] use distutils terminology in "PyPI
	package display"	section
Message-ID: <1361988977.92.0.980923457558.issue17311@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

As suggested by ?ric in a Rietveld comment to issue 16406, this issue is to make the "PyPI package display" section of the distutils docs use the right terminology:

"It?s too bad this part of the documentation use ?package? with the meaning used on PyPI instead of following the naming conventions used in the rest of the distutils docs (see glossary).  Here I don?t know when ?package? and ?home page? mean pypi.python.org/project or pypi.python.org/project/release (the former being a shortcut to the latest release page)."

----------
assignee: eric.araujo
components: Distutils, Documentation
keywords: easy
messages: 183169
nosy: chris.jerdonek, eric.araujo, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: use distutils terminology in "PyPI package display" section
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Feb 27 20:39:54 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 27 Feb 2013 19:39:54 +0000
Subject: [New-bugs-announce] [issue17312] test_aifc doesn't clean up after
	itself
Message-ID: <1361993994.98.0.627362156743.issue17312@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

test_aifc's AIFCLowLevelTest.test_write_aiff_by_extension() leaves a test file behind.  I'm not sure what other versions are affected.

----------
keywords: easy
messages: 183175
nosy: chris.jerdonek, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: test_aifc doesn't clean up after itself
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Feb 27 20:48:48 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 27 Feb 2013 19:48:48 +0000
Subject: [New-bugs-announce] [issue17313] test_logging doesn't clean up
	after itself
Message-ID: <1361994528.33.0.380746946032.issue17313@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

test_logging leaves behind a file called test.log in the current working directory.  I haven't narrowed down to the specific test, and I'm not sure what other versions are affected.

----------
components: Tests
messages: 183176
nosy: chris.jerdonek, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: test_logging doesn't clean up after itself
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Feb 27 20:56:34 2013
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Feb 2013 19:56:34 +0000
Subject: [New-bugs-announce] [issue17314] Stop using imp.find_module() in
	multiprocessing
Message-ID: <1361994994.99.0.625564916049.issue17314@psf.upfronthosting.co.za>


New submission from Brett Cannon:

I'm trying to remove all uses of imp.find_module()/load_module() and multiprocessing seems to have a single use of both purely for (re)loading a module. The attached patch moves over to importlib.find_loader() and subsequent load_module() call to match the semantics of imp.find_module()/load_module(). If a guaranteed reload is not necessary then importlib.import_module() is a single-line change.

I ran the test suite, but there don't seem to be any explicit tests for this chunk of code (or am I missing something?).

----------
assignee: sbt
components: Library (Lib)
files: remove_imp.find_module.diff
keywords: patch
messages: 183177
nosy: brett.cannon, sbt
priority: normal
severity: normal
stage: patch review
status: open
title: Stop using imp.find_module() in multiprocessing
versions: Python 3.4
Added file: http://bugs.python.org/file29270/remove_imp.find_module.diff

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

From report at bugs.python.org  Wed Feb 27 20:58:41 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 27 Feb 2013 19:58:41 +0000
Subject: [New-bugs-announce] [issue17315] test_posixpath doesn't clean up
	after itself
Message-ID: <1361995121.83.0.653056148204.issue17315@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

test_posixpath leaves behind a file of the following form when running on Mac OS X:

lrwxr-xr-x @test_17700_tmpa -> @test_17700_tmpa/b

I'm not sure which test it is or which other versions are affected.

----------
components: Tests
messages: 183178
nosy: chris.jerdonek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_posixpath doesn't clean up after itself
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Feb 27 21:09:40 2013
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Feb 2013 20:09:40 +0000
Subject: [New-bugs-announce] [issue17316] Add Django 1.5 to benchmarks
Message-ID: <1361995780.43.0.28417987256.issue17316@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Will also need a new Django benchmark target which should get listed in the 2n3 overall target.

----------
assignee: brett.cannon
messages: 183182
nosy: brett.cannon, pitrou
priority: low
severity: normal
status: open
title: Add Django 1.5 to benchmarks

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

From report at bugs.python.org  Wed Feb 27 21:11:39 2013
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Feb 2013 20:11:39 +0000
Subject: [New-bugs-announce] [issue17317] Benchmark driver should calculate
	actual benchmark count	in -h
Message-ID: <1361995899.75.0.774872352722.issue17317@psf.upfronthosting.co.za>


New submission from Brett Cannon:

E.g. when you run ``./perf.py -h`` it lists the py3k benchmark target as having 4 benchmarks, but that's wrong since the 2n3 benchmark alone (which py3k includes) has 23 benchmarks.

----------
keywords: easy
messages: 183183
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Benchmark driver should calculate actual benchmark count in -h

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

From report at bugs.python.org  Thu Feb 28 01:50:37 2013
From: report at bugs.python.org (Raynard Sandwick)
Date: Thu, 28 Feb 2013 00:50:37 +0000
Subject: [New-bugs-announce] [issue17318] xml.sax and xml.dom fetch DTDs by
	default
Message-ID: <1362012637.97.0.538376803739.issue17318@psf.upfronthosting.co.za>


New submission from Raynard Sandwick:

Note that URIs in the following are only meant as links when in parentheses; otherwise, they are identifiers and mostly will not yield useful results. I have only worked with xml.sax in Python 2.6 and 2.7, so I cannot speak to its current state in later versions.

The condition described in Python issue #2124 (http://bugs.python.org/issue2124) may yet be a defect, and is at the least a reasonably important enhancement, but apparently was not sufficiently specified, so I will attempt to clarify. As an aside, it is similar to a libxml2 issue on which I have also commented today (https://bugzilla.gnome.org/show_bug.cgi?id=162776), whose statement of issue actually contains what I would expect to be correct behavior if the toggling action were setting an option/feature rather than importing an additional module.

The most common case, and the reason w3c has been inundated with the described requests, is that every time any user anywhere uses xml.sax in its default form to parse an XHTML document containing a doctype declaration, a request is sent to www.w3.org for the contents of that DTD from the URI in its system identifier. This is not documented anywhere (which would be the primary reason to call this a defect), and is confusing because it has the effect of using the terms parser and validator (or "validating parser," whichever is the preferred name) interchangeably.

The w3c is largely to blame, since their own definition document for XML (http://www.w3.org/TR/REC-xml/#sec-external-ent) defines the DTD as a "special kind of external entity," and then goes on to say that XML processors *MAY* use any combination of pubid+sysid to find an alternative method of resolving the reference, but otherwise *MUST* use the URI.

However, this is only necessary when *validating* XML. The DTD is a "mostly useless, but required" (http://en.wikipedia.org/wiki/Document_Type_Declaration) entity in HTML5, e.g., but is not required in XML generally. Even when present, the only time a processor should consult the DTD is during validation, not parsing. If the default parser revealed by xml.sax is a validator rather than just a parser, that should be communicated clearly to the user. When we discuss a CSV parser, we expect it to accept lines separated by some character, each with columns separated by commas. We do not expect it to verify that certain values are found in certain columns of the first line unless we specify that it should. In specifying that it should, we have asked for a validator rather than a parser. This issue is related to the XML analogue of that distinction.

The most valid and important complaint in the referenced blog post is: "don't fetch stuff unless you actually need it," which is what xml.sax users may be unwittingly doing if validation is the default behavior. Further, if xml.sax were actually *not* conducting validation by default, there is no reason whatever to retrieve the DTD, since any external entity references can remain unresolved in well-formed XML prior to validation.

Note that the features, http://xml.org/sax/features/external-general-entities, .../external-parameter-entities, and .../validation have no specified defaults (http://www.saxproject.org/apidoc/org/xml/sax/package-summary.html#package_description). Making these enabled by default causes network-required side effects, which I would contend is improper: unless a user asks for network activity, none should occur. An implicit request for network activity, such as validation, should be fully and widely-visibly documented as a legitimate side effect.

The set of primary use cases for the xml.sax parsers certainly include validation, but users will often be unaware that it is the default, and more importantly be unaware that the parser will therefore request the DTD from its URI. While the feature, .../external-general-entities, partially solves the problem, it is not a full solution, because a well-formed XML document can contain external entities regardless of the location of DTD subsets. The w3c's description ("special kind of external entity") is important here - the DTD is special for a reason, and has its own tag/specifier as a result: resolving general external entities after intentionally omitting an external DTD subset is an acceptable use case, especially in a non-validating parser.

My proposal would be to enhance/fix xml.sax by doing the following:

1) allow toggling of external DTD subset loading via a feature such as http://apache.org/xml/features/nonvalidating/load-external-dtd (http://xerces.apache.org/xerces-j/features.html),
2) cause the feature, http://xml.org/sax/features/validation, to automatically enable the DTD loading feature as well, just as it does for the two currently implemented external entity features,
3) document the default behavior, specially noting that users can expect URIs to be resolved, across the network/internet if necessary, after either the DTD feature or the validation feature is toggled to the enabled state,

and in my opinion:

4) disable the DTD feature by default, so the xml.sax-uninitiated developer who arrives upon the module as a solution doesn't start testing/using it without realizing these requests will be sent.

Sufficient documentation could override #4, since there is a backward-compatibility issue, but I think the detriment to the w3c is enough reason to rethink it nevertheless. Catalogs are a nice solution as well when validation is needed, but when it is not needed, there is no reason to require the extra work of building a catalog (that can't be guaranteed to be writable in situ without sysadmin access) when it is essentially purposeless.

I am continuing to search for the entry point for "<!" (and would appreciate any pointers) but have resorted to subclassing ExpatParser (which, again, kills the nice abstraction xml.sax touts) and omitting external entites with public identifiers starting with "-//W3C//DTD " - this is not a general solution, as DTDs are not guaranteed to come from w3c, and a correct solution would apply the appropriate omissions to the full "<!DOCTYPE ...>" entity, either by leaving external subsets as unparsed and orphaned entities in the document, or (only as a secondary potential solution since internal subsets could still be present and would thus become broken) by ignoring it completely. It might not even be reasonable to consider the latter, though when parsing only and not validating it would be a correctly-working result, so if the former is unachievable, the latter would be a decent improvement for that situation.

As a final note, in case it's helpful: my approach to a fix has been to examine ways to treat the DOCTYPE declaration itself, but another approach would be to have EntityResolver.resolveEntity receive a declaration type alongside the public and system identifiers, and thus the DOCTYPE declaration type could receive appropriate treatment within the current framework quite easily.

----------
components: XML
messages: 183193
nosy: rsandwick3
priority: normal
severity: normal
status: open
title: xml.sax and xml.dom fetch DTDs by default
type: resource usage
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Thu Feb 28 05:12:05 2013
From: report at bugs.python.org (karl)
Date: Thu, 28 Feb 2013 04:12:05 +0000
Subject: [New-bugs-announce] [issue17319] http.server.BaseHTTPRequestHandler
	send_response_only	doesn't check the type and value of the code.
Message-ID: <1362024725.4.0.923647295599.issue17319@psf.upfronthosting.co.za>


New submission from karl:

def send_response_only(self, code, message=None):
http://hg.python.org/cpython/file/3.3/Lib/http/server.py#l448

There is no type checking on code or if the code is appropriate. Let's take 


==============================================
#!/usr/bin/env python3.3
import http.server


class HTTPHandler(http.server.BaseHTTPRequestHandler):
    "A very simple server"
    def do_GET(self):
        self.send_response(200)
        self.send_header('Content-type', 'text/plain')
        self.end_headers()
        self.wfile.write(bytes('Response body\n\n', 'latin1'))

if __name__ == '__main__':
    addr = ('', 9000)
    http.server.HTTPServer(addr, HTTPHandler).serve_forever()
=====================================================

A request is working well.

=========================================
? http GET localhost:9000
HTTP/1.0 200 OK
Server: BaseHTTP/0.6 Python/3.3.0
Date: Thu, 28 Feb 2013 04:00:44 GMT
Content-type: text/plain

Response body

=========================================

And the server log is 

127.0.0.1 - - [27/Feb/2013 23:00:44] "GET / HTTP/1.1" 200 -

Then let's try


=========================================
#!/usr/bin/env python3.3
import http.server


class HTTPHandler(http.server.BaseHTTPRequestHandler):
    "A very simple server"
    def do_GET(self):
        self.send_response(999)
        self.send_header('Content-type', 'text/plain')
        self.end_headers()
        self.wfile.write(bytes('Response body\n\n', 'latin1'))

if __name__ == '__main__':
    addr = ('', 9000)
    http.server.HTTPServer(addr, HTTPHandler).serve_forever()
=========================================

The response is

=========================================
? http GET localhost:9000
HTTP/1.0 999 
Server: BaseHTTP/0.6 Python/3.3.0
Date: Thu, 28 Feb 2013 03:55:54 GMT
Content-type: text/plain

Response body

=========================================

and the log server is

127.0.0.1 - - [27/Feb/2013 22:55:12] "GET / HTTP/1.1" 999 -

And finally 

=========================================
#!/usr/bin/env python3.3
import http.server


class HTTPHandler(http.server.BaseHTTPRequestHandler):
    "A very simple server"
    def do_GET(self):
        self.send_response('foobar')
        self.send_header('Content-type', 'text/plain')
        self.end_headers()
        self.wfile.write(bytes('Response body\n\n', 'latin1'))

if __name__ == '__main__':
    addr = ('', 9000)
    http.server.HTTPServer(addr, HTTPHandler).serve_forever()
=========================================

The response is then

=========================================
? http GET localhost:9000
HTTPConnectionPool(host='localhost', port=9000): Max retries exceeded with url: /
=========================================

and the server log is 

127.0.0.1 - - [27/Feb/2013 22:56:39] "GET / HTTP/1.1" foobar -
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 53917)
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socketserver.py", line 306, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socketserver.py", line 332, in process_request
    self.finish_request(request, client_address)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socketserver.py", line 345, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socketserver.py", line 666, in __init__
    self.handle()
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/server.py", line 400, in handle
    self.handle_one_request()
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/server.py", line 388, in handle_one_request
    method()
  File "../25/server.py", line 8, in do_GET
    self.send_response('foobar')
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/server.py", line 444, in send_response
    self.send_response_only(code, message)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/server.py", line 459, in send_response_only
    (self.protocol_version, code, message)).encode(
TypeError: %d format: a number is required, not str
----------------------------------------

Both error messages and server logs are not very helpful. 
Shall we fix it? 
What others think?

I guess there should be test cases too?
I'm happy to make unit test cases for it though I might need a bit of guidance as I'm not comfortable with unit test cases mocking connections.

----------
components: Library (Lib)
messages: 183201
nosy: karlcow, orsenthil
priority: normal
severity: normal
status: open
title: http.server.BaseHTTPRequestHandler send_response_only doesn't check the type and value of the code.
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu Feb 28 12:21:01 2013
From: report at bugs.python.org (xiaowei)
Date: Thu, 28 Feb 2013 11:21:01 +0000
Subject: [New-bugs-announce] [issue17320] os.path.abspath in window7,
	return error
Message-ID: <1362050461.97.0.932202728371.issue17320@psf.upfronthosting.co.za>


New submission from xiaowei:

assert os.path.split( os.path.abspath('\xe7\x8e\xb0' ) )[-1] == '\xe7\x8e\xb0'

# it should be true(no error) but py2.7 in window it's false
# and when linux it's ok
# os.path.split( os.path.abspath('\xe7\x8e\xb0' ) )[-1] == '\xe7\x8e'
# i guess it's a real bug , hope some one can resolve it
# i donot try py3.* , i donot know if it exists in 3.*

----------
components: Windows
messages: 183212
nosy: xiaowei.py
priority: normal
severity: normal
status: open
title: os.path.abspath in window7, return error
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb 28 17:53:20 2013
From: report at bugs.python.org (Joe Borg)
Date: Thu, 28 Feb 2013 16:53:20 +0000
Subject: [New-bugs-announce] [issue17321] Better way to pass objects between
	imp.find_module() and	imp.load_module()
Message-ID: <1362070400.21.0.731470144624.issue17321@psf.upfronthosting.co.za>


New submission from Joe Borg:

If I want to use imp to find some load modules, I have to do it in quite an "unpythonic" way:

>>> name = "os"
>>> file, pathname, description = imp.find_module(name)
>>> imp.load_module(name, file, pathname, description)

Can there not be a better way to pass the tuple (or other object) between find_module() and load_module()?

I'm happy to patch this myself and submit, if it's not already been thought about.

----------
messages: 183220
nosy: Joe.Borg
priority: normal
severity: normal
status: open
title: Better way to pass objects between imp.find_module() and imp.load_module()
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb 28 22:27:14 2013
From: report at bugs.python.org (karl)
Date: Thu, 28 Feb 2013 21:27:14 +0000
Subject: [New-bugs-announce] [issue17322] urllib.request add_header()
	currently allows trailing	spaces
Message-ID: <1362086834.26.0.0452612015515.issue17322@psf.upfronthosting.co.za>


New submission from karl:

For HTTP header field names parsing, see http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-22#section-3.2.4

   No whitespace is allowed between the header field-name and colon. In
   the past, differences in the handling of such whitespace have led to
   security vulnerabilities in request routing and response handling.  A
   server MUST reject any received request message that contains
   whitespace between a header field-name and colon with a response code
   of 400 (Bad Request). A proxy MUST remove any such whitespace from a
   response message before forwarding the message downstream.


In python3.3 currently
 
>>> import urllib.request
>>> req = urllib.request.Request('http://www.example.com/')
>>> req.add_header('FoO ', 'Yeah')
>>> req.header_items()
[('Foo ', 'Yeah'), ('User-agent', 'Python-urllib/3.3'), ('Host', 'www.example.com')]

The space has not been removed. So we should fix that at least. This is a bug. I'm not familiar with the specific security issues mentioned in the spec.  

Note that many things can be done too: :/

>>> req.add_header('FoO \n blah', 'Yeah')
>>> req.add_header('Foo:Bar\nFoo2', 'Yeah')
>>> req.header_items()
[('Foo:bar\nfoo2', 'Yeah'), ('Foo \n blah', 'Yeah'), ('Foo ', 'Yeah'), ('User-agent', 'Python-urllib/3.3'), ('Host', 'www.example.com')]


I will check for making a patch tomorrow.

----------
components: Library (Lib)
messages: 183234
nosy: karlcow, orsenthil
priority: normal
severity: normal
status: open
title: urllib.request add_header() currently allows trailing spaces
versions: Python 3.3

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