From report at bugs.python.org  Mon Dec  1 00:27:42 2014
From: report at bugs.python.org (KHH)
Date: Sun, 30 Nov 2014 23:27:42 +0000
Subject: [New-bugs-announce] [issue22969] Compile fails with
	--without-signal-module
Message-ID: <1417390062.47.0.624837709681.issue22969@psf.upfronthosting.co.za>


New submission from KHH:

When compiling with the ./configure --without-signal-module the configure file adds Parser/intrcheck.o to SIGNAL_OBJS, but the corresponding Parser/intercheck.c has been removed from the build tree. 

Removing the Parser/intrcheck.o causes the build to fail due to undefined references.

The error logs are attached.

----------
components: Build
files: python-compile-errors.txt
messages: 231910
nosy: KHH
priority: normal
severity: normal
status: open
title: Compile fails with --without-signal-module
type: compile error
versions: Python 3.4
Added file: http://bugs.python.org/file37329/python-compile-errors.txt

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

From report at bugs.python.org  Mon Dec  1 04:29:42 2014
From: report at bugs.python.org (David Coles)
Date: Mon, 01 Dec 2014 03:29:42 +0000
Subject: [New-bugs-announce] [issue22970] Cancelling wait() after
	notification leaves Condition in	an inconsistent state
Message-ID: <1417404582.01.0.276361050449.issue22970@psf.upfronthosting.co.za>


New submission from David Coles:

If a task that is waiting on an asyncio.Condition is cancelled after notification but before having successfully reacquired the associated lock, the acquire() will be cancelled causing wait() to return without the lock held (violating wait()'s contract and leaving the program in an inconsistent state).

This can be reproduced in cases where there's some contention on the Condition's lock. For example:

    import asyncio

    loop = asyncio.get_event_loop()
    cond = asyncio.Condition()

    @asyncio.coroutine
    def cond_wait_timeout(condition, timeout):
      wait_task = asyncio.async(condition.wait())
      loop.call_later(timeout, wait_task.cancel)
      try:
          yield from wait_task
          return True
      except asyncio.CancelledError:
          print("Timeout (locked: {0})".format(condition.locked()))
          return False

    @asyncio.coroutine
    def waiter():
      yield from cond.acquire()
      try:
          print("Wait")
          if (yield from cond_wait_timeout(cond, 1)):
              # Cause some lock contention
              print("Do work")
              yield from asyncio.sleep(1)
      finally:
          cond.release()

    @asyncio.coroutine
    def notifier():
      # Yield to the waiters
      yield from asyncio.sleep(0.1)

      yield from cond.acquire()
      try:
          print("Notify")
          cond.notify_all()
      finally:
          cond.release()

    loop.run_until_complete(asyncio.wait([waiter(), waiter(), notifier()]))


The most straightforward fix appears to be just to have wait() retry to acquire the lock, effectively ignoring cancellation at this point (since the condition has already finished waiting and just trying to reacquire the lock before returning).

----------
components: asyncio
files: asyncio-fix-wait-cancellation-race.patch
keywords: patch
messages: 231912
nosy: dcoles, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Cancelling wait() after notification leaves Condition in an inconsistent state
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file37330/asyncio-fix-wait-cancellation-race.patch

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

From report at bugs.python.org  Mon Dec  1 11:46:15 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 01 Dec 2014 10:46:15 +0000
Subject: [New-bugs-announce] [issue22971] test_pickle: "Fatal Python error:
	Cannot recover from	stack overflow." on FreeBSD buildbot
Message-ID: <1417430775.66.0.180152689809.issue22971@psf.upfronthosting.co.za>


New submission from STINNER Victor:

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

...
[127/390] test_trace
[128/390] test_imghdr
[129/390] test_queue
[130/390] test_thread
Fatal Python error: Cannot recover from stack overflow.

Current thread 0x0000000801407400 (most recent call first):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__
  ...

[131/390] test_pickle

Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/__main__.py", line 3, in <module>
    regrtest.main_in_temp_cwd()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/regrtest.py", line 1564, in main_in_temp_cwd
    main()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/regrtest.py", line 738, in main
    raise Exception("Child error on {}: {}".format(test, result[1]))
Exception: Child error on test_pickle: Exit code -6
*** [buildbottest] Error code 1

----------
components: Tests
keywords: buildbot
messages: 231925
nosy: haypo
priority: normal
severity: normal
status: open
title: test_pickle: "Fatal Python error: Cannot recover from stack overflow." on FreeBSD buildbot
versions: Python 3.5

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

From report at bugs.python.org  Mon Dec  1 11:54:00 2014
From: report at bugs.python.org (Andrew Burrows)
Date: Mon, 01 Dec 2014 10:54:00 +0000
Subject: [New-bugs-announce] [issue22972] Timeout making ajax calls to
	SimpleHTTPServer from	internet explorer
Message-ID: <1417431240.84.0.697766622208.issue22972@psf.upfronthosting.co.za>


New submission from Andrew Burrows:

I have flask webservice running on windows, run up with `app.run()` which works fine from Chrome but when accessed with IE it sometimes fails with a timeout error. I've managed to reproduce the problem without flask which suggests there is (maybe?) some problem in the underlying Python networking code that flask is using. I've attached a simple website that displays the problem using only SimpleHTTPServer. To reproduce the problem unzip the file, cd into the directory and start the server using:

python -m SimpleHTTPServer 5001

Then visit http://localhost:5001 in Internet Explorer and it will timeout, usually within the first 20 or 30 ajax calls.

I'm using IE11 on windows 7 and python 2.7.8

----------
components: Windows
files: timeout_bug.zip
messages: 231928
nosy: Andrew.Burrows, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Timeout making ajax calls to SimpleHTTPServer from internet explorer
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file37331/timeout_bug.zip

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

From report at bugs.python.org  Mon Dec  1 12:18:28 2014
From: report at bugs.python.org (ardabro)
Date: Mon, 01 Dec 2014 11:18:28 +0000
Subject: [New-bugs-announce] [issue22973] hash() function gives the same
	result for -1 and for -2	argument (==-2)
Message-ID: <1417432708.23.0.68936690634.issue22973@psf.upfronthosting.co.za>


New submission from ardabro:

built-in hash() function cannot be effectively used for integers due to 
weird behavior for -1 argument:

>>> hash(0)
0
>>> hash(-1)
-2                # !!!!!
>>> hash(-2)
-2
>>> hash(-3)
-3
>>>

----------
components: Library (Lib)
messages: 231932
nosy: ardabro
priority: normal
severity: normal
status: open
title: hash() function gives the same result for -1 and for -2 argument (==-2)
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Mon Dec  1 16:59:28 2014
From: report at bugs.python.org (Dmitry Kazakov)
Date: Mon, 01 Dec 2014 15:59:28 +0000
Subject: [New-bugs-announce] [issue22974] Make traceback functions support
	negative limits
Message-ID: <1417449568.58.0.119614287353.issue22974@psf.upfronthosting.co.za>


New submission from Dmitry Kazakov:

This is a complete implementation of negative limits for functions from traceback module (see this proposal - https://mail.python.org/pipermail/python-ideas/2014-August/029105.html). I also added some tests.

----------
components: Library (Lib)
files: traceback_patch_2.diff
keywords: patch
messages: 231943
nosy: vlth
priority: normal
severity: normal
status: open
title: Make traceback functions support negative limits
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file37336/traceback_patch_2.diff

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

From report at bugs.python.org  Mon Dec  1 17:43:35 2014
From: report at bugs.python.org (Elazar Gershuni)
Date: Mon, 01 Dec 2014 16:43:35 +0000
Subject: [New-bugs-announce] [issue22975] Crosses initialization?
Message-ID: <1417452215.15.0.340440438084.issue22975@psf.upfronthosting.co.za>


New submission from Elazar Gershuni:

In Objects/unicodeobject.c, What happens in these lines?

        case PyUnicode_4BYTE_KIND: { \
            Py_UCS4 * to_ = (Py_UCS4 *)((data)) + (start); \
            for (; i_ < (length); ++i_, ++to_) *to_ = (value); \
            break; \
        default: assert(0); \
        } \ // Closing earlier case block. Should be one line up?
        } \ // Closing the switch statement

(I got error here trying to compile Python in g++).

----------
components: Build
hgrepos: 282
messages: 231947
nosy: elazar
priority: normal
severity: normal
status: open
title: Crosses initialization?
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Tue Dec  2 11:09:33 2014
From: report at bugs.python.org (=?utf-8?q?Rados=C5=82aw_Szkodzi=C5=84ski?=)
Date: Tue, 02 Dec 2014 10:09:33 +0000
Subject: [New-bugs-announce] [issue22976] multiprocessing Queue empty() is
	broken on Windows
Message-ID: <1417514973.26.0.394264585481.issue22976@psf.upfronthosting.co.za>


New submission from Rados?aw Szkodzi?ski:

multiprocessing.Queue.empty() uses pipe polling on Windows. Unfortunately, pipe semantics on windows are different from POSIX.

The result is either:
- Hang when one process tries to get() and another checks for empty()
- Falsely returning empty() == False despite nothing being possible to get - because the other process is actually trying to read from the queue.

The attached testcase demonstrates the first case, with main process hard hanging on my Python 2.7.8 (anaconda), 32-bit on Windows 7 64-bit. Whether 1 or 2 happens depends on specific program flow.
Both can cause deadlocks in code that should be valid.

Note that get(block=False) actually works correctly.

It is possible that the problem is also present in Python 3.

----------
components: Library (Lib), Windows
files: testmp.py
messages: 231984
nosy: Rados?aw.Szkodzi?ski, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: multiprocessing Queue empty() is broken on Windows
versions: Python 2.7
Added file: http://bugs.python.org/file37342/testmp.py

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

From report at bugs.python.org  Tue Dec  2 12:19:44 2014
From: report at bugs.python.org (Martin Panter)
Date: Tue, 02 Dec 2014 11:19:44 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue22977=5D_Unformatted_?=
 =?utf-8?q?=E2=80=9CWindows_Error_0x=25X=E2=80=9D_exception_message?=
Message-ID: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za>


New submission from Martin Panter:

The following code generates a connection reset error on Wine (Windows emulator, because I don?t have actual Windows to test on). Probably only a minor issue, but the error message isn?t quite right:

>>> s = create_connection(("localhost", 8181))
>>> # Server end accepts connection and then closes it
>>> s.sendall(b"3" * 3000000)                 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ConnectionResetError: [WinError 10054] Windows Error 0x%X

I?m just guessing, but looking at Python/errors.c, there are two PyUnicode_FromFormat("Windows Error 0x%X", ...) calls. The documentation for that function says only a lower-case %x is supported, so that would explain the behaviour I am seeing.

----------
components: Windows
messages: 231987
nosy: steve.dower, tim.golden, vadmium, zach.ware
priority: normal
severity: normal
status: open
title: Unformatted ?Windows Error 0x%X? exception message
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Dec  2 15:12:04 2014
From: report at bugs.python.org (Maytag Metalark)
Date: Tue, 02 Dec 2014 14:12:04 +0000
Subject: [New-bugs-announce] [issue22978] Logical Negation of NotImplemented
Message-ID: <1417529524.39.0.154038331271.issue22978@psf.upfronthosting.co.za>


New submission from Maytag Metalark:

Performing a logical negation (`not`) on `NotImplemented` should return `NotImplemented`. Currently, it returns `False`.

A common pattern for implementing __eq__ and __ne__ is to implement the comparison in __eq__, and simply delegate to it in __ne__ with a negation. However, if two values are incomparable, then __eq__ and __ne__ should both return NotImplemented. If you try to negate NotImplemented in __ne__, you will end up with a value of False, instead of NotImplemented, so you have to specifically test for this case.

For instance, here is how one would write the code now:

    def __ne__(self, other):
        eq = self.__eq__(other)
        if eq is NotImplemented:
            return NotImplemented
        return not eq

Where as the following would be simpler, and could be used if this change was made:

    def __ne__(self, other):
        return not self.__eq__(other)

This is not simply sugar to reduce typing, it is safer because some coders may forget about NotImplemented and implement __ne__ as shown in the second example anyway, which is not actually correct with the current behavior.

----------
messages: 231996
nosy: Brian.Mearns
priority: normal
severity: normal
status: open
title: Logical Negation of NotImplemented
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Tue Dec  2 15:25:38 2014
From: report at bugs.python.org (Maytag Metalark)
Date: Tue, 02 Dec 2014 14:25:38 +0000
Subject: [New-bugs-announce] [issue22979] Use of None in min and max
Message-ID: <1417530338.57.0.34442889749.issue22979@psf.upfronthosting.co.za>


New submission from Maytag Metalark:

`None` should never be the result of the built-in `min` and `max` functions. When `None` is supplied as one of the values to check, it should never be chosen as the result.

This would make it much easier to find a minimum and/or maximum while iterating over values. For instance, the following is a common pattern:

    mn = None
    mx = None
    for x in iterable:
        if mn is None or x < mn:
            mn = x
        if mx is None or x > mx:
            mx = x

Note that although the `min` and `max` functions could be applied directly to `iterable` in the above case, the above pattern is more efficient (only once through the loop) and covers the common case where additional operations are performed on each value of the iterable.

If the suggested enhancement was made, the above code could be written more simply as:

    mn = None
    mx = None
    for x in iterable:
        mn = min(mn, x)
        mx = max(mx, x)

At present, this will actually work for `max`, as None evaluates as less than every number, but it will not work for `min` (for the same reason).

The suggested change would mean that None is simultaneously greater than and less than every other value, but that only matters if we assume a total ordering of all the values including None, which doesn't seem like it would be important.

----------
messages: 231998
nosy: Brian.Mearns
priority: normal
severity: normal
status: open
title: Use of None in min and max
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Tue Dec  2 15:35:25 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Dec 2014 14:35:25 +0000
Subject: [New-bugs-announce] [issue22980] C extension naming doesn't take
	bitness into account
Message-ID: <1417530925.56.0.55888060474.issue22980@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Currently, C extensions are named something like "_helperlib.cpython-34dm.so". This doesn't take into account the bitness of the interpreter (32- vs. 64-bit), which makes it awkward to use the same working copy with two different interpreters (you have to rebuild everything each time you switch bitnesses).

Worse, under Windows it seems ABI tags aren't even used, giving generic names such as "_helperlib.pyd". Why is that?

----------
messages: 232000
nosy: barry, brett.cannon, eric.snow, ncoghlan, pitrou, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: C extension naming doesn't take bitness into account
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Dec  2 17:20:30 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Dec 2014 16:20:30 +0000
Subject: [New-bugs-announce] [issue22981] Use CFLAGS when extracting
	multiarch
Message-ID: <1417537230.69.0.64347205768.issue22981@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

This patch fixes MULTIARCH computation when using CFLAGS=-m32:

diff --git a/configure b/configure
--- a/configure
+++ b/configure
@@ -5402,7 +5402,7 @@ hp*|HP*)
     esac;;
 esac
 
-MULTIARCH=$($CC --print-multiarch 2>/dev/null)
+MULTIARCH=$($CC $CFLAGS --print-multiarch 2>/dev/null)
 
 
 
diff --git a/configure.ac b/configure.ac
--- a/configure.ac
+++ b/configure.ac
@@ -788,7 +788,7 @@ hp*|HP*)
     esac;;
 esac
 
-MULTIARCH=$($CC --print-multiarch 2>/dev/null)
+MULTIARCH=$($CC $CFLAGS --print-multiarch 2>/dev/null)
 AC_SUBST(MULTIARCH)

----------
messages: 232013
nosy: barry, doko, pitrou
priority: normal
severity: normal
status: open
title: Use CFLAGS when extracting multiarch
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Dec  2 17:41:42 2014
From: report at bugs.python.org (MarkIngramUK)
Date: Tue, 02 Dec 2014 16:41:42 +0000
Subject: [New-bugs-announce] [issue22982] BOM incorrectly inserted before
	writing, after seeking in text file
Message-ID: <1417538502.93.0.814458445398.issue22982@psf.upfronthosting.co.za>


New submission from MarkIngramUK:

If you open a text file for append, but then perform any form of seeking, before attempting to write to the file, it will cause the BOM to be written before you text. See the attached file for an example.

If you run the test, take a look at the output file, and you'll notice the UTF16 BOM gets written out before each number.

I'm running a 2014 iMac with Yosemite.

----------
components: IO
files: append-test.py
messages: 232015
nosy: MarkIngramUK
priority: normal
severity: normal
status: open
title: BOM incorrectly inserted before writing, after seeking in text file
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file37345/append-test.py

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

From report at bugs.python.org  Tue Dec  2 17:59:37 2014
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 02 Dec 2014 16:59:37 +0000
Subject: [New-bugs-announce] [issue22983] Cookie parsing should be more
	permissive
Message-ID: <1417539577.52.0.585535774996.issue22983@psf.upfronthosting.co.za>


New submission from Demian Brecht:

As found in #22931, if an invalid cookie value is found while parsing, the rest of the cookie is silently ignored. The expected behavior is undefined in RFC 6265, but does state that if unexpected values are encountered that user agents MAY ignore an entire set-cookie string (not just a subsection of it). Given that, invalid cookie portions should likely be handled by either:

1. Ignore the cookie string in its entirety and log an error message, or
2. Ignore invalid cookie-pairs but still parse the rest of the string

The latter would likely be the best path (Postel's law and all)

----------
components: Library (Lib)
messages: 232020
nosy: demian.brecht
priority: normal
severity: normal
status: open
title: Cookie parsing should be more permissive
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Dec  2 22:15:19 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 02 Dec 2014 21:15:19 +0000
Subject: [New-bugs-announce] [issue22984]
	test_json.test_endless_recursion(): "Fatal Python
	error:	Cannot recover from stack overflow." on x86 XP-4 3.x buildbot
Message-ID: <1417554919.08.0.0786746086364.issue22984@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/x86%20XP-4%203.x/builds/11271/steps/test/logs/stdio

[116/390] test_json
Fatal Python error: Cannot recover from stack overflow.

Current thread 0x00000e84 (most recent call first):
  File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\json\encoder.py", line 250 in iterencode
  File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\json\encoder.py", line 192 in encode
  File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_json\test_recursion.py", line 96 in test_endless_recursion
  File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\case.py", line 577 in run
  File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\case.py", line 625 in __call__
  File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 125 in run
  File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 87 in __call__
  File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 125 in run
  File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 87 in __call__
  File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 125 in run
  File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 87 in __call__
  File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 125 in run
  File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 87 in __call__
  File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 125 in run
  File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 87 in __call__
  File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\runner.py", line 168 in run
  File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\support\__init__.py", line 1769 in _run_suite
  File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\support\__init__.py", line 1803 in run_unittest
  File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\..\lib\test\regrtest.py", line 1279 in test_runner
  File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\..\lib\test\regrtest.py", line 1280 in runtest_inner
  File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\..\lib\test\regrtest.py", line 967 in runtest
  File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\..\lib\test\regrtest.py", line 763 in main
  File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\..\lib\test\regrtest.py", line 1564 in main_in_temp_cwd
  File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\..\lib\test\regrtest.py", line 1589 in <module>

----------
components: Tests
keywords: buildbot
messages: 232049
nosy: haypo
priority: normal
severity: normal
status: open
title: test_json.test_endless_recursion(): "Fatal Python error: Cannot recover from stack overflow." on x86 XP-4 3.x buildbot
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Wed Dec  3 00:16:34 2014
From: report at bugs.python.org (Omer Katz)
Date: Tue, 02 Dec 2014 23:16:34 +0000
Subject: [New-bugs-announce] [issue22985] Segfault on time.sleep
Message-ID: <1417562194.55.0.557233180564.issue22985@psf.upfronthosting.co.za>


New submission from Omer Katz:

I have found what appears to be a segfualt in time.sleep but I'm not sure.
I have verified that the segfualt occurs both on Python 2.7.8 and 3.4.2.

The following program that reproduces the segfault uses my fork of billiard, a replacement for the multiprocessing module that is used by celery.

In order to install: pip install git+https://github.com/thedrow/billiard at topic/dill-with-threads

The program:
from billiard.pool import ThreadPool

p1 = ThreadPool()

class Foo(object):
    def a(self):
        print("a")
        return 1

    def do(self):
        return p1.apply_async(self.a)


foo = Foo()
r = foo.do()

print(r.get())
p1.close()
p1.join()

The output from gdb:
gdb -ex r -q --args python mt_example.py
Reading symbols from python...done.
Starting program: /home/omer/.virtualenvs/billiard/bin/python mt_example.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff31db700 (LWP 2897)]
[New Thread 0x7ffff29da700 (LWP 2898)]
[New Thread 0x7ffff21d9700 (LWP 2899)]
[New Thread 0x7ffff19d8700 (LWP 2900)]
[New Thread 0x7ffff11d7700 (LWP 2901)]
[New Thread 0x7ffff09d6700 (LWP 2902)]
[New Thread 0x7fffdbfff700 (LWP 2903)]

Program received signal SIGTERM, Terminated.
[Switching to Thread 0x7ffff21d9700 (LWP 2899)]
0x00007ffff71dc1c3 in select () at ../sysdeps/unix/syscall-template.S:81
81	../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0  0x00007ffff71dc1c3 in select () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007ffff5fd5d5d in floatsleep (secs=<optimized out>) at Modules/timemodule.c:948
#2  time_sleep (self=<optimized out>, args=<optimized out>) at Modules/timemodule.c:206
#3  0x00000000004b658c in call_function (oparg=<optimized out>, pp_stack=0x7ffff21d8540) at Python/ceval.c:4033
#4  PyEval_EvalFrameEx (f=f at entry=0x7ffff463eda8, throwflag=throwflag at entry=0) at Python/ceval.c:2679
#5  0x00000000004b6f6b in PyEval_EvalCodeEx (co=<optimized out>, globals=<optimized out>, locals=locals at entry=0x0, args=<optimized out>, 
    argcount=argcount at entry=4, kws=<optimized out>, kwcount=0, defs=0x7ffff40bab68, defcount=1, closure=0x0) at Python/ceval.c:3265
#6  0x00000000004b5b28 in fast_function (nk=<optimized out>, na=4, n=<optimized out>, pp_stack=0x7ffff21d8730, func=0x7ffff31e2938)
    at Python/ceval.c:4129
#7  call_function (oparg=<optimized out>, pp_stack=0x7ffff21d8730) at Python/ceval.c:4054
#8  PyEval_EvalFrameEx (f=f at entry=0x7fffe8000b50, throwflag=throwflag at entry=0) at Python/ceval.c:2679
#9  0x00000000004b6f6b in PyEval_EvalCodeEx (co=<optimized out>, globals=<optimized out>, locals=locals at entry=0x0, args=<optimized out>, 
    argcount=argcount at entry=1, kws=<optimized out>, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3265
#10 0x00000000004b5b28 in fast_function (nk=<optimized out>, na=1, n=<optimized out>, pp_stack=0x7ffff21d8920, func=0x7ffff31e28c0)
    at Python/ceval.c:4129
#11 call_function (oparg=<optimized out>, pp_stack=0x7ffff21d8920) at Python/ceval.c:4054
#12 PyEval_EvalFrameEx (f=f at entry=0x7fffe8000910, throwflag=throwflag at entry=0) at Python/ceval.c:2679
#13 0x00000000004b5bc7 in fast_function (nk=<optimized out>, na=1, n=<optimized out>, pp_stack=0x7ffff21d8a70, func=0x7ffff7e55230)
---Type <return> to continue, or q <return> to quit---
    at Python/ceval.c:4119
#14 call_function (oparg=<optimized out>, pp_stack=0x7ffff21d8a70) at Python/ceval.c:4054
#15 PyEval_EvalFrameEx (f=f at entry=0x7ffff31f1210, throwflag=throwflag at entry=0) at Python/ceval.c:2679
#16 0x00000000004b6f6b in PyEval_EvalCodeEx (co=<optimized out>, globals=<optimized out>, locals=locals at entry=0x0, 
    args=args at entry=0x7ffff31dca68, argcount=<optimized out>, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, 
    defcount=defcount at entry=0, closure=0x0) at Python/ceval.c:3265
#17 0x0000000000529e70 in function_call (func=0x7ffff7e55140, arg=0x7ffff31dca50, kw=0x0) at Objects/funcobject.c:526
#18 0x0000000000422f5a in PyObject_Call (func=func at entry=0x7ffff7e55140, arg=arg at entry=0x7ffff31dca50, kw=kw at entry=0x0)
    at Objects/abstract.c:2529
#19 0x000000000042747d in instancemethod_call (func=0x7ffff7e55140, arg=0x7ffff31dca50, kw=0x0) at Objects/classobject.c:2602
#20 0x0000000000422f5a in PyObject_Call (func=func at entry=0x7ffff4636d70, arg=arg at entry=0x7ffff7f93050, kw=<optimized out>)
    at Objects/abstract.c:2529
#21 0x00000000004b07f7 in PyEval_CallObjectWithKeywords (func=0x7ffff4636d70, arg=0x7ffff7f93050, kw=<optimized out>) at Python/ceval.c:3902
#22 0x00000000004fae92 in t_bootstrap (boot_raw=0x8899c0) at ./Modules/threadmodule.c:614
#23 0x00007ffff7bc40a5 in start_thread (arg=0x7ffff21d9700) at pthread_create.c:309
#24 0x00007ffff71e484d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

----------
components: Interpreter Core
messages: 232059
nosy: Omer.Katz
priority: normal
severity: normal
status: open
title: Segfault on time.sleep
type: crash
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Wed Dec  3 00:39:21 2014
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 02 Dec 2014 23:39:21 +0000
Subject: [New-bugs-announce] [issue22986] Improved handling of __class__
	assignment
Message-ID: <1417563561.24.0.575634102448.issue22986@psf.upfronthosting.co.za>


New submission from Nathaniel Smith:

Following on from the discussion starting here:

http://thread.gmane.org/gmane.comp.python.devel/150438/focus=150604

Here's a patch to improve __class__ assignment.

1) We remove the HEAPTYPE check from object_set_class, and move it to same_slots_added. This fixes an outright bug: previously it was possible for non-HEAPTYPE types to get passed into same_slots_added (either b/c the loop in compatible_for_assignment ended up with non-HEAPTYPE types, or via __bases__ assignment), and it would then wander off following pointers through random memory.

2) Now that object_set_class can potentially accept non-HEAPTYPE types, adjust the reference counting appropriately.

3) To clarify the logic of compatible_for_assignment, rename equiv_structs to compatible_with_tp_base, tweak accordingly, and add a nice comment explaining the logic. (compatible_for_assignment is equiv_structs's only caller so this is totally safe.)

4) Now that equiv_structs/compatible_with_tp_base has a clearer purpose, also move the tp_dealloc check from compatible_for_assignment into compatible_with_tp_base. In the process, add special-case handling for subclass_dealloc, b/c subclass_dealloc delegates to the parent class tp_dealloc anyway.

These changes together make it possible to assign to module instances's __class__ slot, which is useful for reasons described in the above thread. So I added a test for this to check the new code.

----------
components: Interpreter Core
files: better-__class__-assignment-v1.patch
keywords: patch
messages: 232061
nosy: njs
priority: normal
severity: normal
status: open
title: Improved handling of __class__ assignment
Added file: http://bugs.python.org/file37346/better-__class__-assignment-v1.patch

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

From report at bugs.python.org  Wed Dec  3 14:15:58 2014
From: report at bugs.python.org (Kali Kaneko)
Date: Wed, 03 Dec 2014 13:15:58 +0000
Subject: [New-bugs-announce] [issue22987] ssl module documentation:
	incorrect compatibility matrix
Message-ID: <1417612558.33.0.597958584531.issue22987@psf.upfronthosting.co.za>


New submission from Kali Kaneko:

The SSLv23 row that can be read in the socket creation section in the documentation for the ssl module looks incorrect:
https://docs.python.org/2.7/library/ssl.html#socket-creation

by my tests (with python 2.7.8) that row should read:

yes no yes yes yes yes

instead of:

yes no yes no no no 

as it does now.

Since a client specifying SSLv23 should be (and it seems to be) able to negotiate the highest available version that the server can offer, no matter if the server has chosen a tls version.

Is this an error in the documentation, or is there any situation in which the current values hold true?

----------
assignee: docs at python
components: Documentation
messages: 232078
nosy: docs at python, kali
priority: normal
severity: normal
status: open
title: ssl module documentation: incorrect compatibility matrix
versions: Python 2.7

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

From report at bugs.python.org  Wed Dec  3 18:51:14 2014
From: report at bugs.python.org (Felipe)
Date: Wed, 03 Dec 2014 17:51:14 +0000
Subject: [New-bugs-announce] [issue22988] No error when yielding from
	`finally`
Message-ID: <1417629074.29.0.62488033247.issue22988@psf.upfronthosting.co.za>


New submission from Felipe:

This bug report is the opposite of issue #14718. The interpreter did not raise an error when it encountered a `yield` expression inside the `finally` part of a `try/finally` statement.

My system's info: Python 3.4.2 (v3.4.2:ab2c023a9432, Oct  6 2014, 22:15:05) [MSC v.1600 32 bit (Intel)] on win32



More detail
=======================================================

My interpreter does not raise any errors when yielding from a `finally` block. The documentation states, "Yield expressions are allowed in the try clause of a try ... finally construct."[1] Though not explicitly stated, the suggestion is that `yield` is not allowed in the `finally` clause. Issue #14718 suggests that this interpretation is correct.

Not raising an exception for `yield` inside of `finally` can cause incorrect behavior when the generator raises its own unhandled exception in the `try` block. PEP 342 says, "If the generator raises an uncaught exception, it is propagated to send()'s caller." In this case, however, the exception gets paused at the `yield` expression, instead of propagating to the caller. 

Here's an example that can clarify the issue:

>>> def f():  # I expected this function not to compile
...     try:
...         raise ValueError
...     finally:
...         yield 1  # Execution freezes here instead of propagating the ValueError
...     yield "done"
... 
>>> g = f()
>>> g.send(None)  # PEP 342 would require ValueError to be raised here
1
>>> g.send(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in f2
ValueError

I may be arguing over the meaning of "uncaught exception," but I expected (given that the function compiles and doesn't raise a `RuntimeError`) the `ValueError` to propagate rather than get frozen.



Example 2
-------------------------------------------------------

The second example is adapted from http://bugs.python.org/issue14718, where the submitter received a `RuntimeError`, but I did not:

>>> def f2():  # I also expected this function not to compile
...   try:
...     yield 1
...   finally:
...     yield 4
... 
>>> g = f()  # issue 14718 suggests this should raise RuntimeError
>>> next(g)
1
>>> next(g)
4
>>> next(g)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
StopIteration




Possible resolution:
=========================================================

1. Enforce the ban on `yield` inside a finally `clause`. It seems like this should 
   already be happening, so I'm not sure why my version isn't performing the check.
   This could be a run-time check (which seems like it may already be implemented),
   but I think this could even be a compile-time check (by looking at the AST).
2. Clarify the documentation to make explicit the ban on the use of `yield` inside
   the `finally` clause, and specify what type of error it will raise (i.e., 
   `SyntaxError` or `RuntimeError`? or something else?).

I'll submit a patch for 2 if there's support for this change, and I will work on 1 if someone can point me in the right direction. I've engaged with the C source relating to the different protocols, but have never looked through the compiler/VM.




Notes
============================================
[1] https://docs.python.org/3.4/reference/expressions.html#yield-expressions

----------
components: Interpreter Core
messages: 232081
nosy: fov
priority: normal
severity: normal
status: open
title: No error when yielding from `finally`
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Dec  3 19:45:17 2014
From: report at bugs.python.org (Paul Hartmann)
Date: Wed, 03 Dec 2014 18:45:17 +0000
Subject: [New-bugs-announce] [issue22989] HTTPResponse.msg not as documented
Message-ID: <1417632317.82.0.906874710781.issue22989@psf.upfronthosting.co.za>


New submission from Paul Hartmann:

HTTPResponse.msg is documented as a http.client.HTTPMessage object containing the headers of the response [1].

But in fact this is a string containing the status code:

>>> import urllib.request
>>> req=urllib.request.urlopen('http://heise.de')
>>> content = req.read()
>>> type(req.msg)
<class 'str'>
>>> req.msg
'OK'

This value is apparently overriden in urllib/request.py:

./urllib/request.py:1246:        # This line replaces the .msg attribute of the HTTPResponse
./urllib/request.py-1247-        # with .headers, because urllib clients expect the response to
./urllib/request.py:1248:        # have the reason in .msg.  It would be good to mark this
./urllib/request.py-1249-        # attribute is deprecated and get then to use info() or
./urllib/request.py-1250-        # .headers.
./urllib/request.py:1251:        r.msg = r.reason

Anyhow, it should be documented, that is not safe to retrieve the headers with HTTPResponse.msg and maybe add HTTPResponse.headers to the documentation.

[1] https://docs.python.org/3/library/http.client.html

----------
assignee: docs at python
components: Documentation
messages: 232083
nosy: bastik, docs at python
priority: normal
severity: normal
status: open
title: HTTPResponse.msg not as documented
versions: Python 3.4

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

From report at bugs.python.org  Wed Dec  3 23:46:35 2014
From: report at bugs.python.org (Alan)
Date: Wed, 03 Dec 2014 22:46:35 +0000
Subject: [New-bugs-announce] [issue22990] bdist installation dialog
Message-ID: <1417646795.33.0.270415129525.issue22990@psf.upfronthosting.co.za>


New submission from Alan:

The "Select Python Installations" dialog box contains the line "Select the Python locations where <distribution_name> should be installed." If <distribution_name> is anything other than a very short string, the line is truncated, due to the following factors:
- the line doesn't wrap
- the dialog box can't be resized
- the message (aside from the distribution name) is fairly lengthy

See the screenshot, where I created a distribution of a package whose name is "not_such_a_long_name".

At the same time as the line is made wrappable and/or the dialog box is made resizable, it would be nice to improve the wording of the message. It took me a while to figure out what was going on because the GUI elements have different meanings from the ones seen more commonly. Usually these elements (the menu with choices beginning with "Will be installed on local hard drive" and ending with "Entire feature will be unavailable") are used to choose one or more features of an application to install, not one or more places to install the same application. Maybe something like this would work:

Select Where to Install

Select Python locations in which to install <distribution_name>:

Python 2.7 (found in the registry)
Python 3.3 (found in the registry)
Python (other location)

instead of the current:

Select Python Installations

Select the Python locations where <distribution_name> should be installed:

Python 2.7 from registry
Python 3.3 from registry
Python from another location

----------
components: Distutils
files: bdist_screenshot.PNG
messages: 232094
nosy: Alan, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: bdist installation dialog
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file37353/bdist_screenshot.PNG

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

From report at bugs.python.org  Thu Dec  4 00:50:33 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 03 Dec 2014 23:50:33 +0000
Subject: [New-bugs-announce] [issue22991] test_gdb leaves the terminal in
	raw mode with gdb 7.8.1
Message-ID: <1417650633.0.0.0644519046784.issue22991@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

This happens on archlinux. Annoying: the terminal becomes unusable unless you type blindly 'stty sane <CTL-J>', and the backspace key is still wrong.
This does not happen with gdb 7.6.1.
And this does not happen when running gdb with the 'mi' interpreter. The attached patch uses GDB/MI.
The problem with using the GDB/MI interface, is that it is very verbose when trying to debug a test.

----------
components: Tests
files: gdbmi.patch
keywords: patch
messages: 232099
nosy: xdegaye
priority: normal
severity: normal
status: open
title: test_gdb leaves the terminal in raw mode with gdb 7.8.1
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file37354/gdbmi.patch

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

From report at bugs.python.org  Thu Dec  4 01:09:13 2014
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 04 Dec 2014 00:09:13 +0000
Subject: [New-bugs-announce] [issue22992] Adding a git developer's guide to
	Mercurial to devguide
Message-ID: <1417651753.19.0.905189748743.issue22992@psf.upfronthosting.co.za>


New submission from Demian Brecht:

Coming out of a recent thread in python-dev, it was mentioned that adding a git developer's guide to mercurial may be beneficial to help lower the initial barrier of entry for prospective contributors (https://mail.python.org/pipermail/python-dev/2014-November/137280.html). The attached patch is a slightly reworded version of my blog post here: http://demianbrecht.github.io/vcs/2014/07/31/from-git-to-hg/.

----------
components: Devguide
files: gitdevs.patch
keywords: patch
messages: 232100
nosy: demian.brecht, ezio.melotti
priority: normal
severity: normal
status: open
title: Adding a git developer's guide to Mercurial to devguide
Added file: http://bugs.python.org/file37355/gitdevs.patch

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

From report at bugs.python.org  Thu Dec  4 07:34:34 2014
From: report at bugs.python.org (Connor Wolf)
Date: Thu, 04 Dec 2014 06:34:34 +0000
Subject: [New-bugs-announce] [issue22993] Plistlib fails on certain valid
	plist values
Message-ID: <1417674874.83.0.611673896272.issue22993@psf.upfronthosting.co.za>


New submission from Connor Wolf:

I'm using plistlib to process plist files produced by an iphone app. Somehow, the application is generating plist files with a absolute date value along the lines of `0000-12-30T00:00:00Z`.

This is a valid date, and the apple plist libraries can handle this without issue. However, it causes a ValueError if you load a plist containing it.

Minimal example:

python file:  
```
import plistlib
test = plistlib.readPlist('./test.plist')
```

plist file:  
```
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Test</key>
	<date>0000-12-30T00:00:00Z</date>
</dict>
</plist>
```

This fails on both python3 and python2, with the exact same error:


```
herp at mainnas:/media/Storage/Scripts/pFail$ python3 test.py
Traceback (most recent call last):
  File "test.py", line 3, in <module>
    test = plistlib.readPlist('./test.plist')
  File "/usr/lib/python3.4/plistlib.py", line 164, in readPlist
    dict_type=_InternalDict)
  File "/usr/lib/python3.4/plistlib.py", line 995, in load
    return p.parse(fp)
  File "/usr/lib/python3.4/plistlib.py", line 325, in parse
    self.parser.ParseFile(fileobj)
  File "/usr/lib/python3.4/plistlib.py", line 337, in handle_end_element
    handler()
  File "/usr/lib/python3.4/plistlib.py", line 413, in end_date
    self.add_object(_date_from_string(self.get_data()))
  File "/usr/lib/python3.4/plistlib.py", line 291, in _date_from_string
    return datetime.datetime(*lst)
ValueError: year is out of range
herp at mainnas:/media/Storage/Scripts/pFail$ python test.py
Traceback (most recent call last):
  File "test.py", line 3, in <module>
    test = plistlib.readPlist('./test.plist')
  File "/usr/lib/python2.7/plistlib.py", line 78, in readPlist
    rootObject = p.parse(pathOrFile)
  File "/usr/lib/python2.7/plistlib.py", line 406, in parse
    parser.ParseFile(fileobj)
  File "/usr/lib/python2.7/plistlib.py", line 418, in handleEndElement
    handler()
  File "/usr/lib/python2.7/plistlib.py", line 474, in end_date
    self.addObject(_dateFromString(self.getData()))
  File "/usr/lib/python2.7/plistlib.py", line 198, in _dateFromString
    return datetime.datetime(*lst)
ValueError: year is out of range
herp at mainnas:/media/Storage/Scripts/pFail$

```

----------
components: Library (Lib)
messages: 232107
nosy: Connor.Wolf
priority: normal
severity: normal
status: open
title: Plistlib fails on certain valid plist values
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Thu Dec  4 11:30:01 2014
From: report at bugs.python.org (santhosh)
Date: Thu, 04 Dec 2014 10:30:01 +0000
Subject: [New-bugs-announce] [issue22994] datetime buggy
Message-ID: <1417689001.58.0.198336603717.issue22994@psf.upfronthosting.co.za>


New submission from santhosh:

val=datetime.datetime.strptime("2015-02-01",'%Y-%m-%d').date()
zon=pytz.timezone('US/Pacific')
dt=datetime.datetime(val.year,val.month,val.day, tzinfo=zon)
print dt,zon


output:
2015-02-01 00:00:00-07:53 US/Pacific

output should be
2015-02-01 00:00:00-08:00 US/Pacific

----------
messages: 232119
nosy: santhoshch
priority: normal
severity: normal
status: open
title: datetime buggy
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Dec  4 14:16:43 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 04 Dec 2014 13:16:43 +0000
Subject: [New-bugs-announce] [issue22995] Restrict default picleability
Message-ID: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

When no efforts were spent to support pickling of instances of Python class, in most cases the class will be pickleable. Default implementation just saves all attributes and this works if all attributes are pickleable. Exceptional special cases:

1) Classes with __slot__. In this case an attempt to pickle will raise an exception with explaining message.

2) Classes with __new__ wish mandatory parameters. In this case the pickling will be silently "successful", but actually data will be not saved and unpickling will fail. See for example issue21975, issue22955.

But when the class is implemented in C and doesn't expose its attribute in __dict__, in most cases it is variant (2) -- silent incorrect pickling.

I think we should prevent incorrect pickling by default. It is better to fail loudly. Default reduce could inspect the __new__ method and raise an exception if it has non-optional parameters and the class doesn't implement __getnewargs_ex__ or __getnewargs__ methods. And fail on all classes implemented in C if they don't implement any pickle-related methods.

----------
messages: 232135
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Restrict default picleability

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

From report at bugs.python.org  Thu Dec  4 14:50:26 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Dec 2014 13:50:26 +0000
Subject: [New-bugs-announce] [issue22996] Order of _io objects finalization
	can lose data in	reference cycles
Message-ID: <1417701026.92.0.498236598098.issue22996@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Spun off from issue #17852, which sticks to interpreter shutdown issue. There is a more general issue when e.g. a BufferedWriter can be finalized (tp_finalize) before the TextIOWrapper wrapping it if they belong to a reference chain, losing unflushed data.

Reproducer attached.

----------
components: IO
files: gcio.py
messages: 232138
nosy: pitrou
priority: normal
severity: normal
status: open
title: Order of _io objects finalization can lose data in reference cycles
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37358/gcio.py

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

From report at bugs.python.org  Thu Dec  4 18:10:19 2014
From: report at bugs.python.org (Simeon Visser)
Date: Thu, 04 Dec 2014 17:10:19 +0000
Subject: [New-bugs-announce] [issue22997] Minor improvements to "Functional
	API" section of Enum	documentation
Message-ID: <1417713019.92.0.36560038902.issue22997@psf.upfronthosting.co.za>


New submission from Simeon Visser:

This patch contributes two changes to the "Functional API" section of the Enum documentation:

- Early in the section it mentions four different ways of creating an Enum but later it only lists three different ways (the "sequence of names" approach wasn't listed anymore).

- The use of "Animal" and "Animals" wasn't consistent.

This issue is mainly to test my ability to make a (trivial) patch.

----------
assignee: docs at python
components: Documentation
messages: 232142
nosy: docs at python, simeon.visser
priority: normal
severity: normal
status: open
title: Minor improvements to "Functional API" section of Enum documentation
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu Dec  4 21:14:01 2014
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Thu, 04 Dec 2014 20:14:01 +0000
Subject: [New-bugs-announce] [issue22998] inspect.Signature and default
	arguments
Message-ID: <1417724041.66.0.201313804397.issue22998@psf.upfronthosting.co.za>


New submission from Walter D?rwald:

inspect.Signature.bind() doesn't add values for parameters that are unspecified but have a default value. The documentation at https://docs.python.org/3/library/inspect.html#inspect.BoundArguments.arguments includes an example how to add default values, but that example doesn't work for the * and ** parameters.

This patch adds a new method Signature.bind_with_defaults() that works like Signature.bind(), but includes parameters with a default value (and can handle values for the * and ** parameters).

----------
components: Library (Lib)
files: signature-bind.diff
keywords: patch
messages: 232150
nosy: doerwalter
priority: normal
severity: normal
status: open
title: inspect.Signature and default arguments
type: enhancement
Added file: http://bugs.python.org/file37362/signature-bind.diff

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

From report at bugs.python.org  Fri Dec  5 10:58:05 2014
From: report at bugs.python.org (Cees Timmerman)
Date: Fri, 05 Dec 2014 09:58:05 +0000
Subject: [New-bugs-announce] [issue22999] Copying emoji to Windows clipboard
	corrupts string in	Python 3.3 and up
Message-ID: <1417773485.83.0.226794721808.issue22999@psf.upfronthosting.co.za>


New submission from Cees Timmerman:

# http://stackoverflow.com/a/25678113/819417
def copy(data):
    if not isinstance(data, unicode):
        data = data.decode('mbcs')
    OpenClipboard(None)
    EmptyClipboard()
    hCd = GlobalAlloc(GMEM_DDESHARE, 2 * (len(data) + 1))
    pchData = GlobalLock(hCd)
    wcscpy(ctypes.c_wchar_p(pchData), data)
    GlobalUnlock(hCd)
    SetClipboardData(CF_UNICODETEXT, hCd)
    CloseClipboard()

Emoji "?" (\U0001f400) is copied as "?" (\U0001f4cb), or "?." turns to "?" (note the period).

It works fine in Python 3.2.5.

----------
components: Unicode
messages: 232188
nosy: Cees.Timmerman, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: Copying emoji to Windows clipboard corrupts string in Python 3.3 and up
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Dec  6 13:24:02 2014
From: report at bugs.python.org (StoreIntegrator)
Date: Sat, 06 Dec 2014 12:24:02 +0000
Subject: [New-bugs-announce] [issue23000] More support for Visual Studio
	users on Windows?
Message-ID: <1417868642.13.0.879452614087.issue23000@psf.upfronthosting.co.za>


New submission from StoreIntegrator:

Hi,

When using Python on Windows I always encounter plenty of errors which are simply frustrating. Typically issues compilation, linking, libraries which have nothing to do with functional coding in Python are numerous.

Do have a look at PTVS tools how an integrated UI can work...

And do try to get rid of the already for > 5 years existing BUGS like:
https://pytools.codeplex.com/workitem/2808

Simply frustrating to use Python this way.

J.

----------
messages: 232240
nosy: StoreIntegrator
priority: normal
severity: normal
status: open
title: More support for Visual Studio users on Windows?
type: compile error
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Dec  6 15:25:06 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 06 Dec 2014 14:25:06 +0000
Subject: [New-bugs-announce] [issue23001] Accept mutable bytes-like objects
Message-ID: <1417875906.64.0.311564166909.issue23001@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Some builtins accept only read-only bytes-like objects (PyArg_Parse format codes "s#", "z#", "y", and "y#"). Proposed patch makes them accepting also mutable bytes-like objects such as bytearray.

I'm not sure that all these changes are useful, but in some cases this can get rid of copying binary data created in bytearray (e.g. read by readinto()).

----------
components: Extension Modules
files: accept_mutable_buffers.patch
keywords: patch
messages: 232244
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Accept mutable bytes-like objects
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file37373/accept_mutable_buffers.patch

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

From report at bugs.python.org  Sat Dec  6 23:09:16 2014
From: report at bugs.python.org (Aivar Annamaa)
Date: Sat, 06 Dec 2014 22:09:16 +0000
Subject: [New-bugs-announce] [issue23002] Trackpad scrolling in tkinter
	doesn't work on some	laptops
Message-ID: <1417903756.15.0.927903848388.issue23002@psf.upfronthosting.co.za>


New submission from Aivar Annamaa:

Here's a simple tkinter program, where text can be scrolled by mouse wheel, and by trackpads of some laptops (Macbook Pro, Dell Latitude E5430), but not by trackpads of some other laptops (Lenovo T420).


from tkinter import Tk
from tkinter import scrolledtext
window = Tk()
text = scrolledtext.ScrolledText(window)
text.grid()
window.mainloop()

----------
components: Tkinter
messages: 232253
nosy: Aivar.Annamaa
priority: normal
severity: normal
status: open
title: Trackpad scrolling in tkinter doesn't work on some laptops
versions: Python 3.4

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

From report at bugs.python.org  Sun Dec  7 00:37:27 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 06 Dec 2014 23:37:27 +0000
Subject: [New-bugs-announce] [issue23003] traceback.{print_exc,
	print_exception, format_exc,
	format_exception}: Potential AttributeError
Message-ID: <1417909047.64.0.652633919593.issue23003@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

Usage of some functions from traceback module can result in AttributeError exception in Python 3, while simply printing/returning something with None in Python 2.
This regression was introduced in Python 3.0.

$ python2.7 -c 'import traceback; print(traceback.print_exc())'
None
None
$ python2.7 -c 'import traceback; print(traceback.print_exception(None, None, None))'
None
None
$ python2.7 -c 'import traceback; print(traceback.format_exc())'
None

$ python2.7 -c 'import traceback; print(traceback.format_exception(None, None, None))'
['None\n']



$ python3.5 -c 'import traceback; print(traceback.print_exc())'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib64/python3.5/traceback.py", line 252, in print_exc
    print_exception(*sys.exc_info(), limit=limit, file=file, chain=chain)
  File "/usr/lib64/python3.5/traceback.py", line 169, in print_exception
    for line in _format_exception_iter(etype, value, tb, limit, chain):
  File "/usr/lib64/python3.5/traceback.py", line 146, in _format_exception_iter
    for value, tb in values:
  File "/usr/lib64/python3.5/traceback.py", line 125, in _iter_chain
    context = exc.__context__
AttributeError: 'NoneType' object has no attribute '__context__'
$ python3.5 -c 'import traceback; print(traceback.print_exception(None, None, None))'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib64/python3.5/traceback.py", line 169, in print_exception
    for line in _format_exception_iter(etype, value, tb, limit, chain):
  File "/usr/lib64/python3.5/traceback.py", line 146, in _format_exception_iter
    for value, tb in values:
  File "/usr/lib64/python3.5/traceback.py", line 125, in _iter_chain
    context = exc.__context__
AttributeError: 'NoneType' object has no attribute '__context__'
$ python3.5 -c 'import traceback; print(traceback.format_exc())'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib64/python3.5/traceback.py", line 256, in format_exc
    return "".join(format_exception(*sys.exc_info(), limit=limit, chain=chain))
  File "/usr/lib64/python3.5/traceback.py", line 181, in format_exception
    return list(_format_exception_iter(etype, value, tb, limit, chain))
  File "/usr/lib64/python3.5/traceback.py", line 146, in _format_exception_iter
    for value, tb in values:
  File "/usr/lib64/python3.5/traceback.py", line 125, in _iter_chain
    context = exc.__context__
AttributeError: 'NoneType' object has no attribute '__context__'
$ python3.5 -c 'import traceback; print(traceback.format_exception(None, None, None))'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib64/python3.5/traceback.py", line 181, in format_exception
    return list(_format_exception_iter(etype, value, tb, limit, chain))
  File "/usr/lib64/python3.5/traceback.py", line 146, in _format_exception_iter
    for value, tb in values:
  File "/usr/lib64/python3.5/traceback.py", line 125, in _iter_chain
    context = exc.__context__
AttributeError: 'NoneType' object has no attribute '__context__'

----------
messages: 232259
nosy: Arfrever
priority: normal
severity: normal
status: open
title: traceback.{print_exc,print_exception,format_exc,format_exception}: Potential AttributeError
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Dec  7 16:24:17 2014
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 07 Dec 2014 15:24:17 +0000
Subject: [New-bugs-announce] [issue23004] mock_open() should allow reading
	binary data
Message-ID: <1417965857.24.0.521739131396.issue23004@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n:

mock_open(read_data=b'...') gives an error:

"""Traceback (most recent call last):
  File "z.py", line 6, in <module>
    print(f.read())
  File "/usr/local/lib/python3.4/unittest/mock.py", line 896, in __call__
    return _mock_self._mock_call(*args, **kwargs)
  File "/usr/local/lib/python3.4/unittest/mock.py", line 962, in _mock_call
    ret_val = effect(*args, **kwargs)
  File "/usr/local/lib/python3.4/unittest/mock.py", line 2279, in _read_side_effect
    return ''.join(_data)
  File "/usr/local/lib/python3.4/unittest/mock.py", line 2244, in _iterate_read_data
    data_as_list = ['{}\n'.format(l) for l in read_data.split('\n')]
"""

Easy to reproduce:

"""
from unittest.mock import mock_open, patch

m = mock_open(read_data= b'abc')
with patch('__main__.open', m, create=True) :
    with open('abc', 'rb') as f :
        print(f.read())
"""

Looks like this bug was introduced as result of issue #17467. I add those people to the nosy list.

----------
keywords: easy
messages: 232271
nosy: a.badger, jcea, michael.foord
priority: normal
severity: normal
status: open
title: mock_open() should allow reading binary data
versions: Python 3.5

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

From report at bugs.python.org  Sun Dec  7 19:47:34 2014
From: report at bugs.python.org (Martin Matusiak)
Date: Sun, 07 Dec 2014 18:47:34 +0000
Subject: [New-bugs-announce] [issue23005] typos on heapq doc
Message-ID: <1417978054.94.0.0217424241667.issue23005@psf.upfronthosting.co.za>


New submission from Martin Matusiak:

- which are pre-sorted sequences, which size is usually related to the amount of CPU memory

whose size

- Tournaments are a good way to that. 

Tournaments are a good way to achieve that.

----------
components: Library (Lib)
files: heapq_docs_typos.diff
keywords: patch
messages: 232273
nosy: ned.deily, numerodix
priority: normal
severity: normal
status: open
title: typos on heapq doc
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37381/heapq_docs_typos.diff

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

From report at bugs.python.org  Sun Dec  7 21:49:29 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 07 Dec 2014 20:49:29 +0000
Subject: [New-bugs-announce] [issue23006] Improve the doc and indexing of
	adict.__missing__.
Message-ID: <1417985369.96.0.326358204226.issue23006@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Currently, the only index entry for __missing__ is  "__missing__() (collections.defaultdict method)".  This entry should probably not exist -- see #9536, which inspired this issue.  The method is not mentioned in the special-methods doc, and the explanation in the dict doc is not indexed.  Two suggestions:

https://docs.python.org/3/reference/datamodel.html#emulating-container-types

After __getitem__ entry, add automatically indexed entry, something like 

object.__missing__(self, key):
   When present in a dict subclass, called by dict.__getitem__ for missing keys.

https://docs.python.org/3/library/stdtypes.html#mapping-types-dict

Before the d[key] paragraph starting "If a subclass of dict defines a method __missing__()" add explicit __missing__ index directive.  The last sentence of the paragraph

"See collections.Counter for a complete implementation including other methods helpful for accumulating and managing tallies."

is confusing because the linked entry makes no mention of __missing__ (as it should not).  Change sentence to something like

"There are two stdlib dict subclasses that use (different) __missing__ methods as part of their implementation: collections.Counter and collections.defaultdict."

I will work on a patch and try to get the markup correct.

----------
assignee: docs at python
components: Documentation
messages: 232279
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve the doc and indexing of adict.__missing__.
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Dec  7 23:43:11 2014
From: report at bugs.python.org (Sergey Litvinov)
Date: Sun, 07 Dec 2014 22:43:11 +0000
Subject: [New-bugs-announce] [issue23007] Unnecessary big intermediate
	result in Lib/bisect.py
Message-ID: <1417992191.21.0.852637765732.issue23007@psf.upfronthosting.co.za>


New submission from Sergey Litvinov:

Bisection algorithms use
mid = (lo+hi)//2

Textbook formula is
mid = (hi-lo)//2 + lo

See
http://en.wikipedia.org/w/index.php?title=Binary_search_algorithm&oldid=634658510#Arithmetic

For "vanilla" lists and integers it is not a problem but one can run
into troubles with user defined types.

----------
components: Library (Lib)
messages: 232286
nosy: Sergey.Litvinov
priority: normal
severity: normal
status: open
title: Unnecessary big intermediate result in Lib/bisect.py
type: behavior
versions: Python 2.7, Python 3.6

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

From report at bugs.python.org  Mon Dec  8 07:04:08 2014
From: report at bugs.python.org (Antony Lee)
Date: Mon, 08 Dec 2014 06:04:08 +0000
Subject: [New-bugs-announce] [issue23008] pydoc enum.{,Int}Enum fails
Message-ID: <1418018648.34.0.0967171282391.issue23008@psf.upfronthosting.co.za>


New submission from Antony Lee:

Not a big deal, but "$ pydoc enum.Enum" and "$ pydoc enum.IntEnum" fail to retrieve the docstrings, while they are visible with "$ pydoc enum".

----------
components: Library (Lib)
messages: 232298
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: pydoc enum.{,Int}Enum fails
versions: Python 3.4

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

From report at bugs.python.org  Mon Dec  8 11:36:45 2014
From: report at bugs.python.org (Alexey Poryadin)
Date: Mon, 08 Dec 2014 10:36:45 +0000
Subject: [New-bugs-announce] [issue23009] selectors.EpollSelector.select
	raises exception when	nothing to select.
Message-ID: <1418035005.39.0.294462650059.issue23009@psf.upfronthosting.co.za>


New submission from Alexey Poryadin:

When is called `select`, but registered no one `fileobject` rise exception:
...
    polled = self._selector.select(timeout)
  File "/usr/lib/python3.4/selectors.py", line 424, in select
    fd_event_list = self._epoll.poll(timeout, max_ev)
ValueError: maxevents must be greater than 0, got 0

Of course, it makes no sense to call `select` if there is nothing to watch. But "select.epol.poll" is not raises exception in the same case if `max_ev`=-1. And this simplifies the application code and is useful if need just sleep for a timeout.

So, I suggest a small fix:
-    fd_event_list = self._epoll.poll(timeout, max_ev)
+    fd_event_list = self._epoll.poll(timeout, max_ev or -1)

----------
messages: 232300
nosy: Alexey.Poryadin
priority: normal
severity: normal
status: open
title: selectors.EpollSelector.select raises exception when nothing to select.
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Dec  8 14:46:55 2014
From: report at bugs.python.org (Walter Doekes)
Date: Mon, 08 Dec 2014 13:46:55 +0000
Subject: [New-bugs-announce] [issue23010] "unclosed file" warning when
	defining unused logging	FileHandler in dictConfig
Message-ID: <1418046415.01.0.116582999558.issue23010@psf.upfronthosting.co.za>


New submission from Walter Doekes:

If you define a FileHandler in your logging dictConfig but fail to use it in the same configuration, the file handle is leaked and a ResourceWarning is thrown.

Versions:

    $ python3 -V
    Python 3.4.0
    $ apt-cache show python3.4 | grep ^Version
    Version: 3.4.0-2ubuntu1

Expected:

    $ PYTHONWARNINGS="default,ignore::DeprecationWarning" \
        python3 problem.py 
    imported once

Observed:

    $ PYTHONWARNINGS="default,ignore::DeprecationWarning" \
        python3 problem.py 
    .../lib/python3.4/importlib/_bootstrap.py:656:
        ResourceWarning: unclosed file
          <_io.FileIO name='/tmp/debug.log' mode='ab'>
      code = marshal.loads(data)
    imported once

To reproduce, save below as problem.py:

    if __name__ == '__main__':
        LOGGING = {
            'version': 1,
            'handlers': {
                'logfile': {
                    'level': 'DEBUG',
                    'class': 'logging.FileHandler',
                    'filename': '/tmp/debug.log',
                },
            },
        }
        
        from logging.config import dictConfig
        dictConfig(LOGGING)
        
        # using importlib on a new file triggers the warnings
        import importlib, shutil, os
        shutil.copy(__file__, __file__ + '.new')
        os.unlink(__file__)
        os.rename(__file__ + '.new', __file__)
        importlib.import_module('problem')
    else:
        print('imported once')


Fixed by:

    --- /usr/lib/python3.4/logging/config.py.orig	2014-12-08 14:06:24.911460799 +0100
    +++ /usr/lib/python3.4/logging/config.py	2014-12-08 14:16:17.519460799 +0100
    @@ -637,6 +637,16 @@ class DictConfigurator(BaseConfigurator)
                         except Exception as e:
                             raise ValueError('Unable to configure root '
                                              'logger: %s' % e)
    +
    +                # Close unused loggers
    +                used_handlers = set()
    +                for logger in logging.root.manager.loggerDict.values():
    +                    if hasattr(logger, 'handlers') and logger.handlers:
    +                        used_handlers.add(*logger.handlers)
    +                for name, handler in handlers.items():
    +                    if handler not in used_handlers:
    +                        if hasattr(handler, 'close'):
    +                            handler.close()
             finally:
                 logging._releaseLock()
     

The fix above might not be the best fix, but it proves where the problem is. Perhaps the handlers shouldn't be instantiated until the first user of such a handler is instantiated.

This issue was found by using Django 1.7 with Python 3.4 when enabling the PYTHONWARNINGS.

Cheers,
Walter Doekes
OSSO B.V.

----------
components: Library (Lib)
messages: 232302
nosy: wdoekes
priority: normal
severity: normal
status: open
title: "unclosed file" warning when defining unused logging FileHandler in dictConfig
versions: Python 3.4

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

From report at bugs.python.org  Mon Dec  8 15:08:55 2014
From: report at bugs.python.org (berndca)
Date: Mon, 08 Dec 2014 14:08:55 +0000
Subject: [New-bugs-announce] [issue23011] Duplicate Paragraph in
	documentation for json module
Message-ID: <1418047735.37.0.83441849339.issue23011@psf.upfronthosting.co.za>


New submission from berndca:

There is a duplication of the first section of 18.2.2 (JSON) Encoders and Decoders of the python 2.7.9RC1 doc as well of the corresponding paragraph in 19.2.2 of the Python 3 docs.

----------
assignee: docs at python
components: Documentation
messages: 232303
nosy: berndca, docs at python
priority: normal
severity: normal
status: open
title: Duplicate Paragraph in documentation for json module
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Dec  8 15:26:18 2014
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 08 Dec 2014 14:26:18 +0000
Subject: [New-bugs-announce] [issue23012] RuntimeError: settrace/setprofile
	function gets lost
Message-ID: <1418048778.92.0.0497543506697.issue23012@psf.upfronthosting.co.za>


New submission from Armin Rigo:

It's not possible to write a settrace() or setprofile() function that remains active if we're about to run out of stack. If we are, we get a RuntimeError when the function is called. The RuntimeError is normally propagated, but in case it is eaten (e.g. see example) then the program continues to run normally --- but the trace/profile function is disabled from now on.

----------
files: test9.py
messages: 232305
nosy: arigo
priority: normal
severity: normal
status: open
title: RuntimeError: settrace/setprofile function gets lost
type: behavior
Added file: http://bugs.python.org/file37386/test9.py

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

From report at bugs.python.org  Mon Dec  8 17:09:14 2014
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 08 Dec 2014 16:09:14 +0000
Subject: [New-bugs-announce] [issue23013] Tweak wording for
	importlib.util.LazyLoader in regards	to Loader.create_module()
Message-ID: <1418054954.8.0.232826100302.issue23013@psf.upfronthosting.co.za>


New submission from Brett Cannon:

The docs for importlib.util.LazyLoader emphatically say that a "loader cannot define importlib.abc.Loader.create_module()" if it is to be subclassed. What in fact should say is that the subclass' create_module() will not be called; whether it is defined or not is of no consequence.

----------
assignee: brett.cannon
components: Documentation
keywords: easy
messages: 232312
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Tweak wording for importlib.util.LazyLoader in regards to Loader.create_module()
versions: Python 3.5

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

From report at bugs.python.org  Mon Dec  8 17:18:58 2014
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 08 Dec 2014 16:18:58 +0000
Subject: [New-bugs-announce] [issue23014] Don't have
	importlib.abc.Loader.create_module() be	optional
Message-ID: <1418055538.78.0.471721917483.issue23014@psf.upfronthosting.co.za>


New submission from Brett Cannon:

I continue to be bothered by how we designed importlib.abc.Loader.create_module(). I don't like that it's optional and I don't like that it can return None.

I would much rather make it so that importlib.abc.Loader.create_module() was a static method that does what importlib.util.module_from_spec() does. I would also like importlib to throw a fit if exec_module() was defined on a loader but not create_module() with a DeprecationWarning to start and then an AttributeError later (as I said, this requires exec_module() defined and does not play into the whole load_module() discussion). This should also hopefully promote people subclassing importlib.abc.Loader more as well.

What do other people think?

----------
components: Interpreter Core
messages: 232313
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Don't have importlib.abc.Loader.create_module() be optional
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Dec  8 21:33:10 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 08 Dec 2014 20:33:10 +0000
Subject: [New-bugs-announce] [issue23015] Improve test_uuid
Message-ID: <1418070790.02.0.347463680837.issue23015@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch makes following changes to test_uuid.

* Report the test as skipped if this method to determine MAC address doesn't work on this platform.
* Output found node value if test ran with -vv.
* Output node values in hexadecimal if node tests fail.
* Check that 47 bit is clear for node values obtained from network card.
* Remove unused commented out code.
* Move internal functions tests to separate test class.

----------
components: Tests
files: test_uuid.patch
keywords: patch
messages: 232327
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Improve test_uuid
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37389/test_uuid.patch

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

From report at bugs.python.org  Tue Dec  9 02:27:03 2014
From: report at bugs.python.org (stockbsd Li)
Date: Tue, 09 Dec 2014 01:27:03 +0000
Subject: [New-bugs-announce] [issue23016] uncatched exception in
	lib/warnings.py when executed	with pythonw
Message-ID: <1418088423.32.0.545997731561.issue23016@psf.upfronthosting.co.za>


New submission from stockbsd Li:

in py3k, the following simple code will throw an uncatched exception when executed with pythonw:

import warnings
warnings.warn('test')

the problem occurs in showarning function: in py3k's pythonw , stderr/stdout is set to None, so the file.write(...) statement will thorw AttributeError uncatched. I think a catch-all except(delete 'OSError') can solve this.

def showwarning(message, category, filename, lineno, file=None, line=None):
    """Hook to write a warning to a file; replace if you like."""
    if file is None:
        file = sys.stderr
    try:
        file.write(formatwarning(message, category, filename, lineno, line))
    except OSError:
        pass # the file (probably stderr) is invalid - this warning gets lost.

----------
components: Library (Lib)
messages: 232342
nosy: stockbsd
priority: normal
severity: normal
status: open
title: uncatched exception in lib/warnings.py when executed with pythonw
type: crash
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Dec  9 04:52:01 2014
From: report at bugs.python.org (Steve Ward)
Date: Tue, 09 Dec 2014 03:52:01 +0000
Subject: [New-bugs-announce] [issue23017] string.printable.isprintable()
	returns False
Message-ID: <1418097121.16.0.891016494417.issue23017@psf.upfronthosting.co.za>


New submission from Steve Ward:

string.printable includes all whitespace characters.  However, the only whitespace character that is printable is the space (0x20).


By definition, the only ASCII characters considered printable are:
    alphanumeric characters
    punctuation characters
    the space character (not all whitespace characters)


Source:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html#tag_07_03

7.2 POSIX Locale

Conforming systems shall provide a POSIX locale, also known as the C locale.


7.3.1 LC_CTYPE

space
    Define characters to be classified as white-space characters.

    In the POSIX locale, exactly <space>, <form-feed>, <newline>, <carriage-return>, <tab>, and <vertical-tab> shall be included.

cntrl
    Define characters to be classified as control characters.

    In the POSIX locale, no characters in classes alpha or print shall be included.

graph
    Define characters to be classified as printable characters, not including the <space>.

    In the POSIX locale, all characters in classes alpha, digit, and punct shall be included; no characters in class cntrl shall be included.

print
    Define characters to be classified as printable characters, including the <space>.

    In the POSIX locale, all characters in class graph shall be included; no characters in class cntrl shall be included.


LC_CTYPE Category in the POSIX Locale

# "print" is by default "alnum", "punct", and the <space>

----------
components: Library (Lib)
files: bug-string-ascii.py
messages: 232343
nosy: planet36
priority: normal
severity: normal
status: open
title: string.printable.isprintable() returns False
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file37391/bug-string-ascii.py

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

From report at bugs.python.org  Tue Dec  9 06:27:42 2014
From: report at bugs.python.org (Steve Dower)
Date: Tue, 09 Dec 2014 05:27:42 +0000
Subject: [New-bugs-announce] [issue23018] Add version info to python[w].exe
Message-ID: <1418102862.79.0.624047396863.issue23018@psf.upfronthosting.co.za>


New submission from Steve Dower:

We should include the version resource in python[w].exe as well as python35.dll so that it can be properly identified. (If possible, we should do .pyd files too, though I don't think the version info will be displayed, so it's probably not worth it.)

----------
assignee: steve.dower
messages: 232345
nosy: steve.dower
priority: normal
severity: normal
status: open
title: Add version info to python[w].exe
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Dec  9 08:45:27 2014
From: report at bugs.python.org (=?utf-8?q?Bj=C3=B6rn_Karge?=)
Date: Tue, 09 Dec 2014 07:45:27 +0000
Subject: [New-bugs-announce] [issue23019] pyexpat.errors wrongly bound to
	message strings instead	of message codes
Message-ID: <1418111127.16.0.333870475533.issue23019@psf.upfronthosting.co.za>


New submission from Bj?rn Karge:

expat.errors should expose the enum values and NOT the associated message strings, so they can be tested against ExpatError.code

----------
components: Library (Lib)
messages: 232348
nosy: bkarge
priority: normal
severity: normal
status: open
title: pyexpat.errors wrongly bound to message strings instead of message codes
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Dec  9 13:31:43 2014
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 09 Dec 2014 12:31:43 +0000
Subject: [New-bugs-announce] [issue23020] New matmul operator crashes
	modules compiled with	CPython3.4
Message-ID: <1418128303.35.0.105853053103.issue23020@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc:

When an extension module is compiled with CPython3.4, the nb_matrix_multiply slot is not filled, and no memory is allocated for it.
If the extension module is imported by CPython3.5, nb_matrix_multiply contains garbage and segfaults the interpreter.

In Python 2.7 there are flags like Py_TPFLAGS_HAVE_INDEX to gate the access  to recently added slots. I think Python3.5 should have a similar one.

----------
messages: 232372
nosy: amaury.forgeotdarc, benjamin.peterson
priority: normal
severity: normal
status: open
title: New matmul operator crashes modules compiled with CPython3.4
type: crash

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

From report at bugs.python.org  Tue Dec  9 17:05:04 2014
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 09 Dec 2014 16:05:04 +0000
Subject: [New-bugs-announce] [issue23021] Get rid of references to PyString
	in Modules/
Message-ID: <1418141104.02.0.91056311182.issue23021@psf.upfronthosting.co.za>


New submission from Berker Peksag:

See issue 22883 for a similar issue.

Modules/_io/_iomodule.h:72:/* Printing a variable of type off_t (with e.g., PyString_FromFormat)
Modules/_json.c:708:    /* Read a JSON array from PyString pystr.
Modules/_json.c:781:    /* Read a JSON constant from PyString pystr.
Modules/_sqlite/connection.h:55:    /* None for autocommit, otherwise a PyString with the isolation level */
Modules/unicodedata.c:482:    /* XXX: could allocate the PyString up front instead

----------
components: Extension Modules
keywords: easy
messages: 232387
nosy: berker.peksag, serhiy.storchaka
priority: low
severity: normal
stage: needs patch
status: open
title: Get rid of references to PyString in Modules/
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Dec 10 10:43:38 2014
From: report at bugs.python.org (peerhash)
Date: Wed, 10 Dec 2014 09:43:38 +0000
Subject: [New-bugs-announce] [issue23022] heap-use-after-free in
	find_maxchar_surrogates
Message-ID: <1418204618.33.0.00964424099855.issue23022@psf.upfronthosting.co.za>


New submission from peerhash:

Line 27-29 trigger use-after-free.

=================================================================
==18203== ERROR: AddressSanitizer: heap-use-after-free on address 0x60080003b2e0 at pc 0x5e844f bp 0x7ffff5351750 sp 0x7ffff5351748
READ of size 4 at 0x60080003b2e0 thread T0
    #0 0x5e844e in find_maxchar_surrogates ./cpython/Objects/unicodeobject.c:1428
    #1 0x5ed62e in PyUnicode_FromUnicode ./cpython/Objects/unicodeobject.c:1822
    #2 0x5f57cd in PyUnicode_FromWideChar ./cpython/Objects/unicodeobject.c:2311
    #3 0x7f4ebbd00976 in Z_get /media/truecrypt1/bounty/cpython/Modules/_ctypes/cfield.c:1429
    #4 0x7f4ebbcde48b in PyCData_get /media/truecrypt1/bounty/cpython/Modules/_ctypes/_ctypes.c:2756
    #5 0x7f4ebbcf90b8 in PyCField_get /media/truecrypt1/bounty/cpython/Modules/_ctypes/cfield.c:230
    #6 0x56ff34 in _PyObject_GenericGetAttrWithDict ./cpython/Objects/object.c:1059
    #7 0x5704ee in PyObject_GenericGetAttr ./cpython/Objects/object.c:1119
    #8 0x56f169 in PyObject_GetAttr ./cpython/Objects/object.c:889
    #9 0x70ef2d in PyEval_EvalFrameEx ./cpython/Python/ceval.c:2442
    #10 0x723c20 in fast_function ./cpython/Python/ceval.c:4368
    #11 0x7234ea in call_function ./cpython/Python/ceval.c:4294
    #12 0x715433 in PyEval_EvalFrameEx ./cpython/Python/ceval.c:2860
    #13 0x71e164 in _PyEval_EvalCodeWithName ./cpython/Python/ceval.c:3610
    #14 0x71e354 in PyEval_EvalCodeEx ./cpython/Python/ceval.c:3631
    #15 0x6f7af3 in PyEval_EvalCode ./cpython/Python/ceval.c:773
    #16 0x42ea99 in run_mod ./cpython/Python/pythonrun.c:968
    #17 0x42e69f in PyRun_FileExFlags ./cpython/Python/pythonrun.c:921
    #18 0x42b456 in PyRun_SimpleFileExFlags ./cpython/Python/pythonrun.c:394
    #19 0x429ac3 in PyRun_AnyFileExFlags ./cpython/Python/pythonrun.c:80
    #20 0x45624b in run_file ./cpython/Modules/main.c:318
    #21 0x457717 in Py_Main ./cpython/Modules/main.c:767
    #22 0x41b845 in main ./cpython/./Programs/python.c:69
    #23 0x7f4ebc741ed4 in __libc_start_main ??:?
    #24 0x41b438 in _start /glibc-tmp-c47113ea580c02d806fd2bb53621c6f5/glibc-2.20/csu/../sysdeps/x86_64/start.S:122
0x60080003b2e0 is located 16 bytes inside of 37-byte region [0x60080003b2d0,0x60080003b2f5)
freed by thread T0 here:
    #0 0x7f4ebd41d34a in __interceptor_free ??:?
    #1 0x41b9b5 in _PyMem_RawFree ./cpython/Objects/obmalloc.c:90
    #2 0x41f4aa in _PyMem_DebugFree ./cpython/Objects/obmalloc.c:1892
    #3 0x41c3db in PyMem_Free ./cpython/Objects/obmalloc.c:349
    #4 0x502f7a in float_repr ./cpython/Objects/floatobject.c:275
    #5 0x56d68a in PyObject_Str ./cpython/Objects/object.c:535
    #6 0x500926 in PyFile_WriteObject ./cpython/Objects/fileobject.c:141
    #7 0x6efe19 in builtin_print ./cpython/Python/bltinmodule.c:2243
    #8 0x564fb5 in PyCFunction_Call ./cpython/Objects/methodobject.c:100
    #9 0x72310c in call_function ./cpython/Python/ceval.c:4269 (discriminator 2)
    #10 0x715433 in PyEval_EvalFrameEx ./cpython/Python/ceval.c:2860
    #11 0x723c20 in fast_function ./cpython/Python/ceval.c:4368
    #12 0x7234ea in call_function ./cpython/Python/ceval.c:4294
    #13 0x715433 in PyEval_EvalFrameEx ./cpython/Python/ceval.c:2860
    #14 0x71e164 in _PyEval_EvalCodeWithName ./cpython/Python/ceval.c:3610
    #15 0x71e354 in PyEval_EvalCodeEx ./cpython/Python/ceval.c:3631
    #16 0x6f7af3 in PyEval_EvalCode ./cpython/Python/ceval.c:773
    #17 0x42ea99 in run_mod ./cpython/Python/pythonrun.c:968
    #18 0x42e69f in PyRun_FileExFlags ./cpython/Python/pythonrun.c:921
    #19 0x42b456 in PyRun_SimpleFileExFlags ./cpython/Python/pythonrun.c:394
    #20 0x429ac3 in PyRun_AnyFileExFlags ./cpython/Python/pythonrun.c:80
    #21 0x45624b in run_file ./cpython/Modules/main.c:318
    #22 0x457717 in Py_Main ./cpython/Modules/main.c:767
    #23 0x41b845 in main ./cpython/./Programs/python.c:69
    #24 0x7f4ebc741ed4 in __libc_start_main ??:?
previously allocated by thread T0 here:
    #0 0x7f4ebd41d42a in malloc ??:?
    #1 0x41b918 in _PyMem_RawMalloc ./cpython/Objects/obmalloc.c:62
    #2 0x41efe9 in _PyMem_DebugAlloc ./cpython/Objects/obmalloc.c:1838
    #3 0x41f29e in _PyMem_DebugMalloc ./cpython/Objects/obmalloc.c:1861
    #4 0x41c256 in PyMem_Malloc ./cpython/Objects/obmalloc.c:325
    #5 0x78b7c0 in format_float_short ./cpython/Python/pystrtod.c:1094
    #6 0x78c224 in PyOS_double_to_string ./cpython/Python/pystrtod.c:1231
    #7 0x502ecb in float_repr ./cpython/Objects/floatobject.c:268
    #8 0x56d68a in PyObject_Str ./cpython/Objects/object.c:535
    #9 0x500926 in PyFile_WriteObject ./cpython/Objects/fileobject.c:141
    #10 0x6efe19 in builtin_print ./cpython/Python/bltinmodule.c:2243
    #11 0x564fb5 in PyCFunction_Call ./cpython/Objects/methodobject.c:100
    #12 0x72310c in call_function ./cpython/Python/ceval.c:4269 (discriminator 2)
    #13 0x715433 in PyEval_EvalFrameEx ./cpython/Python/ceval.c:2860
    #14 0x723c20 in fast_function ./cpython/Python/ceval.c:4368
    #15 0x7234ea in call_function ./cpython/Python/ceval.c:4294
    #16 0x715433 in PyEval_EvalFrameEx ./cpython/Python/ceval.c:2860
    #17 0x71e164 in _PyEval_EvalCodeWithName ./cpython/Python/ceval.c:3610
    #18 0x71e354 in PyEval_EvalCodeEx ./cpython/Python/ceval.c:3631
    #19 0x6f7af3 in PyEval_EvalCode ./cpython/Python/ceval.c:773
    #20 0x42ea99 in run_mod ./cpython/Python/pythonrun.c:968
    #21 0x42e69f in PyRun_FileExFlags ./cpython/Python/pythonrun.c:921
    #22 0x42b456 in PyRun_SimpleFileExFlags ./cpython/Python/pythonrun.c:394
    #23 0x429ac3 in PyRun_AnyFileExFlags ./cpython/Python/pythonrun.c:80
    #24 0x45624b in run_file ./cpython/Modules/main.c:318
    #25 0x457717 in Py_Main ./cpython/Modules/main.c:767
    #26 0x41b845 in main ./cpython/./Programs/python.c:69
    #27 0x7f4ebc741ed4 in __libc_start_main ??:?
Shadow bytes around the buggy address:
  0x0c017ffff600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c017ffff610: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c017ffff620: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c017ffff630: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c017ffff640: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c017ffff650: fa fa fa fa fa fa fa fa fa fa fd fd[fd]fd fd fa
  0x0c017ffff660: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa
  0x0c017ffff670: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa
  0x0c017ffff680: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fd
  0x0c017ffff690: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 04
  0x0c017ffff6a0: fa fa 00 00 00 00 00 04 fa fa fd fd fd fd fd fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:     fa
  Heap righ redzone:     fb
  Freed Heap region:     fd
  Stack left redzone:    f1
  Stack mid redzone:     f2
  Stack right redzone:   f3
  Stack partial redzone: f4
  Stack after return:    f5
  Stack use after scope: f8
  Global redzone:        f9
  Global init order:     f6
  Poisoned by user:      f7
  ASan internal:         fe
==18203== ABORTING

----------
components: ctypes
files: repro.py
hgrepos: 284
messages: 232417
nosy: peerhash
priority: normal
severity: normal
status: open
title: heap-use-after-free in find_maxchar_surrogates
type: security
versions: Python 3.5
Added file: http://bugs.python.org/file37406/repro.py

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

From report at bugs.python.org  Wed Dec 10 13:30:33 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 10 Dec 2014 12:30:33 +0000
Subject: [New-bugs-announce] [issue23023] ./Modules/ld_so_aix not found on
	AIX during	test_distutils
Message-ID: <1418214633.02.0.849905032386.issue23023@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg:

Here's the traceback from one of the AIX buildbots:

[ 32/400] test_distutils
unable to execute './Modules/ld_so_aix': No such file or directory
[22429 refs]
test test_distutils failed -- Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/2.7.edelsohn-aix-ppc64/build/Lib/distutils/tests/test_build_ext.py", line 285, in test_get_outputs
    cmd.run()
  File "/home/shager/cpython-buildarea/2.7.edelsohn-aix-ppc64/build/Lib/distutils/command/build_ext.py", line 337, in run
    self.build_extensions()
  File "/home/shager/cpython-buildarea/2.7.edelsohn-aix-ppc64/build/Lib/distutils/command/build_ext.py", line 446, in build_extensions
    self.build_extension(ext)
  File "/home/shager/cpython-buildarea/2.7.edelsohn-aix-ppc64/build/Lib/distutils/command/build_ext.py", line 528, in build_extension
    target_lang=language)
  File "/home/shager/cpython-buildarea/2.7.edelsohn-aix-ppc64/build/Lib/distutils/ccompiler.py", line 691, in link_shared_object
    extra_preargs, extra_postargs, build_temp, target_lang)
  File "/home/shager/cpython-buildarea/2.7.edelsohn-aix-ppc64/build/Lib/distutils/unixccompiler.py", line 200, in link
    raise LinkError, msg
LinkError: command './Modules/ld_so_aix' failed with exit status 1

(this is the build: http://buildbot.python.org/all/builders/PPC64%20AIX%202.7/builds/917)

This appears to be related to issue18235 which was only fixed for 3.3 and 3.4. I guess a backport should fix the problem for Python 2.7 as well, but cannot test this.

The result of traceback is AIX Python 2.7 always failing on the buildbot waterfall: http://buildbot.python.org/all/builders/PPC64%20AIX%202.7

----------
components: Build, Distutils
messages: 232420
nosy: dstufft, eric.araujo, lemburg
priority: normal
severity: normal
status: open
title: ./Modules/ld_so_aix not found on AIX during test_distutils
versions: Python 2.7

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

From report at bugs.python.org  Wed Dec 10 17:49:32 2014
From: report at bugs.python.org (zhuoyikang)
Date: Wed, 10 Dec 2014 16:49:32 +0000
Subject: [New-bugs-announce] [issue23024] Python Compile Error on Mac os X
	ld: unknown option:	-export-dynamic
Message-ID: <1418230172.81.0.749154265279.issue23024@psf.upfronthosting.co.za>


New submission from zhuoyikang:

/Applications/Xcode.app/Contents/Developer/usr/bin/make Parser/pgen
gcc -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -L/usr/local/lib -export-dynamic  Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/dynamic_annotations.o Python/mysnprintf.o Python/pyctype.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/parsetok_pgen.o Parser/pgenmain.o -ldl  -framework CoreFoundation -o Parser/pgen
ld: unknown option: -export-dynamic
collect2: error: ld returned 1 exit status
make[1]: *** [Parser/pgen] Error 1
make: *** [Include/graminit.h] Error 2

----------
components: Cross-Build
messages: 232434
nosy: zhuoyikang
priority: normal
severity: normal
status: open
title: Python Compile Error on Mac os X  ld: unknown option: -export-dynamic
versions: Python 3.4

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

From report at bugs.python.org  Wed Dec 10 19:16:06 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Wed, 10 Dec 2014 18:16:06 +0000
Subject: [New-bugs-announce] [issue23025] ssl.RAND_bytes docs should mention
	os.urandom
Message-ID: <1418235366.16.0.20927959194.issue23025@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

For almost any conceivable application, os.urandom is a preferable way to access a CSPRNG, and is less error prone, the docs should point this out.

----------
assignee: docs at python
components: Documentation
files: rand.diff
keywords: patch
messages: 232436
nosy: alex, docs at python
priority: normal
severity: normal
status: open
title: ssl.RAND_bytes docs should mention os.urandom
Added file: http://bugs.python.org/file37410/rand.diff

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

From report at bugs.python.org  Wed Dec 10 21:13:53 2014
From: report at bugs.python.org (Mark Grandi)
Date: Wed, 10 Dec 2014 20:13:53 +0000
Subject: [New-bugs-announce] [issue23026] Winreg module doesn't support
	REG_QWORD, small DWORD doc update
Message-ID: <1418242433.97.0.849861872047.issue23026@psf.upfronthosting.co.za>


New submission from Mark Grandi:

The winreg module has constants for the different Windows registry types: https://docs.python.org/3/library/winreg.html?highlight=winreg#value-types

It also links to the Microsoft documentation on the registry types, and I noticed that python doesn't have constants for 2 of the types (really just 1), REG_QWORD and REG_QWORD_LITTLE_ENDIAN (same as REG_QWORD).

So I added the constants in winreg.c, which I think is right, as its the same format as the other ones, and I edited the documentation inside of winreg.c, which is the same changes i made to the docs in winreg.rst, except it doesn't have the markdown/rst/whatever formatting markers. I also made notes on REG_DWORD_LITTLE_ENDIAN that it is equivalent to REG_DWORD.

I also tested to make sure that the documentation builds fine, but I haven't tested building python with the winreg.c changes, as I don't have access to a windows computer that can compile it at the moment. 

Some concerns: 

1: I have no idea if REG_QWORD is defined on 32 bit windows, I would assume it would be, but I can't check at the moment. 

2: There should probably be some switch statement entries in the Reg2Py() and Py2Reg() functions that deal with QWORDs, and dealing with if the python build is 32 bit vs 64 bit. I'm not comfortable with the python C internals to do that myself.

My initial patch is attached, with the documentation + changes to winreg.c that just add the constants to the module

----------
components: Windows
files: winreg_add_qword_constants_part1_markgrandi.patch
keywords: patch
messages: 232442
nosy: markgrandi, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Winreg module doesn't support REG_QWORD, small DWORD doc update
versions: Python 3.4
Added file: http://bugs.python.org/file37411/winreg_add_qword_constants_part1_markgrandi.patch

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

From report at bugs.python.org  Wed Dec 10 22:51:35 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 10 Dec 2014 21:51:35 +0000
Subject: [New-bugs-announce] [issue23027] test_warnings fails with -Werror
Message-ID: <1418248295.01.0.00165630152899.issue23027@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

$ ./python -Werror -m test.regrtest -v test_warnings
...
======================================================================
ERROR: test_warning_classes (test.test_warnings.CWarnTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/test_warnings.py", line 460, in test_warning_classes
    self.module.warn('good warning category', MyWarningClass)
test.test_warnings.WarnTests.test_warning_classes.<locals>.MyWarningClass: good warning category

======================================================================
ERROR: test_warning_classes (test.test_warnings.PyWarnTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/test_warnings.py", line 460, in test_warning_classes
    self.module.warn('good warning category', MyWarningClass)
  File "/home/serhiy/py/cpython/Lib/warnings.py", line 204, in warn
    globals)
  File "/home/serhiy/py/cpython/Lib/warnings.py", line 249, in warn_explicit
    raise message
test.test_warnings.WarnTests.test_warning_classes.<locals>.MyWarningClass: good warning category

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

This is 3.x only issue.

----------
components: Tests
messages: 232446
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_warnings fails with -Werror
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Dec 10 22:58:49 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 10 Dec 2014 21:58:49 +0000
Subject: [New-bugs-announce] [issue23028] CEnvironmentVariableTests and
	PyEnvironmentVariableTests	test the same implementation
Message-ID: <1418248729.18.0.338181805026.issue23028@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

CEnvironmentVariableTests and PyEnvironmentVariableTests are purposed to test C and Python implementations. But they are test the same implementation because execute test code in a subprocess and changes of sys.modules in current process don't affect a subprocess.

----------
components: Tests
messages: 232447
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: CEnvironmentVariableTests and PyEnvironmentVariableTests test the same implementation
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Dec 10 23:08:11 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 10 Dec 2014 22:08:11 +0000
Subject: [New-bugs-announce] [issue23029] test_warnings produces extra
	output in quit mode
Message-ID: <1418249291.77.0.334327768838.issue23029@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

$ ./python -m test.regrtest -q test_warnings
test.test_warnings:559: UserWarning: test

This is 2.7 only issue.

----------
components: Tests
messages: 232448
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_warnings produces extra output in quit mode
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Dec 11 14:59:36 2014
From: report at bugs.python.org (Constantin)
Date: Thu, 11 Dec 2014 13:59:36 +0000
Subject: [New-bugs-announce] [issue23030] lru_cache manual get/put
Message-ID: <1418306376.38.0.155577623227.issue23030@psf.upfronthosting.co.za>


New submission from Constantin:

In an effort for improved communication between stacked decorators, I would like to propose that all decorators providing caching mechanisms should provide the functions cache_info, cache_clear, cache_get and cache_put. The standard lib only provides functools.lru_cache as caching decorators, which already implements the former two. I have attached a patch to provide the latter two.

On python-ideas there was also the idea to create a cache data structure and then have a decorator take its data structure as an argument. But it was argued that this could lead to some optimizations of the caching being impossible.

I think my suggested approach should not impose a problem on highly optimized caching code, because every cache - no matter how optimized - must have some functionality to add something to the cache and lookup something in the cache.

----------
components: Library (Lib)
files: lru_get_put.patch
keywords: patch
messages: 232476
nosy: ConnyOnny
priority: normal
severity: normal
status: open
title: lru_cache manual get/put
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file37415/lru_get_put.patch

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

From report at bugs.python.org  Thu Dec 11 16:59:56 2014
From: report at bugs.python.org (Dan)
Date: Thu, 11 Dec 2014 15:59:56 +0000
Subject: [New-bugs-announce] [issue23031] pdb crashes when jumping over
	"with" statement
Message-ID: <1418313596.21.0.478510528753.issue23031@psf.upfronthosting.co.za>


New submission from Dan:

-> print(1)
(Pdb) jump 6
Segmentation fault

----------
components: Library (Lib)
files: pdb_segfault.py
messages: 232481
nosy: DSP
priority: normal
severity: normal
status: open
title: pdb crashes when jumping over "with" statement
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file37416/pdb_segfault.py

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

From report at bugs.python.org  Thu Dec 11 21:41:07 2014
From: report at bugs.python.org (Ned Deily)
Date: Thu, 11 Dec 2014 20:41:07 +0000
Subject: [New-bugs-announce] [issue23032] 2.7 OS X installer builds fail
	building OpenSSL on OS X	10.4 / Xcode 2.5
Message-ID: <1418330467.3.0.591486521242.issue23032@psf.upfronthosting.co.za>


New submission from Ned Deily:

As of 2.7.9, OS X installer builds now build and link with a private copy of OpenSSL when building for deployment targets of 10.5 or earlier (see Issue17128).  Although we no longer produce installers for earlier than 10.5 and even then built them on 10.5 systems, the legacy installer dmg buildbot still produces 10.3+ builds on OS X 10.4 (presumably using the Xcode 2.5 tool chain) and now fails. 

x86cpuid.s:327:Rest of line ignored. 1st junk character valued 44 (,).
make[1]: *** [x86cpuid.o] Error 1
make: *** [build_crypto] Error 1

I have verified that it is still possible to build for 10.3+ using Xcode 3.1.6 on OS X 10.5 so there is that workaround if anyone needs to build installers for old systems.

It looks like a fix is to disable assembly code in OpenSSL ("no-asm") when building on 10.4.

http://buildbot.python.org/all/builders/bolen-dmg-2.7
https://trac.macports.org/ticket/42049

----------
assignee: ned.deily
components: Build, Macintosh
messages: 232490
nosy: ned.deily, ronaldoussoren
priority: low
severity: normal
stage: needs patch
status: open
title: 2.7 OS X installer builds fail building OpenSSL on OS X 10.4 / Xcode 2.5
versions: Python 2.7

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

From report at bugs.python.org  Thu Dec 11 22:03:43 2014
From: report at bugs.python.org (Donald Stufft)
Date: Thu, 11 Dec 2014 21:03:43 +0000
Subject: [New-bugs-announce] [issue23033] Disallow support for
	a*.example.net, *a.example.net,
	and a*b.example.net in certificate wildcard handling.
Message-ID: <1418331823.45.0.0499057066046.issue23033@psf.upfronthosting.co.za>


New submission from Donald Stufft:

Various browsers[1][2] are dropping support for wild card certificates which are anything but a single "*" alone in the left most position. The other style wildcards were deprecated previously and they should not appear in any public certificate and in the words of the Chrome project are "dang weird for internal certificates".

I believe we should follow suite and just only allow a single "*" alone in the left most segment for the SSL handling code.

[1] https://codereview.chromium.org/762013002
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1107791

----------
messages: 232493
nosy: dstufft
priority: normal
severity: normal
status: open
title: Disallow support for a*.example.net, *a.example.net, and a*b.example.net in certificate wildcard handling.
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Dec 11 22:09:33 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Dec 2014 21:09:33 +0000
Subject: [New-bugs-announce] [issue23034] Dynamically control debugging
	output
Message-ID: <1418332173.89.0.386427809737.issue23034@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

When Python is compiled with some defined macros (e.g. COUNT_ALLOCS) it prints additional debugging output at shutdown. This additional output can cause tests failure (see issue19527). It would be good if Python will silent by default and produce debugging output only if special command line option or environment variable is set.

Debugging output switched by Py_REF_DEBUG is now enabled only when "-X showrefcount" is specified (issue17323).

----------
components: Interpreter Core
messages: 232495
nosy: bkabrda, ezio.melotti, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Dynamically control debugging output
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Fri Dec 12 02:44:07 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 12 Dec 2014 01:44:07 +0000
Subject: [New-bugs-announce] [issue23035] -c: Line causing exception not
	shown for exceptions	other than SyntaxErrors
Message-ID: <1418348647.52.0.502974463654.issue23035@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

When 'python -c ${command}' is used and exception other than SyntaxError occurs, then line causing exception is not shown.

Problem seen in output of last 2 commands below:

$ cat /tmp/test1
1 /
$ cat /tmp/test2
1 / 0
$ cat /tmp/test3
a
$ python3.5 /tmp/test1
  File "/tmp/test1", line 1
    1 /
      ^
SyntaxError: invalid syntax
$ python3.5 /tmp/test2
Traceback (most recent call last):
  File "/tmp/test2", line 1, in <module>
    1 / 0
ZeroDivisionError: division by zero
$ python3.5 /tmp/test3
Traceback (most recent call last):
  File "/tmp/test3", line 1, in <module>
    a
NameError: name 'a' is not defined
$ python3.5 -c '1 /'
  File "<string>", line 1
    1 /
      ^
SyntaxError: invalid syntax
$ python3.5 -c '1 / 0'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ZeroDivisionError: division by zero
$ python3.5 -c 'a'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'a' is not defined

----------
components: Interpreter Core
messages: 232506
nosy: Arfrever, benjamin.peterson, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: -c: Line causing exception not shown for exceptions other than SyntaxErrors
versions: Python 3.5

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

From report at bugs.python.org  Fri Dec 12 12:58:21 2014
From: report at bugs.python.org (E Roberts)
Date: Fri, 12 Dec 2014 11:58:21 +0000
Subject: [New-bugs-announce] [issue23036] Crash Error?
Message-ID: <1418385501.98.0.240780144753.issue23036@psf.upfronthosting.co.za>


New submission from E Roberts:

New to the world of Python. The picture attached is an error that a teacher at my school is receiving when he tries to run anything in IDLE.

I know nothing about coding/python/idle or anything of that nature. 

Sorry I am of little help.

Please can someone help me out with this error and provide any help or an answer. 

Thank you for dealing with a complete novice.

----------
components: IDLE
files: python error.png
messages: 232531
nosy: E.Roberts
priority: normal
severity: normal
status: open
title: Crash Error?
type: crash
versions: Python 3.3
Added file: http://bugs.python.org/file37425/python error.png

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

From report at bugs.python.org  Fri Dec 12 13:36:11 2014
From: report at bugs.python.org (Mark Summerfield)
Date: Fri, 12 Dec 2014 12:36:11 +0000
Subject: [New-bugs-announce] [issue23037] cpu_count() unreliable on Windows
Message-ID: <1418387771.87.0.957316406628.issue23037@psf.upfronthosting.co.za>


New submission from Mark Summerfield:

In message
http://bugs.python.org/issue17914#msg188626
Victor Stenner says

"On Windows, GetSystemInfo() is called instead of reading an environment variable. I suppose that this function is more reliable."

>From my reading, and based on feedback from one of my customers, I believe he is correct and that GetSystemInfo() ought to be used on Windows. (It is available in pywin32 win32api.)

----------
components: Library (Lib), Windows
messages: 232540
nosy: mark, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
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/issue23037>
_______________________________________

From report at bugs.python.org  Fri Dec 12 15:44:33 2014
From: report at bugs.python.org (Collin Anderson)
Date: Fri, 12 Dec 2014 14:44:33 +0000
Subject: [New-bugs-announce] [issue23038] #python.web irc channel is dead
Message-ID: <1418395473.68.0.943574829813.issue23038@psf.upfronthosting.co.za>


New submission from Collin Anderson:

Can we remove references to #python.web? I assume it was a flourishing channel at some point.

https://docs.python.org/3/howto/webservers.html#other-notable-frameworks

----------
assignee: docs at python
components: Documentation
messages: 232550
nosy: collinanderson, docs at python
priority: normal
severity: normal
status: open
title: #python.web irc channel is dead
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Dec 12 16:33:43 2014
From: report at bugs.python.org (Philip Lee)
Date: Fri, 12 Dec 2014 15:33:43 +0000
Subject: [New-bugs-announce] [issue23039] File name restriction on Windows
Message-ID: <1418398423.1.0.43489098063.issue23039@psf.upfronthosting.co.za>


New submission from Philip Lee:

when using open(filename, 'w') on Windows , File names are not allowed to contain any characters in \/:*?"<>|  , however open(filename, 'w') doesn't throw any exceptions when the file name  contains these characters .

I think some warning should be written in the documentation or exceptions thrown should happen  when the file name  contains these characters .

----------
components: IO
messages: 232555
nosy: iMath
priority: normal
severity: normal
status: open
title: File name restriction on Windows
type: enhancement

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

From report at bugs.python.org  Fri Dec 12 16:34:59 2014
From: report at bugs.python.org (Wojtek Ruszczewski)
Date: Fri, 12 Dec 2014 15:34:59 +0000
Subject: [New-bugs-announce] [issue23040] Better documentation for the
	urlencode safe parameter
Message-ID: <1418398499.72.0.468214874616.issue23040@psf.upfronthosting.co.za>


New submission from Wojtek Ruszczewski:

The documentation for urlencode() [1] isn't very clear on how the safe parameter is used, it would better not list it together with encoding and error as only applying to strings.

[1] https://docs.python.org/3.5/library/urllib.parse.html#urllib.parse.urlencode

----------
assignee: docs at python
components: Documentation
files: urlencode-safe.diff
keywords: patch
messages: 232556
nosy: docs at python, wrwrwr
priority: normal
severity: normal
status: open
title: Better documentation for the urlencode safe parameter
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file37426/urlencode-safe.diff

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

From report at bugs.python.org  Fri Dec 12 17:36:45 2014
From: report at bugs.python.org (Samwyse)
Date: Fri, 12 Dec 2014 16:36:45 +0000
Subject: [New-bugs-announce] [issue23041] csv needs more quoting rules
Message-ID: <1418402205.61.0.685044268577.issue23041@psf.upfronthosting.co.za>


New submission from Samwyse:

The csv module currently implements four quoting rules for dialects: QUOTE_MINIMAL, QUOTE_ALL, QUOTE_NONNUMERIC and QUOTE_NONE.  These rules treat values of None the same as an empty string, i.e. by outputting two consecutive quotes.  I propose the addition of two new rules, QUOTE_NOTNULL and QUOTE_STRINGS.  The former behaves like QUOTE_ALL while the later behaves like QUOTE_NONNUMERIC, except that in both cases values of None are output as an empty field.  Examples follow.


Current behavior (which will remain unchanged)

>>> csv.register_dialect('quote_all', quoting=csv.QUOTE_ALL)
>>> csv.writer(sys.stdout, dialect='quote_all').writerow(['foo', None, 42])
"foo","","42"

>>> csv.register_dialect('quote_nonnumeric', quoting=csv.QUOTE_NONNUMERIC)
>>> csv.writer(sys.stdout, dialect='quote_nonnumeric').writerow(['foo', None, 42])
"foo","",42


Proposed behavior

>>> csv.register_dialect('quote_notnull', quoting=csv.QUOTE_NOTNULL)
>>> csv.writer(sys.stdout, dialect='quote_notnull').writerow(['foo', None, 42])
"foo",,"42"

>>> csv.register_dialect('quote_strings', quoting=csv.QUOTE_STRINGS)
>>> csv.writer(sys.stdout, dialect='quote_strings').writerow(['foo', None, 42])
"foo",,42

----------
components: Library (Lib)
messages: 232560
nosy: samwyse
priority: normal
severity: normal
status: open
title: csv needs more quoting rules
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Dec 12 21:40:59 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 12 Dec 2014 20:40:59 +0000
Subject: [New-bugs-announce] [issue23042] Python 2.7.9 ctypes module doesn't
	build on FreeBSD x86
Message-ID: <1418416859.8.0.212660740366.issue23042@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg:

With Python 2.7.8, ctypes builds fine on FreeBSD x86, but with Python 2.7.9, the build fails with:

*** WARNING: renaming "_ctypes" since importing it failed: build/lib.freebsd-8.3-RELEASE-p3-i386-2.7/_ctypes.so: Undefined symbol "ffi_call_win32"

Since this is FreeBSD, there shouldn't really be any calls to ffi_call_win32() in the _ctypes module or libffi.

Looking at the code changes in libffi/src/x86/ffi.c, it looks as if some of the #ifdefs for X86_WIN64 and X86_WIN32 were mixed up, causing calls to the Windows function to be compiled on FreeBSD x86, without also compiling the function definition in the same file.

----------
components: Build, ctypes
messages: 232574
nosy: lemburg
priority: normal
severity: normal
status: open
title: Python 2.7.9 ctypes module doesn't build on FreeBSD x86
versions: Python 2.7

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

From report at bugs.python.org  Fri Dec 12 22:28:18 2014
From: report at bugs.python.org (Vjacheslav)
Date: Fri, 12 Dec 2014 21:28:18 +0000
Subject: [New-bugs-announce] [issue23043] doctest ignores "from __future__
	import print_function"
Message-ID: <1418419698.58.0.173848086418.issue23043@psf.upfronthosting.co.za>


New submission from Vjacheslav:

>>> from __future__ import print_function
>>> print (1,2)
1 2

in interactive session, but, with this 3 lines in tmp.txt:

python -m doctest tmp.txt 

fails (prints tuple)

----------
components: Library (Lib)
messages: 232577
nosy: fva
priority: normal
severity: normal
status: open
title: doctest ignores "from __future__ import print_function"
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Dec 13 03:34:21 2014
From: report at bugs.python.org (Bart Grzybicki)
Date: Sat, 13 Dec 2014 02:34:21 +0000
Subject: [New-bugs-announce] [issue23044] incorrect addition of floating
	point numbers
Message-ID: <1418438061.96.0.666548140464.issue23044@psf.upfronthosting.co.za>


New submission from Bart Grzybicki:

Python 2.7.6 (default, Mar 22 2014, 22:59:56) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 115.26 + 2.01
117.27000000000001
>>> 115.26 + 2.02
117.28
>>> 115.27 + 2.01
117.28
>>>

----------
messages: 232586
nosy: bartgee
priority: normal
severity: normal
status: open
title: incorrect addition of floating point numbers
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Dec 13 05:57:15 2014
From: report at bugs.python.org (vegeshna satyanarayana raju)
Date: Sat, 13 Dec 2014 04:57:15 +0000
Subject: [New-bugs-announce] [issue23045] json data iteration through loop
	in python
Message-ID: <1418446635.96.0.654636210763.issue23045@psf.upfronthosting.co.za>


Changes by vegeshna satyanarayana raju <satya.nani.40 at gmail.com>:


----------
nosy: satyanani40
priority: normal
severity: normal
status: open
title: json data iteration through loop in python

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

From report at bugs.python.org  Sat Dec 13 08:13:12 2014
From: report at bugs.python.org (Martin Panter)
Date: Sat, 13 Dec 2014 07:13:12 +0000
Subject: [New-bugs-announce] [issue23046] asyncio.BaseEventLoop is
	documented, but only exported via asyncio.base_events
Message-ID: <1418454792.43.0.104807870648.issue23046@psf.upfronthosting.co.za>


New submission from Martin Panter:

The documentation mentions BaseEventLoop as an attribute of the ?asyncio? module, but it is not actually there (at least in v3.4.2). I have to import it specially from ?asyncio.base_events?. Is this an oversight in the documentation, or am I relying on undocumented internals? I find the BaseEventLoop class is somewhat helpful for implementing my own event loops.

----------
components: asyncio
messages: 232598
nosy: gvanrossum, haypo, vadmium, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.BaseEventLoop is documented, but only exported via asyncio.base_events
versions: Python 3.4

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

From report at bugs.python.org  Sat Dec 13 11:01:17 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 13 Dec 2014 10:01:17 +0000
Subject: [New-bugs-announce] [issue23047] typo in pyporting.rst
Message-ID: <1418464877.74.0.653707717476.issue23047@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

In Doc/howto/pyporting.rst at line "from __future__ import print_statement":
  s/print_statement/print_function/

----------
assignee: docs at python
components: Documentation
messages: 232600
nosy: brett.cannon, docs at python, xdegaye
priority: normal
severity: normal
status: open
title: typo in pyporting.rst
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sat Dec 13 12:34:33 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 13 Dec 2014 11:34:33 +0000
Subject: [New-bugs-announce] [issue23048] abort when jumping out of a loop
Message-ID: <1418470473.22.0.855190450782.issue23048@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

With the following jump.py script:
def foo():
    import pdb; pdb.set_trace()
    while 1:
        pass
    return # this is line 5

foo()


The following debugging session aborts on Python 3.5.0a0 (default:334c01aa7f93, Dec  3 2014, 16:20:19):
$ python jump.py
> /tmp/test/jump.py(3)foo()
-> while 1:
(Pdb) next
> /tmp/test/jump.py(4)foo()
-> pass
(Pdb) jump 5
python: Objects/frameobject.c:258: frame_setlineno: Assertion `blockstack_top == 0' failed.
Aborted (core dumped)

----------
components: Interpreter Core
messages: 232604
nosy: xdegaye
priority: normal
severity: normal
status: open
title: abort when jumping out of a loop
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Sun Dec 14 01:27:27 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 14 Dec 2014 00:27:27 +0000
Subject: [New-bugs-announce] [issue23049] Fix functools.reduce code
	equivalent.
Message-ID: <1418516847.13.0.26860108886.issue23049@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

from functools import reduce
def add(a,b): return a+b
reduce(add, {})
>>>
Traceback (most recent call last):
  File "C:\Programs\Python34\tem.py", line 3, in <module>
    reduce(add, {})
TypeError: reduce() of empty sequence with no initial value

However, the reduce-equivalent code in the doc sets a bad example and forgets to account for empty iterators.

def reduce(function, iterable, initializer=None):
    it = iter(iterable)
    if initializer is None:
        value = next(it)
    else: ...

So it lets the StopIteration escape (a bad practice that can silently break iterators).  The code should be

def reduce(function, iterable, initializer=None):
    it = iter(iterable)
    if initializer is None:
        try:
            value = next(it)
        except StopIteration:
            raise TypeError("reduce() of empty sequence with no initial value") from None
    else: ...

(patch coming)

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 232626
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Fix functools.reduce code equivalent.
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Dec 14 15:34:49 2014
From: report at bugs.python.org (Tetsuya Morimoto)
Date: Sun, 14 Dec 2014 14:34:49 +0000
Subject: [New-bugs-announce] [issue23050] Add Japanese legacy encodings
Message-ID: <1418567689.35.0.572357268777.issue23050@psf.upfronthosting.co.za>


New submission from Tetsuya Morimoto:

This patch adds Japanese legacy encodings as below.
https://bitbucket.org/t2y/cpython/branches/compare/japanese-legacy-encoding..default

* eucjp_ms (euc-jp compatible with cp932)
* iso2022_jp_ms (yet another iso-2022-jp compatible with cp932, similar to cp50220)
* cp50220 (http://www.iana.org/assignments/charset-reg/CP50220)
* cp50221 (a variant of cp50220)
* cp50222 (a variant of cp50220)
* cp51932 (http://www.iana.org/assignments/charset-reg/CP51932)

Originally, these character encodings patch was created as result in IPA project in 2005, by Masayuki Moriyama. The result was contributed to several community: libiconv, glibc, perl, PHP, Ruby, PostgreSQL, MySQL, nkf. He had made a patch for Python 2.4.3 at that time, but somehow, no one worked to integrate. That's a crying shame.

These character encodings are legacy, but are still used. Lots of end-user don't care the character encoding. Unfortunately, for historical reason, e-mails are encoded with these legacy encodings on Japanese Windows platform. Actually, my customer recently reported about Mojibake since its e-mail data would be encoded with cp50220 (iso-2022-jp-ms).

References:

* About IPA: http://www.ipa.go.jp/english/about/summary.html
* Mojibake: http://en.wikipedia.org/wiki/Mojibake
* Java encoding names: http://docs.oracle.com/javase/8/docs/technotes/guides/intl/encoding.doc.html

References in Japanese:

* Japanese Legacy Encoding Project: http://legacy-encoding.sourceforge.jp/wiki/
* Project details: http://www.ipa.go.jp/about/jigyoseika/05fy-pro/open/2005-1467d.pdf

----------
components: Library (Lib)
files: add-japanese-legacy-encoding1.patch
hgrepos: 285
keywords: patch
messages: 232638
nosy: ishimoto, naoki, t2y
priority: normal
severity: normal
status: open
title: Add Japanese legacy encodings
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file37447/add-japanese-legacy-encoding1.patch

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

From report at bugs.python.org  Sun Dec 14 23:47:29 2014
From: report at bugs.python.org (Alon Diamant)
Date: Sun, 14 Dec 2014 22:47:29 +0000
Subject: [New-bugs-announce] [issue23051] multiprocessing.pool methods
	imap() and imap_unordered()	cause deadlock
Message-ID: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za>


New submission from Alon Diamant:

When imap() or imap_unordered() are called with the iterable parameter set as a generator function, and when that generator function raises an exception, then the _task_handler thread (running the method _handle_tasks) dies immediately, without causing the other threads to stop and without reporting the exception to the main thread (that one that called imap()).

I saw this issue in Python 2.7.8, 2.7.9 and 3.4.2. Didn't check other versions, but I assume this is a bug in all Python versions since 2.6.

I will be attaching examples that reproduce this issue, as well as patches for both Python 2.7 and Python 3.4.

----------
components: Library (Lib)
messages: 232643
nosy: advance512
priority: normal
severity: normal
status: open
title: multiprocessing.pool methods imap() and imap_unordered() cause deadlock
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Mon Dec 15 06:46:14 2014
From: report at bugs.python.org (binbjz)
Date: Mon, 15 Dec 2014 05:46:14 +0000
Subject: [New-bugs-announce] [issue23052] python2.7.9 [SSL:
	CERTIFICATE_VERIFY_FAILED] certificate	verify failed (_ssl.c:581)
Message-ID: <1418622374.17.0.593606620292.issue23052@psf.upfronthosting.co.za>


New submission from binbjz:

It will prompt ssl certificate_vefify_failed(_ssl.c:581) when I used pysphere with python 2.7.9 to connect server. But I switched python 2.7.8 it works well.

2014-12-15 13:22:53,187 [DEBUG] Can not connect to xxx.xxx.xxx.108: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)
2014-12-15 13:22:53,187 [DEBUG] Can not connect to 153.65.178.113: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)
Process Process-2:
Process Process-3:
Traceback (most recent call last):
Traceback (most recent call last):
  File "2.7.9/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap
  File "2.7.9/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap
2014-12-15 13:22:53,187 [DEBUG] Can not connect to xxx.xxx.xxx.109: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)
Process Process-4:
Traceback (most recent call last):
  File "2.7.9/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap
2014-12-15 13:22:53,188 [DEBUG] Can not connect to xxx.xxx.xxx.104: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)
Process Process-6:
Traceback (most recent call last):
  File "2.7.9/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap
2014-12-15 13:22:53,188 [DEBUG] Can not connect to 153.65.178.112: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)
Process Process-1:
Traceback (most recent call last):
  File "2.7.9/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap
2014-12-15 13:22:53,189 [DEBUG] Can not connect to xxx.xxx.xxx.105: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)
Process Process-7:
Traceback (most recent call last):
  File "2.7.9/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap
2014-12-15 13:22:53,190 [DEBUG] Can not connect to xxx.xxx.xxx.106: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)
Process Process-8:
Traceback (most recent call last):
  File "2.7.9/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap
    self.run()
    self.run()
    self.run()
    self.run()
  File "2.7.9/lib/python2.7/multiprocessing/process.py", line 114, in run
  File "2.7.9/lib/python2.7/multiprocessing/process.py", line 114, in run
    self.run()
  File "2.7.9/lib/python2.7/multiprocessing/process.py", line 114, in run
  File "2.7.9/lib/python2.7/multiprocessing/process.py", line 114, in run
    self._target(*self._args, **self._kwargs)
    self.run()
  File "2.7.9/lib/python2.7/multiprocessing/process.py", line 114, in run
    self._target(*self._args, **self._kwargs)
  File "EsxiControler.py", line 153, in get_all_inUse_vm_statusList
  File "2.7.9/lib/python2.7/multiprocessing/process.py", line 114, in run
    self._target(*self._args, **self._kwargs)
  File "EsxiControler.py", line 153, in get_all_inUse_vm_statusList
    self._target(*self._args, **self._kwargs)
  File "EsxiControler.py", line 153, in get_all_inUse_vm_statusList
    self._target(*self._args, **self._kwargs)
    self._target(*self._args, **self._kwargs)
  File "EsxiControler.py", line 153, in get_all_inUse_vm_statusList
  File "EsxiControler.py", line 153, in get_all_inUse_vm_statusList
  File "EsxiControler.py", line 153, in get_all_inUse_vm_statusList
    meth2='get_inUse_vmstatus', meth3='disconnect', initK='vm_name', initV='vm_status')
  File "EsxiControler.py", line 210, in get_output_formatter
    meth2='get_inUse_vmstatus', meth3='disconnect', initK='vm_name', initV='vm_status')
    meth2='get_inUse_vmstatus', meth3='disconnect', initK='vm_name', initV='vm_status')
  File "EsxiControler.py", line 210, in get_output_formatter
    vm_dict = mtd2()
    meth2='get_inUse_vmstatus', meth3='disconnect', initK='vm_name', initV='vm_status')
  File "EsxiControler.py", line 210, in get_output_formatter
    meth2='get_inUse_vmstatus', meth3='disconnect', initK='vm_name', initV='vm_status')
  File "/tmp/EsxiControler.py", line 69, in get_inUse_vmstatus
  File "EsxiControler.py", line 210, in get_output_formatter
    vm_dict = mtd2()
  File "EsxiControler.py", line 210, in get_output_formatter
    vm_dict = mtd2()
  File "/tmp/EsxiControler.py", line 69, in get_inUse_vmstatus
    vm_dict = mtd2()
  File "/tmp/EsxiControler.py", line 69, in get_inUse_vmstatus
    vm_dict = mtd2()
  File "/tmp/EsxiControler.py", line 69, in get_inUse_vmstatus
  File "/tmp/EsxiControler.py", line 69, in get_inUse_vmstatus
    meth2='get_inUse_vmstatus', meth3='disconnect', initK='vm_name', initV='vm_status')
  File "EsxiControler.py", line 210, in get_output_formatter
    vm_dict = mtd2()
  File "/tmp/EsxiControler.py", line 69, in get_inUse_vmstatus
    for vmPath in self.get_vmlist():
    for vmPath in self.get_vmlist():
  File "/tmp/EsxiControler.py", line 56, in get_vmlist
  File "/tmp/EsxiControler.py", line 56, in get_vmlist
    for vmPath in self.get_vmlist():
    for vmPath in self.get_vmlist():
    for vmPath in self.get_vmlist():
    self.vmlist = self.server.get_registered_vms()
    self.vmlist = self.server.get_registered_vms()
  File "/tmp/EsxiControler.py", line 56, in get_vmlist
  File "/tmp/EsxiControler.py", line 56, in get_vmlist
  File "/tmp/EsxiControler.py", line 56, in get_vmlist
  File "2.7.9/lib/python2.7/site-packages/pysphere/vi_server.py", line 357, in get_registered_vms
  File "2.7.9/lib/python2.7/site-packages/pysphere/vi_server.py", line 357, in get_registered_vms
    self.vmlist = self.server.get_registered_vms()
    self.vmlist = self.server.get_registered_vms()
    self.vmlist = self.server.get_registered_vms()
  File "2.7.9/lib/python2.7/site-packages/pysphere/vi_server.py", line 357, in get_registered_vms
  File "2.7.9/lib/python2.7/site-packages/pysphere/vi_server.py", line 357, in get_registered_vms
  File "2.7.9/lib/python2.7/site-packages/pysphere/vi_server.py", line 357, in get_registered_vms
    for vmPath in self.get_vmlist():
  File "/tmp/EsxiControler.py", line 56, in get_vmlist
    self.vmlist = self.server.get_registered_vms()
  File "2.7.9/lib/python2.7/site-packages/pysphere/vi_server.py", line 357, in get_registered_vms
    self.run()
  File "2.7.9/lib/python2.7/multiprocessing/process.py", line 114, in run
    self._target(*self._args, **self._kwargs)
  File "EsxiControler.py", line 153, in get_all_inUse_vm_statusList
2014-12-15 13:22:53,192 [DEBUG] Can not connect to xxx.xxx.xxx.83: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)
    meth2='get_inUse_vmstatus', meth3='disconnect', initK='vm_name', initV='vm_status')
  File "EsxiControler.py", line 210, in get_output_formatter
    vm_dict = mtd2()
  File "/tmp/EsxiControler.py", line 69, in get_inUse_vmstatus
    for vmPath in self.get_vmlist():
  File "/tmp/EsxiControler.py", line 56, in get_vmlist
    self.vmlist = self.server.get_registered_vms()
  File "2.7.9/lib/python2.7/site-packages/pysphere/vi_server.py", line 357, in get_registered_vms
Process Process-5:
Traceback (most recent call last):
  File "2.7.9/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap
2014-12-15 13:22:53,192 [DEBUG] Can not connect to xxx.xxx.xxx.107: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)
2014-12-15 13:22:53,192 [DEBUG] Can not connect to xxx.xxx.xxx.101: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)
    self.run()
  File "2.7.9/lib/python2.7/multiprocessing/process.py", line 114, in run
    self._target(*self._args, **self._kwargs)
  File "EsxiControler.py", line 153, in get_all_inUse_vm_statusList
    meth2='get_inUse_vmstatus', meth3='disconnect', initK='vm_name', initV='vm_status')
  File "EsxiControler.py", line 210, in get_output_formatter
    vm_dict = mtd2()
Process Process-10:
  File "/tmp/EsxiControler.py", line 69, in get_inUse_vmstatus
Traceback (most recent call last):
Process Process-9:
Traceback (most recent call last):
  File "2.7.9/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap
  File "2.7.9/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap
    for vmPath in self.get_vmlist():
  File "/tmp/EsxiControler.py", line 56, in get_vmlist
    self.vmlist = self.server.get_registered_vms()
  File "2.7.9/lib/python2.7/site-packages/pysphere/vi_server.py", line 357, in get_registered_vms
    self.run()
  File "2.7.9/lib/python2.7/multiprocessing/process.py", line 114, in run
    self._target(*self._args, **self._kwargs)
    self.run()
  File "EsxiControler.py", line 153, in get_all_inUse_vm_statusList
  File "2.7.9/lib/python2.7/multiprocessing/process.py", line 114, in run
    self._target(*self._args, **self._kwargs)
  File "EsxiControler.py", line 153, in get_all_inUse_vm_statusList
    meth2='get_inUse_vmstatus', meth3='disconnect', initK='vm_name', initV='vm_status')
  File "EsxiControler.py", line 210, in get_output_formatter
    vm_dict = mtd2()
    meth2='get_inUse_vmstatus', meth3='disconnect', initK='vm_name', initV='vm_status')
  File "/tmp/EsxiControler.py", line 69, in get_inUse_vmstatus
  File "EsxiControler.py", line 210, in get_output_formatter
    vm_dict = mtd2()
  File "/tmp/EsxiControler.py", line 69, in get_inUse_vmstatus
    for vmPath in self.get_vmlist():
  File "/tmp/EsxiControler.py", line 56, in get_vmlist
    self.vmlist = self.server.get_registered_vms()
  File "2.7.9/lib/python2.7/site-packages/pysphere/vi_server.py", line 357, in get_registered_vms
    for vmPath in self.get_vmlist():
  File "/tmp/EsxiControler.py", line 56, in get_vmlist
    self.vmlist = self.server.get_registered_vms()
  File "2.7.9/lib/python2.7/site-packages/pysphere/vi_server.py", line 357, in get_registered_vms
2014-12-15 13:22:53,193 [DEBUG] Can not connect to xxx.xxx.xxx.102: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)
Process Process-11:
Traceback (most recent call last):
  File "2.7.9/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap
2014-12-15 13:22:53,194 [DEBUG] Can not connect to xxx.xxx.xxx.103: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)
    self.run()
  File "2.7.9/lib/python2.7/multiprocessing/process.py", line 114, in run
    self._target(*self._args, **self._kwargs)
  File "EsxiControler.py", line 153, in get_all_inUse_vm_statusList
    meth2='get_inUse_vmstatus', meth3='disconnect', initK='vm_name', initV='vm_status')
  File "EsxiControler.py", line 210, in get_output_formatter
    vm_dict = mtd2()
  File "/tmp/EsxiControler.py", line 69, in get_inUse_vmstatus
Process Process-12:
Traceback (most recent call last):
  File "2.7.9/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap
    for vmPath in self.get_vmlist():
  File "/tmp/EsxiControler.py", line 56, in get_vmlist
    self.vmlist = self.server.get_registered_vms()
  File "2.7.9/lib/python2.7/site-packages/pysphere/vi_server.py", line 357, in get_registered_vms
    self.run()
  File "2.7.9/lib/python2.7/multiprocessing/process.py", line 114, in run
    self._target(*self._args, **self._kwargs)
  File "EsxiControler.py", line 153, in get_all_inUse_vm_statusList
    meth2='get_inUse_vmstatus', meth3='disconnect', initK='vm_name', initV='vm_status')
  File "EsxiControler.py", line 210, in get_output_formatter
    vm_dict = mtd2()
  File "/tmp/EsxiControler.py", line 69, in get_inUse_vmstatus
    for vmPath in self.get_vmlist():
  File "/tmp/EsxiControler.py", line 56, in get_vmlist
    self.vmlist = self.server.get_registered_vms()
  File "2.7.9/lib/python2.7/site-packages/pysphere/vi_server.py", line 357, in get_registered_vms
    FaultTypes.NOT_CONNECTED)
    FaultTypes.NOT_CONNECTED)
VIException: [Not Connected]: Must call 'connect' before invoking this method
VIException: [Not Connected]: Must call 'connect' before invoking this method
    FaultTypes.NOT_CONNECTED)
VIException: [Not Connected]: Must call 'connect' before invoking this method
    FaultTypes.NOT_CONNECTED)
VIException: [Not Connected]: Must call 'connect' before invoking this method
    FaultTypes.NOT_CONNECTED)
VIException: [Not Connected]: Must call 'connect' before invoking this method
    FaultTypes.NOT_CONNECTED)
VIException: [Not Connected]: Must call 'connect' before invoking this method
    FaultTypes.NOT_CONNECTED)
VIException: [Not Connected]: Must call 'connect' before invoking this method
    FaultTypes.NOT_CONNECTED)
VIException: [Not Connected]: Must call 'connect' before invoking this method
    FaultTypes.NOT_CONNECTED)
VIException: [Not Connected]: Must call 'connect' before invoking this method
    FaultTypes.NOT_CONNECTED)
    FaultTypes.NOT_CONNECTED)
VIException: [Not Connected]: Must call 'connect' before invoking this method
VIException: [Not Connected]: Must call 'connect' before invoking this method
    FaultTypes.NOT_CONNECTED)
VIException: [Not Connected]: Must call 'connect' before invoking this method

----------
components: Library (Lib)
messages: 232649
nosy: binbjz
priority: normal
severity: normal
status: open
title: python2.7.9 [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Dec 15 15:10:37 2014
From: report at bugs.python.org (jan matejek)
Date: Mon, 15 Dec 2014 14:10:37 +0000
Subject: [New-bugs-announce] [issue23053] test_urllib2_localnet fails
	without ssl
Message-ID: <1418652637.29.0.740829735045.issue23053@psf.upfronthosting.co.za>


New submission from jan matejek:

The pep 476 commit to Python 2.7 [1] adds unconditional "import ssl" to test_urllib2_localnet.py. This causes the test to fail with an ImportError if ssl module is not built.

Note that like 5 lines later, ssl is imported conditionally, and all the relevant tests are configured to skip if ssl is not present. So to fix this, all that is needed is to remove the "import ssl" line. Attached patch does just that.

[1] https://hg.python.org/cpython/rev/fb83916c3ea1

----------
components: Tests
files: python-2.7-urllib2-localnet-ssl.patch
keywords: patch
messages: 232663
nosy: matejcik
priority: normal
severity: normal
status: open
title: test_urllib2_localnet fails without ssl
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file37454/python-2.7-urllib2-localnet-ssl.patch

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

From report at bugs.python.org  Mon Dec 15 15:49:03 2014
From: report at bugs.python.org (Joe Cabrera)
Date: Mon, 15 Dec 2014 14:49:03 +0000
Subject: [New-bugs-announce] [issue23054] ConnectionError: ('Connection
	aborted.', BadStatusLine(""''''"))
Message-ID: <1418654943.54.0.176050651858.issue23054@psf.upfronthosting.co.za>


New submission from Joe Cabrera:

ConnectionError: ('Connection aborted.', BadStatusLine(""''''"))

This error can also occur on Linux and Windows, a more descriptive error messages would be useful for people trying to debug their code.

----------
assignee: docs at python
components: Documentation
messages: 232664
nosy: docs at python, joecabrera
priority: normal
severity: normal
status: open
title: ConnectionError: ('Connection aborted.', BadStatusLine(""''''"))
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Dec 15 18:18:35 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 15 Dec 2014 17:18:35 +0000
Subject: [New-bugs-announce] [issue23055] PyUnicode_FromFormatV crasher
Message-ID: <1418663915.64.0.885404540917.issue23055@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

Fix as reported by Guido Vranken on security at python.org, with minimal test by me.

Needs:

- review
- port to 3.2--3.5

Questions:

- Does my test case cover all changed code?

----------
assignee: gvanrossum
files: vranken.diff
keywords: needs review, patch
messages: 232673
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: PyUnicode_FromFormatV crasher
type: crash
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37455/vranken.diff

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

From report at bugs.python.org  Mon Dec 15 20:27:54 2014
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 15 Dec 2014 19:27:54 +0000
Subject: [New-bugs-announce] [issue23056] tarfile raises an exception when
	reading an empty tar in	streaming mode
Message-ID: <1418671674.41.0.864207249713.issue23056@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

$ cat >test.py <<EOF
import tarfile
import sys

with tarfile.open(sys.argv[1], mode="r|*") as f:
  while True:
    info = f.next()
    if not info:
      break
EOF
$ tar cf test.tar -T /dev/null
$ python2.7 test.py test.tar
Traceback (most recent call last):
  File "test.py", line 6, in <module>
    info = f.next()
  File "/usr/lib/python2.7/tarfile.py", line 2319, in next
    self.fileobj.seek(self.offset)
  File "/usr/lib/python2.7/tarfile.py", line 555, in seek
    raise StreamError("seeking backwards is not allowed")
tarfile.StreamError: seeking backwards is not allowed
$ python3.4 test.py test.tar
Traceback (most recent call last):
  File "test.py", line 6, in <module>
    info = f.next()
  File "/usr/lib/python3.4/tarfile.py", line 2244, in next
    self.fileobj.seek(self.offset)
  File "/usr/lib/python3.4/tarfile.py", line 518, in seek
    raise StreamError("seeking backwards is not allowed")
tarfile.StreamError: seeking backwards is not allowed

I have reconfirmed that the above still happens using a top of tree 2.7.9+ build.

----------
components: Library (Lib)
messages: 232675
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: tarfile raises an exception when reading an empty tar in streaming mode
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Dec 15 21:10:56 2014
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 15 Dec 2014 20:10:56 +0000
Subject: [New-bugs-announce] [issue23057] asyncio loop on Windows should
	stop on keyboard interrupt
Message-ID: <1418674256.87.0.827009141117.issue23057@psf.upfronthosting.co.za>


New submission from Andrew Svetlov:

See http://stackoverflow.com/questions/27480967/why-does-the-asyncios-event-loop-suppress-the-keyboardinterrupt-on-windows for details

----------
components: asyncio
messages: 232678
nosy: asvetlov, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio loop on Windows should stop on keyboard interrupt
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Dec 15 22:02:07 2014
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=)
Date: Mon, 15 Dec 2014 21:02:07 +0000
Subject: [New-bugs-announce] [issue23058] argparse silently ignores arguments
Message-ID: <1418677327.73.0.355612765077.issue23058@psf.upfronthosting.co.za>


New submission from R?mi Rampin:

This works correctly on Python 3.4.

On Python 2.7, argparse seems to completely and silently ignore arguments in some conditions, for instance this setup will cause --verbose to be ignored on the main parser:

    options = argparse.ArgumentParser(add_help=False)
    options.add_argument('-v', '--verbose', action='store_true')
    parser = argparse.ArgumentParser(parents=[options])
    subparsers = parser.add_subparsers()
    parser_cmd = subparsers.add_parser('cmd', parents=[options])

Full runnable example here: http://paste.pound-python.org/show/XfVVhdJHSPISXLP1lASd/

Might or might not be related to #9351, workarounds welcome.

----------
components: Library (Lib)
messages: 232679
nosy: remram
priority: normal
severity: normal
status: open
title: argparse silently ignores arguments
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Dec 15 22:02:49 2014
From: report at bugs.python.org (Samwyse)
Date: Mon, 15 Dec 2014 21:02:49 +0000
Subject: [New-bugs-announce] [issue23059] sort misc help topics in cmd
Message-ID: <1418677369.11.0.558268336279.issue23059@psf.upfronthosting.co.za>


New submission from Samwyse:

I've discovered that do_help method of cmd.Cmd prints the documented and undocumented commands in sorted order, but does not sort the miscellaneous topics.  This would be an easy fix, just change "self.print_topics(self.misc_header, help.keys(),15,80)" to use "sorted(help.keys())".

----------
components: Library (Lib)
messages: 232680
nosy: samwyse
priority: normal
severity: normal
status: open
title: sort misc help topics in cmd
versions: Python 3.5

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

From report at bugs.python.org  Tue Dec 16 03:29:55 2014
From: report at bugs.python.org (Steve Dower)
Date: Tue, 16 Dec 2014 02:29:55 +0000
Subject: [New-bugs-announce] [issue23060] Assert fails in
	multiprocessing.heap.Arena.__setstate__	on Windows
Message-ID: <1418696995.02.0.22756137648.issue23060@psf.upfronthosting.co.za>


New submission from Steve Dower:

Currently, the implementation of __setstate__ at Lib/multiprocessing/heap.py:54 looks like this:

def __setstate__(self, state):
    self.size, self.name = self._state = state
    self.buffer = mmap.mmap(-1, self.size, tagname=self.name)
    assert _winapi.GetLastError() == _winapi.ERROR_ALREADY_EXISTS

This assertion can fail when the assignment to buffer triggers memory [re]allocation, which could clear the last error result. So far, this fails reliably on debug builds using VS 2015 (which causes some tests to timeout when all of the child processes fail to start), but could also fail in threaded code at any time.

I don't know why release builds or builds with VS 2010 did not trigger this, but I would speculate that either VS 2015 is using a different API to allocate memory or Windows 8.1 has changed the behaviour of an API. Whether a function resets the last error code is deliberately unspecified (http://msdn.microsoft.com/en-us/library/windows/desktop/ms679360(v=vs.85).aspx - "some functions set the last-error code to 0 on success and others do not").

In my opinion, the assertion should just be removed.

A hack that appears to work currently is to add "self.buffer = None" before the existing assignment (to pre-expand self.__dict__ and avoid the allocation).

If the assertion is important, someone may want to add a parameter to mmap() to require that the memory-mapped file already exists and throws otherwise, but I am not volunteering to do this.

----------
components: Windows
messages: 232697
nosy: jnoller, sbt, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Assert fails in multiprocessing.heap.Arena.__setstate__ on Windows
versions: Python 3.5

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

From report at bugs.python.org  Tue Dec 16 05:24:24 2014
From: report at bugs.python.org (Ian Lee)
Date: Tue, 16 Dec 2014 04:24:24 +0000
Subject: [New-bugs-announce] [issue23061] Update pep8 to specify explicitly
	'module level' imports	at top of file
Message-ID: <1418703864.09.0.281927050653.issue23061@psf.upfronthosting.co.za>


New submission from Ian Lee:

Minor update pep8 to specify explicitly that "Imports at top of file" refers specifically to module level imports, per input from Nick Coghlan @ https://github.com/jcrocholl/pep8/pull/304#issuecomment-66939162

----------
assignee: docs at python
components: Documentation
files: pep-0008.patch
keywords: patch
messages: 232708
nosy: IanLee1521, docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: Update pep8 to specify explicitly 'module level' imports at top of file
type: enhancement
Added file: http://bugs.python.org/file37459/pep-0008.patch

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

From report at bugs.python.org  Tue Dec 16 06:12:16 2014
From: report at bugs.python.org (Martin Panter)
Date: Tue, 16 Dec 2014 05:12:16 +0000
Subject: [New-bugs-announce] [issue23062] test_argparse --version test cases
Message-ID: <1418706736.64.0.85644160224.issue23062@psf.upfronthosting.co.za>


New submission from Martin Panter:

In Lib/test/test_argparse.py:

class TestHelpVersionOptional(HelpTestCase):
    """Test that the --version argument can be suppressed help messages"""

Assuming that the docstring means something like ?. . . can be suppressed _in_ help messages?, the test is wrong, because the --version option is present in the expected output. Maybe it is missing a help=SUPPRESS option? Otherwise it seems this test class would be largely redundant with TestHelpVersionAction.

It also looks like the ?version? attribute of the test classes is not used.

----------
components: Tests
messages: 232712
nosy: vadmium
priority: normal
severity: normal
status: open
title: test_argparse --version test cases
versions: Python 3.5

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

From report at bugs.python.org  Tue Dec 16 08:58:05 2014
From: report at bugs.python.org (Marc Abramowitz)
Date: Tue, 16 Dec 2014 07:58:05 +0000
Subject: [New-bugs-announce] [issue23063] `python setup.py check
	--restructuredtext --strict	--metadata` fails with: `warning:
	check: Could not finish the	parsing.` if the RST document
	uses code or code-block directives.
Message-ID: <1418716685.25.0.847417973192.issue23063@psf.upfronthosting.co.za>


New submission from Marc Abramowitz:

`python setup.py check --restructuredtext --strict --metadata` fails with:

    warning: check: Could not finish the parsing.

if the RST document uses `code` or `code-block` directives.

This is annoying because the document is valid, but it appears to be invalid
and confuses people. For example, see
https://github.com/ionelmc/pytest-benchmark/pull/4#issuecomment-66940307

How to reproduce this bug
-------------------------

Clone a repo that has a `README.rst` with `code-block` directives in it. E.g.:

    $ git clone git at github.com:ionelmc/pytest-benchmark.git
    $ cd pytest-benchmark
    $ git checkout ab0b08f6fccb06a7909905a8409f8faa8b01e0d8

   Observe that it has "code-blocks" in it:

       $ grep 'code-block' README.rst
       .. code-block:: python
       .. code-block:: python

Observe that RST document is valid, according to `rst2html.py`:

       $ rst2html.py --halt=1 README.rst > README.html && echo "RST was OK."
       RST was OK.

       $ head -n 3 README.html
       <?xml version="1.0" encoding="utf-8" ?>
       <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
       <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

Observe that `python setup.py check --restructuredtext --strict --metadata` fails:

    $ python setup.py check --restructuredtext --strict --metadata
    running check
    warning: check: Could not finish the parsing.

    error: Please correct your package.

    $ echo $?
    1

**What was expected**: `python setup.py check --restructuredtext --strict
--metadata` should succeed with no warnings, just as `rst2html.py did`, because
`README.rst` is a valid RST document.

**What actually happened**: `python setup.py check --restructuredtext --strict
--metadata` prints a warning and an error and fails, unlike `rst2html.py`

The error is coming from here:
https://github.com/python/cpython/blob/master/Lib/distutils/command/check.py#L142

It's happening because of this line:
https://github.com/python/cpython/blob/master/Lib/distutils/command/check.py#L125

    :::python
    settings = frontend.OptionParser().get_default_values()

If this is changed to:

    :::python
    settings = frontend.OptionParser(components=(Parser,)).get_default_values()

then things work much better (this is how `tools/quicktest.py` in docutils does it for example -- see https://sourceforge.net/p/docutils/code/HEAD/tree/trunk/docutils/tools/quicktest.py#l196)

The attached patch prevents the failure from happening and also adds more information to the error when things go south.

----------
components: Distutils
hgrepos: 286
messages: 232720
nosy: Marc.Abramowitz, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: `python setup.py check --restructuredtext --strict --metadata` fails with: `warning: check: Could not finish the parsing.` if the RST document uses code or code-block directives.
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Dec 16 10:41:22 2014
From: report at bugs.python.org (liu chang)
Date: Tue, 16 Dec 2014 09:41:22 +0000
Subject: [New-bugs-announce] [issue23064] pep8 asyncore.py
Message-ID: <1418722882.44.0.721367843466.issue23064@psf.upfronthosting.co.za>


New submission from liu chang:

pep8 Lib/asycore.py.

----------
components: Library (Lib)
files: pep8-asyncore.patch
hgrepos: 287
keywords: patch
messages: 232730
nosy: ?.?
priority: normal
severity: normal
status: open
title: pep8 asyncore.py
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file37462/pep8-asyncore.patch

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

From report at bugs.python.org  Tue Dec 16 11:55:19 2014
From: report at bugs.python.org (GamesGamble)
Date: Tue, 16 Dec 2014 10:55:19 +0000
Subject: [New-bugs-announce] [issue23065] Pyhton27.dll at SysWOW64 not
	updated when updating	Python 2.7.X
Message-ID: <1418727319.18.0.894015013947.issue23065@psf.upfronthosting.co.za>


New submission from GamesGamble:

Hello,
the Python27.dll at >C:\Windows\SysWOW64< not get updated when updating Python 2.7.X at Windows 7 SP1 (Reported weak spot from Kaspersky Pure 3.0 weak spot search). When I?am manually deinstalling Python und install Python after deinstalling It got the updated *.dll .

----------
components: Windows
messages: 232733
nosy: GamesGamble, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Pyhton27.dll at SysWOW64 not updated when updating Python 2.7.X
type: security
versions: Python 2.7

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

From report at bugs.python.org  Tue Dec 16 16:28:28 2014
From: report at bugs.python.org (Jie Yin)
Date: Tue, 16 Dec 2014 15:28:28 +0000
Subject: [New-bugs-announce] [issue23066] re.match hang
Message-ID: <1418743708.93.0.075282769465.issue23066@psf.upfronthosting.co.za>


New submission from Jie Yin:

The following expression hang in 2.7.9 for the module re:

re.match('^([a-zA-Z0-9]+|[\\s]+|[,.])+$', 'Feature Test Macro Requirements for glibc ()')

----------
components: Interpreter Core
messages: 232746
nosy: writalnaie
priority: normal
severity: normal
status: open
title: re.match hang
type: security
versions: Python 2.7

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

From report at bugs.python.org  Tue Dec 16 20:29:14 2014
From: report at bugs.python.org (Chris Hand)
Date: Tue, 16 Dec 2014 19:29:14 +0000
Subject: [New-bugs-announce] [issue23067] Export readline
	forced_update_display
Message-ID: <1418758154.75.0.0731776033419.issue23067@psf.upfronthosting.co.za>


New submission from Chris Hand:

The current implementation of readline implements the redisplay function, but not the forced version. This patch maintains the current behavior as the default, but also allows a bool to be passed which, if True, calls rl_forced_update_display instead.

----------
components: Extension Modules
files: readline_redisplay_force.patch
keywords: patch
messages: 232757
nosy: dexteradeus
priority: normal
severity: normal
status: open
title: Export readline forced_update_display
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file37473/readline_redisplay_force.patch

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

From report at bugs.python.org  Wed Dec 17 03:14:37 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 17 Dec 2014 02:14:37 +0000
Subject: [New-bugs-announce] [issue23068] Add a way to determine if the
	current thread has the	import lock
Message-ID: <1418782477.87.0.643327890289.issue23068@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

imp.lock_held() returns True if *any* thread is currently importing something. I'd like to have an API that can tell whether the *current* thread has the import lock.  The implementation keeps track of this, but doesn't make the info available.

Use case: print a warning/error if a network call is made during import.

----------
components: Library (Lib)
messages: 232792
nosy: gvanrossum
priority: normal
severity: normal
stage: needs patch
status: open
title: Add a way to determine if the current thread has the import lock
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Dec 17 03:30:30 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 17 Dec 2014 02:30:30 +0000
Subject: [New-bugs-announce] [issue23069] IDLE's F5 Run Module doesn't
	transfer effects of future	import
Message-ID: <1418783430.85.0.171264628982.issue23069@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Future imports in a module aren't transferring to the interactive shell when executing Run Module.

Given the file tmp_future.py
----------------------------
$ cat tmp_future.py
from __future__ import division, print_function

print(32 / 5)

Run Python interactively
------------------------
$ python2.7 -i tmp_future.py 
6.4
>>> 32 / 5          # this works fine!
6.4

But open the file in IDLE and press F5:
---------------------------------------
Python 2.7.9 (v2.7.9:648dcafa7e5f, Dec 10 2014, 10:10:46) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "copyright", "credits" or "license()" for more information.
>>> ================================ RESTART ================================
>>> 
6.4
>>> print(32 / 5)       # this is broken!
6

Note, the problem may also apply to IDLE Python 3.4 and 3.5 but it won't affect this example because the future imports have not effect.

----------
components: IDLE
files: tmp_future.py
messages: 232794
nosy: rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE's F5 Run Module doesn't transfer effects of future import
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file37477/tmp_future.py

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

From report at bugs.python.org  Wed Dec 17 03:51:07 2014
From: report at bugs.python.org (Ross Burnett)
Date: Wed, 17 Dec 2014 02:51:07 +0000
Subject: [New-bugs-announce] [issue23070] Error in Tutorial comment
Message-ID: <1418784667.28.0.75679477956.issue23070@psf.upfronthosting.co.za>


New submission from Ross Burnett:

In section "3.1.2. Strings" of the Tutorial (version 3.4 plus others?), a comment on a slicing error has an error:

"word[42]  # the word only has 7 characters"

It should say "word[42]  # the word has 6 characters"

----------
assignee: docs at python
components: Documentation
messages: 232795
nosy: docs at python, rossburnett
priority: normal
severity: normal
status: open
title: Error in Tutorial comment
versions: Python 3.4

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

From report at bugs.python.org  Wed Dec 17 05:53:33 2014
From: report at bugs.python.org (Martin Panter)
Date: Wed, 17 Dec 2014 04:53:33 +0000
Subject: [New-bugs-announce] [issue23071] codecs.__all__ incomplete
Message-ID: <1418792013.22.0.617617600077.issue23071@psf.upfronthosting.co.za>


New submission from Martin Panter:

First ones I noticed were codecs.encode() and codecs.decode(). Here is a list of other candidates, although they are not all documented, so maybe should not all be in __all__.

>>> import codecs
>>> public = (a for a in dir(codecs) if not a.startswith("_"))
>>> sorted(set(public).difference(codecs.__all__))
['BufferedIncrementalDecoder', 'BufferedIncrementalEncoder', 'Codec', 'CodecInfo', 'IncrementalDecoder', 'IncrementalEncoder', 'StreamReader', 'StreamReaderWriter', 'StreamRecoder', 'StreamWriter', 'ascii_decode', 'ascii_encode', 'backslashreplace_errors', 'builtins', 'charmap_build', 'charmap_decode', 'charmap_encode', 'decode', 'encode', 'escape_decode', 'escape_encode', 'getdecoder', 'getencoder', 'getincrementaldecoder', 'getincrementalencoder', 'getreader', 'getwriter', 'iterdecode', 'iterencode', 'latin_1_decode', 'latin_1_encode', 'make_encoding_map', 'make_identity_dict', 'raw_unicode_escape_decode', 'raw_unicode_escape_encode', 'readbuffer_encode', 'sys', 'unicode_escape_decode', 'unicode_escape_encode', 'unicode_internal_decode', 'unicode_internal_encode', 'utf_16_be_decode', 'utf_16_be_encode', 'utf_16_decode', 'utf_16_encode', 'utf_16_ex_decode', 'utf_16_le_decode', 'utf_16_le_encode', 'utf_32_be_decode', 'utf_32_be_encode', 'utf_32_decode', 'utf_32_encode', 'utf_32_ex_decode', 'utf_32_le_decode', 'utf_32_le_encode', 'utf_7_decode', 'utf_7_encode', 'utf_8_decode', 'utf_8_encode']

----------
components: Library (Lib)
messages: 232800
nosy: vadmium
priority: normal
severity: normal
status: open
title: codecs.__all__ incomplete
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Dec 17 06:37:53 2014
From: report at bugs.python.org (aab)
Date: Wed, 17 Dec 2014 05:37:53 +0000
Subject: [New-bugs-announce] [issue23072] 2.7.9 multiprocessing compile
	conflict
Message-ID: <1418794673.39.0.221318823729.issue23072@psf.upfronthosting.co.za>


New submission from aab:

python-2.7.9/Modules/_multiprocessing/multiprocessing.c
python-2.7.9/Modules/_multiprocessing/semaphore.c

The compile lines for the above two files have "-DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1 -DHAVE_SEM_TIMEDWAIT=0" in them.  The cpp code in those files uses "#ifdef" and "#ifndef" with those symbols commensurate with the #define/#undef commands used in 'pyconfig.h'. In my case, the biggest problem is the "-DHAVE_SEM_TIMEDWAIT=0" which DEFINES that symbol so that the "#ifndef HAVE_SEM_TIMEDWAIT" in semaphore.c fails to do what the coder wanted.  Being very lazy, I just hacked the files to use "#if SYMBOL" and "#if ! SYMBOL".  Worked fine.

Solaris 2.8
Studio 11 Compiler Suite

--  Thanks,
--    aab

----------
components: Build
messages: 232801
nosy: aab at purdue.edu
priority: normal
severity: normal
status: open
title: 2.7.9 multiprocessing compile conflict
versions: Python 2.7

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

From report at bugs.python.org  Wed Dec 17 22:28:40 2014
From: report at bugs.python.org (bbc)
Date: Wed, 17 Dec 2014 21:28:40 +0000
Subject: [New-bugs-announce] [issue23073] Broken turtle example in Cmd
	documentation
Message-ID: <1418851720.64.0.216827601034.issue23073@psf.upfronthosting.co.za>


New submission from bbc:

The documentation page for the cmd module contains an example with the turtle module:

https://docs.python.org/3.4/library/cmd.html#cmd-example

It seems like the turtle module has changed quite a bit since the code was written, and exposes a Pen class instead of all the various movement functions.  The example, while still useful, cannot be executed as is.

I like the example and would be happy to provide an idiomatic replacement if you think this is necessary.

----------
assignee: docs at python
components: Documentation
messages: 232829
nosy: bbc, docs at python
priority: normal
severity: normal
status: open
title: Broken turtle example in Cmd documentation
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Dec 17 23:49:12 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Dec 2014 22:49:12 +0000
Subject: [New-bugs-announce] [issue23074] asyncio: get_event_loop() must
	always raise an exception, even when assertions are disabled by -O
Message-ID: <1418856552.4.0.422863873532.issue23074@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Spinoff of the issue #22926: asyncio.get_event_loop() must always raise an exception, even when assertions are disabled by -O.

Attached patch implements this suggestion.

----------
components: asyncio
files: get_event_loop.patch
keywords: patch
messages: 232830
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: get_event_loop() must always raise an exception, even when assertions are disabled by -O
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37482/get_event_loop.patch

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

From report at bugs.python.org  Thu Dec 18 00:52:00 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Wed, 17 Dec 2014 23:52:00 +0000
Subject: [New-bugs-announce] [issue23075] Mock backport in 2.7 relies on
	implementation defined	behavior
Message-ID: <1418860320.5.0.0748673104985.issue23075@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

Whether __builtins__ is a module or a dict is undefined in CPython. Use the reliably well defined `import __builtin__` instead.

----------
components: Library (Lib)
files: mock-backport.diff
keywords: patch
messages: 232838
nosy: alex, benjamin.peterson, dstufft
priority: normal
severity: normal
status: open
title: Mock backport in 2.7 relies on implementation defined behavior
versions: Python 2.7
Added file: http://bugs.python.org/file37484/mock-backport.diff

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

From report at bugs.python.org  Thu Dec 18 00:59:40 2014
From: report at bugs.python.org (Antony Lee)
Date: Wed, 17 Dec 2014 23:59:40 +0000
Subject: [New-bugs-announce] [issue23076] path.glob("") fails with IndexError
Message-ID: <1418860780.4.0.558535328721.issue23076@psf.upfronthosting.co.za>


New submission from Antony Lee:

glob.glob returns an empty list when passed an empty pattern as argument, but pathlib's Path.glob fails with IndexError.  The first option seems more reasonable (or at least it should be a ValueError).

----------
components: Library (Lib)
messages: 232841
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: path.glob("") fails with IndexError
versions: Python 3.4

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

From report at bugs.python.org  Thu Dec 18 01:08:58 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 18 Dec 2014 00:08:58 +0000
Subject: [New-bugs-announce] [issue23077] PEP 1: Allow Provisional status
	for PEPs
Message-ID: <1418861338.72.0.949069550217.issue23077@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

As per python-dev discussion [1], filing this as the home for a proposed update to PEP 1 that allows Standards Track PEPs to be granted Provisional status before moving on to Accepted/Final.

The new status will be for PEPs where we want to release an initial reference implementation (whether in CPython under PEP 411 or through the PyPA toolchain) before locking down the exact details of the API specification.

[1] https://mail.python.org/pipermail/python-dev/2014-December/137622.html

----------
assignee: ncoghlan
messages: 232842
nosy: Jeremy.Hylton, barry, goodger, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: PEP 1: Allow Provisional status for PEPs
type: enhancement

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

From report at bugs.python.org  Thu Dec 18 09:45:23 2014
From: report at bugs.python.org (Kevin Benton)
Date: Thu, 18 Dec 2014 08:45:23 +0000
Subject: [New-bugs-announce] [issue23078] unittest.mock patch autospec
	doesn't work on	staticmethods
Message-ID: <1418892323.1.0.910322233262.issue23078@psf.upfronthosting.co.za>


New submission from Kevin Benton:

If one of the mock.patch methods is used with autospec=True on a staticmethod in an object, the mock library determines that it is not callable by checking for the __call__ attribute. This results in a NonCallableMagicMock being returned which of course dies with the following error when the mocked method is called:

TypeError: 'NonCallableMagicMock' object is not callable


It seems that the create_autospec needs to special case for classmethod and staticmethod.



The following change seems to fix it, however I am only vaguely familiar with the internals of mock so I'm not sure what this breaks.

diff -r d356250e275d mock.py
--- a/mock.py	Tue Apr 09 14:53:33 2013 +0100
+++ b/mock.py	Wed Dec 17 07:35:15 2014 -0800
@@ -2191,7 +2191,8 @@
         # descriptors don't have a spec
         # because we don't know what type they return
         _kwargs = {}
-    elif not _callable(spec):
+    elif not _callable(spec) and not isinstance(spec, (staticmethod,
+                                                       classmethod)):
         Klass = NonCallableMagicMock
     elif is_type and instance and not _instance_callable(spec):
         Klass = NonCallableMagicMock

----------
components: Tests
messages: 232864
nosy: kevinbenton, michael.foord
priority: normal
severity: normal
status: open
title: unittest.mock patch autospec doesn't work on staticmethods
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Dec 18 13:02:11 2014
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 18 Dec 2014 12:02:11 +0000
Subject: [New-bugs-announce] [issue23079] os.path.normcase documentation
	confusing
Message-ID: <1418904131.32.0.416083778815.issue23079@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The documentation for os.path.normcase(path) is currently confusing or self-contradictory.

Currently, it reads--

"Normalize the case of a pathname. On Unix and Mac OS X, this returns the path unchanged; on case-insensitive filesystems, it converts the path to lowercase."

However, with a case-insensitive file system on Mac OS X (e.g. "File System Personality: Journaled HFS+"), normcase() does not convert paths to lowercase.

As it stands, it seems like the clause "on case-insensitive filesystems, it converts the path to lowercase" should be removed or further qualified.  I don't know what the qualification is though.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 232871
nosy: chris.jerdonek, docs at python
priority: normal
severity: normal
status: open
title: os.path.normcase documentation confusing
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Dec 18 13:56:29 2014
From: report at bugs.python.org (Antony Lee)
Date: Thu, 18 Dec 2014 12:56:29 +0000
Subject: [New-bugs-announce] [issue23080] BoundArguments.arguments should be
	unordered
Message-ID: <1418907389.55.0.608772896554.issue23080@psf.upfronthosting.co.za>


New submission from Antony Lee:

This patch makes BoundArguments.arguments an unordered dict.  As discussed on python-ideas, the rationale for this is

1. The current ordering in ba.arguments is the one of the parameters in the signature (which is already available via the ba.signature attribute), not the one in which the arguments are given (which will always be unavailable as long as Python doesn't keep the order of keyword arguments), so no information is lost by this patch.

2. The recipe in the docs for updating ba.arguments to also contain default argument values breaks that ordering, making __eq__ behavior difficult to explain:

s = signature(lambda x=None, y=None: None)
ba0 = s.bind()
ba1 = s.bind(x=None)
ba2 = s.bind(y=None)
<add default values as suggested in the docs>

At that point, with the current implementation, we'll have ba0 == ba1 != ba2... why?

3. Implementing ba.arguments as a regular dict makes signature.bind much faster, which is important e.g. if it is used in a decorating type-checker as suggested in PEP362.  (That specific issue could also be improved by a C-implemented OrderedDict, but the other reasons remain valid.)

----------
components: Library (Lib)
files: unordered-boundarguments.patch
keywords: patch
messages: 232874
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: BoundArguments.arguments should be unordered
versions: Python 3.5
Added file: http://bugs.python.org/file37492/unordered-boundarguments.patch

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

From report at bugs.python.org  Thu Dec 18 14:15:20 2014
From: report at bugs.python.org (Lars Buitinck)
Date: Thu, 18 Dec 2014 13:15:20 +0000
Subject: [New-bugs-announce] [issue23081] Document PySequence_List(o) as
	equivalent to list(o)
Message-ID: <1418908520.28.0.480794985208.issue23081@psf.upfronthosting.co.za>


New submission from Lars Buitinck:

PySequence_List has accepted iterables since changeset 6c82277e77f3 of May 1, 2001 ("NEEDS DOC CHANGES" :), but its documentation still only speaks of sequences. I suggest that it is changed to promise to handle arbitrary iterables, just like PySequence_Tuple.

----------
assignee: docs at python
components: Documentation
files: PySequence_List-doc.patch
keywords: patch
messages: 232875
nosy: docs at python, larsmans
priority: normal
severity: normal
status: open
title: Document PySequence_List(o) as equivalent to list(o)
versions: Python 3.5
Added file: http://bugs.python.org/file37493/PySequence_List-doc.patch

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

From report at bugs.python.org  Thu Dec 18 14:37:19 2014
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 18 Dec 2014 13:37:19 +0000
Subject: [New-bugs-announce] [issue23082] pathlib relative_to() can give
	confusing error message
Message-ID: <1418909839.25.0.648032443428.issue23082@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

pathlib's relative_to(other) can give a confusing message when "other" is os.curdir.

For example--

    Python 3.4.2 (default, Nov 12 2014, 18:23:59) 
    [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.54)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import os
    >>> from pathlib import Path
    >>> Path("/foo").relative_to(os.curdir)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/pathlib.py", line 806, in relative_to
        .format(str(self), str(formatted)))
    ValueError: '/foo' does not start with ''

I guess the error here is that the path must be relative when "other" is relative.

----------
components: Library (Lib)
messages: 232876
nosy: chris.jerdonek
priority: normal
severity: normal
status: open
title: pathlib relative_to() can give confusing error message
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Dec 18 16:06:24 2014
From: report at bugs.python.org (Polux Moon)
Date: Thu, 18 Dec 2014 15:06:24 +0000
Subject: [New-bugs-announce] [issue23083] sys.exit with bool parameter
Message-ID: <1418915184.17.0.474799432406.issue23083@psf.upfronthosting.co.za>


New submission from Polux Moon:

when using a bool as parameter implementation (2.7) behave like:
sys.exit(True) <=> sys.exit(1)
sys.exit(False) <=> sys.exit(0)

so the bool indicate if the termination is abnormal

following the doc it should be equivalent to sys.exit(1) in all cases
if we assume the implementation is right, the doc should describe the behavior for boolean input

----------
assignee: docs at python
components: Documentation
messages: 232883
nosy: Polux.Moon, docs at python
priority: normal
severity: normal
status: open
title: sys.exit with bool parameter
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Dec 18 17:34:38 2014
From: report at bugs.python.org (mdcb)
Date: Thu, 18 Dec 2014 16:34:38 +0000
Subject: [New-bugs-announce] [issue23084] nanosecond support
Message-ID: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za>


New submission from mdcb:

nanosecond support has been discussed at length on python-dev and issue 15443.
POSIX.1b defines a struct timespec that is commonly used in C, and seems a good candidate to add core nanosecond support. kernel's time-related structs typically end up in the time module.

Attached patch defines a new type struct_timespec for the time module. A new capsule exports the type along with to/from converters - opening a bridge for C, and for example the datetime module.

----------
components: Library (Lib)
files: time.struct_timespec.patch
hgrepos: 289
keywords: patch
messages: 232889
nosy: mdcb808 at gmail.com
priority: normal
severity: normal
status: open
title: nanosecond support
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file37495/time.struct_timespec.patch

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

From report at bugs.python.org  Thu Dec 18 18:13:23 2014
From: report at bugs.python.org (Gustavo Temple)
Date: Thu, 18 Dec 2014 17:13:23 +0000
Subject: [New-bugs-announce] [issue23085] update internal libffi copy to 3.1
Message-ID: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za>


New submission from Gustavo Temple:

Link to the file:
https://github.com/gustavotemple/cpython/pull/2.diff

Link to the changes:
https://github.com/gustavotemple/cpython/pull/2/commits

----------
components: ctypes
files: libffi.patch
keywords: patch
messages: 232890
nosy: doko, gustavotemple, meador.inge
priority: normal
severity: normal
status: open
title: update internal libffi copy to 3.1
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37496/libffi.patch

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

From report at bugs.python.org  Thu Dec 18 21:41:46 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 18 Dec 2014 20:41:46 +0000
Subject: [New-bugs-announce] [issue23086] Add start and stop parameters to
	the Sequence.index()	ABC mixin method
Message-ID: <1418935306.72.0.256960321979.issue23086@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Currently, the Sequence ABC doesn't support start and stop arguments for the index() method which limits its usefulness in doing repeated searches (iterating over a target value) and which limits it substitutablity for various concrete sequences such as tuples, lists, strings, bytes, bytearrays, etc.

>>> help(Sequence.index)
Help on method index in module _abcoll:

index(self, value) unbound _abcoll.Sequence method
    S.index(value) -> integer -- return first index of value.
    Raises ValueError if the value is not present.

>>> help(list.index)
Help on method_descriptor:

index(...)
    L.index(value, [start, [stop]]) -> integer -- return first index of value.
    Raises ValueError if the value is not present.

>>> help(str.index)
Help on method_descriptor:

index(...)
    S.index(sub [,start [,end]]) -> int
    
    Like S.find() but raise ValueError when the substring is not found.

>>> help(tuple.index)
Help on method_descriptor:

index(...)
    T.index(value, [start, [stop]]) -> integer -- return first index of value.
    Raises ValueError if the value is not present.

>>> help(bytes.index)
Help on method_descriptor:

index(...)
    S.index(sub [,start [,end]]) -> int
    
    Like S.find() but raise ValueError when the substring is not found.

>>> help(bytearray.index)
Help on method_descriptor:

index(...)
    B.index(sub [,start [,end]]) -> int
    
    Like B.find() but raise ValueError when the subsection is not found.

----------
assignee: rhettinger
components: Library (Lib)
messages: 232904
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Add start and stop parameters to the Sequence.index() ABC mixin method
versions: Python 3.5

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

From report at bugs.python.org  Thu Dec 18 23:27:04 2014
From: report at bugs.python.org (Keith Chewning)
Date: Thu, 18 Dec 2014 22:27:04 +0000
Subject: [New-bugs-announce] [issue23087] Exec variable not found error
Message-ID: <1418941624.73.0.497940658508.issue23087@psf.upfronthosting.co.za>


New submission from Keith Chewning:

If I %paste this code into an ipython shell the test passes. If this is saved to a file DictTest.py and run with ./DictTest.py -m the test fails. with the error

name 'keys' is not defined

If the variable keys is made global, as is suggested in the comment, the test passes with both methods of execution. Is there a scoping issue with executing this as a script?

I am using version: '3.4.1 |Anaconda 2.1.0 (64-bit)| (default, Sep 10 2014, 17:10:18) \n[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)]'

import unittest

class DictTest(unittest.TestCase):
    def test_dict_comprehension(self):
        code = """
d = {'a':1, 'b':2, 'c':3, 'd':4}
# global keys # UNCOMMENT FOR TEST TO PASS
keys = ['a', 'd']
items = d.items()
nd = {k: v for k, v in items if k in keys}
print('>>> ' + str(nd))
"""
        try:
            exec(code)
        except Exception as e:
            self.assertTrue(False, "Exec ERROR>>> %s" % e)

def main():
    dt = DictTest()    
    dt.test_dict_comprehension()

if  __name__ =='__main__':main()

----------
messages: 232907
nosy: Keith.Chewning
priority: normal
severity: normal
status: open
title: Exec variable not found error
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Dec 19 05:42:34 2014
From: report at bugs.python.org (Martin Panter)
Date: Fri, 19 Dec 2014 04:42:34 +0000
Subject: [New-bugs-announce] [issue23088] Document that PyUnicode_AsUTF8()
	returns a	null-terminated string
Message-ID: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za>


New submission from Martin Panter:

As discussed in msg232863, and later confirmed in the code

----------
assignee: docs at python
components: Documentation
files: utf8-null.patch
keywords: patch
messages: 232925
nosy: docs at python, vadmium
priority: normal
severity: normal
status: open
title: Document that PyUnicode_AsUTF8() returns a null-terminated string
versions: Python 3.4
Added file: http://bugs.python.org/file37502/utf8-null.patch

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

From report at bugs.python.org  Fri Dec 19 17:07:34 2014
From: report at bugs.python.org (Gustavo Temple)
Date: Fri, 19 Dec 2014 16:07:34 +0000
Subject: [New-bugs-announce] [issue23089] Update config files
Message-ID: <1419005254.2.0.517752739413.issue23089@psf.upfronthosting.co.za>


New submission from Gustavo Temple:

Update config.guess and config.sub

----------
components: Installation
files: config.patch
keywords: patch
messages: 232937
nosy: gustavotemple
priority: normal
severity: normal
status: open
title: Update config files
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37506/config.patch

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

From report at bugs.python.org  Fri Dec 19 18:53:40 2014
From: report at bugs.python.org (Brian Kearns)
Date: Fri, 19 Dec 2014 17:53:40 +0000
Subject: [New-bugs-announce] [issue23090] fix test_doctest relying on
	refcounting to close files
Message-ID: <1419011620.53.0.891989929963.issue23090@psf.upfronthosting.co.za>


Changes by Brian Kearns <bdkearns at gmail.com>:


----------
files: fix_test_doctest.patch
keywords: patch
nosy: bdkearns
priority: normal
severity: normal
status: open
title: fix test_doctest relying on refcounting to close files
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file37508/fix_test_doctest.patch

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

From report at bugs.python.org  Sat Dec 20 03:37:18 2014
From: report at bugs.python.org (S. Andrew Sheppard)
Date: Sat, 20 Dec 2014 02:37:18 +0000
Subject: [New-bugs-announce] [issue23091] unpacked keyword arguments are not
	unicode normalized
Message-ID: <1419043038.74.0.103514960492.issue23091@psf.upfronthosting.co.za>


New submission from S. Andrew Sheppard:

I came across unexpected behavior working with unpacking keyword arguments in Python 3.  It appears to be related to the automatic normalization of unicode characters to NFKC (PEP 3131), which converts e.g. MICRO SIGN to GREEK SMALL LETTER MU.  This conversion is applied to regular keyword arguments but not when unpacking arguments via **.

This issue arose while I was working with some automatically generated namedtuple classes, but I was able to reproduce it with a simple function:

def test(?):
    print(?)

>>> test(?="test1") # chr(181)
test1

>>> test(?="test2") # chr(956)
test2

>>> test(**{'?': "test3"}) # chr(956)
test3

>>> test(**{'?': "test4"}) # chr(181)

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: test() got an unexpected keyword argument '?'


I can obviously work around this, but wanted to bring it up in case it's a bug.  My naive expectation would be that unpacked ** keys should be treated exactly like normal keyword arguments.

----------
components: Unicode
messages: 232956
nosy: ezio.melotti, haypo, sheppard
priority: normal
severity: normal
status: open
title: unpacked keyword arguments are not unicode normalized
versions: Python 3.4

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

From report at bugs.python.org  Sat Dec 20 03:39:45 2014
From: report at bugs.python.org (Vinson Lee)
Date: Sat, 20 Dec 2014 02:39:45 +0000
Subject: [New-bugs-announce] [issue23092] Python 2.7.9 test_readline
	regression on CentOS 6
Message-ID: <1419043185.97.0.756938564911.issue23092@psf.upfronthosting.co.za>


New submission from Vinson Lee:

test_readline regressed from Python 2.7.8 to Python 2.7.9 on CentOS 6

Python 2.7.8
$ ./python -m test.regrtest test_readline
test_readline
1 test OK.

Python 2.7.9
$ ./python -m test.regrtest test_readline
[1/1] test_readline
test test_readline failed -- Traceback (most recent call last):
  File "Python-2.7.9/Lib/test/test_readline.py", line 56, in test_init
    self.assertEqual(stdout, b'')
AssertionError: '\x1b[?1034h' != ''

1 test failed:
    test_readline

$ cat /etc/redhat-release
CentOS release 6.6 (Final)

$ rpm -qa | grep readline
readline-6.0-4.el6.x86_64
compat-readline5-5.2-17.1.el6.x86_64
readline-devel-6.0-4.el6.x86_64

----------
components: Tests
messages: 232957
nosy: vlee
priority: normal
severity: normal
status: open
title: Python 2.7.9 test_readline regression on CentOS 6
versions: Python 2.7

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

From report at bugs.python.org  Sat Dec 20 15:19:49 2014
From: report at bugs.python.org (Martin Panter)
Date: Sat, 20 Dec 2014 14:19:49 +0000
Subject: [New-bugs-announce] [issue23093] repr() on detached stream objects
	fails
Message-ID: <1419085189.47.0.13249408936.issue23093@psf.upfronthosting.co.za>


New submission from Martin Panter:

Patch to fix the underlying issue I mentioned in msg230955. After calling detach() on one of the BufferedIOBase wrappers or a TextIOWrapper, most operations will raise an exception. My patch ensures the following operations are still usable, because they are documented and it doesn?t make sense to disable them:

repr(stream)
stream.encoding
stream.errors
stream.line_buffering

----------
components: IO
files: detach-indep.patch
keywords: patch
messages: 232971
nosy: vadmium
priority: normal
severity: normal
status: open
title: repr() on detached stream objects fails
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file37516/detach-indep.patch

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

From report at bugs.python.org  Sun Dec 21 00:24:32 2014
From: report at bugs.python.org (CensoredUsername)
Date: Sat, 20 Dec 2014 23:24:32 +0000
Subject: [New-bugs-announce] [issue23094] Unpickler failing with
	PicklingError at frame end on	readline due to a broken comparison
Message-ID: <1419117872.02.0.125928182025.issue23094@psf.upfronthosting.co.za>


New submission from CensoredUsername:

If a pickle frame ends at the end of a pickle._Unframer.readline() call then an UnpicklingError("pickle exhausted before end of frame") will unconditionally be raised due to a faulty check if the frame ended before the line ended.

It concerns this conditional in pickle._Unframer.readline, line 245 in pickle.py:

if data[-1] != b'\n':
    raise UnpicklingError(
        "pickle exhausted before end of frame")

This comparison will always evaluate to True even if data ends in a newline. This is caused by data being a bytes object, and such data[-1] will evaluate to 10 in case of data ending in a newline. 10 != b'\n' will then always evaluate to True due to the type mismatch, and the UnpicklingError will be raised.

This error can be corrected by slicing an actual one character bytes object like:

if data[-1:] != b'\n':
    raise UnpicklingError(
        "pickle exhausted before end of frame")

Or by comparing against the numeric representation of b'\n':

if data[-1] != b'\n'[0]:
    raise UnpicklingError(
        "pickle exhausted before end of frame")

----------
messages: 232984
nosy: CensoredUsername
priority: normal
severity: normal
status: open
title: Unpickler failing with PicklingError at frame end on readline due to a broken comparison
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Dec 21 01:47:46 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 21 Dec 2014 00:47:46 +0000
Subject: [New-bugs-announce] [issue23095] asyncio: race condition in the
	IOCP code (proactor event	loop)
Message-ID: <1419122866.29.0.725788641938.issue23095@psf.upfronthosting.co.za>


New submission from STINNER Victor:

On Windows using the IOCP (proactor) event loop, I noticed race conditions when running the test suite of Trollius. For examples, sometimes the returncode of a process is None, which should never happen. It looks like wait_for_handle() has an invalid behaviour.

When I run the test suite of asyncio in debug mode (PYTHONASYNCIODEBUG=1), sometimes I see the message "GetQueuedCompletionStatus() returned an unexpected event" which should never occur neither.

I added debug traces. I saw that the IocpProactor.wait_for_handle() calls later PostQueuedCompletionStatus() through its internal C callback (PostToQueueCallback). It looks like sometimes the callback is called whereas the wait was cancelled/acked with UnregisterWait().

I didn't understand the logic between RegisterWaitForSingleObject(), UnregisterWait() and the callback.

It looks like sometimes the overlapped object created in Python ("ov = _overlapped.Overlapped(NULL)") is destroyed, before PostToQueueCallback() was called. In the unit tests, it doesn't crash because a different overlapped object is created and it gets the same memory address (probably because we are lucky!).

The current implementation of wait_for_handle() has an optimization: it polls immediatly the wait to check if it already completed. I tried to remove it, but I got some different issues. If I understood correctly, this optimization hides other bugs and reduce the probability of getting the race condition.

wait_for_handle() in used to wait for the completion of a subprocess, so by all unit tests running subprocesses, but also in test_wait_for_handle() and test_wait_for_handle_cancel() tests. I suspect that running test_wait_for_handle() or test_wait_for_handle_cancel() schedule the bug.

Note: Removing "_winapi.CloseHandle(self._iocp)" in IocpProactor.close() works around the bug. The bug looks to be an expected call to PostToQueueCallback() which calls PostQueuedCompletionStatus() on an IOCP. Not closing the IOCP means using a different IOCP for each test, so the unexpected call to PostQueuedCompletionStatus() has no effect on following tests.

--

I rewrote some parts of the IOCP code in asyncio. Maybe I introduced this issue during the refactoring. Maybe it already existed before but nobody noticed it, asyncio had fewer unit tests before.

At the beginning, I wanted to fix this crash:
https://code.google.com/p/tulip/issues/detail?id=195
"_WaitHandleFuture.cancel() crash if the wait event was already unregistered"

Later, I tried to make the code more reliable in this issue:
https://code.google.com/p/tulip/issues/detail?id=196
"_OverlappedFuture.set_result() should clear the its reference to the overlapped object"

Read Trollius 1.0.1 changelog which lists these changes:
http://trollius.readthedocs.org/changelog.html#version-1-0-1

--

Note: The IOCP code still has code which can be enhanced:

- "Investigate IocpProactor.accept_pipe() special case (don't register overlapped)"
  https://code.google.com/p/tulip/issues/detail?id=204

- "Rewrite IocpProactor.connect_pipe() with non-blocking calls to avoid non interruptible QueueUserWorkItem()"
  https://code.google.com/p/tulip/issues/detail?id=197

----------
components: Windows, asyncio
messages: 232987
nosy: gvanrossum, haypo, steve.dower, tim.golden, yselivanov, zach.ware
priority: normal
severity: normal
status: open
title: asyncio: race condition in the IOCP code (proactor event loop)
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Dec 21 09:10:33 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 21 Dec 2014 08:10:33 +0000
Subject: [New-bugs-announce] [issue23096] Implementation-depended pickling
	floats with protocol 0
Message-ID: <1419149433.29.0.802482425543.issue23096@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Python and C implementations of pickle produce different results when pickle floats with protocol 0.

>>> pickle.dumps(4.2, 0)
b'F4.2000000000000002\n.'
>>> pickle._dumps(4.2, 0)
b'F4.2\n.'

----------
components: Library (Lib)
messages: 232992
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Implementation-depended pickling floats with protocol 0
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Dec 21 09:42:19 2014
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 21 Dec 2014 08:42:19 +0000
Subject: [New-bugs-announce] [issue23097] unittest can unnecessarily modify
	sys.path (and with the	wrong case)
Message-ID: <1419151339.28.0.203745779889.issue23097@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

I have observed that when running unit tests using unittest's test discovery, unittest can simultaneously (1) modify sys.path unnecessarily (by adding a path that is already in sys.path with a different case), and (2) modify sys.path by adding a path of the "wrong" case.

This occurs for me on Mac OS X with the default case-insensitive file system.

If the path--

'/Users/chris/Dev/python/my_package'

is already in sys.path, running unittest's test discovery will prepend sys.path with the following:

'/Users/chris/dev/python/my_package'

Aside from causing unnecessary modifications of sys.path, this also causes an issue in coverage, for example:

https://bitbucket.org/ned/coveragepy/issue/348

The relevant code is here in unittest/loader.py (with `top_level_dir` starting out as os.curdir):

    top_level_dir = os.path.abspath(top_level_dir)

    if not top_level_dir in sys.path:
        # all test modules must be importable from the top level directory
        # should we *unconditionally* put the start directory in first
        # in sys.path to minimise likelihood of conflicts between installed
        # modules and development versions?
        sys.path.insert(0, top_level_dir)
    self._top_level_dir = top_level_dir

(from https://hg.python.org/cpython/file/75ede5bec8db/Lib/unittest/loader.py#l259 )

The issue occurs when os.path.abspath(top_level_dir) is already in sys.path but with a different case.  (Note that if os.path.abspath() returned a path with the "right" case, then the unittest code would be okay.)

See also these two threads regarding obtaining the correct case for a path:

1. https://mail.python.org/pipermail/python-dev/2010-September/103823.html
2. https://mail.python.org/pipermail/python-ideas/2010-September/008153.html

----------
components: Library (Lib)
messages: 232993
nosy: chris.jerdonek
priority: normal
severity: normal
status: open
title: unittest can unnecessarily modify sys.path (and with the wrong case)
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Dec 21 23:36:24 2014
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 21 Dec 2014 22:36:24 +0000
Subject: [New-bugs-announce] [issue23098] mknod devices can be >32 bits
Message-ID: <1419201384.94.0.109155979555.issue23098@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n:

Dan MacDonald told me that "os.mknod()" should accept devices >32 bits.

I wrote this code in linux 64 bits:

"""
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>

int main(void) {
    printf("%d", sizeof(dev_t));
    return 0;
}
"""

The result of running this is "8". We need a long long.

I did this change in Python 2.7 branch:

"""
diff -r f00412d32b41 Modules/posixmodule.c
--- a/Modules/posixmodule.c	Sat Dec 20 13:41:14 2014 -0600
+++ b/Modules/posixmodule.c	Sun Dec 21 23:30:00 2014 +0100
@@ -7009,9 +7009,9 @@
 {
     char *filename;
     int mode = 0600;
-    int device = 0;
+    long long device = 0;
     int res;
-    if (!PyArg_ParseTuple(args, "s|ii:mknod", &filename, &mode, &device))
+    if (!PyArg_ParseTuple(args, "s|iL:mknod", &filename, &mode, &device))
         return NULL;
     Py_BEGIN_ALLOW_THREADS
     res = mknod(filename, mode, device);
"""

Looks like this patch is trivial. Please, comment.

----------
assignee: jcea
keywords: easy
messages: 233004
nosy: jcea
priority: normal
severity: normal
stage: patch review
status: open
title: mknod devices can be >32 bits
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Dec 22 12:41:17 2014
From: report at bugs.python.org (Martin Panter)
Date: Mon, 22 Dec 2014 11:41:17 +0000
Subject: [New-bugs-announce] [issue23099] BytesIO and StringIO values
	unavailable when closed
Message-ID: <1419248477.31.0.512702147737.issue23099@psf.upfronthosting.co.za>


New submission from Martin Panter:

IOBase.close() doc says file operations raise ValueError, but it is not obvious to me that reading back the ?file? buffer is a file operation.

>>> with BytesIO() as b:
...     b.write(b"123")
... 
3
>>> b.getvalue()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: I/O operation on closed file.

Even worse, the memoryview gets corrupted on close():

>>> b = BytesIO(b"123")
>>> m = b.getbuffer()
>>> b.close()
>>> bytes(m)
b'\x98\x02>'

I also noticed that in the ?io? implementation, writing to the file seems to be completely disallowed, even if it would not seem to change the size:

>>> b = BytesIO(b"123")
>>> m = b.getbuffer()
>>> b.write(b"x")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
BufferError: Existing exports of data: object cannot be re-sized

----------
components: IO
messages: 233016
nosy: vadmium
priority: normal
severity: normal
status: open
title: BytesIO and StringIO values unavailable when closed
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Dec 23 00:58:11 2014
From: report at bugs.python.org (Davin Potts)
Date: Mon, 22 Dec 2014 23:58:11 +0000
Subject: [New-bugs-announce] [issue23100] multiprocessing doc organization
	impedes understanding
Message-ID: <1419292691.51.0.0335324108877.issue23100@psf.upfronthosting.co.za>


New submission from Davin Potts:

The organization and multiple sections of the multiprocessing module's documentation do not adhere to the Python Dev Guidelines for economy of expression, affirmative tone, and/or code examples.

Problem description:
The raw material and information in the multiprocessing module docs are good to excellent and very information rich -- the presentation of that information suffers primarily from its organization.
(1)  Too much information is presented in the same or neighboring subsections where the economy of expression guidelines would advocate for a different approach.  Specifically, section 17.2.2 "Reference" co-mingles discourses on usage topics with a description of the available objects and apis.  Section 17.2.1 "Introduction" does something similar and though some of this can be helpful in an intro section, it takes discourse a bit far at times, arguably losing its focus which is to clearly introduce the reader to the module and efficiently set them on a healthy path to understanding topics and establish sufficient comfort to begin working with the module.  Economy of expression would have us maintain focus in an Introduction or Reference section and re-organize such helpful discourses into supporting but distinct sections.
(2) Affirmative tone is not consistently used throughout the docs.  Multiple of the items under section 17.2.3 "Programming guidelines" leverage negative examples to motivate what should be done instead -- each of these can be rewritten in the way advocated in the Python Dev Guidelines for affirmative tone.
(3) Per the Python Dev Guidelines for code examples, examples should accelerate understanding versus alternative prose.  Code snippets showcasing internal behavior to the module, such as the "Beware of replacing sys.stdin" subsection inside 17.2.3.1 "All start methods", should arguably have their example code blocks replaced with prose.  Section 17.2.4 "Examples" provides examples showcasing many facets all in the same example code block yet little to no supporting or motivating explanation is offered for each (more could be offered inline as well as outside as prose).

Suggested changes:
* Re-organize the single multiprocessing module doc into multiple in the style of the logging module.  Specifically, tutorials should be created to house the "bunny trail" discourses from the Introduction/Reference sections and a cookbook should be created to house the material from the Examples section.
* By de-bunny-trailing the Introduction/Reference sections, a more focused set of sections in the style of the threading module should result.
* Limited modifications to code examples are advocated only so far as they restore the affirmative tone as needed.
* New examples are not advocated as part of this issue; they are out-of-scope.

This issue is intended to add to the path started/advocated by Issue 22952.  It does not supplant but rather expands upon that issue.

----------
assignee: docs at python
components: Documentation
messages: 233030
nosy: davin, docs at python, rhettinger
priority: normal
severity: normal
status: open
title: multiprocessing doc organization impedes understanding
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Dec 23 06:23:11 2014
From: report at bugs.python.org (Greg Turner)
Date: Tue, 23 Dec 2014 05:23:11 +0000
Subject: [New-bugs-announce] [issue23101] \\di\\\\
Message-ID: <1419312191.92.0.129176482008.issue23101@psf.upfronthosting.co.za>


Changes by Greg Turner <gmt at be-evil.net>:


----------
components: Distutils
nosy: dstufft, eric.araujo, gmt
priority: normal
severity: normal
status: open
title: \\di\\\\

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

From report at bugs.python.org  Tue Dec 23 07:36:28 2014
From: report at bugs.python.org (Greg Turner)
Date: Tue, 23 Dec 2014 06:36:28 +0000
Subject: [New-bugs-announce] [issue23102] distutils: tip-toe around quirks
	owing to setuptools	monkey-patching Extension
Message-ID: <1419316588.75.0.487755278973.issue23102@psf.upfronthosting.co.za>


New submission from Greg Turner:

Clinical Presentation:
Sometimes a developer consuming distutils will write what seems like a perfectly sensible setup.py, but something inscrutable happens: setup.py bombs out claiming "error: each element of 'ext_modules' option must be an Extension instance or 2-tuple".

Prognosis:
Once she manages to capture this error in pdb (takes some doing), intrepid developer may discover that, bizarrely, it IS an Extension instance, yet, somehow, (not isinstance(that_thing, Extension)) == True.  Sooner or later she'll likely throw up her hands and follow some far-seeing dude's advice on StackOverflow([1]), which will probably work.

If she undertakes a more thorough investigation, she may figure out the true etiology (see below), at which point, various minor tweaks will likely present themselves to her as obvious situation-specific solutions to the problem.

Etiology:
Developer likely employed code early in her module like:

  from distutils.extension import Extension

  .
  . (some other imports)
  .

  setup(..., ext_modules = [
      Extension(...), 
      ...,
  ], ...)

What happened was that setuptools got imported by (presumably) some third-party code, at which point, setuptools monkey-patched distutils.extension.Extension(*), as is setuptools' SOP.

However, in setup.py, a reference to the un-monkey-patched Extension was already saved off as __main__.Extension (along with, in all probability, other un-patched distutils things, as folks tend to consistently use one style or another of import).  So __main__ calls (an un-monkey-patched version of) distutils.core.setup, which ultimately iterates through the list of Extensions, checking isinstance(item, Extension), or so, which, as can now be seen, is not going to be true.

So, the error message is correct, it just fails to mention the possibility that there are multiple things called "Extension" floating around with identical repr's.

Epidemiological Outlook:
Seemingly this is a rare condition, but when a case develops, it can be costly, due to the likelihood of misdiagnosis and/or partial remission and relapse.

One possible vaccine has been developed and is enclosed.  It has not been subjected to clinical trial, nor peer-review (until now).  It is enclosed as a patch which applies to python 2.7-3.5 and seems to do the trick in the particular case that was buggin' me (wish I could say it will do the trick for any non-broken use-case, but I can't, as if I made such a claim, I'd clearly jinx it).

--
* Arguably, this is a bug or misfeature of setuptools, as here setuptools appears to too liberally assume that, if its modules were even casually imported, then it's a good time to monkey-patch distutils.  However, IME, fixing this putative bug, threatens to be a non-trivial undertaking and cause a bunch of regressions and contingent hassles.

Background URLS:

[1] http://stackoverflow.com/questions/21594925/error-each-element-of-ext-modules-option-must-be-an-extension-instance-or-2-t

https://bitbucket.org/pypa/setuptools/issue/309

https://bugs.gentoo.org/show_bug.cgi?id=532708

----------
components: Distutils
files: distutils_accomodate_extension_ducktypes.patch
keywords: patch
messages: 233034
nosy: dstufft, eric.araujo, gmt
priority: normal
severity: normal
status: open
title: distutils: tip-toe around quirks owing to setuptools monkey-patching Extension
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file37529/distutils_accomodate_extension_ducktypes.patch

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

From report at bugs.python.org  Tue Dec 23 10:57:26 2014
From: report at bugs.python.org (Seth Bromberger)
Date: Tue, 23 Dec 2014 09:57:26 +0000
Subject: [New-bugs-announce] [issue23103] ipaddress should be Flyweight
Message-ID: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za>


New submission from Seth Bromberger:

ipaddress.ip_address instances should be flyweight. There's really no reason to make them mutable:

>>> a = ipaddress.ip_address("10.1.2.3")
>>> b = ipaddress.ip_address("10.1.2.3")
>>> id(a)
140066533772368
>>> id(b)
140066504622544

Especially with IPv6 and large numbers of addresses, it would be helpful not to have separate instances with the same underlying properties.

----------
components: Library (Lib)
messages: 233038
nosy: Seth.Bromberger
priority: normal
severity: normal
status: open
title: ipaddress should be Flyweight
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue Dec 23 12:33:43 2014
From: report at bugs.python.org (=?utf-8?b?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?=)
Date: Tue, 23 Dec 2014 11:33:43 +0000
Subject: [New-bugs-announce] [issue23104] [Windows x86-64] Incorrect
	function call
Message-ID: <1419334423.22.0.551057120801.issue23104@psf.upfronthosting.co.za>


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

To reproduce:

0) Compile attached testlib.c

1) Run the following code:
from __future__ import print_function
from __future__ import unicode_literals

from ctypes import *

testlib = windll.LoadLibrary('testlib')
testfun = testlib.test

class objid(Structure):
    _fields_ = [('bytes', c_ubyte*16)]

print('Calling...')
testfun(objid(), c_wchar_p('test'))
print('Done.')

---

It gives different output for different versions of Python and processor architectures:

>c:\python27\python test.py
Calling...
test
Done.

>c:\python34\python test.py
Calling...
test
Done.

>c:\python27-64\python test.py
Calling...
test
Done.

>c:\python34-64\python test.py
Calling...

Done.

It appears that Python 3.4 on Windows x86-64 generates incorrect function call code.

----------
components: ctypes
files: testlib.c
messages: 233042
nosy: ??????.?????????
priority: normal
severity: normal
status: open
title: [Windows x86-64] Incorrect function call
versions: Python 3.4
Added file: http://bugs.python.org/file37534/testlib.c

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

From report at bugs.python.org  Tue Dec 23 15:38:55 2014
From: report at bugs.python.org (Sworddragon)
Date: Tue, 23 Dec 2014 14:38:55 +0000
Subject: [New-bugs-announce] [issue23105] os.O_SHLOCK and os.O_EXLOCK are
	not available on Linux
Message-ID: <1419345535.42.0.312768269587.issue23105@psf.upfronthosting.co.za>


New submission from Sworddragon:

>From the documentation:

"
os.O_DSYNC
os.O_RSYNC
os.O_SYNC
os.O_NDELAY
os.O_NONBLOCK
os.O_NOCTTY
os.O_SHLOCK
os.O_EXLOCK
os.O_CLOEXEC

    These constants are only available on Unix.
"

But os.O_SHLOCK and os.O_EXLOCK are not available on my system (Linux 3.16.7-ckt1 x86_64):

sworddragon at ubuntu:~$ python3
Python 3.4.2 (default, Dec  4 2014, 09:34:20) 
[GCC 4.9.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.O_SHLOCK
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'O_SHLOCK'
>>> os.O_EXLOCK
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'O_EXLOCK'
>>> exit()

----------
messages: 233048
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: os.O_SHLOCK and os.O_EXLOCK are not available on Linux
versions: Python 3.4

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

From report at bugs.python.org  Wed Dec 24 00:40:45 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Dec 2014 23:40:45 +0000
Subject: [New-bugs-announce] [issue23106] Remove smalltable from set objects
Message-ID: <1419378045.35.0.931278321867.issue23106@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

This tracker item is here to record my efforts to re-evaluate whether we were getting much if any benefit from the smalltable in set objects.

Removing the smalltable special case and instead using a memory allocation had the following effects:

* Nice simplification of the code, greatly improving the clarity of the functions for resizing, clearing, and swapping.

* Reduced the memory consumption for sets that were already using memory allocated tables (saved the memory cost of the unused smalltable).

* Nearly doubled the time to allocate and free set objects (see timings below for CLang and GCC).

As a percentage change, the time penalty seems like a killer, but then we're talking about only 1/10th of a ?sec per set.



# CLANG #########

~/base_cp/python.exe -m timeit -s 'from itertools import repeat, starmap' 'list(starmap(set, repeat((), 250000)))'
10 loops, best of 3: 39.1 msec per loop
~/cpython/python.exe -m timeit -s 'from itertools import repeat, starmap' 'list(starmap(set, repeat((), 250000)))'
10 loops, best of 3: 76.7 msec per loop
~/base_cp/python.exe -m timeit -s 'from itertools import repeat, starmap' 'list(starmap(set, repeat((), 250000)))'
10 loops, best of 3: 38.8 msec per loop
~/cpython/python.exe -m timeit -s 'from itertools import repeat, starmap' 'list(starmap(set, repeat((), 250000)))'
10 loops, best of 3: 76.6 msec per loop

~/base_cp/python.exe -m timeit '{1,2,3}'
10000000 loops, best of 3: 0.0964 usec per loop
~/cpython/python.exe -m timeit '{1,2,3}'
10000000 loops, best of 3: 0.148 usec per loop
~/base_cp/python.exe -m timeit '{1,2,3}'
10000000 loops, best of 3: 0.0964 usec per loop
~/cpython/python.exe -m timeit '{1,2,3}'
10000000 loops, best of 3: 0.149 usec per loop

# GCC-4.9 ########
~/base_cp $ ~/base_cp/python.exe -m timeit '{1,2,3}'
10000000 loops, best of 3: 0.0701 usec per loop
~/base_cp $ ~/cpython/python.exe -m timeit '{1,2,3}'
10000000 loops, best of 3: 0.155 usec per loop
~/base_cp $ ~/base_cp/python.exe -m timeit '{1,2,3}'
10000000 loops, best of 3: 0.0691 usec per loop
~/base_cp $ ~/cpython/python.exe -m timeit '{1,2,3}'
10000000 loops, best of 3: 0.157 usec per loop

~/base_cp $ ~/base_cp/python.exe -m timeit -s 'from itertools import repeat, starmap' 'list(starmap(set, repeat((), 250000)))'
10 loops, best of 3: 34.6 msec per loop
~/base_cp $ ~/cpython/python.exe -m timeit -s 'from itertools import repeat, starmap' 'list(starmap(set, repeat((), 250000)))'
10 loops, best of 3: 77 msec per loop
~/base_cp $ ~/base_cp/python.exe -m timeit -s 'from itertools import repeat, starmap' 'list(starmap(set, repeat((), 250000)))'
10 loops, best of 3: 34.1 msec per loop
~/base_cp $ ~/cpython/python.exe -m timeit -s 'from itertools import repeat, starmap' 'list(starmap(set, repeat((), 250000)))'
10 loops, best of 3: 77.3 msec per loop

----------
assignee: rhettinger
components: Interpreter Core
files: no_smalltable2.diff
keywords: patch
messages: 233068
nosy: rhettinger
priority: low
severity: normal
status: open
title: Remove smalltable from set objects
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file37535/no_smalltable2.diff

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

From report at bugs.python.org  Wed Dec 24 06:52:12 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 24 Dec 2014 05:52:12 +0000
Subject: [New-bugs-announce] [issue23107] Tighten-up search loops in sets
Message-ID: <1419400332.58.0.470390691587.issue23107@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The lookkey functions currently check for an exact key match in the inner search-loop.  Move that test to occur after a matching hash is found rather than testing every entry.  This gives a modest speed improvement.

--- n = 10,000 ---
$ ~/baseline/python.exe -m timeit -s 'from time_tight import s,t,u' 's&t'
1000 loops, best of 3: 396 usec per loop
$ ~/tight/python.exe -m timeit -s 'from time_tight import s,t,u' 's&t'
1000 loops, best of 3: 367 usec per loop
$ ~/tight/python.exe -m timeit -s 'from time_tight import s,t,u' 's&t'
1000 loops, best of 3: 375 usec per loop
$ ~/baseline/python.exe -m timeit -s 'from time_tight import s,t,u' 's&t'
1000 loops, best of 3: 389 usec per loop
$ 
$ ~/baseline/python.exe -m timeit -s 'from time_tight import s,t,u' 's&u'
1000 loops, best of 3: 656 usec per loop
$ ~/tight/python.exe -m timeit -s 'from time_tight import s,t,u' 's&u'
1000 loops, best of 3: 657 usec per loop
$ ~/baseline/python.exe -m timeit -s 'from time_tight import s,t,u' 's&u'
1000 loops, best of 3: 662 usec per loop
$ ~/tight/python.exe -m timeit -s 'from time_tight import s,t,u' 's&u'
1000 loops, best of 3: 642 usec per loop

-- n = 1,000,000 --
$ ~/baseline/python.exe -m timeit -s 'from time_tight import s,t,u' 's&t'
10 loops, best of 3: 67 msec per loop
$ ~/tight/python.exe -m timeit -s 'from time_tight import s,t,u' 's&t'
10 loops, best of 3: 48.2 msec per loop
$ ~/baseline/python.exe -m timeit -s 'from time_tight import s,t,u' 's&t'
10 loops, best of 3: 59.9 msec per loop
$ ~/tight/python.exe -m timeit -s 'from time_tight import s,t,u' 's&t'
10 loops, best of 3: 49.1 msec per loop
 
$ ~/baseline/python.exe -m timeit -s 'from time_tight import s,t,u' 's&u'
10 loops, best of 3: 173 msec per loop
$ ~/tight/python.exe -m timeit -s 'from time_tight import s,t,u' 's&u'
10 loops, best of 3: 152 msec per loop
$ ~/baseline/python.exe -m timeit -s 'from time_tight import s,t,u' 's&u'
10 loops, best of 3: 170 msec per loop
$ ~/tight/python.exe -m timeit -s 'from time_tight import s,t,u' 's&u'
10 loops, best of 3: 167 msec per loop

----------
assignee: rhettinger
components: Interpreter Core
files: tight0.diff
keywords: patch
messages: 233073
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Tighten-up search loops in sets
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file37537/tight0.diff

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

From report at bugs.python.org  Wed Dec 24 11:56:54 2014
From: report at bugs.python.org (Lukas Barth)
Date: Wed, 24 Dec 2014 10:56:54 +0000
Subject: [New-bugs-announce] [issue23108] pysha3 fails with obscure internal
	error
Message-ID: <1419418614.4.0.468641067745.issue23108@psf.upfronthosting.co.za>


New submission from Lukas Barth:

Hi!

Since there is no separate bug tracker for pysha3 (and it is being discussed in some other bug on this tracker), I figured that this is the right place to file this bug. I hope I'm right.

I'm trying to import pysha3, and it fails with the error 

"undefined symbol: _PyUnicode_CheckConsistency"

(full backtrace here: http://pastebin.com/ueXDAwu6 )

I can't find anything useful about this error using Google etc.

I'm using Python 3.3.5 on a current Gentoo Linux. I'm running in a virtualenv, so there should not be too much getting in the way. I basically have Django and pysha3 installed. 

Full output of 'pip freeze': http://pastebin.com/Z7DF96Z0 
Full output of 'python -v': http://pastebin.com/1HeSJJ8p

----------
components: Extension Modules, Interpreter Core
messages: 233075
nosy: tinLoaf
priority: normal
severity: normal
status: open
title: pysha3 fails with obscure internal error
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Wed Dec 24 12:42:35 2014
From: report at bugs.python.org (=?utf-8?q?Cl=C3=A9ment?=)
Date: Wed, 24 Dec 2014 11:42:35 +0000
Subject: [New-bugs-announce] [issue23109] French quotes in the documentation
	are often	ungrammatical
Message-ID: <1419421355.57.0.399831572163.issue23109@psf.upfronthosting.co.za>


New submission from Cl?ment:

>From https://docs.python.org/3/howto/unicode.html:

> For a while people just wrote programs that didn?t display accents.
> In the mid-1980s an Apple II BASIC program written by a French 
> speaker might have lines like these:
> 
> PRINT "FICHIER EST COMPLETE."
> PRINT "CARACTERE NON ACCEPTE."
> 
> Those messages should contain accents (complet?, caract?re, accept?), > and they just look wrong to someone who can read French.

One of the reasons the message looks wrong is that "FICHIER EST COMPLETE" in ungrammatical in French. Google has 16 hits for that query, half of which are from the Python documentation. The second one is better.

I imagine the first one comes from the English "FILE IS COMPLETE", but I'm not even sure what that meant, so it's hard to give a better translation :/ Instead, here are a few examples that could work:

MISE A JOUR TERMINEE (Update completed ? missing ? and ? in termin?e)
VEUILLEZ REDEMARRER (Please reboot ? missing ? in red?marrer)
PARAMETRES ENREGISTRES (Settings saved ? missing ? in param?tre and ? in enregistr?s)

Similarly, https://docs.python.org/3/library/email-examples.html#examples-using-the-provisional-api:

> msg['Subject'] = "Ayons asperges pour le d?jeuner"

I imagine this comes from the English "Let's have asparagus for lunch!", but the translation reads "Possess asparagus for lunch we". A proper idiomatic French version would be "?a te dirait de manger des asperges ? midi?" (Would you like to eat asparagus for lunch?)

Again further on the same page:

> Cela ressemble ? un excellent recipie[1] d?jeuner.

Could this mean "This looks like a delicious lunch recipie?" The typo in recipie would have prevented the machine translation from picking up recipie, which survived in the French version? This currently reads "This look like recipie lunch a excellent". A proper French version (adjusted to have accents) might be "J'ai trouv? une recette sympa: [1]" ("I found a nice recipe: [1]").

Not sure why using French is needed though; English already has a few accented words: a message with subject "R?sum? attached", and body "Here's my r?sum?" would probably work just as well, and might not divert the reader's attention as much.

Side note: in the example P?p? writes to Fabrette and Penelope. Aren't they the same character?

Cl?ment.

----------
assignee: docs at python
components: Documentation
messages: 233076
nosy: cpitcla, docs at python
priority: normal
severity: normal
status: open
title: French quotes in the documentation are often ungrammatical
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Dec 24 17:22:53 2014
From: report at bugs.python.org (Robert Snoeberger)
Date: Wed, 24 Dec 2014 16:22:53 +0000
Subject: [New-bugs-announce] [issue23110] Document if argument to Py_SetPath
	requires static	storage.
Message-ID: <1419438173.5.0.679263724855.issue23110@psf.upfronthosting.co.za>


New submission from Robert Snoeberger:

The documentation for the Py_SetPath API does not indicate if the argument should point to a wide character array in static storage. However, the documentation for Py_GetPath says, "The returned string points into static storage; the caller should not modify its value." This leads me to believe that static storage is required for Py_SetPath.

The documentation for similar API functions, Py_SetPythonHome and Py_SetProgramName, indicates, "The argument should point to a zero-terminated wide character string in static storage whose contents will not change...".

----------
assignee: docs at python
components: Documentation
messages: 233081
nosy: docs at python, snoeberger
priority: normal
severity: normal
status: open
title: Document if argument to Py_SetPath requires static storage.
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Dec 24 22:45:07 2014
From: report at bugs.python.org (varde)
Date: Wed, 24 Dec 2014 21:45:07 +0000
Subject: [New-bugs-announce] [issue23111] ftplib.FTP_TLS's default
	constructor does not work with	TLSv1.1 or TLSv1.2
Message-ID: <1419457507.62.0.0499182915126.issue23111@psf.upfronthosting.co.za>


New submission from varde:

When trying to connect to a server which only supports TLS version 1.1 or 1.2, the following error is raised:
ssl.SSLError: [SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:598)
For some reason, the SSL version is set to ssl.PROTOCOL_TLSv1 before initialisation and an SSL context is created in __init__, making any subsequent change to ssl_version useless.
The only way to establish a successful connection is to pass a custom SSL context to the constructor.
I think ssl_version should be settable at construction time before the context is created.
I'm not sure exposing ssl_version is useful either, the documentation mentions it but it has no use after initialisation.

The following lines should also be changed:
if self.ssl_version == ssl.PROTOCOL_TLSv1:
    resp = self.voidcmd('AUTH TLS')

----------
components: Library (Lib)
messages: 233087
nosy: varde
priority: normal
severity: normal
status: open
title: ftplib.FTP_TLS's default constructor does not work with TLSv1.1 or TLSv1.2
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/issue23111>
_______________________________________

From report at bugs.python.org  Thu Dec 25 12:34:44 2014
From: report at bugs.python.org (Josep Portella Florit)
Date: Thu, 25 Dec 2014 11:34:44 +0000
Subject: [New-bugs-announce] [issue23112] SimpleHTTPServer/http.server adds
	trailing slash after	query string
Message-ID: <1419507284.07.0.378357430215.issue23112@psf.upfronthosting.co.za>


New submission from Josep Portella Florit:

To reproduce:

1) Create directory "foo" in the current directory.
2) Run "python -m SimpleHTTPServer" or "python3 -m http.server".
3A) Point web browser to "http://127.0.0.1:8000/foo/?".
    The request is redirected to "http://127.0.0.1:8000/foo/?/".
    The expected behaviour was no redirection.
3B) Point web browser to "http://127.0.0.1:8000/foo?".
    The request is redirected to "http://127.0.0.1:8000/foo?/".
    The expected behaviour was a redirection to
    "http://127.0.0.1:8000/foo/?".

Reproduced with 2.7.6 and 3.4.0.

----------
components: Library (Lib)
messages: 233095
nosy: jpf
priority: normal
severity: normal
status: open
title: SimpleHTTPServer/http.server adds trailing slash after query string
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Thu Dec 25 18:05:06 2014
From: report at bugs.python.org (John Firestone)
Date: Thu, 25 Dec 2014 17:05:06 +0000
Subject: [New-bugs-announce] [issue23113] Compiler doesn't recognize
	qualified exec('', {})
Message-ID: <1419527106.51.0.659290194447.issue23113@psf.upfronthosting.co.za>


New submission from John Firestone:

Python 2.7.8 (v2.7.8:ee879c0ffa11, Jun 29 2014, 21:07:35) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def outer():
...     def inner(arg):
...         len(arg)
...     exec('', {})
... 
  File "<stdin>", line 4
SyntaxError: unqualified exec is not allowed in function 'outer' it contains a nested function with free variables
>>> 
>>> def outer():
...     def inner(arg):
...         len(arg)
...     exec '' in {}
... 
>>>

----------
components: Interpreter Core
files: bug.py
messages: 233096
nosy: johnf
priority: normal
severity: normal
status: open
title: Compiler doesn't recognize qualified exec('', {})
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file37541/bug.py

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

From report at bugs.python.org  Fri Dec 26 11:30:55 2014
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 26 Dec 2014 10:30:55 +0000
Subject: [New-bugs-announce] [issue23114] "dist must be a Distribution
	instance" check fails with	setuptools
Message-ID: <1419589855.59.0.704259891528.issue23114@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

distutils uses this code to validate the input in "Command.__init__()":

        # late import because of mutual dependence between these classes
        from distutils.dist import Distribution

        if not isinstance(dist, Distribution):
            raise TypeError, "dist must be a Distribution instance"

(Lib/distutils/cmd.py, after line 50)

This fails if the calling code uses the stdlib Distribution type (e.g. with a module global import) but setuptools was only imported afterwards and replaced "distutils.dist.Distribution" with its own implementation. In this case, the above code will get hold of the setuptools implementation and the isinstance() check will fail as both classes are not compatible.

I guess this is a problem more in setuptools than in distutils, but a) this isinstance() check has a general code smell and b) pip and setuptools are automatically installed in a specific (impacted) version in Py2.7.9 and Py3.4, which makes this problem quite pressing for the stdlib side.

----------
components: Distutils
messages: 233104
nosy: dstufft, eric.araujo, scoder
priority: normal
severity: normal
status: open
title: "dist must be a Distribution instance" check fails with setuptools
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Fri Dec 26 17:21:13 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Fri, 26 Dec 2014 16:21:13 +0000
Subject: [New-bugs-announce] [issue23115] Backport #22585 -- getentropy for
	urandom to Python 2.7
Message-ID: <1419610873.69.0.17447907262.issue23115@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

This makes the urandom codebase easier to maintain by allowing porting patches between 2.7 and 3.x easier; it also improves support for the OpenBSD platform.

Support for porting patches is not just a theoretical concern, it's likely that Linux's getrandom() will be supported at some point; like getentropy() it's useful because it's less error prone, and works in chroots and other environments that don't explicitly set up the /dev/urandom device.

----------
components: Library (Lib)
keywords: needs review, patch
messages: 233105
nosy: alex, benjamin.peterson, dstufft
priority: normal
severity: normal
status: open
title: Backport #22585 -- getentropy for urandom to Python 2.7
versions: Python 2.7

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

From report at bugs.python.org  Fri Dec 26 20:42:14 2014
From: report at bugs.python.org (Amy)
Date: Fri, 26 Dec 2014 19:42:14 +0000
Subject: [New-bugs-announce] [issue23116] Python Tutorial 4.7.1: Improve
	ask_ok() to cover more	input values
Message-ID: <1419622934.77.0.489991713093.issue23116@psf.upfronthosting.co.za>


New submission from Amy:

https://docs.python.org/3/tutorial/controlflow.html#default-argument-values
def ask_ok(prompt, retries=4, complaint='Yes or no, please!'):
    while True:
        ok = input(prompt)

Suggestion: change to "ok = input(prompt).lower()" in order to cover values with capitalized characters such as "Yes" or "NO".

----------
messages: 233114
nosy: amyluo
priority: normal
severity: normal
status: open
title: Python Tutorial 4.7.1: Improve ask_ok() to cover more input values
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Dec 27 00:03:04 2014
From: report at bugs.python.org (James Wahlman)
Date: Fri, 26 Dec 2014 23:03:04 +0000
Subject: [New-bugs-announce] [issue23117] Properly codesign Mac python
	2.7.9.pkg so it can work	thru OS X firewall
Message-ID: <1419634984.21.0.96201874002.issue23117@psf.upfronthosting.co.za>


New submission from James Wahlman:

The app is not code signed properly so when using Python 2.7.9 on OS X 10.10 or any version or OS X I imagine when a user enables the built in OS X firewall and runs Python it complains about allowing the app thru the firewall. The only way to fix since it wasn't signed properly was to install command line tools then typing this in terminal:

sudo codesign -f -s - /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app

please sign this app properly so it works without this annoying workaround. Thanks ;)

----------
messages: 233121
nosy: James.Wahlman
priority: normal
severity: normal
status: open
title: Properly codesign Mac python 2.7.9.pkg so it can work thru OS X firewall

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

From report at bugs.python.org  Sat Dec 27 00:04:09 2014
From: report at bugs.python.org (James Wahlman)
Date: Fri, 26 Dec 2014 23:04:09 +0000
Subject: [New-bugs-announce] [issue23118] Properly codesign Mac python
	2.7.9.pkg so it can work	thru OS X firewall
Message-ID: <1419635049.3.0.430313609014.issue23118@psf.upfronthosting.co.za>


New submission from James Wahlman:

The app is not code signed properly so when using Python 2.7.9 on OS X 10.10 or any version of OS X I imagine when a user enables the built in OS X firewall and runs Python it complains about allowing the app thru the firewall. The only way to fix since it wasn't signed properly was to install command line tools then typing this in terminal:

sudo codesign -f -s - /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app

please sign this app properly so it works without this annoying workaround. Thanks ;)

----------
messages: 233122
nosy: James.Wahlman
priority: normal
severity: normal
status: open
title: Properly codesign Mac python 2.7.9.pkg so it can work thru OS X firewall

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

From report at bugs.python.org  Sat Dec 27 11:50:11 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 27 Dec 2014 10:50:11 +0000
Subject: [New-bugs-announce] [issue23119] Remove unicode specialization from
	set objects
Message-ID: <1419677411.19.0.303130627071.issue23119@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

This tracker item is to record experiments with removing unicode specialization code from set objects and run timings to determine the performance benefits or losses from those specializations.

* Removes the set_lookkey_unicode() function and the attendant so->lookup indirections.  That saves 60 lines of code.  On each lookup, it saves one indirection for the lookup dispatch, but in the case of unicode only tables, it costs an additional indirection through the abstract API for PyObject_RichCompareBool.

* Removes the specialization code in add, discard, and contains functions to check for a unicode key with an already computed hash value.  This saves a type check (cheap), a hash field check, and a nine lines of code.  In the cast where the hash value would have already been computed, it costs a call to PyObject_Hash (which has an indirection, but otherwise does the same field test that we are doing).  The working hypothesis is that this specialization code saves only a little in cases where it applies and adds a little to all the cases where it does not apply.  (Note, the use cases for sets are less likely than dicts to be looking up strings whose hash value has already been computed.)

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

Here are some initial timings for the first patch.  It seems to show that intersection benefits slightly and that set creation time is unaffected.

$ ./time_suite.sh 
100000 loops, best of 3: 14.9 usec per loop
100000 loops, best of 3: 15.3 usec per loop
1000000 loops, best of 3: 1.17 usec per loop
1000000 loops, best of 3: 1.13 usec per loop
10000 loops, best of 3: 24.9 usec per loop
10000 loops, best of 3: 24.2 usec per loop

$ ./time_suite.sh 
100000 loops, best of 3: 14.7 usec per loop
100000 loops, best of 3: 14.6 usec per loop
1000000 loops, best of 3: 1.16 usec per loop
1000000 loops, best of 3: 1.07 usec per loop
10000 loops, best of 3: 23.1 usec per loop
10000 loops, best of 3: 23.4 usec per loop

$ ./time_suite.sh 
100000 loops, best of 3: 14.5 usec per loop
100000 loops, best of 3: 14.5 usec per loop
1000000 loops, best of 3: 1.16 usec per loop
1000000 loops, best of 3: 1.17 usec per loop
10000 loops, best of 3: 22.5 usec per loop
10000 loops, best of 3: 22 usec per loop

----------
assignee: rhettinger
components: Interpreter Core
files: one_lookkey.diff
keywords: patch
messages: 233128
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Remove unicode specialization from set objects
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file37547/one_lookkey.diff

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

From report at bugs.python.org  Sat Dec 27 14:38:30 2014
From: report at bugs.python.org (Peter Santoro)
Date: Sat, 27 Dec 2014 13:38:30 +0000
Subject: [New-bugs-announce] [issue23120] installation order of 32bit and
	64bit python seems to	matter
Message-ID: <1419687510.82.0.457945734006.issue23120@psf.upfronthosting.co.za>


New submission from Peter Santoro:

It appears that installation order matters when installing both 32bit and 64bit versions of Python.  If you install the 32bit version first, the 64bit version will uninstall the 32bit version.  Here are the steps I used:

1. Starting point (Windows 7 64bit with latest MS patches):
   Python 3.3.5 32bit (c:\bin32\python33, required for support of older systems that will be upgraded to 3.4.3 when it's available)
   Python 3.4.1 32bit (c:\bin32\python34)
   Python 3.4.1 64bit (c:\bin\python34, included in PATH)
2. Uninstalled
   Python 3.4.1 32bit - ran as expected
   Python 3.4.1 64bit - ran as expected
3. Attempted Install (32bit install before 64bit install)
   Python 3.4.2 32bit (c:\bin32\python34) - ran as expected
   Python 3.4.2 64bit (c:\bin\python34) - install dialog had red warning message at top stating that previous version will be uninstalled; if you continue, the 64bit install deletes the Python 3.4.2 32bit install
4. Work around installation order (64bit install before 32bit install):
   Python 3.4.2 64bit (c:\bin\python34) - ran as expected
   Python 3.4.2 32bit (c:\bin32\python34) - ran as expected

Notes:

I've reported other strange issues with multiple versions of python installed, but they were deemed different than the original reported bug and were not further discussed.  It's quite possible that the combination of python versions installed/uninstalled over time on this system has caused some bad/unexpected/untested state (e.g. Windows registry entries).

----------
components: Installation
messages: 233131
nosy: peter at psantoro.net
priority: normal
severity: normal
status: open
title: installation order of 32bit and 64bit python seems to matter
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Dec 27 16:10:13 2014
From: report at bugs.python.org (Joshua Ellinger)
Date: Sat, 27 Dec 2014 15:10:13 +0000
Subject: [New-bugs-announce] [issue23121] pip.exe breaks if python 2.7.9 is
	installed under	c:\Program Files\Python
Message-ID: <1419693013.55.0.898507304072.issue23121@psf.upfronthosting.co.za>


New submission from Joshua Ellinger:

The problem is that the python path name is quoted if it contains spaces.  The launcher does not remove the extra quotes and fails.

I 'solved' by editing the pip.exe to remove the quotes.

ps - Windows programs are normally installed under c:\Program Files or c:\Program Files (x86).  That should be the default in the installer if possible.

----------
components: Windows
messages: 233133
nosy: joshuaellinger, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pip.exe breaks if python 2.7.9 is installed under c:\Program Files\Python
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Sat Dec 27 16:31:19 2014
From: report at bugs.python.org (Marcel Hellkamp)
Date: Sat, 27 Dec 2014 15:31:19 +0000
Subject: [New-bugs-announce] [issue23122] python@93442 breaks build if
	system Python is 2.6
Message-ID: <1419694279.3.0.364576182532.issue23122@psf.upfronthosting.co.za>


New submission from Marcel Hellkamp:

On CentOS 6.6 the system Python is 2.6. The use to set literals in Parser/adsl.py breaks the build process on these systems. The ./configure should ensure that a compatible version of python is available.

----------
components: Build
messages: 233134
nosy: Marcel.Hellkamp
priority: normal
severity: normal
status: open
title: python at 93442 	breaks build if system Python is 2.6
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Sat Dec 27 18:10:51 2014
From: report at bugs.python.org (Anders Rundgren)
Date: Sat, 27 Dec 2014 17:10:51 +0000
Subject: [New-bugs-announce] [issue23123] Only READ support for Decimal in
	json
Message-ID: <1419700251.42.0.619867786079.issue23123@psf.upfronthosting.co.za>


New submission from Anders Rundgren:

jsonString = '{"t":6,"h":4.50, "g":"text","j":1.40e450}'
jsonObject = json.loads(jsonString, object_pairs_hook=collections.OrderedDict,parse_float=Decimal)
for item in jsonObject:
  print jsonObject[item]
6
4.50
text
1.40E+450

Works as expected.

However, there seems to be no way to get back to the original JSON string as far as I can tell since you have to convert Decimal to str in cls when using json.dumps which adds "" around the arguments

----------
components: Extension Modules
messages: 233139
nosy: anders.rundgren.net at gmail.com
priority: normal
severity: normal
status: open
title: Only READ support for Decimal in json
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Dec 28 02:48:19 2014
From: report at bugs.python.org (Adam Carruthers)
Date: Sun, 28 Dec 2014 01:48:19 +0000
Subject: [New-bugs-announce] [issue23124] Incorrect Integer saving
Message-ID: <1419731299.6.0.137708787639.issue23124@psf.upfronthosting.co.za>


New submission from Adam Carruthers:

255 is 255 -> True           (255).bit_length() -> 8
256 is 256 -> True           (256).bit_length() -> 9
257 is 257 -> False          (257).bit_length() -> 9
^
Will show True if you do it exactly like this because of a quirk.
a = 257
b = 257
a is b -> False

I think you don't want to map variables to integers direct unless they are at or under 8 bits in length.

----------
messages: 233145
nosy: Adam.Carruthers
priority: normal
severity: normal
status: open
title: Incorrect Integer saving
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sun Dec 28 09:50:57 2014
From: report at bugs.python.org (=?utf-8?q?Damien_Mari=C3=A9?=)
Date: Sun, 28 Dec 2014 08:50:57 +0000
Subject: [New-bugs-announce] [issue23125] Link to the nose project obsolete
Message-ID: <1419756657.65.0.513358597735.issue23125@psf.upfronthosting.co.za>


New submission from Damien Mari?:

The Nose project moved from Google Code to Github, the link in the unittest documentation didn't change.

How to reproduce:
- Go to https://docs.python.org/3.5/library/unittest.html 
- Click on nose (in the "See also" section)
- See the Google Code project being moved to github

How to fix:
Replace the link with the readthedocs page ( https://nose.readthedocs.org/en/latest/ ) or the github page

----------
assignee: docs at python
components: Documentation
messages: 233148
nosy: docs at python, mariedam
priority: normal
severity: normal
status: open
title: Link to the nose project obsolete
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Dec 28 17:35:01 2014
From: report at bugs.python.org (Chris Angelico)
Date: Sun, 28 Dec 2014 16:35:01 +0000
Subject: [New-bugs-announce] [issue23126] Add Python hook function to
	replace NameError
Message-ID: <1419784501.24.0.582986414066.issue23126@psf.upfronthosting.co.za>


New submission from Chris Angelico:

Creating an issue to keep track of a patch, but this probably wants to be discussed on python-ideas.

The attached patch allows a Python function to be put into sys.__getglobal__, which then works like __getattr__ but for global names. This allows interactive interpreters to auto-import, for instance:

def try_import(n):
    try: return __import__(n)
    except ImportError: raise NameError("Name %r is not defined"%n)

import sys
sys.__getglobal__ = try_import

----------
components: Interpreter Core
files: nameerror_hook.patch
keywords: patch
messages: 233149
nosy: Rosuav
priority: normal
severity: normal
status: open
title: Add Python hook function to replace NameError
versions: Python 3.5
Added file: http://bugs.python.org/file37551/nameerror_hook.patch

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

From report at bugs.python.org  Mon Dec 29 14:31:07 2014
From: report at bugs.python.org (Bertrand Janin)
Date: Mon, 29 Dec 2014 13:31:07 +0000
Subject: [New-bugs-announce] [issue23127] socket.setsockopt() is still
	broken for multicast TTL	and Loop options
Message-ID: <1419859867.69.0.91970081595.issue23127@psf.upfronthosting.co.za>


New submission from Bertrand Janin:

Since I can't re-open issue 3372, I'm opening a new issue.  socket.setsockopt() still sets an optlen of '4' in the setsockopt() system call for options IP_MULTICAST_TTL and IP_MULTICAST_LOOP.  On OpenBSD, this causes the kernel to hit an error condition and set errno 22 when these options are set:

    socket.error: (22, 'Invalid argument')

According to both FreeBSD and OpenBSD manual pages (see e.g. http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/ip.4), these fields are in fact both 8 bit unsigned, and the manuals suggest the following:

    u_char ttl;	/* range: 0 to 255, default = 1 */ 
    setsockopt(s, IPPROTO_IP, IP_MULTICAST_TTL, &ttl, sizeof(ttl));

The following updated patch for branch "2.7" passes a shorter "optlen" for certain Multicast options, it was tested on OpenBSD, Linux and OSX and was initially proposed by niallo:

diff -r 88de50c1696b Modules/socketmodule.c
--- a/Modules/socketmodule.c    Sun Dec 28 18:51:25 2014 +0200
+++ b/Modules/socketmodule.c    Mon Dec 29 08:27:24 2014 -0500
@@ -1879,26 +1879,29 @@
 static PyObject *
 sock_setsockopt(PySocketSockObject *s, PyObject *args)
 {
     int level;
     int optname;
     int res;
     char *buf;
     int buflen;
     int flag;
 
     if (PyArg_ParseTuple(args, "iii:setsockopt",
                          &level, &optname, &flag)) {
+        buflen = sizeof flag;
+        /* Multicast options take shorter arguments */
+        if (optname == IP_MULTICAST_TTL || optname == IP_MULTICAST_LOOP)
+            buflen = sizeof(u_char);
         buf = (char *) &flag;
-        buflen = sizeof flag;
     }
     else {
         PyErr_Clear();
         if (!PyArg_ParseTuple(args, "iis#:setsockopt",
                               &level, &optname, &buf, &buflen))
             return NULL;
     }
     res = setsockopt(s->sock_fd, level, optname, (void *)buf, buflen);
     if (res < 0)
         return s->errorhandler();
     Py_INCREF(Py_None);
     return Py_None;

----------
components: Library (Lib)
messages: 233174
nosy: tamentis
priority: normal
severity: normal
status: open
title: socket.setsockopt() is still broken for multicast TTL and Loop options
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Mon Dec 29 17:34:22 2014
From: report at bugs.python.org (Philipp Emanuel Weidmann)
Date: Mon, 29 Dec 2014 16:34:22 +0000
Subject: [New-bugs-announce] [issue23128] Key presses are doubled in Tkinter
	dialog invoked from	window close handler (OS X only)
Message-ID: <1419870862.78.0.0503102610416.issue23128@psf.upfronthosting.co.za>


New submission from Philipp Emanuel Weidmann:

Minimal code example:


from Tkinter import Tk
from tkSimpleDialog import askstring

def close_handler():
    askstring('', '')
    root.destroy()

root = Tk()
root.protocol('WM_DELETE_WINDOW', close_handler)
root.mainloop()


Closing the main window brings up the askstring dialog. *When run on OS X* (Yosemite, default Python and Tkinter version), each key press on the dialog's input field is doubled (thus when typing "abc" what will actually be entered is "aabbcc"). On Linux (Python + Tkinter 2.7.8) the problem does not occur. When the dialog is invoked from outside the close handler, the problem does not occur.

This bug is causing a downstream issue in the "quicksafe" system (https://github.com/p-e-w/quicksafe/issues/2).

----------
components: Tkinter
messages: 233177
nosy: pew
priority: normal
severity: normal
status: open
title: Key presses are doubled in Tkinter dialog invoked from window close handler (OS X only)
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Dec 29 18:11:18 2014
From: report at bugs.python.org (Jim Carroll)
Date: Mon, 29 Dec 2014 17:11:18 +0000
Subject: [New-bugs-announce] [issue23129] sqlite3 COMMIT nested in SELECT
	returns unexpected	results
Message-ID: <1419873078.33.0.518262497665.issue23129@psf.upfronthosting.co.za>


New submission from Jim Carroll:

I reported this to the sqlite mailing list, and the comments I received suggested the problem may by the python sqlite connector issue, so I'm opening this as a bug report.

I understand that performing a SELECT and nested COMMIT on the same table is not supported in sqlite, but I would have expected a COMMIT on a separate table would not be a problem.  Some test code in python however reveals that performing the COMMIT disrupts the SELECT statement, and causes duplicate data to be returned.

If this is not a supported operation, would you mind pointing me to the docs so I can understand it better?

Example

#!/usr/bin/env python

import sqlite3 as sq

db = sq.connect(':memory:')

db.execute('CREATE TABLE tbl (col INTEGER)')
db.execute('CREATE TABLE tbl2 (col INTEGER)')
db.executemany('INSERT INTO tbl (col) VALUES (?)', [(0,), (1,), (2,)])
db.commit()

print('count=' + str(db.execute('SELECT count(*) FROM tbl').fetchone()[0]))

# Read and print the values just inserted into tbl
for col in db.execute('SELECT col FROM tbl'):
    print(col)
    db.execute('INSERT INTO tbl2 VALUES (?)', col)
    db.commit()

print('count=' + str(db.execute('SELECT count(*) FROM tbl').fetchone()[0]))


The output we see is:

count=3
(0,)
(1,)
(0,)
(1,)
(2,)
count=3


The expected output was:

count=3
(0,)
(1,)
(2,)
count=3

Tested on Linux:

    sqlite version 3.7.13

    sqlite3 connector version 2.6.0
     
    # uname -a
    Linux hostname 3.16-0.bpo.3-amd64 #1 SMP Debian 
    3.16.5-1~bpo70+1 (2014-11-02) x86_64 GNU/Linux

Also tested on Windows with identical results

     Sqlite version 3.6.21
     Windows 7 Professional, 64-bit

----------
messages: 233178
nosy: jamercee
priority: normal
severity: normal
status: open
title: sqlite3 COMMIT nested in SELECT returns unexpected results
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Dec 30 02:56:34 2014
From: report at bugs.python.org (Guido Vranken)
Date: Tue, 30 Dec 2014 01:56:34 +0000
Subject: [New-bugs-announce] [issue23130] Tools/scripts/ftpmirror.py allows
	overwriting arbitrary	files on filesystem
Message-ID: <1419904594.24.0.782191401639.issue23130@psf.upfronthosting.co.za>


New submission from Guido Vranken:

Tools/scripts/ftpmirror.py does not guard against arbitrary path constructions, and, given a connection to a malicious FTP server (or a man in the middle attack), it is possible that any file on the client's filesystem gets overwritten. Ie,. if we suppose that ftpmirror.py is run from a "base directory" /home/xxx/yyy, file creations can occur outside this base directory, such as in /tmp, /etc, /var, just to give some examples.

I've constructed a partial proof of concept FTP server that demonstrates directory and file creation outside the base directory (the directory the client script was launched from). I understand that most of the files in Tools/scripts/ are legacy applications that have long been deprecated. However, if the maintainers think these applications should be safe nonetheless, I'll be happy to construct and submit a patch that will remediate this issue.

Guido Vranken
Intelworks

----------
components: Demos and Tools
messages: 233189
nosy: Guido
priority: normal
severity: normal
status: open
title: Tools/scripts/ftpmirror.py allows overwriting arbitrary files on filesystem
type: security
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Dec 30 05:21:10 2014
From: report at bugs.python.org (Rosa Maria)
Date: Tue, 30 Dec 2014 04:21:10 +0000
Subject: [New-bugs-announce] [issue23131] saving to file add inexistance
	characters
Message-ID: <1419913270.54.0.105314148927.issue23131@psf.upfronthosting.co.za>


New submission from Rosa Maria:

I make an xml extractor for mexican internet invoices; the extraction is correct, but when save to csv, some numbers has additional numbers that does not exist, for example 5010.000000 is saved as 5010.0000002. As you can see in the print function at line 155.

The problem is in Python 3.4.2 in machines with windows xp, windows 7 and windows 8
It is an small error, but this data is used for Accounting.

Thanks in advance and best regards.
Rosa Maria

----------
components: IO
files: Python_Send.7z
messages: 233190
nosy: Gravitania
priority: normal
severity: normal
status: open
title: saving to file add inexistance characters
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file37559/Python_Send.7z

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

From report at bugs.python.org  Tue Dec 30 10:22:09 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 30 Dec 2014 09:22:09 +0000
Subject: [New-bugs-announce] [issue23132] Faster total_ordering
Message-ID: <1419931329.13.0.970719266671.issue23132@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch makes comparation method generated by the total_ordering decorator faster up to 20%.

Benchmark results:

      Unpatched Patched
a < b   2.46      2.45
b < a   2.48      2.49
a >= b  4.86      4.16
b >= a  5.1       4.16
a <= b  4.93      4.15
b <= a  7.31      5.98
a > b   5.25      4.38
b > a   8.11      7.04

It also adds few additional attributes to generated methods.

----------
components: Library (Lib)
files: total_ordering_faster.patch
keywords: patch
messages: 233196
nosy: ncoghlan, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Faster total_ordering
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file37561/total_ordering_faster.patch

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

From report at bugs.python.org  Tue Dec 30 11:52:49 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 30 Dec 2014 10:52:49 +0000
Subject: [New-bugs-announce] [issue23133] Pickling of ipaddress classes
Message-ID: <1419936769.64.0.614386046628.issue23133@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently ipaddress classes support pickling, but the pickling is not efficient and is implementation depened. Proposed patch makes pickling more compact and implementation agnostic.

----------
components: Library (Lib)
files: ipaddress_pickle.patch
keywords: patch
messages: 233201
nosy: ncoghlan, pmoody, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Pickling of ipaddress classes
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file37564/ipaddress_pickle.patch

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

From report at bugs.python.org  Tue Dec 30 19:04:02 2014
From: report at bugs.python.org (Tomasz Ryczkowski)
Date: Tue, 30 Dec 2014 18:04:02 +0000
Subject: [New-bugs-announce] [issue23134] datetime.strptime at the turn of
	the year
Message-ID: <1419962642.25.0.70032949175.issue23134@psf.upfronthosting.co.za>


New submission from Tomasz Ryczkowski:

I've found wrong behaviour datetime.strptim function at the turn of the year.

I've created datetime object base on the week number (%W), year (%Y) and day of week (%w). The date for Tuesday in the first week in 2015 is wrong:

>>> from datetime import datetime
>>> datetime.strptime('%s %s %s' % (0, 2015, 1), '%W %Y %w').date()
datetime.date(2014, 12, 29) # OK

>>> datetime.strptime('%s %s %s' % (0, 2015, 2), '%W %Y %w').date()
datetime.date(2015, 1, 1) # WRONG !!!

>>> datetime.strptime('%s %s %s' % (0, 2015, 3), '%W %Y %w').date()
datetime.date(2014, 12, 31) # OK

>>> datetime.strptime('%s %s %s' % (0, 2015, 4), '%W %Y %w').date()
datetime.date(2015, 1, 1) # OK

>>> datetime.strptime('%s %s %s' % (0, 2015, 5), '%W %Y %w').date()
datetime.date(2015, 1, 2) # OK

>>> datetime.strptime('%s %s %s' % (0, 2015, 6), '%W %Y %w').date()
datetime.date(2015, 1, 3) # OK

>>> datetime.strptime('%s %s %s' % (0, 2015, 0), '%W %Y %w').date()
datetime.date(2015, 1, 4) # OK

The same error exists in another years.

Link to my post about this on stackoverflow:
http://stackoverflow.com/questions/27708833/why-does-datetime-strptime-get-an-incorrect-date-for-tuesday-in-the-week-0-of

----------
messages: 233213
nosy: torm
priority: normal
severity: normal
status: open
title: datetime.strptime at the turn of the year
type: behavior

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

From report at bugs.python.org  Tue Dec 30 20:10:31 2014
From: report at bugs.python.org (c2621566)
Date: Tue, 30 Dec 2014 19:10:31 +0000
Subject: [New-bugs-announce] [issue23135] import searchpaths as arguments
Message-ID: <1419966631.84.0.639997296504.issue23135@psf.upfronthosting.co.za>


New submission from c2621566:

This patch allows specifying import searchpaths as `-p path` arguments to the interpreter, without touching environment variables.

Avoiding environment variables simplifies a script of mine and is a portable way of swapping module implementation without touching the importing script.

e.g.
# python -p ~/.bin/customlib -p ~/.bin/other script.py
is equivalent to
# PYTHONPATH=~/.bin/customlib:~/.bin/other:$PYTHONPATH python script.py
similarly to
# ghci -i.bin/customlib:.bin/other foo.hs

It is implemented by prepending the arguments to sys.path in Py_Main just after Py_Initialize is called.

----------
components: Interpreter Core
files: main.c.searchpatharg1.diff
keywords: patch
messages: 233216
nosy: c2621566
priority: normal
severity: normal
status: open
title: import searchpaths as arguments
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file37567/main.c.searchpatharg1.diff

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

From report at bugs.python.org  Tue Dec 30 22:04:37 2014
From: report at bugs.python.org (Jim Carroll)
Date: Tue, 30 Dec 2014 21:04:37 +0000
Subject: [New-bugs-announce] [issue23136] BUG in how _strptime() handles
	week 0
Message-ID: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za>


New submission from Jim Carroll:

The following bit of code demonstrates a bug in how _strptime handles week 0. The bug is an edge condition that specifically affects how it handles two days before the first day of the new year

>>> for i in range(7):
...     datetime.strptime('%s %s %s' % (0, 2015, i), '%W %Y %w').date()
... 
datetime.date(2015, 1, 4)
datetime.date(2014, 12, 29)
datetime.date(2015, 1, 1)   # <-- ERROR: should be '2014, 12, 30'
datetime.date(2014, 12, 31)
datetime.date(2015, 1, 1)
datetime.date(2015, 1, 2)
datetime.date(2015, 1, 3)

The issue stems from the fact that calls to _calc_julian_from_U_or_W() can return a -1, which under normal circumstances is invalid. The strptime() function tests and corrects when julian values are -1...but it should not do this when the week_of_year is zero.

The fact that it tests for ONLY -1 is why we see the problem in 2015. The error condition only exists when the first day of the year is exactly two days ahead of the date being tested for.

Patch is attached

----------
components: Library (Lib)
files: patch.txt
messages: 233219
nosy: jamercee
priority: normal
severity: normal
status: open
title: BUG in how _strptime() handles week 0
versions: Python 2.7
Added file: http://bugs.python.org/file37568/patch.txt

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

From report at bugs.python.org  Wed Dec 31 00:49:10 2014
From: report at bugs.python.org (Vinson Lee)
Date: Tue, 30 Dec 2014 23:49:10 +0000
Subject: [New-bugs-announce] [issue23137] Python 2.7.9 test_gdb fails on
	CentOS 7
Message-ID: <1419983350.87.0.850193733351.issue23137@psf.upfronthosting.co.za>


New submission from Vinson Lee:

Python 2.7.9 test_gdb fails on CentOS 7.

$./python Lib/test/regrtest.py -v test_gdb
== CPython 2.7.9 (default, Dec 22 2014, 10:54:52) [GCC 4.8.2 20140120 (Red Hat 4.8.2-16)]
==   Linux-3.10.0-123.13.2.el7.x86_64-x86_64-with-centos-7.0.1406-Core little-endian
==   Python-2.7.9/build/test_python_16739
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)
[1/1] 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 "Python-2.7.9/Lib/test/test_gdb.py", line 476, in test_NULL_instance_dict
    exptype='Foo')
  File "Python-2.7.9/Lib/test/test_gdb.py", line 432, in assertSane
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: 'op at entry=<Foo at remote 0x7ffff7f96710>'
Breakpoint 1 at 0x45d9c0: PyObject_Print. (2 locations)
[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 0x7ffff7f96710>, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329
329	{
#0  PyObject_Print (op=op at entry=<Foo at remote 0x7ffff7f96710>, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329
#1  0x000000000043a38c in file_PyObject_Print (f=0x7ffff7fc3150, f=0x7ffff7fc3150, flags=1, op=<Foo at remote 0x7ffff7f96710>) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=<Foo at remote 0x7ffff7f96710>, f=f at entry=<file at remote 0x7ffff7fc3150>, flags=flags at entry=1) at Objects/fileobject.c:2579
#3  0x00000000004b3bbf in PyEval_EvalFrameEx (f=f at entry=Frame 0x7ffff7f23050, for file <string>, line 6, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1771
#4  0x00000000004b69f8 in PyEval_EvalCodeEx (co=co at entry=0x7ffff7fb4bb0, globals=globals at entry={'foo': <Foo at remote 0x7ffff7f96710>, '__builtins__': <module at remote 0x7ffff7fa1b08>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x7ffff7f9a1f0>, '__doc__': None}, locals=locals at entry={'foo': <Foo at remote 0x7ffff7f96710>, '__builtins__': <module at remote 0x7ffff7fa1b08>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x7ffff7f9a1f0>, '__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:3265
#5  0x00000000004b6b22 in PyEval_EvalCode (co=co at entry=0x7ffff7fb4bb0, globals=globals at entry={'foo': <Foo at remote 0x7ffff7f96710>, '__builtins__': <module at remote 0x7ffff7fa1b08>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x7ffff7f9a1f0>, '__doc__': None}, locals=locals at entry={'foo': <Foo at remote 0x7ffff7f96710>, '__builtins__': <module at remote 0x7ffff7fa1b08>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x7ffff7f9a1f0>, '__doc__': None}) at Python/ceval.c:667
#6  0x00000000004e6d62 in run_mod (arena=0x7f6710, flags=0x7fffffffe310, locals={'foo': <Foo at remote 0x7ffff7f96710>, '__builtins__': <module at remote 0x7ffff7fa1b08>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x7ffff7f9a1f0>, '__doc__': None}, globals={'foo': <Foo at remote 0x7ffff7f96710>, '__builtins__': <module at remote 0x7ffff7fa1b08>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x7ffff7f9a1f0>, '__doc__': None}, filename=0x549f56 "<string>", mod=0x835030) at Python/pythonrun.c:1371
#7  PyRun_StringFlags (flags=0x7fffffffe310, locals={'foo': <Foo at remote 0x7ffff7f96710>, '__builtins__': <module at remote 0x7ffff7fa1b08>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x7ffff7f9a1f0>, '__doc__': None}, globals={'foo': <Foo at remote 0x7ffff7f96710>, '__builtins__': <module at remote 0x7ffff7fa1b08>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x7ffff7f9a1f0>, '__doc__': None}, start=257, str=0x7ef010 "\nclass Foo:\n    pass\nfoo = Foo()\nfoo.an_int = 42\nprint foo\n") at Python/pythonrun.c:1334
#8  PyRun_SimpleStringFlags (command=command at entry=0x7ef010 "\nclass Foo:\n    pass\nfoo = Foo()\nfoo.an_int = 42\nprint foo\n", flags=flags at entry=0x7fffffffe310) at Python/pythonrun.c:975
#9  0x0000000000415548 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:584
#10 0x00007ffff7117af5 in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000414b91 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 "Python-2.7.9/Lib/test/test_gdb.py", line 447, in test_NULL_ob_type
    'set op->ob_type=0')
  File "Python-2.7.9/Lib/test/test_gdb.py", line 432, in assertSane
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: 'op at entry=<unknown at remote 0x807568>'
Breakpoint 1 at 0x45d9c0: PyObject_Print. (2 locations)
[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=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329
329	{
#0  PyObject_Print (op=op at entry=<unknown at remote 0x807568>, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329
#1  0x000000000043a38c in file_PyObject_Print (f=0x7ffff7fc3150, f=0x7ffff7fc3150, flags=1, op=<unknown at remote 0x807568>) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=<unknown at remote 0x807568>, f=f at entry=<file at remote 0x7ffff7fc3150>, flags=flags at entry=1) at Objects/fileobject.c:2579
#3  0x00000000004b3bbf in PyEval_EvalFrameEx (f=f at entry=Frame 0x7ffff7f921f8, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1771
#4  0x00000000004b69f8 in PyEval_EvalCodeEx (co=co at entry=0x7ffff7fb4830, globals=globals at entry={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__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:3265
#5  0x00000000004b6b22 in PyEval_EvalCode (co=co at entry=0x7ffff7fb4830, globals=globals at entry={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00000000004e6d62 in run_mod (arena=0x7f66e0, flags=0x7fffffffe340, locals={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x549f56 "<string>", mod=0x834da8) at Python/pythonrun.c:1371
#7  PyRun_StringFlags (flags=0x7fffffffe340, locals={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}, start=257, str=0x7ef010 "print 42\n") at Python/pythonrun.c:1334
#8  PyRun_SimpleStringFlags (command=command at entry=0x7ef010 "print 42\n", flags=flags at entry=0x7fffffffe340) at Python/pythonrun.c:975
#9  0x0000000000415548 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:584
#10 0x00007ffff7117af5 in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000414b91 in _start ()


======================================================================
FAIL: test_NULL_ptr (test.test_gdb.PrettyPrintTests)
Ensure that a NULL PyObject* is handled gracefully
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Python-2.7.9/Lib/test/test_gdb.py", line 442, 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 "Python-2.7.9/Lib/test/test_gdb.py", line 579, 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 "Python-2.7.9/Lib/test/test_gdb.py", line 586, in test_builtin_method
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: 'op at entry=<built-in method readlines of file object at remote 0x7ffff7fc3150>'
Breakpoint 1 at 0x45d9c0: PyObject_Print. (2 locations)
[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 0x7ffff7fc3150>, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329
329	{
#0  PyObject_Print (op=op at entry=<built-in method readlines of file object at remote 0x7ffff7fc3150>, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329
#1  0x000000000043a38c in file_PyObject_Print (f=0x7ffff7fc3150, f=0x7ffff7fc3150, flags=1, op=<built-in method readlines of file object at remote 0x7ffff7fc3150>) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=<built-in method readlines of file object at remote 0x7ffff7fc3150>, f=f at entry=<file at remote 0x7ffff7fc3150>, flags=flags at entry=1) at Objects/fileobject.c:2579
#3  0x00000000004b3bbf in PyEval_EvalFrameEx (f=f at entry=Frame 0x7ffff7fca200, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1771
#4  0x00000000004b69f8 in PyEval_EvalCodeEx (co=co at entry=0x7ffff7fb4830, globals=globals at entry={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', 'sys': <module at remote 0x7ffff7fa1bb0>, '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', 'sys': <module at remote 0x7ffff7fa1bb0>, '__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:3265
#5  0x00000000004b6b22 in PyEval_EvalCode (co=co at entry=0x7ffff7fb4830, globals=globals at entry={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', 'sys': <module at remote 0x7ffff7fa1bb0>, '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', 'sys': <module at remote 0x7ffff7fa1bb0>, '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00000000004e6d62 in run_mod (arena=0x7f66f0, flags=0x7fffffffe320, locals={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', 'sys': <module at remote 0x7ffff7fa1bb0>, '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', 'sys': <module at remote 0x7ffff7fa1bb0>, '__doc__': None, '__package__': None}, filename=0x549f56 "<string>", mod=0x834e80) at Python/pythonrun.c:1371
#7  PyRun_StringFlags (flags=0x7fffffffe320, locals={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', 'sys': <module at remote 0x7ffff7fa1bb0>, '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', 'sys': <module at remote 0x7ffff7fa1bb0>, '__doc__': None, '__package__': None}, start=257, str=0x7ef010 "import sys; print sys.stdout.readlines\n") at Python/pythonrun.c:1334
#8  PyRun_SimpleStringFlags (command=command at entry=0x7ef010 "import sys; print sys.stdout.readlines\n", flags=flags at entry=0x7fffffffe320) at Python/pythonrun.c:975
#9  0x0000000000415548 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:584
#10 0x00007ffff7117af5 in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000414b91 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 "Python-2.7.9/Lib/test/test_gdb.py", line 486, in test_builtins_help
    msg='Unexpected rendering %r' % gdb_repr)
AssertionError: Unexpected rendering 'op at entry=<_Helper at remote 0x7ffff7eefd90>'

======================================================================
FAIL: test_classic_class (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of classic class instances
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Python-2.7.9/Lib/test/test_gdb.py", line 360, 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 0x7ffff7f96710>'

======================================================================
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 "Python-2.7.9/Lib/test/test_gdb.py", line 453, in test_corrupt_ob_type
    expvalue=42)
  File "Python-2.7.9/Lib/test/test_gdb.py", line 432, in assertSane
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: 'op at entry=<unknown at remote 0x807568>'
Breakpoint 1 at 0x45d9c0: PyObject_Print. (2 locations)
[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=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329
329	{
#0  PyObject_Print (op=op at entry=<unknown at remote 0x807568>, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329
#1  0x000000000043a38c in file_PyObject_Print (f=0x7ffff7fc3150, f=0x7ffff7fc3150, flags=1, op=<unknown at remote 0x807568>) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=<unknown at remote 0x807568>, f=f at entry=<file at remote 0x7ffff7fc3150>, flags=flags at entry=1) at Objects/fileobject.c:2579
#3  0x00000000004b3bbf in PyEval_EvalFrameEx (f=f at entry=Frame 0x7ffff7f921f8, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1771
#4  0x00000000004b69f8 in PyEval_EvalCodeEx (co=co at entry=0x7ffff7fb4830, globals=globals at entry={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__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:3265
#5  0x00000000004b6b22 in PyEval_EvalCode (co=co at entry=0x7ffff7fb4830, globals=globals at entry={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00000000004e6d62 in run_mod (arena=0x7f66e0, flags=0x7fffffffe340, locals={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x549f56 "<string>", mod=0x834da8) at Python/pythonrun.c:1371
#7  PyRun_StringFlags (flags=0x7fffffffe340, locals={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}, start=257, str=0x7ef010 "print 42\n") at Python/pythonrun.c:1334
#8  PyRun_SimpleStringFlags (command=command at entry=0x7ef010 "print 42\n", flags=flags at entry=0x7fffffffe340) at Python/pythonrun.c:975
#9  0x0000000000415548 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:584
#10 0x00007ffff7117af5 in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000414b91 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 "Python-2.7.9/Lib/test/test_gdb.py", line 459, in test_corrupt_tp_flags
    expvalue=42)
  File "Python-2.7.9/Lib/test/test_gdb.py", line 432, in assertSane
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: 'op at entry=<int at remote 0x807568>'
Breakpoint 1 at 0x45d9c0: PyObject_Print. (2 locations)
[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=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329
329	{
#0  PyObject_Print (op=op at entry=<int at remote 0x807568>, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329
#1  0x000000000043a38c in file_PyObject_Print (f=0x7ffff7fc3150, f=0x7ffff7fc3150, flags=1, op=<int at remote 0x807568>) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=<int at remote 0x807568>, f=f at entry=<file at remote 0x7ffff7fc3150>, flags=flags at entry=1) at Objects/fileobject.c:2579
#3  0x00000000004b3bbf in PyEval_EvalFrameEx (f=f at entry=Frame 0x7ffff7f921f8, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1771
#4  0x00000000004b69f8 in PyEval_EvalCodeEx (co=co at entry=0x7ffff7fb4830, globals=globals at entry={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__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:3265
#5  0x00000000004b6b22 in PyEval_EvalCode (co=co at entry=0x7ffff7fb4830, globals=globals at entry={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00000000004e6d62 in run_mod (arena=0x7f66e0, flags=0x7fffffffe340, locals={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x549f56 "<string>", mod=0x834da8) at Python/pythonrun.c:1371
#7  PyRun_StringFlags (flags=0x7fffffffe340, locals={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}, start=257, str=0x7ef010 "print 42\n") at Python/pythonrun.c:1334
#8  PyRun_SimpleStringFlags (command=command at entry=0x7ef010 "print 42\n", flags=flags at entry=0x7fffffffe340) at Python/pythonrun.c:975
#9  0x0000000000415548 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:584
#10 0x00007ffff7117af5 in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000414b91 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 "Python-2.7.9/Lib/test/test_gdb.py", line 465, in test_corrupt_tp_name
    expvalue=42)
  File "Python-2.7.9/Lib/test/test_gdb.py", line 432, in assertSane
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: 'op at entry=<unknown at remote 0x807568>'
Breakpoint 1 at 0x45d9c0: PyObject_Print. (2 locations)
[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=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329
329	{
#0  PyObject_Print (op=op at entry=<unknown at remote 0x807568>, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329
#1  0x000000000043a38c in file_PyObject_Print (f=0x7ffff7fc3150, f=0x7ffff7fc3150, flags=1, op=<unknown at remote 0x807568>) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=<unknown at remote 0x807568>, f=f at entry=<file at remote 0x7ffff7fc3150>, flags=flags at entry=1) at Objects/fileobject.c:2579
#3  0x00000000004b3bbf in PyEval_EvalFrameEx (f=f at entry=Frame 0x7ffff7f921f8, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1771
#4  0x00000000004b69f8 in PyEval_EvalCodeEx (co=co at entry=0x7ffff7fb4830, globals=globals at entry={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__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:3265
#5  0x00000000004b6b22 in PyEval_EvalCode (co=co at entry=0x7ffff7fb4830, globals=globals at entry={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00000000004e6d62 in run_mod (arena=0x7f66e0, flags=0x7fffffffe340, locals={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x549f56 "<string>", mod=0x834da8) at Python/pythonrun.c:1371
#7  PyRun_StringFlags (flags=0x7fffffffe340, locals={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x7ffff7fa1b08>, '__name__': '__main__', '__doc__': None, '__package__': None}, start=257, str=0x7ef010 "print 42\n") at Python/pythonrun.c:1334
#8  PyRun_SimpleStringFlags (command=command at entry=0x7ef010 "print 42\n", flags=flags at entry=0x7fffffffe340) at Python/pythonrun.c:975
#9  0x0000000000415548 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:584
#10 0x00007ffff7117af5 in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000414b91 in _start ()


======================================================================
FAIL: test_dicts (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of dictionaries
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Python-2.7.9/Lib/test/test_gdb.py", line 251, in test_dicts
    self.assertGdbRepr({})
  File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val))
AssertionError: 'op at entry={}' != '{}'

======================================================================
FAIL: test_exceptions (test.test_gdb.PrettyPrintTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Python-2.7.9/Lib/test/test_gdb.py", line 337, 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 "Python-2.7.9/Lib/test/test_gdb.py", line 318, in test_frozensets
    self.assertGdbRepr(frozenset())
  File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val))
AssertionError: 'op at entry=frozenset([])' != 'frozenset([])'

======================================================================
FAIL: test_int (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of various "int" values
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Python-2.7.9/Lib/test/test_gdb.py", line 230, in test_int
    self.assertGdbRepr(42)
  File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val))
AssertionError: 'op at entry=42' != '42'

======================================================================
FAIL: test_lists (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of lists
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Python-2.7.9/Lib/test/test_gdb.py", line 257, in test_lists
    self.assertGdbRepr([])
  File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val))
AssertionError: 'op at entry=[]' != '[]'

======================================================================
FAIL: test_long (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of various "long" values
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Python-2.7.9/Lib/test/test_gdb.py", line 238, in test_long
    self.assertGdbRepr(0L)
  File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val))
AssertionError: 'op at entry=0L' != '0L'

======================================================================
FAIL: test_modern_class (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of new-style class instances
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Python-2.7.9/Lib/test/test_gdb.py", line 372, 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 0x7ffff7f70310>'

======================================================================
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 "Python-2.7.9/Lib/test/test_gdb.py", line 507, 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 "Python-2.7.9/Lib/test/test_gdb.py", line 494, 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 "Python-2.7.9/Lib/test/test_gdb.py", line 533, in test_selfreferential_new_style_instance
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: 'op at entry=<Foo(an_attr=<...>) at remote 0x7ffff7f70310>'
Breakpoint 1 at 0x45d9c0: PyObject_Print. (2 locations)
[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 0x7ffff7f70310>, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329
329	{
#0  PyObject_Print (op=op at entry=<Foo(an_attr=<...>) at remote 0x7ffff7f70310>, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329
#1  0x000000000043a38c in file_PyObject_Print (f=0x7ffff7fc3150, f=0x7ffff7fc3150, flags=1, op=<Foo(an_attr=<...>) at remote 0x7ffff7f70310>) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=<Foo(an_attr=<...>) at remote 0x7ffff7f70310>, f=f at entry=<file at remote 0x7ffff7fc3150>, flags=flags at entry=1) at Objects/fileobject.c:2579
#3  0x00000000004b3bbf in PyEval_EvalFrameEx (f=f at entry=Frame 0x7ffff7f23050, for file <string>, line 6, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1771
#4  0x00000000004b69f8 in PyEval_EvalCodeEx (co=co at entry=0x7ffff7fb4bb0, globals=globals at entry={'foo': <Foo(an_attr=<...>) at remote 0x7ffff7f70310>, '__builtins__': <module at remote 0x7ffff7fa1b08>, '__package__': None, '__name__': '__main__', 'Foo': <type at remote 0x849560>, '__doc__': None}, locals=locals at entry={'foo': <Foo(an_attr=<...>) at remote 0x7ffff7f70310>, '__builtins__': <module at remote 0x7ffff7fa1b08>, '__package__': None, '__name__': '__main__', 'Foo': <type at remote 0x849560>, '__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:3265
#5  0x00000000004b6b22 in PyEval_EvalCode (co=co at entry=0x7ffff7fb4bb0, globals=globals at entry={'foo': <Foo(an_attr=<...>) at remote 0x7ffff7f70310>, '__builtins__': <module at remote 0x7ffff7fa1b08>, '__package__': None, '__name__': '__main__', 'Foo': <type at remote 0x849560>, '__doc__': None}, locals=locals at entry={'foo': <Foo(an_attr=<...>) at remote 0x7ffff7f70310>, '__builtins__': <module at remote 0x7ffff7fa1b08>, '__package__': None, '__name__': '__main__', 'Foo': <type at remote 0x849560>, '__doc__': None}) at Python/ceval.c:667
#6  0x00000000004e6d62 in run_mod (arena=0x7f6710, flags=0x7fffffffe300, locals={'foo': <Foo(an_attr=<...>) at remote 0x7ffff7f70310>, '__builtins__': <module at remote 0x7ffff7fa1b08>, '__package__': None, '__name__': '__main__', 'Foo': <type at remote 0x849560>, '__doc__': None}, globals={'foo': <Foo(an_attr=<...>) at remote 0x7ffff7f70310>, '__builtins__': <module at remote 0x7ffff7fa1b08>, '__package__': None, '__name__': '__main__', 'Foo': <type at remote 0x849560>, '__doc__': None}, filename=0x549f56 "<string>", mod=0x835078) at Python/pythonrun.c:1371
#7  PyRun_StringFlags (flags=0x7fffffffe300, locals={'foo': <Foo(an_attr=<...>) at remote 0x7ffff7f70310>, '__builtins__': <module at remote 0x7ffff7fa1b08>, '__package__': None, '__name__': '__main__', 'Foo': <type at remote 0x849560>, '__doc__': None}, globals={'foo': <Foo(an_attr=<...>) at remote 0x7ffff7f70310>, '__builtins__': <module at remote 0x7ffff7fa1b08>, '__package__': None, '__name__': '__main__', 'Foo': <type at remote 0x849560>, '__doc__': None}, start=257, str=0x7ef010 "\nclass Foo(object):\n    pass\nfoo = Foo()\nfoo.an_attr = foo\nprint foo\n") at Python/pythonrun.c:1334
#8  PyRun_SimpleStringFlags (command=command at entry=0x7ef010 "\nclass Foo(object):\n    pass\nfoo = Foo()\nfoo.an_attr = foo\nprint foo\n", flags=flags at entry=0x7fffffffe300) at Python/pythonrun.c:975
#9  0x0000000000415548 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:584
#10 0x00007ffff7117af5 in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000414b91 in _start ()


======================================================================
FAIL: test_selfreferential_old_style_instance (test.test_gdb.PrettyPrintTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Python-2.7.9/Lib/test/test_gdb.py", line 520, in test_selfreferential_old_style_instance
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: 'op at entry=<Foo(an_attr=<...>) at remote 0x7ffff7f966c8>'
Breakpoint 1 at 0x45d9c0: PyObject_Print. (2 locations)
[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 0x7ffff7f966c8>, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329
329	{
#0  PyObject_Print (op=op at entry=<Foo(an_attr=<...>) at remote 0x7ffff7f966c8>, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329
#1  0x000000000043a38c in file_PyObject_Print (f=0x7ffff7fc3150, f=0x7ffff7fc3150, flags=1, op=<Foo(an_attr=<...>) at remote 0x7ffff7f966c8>) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=<Foo(an_attr=<...>) at remote 0x7ffff7f966c8>, f=f at entry=<file at remote 0x7ffff7fc3150>, flags=flags at entry=1) at Objects/fileobject.c:2579
#3  0x00000000004b3bbf in PyEval_EvalFrameEx (f=f at entry=Frame 0x7ffff7f23050, for file <string>, line 6, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1771
#4  0x00000000004b69f8 in PyEval_EvalCodeEx (co=co at entry=0x7ffff7fb4bb0, globals=globals at entry={'foo': <Foo(an_attr=<...>) at remote 0x7ffff7f966c8>, '__builtins__': <module at remote 0x7ffff7fa1b08>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x7ffff7f9a1f0>, '__doc__': None}, locals=locals at entry={'foo': <Foo(an_attr=<...>) at remote 0x7ffff7f966c8>, '__builtins__': <module at remote 0x7ffff7fa1b08>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x7ffff7f9a1f0>, '__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:3265
#5  0x00000000004b6b22 in PyEval_EvalCode (co=co at entry=0x7ffff7fb4bb0, globals=globals at entry={'foo': <Foo(an_attr=<...>) at remote 0x7ffff7f966c8>, '__builtins__': <module at remote 0x7ffff7fa1b08>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x7ffff7f9a1f0>, '__doc__': None}, locals=locals at entry={'foo': <Foo(an_attr=<...>) at remote 0x7ffff7f966c8>, '__builtins__': <module at remote 0x7ffff7fa1b08>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x7ffff7f9a1f0>, '__doc__': None}) at Python/ceval.c:667
#6  0x00000000004e6d62 in run_mod (arena=0x7f6710, flags=0x7fffffffe300, locals={'foo': <Foo(an_attr=<...>) at remote 0x7ffff7f966c8>, '__builtins__': <module at remote 0x7ffff7fa1b08>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x7ffff7f9a1f0>, '__doc__': None}, globals={'foo': <Foo(an_attr=<...>) at remote 0x7ffff7f966c8>, '__builtins__': <module at remote 0x7ffff7fa1b08>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x7ffff7f9a1f0>, '__doc__': None}, filename=0x549f56 "<string>", mod=0x835030) at Python/pythonrun.c:1371
#7  PyRun_StringFlags (flags=0x7fffffffe300, locals={'foo': <Foo(an_attr=<...>) at remote 0x7ffff7f966c8>, '__builtins__': <module at remote 0x7ffff7fa1b08>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x7ffff7f9a1f0>, '__doc__': None}, globals={'foo': <Foo(an_attr=<...>) at remote 0x7ffff7f966c8>, '__builtins__': <module at remote 0x7ffff7fa1b08>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x7ffff7f9a1f0>, '__doc__': None}, start=257, str=0x7ef010 "\nclass Foo:\n    pass\nfoo = Foo()\nfoo.an_attr = foo\nprint foo\n") at Python/pythonrun.c:1334
#8  PyRun_SimpleStringFlags (command=command at entry=0x7ef010 "\nclass Foo:\n    pass\nfoo = Foo()\nfoo.an_attr = foo\nprint foo\n", flags=flags at entry=0x7fffffffe300) at Python/pythonrun.c:975
#9  0x0000000000415548 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:584
#10 0x00007ffff7117af5 in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000414b91 in _start ()


======================================================================
FAIL: test_sets (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of sets
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Python-2.7.9/Lib/test/test_gdb.py", line 299, in test_sets
    self.assertGdbRepr(set())
  File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val))
AssertionError: 'op at entry=set([])' != 'set([])'

======================================================================
FAIL: test_singletons (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of True, False and None
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Python-2.7.9/Lib/test/test_gdb.py", line 245, in test_singletons
    self.assertGdbRepr(True)
  File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val))
AssertionError: 'op at entry=True' != 'True'

======================================================================
FAIL: test_strings (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of strings
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Python-2.7.9/Lib/test/test_gdb.py", line 262, in test_strings
    self.assertGdbRepr('')
  File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val))
AssertionError: "op at entry=''" != "''"

======================================================================
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 "Python-2.7.9/Lib/test/test_gdb.py", line 385, 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 0x7ffff7f804c8>'

======================================================================
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 "Python-2.7.9/Lib/test/test_gdb.py", line 399, 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 0x7ffff7f8b530>'

======================================================================
FAIL: test_truncation (test.test_gdb.PrettyPrintTests)
Verify that very long output is truncated
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Python-2.7.9/Lib/test/test_gdb.py", line 553, 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 "Python-2.7.9/Lib/test/test_gdb.py", line 269, in test_tuples
    self.assertGdbRepr(tuple())
  File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val))
AssertionError: 'op at entry=()' != '()'

======================================================================
FAIL: test_unicode (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of unicode values
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Python-2.7.9/Lib/test/test_gdb.py", line 276, in test_unicode
    self.assertGdbRepr(u'')
  File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val))
AssertionError: "op at entry=u''" != "u''"

----------------------------------------------------------------------
Ran 45 tests in 8.235s

FAILED (failures=29, skipped=12)
1 test failed:
    test_gdb

----------
components: Tests
messages: 233224
nosy: vlee
priority: normal
severity: normal
status: open
title: Python 2.7.9 test_gdb fails on CentOS 7
versions: Python 2.7

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

From report at bugs.python.org  Wed Dec 31 06:06:29 2014
From: report at bugs.python.org (Christopher Foo)
Date: Wed, 31 Dec 2014 05:06:29 +0000
Subject: [New-bugs-announce] [issue23138] cookiejar parses cookie value as
	int with empty	name-value pair and Expires
Message-ID: <1420002389.34.0.647467472383.issue23138@psf.upfronthosting.co.za>


New submission from Christopher Foo:

Something like "Set-Cookie: ; Expires=Thu, 01 Jan 1970 00:00:10 GMT" causes the resulting cookie.value to be parsed as an int.

I expected either str or None as described in the documentation.

Example evil server:

    try:
        import http.server as http_server
    except ImportError:
        import BaseHTTPServer as http_server


    class MyHandler(http_server.BaseHTTPRequestHandler):
        def do_GET(self):
            self.send_response(200)
            self.send_header('Set-Cookie', '; Expires=Thu, 01 Jan 1970 00:00:10 GMT')
            self.send_header('Set-Cookie', 'good=123.45600')
            self.end_headers()


    def main():
        server = http_server.HTTPServer(('127.0.0.1', 8000), MyHandler)
        server.serve_forever()


    if __name__ == '__main__':
        main()
        

Example innocent client:

    try:
        import http.cookiejar as http_cookiejar
    except ImportError:
        import cookielib as http_cookiejar

    try:
        import urllib.request as urllib_request
    except ImportError:
        import urllib2 as urllib_request
        

    def main():
        cj = http_cookiejar.CookieJar()
        opener = urllib_request.build_opener(urllib_request.HTTPCookieProcessor(cj))
        r = opener.open("http://127.0.0.1:8000/")
        
        print(cj._cookies)

    if __name__ == '__main__':
        main()


The resulting output is:

{'127.0.0.1': {'/': {'expires': Cookie(version=0, name='expires', value=10.0, port=None, port_specified=False, domain='127.0.0.1', domain_specified=False, domain_initial_dot=False, path='/', path_specified=False, secure=False, expires=None, discard=True, comment=None, comment_url=None, rest={}, rfc2109=False), 'good': Cookie(version=0, name='good', value='123.45600', port=None, port_specified=False, domain='127.0.0.1', domain_specified=False, domain_initial_dot=False, path='/', path_specified=False, secure=False, expires=None, discard=True, comment=None, comment_url=None, rest={}, rfc2109=False)}}}

It gives two cookies where the first one contains name='expires', value=10.0 which is unexpected. I expected that either the bad cookie is discarded or it is accepted but the value is always a str (even if it is garbage) or None.

This bug was found in my custom cookie policy where I do len(cookie.value or ''). There is also a reference on StackOverflow but I believe no Python library bug report was filed: http://stackoverflow.com/q/20325571/1524507 . 

This was tested on Python 2.7.8, 3.2.6, 3.3.6, and 3.4.2.

----------
components: Library (Lib)
messages: 233227
nosy: chfoo
priority: normal
severity: normal
status: open
title: cookiejar parses cookie value as int with empty name-value pair and Expires
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Dec 31 10:47:51 2014
From: report at bugs.python.org (Friedrich Spee von Langenfeld)
Date: Wed, 31 Dec 2014 09:47:51 +0000
Subject: [New-bugs-announce] [issue23139] syntax diagram after EBNF
	description?
Message-ID: <1420019271.73.0.760663743856.issue23139@psf.upfronthosting.co.za>


New submission from Friedrich Spee von Langenfeld:

In our full grammar specification (10th chapter of the language reference, https://docs.python.org/3/reference/grammar.html), the grammar of Python is comprehensively notated. What would you think of adding a picture with an equivalent syntax diagram (e. g. produced with the help of http://www.bottlecaps.de/rr/ui) to open a new way of understanding for readers?

----------
assignee: docs at python
components: Documentation
messages: 233236
nosy: Friedrich.Spee.von.Langenfeld, docs at python
priority: normal
severity: normal
status: open
title: syntax diagram after EBNF description?

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

From report at bugs.python.org  Wed Dec 31 10:56:13 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 31 Dec 2014 09:56:13 +0000
Subject: [New-bugs-announce] [issue23140] InvalidStateError on asyncio
	subprocess task cancelled
Message-ID: <1420019773.34.0.176587493323.issue23140@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

The attached test_cancel.py script prints the following error:

Exception in callback SubprocessStreamProtocol.process_exited()
handle: <Handle SubprocessStreamProtocol.process_exited() created at Lib/asyncio/base_subprocess.py:130>
source_traceback: Object created at (most recent call last):
  File "test_cancel.py", line 37, in <module>
    loop.run_until_complete(main_task)
  File "Lib/asyncio/base_events.py", line 286, in run_until_complete
    self.run_forever()
  File "Lib/asyncio/base_events.py", line 258, in run_forever
    self._run_once()
  File "Lib/asyncio/base_events.py", line 1102, in _run_once
    handle._run()
  File "Lib/asyncio/events.py", line 120, in _run
    self._callback(*self._args)
  File "Lib/asyncio/base_subprocess.py", line 146, in _process_exited
    self._call(self._protocol.process_exited)
  File "Lib/asyncio/base_subprocess.py", line 130, in _call
    self._loop.call_soon(cb, *data)
Traceback (most recent call last):
  File "Lib/asyncio/events.py", line 120, in _run
    self._callback(*self._args)
  File "Lib/asyncio/subprocess.py", line 99, in process_exited
    waiter.set_result(returncode)
  File "Lib/asyncio/futures.py", line 338, in set_result
    raise InvalidStateError('{}: {!r}'.format(self._state, self))
asyncio.futures.InvalidStateError: CANCELLED: <Future cancelled created at Lib/asyncio/subprocess.py:126>

----------
components: asyncio
files: test_cancel.py
messages: 233237
nosy: giampaolo.rodola, gvanrossum, haypo, pitrou, xdegaye, yselivanov
priority: normal
severity: normal
status: open
title: InvalidStateError on asyncio subprocess task cancelled
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file37571/test_cancel.py

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

From report at bugs.python.org  Wed Dec 31 13:56:48 2014
From: report at bugs.python.org (Adam Mead)
Date: Wed, 31 Dec 2014 12:56:48 +0000
Subject: [New-bugs-announce] [issue23141] Command line long filename not
	passed correctly
Message-ID: <1420030608.19.0.589524689474.issue23141@psf.upfronthosting.co.za>


New submission from Adam Mead:

Under windows the following code does not pass the LFN to the script. Nor does any other method I've tried (getopts & argparse)

test.py
import sys

print ('Number of arguments:', len(sys.argv), 'arguments.')
print ('Argument List:', str(sys.argv))
for x in range(0, len(sys.argv)):
    print("->" + sys.argv[x])

----------------------------------------
Output with quotes:
H:\bin>test "test lfn.txt"
Number of arguments: 3 arguments.
Argument List: ['H:\\bin\\test.py', ' test', 'lfn.txt']
->H:\bin\test.py
-> test
->lfn.txt

Output when doubling the quotes:
H:\bin>test ""test lfn.txt""
Number of arguments: 2 arguments.
Argument List: ['H:\\bin\\test.py', ' "test lfn.txt"']
->H:\bin\test.py
-> "test lfn.txt"

----------
components: Windows
messages: 233240
nosy: Adam.Mead, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Command line long filename not passed correctly
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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