From report at bugs.python.org  Thu Oct  1 07:31:31 2015
From: report at bugs.python.org (Akira Li)
Date: Thu, 01 Oct 2015 05:31:31 +0000
Subject: [New-bugs-announce] [issue25286] views are not sequences
Message-ID: <1443677491.48.0.268151687155.issue25286@psf.upfronthosting.co.za>


New submission from Akira Li:

The entry for *dict view* in the glossary may be clarified, to avoid
confusion with collection.abc.Sequence i.e., from:

  They are lazy sequences that will see changes in the underlying
  dictionary.

to something like:

  They provide a dynamic view on the dictionary?s entries, which means
  that when the dictionary changes, the view reflects these changes.

See https://mail.python.org/pipermail/python-ideas/2015-October/036682.html

I've attached the corresponding doc patch.

----------
assignee: docs at python
components: Documentation
files: dict-views-glossary.patch
keywords: patch
messages: 251995
nosy: akira, docs at python
priority: normal
severity: normal
status: open
title: views are not sequences
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40638/dict-views-glossary.patch

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

From report at bugs.python.org  Thu Oct  1 08:49:51 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 06:49:51 +0000
Subject: [New-bugs-announce] [issue25287] test_crypt fails on OpenBSD
Message-ID: <1443682191.0.0.229033947807.issue25287@psf.upfronthosting.co.za>


New submission from STINNER Victor:

It looks like crypt.crypt('', crypt.METHOD_CRYPT) returns None. This method must be excluded from crypt.methods. Attached patch should fix the issue, but I didn't try it on OpenBSD.

Python 3.4-3.6 is affect, Python 2.7 is not affect (crypt.methods was introduced in Python 3).

http://buildbot.python.org/all/builders/x86%20OpenBSD%203.5/builds/186/steps/test/logs/stdio

test_saltedcrypt (test.test_crypt.CryptTestCase) ... ERROR

======================================================================
ERROR: test_saltedcrypt (test.test_crypt.CryptTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/python-builds/3.5.borja-openbsd-x86/build/Lib/test/test_crypt.py", line 23, in test_saltedcrypt
    self.assertEqual(len(pw), method.total_size)
TypeError: object of type 'NoneType' has no len()

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

----------
files: crypt_openbsd.patch
keywords: patch
messages: 251998
nosy: haypo
priority: normal
severity: normal
status: open
title: test_crypt fails on OpenBSD
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40639/crypt_openbsd.patch

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

From report at bugs.python.org  Thu Oct  1 11:26:41 2015
From: report at bugs.python.org (Hiroki Kiyohara)
Date: Thu, 01 Oct 2015 09:26:41 +0000
Subject: [New-bugs-announce] [issue25288] readline.py file in current
 directory caused unexpected code execution.
Message-ID: <1443691601.94.0.65090362489.issue25288@psf.upfronthosting.co.za>


New submission from Hiroki Kiyohara:

Running `python` interpreter will import `readline.py` file in current directory.
It causes unexpected code execution.

This problem is reported by 'Japan Vulnerability Notes' as a bug on
Windows version Python http://jvn.jp/jp/JVN49503705/

It says that when we run Windows version python will import `readline.pyd` file in current directory. And it may run unexpected codes with permission assigned to python.exe.

The line causing this problem may be...
https://github.com/python/cpython/blob/2.7/Lib/code.py#L303


Should it be considered as vulnerability of python (or Windows version python)?

----------
messages: 252012
nosy: Hiroki Kiyohara
priority: normal
severity: normal
status: open
title: readline.py file in current directory caused unexpected code execution.
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/issue25288>
_______________________________________

From report at bugs.python.org  Thu Oct  1 14:55:09 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 12:55:09 +0000
Subject: [New-bugs-announce] [issue25289] test_strptime hangs sometimes on
 AMD64 Windows7 SP1 3.x buildbot
Message-ID: <1443704109.85.0.472487491984.issue25289@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The AMD64 Windows7 SP1 3.x buildbot randomly fails. Tests take a lot of time. I don't know if it's a slow hardware/VM, or if the system is very busy. By the way, regrtest is run with -j4 (run 4 tests in parallel).

Example of errors:

http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/6773/steps/test/logs/stdio
---
...
[396/399] test_long -- running: test_lib2to3 (102 sec), test_strptime (54 sec)
[397/399] test_source_encoding -- running: test_lib2to3 (102 sec), test_strptime (54 sec)
running: test_lib2to3 (162 sec), test_strptime (114 sec)
[398/399] test_lib2to3 (205 sec) -- running: test_strptime (159 sec)

command timed out: 3900 seconds without output, attempting to kill
program finished with exit code 1
elapsedTime=4929.577000
---


http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/6783/steps/test/logs/stdio
---
...
[392/399] test_wait3 -- running: test_tools (247 sec), test_strptime (770 sec)
[393/399] test_httplib -- running: test_tools (253 sec), test_strptime (776 sec)
[394/399] test_strtod -- running: test_tools (254 sec), test_strptime (777 sec)
[395/399] test_fork1 -- running: test_tools (255 sec), test_strptime (777 sec)
[396/399] test_xmlrpc -- running: test_tools (263 sec), test_strptime (785 sec)
[397/399] test_multiprocessing_main_handling -- running: test_tools (271 sec), test_strptime (794 sec)
running: test_tools (331 sec), test_strptime (854 sec)
[398/399] test_tools (337 sec) -- running: test_strptime (861 sec)

command timed out: 3900 seconds without output, attempting to kill
program finished with exit code 1
elapsedTime=5068.979000
---

----------
components: Windows
messages: 252025
nosy: haypo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: test_strptime hangs sometimes on AMD64 Windows7 SP1 3.x buildbot
versions: Python 3.6

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

From report at bugs.python.org  Thu Oct  1 16:42:25 2015
From: report at bugs.python.org (Johannes Niediek)
Date: Thu, 01 Oct 2015 14:42:25 +0000
Subject: [New-bugs-announce] [issue25290] csv.reader: minor docstring typo
Message-ID: <1443710545.32.0.660901120379.issue25290@psf.upfronthosting.co.za>


New submission from Johannes Niediek:

docstring ends with colon, should be fullstop.

----------
components: Library (Lib)
files: csvreader_docstring.txt
messages: 252030
nosy: wasserverein
priority: normal
severity: normal
status: open
title: csv.reader: minor docstring typo
type: enhancement
versions: Python 2.7, Python 3.6
Added file: http://bugs.python.org/file40648/csvreader_docstring.txt

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

From report at bugs.python.org  Thu Oct  1 21:57:59 2015
From: report at bugs.python.org (Oleg)
Date: Thu, 01 Oct 2015 19:57:59 +0000
Subject: [New-bugs-announce] [issue25291] better Exception message for
 certain task termination scenario
Message-ID: <1443729479.04.0.835148542508.issue25291@psf.upfronthosting.co.za>


New submission from Oleg:

the weird condition in the code 
causes the task to end with double exception, hard
to understand what really had happened. 

 
producing output like that:


|    i am task..
|    i keep working
|    Exception in callback Task._step()
|    handle: <Handle Task._step()>
|    Traceback (most recent call last):
|      File "/home/http/Python-3.5.0/lib/python3.5/asyncio/tasks.py", line 239, in _step
|        result = coro.send(value)
|    StopIteration
|
|    During handling of the above exception, another exception occurred:
|
|    Traceback (most recent call last):
|      File "/home/http/Python-3.5.0/lib/python3.5/asyncio/events.py", line 125, in _run
|        self._callback(*self._args)
|      File "/home/http/Python-3.5.0/lib/python3.5/asyncio/tasks.py", line 241, in _step
|        self.set_result(exc.value)
|      File "/home/http/Python-3.5.0/lib/python3.5/asyncio/futures.py", line 335, in set_result
|        raise InvalidStateError('{}: {!r}'.format(self._state, self))
|    asyncio.futures.InvalidStateError: FINISHED: <Task finished coro=<task() done, defined at test_aio_exception.py:4> exception=RuntimeError('something bad',)>


it would be good to improve that shutdown procedure 
to pinpoint real reason why and when it got into broken state.

additional info can be found here:
https://groups.google.com/forum/#!topic/python-tulip/-EcYtJXDvSo

----------
components: asyncio
files: test_aio_exception.py
messages: 252049
nosy: gvanrossum, haypo, ovex, yselivanov
priority: normal
severity: normal
status: open
title: better Exception message for certain task termination scenario
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file40650/test_aio_exception.py

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

From report at bugs.python.org  Thu Oct  1 22:06:12 2015
From: report at bugs.python.org (Oleg)
Date: Thu, 01 Oct 2015 20:06:12 +0000
Subject: [New-bugs-announce] [issue25292] ssl socket gets into broken state
 when client exits during handshake
Message-ID: <1443729972.18.0.386386409576.issue25292@psf.upfronthosting.co.za>


New submission from Oleg:

when i run the server in one terminal and the client in another

the server output wold be:

Serving on ('127.0.0.1', 8443)
my transport None
my backlog len 2
my backlog size 4200

that output proves that it is trying to write into socket, 
while there is no transport!

see attached example server+client mini apps.

----------
components: asyncio
files: example_files.tar.gz
messages: 252052
nosy: gvanrossum, haypo, ovex, yselivanov
priority: normal
severity: normal
status: open
title: ssl socket gets into broken state when client exits during handshake
versions: Python 3.5
Added file: http://bugs.python.org/file40652/example_files.tar.gz

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

From report at bugs.python.org  Fri Oct  2 00:09:12 2015
From: report at bugs.python.org (Antony Lee)
Date: Thu, 01 Oct 2015 22:09:12 +0000
Subject: [New-bugs-announce] [issue25293] Hooking Thread/Process
 instantiation in concurrent.futures.
Message-ID: <1443737352.06.0.289026067314.issue25293@psf.upfronthosting.co.za>


New submission from Antony Lee:

http://bugs.python.org/issue21423 and http://bugs.python.org/issue24980 suggest adding an initializer/on_new_thread argument to {Thread,Process}PoolExecutor.  I would like to suggest a more unified API, that would allow not only handling initialization, but also finalization, by adding a {thread,process}_class attribute / constructor argument to {Thread,Process}PoolExecutor, so that one could do:

class MyThread(Thread):
    def run(self):
        initialize()
        try: super().run()
        finally: finalize()

with ThreadPoolExecutor(thread_class=MyThread): ...

Thoughts?

----------
components: Library (Lib)
messages: 252067
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Hooking Thread/Process instantiation in concurrent.futures.
versions: Python 3.6

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

From report at bugs.python.org  Fri Oct  2 04:23:44 2015
From: report at bugs.python.org (Patrick Maupin)
Date: Fri, 02 Oct 2015 02:23:44 +0000
Subject: [New-bugs-announce] [issue25294] Absolute imports fail in some
 cases where relative imports would work
Message-ID: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>


New submission from Patrick Maupin:

PEP 8 recommends absolute imports over relative imports, and section 5.4.2 of the import documentation says that an import will cause a binding to be placed in the imported module's parent's namespace.

However, since (with all current Python versions) this binding is not made until _after_ the module body has been executed, there are cases where relative imports will work fine but absolute imports will fail.  Consider the simple case of these five files:

xyz.py: import x
x/__init__.py:  import x.y
x/y/__init__.py:  import x.y.a
x/y/a/__init__.py:  import x.y.b; foo = x.y.b.foo
x/y/b/__init__.py:  foo = 1

This will fail in a fashion that may be very surprising to the uninitiated.  It will not fail on any of the import statements; rather it will fail with an AttributeError on the assignment statement in x.y.a, because the import of y has not yet finished, so y has not yet been bound into x.

This could conceivably be fixed in the import machinery by performing the binding before performing the exec.  Whether it can be done cleanly, so as not to cause compatibility issues with existing loaders, is a question for core maintainers.

But if it is decided that the current behavior is acceptable, then at a minimum both the PEP 8 and the import documentation should have an explanation of this corner case and how it can be solved with relative imports.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 252078
nosy: Patrick Maupin, docs at python
priority: normal
severity: normal
status: open
title: Absolute imports fail in some cases where relative imports would work
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/issue25294>
_______________________________________

From report at bugs.python.org  Fri Oct  2 05:58:34 2015
From: report at bugs.python.org (Peter Brady)
Date: Fri, 02 Oct 2015 03:58:34 +0000
Subject: [New-bugs-announce] [issue25295] functools.lru_cache raises KeyError
Message-ID: <1443758314.48.0.0379621558494.issue25295@psf.upfronthosting.co.za>


New submission from Peter Brady:

The SymPy project (https://github.com/sympy/sympy) makes heavy use of caching to speed up the creation of symbols and expressions.  If available, we make use of the fastcache library (https://github.com/pbrady/fastcache) - an lru_cache written in C.  Otherwise we use lru_cache provided by functools.  When testing with 3.5, we started to observe `KeyError`s coming from the new lru_cache implementation in _functoolsmodule.c.  There was some discussion on this on the SymPy mailing list here https://groups.google.com/forum/#!topic/sympy/AnwYTJGRBB4.

Here's an example of the failure in the SymPy test suite (Note that this failure does not occur if we use the lru_cache in 3.4 or fastcache or if we use the lru_cache in 3.5 with no size limit)

$ /usr/local/opt/python-3.5/bin/python3
Python 3.5.0 (default, Oct  1 2015, 21:51:43) 
[GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from sympy import test
>>> test("test_frame.py")
============================= test process starts ==============================
executable:         /usr/local/opt/python-3.5/bin/python3  (3.5.0-final-0) [CPython]
architecture:       64-bit
cache:              yes
ground types:       python 
random seed:        7625225
hash randomization: on (PYTHONHASHSEED=2787593824)

sympy/physics/vector/tests/test_frame.py[4] .EE.                          [FAIL]

________________________________________________________________________________
____________ sympy/physics/vector/tests/test_frame.py:test_ang_vel _____________
  File "/home/peter/.local/lib/python3.5/site-packages/sympy/physics/vector/tests/test_frame.py", line 66, in test_ang_vel
    B = A.orientnew('B', 'Axis', [q2, A.x])
  File "/home/peter/.local/lib/python3.5/site-packages/sympy/physics/vector/frame.py", line 640, in orientnew
    newframe.orient(self, rot_type, amounts, rot_order)
  File "/home/peter/.local/lib/python3.5/site-packages/sympy/physics/vector/frame.py", line 523, in orient
    [-axis[1], axis[0], 0]]) * sin(theta) + axis * axis.T)
  File "/home/peter/.local/lib/python3.5/site-packages/sympy/core/cache.py", line 93, in wrapper
    retval = cfunc(*args, **kwargs)
  File "/home/peter/.local/lib/python3.5/site-packages/sympy/core/function.py", line 375, in __new__
    result = super(Function, cls).__new__(cls, *args, **options)
  File "/home/peter/.local/lib/python3.5/site-packages/sympy/core/cache.py", line 93, in wrapper
    retval = cfunc(*args, **kwargs)
  File "/home/peter/.local/lib/python3.5/site-packages/sympy/core/function.py", line 199, in __new__
    evaluated = cls.eval(*args)
  File "/home/peter/.local/lib/python3.5/site-packages/sympy/functions/elementary/trigonometric.py", line 459, in eval
    if arg.could_extract_minus_sign():
  File "/home/peter/.local/lib/python3.5/site-packages/sympy/core/expr.py", line 2047, in could_extract_minus_sign
    negative_self = -self
  File "/home/peter/.local/lib/python3.5/site-packages/sympy/core/expr.py", line 113, in __neg__
    return Mul(S.NegativeOne, self)
  File "/home/peter/.local/lib/python3.5/site-packages/sympy/core/cache.py", line 93, in wrapper
    retval = cfunc(*args, **kwargs)
KeyError: (<class 'sympy.core.mul.Mul'>, 1, B_y, sin(2*q(t)), <class 'sympy.core.assumptions.ManagedProperties'>, <class 'sympy.core.numbers.One'>, <class 'sympy.physics.vector.frame.CoordinateSym'>, sin)
________________________________________________________________________________
______________ sympy/physics/vector/tests/test_frame.py:test_dcm _______________
  File "/home/peter/.local/lib/python3.5/site-packages/sympy/physics/vector/tests/test_frame.py", line 131, in test_dcm
    B = A.orientnew('B', 'Axis', [q2, A.x])
  File "/home/peter/.local/lib/python3.5/site-packages/sympy/physics/vector/frame.py", line 640, in orientnew
    newframe.orient(self, rot_type, amounts, rot_order)
  File "/home/peter/.local/lib/python3.5/site-packages/sympy/physics/vector/frame.py", line 523, in orient
    [-axis[1], axis[0], 0]]) * sin(theta) + axis * axis.T)
  File "/home/peter/.local/lib/python3.5/site-packages/sympy/core/cache.py", line 93, in wrapper
    retval = cfunc(*args, **kwargs)
  File "/home/peter/.local/lib/python3.5/site-packages/sympy/core/function.py", line 375, in __new__
    result = super(Function, cls).__new__(cls, *args, **options)
  File "/home/peter/.local/lib/python3.5/site-packages/sympy/core/cache.py", line 93, in wrapper
    retval = cfunc(*args, **kwargs)
  File "/home/peter/.local/lib/python3.5/site-packages/sympy/core/function.py", line 199, in __new__
    evaluated = cls.eval(*args)
  File "/home/peter/.local/lib/python3.5/site-packages/sympy/functions/elementary/trigonometric.py", line 459, in eval
    if arg.could_extract_minus_sign():
  File "/home/peter/.local/lib/python3.5/site-packages/sympy/core/expr.py", line 2050, in could_extract_minus_sign
    (negative_self).extract_multiplicatively(-1) is not None)
  File "/home/peter/.local/lib/python3.5/site-packages/sympy/core/expr.py", line 1859, in extract_multiplicatively
    quotient = self / c
  File "/home/peter/.local/lib/python3.5/site-packages/sympy/core/decorators.py", line 77, in __sympifyit_wrapper
    return func(a, b)
  File "/home/peter/.local/lib/python3.5/site-packages/sympy/core/decorators.py", line 118, in binary_op_wrapper
    return func(self, other)
  File "/home/peter/.local/lib/python3.5/site-packages/sympy/core/expr.py", line 161, in __div__
    return Mul(self, Pow(other, S.NegativeOne))
  File "/home/peter/.local/lib/python3.5/site-packages/sympy/core/cache.py", line 93, in wrapper
    retval = cfunc(*args, **kwargs)
KeyError: (<class 'sympy.core.mul.Mul'>, B_x, -cos(2*q(t)) + 1, <class 'sympy.core.assumptions.ManagedProperties'>, <class 'sympy.physics.vector.frame.CoordinateSym'>, <class 'sympy.core.add.Add'>)

=========== tests finished: 2 passed, 2 exceptions, in 1.57 seconds ============
DO *NOT* COMMIT!
False
>>> 



Sadly, I don't have a simplified test case to reproduce the error.  I would be happy to try some debugging suggestions.

Thanks,
Peter.

----------
components: Library (Lib)
messages: 252083
nosy: Peter Brady
priority: normal
severity: normal
status: open
title: functools.lru_cache raises KeyError
versions: Python 3.5

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

From report at bugs.python.org  Fri Oct  2 07:27:49 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 02 Oct 2015 05:27:49 +0000
Subject: [New-bugs-announce] [issue25296] Simple End-of-life guide covering
 all unsupported versions
Message-ID: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Katie McLaughlin recently pointed me at PHP's summary page for the End-of-Life dates for their various releases: http://php.net/eol.php

That seems like a useful thing to offer, but we unfortunately don't currently have a great place for this kind of documentation:

- the main docs are version specific, while this kind of page should be version independent
- the update process, access control model and reader experience for python.org is too different from that for the main documentation
- ditto for the wiki
- informational PEPs are closer from an access control perspective, but aren't generated with Sphinx and are still disconnected from the main docs from a reader perspective
- it's off-topic for the developer guide

The "right" answer seems to be setting up a separate "docs" project on hg.python.org to use as the landing page for docs.python.org and for version independent information like this (the redirects already defined as part of PEP 430 should continue to handle unqualified deep links into the Python 2 docs).

I'm not sure how much reconfiguration work such a change would entail, though.

----------
assignee: docs at python
components: Documentation
messages: 252084
nosy: docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: Simple End-of-life guide covering all unsupported versions
type: enhancement

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

From report at bugs.python.org  Fri Oct  2 10:55:13 2015
From: report at bugs.python.org (Alexander)
Date: Fri, 02 Oct 2015 08:55:13 +0000
Subject: [New-bugs-announce] [issue25297] max_help_position is not works in
	argparse library
Message-ID: <1443776113.96.0.923054986589.issue25297@psf.upfronthosting.co.za>


New submission from Alexander:

Hi colleagues I have the code (max_help_position is 2000):

formatter_class=lambda prog: argparse.HelpFormatter(prog, max_help_position=2000)
parser = argparse.ArgumentParser(formatter_class=formatter_class)


subparsers = parser.add_subparsers(title="Commands", metavar="<command>")

cmd_parser = subparsers.add_parser('long_long_long_long_long_long_long',
                                   help='- jksljdalkjda',
                                   formatter_class=formatter_class)

args = parser.parse_args(['-h'])
print args

Result:

we have

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

Commands:
  <command>
    long_long_long_long_long_long_long
                                      - jksljdalkjda
    small                             - descr

instead

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

Commands:
  <command>
    long_long_long_long_long_long_long - jksljdalkjda
    small                              - descr

The code:

class MyFormatter(argparse.HelpFormatter):
    def __init__(self, prog):
        super(MyFormatter, self).__init__(prog, max_help_position=2000, width=2000)
        self._max_help_position = 2000
        self._action_max_length += 4

got same result.

The strings like:

formatter_class = lambda prog: argparse.HelpFormatter(prog,
                  max_help_position=2000, width=2000)

formatter_class = lambda prog: argparse.HelpFormatter(prog,
                  max_help_position=1000, width=2000)

formatter_class = lambda prog: argparse.HelpFormatter(prog,
                  max_help_position=2000, width=1000)

got same result: we always have new line after command.

----------
components: Library (Lib)
messages: 252093
nosy: morden2k
priority: normal
severity: normal
status: open
title: max_help_position is not works in argparse library
versions: Python 2.7

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

From report at bugs.python.org  Fri Oct  2 11:44:52 2015
From: report at bugs.python.org (Nir Soffer)
Date: Fri, 02 Oct 2015 09:44:52 +0000
Subject: [New-bugs-announce] [issue25298] Add lock and rlock weakref tests
Message-ID: <1443779092.42.0.963711560686.issue25298@psf.upfronthosting.co.za>


Changes by Nir Soffer <nirsof at gmail.com>:


----------
components: Tests
files: 0001-Add-lock-rlock-weakref-tests.patch
keywords: patch
nosy: nirs
priority: normal
severity: normal
status: open
title: Add lock and rlock weakref tests
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40655/0001-Add-lock-rlock-weakref-tests.patch

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

From report at bugs.python.org  Fri Oct  2 13:25:46 2015
From: report at bugs.python.org (A. Skrobov)
Date: Fri, 02 Oct 2015 11:25:46 +0000
Subject: [New-bugs-announce] [issue25299] TypeError: __init__() takes at
 least 4 arguments (4 given)
Message-ID: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za>


New submission from A. Skrobov:

Python 2.7.3 (default, Dec 18 2014, 19:10:20) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from argparse import ArgumentParser
>>> parser = ArgumentParser()
>>> parser.add_argument("--foo", help="foo", action='store_const')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/argparse.py", line 1281, in add_argument
    action = action_class(**kwargs)
TypeError: __init__() takes at least 4 arguments (4 given)
>>> 



First, the exception message is entirely unhelpful (you wanted at least 4, you got 4, what's your problem?)

Second, adding "const=None" to the invocation makes it succeed; but,  according to https://docs.python.org/2/library/argparse.html#const this argument defaults to "None", so it shouldn't be necessary to specify it explicitly. Thus, either the documentation or the implementation is wrong.

----------
assignee: docs at python
components: Documentation, Extension Modules
messages: 252106
nosy: A. Skrobov, docs at python
priority: normal
severity: normal
status: open
title: TypeError: __init__() takes at least 4 arguments (4 given)
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Oct  2 14:25:37 2015
From: report at bugs.python.org (Florin Papa)
Date: Fri, 02 Oct 2015 12:25:37 +0000
Subject: [New-bugs-announce] [issue25300] Enable Intel MPX (Memory
	protection Extensions) feature
Message-ID: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>


New submission from Florin Papa:

Hi all,

My name is Florin Papa and I work in the Server Languages Optimizations Team at Intel Corporation.

I would like to submit a patch that enables the use of the Intel MPX (Memory Protection Extensions) feature on Python default and 2.7. Invalid memory access problem is commonly found in C/C++ programs and leads to time consuming debugging, program instability and vulnerability. Many attacks exploit software bugs related to invalid memory access caused by buffer overflow/underflow. Existing set of techniques to avoid such memory bugs represent software only solutions which result in poor protection and performance.

Intel MPX introduces new registers and new instructions that operate on these registers. Some of the registers added are bounds registers which store a pointer?s lower bound and upper bound limits. Whenever the pointer is used, the requested reference is checked against the pointer?s associated bounds, thereby preventing out-of-bound memory access (such as buffer overflows and overruns). Out-of-bounds memory references initiate a #BR exception which can then be handled in an appropriate manner.

MPX technology was introduced on the sixth generation of Intel Core processors, code name SkyLake, the successor to Broadwell microarchitecture (only desktop processor is available on the market, server has not been released). For older generations of Intel processors that do not support MPX, nop?s will be added to the instruction stream [1]. 

MPX enabled builds are only possible using gcc 5.1 and newer [2].

To apply the patch please follow these steps:
hg clone https://hg.python.org/cpython
cd cpython
copy mpx_enable.patch to the current directory
hg import --no-commit mpx_enable.patch
./configure ?with-mpx
make ?j #cores

[1] https://software.intel.com/en-us/articles/introduction-to-intel-memory-protection-extensions
[2] https://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler

Regards,
Florin

----------
components: Extension Modules
files: mpx_enable_3_6.patch
keywords: patch
messages: 252110
nosy: florin.papa
priority: normal
severity: normal
status: open
title: Enable Intel MPX (Memory protection Extensions) feature
type: security
versions: Python 3.6
Added file: http://bugs.python.org/file40657/mpx_enable_3_6.patch

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

From report at bugs.python.org  Fri Oct  2 16:44:42 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 14:44:42 +0000
Subject: [New-bugs-announce] [issue25301] Optimize UTF-8 decoder with error
	handlers
Message-ID: <1443797082.73.0.711354360874.issue25301@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The issue #24870 optimized the ASCII decoder with error handlers:

New changeset 3c430259873e by Victor Stinner in branch 'default':
Issue #24870: Optimize the ASCII decoder for error handlers: surrogateescape,
https://hg.python.org/cpython/rev/3c430259873e

We should also optimize the UTF-8 decoder with error handlers.

I will work on a patch next days.

----------
components: Unicode
messages: 252117
nosy: ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: Optimize UTF-8 decoder with error handlers
type: performance
versions: Python 3.6

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

From report at bugs.python.org  Fri Oct  2 18:04:25 2015
From: report at bugs.python.org (Matt Clarkson)
Date: Fri, 02 Oct 2015 16:04:25 +0000
Subject: [New-bugs-announce] [issue25302] Memory Leaks with Address Sanitizer
Message-ID: <1443801865.56.0.796405543991.issue25302@psf.upfronthosting.co.za>


New submission from Matt Clarkson:

I have the following `main.cpp`

```
#include <Python.h>

int main() {
  Py_Initialize();

  if (!Py_IsInitialized())
    return 1;

  Py_Finalize();

  return 0;
}
```

Compiled with on Arch Linux 4.2.1 gcc 5.2.0 python 3.4.3:

```
g++ -fsanitize=address main.cpp -o main `python-config --includes --ldflags
```

I end up with 424764 byte(s) leaked in 316 allocation(s).

I can suppress the leaks in the following ways:

```
# These are the high level functions that leak (i.e. the *top* of the call stack)
#leak:Py_Initialize
#leak:Py_Finalize
#leak:PyEval_EvalCode

# Low level private functions that leak (i.e. the *bottom* of the call stack)
leak:new_keys_object
leak:type_new
leak:new_dict_with_shared_keys
leak:make_keys_shared
leak:_PyObject_Malloc
leak:PyList_New

# The closest to the leak public functions (i.e. closest to the *top* of the call stack)
#leak:PyUnicode_New
#leak:PyList_New
#leak:PyFrame_New
#leak:PyDict_New
#leak:PyBytes_FromStringAndSize
#leak:PyObject_Call
#leak:PyType_Ready
#leak:PyDict_Merge
#leak:PyDict_SetItemString
#leak:PyEval_EvalFrameEx
```

I read in the `PyInitalize` documentation that circular references, etc might not be freed but 424764 bytes seems a lot just for initializing the Python engine.

I would like to help out solving the memory leaks, if that is possible?

----------
components: Interpreter Core
files: leak.log
messages: 252136
nosy: Matt Clarkson
priority: normal
severity: normal
status: open
title: Memory Leaks with Address Sanitizer
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file40659/leak.log

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

From report at bugs.python.org  Sat Oct  3 02:52:11 2015
From: report at bugs.python.org (Pavel Roskin)
Date: Sat, 03 Oct 2015 00:52:11 +0000
Subject: [New-bugs-announce] [issue25303] py_compile disregards
	PYTHONDONTWRITEBYTECODE and -B
Message-ID: <1443833531.37.0.101836027368.issue25303@psf.upfronthosting.co.za>


New submission from Pavel Roskin:

$ echo "'''Simple script'''" >simple-script
$ PYTHONDONTWRITEBYTECODE=1 python3 -B -m py_compile simple-script
$ ls __pycache__
simple-scriptcpython-35.pyc

py_compile should recognize when the user doesn't want the bytecode to be produced. Otherwise, it's not usable in makefiles for a quick code check.

See also http://stackoverflow.com/questions/4284313/

----------
components: Library (Lib)
messages: 252185
nosy: proski
priority: normal
severity: normal
status: open
title: py_compile disregards PYTHONDONTWRITEBYTECODE and -B
versions: Python 3.5

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

From report at bugs.python.org  Sat Oct  3 17:23:53 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 03 Oct 2015 15:23:53 +0000
Subject: [New-bugs-announce] [issue25304] Add run_coroutine_threadsafe() to
	asyncio
Message-ID: <1443885833.8.0.0767295795531.issue25304@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

This is a placeholder bug to reference the PR: https://github.com/python/asyncio/pull/273 by Vincent Michel.

----------
assignee: gvanrossum
components: asyncio
messages: 252215
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Add run_coroutine_threadsafe() to asyncio
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Oct  3 21:17:18 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Oct 2015 19:17:18 +0000
Subject: [New-bugs-announce] [issue25305] Windows: python opens a popup and
 flood stderr with assertion error on FD error
Message-ID: <1443899838.3.0.138123456513.issue25305@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I compiled Python 3.6 in debug mode on Windows, and I'm trying to run test_regrtest to try to reproduce a bug. The problem is that the test opens a million of popup. Clicking on Ignore is useless, the popup continues to reappear again and again. The stderr is also flooded with "Assertion error ..." with the MSCRT.

I don't understand the usage of this popup and this error message. Python already raises a nice OSError when a FD is invalid.

Can we please always turn these warnings off even in debug mode when calling a MSCRT function protected by _Py_BEGIN_SUPPRESS_IPH/_Py_END_SUPPRESS_IPH?

See also issue #25001 "Make --nowindows argument to regrtest propagate when running with -j".

----------
components: Windows
messages: 252226
nosy: haypo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows: python opens a popup and flood stderr with assertion error on FD error
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Oct  3 21:19:23 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Oct 2015 19:19:23 +0000
Subject: [New-bugs-announce] [issue25306] test_huntrleaks_fd_leak() of
 test_regrtest hangs on Windows
Message-ID: <1443899963.15.0.405890831726.issue25306@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I suspect that the test hangs because of the MSCRT assertion error popup: see issue #25305.

http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/10279/steps/test/logs/stdio

[287/400/1] test_regrtest
Timeout (1:00:00)!
Thread 0x00000d48 (most recent call first):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\subprocess.py", line 1279 in _readerthread
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\threading.py", line 871 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\threading.py", line 923 in _bootstrap_inner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\threading.py", line 891 in _bootstrap

Thread 0x000009b8 (most recent call first):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\threading.py", line 1079 in _wait_for_tstate_lock
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\threading.py", line 1063 in join
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\subprocess.py", line 1308 in _communicate
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\subprocess.py", line 1068 in communicate
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\subprocess.py", line 698 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_regrtest.py", line 395 in run_command
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_regrtest.py", line 417 in run_python
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_regrtest.py", line 524 in run_tests
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_regrtest.py", line 663 in test_huntrleaks_fd_leak
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 600 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 648 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\runner.py", line 176 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1775 in _run_suite
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1809 in run_unittest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 161 in test_runner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 162 in runtest_inner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 115 in runtest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 293 in run_tests_sequential
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 352 in run_tests
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 388 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 429 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 451 in main_in_temp_cwd
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\PCbuild\..\lib\test\regrtest.py", line 39 in <module>

command timed out: 3900 seconds without output

----------
components: Windows
messages: 252228
nosy: haypo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: test_huntrleaks_fd_leak() of test_regrtest hangs on Windows
versions: Python 3.6

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

From report at bugs.python.org  Sat Oct  3 22:58:03 2015
From: report at bugs.python.org (Sworddragon)
Date: Sat, 03 Oct 2015 20:58:03 +0000
Subject: [New-bugs-announce] [issue25307] Enhancing the argparse help output
Message-ID: <1443905883.43.0.512702237453.issue25307@psf.upfronthosting.co.za>


New submission from Sworddragon:

I'm noticing some things on the argparse help output that can maybe enhanced. Here is a testcase that produces an example output:

#!/usr/bin/python3 -BEOObbs
# coding=utf-8
import argparse
arguments = argparse.ArgumentParser()
arguments.add_argument('-t', '--test1', action = 'store_true', help = 'Description1')
arguments.add_argument('--test2', action = 'store_true', help = 'Description2')
arguments.add_argument('-u', '--test3', choices = ['choice1', 'choice2'], help = 'Description3', nargs = '+')
arguments.parse_args()


- A way to automatically indent names or to give the user a way to control the indentation would make them easier to read. For example --test2 is here under a short option but it would be easier to read if it would have an offset to be directly under --test1.
- The line "-u {choice1,choice2} [{choice1,choice2} ...], --test3 {choice1,choice2} [{choice1,choice2} ...]" shows the choices for every name while they are the same. Maybe they can be shortened to be shown only on the last name like "-u, --test3 {choice1,choice2} [{choice1,choice2} ...]".

----------
components: Library (Lib)
messages: 252239
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Enhancing the argparse help output
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Oct  3 23:55:16 2015
From: report at bugs.python.org (Sworddragon)
Date: Sat, 03 Oct 2015 21:55:16 +0000
Subject: [New-bugs-announce] [issue25308] Multiple names can target the same
	namespace
Message-ID: <1443909316.53.0.827518024147.issue25308@psf.upfronthosting.co.za>


New submission from Sworddragon:

In the argparse module I'm noticing that for example an optional argument and a positional argument can target the same namespace. Here is a testcase:

#!/usr/bin/python3 -BEOObbs
# coding=utf-8
import argparse
arguments = argparse.ArgumentParser()
arguments.add_argument('test', action = 'store_true', help = 'Description')
arguments.add_argument('--test', action = 'store_true', help = 'Description')
print(arguments.parse_args())


Maybe if argparse finds out that adding an argument would use the same namespace of an already added argument an exception should be thrown?

----------
components: Library (Lib)
messages: 252245
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Multiple names can target the same namespace
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Oct  4 01:28:41 2015
From: report at bugs.python.org (alex wieder)
Date: Sat, 03 Oct 2015 23:28:41 +0000
Subject: [New-bugs-announce] [issue25309] askopenfilename crashes on XP with
 "Show pop-up description for folder and desktop items" on
Message-ID: <1443914921.38.0.807954520295.issue25309@psf.upfronthosting.co.za>


New submission from alex wieder:

Hi,

This is my first bug report, so please be gentle if I don't stick to protocol correctly. I'm also tired from spending about 8 hours tracking down this problem.

OS Affected: XP SP3 (maybe others as well, and I'm aware that python doesn't support xp anymore, but I have plenty of clients still on it). I suggest that you test this in more recent Windows versions as well.

To reproduce:
- Enable "Show Pop-up description for folder and desktop items" in Explorer->Tools->Folder Options->View.
- Create a small python script that opens the askopenfilename dialog.
- Open any local folder.
- Hover the mouse over some files and wait for the pointer to turn into an hourglass as the system tries to gather information for the pop-up for that file. (pdf's are ideal for this as it takes a few seconds for the pop-up to appear.)
- Once the pointer's an hourglass, double click on the file.

Workaround:
- Disable  "Show Pop-up description for folder and desktop items" in Explorer->Tools->Folder Options->View and the problem goes away.

----------
components: Tkinter, Windows
files: pickfile.py
messages: 252248
nosy: alexwieder, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: askopenfilename crashes on XP with "Show pop-up description for folder and desktop items" on
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file40669/pickfile.py

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

From report at bugs.python.org  Sun Oct  4 03:22:27 2015
From: report at bugs.python.org (Alan Cristhian)
Date: Sun, 04 Oct 2015 01:22:27 +0000
Subject: [New-bugs-announce] [issue25310] End mark argument for
	StreamReader.readline() method
Message-ID: <1443921747.34.0.642955426854.issue25310@psf.upfronthosting.co.za>


New submission from Alan Cristhian:

I use pickle to serialize data. The pickle.dumps() methods sometimes introduce the b"\n" character:

    >>> import pickle
    >>> tuple_with_10 = (10,)
    >>> result = pickle.dumps(tuple_with_10, protocol=4)
    >>> result
    b'\x80\x04\x95\x05\x00\x00\x00\x00\x00\x00\x00K\n\x85\x94.'
    >>> b"\n" in result
    True

The same is true with all protocols.

So, if I read the stream with StreamReader.readline() method and then try to deserialize with pickle.loads(), I got and EOLError because the stream has been cut.

An default argument in the readline() method can solve this issue.

----------
components: asyncio
messages: 252249
nosy: Alan.Cristhian, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: End mark argument for StreamReader.readline() method
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sun Oct  4 19:23:27 2015
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 04 Oct 2015 17:23:27 +0000
Subject: [New-bugs-announce] [issue25311] Add f-string support to tokenize.py
Message-ID: <1443979407.62.0.707305717475.issue25311@psf.upfronthosting.co.za>


New submission from Stefan Krah:

I think tokenize.py needs to be updated to support f-strings.


BTW, the f-string implementation seems to be incredibly robust. Nice work!

----------
components: Library (Lib)
messages: 252274
nosy: eric.smith, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: Add f-string support to tokenize.py
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Sun Oct  4 20:07:08 2015
From: report at bugs.python.org (Tzu-ping Chung)
Date: Sun, 04 Oct 2015 18:07:08 +0000
Subject: [New-bugs-announce] [issue25312] Cryptic error message if incorrect
 spec is set on a callable mock
Message-ID: <1443982028.68.0.922333733292.issue25312@psf.upfronthosting.co.za>


New submission from Tzu-ping Chung:

>>> from unittest import mock
>>> 
>>> class Foo:
...     def __init__(self, val):
...         pass
...     def func(self):
...         pass
... 
>>> class FooMock(mock.Mock):
...     def _get_child_mock(self, **kwargs):
...         return mock.Mock(spec_set=Foo)
... 
>>> mock_foo = FooMock()
>>> mock_foo.func()
<Mock name='mock()' id='4340652632'>
>>> mock_foo.func.mock_calls
[call()]
>>> mock_foo.func.assert_has_calls([mock.call()])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.5/unittest/mock.py", line 824, in assert_has_calls
    ) from cause
AssertionError: Calls not found.
Expected: [call()]
Actual: [call()]


While this code is expected to fail (FooMock.func is set to an incorrect spec), the error message is misleading and does not make any sense.

----------
components: Library (Lib)
messages: 252276
nosy: uranusjr
priority: normal
severity: normal
status: open
title: Cryptic error message if incorrect spec is set on a callable mock
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Oct  4 20:23:48 2015
From: report at bugs.python.org (Mark Roseman)
Date: Sun, 04 Oct 2015 18:23:48 +0000
Subject: [New-bugs-announce] [issue25313] IDLE: gracefully handle themes (or
 keysets, or ...) not present
Message-ID: <1443983028.38.0.330062493222.issue25313@psf.upfronthosting.co.za>


New submission from Mark Roseman:

As a follow-on to #24820, when a particular theme is selected in the configuration files, but that theme is not available, IDLE will print out a bunch of warning messages on console. That can occur for example when using a newer built-in theme in an older version before that theme was added, or if the user highlight config file was modified or removed.

IDLE should be smart enough to recognize that and switch to a default theme, without dumping out console error messages. May alert user to that case with an appropriate error message, e.g. theme xyz not found, using default.

The current workaround in #24820 (when a newer theme is chosen in a new version, explain it may not work in older version but explain how it could be made to) is unfortunately necessary unless a more clever solution for this backwards compatibility issue can be found.

Would apply to keysets, etc. in the same was as themes.

----------
components: IDLE
messages: 252278
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: gracefully handle themes (or keysets, or ...) not present
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Oct  4 23:04:53 2015
From: report at bugs.python.org (Julien Baley)
Date: Sun, 04 Oct 2015 21:04:53 +0000
Subject: [New-bugs-announce] [issue25314] Documentation: argparse's actions
 store_{true, false} default to False/True (undocumented)
Message-ID: <1443992693.14.0.504421256983.issue25314@psf.upfronthosting.co.za>


New submission from Julien Baley:

The documentation of the action `store_const` states that it defaults to None. In turn, the documentation of `store_true` and `store_false` states that "[t]hese are special cases of 'store_const'", suggesting that they would also default to None.

Thankfully, `store_true` defaults to False and `store_false` to True, but this is not documented. That would be useful, as I keep seeing people writing `action='store_true' default=False` and vice-versa.

----------
assignee: docs at python
components: Documentation
files: store_true_false_doc.patch
keywords: patch
messages: 252288
nosy: Julien Baley, docs at python
priority: normal
severity: normal
status: open
title: Documentation: argparse's actions store_{true,false} default to False/True (undocumented)
type: enhancement
Added file: http://bugs.python.org/file40676/store_true_false_doc.patch

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

From report at bugs.python.org  Mon Oct  5 04:03:07 2015
From: report at bugs.python.org (Serge Matveenko (lig))
Date: Mon, 05 Oct 2015 02:03:07 +0000
Subject: [New-bugs-announce] [issue25315] OrderedDict mangled private
	attribute is inaccessible
Message-ID: <1444010587.49.0.504903152106.issue25315@psf.upfronthosting.co.za>


New submission from Serge Matveenko (lig):

Consider this code in Python 3.5.0:

Python 3.5.0 (default, Sep 26 2015, 14:59:25) 
[GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from collections import OrderedDict
>>> class MyDict(OrderedDict):
...     def __setitem__(self, *args, **kwargs):
...         print(self._OrderedDict__root)
...         OrderedDict.__setitem__(self, *args, **kwargs)
... 
>>> md = MyDict({'a': 1})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in __setitem__
AttributeError: 'MyDict' object has no attribute '_OrderedDict__root'


However in Python 3.4:

Python 3.4.2 (default, Jul  9 2015, 17:24:30) 
[GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from collections import OrderedDict
>>> class MyDict(OrderedDict):
...     def __setitem__(self, *args, **kwargs):
...         print(self._OrderedDict__root)
...         OrderedDict.__setitem__(self, *args, **kwargs)
... 
>>> md = MyDict({'a': 1})
<collections._Link object at 0x7f0398a79b88>

----------
components: Library (Lib)
messages: 252296
nosy: Serge Matveenko (lig)
priority: normal
severity: normal
status: open
title: OrderedDict mangled private attribute is inaccessible
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Oct  5 09:19:45 2015
From: report at bugs.python.org (Marius Gedminas)
Date: Mon, 05 Oct 2015 07:19:45 +0000
Subject: [New-bugs-announce] [issue25316] distutils: broken error reporting
	about vcvarsall.bat
Message-ID: <1444029585.13.0.59398621181.issue25316@psf.upfronthosting.co.za>


New submission from Marius Gedminas:

When you try to build a C extension on Windows without having a C compiler, distutils tries to raise DistutilsPlatformError("Unable to find vcvarsall.bat").  However, on Python 3.5, it doesn't do that -- instead it lets a WinError(2 "no such file or directory") from _find_vcvarsall escape.

This breaks packages such as zope.interface that ship optional C modules for faster execution, but would like to work on people's computers even when there is no C compiler.  See https://github.com/zopefoundation/zope.interface/issues/24 for details.

----------
components: Distutils
messages: 252308
nosy: dstufft, eric.araujo, mgedmin
priority: normal
severity: normal
status: open
title: distutils: broken error reporting about vcvarsall.bat
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Oct  5 11:37:57 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Oct 2015 09:37:57 +0000
Subject: [New-bugs-announce] [issue25317] Convert test_
Message-ID: <1444037877.91.0.0285113512794.issue25317@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

A large part of test_tokenize is doctests. Doctests are less powerful than unittests, and error reporting in doctests is less informative than in unittests. Proposed patch converts doctests to unittests.

----------
components: Tests
files: test_tokenize.patch
keywords: patch
messages: 252312
nosy: ezio.melotti, meador.inge, michael.foord, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Convert test_
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40680/test_tokenize.patch

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

From report at bugs.python.org  Mon Oct  5 14:01:28 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Oct 2015 12:01:28 +0000
Subject: [New-bugs-announce] [issue25318] Add _PyBytesWriter API to optimize
	Unicode encoders
Message-ID: <1444046488.88.0.905297361267.issue25318@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch is the first step to optimize Unicode encoders: it adds a _PyBytesWriter API. This API is responsible to use the most efficient buffer depending on the need:

* it's possible to use a small buffer directly allocated on the C stack
* otherwise a Python bytes object is allocated
* it's possible to overallocate the bytes objcet to reduce the number of calls to _PyBytes_Resize()

The patch only adds the new API, don't expect any speed up. I just added a small optimization: the overallocation is disabled in UCS1 encoder (ASCII and Latin1) for the last write.

----------
components: Unicode
messages: 252322
nosy: ezio.melotti, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add _PyBytesWriter API to optimize Unicode encoders
type: performance
versions: Python 3.6

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

From report at bugs.python.org  Mon Oct  5 15:23:23 2015
From: report at bugs.python.org (Nir Soffer)
Date: Mon, 05 Oct 2015 13:23:23 +0000
Subject: [New-bugs-announce] [issue25319] Keep lock type when reseting
	internal locks
Message-ID: <1444051403.68.0.196001867236.issue25319@psf.upfronthosting.co.za>


New submission from Nir Soffer:

When Event._reset_internal_locks was called after fork, it use to
reinitialize its condition without arguments, using RLock instead of
Lock.

----------
components: Library (Lib)
files: 0001-Keep-lock-type-when-reseting-internal-locks.patch
keywords: patch
messages: 252326
nosy: nirs
priority: normal
severity: normal
status: open
title: Keep lock type when reseting internal locks
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40686/0001-Keep-lock-type-when-reseting-internal-locks.patch

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

From report at bugs.python.org  Mon Oct  5 18:43:44 2015
From: report at bugs.python.org (Victor van den Elzen)
Date: Mon, 05 Oct 2015 16:43:44 +0000
Subject: [New-bugs-announce] [issue25320] unittest loader.py TypeError when
 code directory contains a socket
Message-ID: <1444063424.79.0.244583020203.issue25320@psf.upfronthosting.co.za>


New submission from Victor van den Elzen:

Hi, when trying to run tests after upgrading from Python 3.4 to Python 3.5 I encountered the following exception:

Traceback (most recent call last):
  ...
  File "/usr/lib/python3.5/unittest/loader.py", line 341, in discover
    tests = list(self._find_tests(start_dir, pattern))
  File "/usr/lib/python3.5/unittest/loader.py", line 398, in _find_tests
    full_path, pattern, namespace)
TypeError: 'NoneType' object is not iterable

This was caused by a stray socket in my code directory, and the fact that _find_test_path only considers directories and regular files.

I attached a suggested fix that just skips all special files. No tests other than "it works on my machine".

----------
components: Library (Lib)
files: unittest_socket.diff
keywords: patch
messages: 252342
nosy: Victor van den Elzen
priority: normal
severity: normal
status: open
title: unittest loader.py TypeError when code directory contains a socket
versions: Python 3.5
Added file: http://bugs.python.org/file40690/unittest_socket.diff

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

From report at bugs.python.org  Tue Oct  6 07:47:16 2015
From: report at bugs.python.org (Pankaj Sharma)
Date: Tue, 06 Oct 2015 05:47:16 +0000
Subject: [New-bugs-announce] [issue25321] Null Dereference "subname" in
	zipimport.c
Message-ID: <1444110436.55.0.477379741136.issue25321@psf.upfronthosting.co.za>


New submission from Pankaj Sharma:

Hi ,
The issues reported as String NULL dereferecne at line 
Python-2.7.10/Modules/zipimport.c:266 for "subname" which assigned by
get_subname(fullname) at line 264.so there should be check "subname" for NULL and return error,if it is NULL.
the respective patch have been attached ,please review it.
Thanks

----------
components: Library (Lib)
files: Python-2.7.10-zipimport-01.patch
keywords: patch
messages: 252377
nosy: benjamin.peterson, pankaj.s01, twouters
priority: normal
severity: normal
status: open
title: Null Dereference  "subname" in zipimport.c
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file40695/Python-2.7.10-zipimport-01.patch

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

From report at bugs.python.org  Tue Oct  6 11:21:46 2015
From: report at bugs.python.org (Frazer McLean)
Date: Tue, 06 Oct 2015 09:21:46 +0000
Subject: [New-bugs-announce] [issue25322] contextlib.suppress not tested for
	nested usage
Message-ID: <1444123306.69.0.0149294325224.issue25322@psf.upfronthosting.co.za>


New submission from Frazer McLean:

In Lib/test/test_contextlib.py, there is a bug in the nested usage part of the following function:

def test_cm_is_reentrant(self): 
    ignore_exceptions = suppress(Exception) 
    with ignore_exceptions: 
        pass 
    with ignore_exceptions: 
        len(5) 
    with ignore_exceptions: 
        1/0 
        with ignore_exceptions: # Check nested usage 
            len(5)

Specifically, the final 2 lines aren't reached since the exception raised by 1/0 exits the context manager.

----------
components: Tests
messages: 252382
nosy: RazerM, ncoghlan, yselivanov
priority: normal
severity: normal
status: open
title: contextlib.suppress not tested for nested usage
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Oct  6 12:42:51 2015
From: report at bugs.python.org (=?utf-8?q?Rados=C5=82aw_Ejsmont?=)
Date: Tue, 06 Oct 2015 10:42:51 +0000
Subject: [New-bugs-announce] [issue25323] Bus error: 10 when executing
	recursive program
Message-ID: <1444128171.82.0.123240917074.issue25323@psf.upfronthosting.co.za>


New submission from Rados?aw Ejsmont:

When I execute a recursive deep tree reconstruction algorithm (depth ~20000) I am hitting a bus error 10. I have modified the recursion limit accordingly (sys.setrecursionlimit(20000)).

I am running python 2.7.10 on OS X 10.11.

The code I am running is here: https://github.com/rejsmont/nuclearP/blob/master/src/Compact.py

Function that fails is nfill()

Code runs fine on linux python 2.7.3 or 2.7.9

----------
components: Macintosh
messages: 252385
nosy: Rados?aw Ejsmont, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Bus error: 10 when executing recursive program
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Tue Oct  6 17:36:38 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Oct 2015 15:36:38 +0000
Subject: [New-bugs-announce] [issue25324] Importing tokenize modifies token
Message-ID: <1444145798.79.0.176080140328.issue25324@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Importing the tokenize modifies the content of the token module.

>>> import token
>>> len(token.tok_name)
59
>>> import tokenize
>>> len(token.tok_name)
61

Such side effect looks as bad design to me. Either token.tok_name should contain elements needed for tokenize, or tokenize should not modify token.tok_name.

----------
components: Library (Lib)
messages: 252397
nosy: georg.brandl, meador.inge, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Importing tokenize modifies token
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Oct  6 18:39:09 2015
From: report at bugs.python.org (Daniel Blanchard)
Date: Tue, 06 Oct 2015 16:39:09 +0000
Subject: [New-bugs-announce] [issue25325] UTF-16LE, UTF-16BE, UTF-32LE,
 and UTF-32BE encodings don't add/remove BOM on encode/decode
Message-ID: <1444149549.66.0.600836718737.issue25325@psf.upfronthosting.co.za>


New submission from Daniel Blanchard:

As I recently discovered when someone filed a PR on chardet (see https://github.com/chardet/chardet/issues/70), BOMs are handled are not handled correctly by the endian-specific encodings UTF-16LE, UTF-16BE, UTF-32LE, and UTF-32BE, but are by the UTF-16 and UTF-32 encodings.

For example:

>>> 'foo'.encode('utf-16le')
b'f\x00o\x00o\x00'
>>> 'foo'.encode('utf-16')
b'\xff\xfef\x00o\x00o\x00'

You can see that when using UTF-16 (instead of UTF-16LE), you get the BOM correctly prepended to the bytes.

If you were on a little endian system and purposefully wanted to create a UTF-16BE file, the only way to do it is:

>>> codecs.BOM_UTF16_BE + 'foo'.encode('utf-16be')
b'\xfe\xff\x00f\x00o\x00o'

This doesn't make a lot of sense to me.  Why is the BOM not prepended automatically when encoding with UTF-16BE?

Furthermore, if you were given a UTF-16BE file on a little endian system, you might think that this would be the correct way to decode it:

>>> (codecs.BOM_UTF16_BE + 'foo'.encode('utf-16be')).decode('utf-16be')
'\ufefffoo'

but as you can see that leaves the BOM on there.  Strangely, decoding with UTF-16 works fine however:

>>> (codecs.BOM_UTF16_BE + 'foo'.encode('utf-16be')).decode('utf-16')
'foo'

It seems to me that the endian-specific versions of UTF-16 and UTF-32 should be adding/removing the appropriate BOMs, and this is a long-standing bug.

----------
components: Unicode
messages: 252406
nosy: Daniel.Blanchard, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: UTF-16LE, UTF-16BE, UTF-32LE, and UTF-32BE encodings don't add/remove BOM on encode/decode
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/issue25325>
_______________________________________

From report at bugs.python.org  Tue Oct  6 18:43:41 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 06 Oct 2015 16:43:41 +0000
Subject: [New-bugs-announce] [issue25326] Improve error message for
	"character buffer objects"
Message-ID: <1444149821.04.0.208726317161.issue25326@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
components: Interpreter Core
files: better_error_message.diff
keywords: patch
nosy: rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: Improve error message for "character buffer objects"
versions: Python 2.7
Added file: http://bugs.python.org/file40702/better_error_message.diff

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

From report at bugs.python.org  Tue Oct  6 21:15:29 2015
From: report at bugs.python.org (Max Farrell)
Date: Tue, 06 Oct 2015 19:15:29 +0000
Subject: [New-bugs-announce] [issue25327] Windows 10 Installation Fails With
 Corrupt Directory Error
Message-ID: <1444158929.17.0.958529864841.issue25327@psf.upfronthosting.co.za>


New submission from Max Farrell:

Cannot install Python 3.5 64-bit on Windows 10 64-bit Educational Edition.

I have Python 3.4 Installed.

Log include.

----------
components: Installation
files: Python 3.5.0 (64-bit)_20151006150920.log
messages: 252423
nosy: Max Farrell
priority: normal
severity: normal
status: open
title: Windows 10 Installation Fails With Corrupt Directory Error
type: compile error
versions: Python 3.5
Added file: http://bugs.python.org/file40705/Python 3.5.0 (64-bit)_20151006150920.log

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

From report at bugs.python.org  Tue Oct  6 21:59:27 2015
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 06 Oct 2015 19:59:27 +0000
Subject: [New-bugs-announce] [issue25328] ValueError in smtpd.py __init__()
	is not raised
Message-ID: <1444161567.94.0.721141385253.issue25328@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

In Python 3.5, SMTPChannel.__init__() ensures that enable_SMTPUTF8 and decode_data arguments are not both true.  This even seems to be tested in test_smtpd.py.  But it's clearly bogus because the exception is never raised!  It just creates and throws away the exception instance.

----------
messages: 252426
nosy: barry, r.david.murray
priority: normal
severity: normal
status: open
title: ValueError in smtpd.py __init__() is not raised
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Oct  6 22:41:01 2015
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 06 Oct 2015 20:41:01 +0000
Subject: [New-bugs-announce] [issue25329] test_json crashes with stack
	overflow on Windows
Message-ID: <1444164061.67.0.762118597604.issue25329@psf.upfronthosting.co.za>


New submission from Zachary Ware:

See for example:

http://buildbot.python.org/all/builders/AMD64%20Windows8.1%20Non-Debug%203.4/builds/224

Possibly related to #25222.

----------
components: Tests, Windows
messages: 252432
nosy: ezio.melotti, haypo, paul.moore, pitrou, rhettinger, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: test_json crashes with stack overflow on Windows
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Oct  7 05:06:14 2015
From: report at bugs.python.org (Antony Lee)
Date: Wed, 07 Oct 2015 03:06:14 +0000
Subject: [New-bugs-announce] [issue25330] Two issues with pkgutil.get_data
Message-ID: <1444187174.4.0.432847594977.issue25330@psf.upfronthosting.co.za>


New submission from Antony Lee:

The docs of pkgutil.get_data say "The resource argument should be in the form of a relative filename, using / as the path separator. The parent directory name .. is not allowed, and nor is a rooted name (starting with a /)."

In fact (on Python 3.5 at least):
* pkgutil.get_data("logging", "/__init__.py") works, but simply chops off the first slash, returning the contents of the stdlib's logging/__init__.py.
* pkgutil.get_data("logging", "../re.py") works, returning the contents of the stdlib's re.py.

People who actually thought about the implications of get_data/zipimport/etc. can decide whether to remove this functionality or to update the docs, I'm just reporting it.

Also, it would be nice if get_data gained a "text mode" (i.e. returning str instead of bytes and with support for universal newlines).

----------
components: Library (Lib)
messages: 252450
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Two issues with pkgutil.get_data
versions: Python 3.6

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

From report at bugs.python.org  Wed Oct  7 12:36:38 2015
From: report at bugs.python.org (Laura Creighton)
Date: Wed, 07 Oct 2015 10:36:38 +0000
Subject: [New-bugs-announce] [issue25331]
 https://docs.python.org/3.5/using/windows.html should list whcih windows
 service packs are
Message-ID: <1444214198.22.0.92198325395.issue25331@psf.upfronthosting.co.za>


New submission from Laura Creighton:

https://docs.python.org/3.5/using/windows.html should list which
windows service packs are needed to install Python.  Could somebody knowledgable please add this information.

----------
assignee: docs at python
components: Documentation, Windows
messages: 252460
nosy: docs at python, lac, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: https://docs.python.org/3.5/using/windows.html should list whcih windows service packs are

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

From report at bugs.python.org  Wed Oct  7 12:48:40 2015
From: report at bugs.python.org (raghu prasad)
Date: Wed, 07 Oct 2015 10:48:40 +0000
Subject: [New-bugs-announce] [issue25332] [Errno 10035] A non-blocking
 socket operation could not be completed immediately on python 3.1.2
Message-ID: <1444214920.55.0.915956514334.issue25332@psf.upfronthosting.co.za>


New submission from raghu prasad:

On one machine we are facing this issue 

[Errno 10035] A non-blocking socket operation could not be completed immediately

We are using urllib.request.urlopen with some timeout value

sample code 

getRequest = urllib.request.Request(getUrl)
                   getRequest.add_header("SessionID", sessID)
                   if (compName != None):
                       getRequest.add_header("ServerContent",compName)
                       getRequest.add_header("Content-
                   getReqResp = urllib.request.urlopen(getRequest, xmlContent , TIME_OUT)

every time we do urlopen for get and post operations we are receiving this 10035 error 

i have searched a lot over the web for any work arounds 

i found one place where the issue got fixed in python 2.7 
https://hg.python.org/cpython/rev/8ec39bfd1f01

i have checked the changes , but the same chages are not visible in the python 3.1.2

so is it a bug or is there any workaround

we are having an issue based in this in our project

so any input / resolution will be greatly helpful

----------
components: Windows
messages: 252463
nosy: paul.moore, raghu prasad, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: [Errno 10035] A non-blocking socket operation could not be completed immediately  on python 3.1.2
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Oct  7 14:58:52 2015
From: report at bugs.python.org (Rodrigo Souto)
Date: Wed, 07 Oct 2015 12:58:52 +0000
Subject: [New-bugs-announce] [issue25333] .1 + .2 == .3 should be True
Message-ID: <1444222732.46.0.826515110458.issue25333@psf.upfronthosting.co.za>


New submission from Rodrigo Souto:

print(.1 + .2 == .3)  should be True like the others

>>> print(.1 + .2 == .3)
False
>>> print(.1 + .3 == .4)
True
>>> print(.1 + .4 == .5)
True
>>> print(.1 + .1 == .2)
True

----------
messages: 252470
nosy: Rodrigo Souto
priority: normal
severity: normal
status: open
title: .1 + .2 == .3 should be True
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Oct  7 15:17:10 2015
From: report at bugs.python.org (Michael Walle)
Date: Wed, 07 Oct 2015 13:17:10 +0000
Subject: [New-bugs-announce] [issue25334] telnetlib: process_rawq() and
	binary data
Message-ID: <1444223830.96.0.970501650084.issue25334@psf.upfronthosting.co.za>


New submission from Michael Walle:

The process_rawq() discards '\x00' and '\x11' bytes.

At least the '\x00' byte is specified by the standard as a No-Op. So this is standard conform according to RFC 854. But there is also the binary transmission mode for telnet (RFC 856). If I want to support this mode I have to receive these all bytes (just IACs are handled special) and I don't see a possibility to achieve this other that overwriting the process_rawq() method, which essentially means copying it and remove/replace the "if c == theNULL" etc checks. IMHO this is bad, because i copy a 64 lines method, just to modify two lines :(

I'd propose to move these checks to a new method, which then can be overwritten. See attached file for example.

----------
components: Library (Lib)
files: telnetlib.diff
keywords: patch
messages: 252472
nosy: mwalle
priority: normal
severity: normal
status: open
title: telnetlib: process_rawq() and binary data
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/file40710/telnetlib.diff

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

From report at bugs.python.org  Wed Oct  7 17:25:19 2015
From: report at bugs.python.org (Scott Turner)
Date: Wed, 07 Oct 2015 15:25:19 +0000
Subject: [New-bugs-announce] [issue25335] ast.literal_eval fails to parse
	numbers with leading "+"
Message-ID: <1444231519.35.0.84058018345.issue25335@psf.upfronthosting.co.za>


New submission from Scott Turner:

import ast
  ast.literal_eval("+3")
  Traceback (most recent call last):
  [...]
  ValueError: malformed string

----------
messages: 252476
nosy: Scott Turner
priority: normal
severity: normal
status: open
title: ast.literal_eval fails to parse numbers with leading "+"
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct  8 02:25:12 2015
From: report at bugs.python.org (CM)
Date: Thu, 08 Oct 2015 00:25:12 +0000
Subject: [New-bugs-announce] [issue25336] Segmentation fault on Mavericks
 consistent crashing of software: Please HELP!!!!!
Message-ID: <1444263912.5.0.0566907258707.issue25336@psf.upfronthosting.co.za>


New submission from CM:

Process:         Python [556]
Path:            /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
Identifier:      Python
Version:         2.7.10 (2.7.10)
Code Type:       X86-64 (Native)
Parent Process:  bash [510]
Responsible:     X11.bin [452]
User ID:         502

Date/Time:       2015-10-07 17:01:32.979 -0700
OS Version:      Mac OS X 10.9.5 (13F1096)
Report Version:  11
Anonymous UUID:  34110EFA-E539-3790-15F7-F5AE427C092E

Sleep/Wake UUID: 1444CE38-3698-4FDA-95B9-196B28CB372E

Crashed Thread:  2

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000

VM Regions Near 0:
--> 
    __TEXT                 000000010802b000-000000010802d000 [    8K] r-x/rwx SM=COW  /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python

Thread 0:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fff8d24f716 __psynch_cvwait + 10
1   libsystem_pthread.dylib       	0x00007fff9185dc3b _pthread_cond_wait + 727
2   org.python.python             	0x0000000108118f51 PyThread_acquire_lock + 145
3   org.python.python             	0x00000001080dc74e PyEval_RestoreThread + 62
4   org.python.python             	0x0000000108104f6d PyGILState_Ensure + 93
5   _gtk.so                       	0x0000000108ec4b36 pygtk_main_watch_check + 50
6   libglib-2.0.0.dylib           	0x0000000108c9efc0 g_main_context_check + 362
7   libglib-2.0.0.dylib           	0x0000000108c9f4ba g_main_context_iterate + 388
8   libglib-2.0.0.dylib           	0x0000000108c9f714 g_main_loop_run + 195
9   libgtk-x11-2.0.0.dylib        	0x000000010918b5db gtk_main + 180
10  _gtk.so                       	0x0000000108e7d0ec _wrap_gtk_main + 241
11  org.python.python             	0x00000001080e1003 PyEval_EvalFrameEx + 15539
12  org.python.python             	0x00000001080dd0dd PyEval_EvalCodeEx + 1725
13  org.python.python             	0x00000001080e4c89 fast_function + 297
14  org.python.python             	0x00000001080e04f5 PyEval_EvalFrameEx + 12709
15  org.python.python             	0x00000001080dd0dd PyEval_EvalCodeEx + 1725
16  org.python.python             	0x00000001080e4c89 fast_function + 297
17  org.python.python             	0x00000001080e04f5 PyEval_EvalFrameEx + 12709
18  org.python.python             	0x00000001080dd0dd PyEval_EvalCodeEx + 1725
19  org.python.python             	0x00000001080e4c89 fast_function + 297
20  org.python.python             	0x00000001080e04f5 PyEval_EvalFrameEx + 12709
21  org.python.python             	0x00000001080dd0dd PyEval_EvalCodeEx + 1725
22  org.python.python             	0x00000001080dca16 PyEval_EvalCode + 54
23  org.python.python             	0x0000000108106774 PyRun_FileExFlags + 164
24  org.python.python             	0x00000001081062f1 PyRun_SimpleFileExFlags + 769
25  org.python.python             	0x000000010811c05e Py_Main + 3070
26  libdyld.dylib                 	0x00007fff8f24c5fd start + 1

Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0   libsystem_kernel.dylib        	0x00007fff8d250662 kevent64 + 10
1   libdispatch.dylib             	0x00007fff90e99421 _dispatch_mgr_invoke + 239
2   libdispatch.dylib             	0x00007fff90e99136 _dispatch_mgr_thread + 52

Thread 2 Crashed:
0   org.python.python             	0x00000001080853af PyObject_Malloc + 79
1   org.python.python             	0x0000000108082222 _PyObject_New + 18
2   org.python.python             	0x000000010811e082 thread_PyThread_allocate_lock + 18
3   org.python.python             	0x00000001080e1003 PyEval_EvalFrameEx + 15539
4   org.python.python             	0x00000001080dd0dd PyEval_EvalCodeEx + 1725
5   org.python.python             	0x00000001080e4c89 fast_function + 297
6   org.python.python             	0x00000001080e04f5 PyEval_EvalFrameEx + 12709
7   org.python.python             	0x00000001080dd0dd PyEval_EvalCodeEx + 1725
8   org.python.python             	0x00000001080e4c89 fast_function + 297
9   org.python.python             	0x00000001080e04f5 PyEval_EvalFrameEx + 12709
10  org.python.python             	0x00000001080dd0dd PyEval_EvalCodeEx + 1725
11  org.python.python             	0x00000001080e4c89 fast_function + 297
12  org.python.python             	0x00000001080e04f5 PyEval_EvalFrameEx + 12709
13  org.python.python             	0x00000001080dd0dd PyEval_EvalCodeEx + 1725
14  org.python.python             	0x0000000108068b4c function_call + 364
15  org.python.python             	0x0000000108042fa3 PyObject_Call + 99
16  org.python.python             	0x00000001080e081d PyEval_EvalFrameEx + 13517
17  org.python.python             	0x00000001080dd0dd PyEval_EvalCodeEx + 1725
18  org.python.python             	0x0000000108068b4c function_call + 364
19  org.python.python             	0x0000000108042fa3 PyObject_Call + 99
20  org.python.python             	0x00000001080e081d PyEval_EvalFrameEx + 13517
21  org.python.python             	0x00000001080dd0dd PyEval_EvalCodeEx + 1725
22  org.python.python             	0x0000000108068b4c function_call + 364
23  org.python.python             	0x0000000108042fa3 PyObject_Call + 99
24  org.python.python             	0x00000001080e081d PyEval_EvalFrameEx + 13517
25  org.python.python             	0x00000001080dd0dd PyEval_EvalCodeEx + 1725
26  org.python.python             	0x0000000108068b4c function_call + 364
27  org.python.python             	0x0000000108042fa3 PyObject_Call + 99
28  org.python.python             	0x0000000108050296 instancemethod_call + 182
29  org.python.python             	0x0000000108042fa3 PyObject_Call + 99
30  org.python.python             	0x000000010804310b PyObject_CallFunction + 251
31  liboof2common.dylib           	0x00000001087df7fa switchboard_notify(OOFMessage const&) + 74
32  liboof2common.dylib           	0x00000001087e218f Progress::start() + 127
33  liboof2common.dylib           	0x00000001087e2442 DefiniteProgress::setFraction(double) + 66
34  progresscmodule.so            	0x000000010891c0ee _wrap_Progress_setFraction(_object*, _object*) + 174
35  org.python.python             	0x0000000108042fa3 PyObject_Call + 99
36  org.python.python             	0x00000001080e43ed PyEval_CallObjectWithKeywords + 93
37  org.python.python             	0x00000001080d8550 builtin_apply + 240
38  org.python.python             	0x00000001080e2356 PyEval_EvalFrameEx + 20486
39  org.python.python             	0x00000001080dd0dd PyEval_EvalCodeEx + 1725
40  org.python.python             	0x00000001080e4c89 fast_function + 297
41  org.python.python             	0x00000001080e04f5 PyEval_EvalFrameEx + 12709
42  org.python.python             	0x00000001080dd0dd PyEval_EvalCodeEx + 1725
43  org.python.python             	0x0000000108068b4c function_call + 364
44  org.python.python             	0x0000000108042fa3 PyObject_Call + 99
45  org.python.python             	0x00000001080e081d PyEval_EvalFrameEx + 13517
46  org.python.python             	0x00000001080e4c22 fast_function + 194
47  org.python.python             	0x00000001080e04f5 PyEval_EvalFrameEx + 12709
48  org.python.python             	0x00000001080e4c22 fast_function + 194
49  org.python.python             	0x00000001080e04f5 PyEval_EvalFrameEx + 12709
50  org.python.python             	0x00000001080e4c22 fast_function + 194
51  org.python.python             	0x00000001080e04f5 PyEval_EvalFrameEx + 12709
52  org.python.python             	0x00000001080e4c22 fast_function + 194
53  org.python.python             	0x00000001080e04f5 PyEval_EvalFrameEx + 12709
54  org.python.python             	0x00000001080dd0dd PyEval_EvalCodeEx + 1725
55  org.python.python             	0x0000000108068b4c function_call + 364
56  org.python.python             	0x0000000108042fa3 PyObject_Call + 99
57  org.python.python             	0x0000000108050296 instancemethod_call + 182
58  org.python.python             	0x0000000108042fa3 PyObject_Call + 99
59  org.python.python             	0x000000010809da35 slot_tp_call + 133
60  org.python.python             	0x0000000108042fa3 PyObject_Call + 99
61  org.python.python             	0x00000001080e11bd PyEval_EvalFrameEx + 15981
62  org.python.python             	0x00000001080e4c22 fast_function + 194
63  org.python.python             	0x00000001080e04f5 PyEval_EvalFrameEx + 12709
64  org.python.python             	0x00000001080e4c22 fast_function + 194
65  org.python.python             	0x00000001080e04f5 PyEval_EvalFrameEx + 12709
66  org.python.python             	0x00000001080e4c22 fast_function + 194
67  org.python.python             	0x00000001080e04f5 PyEval_EvalFrameEx + 12709
68  org.python.python             	0x00000001080e4c22 fast_function + 194
69  org.python.python             	0x00000001080e04f5 PyEval_EvalFrameEx + 12709
70  org.python.python             	0x00000001080dd0dd PyEval_EvalCodeEx + 1725
71  org.python.python             	0x0000000108068b4c function_call + 364
72  org.python.python             	0x0000000108042fa3 PyObject_Call + 99
73  org.python.python             	0x00000001080e081d PyEval_EvalFrameEx + 13517
74  org.python.python             	0x00000001080e4c22 fast_function + 194
75  org.python.python             	0x00000001080e04f5 PyEval_EvalFrameEx + 12709
76  org.python.python             	0x00000001080e4c22 fast_function + 194
77  org.python.python             	0x00000001080e04f5 PyEval_EvalFrameEx + 12709
78  org.python.python             	0x00000001080dd0dd PyEval_EvalCodeEx + 1725
79  org.python.python             	0x0000000108068b4c function_call + 364
80  org.python.python             	0x0000000108042fa3 PyObject_Call + 99
81  org.python.python             	0x0000000108050296 instancemethod_call + 182
82  org.python.python             	0x0000000108042fa3 PyObject_Call + 99
83  org.python.python             	0x00000001080e43ed PyEval_CallObjectWithKeywords + 93
84  org.python.python             	0x000000010811e256 t_bootstrap + 70
85  libsystem_pthread.dylib       	0x00007fff9185b899 _pthread_body + 138
86  libsystem_pthread.dylib       	0x00007fff9185b72a _pthread_start + 137
87  libsystem_pthread.dylib       	0x00007fff9185ffc9 thread_start + 13

Thread 2 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000  rbx: 0x0000000000000020  rcx: 0x000000016af90000  rdx: 0x000000016db04000
  rdi: 0x0000000000000020  rsi: 0x0000000108172ab0  rbp: 0x000000010efb30d0  rsp: 0x000000010efb30a0
   r8: 0x0000000000000000   r9: 0x00007fc2d980b800  r10: 0x00007fc2e01359d0  r11: 0x00007fc2dde57cf0
  r12: 0x00000001080e3c14  r13: 0x0000000000000000  r14: 0x0000000000000003  r15: 0x0000000000000006
  rip: 0x00000001080853af  rfl: 0x0000000000010203  cr2: 0x0000000000000000
  
Logical CPU:     2
Error Code:      0x00000004
Trap Number:     14


Binary Images:
       0x10802b000 -        0x10802cfff +org.python.python (2.7.10 - 2.7.10) <B64E4514-32FA-3ED8-8797-DB9A1C2274CD> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
       0x108035000 -        0x10815dff7 +org.python.python (2.7.10, [c] 2001-2015 Python Software Foundation. - 2.7.10) <A6AFCBF1-A82D-3C49-944C-F7B4699E5491> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Python
       0x1083ca000 -        0x1083ccfff +_locale.so (0) <78AC65A6-C0C7-370B-9A9B-B8D873B5B925> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_locale.so
       0x1083d0000 -        0x1083d9fff +libintl.8.dylib (0) <BAA669D6-5AAD-37C1-9289-DFBCD79B7102> /opt/local/lib/libintl.8.dylib
       0x1083de000 -        0x1084d1ff7 +libiconv.2.dylib (0) <103D57C8-BE15-3BF8-BDBE-53EDBDD0B6A4> /opt/local/lib/libiconv.2.dylib
       0x1084de000 -        0x1084e2ff7 +math.so (0) <B88183F8-C1EB-398B-B544-8CB37355F781> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/math.so
       0x108529000 -        0x10852cff7 +strop.so (0) <BEE2A4BB-D98F-3CE3-BDCB-B09C9AA1D43A> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/strop.so
       0x108531000 -        0x108534fff +binascii.so (0) <0500EE19-8D4E-374A-8103-A6B17E7B9AAD> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/binascii.so
       0x108538000 -        0x108547ff7 +libz.1.dylib (0) <EE52BDB8-6083-3F10-A193-2E52AAF555E7> /opt/local/lib/libz.1.dylib
       0x10854b000 -        0x10854dff7 +_hashlib.so (0) <62BFADCD-C513-3B6F-8DCD-537FEF30FE10> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_hashlib.so
       0x108552000 -        0x10859aff7 +libssl.1.0.0.dylib (0) <3F56809B-832A-3691-A011-16E8DE68D647> /opt/local/lib/libssl.1.0.0.dylib
       0x1085b8000 -        0x108734a7f +libcrypto.1.0.0.dylib (0) <1D9D9F5A-DE01-38D9-A369-DA4AFDBFA340> /opt/local/lib/libcrypto.1.0.0.dylib
       0x1087aa000 -        0x1087abff7 +_random.so (0) <E048EAD2-A19B-3DFD-91AB-BA38BBDB819D> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_random.so
       0x1087af000 -        0x1087b6fff +threadstatecmodule.so (0) <3BF0A7AA-3FD2-3493-8EBB-6675B237F5D2> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/threadstatecmodule.so
       0x1087be000 -        0x1087f3fff +liboof2common.dylib (0) <A0322879-FF39-3DC3-96E5-BBAE0BA3302B> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/liboof2common.dylib
       0x10883c000 -        0x10883eff7 +switchboardcmodule.so (0) <C9584172-02AB-38BD-BAE6-956A8DEC07E8> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/switchboardcmodule.so
       0x108882000 -        0x108888ff7 +lockcmodule.so (0) <47BC30E2-39DB-321C-8DFA-E6D055802C9F> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/lockcmodule.so
       0x10888d000 -        0x10888eff7 +guitopcmodule.so (0) <5B394BB8-9AEB-3B03-A717-2BE37626F0CE> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/guitopcmodule.so
       0x108891000 -        0x108893fff +time.so (0) <A93959AA-DF19-3057-AC38-3FED889CE742> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/time.so
       0x108898000 -        0x1088a1fff +ooferrorcmodule.so (0) <42F0F94C-B8B3-3A27-B5B2-65DFF6ABEC5C> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/ooferrorcmodule.so
       0x1088a9000 -        0x1088acff7 +_collections.so (0) <B29A017B-8E54-377E-A8AB-7E0B04EC23E1> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_collections.so
       0x1088f2000 -        0x1088f5fff +operator.so (0) <3281A6D0-33FC-3E54-831B-DB13D67CB7B0> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/operator.so
       0x1088fc000 -        0x108901fff +itertools.so (0) <9F7DA528-247B-3B3F-B781-0BABC48CDA81> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/itertools.so
       0x10890c000 -        0x10890dfff +_heapq.so (0) <EE4A07D6-D12F-395D-9BC8-673978E59D3C> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_heapq.so
       0x108911000 -        0x108912fff +configcmodule.so (0) <F789675E-027C-360F-AAA7-C4BD5DB248D9> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/configcmodule.so
       0x108915000 -        0x108916fff +crandomcmodule.so (0) <E81A31DE-7EF6-3616-86F9-4C48616C8CA5> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/crandomcmodule.so
       0x108919000 -        0x10891fff7 +progresscmodule.so (0) <9C46562E-C05D-34B7-9D46-7D088C23A4B8> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/progresscmodule.so
       0x108964000 -        0x108965fff +argvcmodule.so (0) <3439FE9B-B714-35C1-98B9-ED4F206B0C15> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/argvcmodule.so
       0x1089a9000 -        0x1089adfff +timestampcmodule.so (0) <F6CB64E5-33E7-331B-8670-2A34DF4AAB9D> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/timestampcmodule.so
       0x1089b4000 -        0x1089b7ff7 +_struct.so (0) <73861C90-94F6-3FD6-92B7-0894F3396736> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_struct.so
       0x108abe000 -        0x108abfff7 +_functools.so (0) <FBDA1656-A7E0-3508-8042-FED754159171> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_functools.so
       0x108b43000 -        0x108b4ffff +parser.so (0) <45E7D37C-98E2-36CD-B6B0-D9CE41217094> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/parser.so
       0x108b54000 -        0x108b55fff +cStringIO.so (0) <02BE2A75-2B0E-341C-9743-1DEC721DE7FA> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/cStringIO.so
       0x108b9a000 -        0x108babfff +_io.so (0) <122F9D7E-7841-3F6C-BD9E-FDA53C14B0E7> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so
       0x108bc3000 -        0x108bc4ff7 +fcntl.so (0) <2F7A0C63-0D5A-3DA5-9575-37B25B1D05AE> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/fcntl.so
       0x108c07000 -        0x108c09fff +cdebugcmodule.so (0) <91334A7A-7E57-3A8B-9BAB-847341AF6FCE> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/cdebugcmodule.so
       0x108c0d000 -        0x108c17fff +_glib.so (0) <6674D27A-A4C9-30FA-8FDD-4125C6CCFA89> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/glib/_glib.so
       0x108c22000 -        0x108c25fff +libpyglib-2.0-python2.7.0.dylib (0) <853FD0FA-128F-387E-B933-BDD7752BDF47> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/libpyglib-2.0-python2.7.0.dylib
       0x108c29000 -        0x108c59fff +libgobject-2.0.0.dylib (0) <234617D2-B747-3629-84C3-8C80F5464287> /opt/local/lib/libgobject-2.0.0.dylib
       0x108c6c000 -        0x108c6efff +libgthread-2.0.0.dylib (0) <66ACAEE6-E7C4-3854-80D5-D0ACC6989570> /opt/local/lib/libgthread-2.0.0.dylib
       0x108c71000 -        0x108d62ff7 +libglib-2.0.0.dylib (0) <1999006A-50C8-394C-B7D6-8DEE6E1FF81A> /opt/local/lib/libglib-2.0.0.dylib
       0x108d87000 -        0x108d8cfff +libffi.6.dylib (0) <7BEB674D-BF64-35C1-B18C-607945ADCBDC> /opt/local/lib/libffi.6.dylib
       0x108e00000 -        0x108e15fff +_gobject.so (0) <06E4C152-79D1-3B6A-97AC-01F15BD3959A> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gobject/_gobject.so
       0x108e64000 -        0x108fafff7 +_gtk.so (0) <2B03FBB1-C08E-371B-B25E-D3A4AACA0950> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gtk-2.0/gtk/_gtk.so
       0x1090ce000 -        0x1093c8ff7 +libgtk-x11-2.0.0.dylib (0) <BA56EE11-CD1B-3442-8A8B-2DF9157AC8DF> /opt/local/lib/libgtk-x11-2.0.0.dylib
       0x109491000 -        0x109509ff7 +libgdk-x11-2.0.0.dylib (0) <78FD1E48-2FB7-3F5D-BE3D-54A5FB1F3D9A> /opt/local/lib/libgdk-x11-2.0.0.dylib
       0x109532000 -        0x10953ffff +libpangocairo-1.0.0.dylib (0) <857FAB06-F490-3991-87B3-A084ED730723> /opt/local/lib/libpangocairo-1.0.0.dylib
       0x10954b000 -        0x109551fff +libXrender.1.dylib (0) <D6BCA0F2-2F17-3CE2-AD9A-D014EB81289E> /opt/local/lib/libXrender.1.dylib
       0x109555000 -        0x109556fff +libXinerama.1.dylib (0) <9BB238DB-5507-3F09-83DA-D10ECE14A6EC> /opt/local/lib/libXinerama.1.dylib
       0x109559000 -        0x109564ff7 +libXi.6.dylib (0) <F3088739-6FF8-3466-8D11-AEF65DC90C4C> /opt/local/lib/libXi.6.dylib
       0x109568000 -        0x10956efff +libXrandr.2.dylib (0) <A600E0E4-FD52-35F3-AA25-6BFC80DD7C06> /opt/local/lib/libXrandr.2.dylib
       0x109572000 -        0x109578ff7 +libXcursor.1.dylib (0) <9179860D-197E-3986-A85F-8E9F76E271D2> /opt/local/lib/libXcursor.1.dylib
       0x10957d000 -        0x10957efff +libXcomposite.1.dylib (0) <FCEF986C-F5DA-3D5D-B3B3-4D261286C543> /opt/local/lib/libXcomposite.1.dylib
       0x109581000 -        0x109582fff +libXdamage.1.dylib (0) <388EC681-01A5-399B-A797-60D2D4055A35> /opt/local/lib/libXdamage.1.dylib
       0x109585000 -        0x109588fff +libXfixes.3.dylib (0) <34352E6A-D1CC-3093-915E-D5270B57C263> /opt/local/lib/libXfixes.3.dylib
       0x10958b000 -        0x109680fff +libX11.6.dylib (0) <33028A20-6F70-36B9-BB0D-50DEA4BC72D5> /opt/local/lib/libX11.6.dylib
       0x1096a4000 -        0x1096aeff7 +libXext.6.dylib (0) <EDFED030-45A8-384C-B548-A1FE00DE0896> /opt/local/lib/libXext.6.dylib
       0x1096b4000 -        0x1096c9fff +libatk-1.0.0.dylib (0) <BA7D006F-F187-3615-BCF8-3F7425908145> /opt/local/lib/libatk-1.0.0.dylib
       0x1096d7000 -        0x109795ff7 +libcairo.2.dylib (0) <4FA99B33-183F-3254-8FE8-B6A9A4FA1DE3> /opt/local/lib/libcairo.2.dylib
       0x1097c4000 -        0x1097d9fff +libgdk_pixbuf-2.0.0.dylib (0) <1A1540AF-8EAB-3AE7-BCD4-DAC6459E67BB> /opt/local/lib/libgdk_pixbuf-2.0.0.dylib
       0x1097e3000 -        0x1098d6ff7 +libgio-2.0.0.dylib (0) <8EDA5B2F-63A1-34FB-8736-A48F44C559E0> /opt/local/lib/libgio-2.0.0.dylib
       0x10993d000 -        0x109949fff +libpangoft2-1.0.0.dylib (0) <895F2047-C283-3483-8A99-D5961636E46E> /opt/local/lib/libpangoft2-1.0.0.dylib
       0x109953000 -        0x109986ff7 +libpango-1.0.0.dylib (0) <3A039F35-2BEF-3965-91AC-74FB7EC49C00> /opt/local/lib/libpango-1.0.0.dylib
       0x109999000 -        0x1099c5fff +libfontconfig.1.dylib (0) <BF6722D4-19CC-324A-8ED1-283CCD929C7C> /opt/local/lib/libfontconfig.1.dylib
       0x1099d1000 -        0x109a44ff7 +libfreetype.6.dylib (0) <45694C25-7047-3240-90F3-D517709D7489> /opt/local/lib/libfreetype.6.dylib
       0x109a5b000 -        0x109a5efff +libgmodule-2.0.0.dylib (0) <9B33CD70-A945-393D-97AE-29F10744641A> /opt/local/lib/libgmodule-2.0.0.dylib
       0x109a61000 -        0x109aa1ff7 +libharfbuzz.0.dylib (0) <F4066E6A-4636-3087-957D-B79240C0BC9B> /opt/local/lib/libharfbuzz.0.dylib
       0x109ab4000 -        0x109b23fff +libpixman-1.0.dylib (0) <3D9F0EB6-81ED-3256-80B2-13A2AB63609B> /opt/local/lib/libpixman-1.0.dylib
       0x109b37000 -        0x109b5aff7 +libpng16.16.dylib (0) <7DA1813B-7483-3B78-914F-90EC130C5A1C> /opt/local/lib/libpng16.16.dylib
       0x109b63000 -        0x109b64fff +libX11-xcb.1.dylib (0) <9DAC9FA4-104E-3426-856F-902E126DA534> /opt/local/lib/libX11-xcb.1.dylib
       0x109b66000 -        0x109b6afff +libxcb-render.0.dylib (0) <45E03A94-EDF9-31DE-940C-D04C37BE2B21> /opt/local/lib/libxcb-render.0.dylib
       0x109b70000 -        0x109b7ffff +libxcb.1.dylib (0) <DDE35A94-2D80-336D-B041-E81209EF0394> /opt/local/lib/libxcb.1.dylib
       0x109b8e000 -        0x109ba7ff7 +libexpat.1.dylib (0) <FC0B6E54-ED80-3460-B2AC-C8B5041957F3> /opt/local/lib/libexpat.1.dylib
       0x109bae000 -        0x109bbcfff +libbz2.1.0.dylib (0) <57564CB0-AD8D-35AD-A8BE-EAF844A6005C> /opt/local/lib/libbz2.1.0.dylib
       0x109bc0000 -        0x109bc1fff +libXau.6.dylib (0) <935C8321-AAF2-3DED-AC86-293C2FAB97EC> /opt/local/lib/libXau.6.dylib
       0x109bc4000 -        0x109bc7ff7 +libXdmcp.6.dylib (0) <A669F1F9-DC0E-38F6-B782-97A43C0A88C4> /opt/local/lib/libXdmcp.6.dylib
       0x109bca000 -        0x109bddfff +libgraphite2.3.dylib (0) <92E7CCC4-F6BF-35C4-B653-7CC0996BB45C> /opt/local/lib/libgraphite2.3.dylib
       0x109be6000 -        0x109bf1fff +_cairo.so (0) <7D76EBEC-538F-3C3D-A5A5-517B10B7A2A4> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/cairo/_cairo.so
       0x109c05000 -        0x109c33fff +_gio.so (0) <D1C4EAF0-3643-3DE0-AA00-1D6930D360C5> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gtk-2.0/gio/_gio.so
       0x109ca3000 -        0x109ca7fff +unix.so (0) <6311E32E-E731-38B4-A6C2-2F0CCE7796EF> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gtk-2.0/gio/unix.so
       0x109cad000 -        0x109cbffff +pango.so (0) <17FA60C4-8AC6-39F6-A8E7-7300C88286E2> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gtk-2.0/pango.so
       0x109cd6000 -        0x109cfbfff +atk.so (0) <455BA498-FC2B-3AFC-8D8F-8AFA81DCAFEA> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gtk-2.0/atk.so
       0x109dd5000 -        0x109dd9fff +pangocairo.so (0) <76E71213-ECE9-3857-9514-98D2FBA92AEA> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gtk-2.0/pangocairo.so
       0x109e1d000 -        0x109e22fff +contourcmodule.so (0) <E4752FDD-29B0-37FB-ACF3-25499A029FDE> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/IO/contourcmodule.so
       0x109e68000 -        0x109e69ff7 +quad4cmodule.so (0) <119B55B7-14F9-3835-825F-1256E9F4B0F1> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/elements/quad4cmodule.so
       0x109e6c000 -        0x109e6dfff +quad4_8cmodule.so (0) <16E738EA-8CE6-3204-B1BD-EE1AF3241A71> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/elements/quad4_8cmodule.so
       0x109e70000 -        0x109e71ff7 +quad8cmodule.so (0) <E9AFB600-40CF-385B-8570-5BABB7DAD2F6> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/elements/quad8cmodule.so
       0x109e74000 -        0x109e75ff7 +quad9cmodule.so (0) <FEB8731C-AA2F-35EF-9973-6C099606D494> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/elements/quad9cmodule.so
       0x109e78000 -        0x109e79ff7 +tri3cmodule.so (0) <315D4775-167B-3457-A960-AA27DA3FB697> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/elements/tri3cmodule.so
       0x109e7c000 -        0x109e7dfff +tri3_6cmodule.so (0) <2912E4CC-9256-3E1B-8027-EFE9CD059190> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/elements/tri3_6cmodule.so
       0x109e80000 -        0x109e81ff7 +tri6cmodule.so (0) <7913D9B5-FDD8-3EDF-82E7-9827624231D7> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/elements/tri6cmodule.so
       0x109e84000 -        0x109e85fff +tri6_3cmodule.so (0) <5F45B57E-316E-3A46-920A-950B59AAC3D0> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/elements/tri6_3cmodule.so
       0x109e88000 -        0x109e8aff7 +angle2colorcmodule.so (0) <F3A12D73-1577-3876-BCC1-AA46122B5249> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/angle2colorcmodule.so
       0x109e8e000 -        0x109e90ff7 +bdyanalysiscmodule.so (0) <91B0ED9C-366A-3181-A8D6-9741AB9098F6> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/bdyanalysiscmodule.so
       0x109e94000 -        0x109e96fff +skeletonrelaxationratecmodule.so (0) <9417C475-A8E7-337D-91DD-1FDB00E9CEC3> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/skeletonrelaxationrate/skeletonrelaxationratecmodule.so
       0x109e9a000 -        0x109e9cff7 +orientationimagecmodule.so (0) <BE08E7BB-16D6-3BD7-A0AD-29560CB162F9> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/orientationimagecmodule.so
       0x109f7b000 -        0x109f7cff7 +pixelattributecmodule.so (0) <BFBBF76C-8E22-3954-867D-78DF6C4855E6> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/pixelattributecmodule.so
       0x109f80000 -        0x109f85ff7 +activeareacmodule.so (0) <43FFCF3B-0EF1-35C0-B736-DF080C10A651> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/activeareacmodule.so
       0x109f8a000 -        0x109f92ff7 +cpixelselectioncmodule.so (0) <AB447A5D-EA05-3EC4-A48C-FF6DADF2F619> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/cpixelselectioncmodule.so
       0x109f98000 -        0x109f9ffff +pixelgroupcmodule.so (0) <71582415-66E4-3B6E-B094-1AC229AFDAAE> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/pixelgroupcmodule.so
       0x109fa5000 -        0x109fadff7 +bitoverlaycmodule.so (0) <9323A98F-90A9-37FC-BB21-74F379ED4319> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/IO/bitoverlaycmodule.so
       0x109fb3000 -        0x109fb6ff7 +stringimagecmodule.so (0) <1385CEA0-0E10-3BBE-8619-BCD2FAC32EA5> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/IO/stringimagecmodule.so
       0x109fba000 -        0x109fbffff +ccolorcmodule.so (0) <54513D47-88CF-3835-969B-88E09DA7610E> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/ccolorcmodule.so
       0x109fc3000 -        0x109fc5ff7 +abstractimagecmodule.so (0) <EBBD69B9-8C51-3F37-99A6-8B7D136B35ED> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/abstractimagecmodule.so
       0x109fc9000 -        0x109fccff7 +coordcmodule.so (0) <17E2E6A1-630F-36A9-AEC3-BF799FE09F00> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/coordcmodule.so
       0x109fd1000 -        0x109fd9fff +cmicrostructurecmodule.so (0) <284DBD38-12CC-3299-97E8-A05B64A52D31> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/cmicrostructurecmodule.so
       0x109fe0000 -        0x109fe9ff7 +pixelselectioncouriercmodule.so (0) <210B8729-921D-3A22-870F-6C296C2B2E0E> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/pixelselectioncouriercmodule.so
       0x109ff2000 -        0x109ff6ff7 +colordifferencecmodule.so (0) <76928E43-A792-3B6A-8733-154B6220E8BF> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/colordifferencecmodule.so
       0x109ffa000 -        0x109ffcff7 +brushstylecmodule.so (0) <14A148E1-77B8-3D4F-BE28-89CBA64103EF> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/brushstylecmodule.so
       0x10c37f000 -        0x10c381fff +pango-basic-coretext.so (0) <A84FFC8E-47A2-3D4C-8587-519E9054ECE0> /opt/local/lib/*/pango-basic-coretext.so
       0x10c3c4000 -        0x10c3d0ff7 +rubberbandcmodule.so (0) <55643495-312D-3806-9ECC-95EAFE8CF2A8> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/IO/GUI/rubberbandcmodule.so
       0x10c3d5000 -        0x10c3e8ff7 +liboof2commonGUI.dylib (0) <EB9B364B-3232-3112-9784-14A564819ED7> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/liboof2commonGUI.dylib
       0x10c3fa000 -        0x10c423fff +libgnomecanvas-2.0.dylib (0) <DD6A5766-7210-3E32-88AB-BED1D8DB3BD1> /opt/local/lib/libgnomecanvas-2.0.dylib
       0x10c435000 -        0x10c445fff +libart_lgpl_2.2.dylib (0) <33C2984F-CF89-3DC3-B609-98C1171C105A> /opt/local/lib/libart_lgpl_2.2.dylib
       0x10c44a000 -        0x10c454fff +libgailutil.18.dylib (0) <B6BBCD2B-FA16-337A-9FE3-98E0429A458F> /opt/local/lib/libgailutil.18.dylib
       0x10c4d9000 -        0x10c4e1fff +progressGUIcmodule.so (0) <70FC2143-FD8D-3634-9609-D1DA1602A6E3> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/IO/GUI/progressGUIcmodule.so
       0x10c524000 -        0x10c528ff7 +geometrycmodule.so (0) <EBB9265E-0C84-3AC4-B517-FFC2D2070035> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/geometrycmodule.so
       0x10c52e000 -        0x10c545ff7 +oofcanvascmodule.so (0) <D47C45FC-6440-3B02-A551-2C6B3ACB2391> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/IO/GUI/oofcanvascmodule.so
       0x10c54e000 -        0x10c557ff7 +gfxbrushstylecmodule.so (0) <759EC464-C718-3AB6-BB7F-3308C6CD3D6D> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/IO/GUI/gfxbrushstylecmodule.so
       0x10c59b000 -        0x10c5a6fff +ooferror2cmodule.so (0) <8420DA5B-6695-3864-AB54-C74677626E59> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/ooferror2cmodule.so
       0x10c5b1000 -        0x10c5bdfff +materialcmodule.so (0) <9985E9B7-ECB7-39A1-9212-582F7CDB9E80> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/materialcmodule.so
       0x10c5c6000 -        0x10c5d1fff +propertiescmodule.so (0) <39712D1B-67A9-37C1-8D30-C7D6D3BD39CC> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/propertiescmodule.so
       0x10c5d7000 -        0x10c5daff7 +cijklcmodule.so (0) <4577E313-1D5F-3939-8572-98617B7D540F> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/elasticity/cijklcmodule.so
       0x10c5de000 -        0x10c5e5ff7 +symmmatrixcmodule.so (0) <D36F3624-A907-353A-A221-8A12948EE906> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/symmmatrixcmodule.so
       0x10c5ea000 -        0x10c5f4fff +outputvalcmodule.so (0) <3823C8E2-85EB-3AC6-BBCE-84343959B1E6> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/outputvalcmodule.so
       0x10c5fa000 -        0x10c5fcfff +identificationcmodule.so (0) <0AA22756-11C5-32C4-9B32-8002F2D4DD9C> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/identificationcmodule.so
       0x10c600000 -        0x10c603ff7 +freedomcmodule.so (0) <F0CF37DA-A501-3631-93B3-CED318BF7032> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/freedomcmodule.so
       0x10c608000 -        0x10c609fff +crystalsymmetrycmodule.so (0) <A7A5C107-6ECA-34D0-A529-8E732CDC1012> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/crystalsymmetrycmodule.so
       0x10c89a000 -        0x10c977fff +liboof2engine.dylib (0) <0AF52ADF-20B7-3F1B-874C-148D5E0AAED1> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/liboof2engine.dylib
       0x10cae5000 -        0x10caf5ff7 +fieldindexcmodule.so (0) <77D2CED3-26B1-31FE-A90F-4366306C13B8> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/fieldindexcmodule.so
       0x10cb49000 -        0x10cb55fff +corientationcmodule.so (0) <2BE73429-C374-3740-B80E-A6A70AFEB9D4> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/corientationcmodule.so
       0x10cb9c000 -        0x10cba5fff +doubleveccmodule.so (0) <DBCBECF7-05ED-36DF-A40A-43EBEDCD9191> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/doubleveccmodule.so
       0x10cbb0000 -        0x10cbbbfff +fieldcmodule.so (0) <D3B125B1-C92B-3207-8E01-EBE91269A645> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/fieldcmodule.so
       0x10cbc2000 -        0x10cbc6fff +fluxcmodule.so (0) <3A3DDD54-0027-3B43-8265-8F423A5F991E> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/fluxcmodule.so
       0x10cbca000 -        0x10cbd7ff7 +sparsematcmodule.so (0) <2DDC73FE-6299-35E8-B202-8054DB297C6F> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/sparsematcmodule.so
       0x10cc21000 -        0x10cc24fff +entiremeshsubproblemcmodule.so (0) <3C72CA0C-BD3A-3B14-B214-53534C603F82> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/entiremeshsubproblemcmodule.so
       0x10cc29000 -        0x10cc3afff +csubproblemcmodule.so (0) <33D37BDB-4A4A-36D5-BC08-8912F39AFB1D> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/csubproblemcmodule.so
       0x10cc44000 -        0x10cc4afff +equationcmodule.so (0) <F007DCE0-D4E6-3430-B088-B844AE15982D> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/equationcmodule.so
       0x10cc50000 -        0x10cc51fff +nodalequationcmodule.so (0) <999E926E-B53E-37AE-BC98-02449AC89FAC> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/nodalequationcmodule.so
       0x10cc94000 -        0x10cc9ffff +femeshcmodule.so (0) <A11EF203-A6C4-3CA0-8131-FDE7AB73ED73> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/femeshcmodule.so
       0x10cca7000 -        0x10ccacff7 +meshiteratorcmodule.so (0) <3FF6E4F4-ADAF-3FFB-8023-4358AFE16A12> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/meshiteratorcmodule.so
       0x10ccb1000 -        0x10ccbeff7 +elementcmodule.so (0) <AAB62F21-E475-3C03-BC84-EFDB6DEC1EFE> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/elementcmodule.so
       0x10ccc7000 -        0x10cccefff +elementnodeiteratorcmodule.so (0) <FD4636AE-9F2E-3275-A8F8-238DA69BF675> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/elementnodeiteratorcmodule.so
       0x10ccd4000 -        0x10ccd8fff +nodecmodule.so (0) <630C7123-1368-348F-A3CF-FDDD72E89E9D> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/nodecmodule.so
       0x10ccdd000 -        0x10cce0fff +pointdatacmodule.so (0) <3262316B-62D8-39DF-8AF9-0B4E5D06B7C8> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/pointdatacmodule.so
       0x10cce5000 -        0x10cce7ff7 +gausspointcmodule.so (0) <1C61AAD2-1524-3C89-9BC6-D15E065D6623> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/gausspointcmodule.so
       0x10cceb000 -        0x10cceefff +mastercoordcmodule.so (0) <4335521B-D605-3426-AA28-36D5E9F357F9> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/mastercoordcmodule.so
       0x10ccf2000 -        0x10ccfdff7 +masterelementcmodule.so (0) <8BFA551C-DC98-3E89-AEE9-9A405275EC02> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/masterelementcmodule.so
       0x10cd47000 -        0x10cd4dff7 +edgecmodule.so (0) <AA9CC6AD-12C5-3997-8AB3-9D01E3FCC150> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/edgecmodule.so
       0x10cd53000 -        0x10cd56ff7 +boundarycondcmodule.so (0) <72F3BA4D-B407-3681-95F7-9FA88924B758> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/boundarycondcmodule.so
       0x10cd5a000 -        0x10cd60fff +edgesetcmodule.so (0) <02DB5D04-9145-320A-87BD-C25BDCA3220A> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/edgesetcmodule.so
       0x10cda6000 -        0x10cdb4fff +cskeletoncmodule.so (0) <84CCD585-3C20-3952-A069-6ECFF55EE282> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/cskeletoncmodule.so
       0x10d17c000 -        0x10d17fff7 +cconjugatecmodule.so (0) <0C9991B6-C707-3593-9511-46F125546AE5> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/cconjugatecmodule.so
       0x10d184000 -        0x10d199ff7 +linearizedsystemcmodule.so (0) <801802A7-66B3-3AA9-9458-DE07AE4EDCA1> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/linearizedsystemcmodule.so
       0x10d1a3000 -        0x10d1a8ff7 +meshdatacachecmodule.so (0) <50F3F77D-B4B6-3ED9-88A7-36C091ED2E0A> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/meshdatacachecmodule.so
       0x10d1ed000 -        0x10d1f0fff +cnonlinearsolvercmodule.so (0) <6210C40C-C1FD-3920-8DCD-D9F0188F4CCF> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/cnonlinearsolvercmodule.so
       0x10d1f4000 -        0x10d1f7fff +cmatrixmethodscmodule.so (0) <6548FA38-FA20-38BB-997E-85C308C7F997> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/cmatrixmethodscmodule.so
       0x10d1fb000 -        0x10d201ff7 +preconditionercmodule.so (0) <F9357E9E-2775-36C3-83B0-59C31EA6EF2E> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/preconditionercmodule.so
       0x10d248000 -        0x10d24bfff +steperrorscalingcmodule.so (0) <2A8F2E11-C65B-32C9-BB9E-57603BBB540F> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/steperrorscalingcmodule.so
       0x10d24f000 -        0x10d251fff +colorcmodule.so (0) <3D4E60AD-00A3-3D16-8993-6D3E2079878D> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/color/colorcmodule.so
       0x10d255000 -        0x10d256fff +dampingcmodule.so (0) <41D2FCDC-CFD8-37BF-A408-A0A6812C8538> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/damping/dampingcmodule.so
       0x10d29a000 -        0x10d29eff7 +anisocmodule.so (0) <E52C4A16-FEBB-3CA3-A3D6-4799B6129275> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/elasticity/aniso/anisocmodule.so
       0x10d2a4000 -        0x10d2a6ff7 +elasticitycmodule.so (0) <D57EBCCB-E88F-314F-A349-506FEA266D5D> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/elasticity/elasticitycmodule.so
       0x10d2aa000 -        0x10d2acfff +isocmodule.so (0) <6E8BB93D-AD49-36FC-AE5F-21A34BCE27F3> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/elasticity/iso/isocmodule.so
       0x10d2f0000 -        0x10d2f3ff7 +largestraincmodule.so (0) <3F9BA4CF-5350-363D-B29A-FF6C8BE7A707> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/elasticity/largestrain/largestraincmodule.so
       0x10d2f7000 -        0x10d2f9fff +thermocmodule.so (0) <65C9FB97-B74F-338B-9480-E5337A2BF76E> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/elasticity/thermo/thermocmodule.so
       0x10d2fd000 -        0x10d2fffff +viscocmodule.so (0) <0FE0FF8D-4EF0-3823-B133-B533FA09EE52> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/elasticity/visco/viscocmodule.so
       0x10d303000 -        0x10d306ff7 +general_nonlinear_elasticitycmodule.so (0) <E8506A0E-1AB7-3C59-A7AA-66A3719046B8> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/elasticity/nonlinear/general_nonlinear_elasticitycmodule.so
       0x10d30c000 -        0x10d30efff +forcedensitycmodule.so (0) <5AE4C1EF-2729-3639-B61F-690729B2A73E> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/forcedensity/forcedensitycmodule.so
       0x10d312000 -        0x10d315fff +nonconstant_force_densitycmodule.so (0) <135B616D-D87A-39F3-8605-E6580208BB7F> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/forcedensity/nonconstant/nonconstant_force_densitycmodule.so
       0x10d31b000 -        0x10d31eff7 +nonlinear_force_densitycmodule.so (0) <D98A945A-D2B1-3341-ACDD-16470C0E8001> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/forcedensity/nonlinear/nonlinear_force_densitycmodule.so
       0x10d364000 -        0x10d365ff7 +heatcapacitycmodule.so (0) <5418AFF4-222B-33BE-9E6D-86CFC4D6336F> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/heatcapacity/heatcapacitycmodule.so
       0x10d369000 -        0x10d36bfff +heatconductivitycmodule.so (0) <B9BE4FDD-015B-331E-8971-49283CC90F55> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/heatconductivity/heatconductivitycmodule.so
       0x10d36f000 -        0x10d372ff7 +nonlinear_heat_conductivitycmodule.so (0) <D860D854-29EE-3A6F-B706-5B372D83FAE4> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/heatconductivity/nonlinear/nonlinear_heat_conductivitycmodule.so
       0x10d378000 -        0x10d37afff +heatsourcecmodule.so (0) <1249C259-D590-39EA-AAC1-587B4D77B68E> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/heatsource/heatsourcecmodule.so
       0x10d37e000 -        0x10d381fff +nonconstant_heat_sourcecmodule.so (0) <98326F6D-E06F-3425-99A5-091CDD0C7794> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/heatsource/nonconstant/nonconstant_heat_sourcecmodule.so
       0x10d387000 -        0x10d38aff7 +nonlinear_heat_sourcecmodule.so (0) <0CFDBCD4-9A5A-3006-885A-D6B4E3FBC9E1> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/heatsource/nonlinear/nonlinear_heat_sourcecmodule.so
       0x10d3d0000 -        0x10d3d1fff +massdensitycmodule.so (0) <EFA68EE7-50AA-36C7-97E2-D09F198676C1> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/massdensity/massdensitycmodule.so
       0x10d3d5000 -        0x10d3d7ff7 +orientationcmodule.so (0) <D91CA095-5EF2-3840-BE1C-31878872113F> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/orientation/orientationcmodule.so
       0x10d3db000 -        0x10d3defff +permittivitycmodule.so (0) <3B3C34A4-4448-3AE1-9187-1F0651F37EEE> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/permittivity/permittivitycmodule.so
       0x10d3e2000 -        0x10d3e4ff7 +piezoelectricitycmodule.so (0) <6FB058D3-E7BB-3D36-B6CB-BB143E6217B4> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/piezoelectricity/piezoelectricitycmodule.so
       0x10d428000 -        0x10d42bff7 +rank3tensorcmodule.so (0) <962D7FE0-9DE6-36D8-9BAA-71F2935F2FAE> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/rank3tensorcmodule.so
       0x10d46f000 -        0x10d471fff +pyroelectricitycmodule.so (0) <11E8BE62-DA99-38E4-B409-15232A823916> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/pyroelectricity/pyroelectricitycmodule.so
       0x10d475000 -        0x10d477fff +stressfreestraincmodule.so (0) <7289AE08-8F70-37D5-8793-980D5099372F> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/stressfreestrain/stressfreestraincmodule.so
       0x10d47b000 -        0x10d47dff7 +thermalexpansioncmodule.so (0) <D8A38954-CB79-34C6-B060-0A77763B4F51> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/thermalexpansion/thermalexpansioncmodule.so
       0x10d4c1000 -        0x10d4c5fff +smallmatrixcmodule.so (0) <901115E9-076B-3307-B895-F67246A800D9> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/smallmatrixcmodule.so
       0x10d4c9000 -        0x10d4ccfff +pypropertywrappercmodule.so (0) <8BF3C38E-A571-3039-BA14-DC41C9F2CEEF> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/pypropertywrappercmodule.so
       0x10d4d1000 -        0x10d4d8fff +smallsystemcmodule.so (0) <E4150023-87B0-338B-AAD8-EA99C234D9F1> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/smallsystemcmodule.so
       0x10d4dd000 -        0x10d4e3ff7 +propertyoutputcmodule.so (0) <509F5050-FD20-3CF7-A68C-E7A971DA0AEF> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/IO/propertyoutputcmodule.so
       0x10d529000 -        0x10d52cfff +invariantcmodule.so (0) <8DB11C4B-F39D-383D-A04C-6C250F2A1DB0> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/invariantcmodule.so
       0x10d531000 -        0x10d532fff +planaritycmodule.so (0) <CDC6F9F9-C088-3716-B601-19C89F4C4027> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/planaritycmodule.so
       0x10d535000 -        0x10d536ff7 +simpletensioncmodule.so (0) <432EB2D7-521E-3948-AF25-962F567DBE9F> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/interfaces/surfacetension/simpletension/simpletensioncmodule.so
       0x10d53a000 -        0x10d53cff7 +surfacetestcmodule.so (0) <A70022BA-2A68-3041-83B4-5FCCC5DFA2C0> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/property/interfaces/surfacetest/surfacetestcmodule.so
       0x10d580000 -        0x10d582ff7 +cstraincmodule.so (0) <72B78EE5-6764-33D8-BADC-DA54450AD1FD> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/cstraincmodule.so
       0x10d686000 -        0x10d692fff +datetime.so (0) <B11B4FF8-D478-3AD0-A54B-D5E4F17995A4> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/datetime.so
       0x10d79e000 -        0x10d7a1ff7 +materialsubproblemcmodule.so (0) <921AC601-D0A0-3C95-9448-1B667EFFFC8A> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/materialsubproblemcmodule.so
       0x10d7a6000 -        0x10d7a9ff7 +pixelgroupsubproblemcmodule.so (0) <382F9590-EA26-34A5-B6B5-06A8FED973AE> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/pixelgroupsubproblemcmodule.so
       0x10d7ae000 -        0x10d7b9fff +compoundsubproblemcmodule.so (0) <43926AA4-97CE-3F91-BA68-F271E707E342> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/compoundsubproblemcmodule.so
       0x10d809000 -        0x10d80dff7 +pixelselectioncourierecmodule.so (0) <2B3E8CD5-FB65-3339-930B-BF13C59D0029> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/pixelselectioncourierecmodule.so
       0x10db12000 -        0x10db15fff +burncmodule.so (0) <5197A763-A661-37DF-B601-C34AD0F85827> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/image/burncmodule.so
       0x10db19000 -        0x10db26fff +liboof2image.dylib (0) <06E19016-743F-3938-ABF8-9DCE81BFDA28> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/liboof2image.dylib
       0x10db38000 -        0x10db64fff +libMagick++-6.Q16.5.dylib (0) <25E901F9-A44D-3EE7-951B-48A757BECFDF> /opt/local/lib/libMagick++-6.Q16.5.dylib
       0x10dbb4000 -        0x10dcebfff +libMagickWand-6.Q16.2.dylib (0) <21C1EDD2-46E4-3EF7-8E5A-44939E2E960D> /opt/local/lib/libMagickWand-6.Q16.2.dylib
       0x10dd04000 -        0x10debafff +libMagickCore-6.Q16.2.dylib (0) <BED933D8-24D1-3123-9864-DCBB0F89AF6A> /opt/local/lib/libMagickCore-6.Q16.2.dylib
       0x10df4d000 -        0x10df84fff +liblcms2.2.dylib (0) <8F0AA1D2-5FB0-3BC5-99DC-7D377AEA0204> /opt/local/lib/liblcms2.2.dylib
       0x10df97000 -        0x10e072fff +libfftw3.3.dylib (0) <BD8ADF23-08C1-38F8-8020-59AC60A5790A> /opt/local/lib/libfftw3.3.dylib
       0x10e088000 -        0x10e0c3fff +libXt.6.dylib (0) <6B8CEA42-14D3-34F1-8BF2-42772CFC0793> /opt/local/lib/libXt.6.dylib
       0x10e0db000 -        0x10e0f8ff7 +liblzma.5.dylib (0) <16DEF41D-C47A-3861-A85C-8D576F52B47F> /opt/local/lib/liblzma.5.dylib
       0x10e0fe000 -        0x10e103ff7 +libltdl.7.dylib (0) <BB8FEDE8-50A1-3951-8E2D-61F3BB39D3B0> /opt/local/lib/libltdl.7.dylib
       0x10e107000 -        0x10e10cff7 +libSM.6.dylib (0) <8432B9C0-3913-315D-9FDF-8937EB85857D> /opt/local/lib/libSM.6.dylib
       0x10e110000 -        0x10e11ffff +libICE.6.dylib (0) <DA3939F8-0829-3B84-9E51-B36E9A0F1321> /opt/local/lib/libICE.6.dylib
       0x10e129000 -        0x10e12dff7 +pixelselectioncouriericmodule.so (0) <88F67E91-3F9C-35DB-8168-3FDD4F73A168> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/image/pixelselectioncouriericmodule.so
       0x10e131000 -        0x10e13efff +oofimagecmodule.so (0) <EE964F17-3999-3092-98BB-E5BDF1E76924> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/image/oofimagecmodule.so
       0x10e18a000 -        0x10e18bff7 +doublearraycmodule.so (0) <4D4A0E81-F74C-391C-A8A6-EA554B518E0F> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/doublearraycmodule.so
       0x10e18f000 -        0x10e192ff7 +boolarraycmodule.so (0) <F9B2C52E-4C0F-3A6C-93C8-2ACC3DDFAF2F> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/boolarraycmodule.so
       0x10e196000 -        0x10e198ff7 +autogroupMPcmodule.so (0) <2D37B8F8-720A-32FF-A4D0-8BD8465B575E> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/image/autogroupMPcmodule.so
       0x10e1db000 -        0x10e1e2ff7 +orientmapdatacmodule.so (0) <45F85BE9-FE07-3704-9DF8-6DE17433C602> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/orientationmap/orientmapdatacmodule.so
       0x10e1e7000 -        0x10e1effff +liboof2orientmap.dylib (0) <D9196B07-E090-3072-B657-6C876DF3CFCF> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/liboof2orientmap.dylib
       0x10e1ff000 -        0x10e201fff +orientmappropertycmodule.so (0) <F32D5DA1-48EB-370F-B3C4-803DCA4B1C0A> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/orientationmap/orientmappropertycmodule.so
       0x10e245000 -        0x10e249ff7 +polefigurecmodule.so (0) <2B375838-2763-3F4E-A4CE-432B6908CE9B> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/orientationmap/polefigurecmodule.so
       0x10e24d000 -        0x10e24fff7 +directioncmodule.so (0) <4ED7AE95-3C9D-30C9-AD71-0E5978CDDD9D> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/common/directioncmodule.so
       0x10efb9000 -        0x10efdbfff +png.so (0) <14DC1CEE-CA14-329D-8D88-3D5C2E100899> /opt/local/lib/*/png.so
       0x10efe1000 -        0x10f00eff7 +libjpeg.9.dylib (0) <08C3C5E3-8C99-3CCB-9A9E-15BF05CBB9F3> /opt/local/lib/libjpeg.9.dylib
       0x10fa08000 -        0x10fa0bfff +iluprecmodule.so (0) <6ECB68D7-47C5-3E6E-854A-EF028B55648D> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/oof2/ooflib/SWIG/engine/iluprecmodule.so
    0x7fff61ac1000 -     0x7fff61af4817  dyld (239.4) <7AD43B9B-5CEA-3C7E-9836-A06909F9CA56> /usr/lib/dyld
    0x7fff8bbf9000 -     0x7fff8bc11fff  com.apple.openscripting (1.4.1 - 157.1) <2C6C6498-D88E-3D9B-B933-9873890F382E> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
    0x7fff8bc12000 -     0x7fff8bc22fff  libbsm.0.dylib (33) <2CAC00A2-1352-302A-88FA-C567D4D69179> /usr/lib/libbsm.0.dylib
    0x7fff8bc23000 -     0x7fff8bc86ffb  com.apple.SystemConfiguration (1.13.1 - 1.13.1) <339A2A90-DA25-33AF-88E5-2FB38A758FEE> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
    0x7fff8bcb0000 -     0x7fff8bcd5ff7  com.apple.CoreVideo (1.8 - 117.2) <4674339E-26D0-35FA-9958-422832B39B12> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
    0x7fff8bcd6000 -     0x7fff8bce5ff8  com.apple.LangAnalysis (1.7.0 - 1.7.0) <8FE131B6-1180-3892-98F5-C9C9B79072D4> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis
    0x7fff8bce6000 -     0x7fff8bd24ff7  libGLImage.dylib (9.6.1) <5E02B38C-9F36-39BE-8746-724F0D8BBFC0> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
    0x7fff8bd91000 -     0x7fff8bd99ffc  libGFXShared.dylib (9.6.1) <65BC4378-C023-30EC-8B80-60FB4EA0B036> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib
    0x7fff8cc89000 -     0x7fff8cc89ffd  libOpenScriptingUtil.dylib (157.1) <D3B6E577-3CDB-3139-9B94-19496DFA7318> /usr/lib/libOpenScriptingUtil.dylib
    0x7fff8cf24000 -     0x7fff8cf66ff7  libauto.dylib (185.5) <F45C36E8-B606-3886-B5B1-B6745E757CA8> /usr/lib/libauto.dylib
    0x7fff8cf83000 -     0x7fff8d1f3ff5  com.apple.security (7.0 - 55471.14.37) <FB3047C7-1BDB-3949-8978-F40AC1BD1C13> /System/Library/Frameworks/Security.framework/Versions/A/Security
    0x7fff8d1fe000 -     0x7fff8d1fefff  com.apple.CoreServices (59 - 59) <7A697B5E-F179-30DF-93F2-8B503CEEEFD5> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
    0x7fff8d1ff000 -     0x7fff8d200fff  libsystem_sandbox.dylib (278.11.2) <0C93EB23-7364-3670-B511-212A7A524695> /usr/lib/system/libsystem_sandbox.dylib
    0x7fff8d232000 -     0x7fff8d237fff  com.apple.DiskArbitration (2.6 - 2.6) <A4165553-770E-3D27-B217-01FC1F852B87> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
    0x7fff8d238000 -     0x7fff8d239ff7  libsystem_blocks.dylib (63) <FB856CD1-2AEA-3907-8E9B-1E54B6827F82> /usr/lib/system/libsystem_blocks.dylib
    0x7fff8d23a000 -     0x7fff8d256ff7  libsystem_kernel.dylib (2422.115.14) <8116098D-B3F1-3E50-A934-576DD6369234> /usr/lib/system/libsystem_kernel.dylib
    0x7fff8d27c000 -     0x7fff8d2bbfff  libGLU.dylib (9.6.1) <AE032555-3E2F-3DBF-A26D-EA4576061605> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
    0x7fff8d341000 -     0x7fff8d341fff  com.apple.Carbon (154 - 157) <45A9A40A-78FF-3EA0-8FAB-A4F81052FA55> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
    0x7fff8d407000 -     0x7fff8d42fffb  libxslt.1.dylib (13) <C9794936-633C-3F0C-9E71-30190B9B41C1> /usr/lib/libxslt.1.dylib
    0x7fff8d73e000 -     0x7fff8d825ff7  libxml2.2.dylib (26) <A1DADD11-89E5-3DE4-8802-07186225967F> /usr/lib/libxml2.2.dylib
    0x7fff8d857000 -     0x7fff8db41fff  com.apple.CoreServices.CarbonCore (1077.17 - 1077.17) <3A2E92FD-DEE2-3D45-9619-11500801A61C> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
    0x7fff8db42000 -     0x7fff8db42fff  com.apple.Accelerate.vecLib (3.9 - vecLib 3.9) <F8D0CC77-98AC-3B58-9FE6-0C25421827B6> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
    0x7fff8db43000 -     0x7fff8dbb0fff  com.apple.SearchKit (1.4.0 - 1.4.0) <B9B8D510-A27E-36B0-93E9-17146D9E9045> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
    0x7fff8dbb1000 -     0x7fff8dc0aff7  libTIFF.dylib (1046) <26E27569-9FCB-3004-BA57-BA9B91940231> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
    0x7fff8dca2000 -     0x7fff8df4cff5  com.apple.HIToolbox (2.1.1 - 698) <26FF0E2C-1CD7-311F-ACF0-84F3D5273AD6> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
    0x7fff8e0a1000 -     0x7fff8e0a2fff  com.apple.TrustEvaluationAgent (2.0 - 25) <334A82F4-4AE4-3719-A511-86D0B0723E2B> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent
    0x7fff8e0af000 -     0x7fff8e0b8ffb  libsystem_notify.dylib (121.20.1) <9B34B4FE-F5AD-3F09-A5F0-46AFF3571323> /usr/lib/system/libsystem_notify.dylib
    0x7fff8e138000 -     0x7fff8e13aff3  libsystem_configuration.dylib (596.15) <4998CB6A-9D54-390A-9F57-5D1AC53C135C> /usr/lib/system/libsystem_configuration.dylib
    0x7fff8e13b000 -     0x7fff8e43bff7  com.apple.Foundation (6.9 - 1056.17) <E0B0FAF6-5CA8-3EEB-8BF2-104C0AEEF925> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
    0x7fff8e43e000 -     0x7fff8e871ffb  com.apple.vision.FaceCore (3.0.0 - 3.0.0) <F42BFC9C-0B16-35EF-9A07-91B7FDAB7FC5> /System/Library/PrivateFrameworks/FaceCore.framework/Versions/A/FaceCore
    0x7fff8e96f000 -     0x7fff8e980ff7  libsystem_asl.dylib (217.1.4) <655FB343-52CF-3E2F-B14D-BEBF5AAEF94D> /usr/lib/system/libsystem_asl.dylib
    0x7fff8e9f9000 -     0x7fff8ea22fff  com.apple.DictionaryServices (1.2 - 208) <A539A058-BA57-35EE-AA08-D0B0E835127D> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
    0x7fff8ea30000 -     0x7fff8ea38ff7  com.apple.speech.recognition.framework (4.2.4 - 4.2.4) <98BBB3E4-6239-3EF1-90B2-84EA0D3B8D61> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
    0x7fff8ec9b000 -     0x7fff8ecb2ff7  com.apple.CFOpenDirectory (10.9 - 173.90.1) <7BC0194E-1B40-3FCA-ACD2-235CE5D65DFA> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
    0x7fff8ed01000 -     0x7fff8ed04fff  com.apple.help (1.3.3 - 46) <AE763646-D07A-3F9A-ACD4-F5CBD734EE36> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
    0x7fff8ed05000 -     0x7fff8ed0cff8  liblaunch.dylib (842.92.1) <A40A0C7B-3216-39B4-8AE0-B5D3BAF1DA8A> /usr/lib/system/liblaunch.dylib
    0x7fff8ee23000 -     0x7fff8ee4bffb  libRIP.A.dylib (599.35.8) <8E11A157-BE53-33AF-AD74-B081446156E4> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib
    0x7fff8ee4c000 -     0x7fff8ef3bfff  libFontParser.dylib (111.1.3) <692CA36E-8E74-313E-8C40-42F1EE1BCB61> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib
    0x7fff8ef40000 -     0x7fff8ef47ffb  libcopyfile.dylib (103.92.1) <CF29DFF6-0589-3590-834C-82E2316612E8> /usr/lib/system/libcopyfile.dylib
    0x7fff8ef48000 -     0x7fff8ef8fffb  libFontRegistry.dylib (127.0.1) <F267F500-6E4A-3BE3-97C1-08AAA649E02E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib
    0x7fff8ef90000 -     0x7fff8f12cff3  com.apple.QuartzCore (1.8 - 332.4) <CFB972D1-FA37-380C-9A47-2A67A84B7442> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
    0x7fff8f12d000 -     0x7fff8f134fff  libcompiler_rt.dylib (35) <4CD916B2-1B17-362A-B403-EF24A1DAC141> /usr/lib/system/libcompiler_rt.dylib
    0x7fff8f194000 -     0x7fff8f199ff7  libunwind.dylib (35.3) <78DCC358-2FC1-302E-B395-0155B47CB547> /usr/lib/system/libunwind.dylib
    0x7fff8f228000 -     0x7fff8f22cfff  com.apple.CommonPanels (1.2.6 - 96) <6B434AFD-50F8-37C7-9A56-162C17E375B3> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels
    0x7fff8f249000 -     0x7fff8f24cff7  libdyld.dylib (239.4) <41077DD7-F909-3B8A-863E-72AE304EDE13> /usr/lib/system/libdyld.dylib
    0x7fff8f3f8000 -     0x7fff8f46bfff  com.apple.securityfoundation (6.0 - 55122.3) <0FDC8F53-104C-3938-A852-5B33C30BAAD5> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
    0x7fff8f46c000 -     0x7fff8f46cff7  libkeymgr.dylib (28) <3AA8D85D-CF00-3BD3-A5A0-E28E1A32A6D8> /usr/lib/system/libkeymgr.dylib
    0x7fff8f46d000 -     0x7fff8f4d1fff  com.apple.datadetectorscore (5.0 - 354.5) <C9FAB401-3FE2-3221-B60C-E4F1841CA5F1> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore
    0x7fff8f567000 -     0x7fff8f6d5ff7  libBLAS.dylib (1094.5) <DE93A590-5FA5-32A2-A16C-5D7D7361769F> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
    0x7fff8f754000 -     0x7fff8f7a5ff7  com.apple.audio.CoreAudio (4.2.1 - 4.2.1) <BE13E840-FB45-3BC2-BCF5-031629754FD5> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
    0x7fff8f7a6000 -     0x7fff8f7b1fff  libkxld.dylib (2422.115.14) <1317F07F-AD7C-397A-9935-26413D641F08> /usr/lib/system/libkxld.dylib
    0x7fff8f7b2000 -     0x7fff8f7b6fff  libpam.2.dylib (20) <B93CE8F5-DAA8-30A1-B1F6-F890509513CB> /usr/lib/libpam.2.dylib
    0x7fff8fab8000 -     0x7fff8fabbffa  libCGXType.A.dylib (599.35.8) <0EDC72E5-751B-35B0-B14F-E449C3AEA3F9> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib
    0x7fff8fabc000 -     0x7fff8fc57ff8  com.apple.CFNetwork (673.6 - 673.6) <CAA196FE-BF5A-384F-975E-E0F81359805B> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
    0x7fff8fd2a000 -     0x7fff8fee2ffb  libicucore.A.dylib (511.35) <6F097DA7-147C-32A1-93D2-728A64CF0DC2> /usr/lib/libicucore.A.dylib
    0x7fff8ff77000 -     0x7fff8ff7dff7  libsystem_platform.dylib (24.90.1) <3C3D3DA8-32B9-3243-98EC-D89B9A1670B3> /usr/lib/system/libsystem_platform.dylib
    0x7fff8ffda000 -     0x7fff902aefc7  com.apple.vImage (7.0 - 7.0) <D241DBFA-AC49-31E2-893D-EAAC31890C90> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
    0x7fff902d6000 -     0x7fff902eeff7  com.apple.GenerationalStorage (2.0 - 160.3) <64749B08-0212-3AC8-9B49-73D662B09304> /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/GenerationalStorage
    0x7fff90309000 -     0x7fff9031bfff  com.apple.ImageCapture (9.0 - 9.0) <BE0B65DA-3031-359B-8BBA-B9803D4ADBF4> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture
    0x7fff9036d000 -     0x7fff903bffff  libc++.1.dylib (120) <4F68DFC5-2077-39A8-A449-CAC5FDEE7BDE> /usr/lib/libc++.1.dylib
    0x7fff906a3000 -     0x7fff90753ff7  libvMisc.dylib (423.32) <049C0735-1808-39B9-943F-76CB8021744F> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
    0x7fff90754000 -     0x7fff90756ff7  com.apple.securityhi (9.0 - 55005) <9985032A-0EE1-3760-8D23-ADD3965A4D18> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
    0x7fff90763000 -     0x7fff9076dfff  libcommonCrypto.dylib (60049) <8C4F0CA0-389C-3EDC-B155-E62DD2187E1D> /usr/lib/system/libcommonCrypto.dylib
    0x7fff9076e000 -     0x7fff9076fff7  libDiagnosticMessagesClient.dylib (100) <4CDB0F7B-C0AF-3424-BC39-495696F0DB1E> /usr/lib/libDiagnosticMessagesClient.dylib
    0x7fff90770000 -     0x7fff90771ffb  libremovefile.dylib (33) <3543F917-928E-3DB2-A2F4-7AB73B4970EF> /usr/lib/system/libremovefile.dylib
    0x7fff90772000 -     0x7fff907fbfff  com.apple.ColorSync (4.9.0 - 4.9.0) <B756B908-9AD1-3F5D-83F9-7A0B068387D2> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync
    0x7fff907fc000 -     0x7fff9082bff9  com.apple.GSS (4.0 - 2.0) <27FCA2B4-0767-3002-8755-862B19B5CF92> /System/Library/Frameworks/GSS.framework/Versions/A/GSS
    0x7fff90a03000 -     0x7fff90a1ffff  libresolv.9.dylib (54) <11C2C826-F1C6-39C6-B4E8-6E0C41D4FA95> /usr/lib/libresolv.9.dylib
    0x7fff90a20000 -     0x7fff90a97fff  com.apple.CoreServices.OSServices (600.4 - 600.4) <5A44F0B5-4A24-3875-ADE4-5B47D6C7E251> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
    0x7fff90af7000 -     0x7fff90bdbff7  com.apple.coreui (2.2 - 231.1) <187DF89C-8A64-366D-8782-F90315FA3CD7> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
    0x7fff90bdc000 -     0x7fff90c08fff  com.apple.CoreServicesInternal (184.9 - 184.9) <4DEA54F9-81D6-3EDB-AA3C-1F9C497B3379> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal
    0x7fff90c09000 -     0x7fff90ccbffd  com.apple.CoreText (367.20 - 367.21) <D19B18DD-62DD-3C9C-B232-D68E206753C5> /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText
    0x7fff90cce000 -     0x7fff90ccefff  com.apple.ApplicationServices (48 - 48) <3E3F01A8-314D-378F-835E-9CC4F8820031> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
    0x7fff90e09000 -     0x7fff90e95ff7  com.apple.ink.framework (10.9 - 207) <8A50B893-AD03-3826-8555-A54FEAF08F47> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
    0x7fff90e96000 -     0x7fff90eb0fff  libdispatch.dylib (339.92.1) <C4E4A18D-3C3B-3C9C-8709-A4270D998DE7> /usr/lib/system/libdispatch.dylib
    0x7fff90eb1000 -     0x7fff90eeaff7  com.apple.QD (3.50 - 298) <C1F20764-DEF0-34CF-B3AB-AB5480D64E66> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
    0x7fff90eeb000 -     0x7fff90f12ffb  libsystem_info.dylib (449.1.3) <7D41A156-D285-3849-A2C3-C04ADE797D98> /usr/lib/system/libsystem_info.dylib
    0x7fff90f13000 -     0x7fff90f1efff  libGL.dylib (9.6.1) <4B65BF9F-F34A-3CD1-94E8-DB26DAA0A59D> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
    0x7fff90f6a000 -     0x7fff90f75ff7  com.apple.NetAuth (5.0 - 5.0) <C811E662-9EC3-3B74-808A-A75D624F326B> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth
    0x7fff90f76000 -     0x7fff90f7aff7  libheimdal-asn1.dylib (323.92.2) <979AEAA0-59B3-3E99-94B1-9BB9C6C45273> /usr/lib/libheimdal-asn1.dylib
    0x7fff90f7b000 -     0x7fff90f87ff7  com.apple.OpenDirectory (10.9 - 173.90.1) <F08601E8-F7E8-3222-AD05-6A26003779CF> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
    0x7fff9101c000 -     0x7fff911c9f27  libobjc.A.dylib (551.1) <AD7FD984-271E-30F4-A361-6B20319EC73B> /usr/lib/libobjc.A.dylib
    0x7fff912bb000 -     0x7fff9134bff7  com.apple.Metadata (10.7.0 - 800.30) <E107CE36-FBC3-35A5-84E0-864B4178FC5D> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
    0x7fff91830000 -     0x7fff91859ff7  libc++abi.dylib (49.1) <21A807D3-6732-3455-B77F-743E9F916DF0> /usr/lib/libc++abi.dylib
    0x7fff9185a000 -     0x7fff91861ff7  libsystem_pthread.dylib (53.1.4) <AB498556-B555-310E-9041-F67EC9E00E2C> /usr/lib/system/libsystem_pthread.dylib
    0x7fff91cd6000 -     0x7fff91d5fff7  libsystem_c.dylib (997.90.3) <6FD3A400-4BB2-3B95-B90C-BE6E9D0D78FA> /usr/lib/system/libsystem_c.dylib
    0x7fff91d60000 -     0x7fff91d67fff  com.apple.NetFS (6.0 - 4.0) <8E26C099-CE9D-3819-91A2-64EA929C6137> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
    0x7fff91d68000 -     0x7fff91dc3ffb  com.apple.AE (665.5 - 665.6) <9B17E7B7-D493-346A-827E-6DF1474E4977> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
    0x7fff91dc4000 -     0x7fff91e0bff7  libcups.2.dylib (372.6) <CBD2F0CF-FA10-36E1-A1D5-1B946B45B3B3> /usr/lib/libcups.2.dylib
    0x7fff91e0c000 -     0x7fff91e51ff6  com.apple.HIServices (1.23 - 468) <A4E9E28B-95C3-3654-85C6-E6A1C53CACFE> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
    0x7fff91f00000 -     0x7fff91f24ff7  libJPEG.dylib (1046) <C0EC0092-CEBA-3C87-822F-2CB7255C739D> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
    0x7fff92488000 -     0x7fff9248cff7  libcache.dylib (62) <BDC1E65B-72A1-3DA3-A57C-B23159CAAD0B> /usr/lib/system/libcache.dylib
    0x7fff92490000 -     0x7fff92db005f  com.apple.CoreGraphics (1.600.0 - 599.35.8) <44C2B90C-9B45-3862-9D8F-E0F850E93EE2> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
    0x7fff92e8f000 -     0x7fff92ea0ff7  libz.1.dylib (53) <42E0C8C6-CA38-3CA4-8619-D24ED5DD492E> /usr/lib/libz.1.dylib
    0x7fff92ea1000 -     0x7fff92f6bff7  com.apple.LaunchServices (572.32 - 572.32) <A4699DED-5101-3068-94F8-8D0B7A84BC79> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
    0x7fff92f6c000 -     0x7fff92f76ff7  com.apple.CrashReporterSupport (10.9 - 539) <B25A09EC-A021-32EC-86F8-05B4837E0EDE> /System/Library/PrivateFrameworks/CrashReporterSupport.framework/Versions/A/CrashReporterSupport
    0x7fff9348b000 -     0x7fff9348dff7  libquarantine.dylib (71) <7A1A2BCB-C03D-3A25-BFA4-3E569B2D2C38> /usr/lib/system/libquarantine.dylib
    0x7fff9348e000 -     0x7fff9348fff7  com.apple.print.framework.Print (9.0 - 260) <EE00FAE1-DA03-3EC2-8571-562518C46994> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
    0x7fff93490000 -     0x7fff93596ff7  com.apple.ImageIO.framework (3.3.0 - 1046) <3E7720A1-8902-36F1-A8A4-870ADBF165DD> /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
    0x7fff935de000 -     0x7fff935e6ff3  libCGCMS.A.dylib (599.35.8) <5BB7FAF6-C300-33CD-A666-EAC23911B4D8> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGCMS.A.dylib
    0x7fff93948000 -     0x7fff93a39ff9  libiconv.2.dylib (41) <BB44B115-AC32-3877-A0ED-AEC6232A4563> /usr/lib/libiconv.2.dylib
    0x7fff93b76000 -     0x7fff93b84fff  com.apple.opengl (9.6.1 - 9.6.1) <359D0ECB-D100-341B-B437-BDE56E27B74B> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
    0x7fff93ba8000 -     0x7fff93bb5fff  com.apple.Sharing (132.2 - 132.2) <F983394A-226D-3244-B511-FA51FDB6ADDA> /System/Library/PrivateFrameworks/Sharing.framework/Versions/A/Sharing
    0x7fff93e9a000 -     0x7fff93e9afff  com.apple.Accelerate (1.9 - Accelerate 1.9) <509BB27A-AE62-366D-86D8-0B06D217CF56> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
    0x7fff93e9b000 -     0x7fff93fcbff7  com.apple.desktopservices (1.8.3 - 1.8.3) <225BEC20-F8E0-3F22-9560-890A1A5B9050> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
    0x7fff94401000 -     0x7fff94404fff  com.apple.TCC (1.0 - 1) <32A075D9-47FD-3E71-95BC-BFB0D583F41C> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC
    0x7fff944ef000 -     0x7fff94643ff3  com.apple.audio.toolbox.AudioToolbox (1.10 - 1.10) <69B273E8-5A8E-3FC7-B807-C16B657662FE> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
    0x7fff94698000 -     0x7fff94786fff  libJP2.dylib (1046) <4C2E5C60-7196-3EBB-BE34-1B891AB4F832> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib
    0x7fff94787000 -     0x7fff947b6fd2  libsystem_m.dylib (3047.16) <B7F0E2E4-2777-33FC-A787-D6430B630D54> /usr/lib/system/libsystem_m.dylib
    0x7fff947b7000 -     0x7fff947c1ff7  com.apple.bsd.ServiceManagement (2.0 - 2.0) <2D27B498-BB9C-3D88-B05A-76908A8A26F3> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement
    0x7fff94803000 -     0x7fff9481eff7  libsystem_malloc.dylib (23.10.1) <A695B4E4-38E9-332E-A772-29D31E3F1385> /usr/lib/system/libsystem_malloc.dylib
    0x7fff9481f000 -     0x7fff9486cff2  com.apple.print.framework.PrintCore (9.0 - 428) <8D8253E3-302F-3DB2-9C5C-572CB974E8B3> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
    0x7fff9486d000 -     0x7fff94871ff7  libGIF.dylib (1046) <2E609CC1-0A2F-370D-8694-A1138D2F2593> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
    0x7fff94875000 -     0x7fff94890ff7  libPng.dylib (1046) <4B2D1356-D82C-3052-9241-EF86DD725804> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
    0x7fff94891000 -     0x7fff94896fff  libmacho.dylib (845) <1D2910DF-C036-3A82-A3FD-44FF73B5FF9B> /usr/lib/system/libmacho.dylib
    0x7fff94ead000 -     0x7fff94efbff7  com.apple.opencl (2.3.59 - 2.3.59) <9F43F471-C3C3-352D-889D-EC418DC1F5B2> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
    0x7fff94efc000 -     0x7fff94f21ff7  com.apple.ChunkingLibrary (2.0 - 155.1) <B845DC7A-D1EA-31E2-967C-D1FE0C628036> /System/Library/PrivateFrameworks/ChunkingLibrary.framework/Versions/A/ChunkingLibrary
    0x7fff94f22000 -     0x7fff94f87ffb  com.apple.Heimdal (4.0 - 2.0) <C28DBCAE-01AC-363A-9046-3BD33F225526> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal
    0x7fff94f88000 -     0x7fff94f9aff7  com.apple.MultitouchSupport.framework (245.13.1 - 245.13.1) <38262B92-C63F-35A0-997D-AD2EBF2F8338> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport
    0x7fff95cac000 -     0x7fff95cdcfff  com.apple.IconServices (25 - 25.17) <4751127E-FBD5-3ED5-8510-08D4E4166EFE> /System/Library/PrivateFrameworks/IconServices.framework/Versions/A/IconServices
    0x7fff95f6e000 -     0x7fff95f76fff  libsystem_dnssd.dylib (522.92.1) <3F8C6A07-3046-3E88-858F-D9CEFC43A405> /usr/lib/system/libsystem_dnssd.dylib
    0x7fff95f77000 -     0x7fff95fcafff  com.apple.ScalableUserInterface (1.0 - 1) <CF745298-7373-38D2-B3B1-727D5A569E48> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/ScalableUserInterface.framework/Versions/A/ScalableUserInterface
    0x7fff95fcb000 -     0x7fff9629cff4  com.apple.CoreImage (9.4.0) <2C636ECD-0F1A-357C-9EFF-0452476FDDF5> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/CoreImage.framework/Versions/A/CoreImage
    0x7fff962d3000 -     0x7fff962dcffd  com.apple.CommonAuth (4.0 - 2.0) <BD720379-757B-305C-A7BE-E00E680F8218> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth
    0x7fff962dd000 -     0x7fff962e9ffb  com.apple.AppleFSCompression (56.92.2 - 1.0) <16542F97-9D21-317D-8A50-4C34AAD35F41> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression
    0x7fff962ea000 -     0x7fff962ebfff  liblangid.dylib (117) <9546E641-F730-3AB0-B3CD-E0E2FDD173D9> /usr/lib/liblangid.dylib
    0x7fff9633f000 -     0x7fff96363fff  libxpc.dylib (300.90.2) <AB40CD57-F454-3FD4-B415-63B3C0D5C624> /usr/lib/system/libxpc.dylib
    0x7fff96364000 -     0x7fff9637fff7  libCRFSuite.dylib (34) <FFAE75FA-C54E-398B-AA97-18164CD9789D> /usr/lib/libCRFSuite.dylib
    0x7fff964d6000 -     0x7fff96524fff  libcorecrypto.dylib (161.1) <F3973C28-14B6-3006-BB2B-00DD7F09ABC7> /usr/lib/system/libcorecrypto.dylib
    0x7fff96525000 -     0x7fff9670afff  com.apple.CoreFoundation (6.9 - 855.17) <729BD6DA-1F63-3E72-A148-26F21EBF52BB> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fff96973000 -     0x7fff969e0ff1  com.apple.ApplicationServices.ATS (360 - 363.6) <96F5E308-5B56-3A5F-870D-FC7240242BA0> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
    0x7fff97be8000 -     0x7fff97bf5ff7  libxar.1.dylib (202) <5572AA71-E98D-3FE1-9402-BB4A84E0E71E> /usr/lib/libxar.1.dylib
    0x7fff97c1d000 -     0x7fff97c20fff  libCoreVMClient.dylib (58.1) <EBC36C69-C896-3C3D-8589-3E9023E7E56F> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib
    0x7fff97d66000 -     0x7fff97d68fff  libRadiance.dylib (1046) <6D0D961B-AC2D-3C8C-A44B-82DAA615C019> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
    0x7fff97df6000 -     0x7fff97df7fff  libunc.dylib (28) <62682455-1862-36FE-8A04-7A6B91256438> /usr/lib/system/libunc.dylib
    0x7fff97e37000 -     0x7fff97e39fff  libCVMSPluginSupport.dylib (9.6.1) <B724E444-6FAE-31B5-9814-1572517229C6> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib
    0x7fff97f16000 -     0x7fff97f3dff7  libsystem_network.dylib (241.4) <0D630D53-C772-3EC5-8257-EFB0ACCE3153> /usr/lib/system/libsystem_network.dylib
    0x7fff981d9000 -     0x7fff981f2ff7  com.apple.Ubiquity (1.3 - 289) <C7F1B734-CE81-334D-BE41-8B20D95A1F9B> /System/Library/PrivateFrameworks/Ubiquity.framework/Versions/A/Ubiquity
    0x7fff98219000 -     0x7fff985faffe  libLAPACK.dylib (1094.5) <7E7A9B8D-1638-3914-BAE0-663B69865986> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
    0x7fff9868b000 -     0x7fff98698ff0  libbz2.1.0.dylib (29) <0B98AC35-B138-349C-8063-2B987A75D24C> /usr/lib/libbz2.1.0.dylib
    0x7fff988c5000 -     0x7fff988c9ff7  libsystem_stats.dylib (93.90.3) <C588E082-D94B-3510-9F9A-7AD83B3402DE> /usr/lib/system/libsystem_stats.dylib
    0x7fff988d4000 -     0x7fff988edff7  com.apple.Kerberos (3.0 - 1) <F108AFEB-198A-3BAF-BCA5-9DFCE55EFF92> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
    0x7fff98ae6000 -     0x7fff98aeffff  com.apple.speech.synthesis.framework (4.7.1 - 4.7.1) <383FB557-E88E-3239-82B8-15F9F885B702> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
    0x7fff98b00000 -     0x7fff98beafff  libsqlite3.dylib (158) <00269BF9-43BE-39E0-9C85-24585B9923C8> /usr/lib/libsqlite3.dylib
    0x7fff98beb000 -     0x7fff98becff7  libSystem.B.dylib (1197.1.1) <70B235FC-BCED-367B-BA6C-67C299BAE7D9> /usr/lib/libSystem.B.dylib
    0x7fff98bfb000 -     0x7fff98bfeffc  com.apple.IOSurface (91.2 - 91.2) <4B2308B5-3F40-33BB-851C-A2A168343F6D> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface
    0x7fff98c08000 -     0x7fff98cd3fff  libvDSP.dylib (423.32) <3BF732BE-DDE0-38EB-8C54-E4E3C64F77A7> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
    0x7fff98d20000 -     0x7fff98d5bfff  com.apple.bom (14.0 - 193.1) <EF24A562-6D3C-379E-8B9B-FAE0E4A0EF7C> /System/Library/PrivateFrameworks/Bom.framework/Versions/A/Bom
    0x7fff99620000 -     0x7fff9968cfff  com.apple.framework.IOKit (2.0.1 - 907.100.14) <10932113-9F7E-38A0-A158-A019A555CAC3> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 4318
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 987235
    thread_create: 5
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=172.2M resident=99.9M(58%) swapped_out_or_unallocated=72.3M(42%)
Writable regions: Total=2.1G written=2.0G(97%) resident=2.0G(99%) swapped_out=0K(0%) unallocated=27.6M(1%)
 
REGION TYPE                      VIRTUAL
===========                      =======
Dispatch continuations             8192K
Kernel Alloc Once                     8K
MALLOC                              2.0G
MALLOC (admin)                       32K
STACK GUARD                        56.0M
Stack                              12.1M
VM_ALLOCATE                         716K
__DATA                             10.8M
__LINKEDIT                         74.9M
__TEXT                             97.3M
__UNICODE                           544K
mapped file                        27.3M
shared memory                         4K
===========                      =======
TOTAL                               2.3G

Model: MacBookPro11,1, BootROM MBP111.0138.B11, 2 processors, Intel Core i5, 2.8 GHz, 16 GB, SMC 2.16f68
Graphics: Intel Iris, Intel Iris, Built-In
Memory Module: BANK 0/DIMM0, 8 GB, DDR3, 1600 MHz, 0x80AD, 0x484D54343147533641465238412D50422020
Memory Module: BANK 1/DIMM0, 8 GB, DDR3, 1600 MHz, 0x80AD, 0x484D54343147533641465238412D50422020
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x112), Broadcom BCM43xx 1.0 (6.30.223.154.65)
Bluetooth: Version 5.2.7f4 15858, 3 services, 23 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
Network Service: VPN (Full Tunnel), IPSec, utun0
Serial ATA Device: APPLE SSD SM0512F, 500.28 GB
USB Device: Internal Memory Card Reader
USB Device: Apple Internal Keyboard / Trackpad
USB Device: BRCM20702 Hub
USB Device: Bluetooth USB Host Controller
Thunderbolt Bus: MacBook Pro, Apple Inc., 17.2

----------
components: Macintosh
messages: 252492
nosy: candreas, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Segmentation fault on Mavericks consistent crashing of software: Please HELP!!!!!
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct  8 04:20:40 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 08 Oct 2015 02:20:40 +0000
Subject: [New-bugs-announce] [issue25337] weakref.finalize documentation
 refers to old interpreter shutdown behavior
Message-ID: <1444270840.16.0.813580393824.issue25337@psf.upfronthosting.co.za>


New submission from Josh Rosenberg:

In weakref.finalize's documentation ( https://docs.python.org/3/library/weakref.html#weakref.finalize ), it says:

"A finalizer will never invoke its callback during the later part of the interpreter shutdown when module globals are liable to have been replaced by None."

While it may not invoke its callback during shutdown (I don't know if it does, or if it should), as of Python 3.4 (which is when weakref.finalize was introduced), module globals aren't set to None anymore, right? https://docs.python.org/3/whatsnew/3.4.html#whatsnew-pep-442

Presumably the docs should be updated not to mention a behavior that no longer occurs (and if it will or should be invoked, weakref.finalizer should have documentation or code updated).

----------
assignee: docs at python
components: Documentation
messages: 252504
nosy: docs at python, josh.r
priority: normal
severity: normal
status: open
title: weakref.finalize documentation refers to old interpreter shutdown behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Oct  8 07:05:21 2015
From: report at bugs.python.org (Jung-chih Wei)
Date: Thu, 08 Oct 2015 05:05:21 +0000
Subject: [New-bugs-announce] [issue25338] urllib fail to check host whether
	it should be bypassed
Message-ID: <1444280721.33.0.78593437261.issue25338@psf.upfronthosting.co.za>


New submission from Jung-chih Wei:

Windows could append a empty host in ProxyOverride list.
Then, proxy_bypass_registry() will return true for any host.

----------
components: Windows
messages: 252510
nosy: Jung-chih Wei, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: urllib fail to check host whether it should be bypassed
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/issue25338>
_______________________________________

From report at bugs.python.org  Thu Oct  8 08:51:28 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Oct 2015 06:51:28 +0000
Subject: [New-bugs-announce] [issue25339] sys.stdout.errors is set to
	"surrogateescape"
Message-ID: <1444287088.0.0.588605250096.issue25339@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The error handler of sys.stdout and sys.stdin is set to "surrogateescape" even for non-ASCII encoding.

$ LANG= PYTHONIOENCODING=UTF-8 ./python -c 'import sys; print(sys.stdout.encoding, sys.stdout.errors)'
UTF-8 surrogateescape

----------
components: IO
messages: 252515
nosy: haypo, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
status: open
title: sys.stdout.errors is set to "surrogateescape"
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Oct  8 09:32:36 2015
From: report at bugs.python.org (Guillaume DAVY)
Date: Thu, 08 Oct 2015 07:32:36 +0000
Subject: [New-bugs-announce] [issue25340] libraries variable in setup.py
 ignore for multiprocessing module
Message-ID: <1444289556.93.0.862916307871.issue25340@psf.upfronthosting.co.za>


New submission from Guillaume DAVY:

Around line 1455 in setup.py the "libraries" variable is assigned but
seems to be ignored when the Extension object for multiprocessing
is created. This leads to a linking error on my system : "undefined symbol: clock_gettime"

----------
components: Installation
messages: 252517
nosy: davyg
priority: normal
severity: normal
status: open
title: libraries variable in setup.py ignore for multiprocessing module
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct  8 09:42:58 2015
From: report at bugs.python.org (Mark Williams)
Date: Thu, 08 Oct 2015 07:42:58 +0000
Subject: [New-bugs-announce] [issue25341] File mode wb+ appears as rb+
Message-ID: <1444290178.48.0.0607111061258.issue25341@psf.upfronthosting.co.za>


New submission from Mark Williams:

There is at least one mode in which a file can be opened that cannot be represented in its mode attribute: wb+.  This mode instead appears as 'rb+' in the mode attribute:

Python 3.5.0 (default, Oct  3 2015, 10:40:38)
[GCC 4.2.1 Compatible FreeBSD Clang 3.4.1 (tags/RELEASE_34/dot1-final 208032)] on freebsd10
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> if os.path.exists('some_file'): os.unlink('some_file')
...
>>> with open('some_file', 'r+b') as f: print(f.mode)
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
FileNotFoundError: [Errno 2] No such file or directory: 'some_file'
>>> with open('some_file', 'w+b') as f: print(f.mode)
...
rb+
>>> with open('some_file', 'r+b') as f: print(f.mode)
rb+


This means code that interacts with file objects cannot trust the mode of binary files.  For example, you can't use tempfile.TemporaryFile (the mode argument of which defaults to 'wb+') and GzipFile:


>>> import gzip
>>> from tempfile import TemporaryFile
>>> with TemporaryFile() as f:
...     gzip.GzipFile(fileobj=f).write(b'test')
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "/usr/local/lib/python3.5/gzip.py", line 249, in write
    raise OSError(errno.EBADF, "write() on read-only GzipFile object")
OSError: [Errno 9] write() on read-only GzipFile object


This occurs because without a mode argument passed to its initializer, GzipFile checks that the fp object's mode starts with 'w', 'a', or 'x'.

For the sake of completeness/searchability: w+ and r+ are different modes, so rb+ and wb+ must be different modes.  Per https://docs.python.org/3/library/functions.html#open :

"""
For binary read-write access, the mode 'w+b' opens and truncates the file to 0 bytes. 'r+b' opens the file without truncation.
"""


I haven't been able to test this on Windows, but I expect precisely the same behavior given my understanding of the relevant source.

_io_FileIO___init___impl in _io/fileio.c does the right thing and includes O_CREAT and O_TRUNC in the open(2) flags upon seeing 'w' in the mode:

https://hg.python.org/cpython/file/3.5/Modules/_io/fileio.c#l324

this ensures correct interaction with the file system.  But it also sets self->readable and self->writable upon seeing '+' in the mode:

https://hg.python.org/cpython/file/3.5/Modules/_io/fileio.c#l341

The open flags are not retained.  Consequently, when the mode attribute is accessed and the get_mode calls the mode_string function, the instance has insufficient information to differentiate between 'rb+' and 'wb+':

https://hg.python.org/cpython/file/3.5/Modules/_io/fileio.c#l1043

If the FileIO instance did retain the 'flags' variable that's declared and set in its initializer, then mode_string could use it to determine the difference between wb+ and rb+.

I would be happy to write a patch for this.

----------
components: IO, Interpreter Core, Library (Lib)
messages: 252518
nosy: Mark.Williams
priority: normal
severity: normal
status: open
title: File mode wb+ appears as rb+
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Oct  8 13:57:39 2015
From: report at bugs.python.org (Remi Pointel)
Date: Thu, 08 Oct 2015 11:57:39 +0000
Subject: [New-bugs-announce] [issue25342] json
Message-ID: <1444305459.69.0.847555547745.issue25342@psf.upfronthosting.co.za>


Changes by Remi Pointel <python at xiri.fr>:


----------
nosy: rpointel
priority: normal
severity: normal
status: open
title: json

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

From report at bugs.python.org  Thu Oct  8 17:43:06 2015
From: report at bugs.python.org (Dima Tisnek)
Date: Thu, 08 Oct 2015 15:43:06 +0000
Subject: [New-bugs-announce] [issue25343] Document atomic operations on
	builtin types
Message-ID: <1444318986.11.0.257913016756.issue25343@psf.upfronthosting.co.za>


New submission from Dima Tisnek:

Please document what builtin type operations are actually atomic.
For example, what set() operations are atomic?

(There are some blogs / tutorials online, but information is outdated and not authoritative)

----------
messages: 252545
nosy: Dima.Tisnek
priority: normal
severity: normal
status: open
title: Document atomic operations on builtin types
versions: Python 3.6

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

From report at bugs.python.org  Thu Oct  8 19:05:58 2015
From: report at bugs.python.org (David Silverman)
Date: Thu, 08 Oct 2015 17:05:58 +0000
Subject: [New-bugs-announce] [issue25344] Enhancement to Logging - Logging
	Stack
Message-ID: <1444323958.12.0.353720924326.issue25344@psf.upfronthosting.co.za>


New submission from David Silverman:

It would be useful to have the ability to push logs onto a stack. This way you can log events to the stack. If an error occurred, you could pop the stack and output the log events. If no error occurred, you could pop the stack and discard the logs.

An example would be when you call a function it could push logs onto the log stack as the function is executing. If an error is encountered, you can pop/output the logs to provide more details. But, if no error is encountered, the detailed logs can be popped and discarded.

----------
components: Library (Lib)
messages: 252557
nosy: dasilver at cisco.com
priority: normal
severity: normal
status: open
title: Enhancement to Logging - Logging Stack
type: enhancement

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

From report at bugs.python.org  Thu Oct  8 19:41:08 2015
From: report at bugs.python.org (Gowtham Nm)
Date: Thu, 08 Oct 2015 17:41:08 +0000
Subject: [New-bugs-announce] [issue25345] Unable to install Python 3.5 on
	Windows 10
Message-ID: <1444326068.92.0.817766252718.issue25345@psf.upfronthosting.co.za>


New submission from Gowtham Nm:

I downloaded Python 3.5 version to install on Windows 10. But apparently, the installation does not succeed.
I have tried with lower version of Python also, the installation does not succeed on Windows 10.

Have attached the logs of the error. I have checked for the particular error code (seen in the screenshot attached) in various forums but none worked.

Looking forward to hear from your team.

----------
components: Windows
files: Python 3.5.0 (32-bit)_20151008230628.log
messages: 252563
nosy: Gowtham Nm, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Unable to install Python 3.5 on Windows 10
type: resource usage
versions: Python 3.5
Added file: http://bugs.python.org/file40721/Python 3.5.0 (32-bit)_20151008230628.log

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

From report at bugs.python.org  Thu Oct  8 20:37:21 2015
From: report at bugs.python.org (Anish Shah)
Date: Thu, 08 Oct 2015 18:37:21 +0000
Subject: [New-bugs-announce] [issue25346] test_regrtest fails because 'sys'
	is not imported.
Message-ID: <1444329441.39.0.356644133094.issue25346@psf.upfronthosting.co.za>


Changes by Anish Shah <shah.anish07 at gmail.com>:


----------
components: Tests
files: test_regrtest.patch
keywords: patch
nosy: Anish Shah, python-dev, steve.dower
priority: normal
severity: normal
status: open
title: test_regrtest fails because 'sys' is not imported.
versions: Python 3.6
Added file: http://bugs.python.org/file40722/test_regrtest.patch

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

From report at bugs.python.org  Fri Oct  9 00:08:43 2015
From: report at bugs.python.org (Robert Zimmerman)
Date: Thu, 08 Oct 2015 22:08:43 +0000
Subject: [New-bugs-announce] [issue25347] assert_has_calls output is
	formatted inconsistently
Message-ID: <1444342123.9.0.512399656595.issue25347@psf.upfronthosting.co.za>


New submission from Robert Zimmerman:

For longer lists of calls, the "Expected" list is printed all on one line while the "Actual" list is pprinted and on multiple lines. This makes it hard to do a visual compare of which calls are missing/incorrect.

Example:

    AssertionError: Calls not found.
    Expected: [call('bbbbbbbbbbbbbbbbbbbb'), call('bbbbbbbbbbbbbbbbbbbb'), call('bbbbbbbbbbbbbbbbbbbb'), call('bbbbbbbbbbbbbbbbbbbb'), call('bbbbbbbbbbbbbbbbbbbb'), call('bbbbbbbbbbbbbbbbbbbb'), call('bbbbbbbbbbbbbbbbbbbb')]
    Actual: [call('aaaaaaaaaaaaaaaaaaa'),
     call('aaaaaaaaaaaaaaaaaaa'),
     call('aaaaaaaaaaaaaaaaaaa'),
     call('aaaaaaaaaaaaaaaaaaa'),
     call('aaaaaaaaaaaaaaaaaaa'),
     call('aaaaaaaaaaaaaaaaaaa'),
     call('aaaaaaaaaaaaaaaaaaa')]


What I'd expect:

    AssertionError: Calls not found.
    Expected: [call('bbbbbbbbbbbbbbbbbbbb'),
     call('bbbbbbbbbbbbbbbbbbbb'),
     call('bbbbbbbbbbbbbbbbbbbb'),
     call('bbbbbbbbbbbbbbbbbbbb'),
     call('bbbbbbbbbbbbbbbbbbbb'),
     call('bbbbbbbbbbbbbbbbbbbb'),
     call('bbbbbbbbbbbbbbbbbbbb')]
    Actual: [call('aaaaaaaaaaaaaaaaaaa'),
     call('aaaaaaaaaaaaaaaaaaa'),
     call('aaaaaaaaaaaaaaaaaaa'),
     call('aaaaaaaaaaaaaaaaaaa'),
     call('aaaaaaaaaaaaaaaaaaa'),
     call('aaaaaaaaaaaaaaaaaaa'),
     call('aaaaaaaaaaaaaaaaaaa')]

----------
components: Tests
files: mock_assert_has_calls.patch
keywords: patch
messages: 252569
nosy: michael.foord, rzimmerman
priority: normal
severity: normal
status: open
title: assert_has_calls output is formatted inconsistently
type: enhancement
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/file40723/mock_assert_has_calls.patch

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

From report at bugs.python.org  Fri Oct  9 01:17:25 2015
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 08 Oct 2015 23:17:25 +0000
Subject: [New-bugs-announce] [issue25348] Update pgo_build.bat to use --pgo
	flag for regrtest
Message-ID: <1444346245.0.0.569960292546.issue25348@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Should upgrade the command to do what is already occurring in the Makefile for consistency.

----------
assignee: brett.cannon
components: Windows
messages: 252572
nosy: brett.cannon, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Update pgo_build.bat to use --pgo flag for regrtest
versions: Python 3.6

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

From report at bugs.python.org  Fri Oct  9 02:50:25 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Oct 2015 00:50:25 +0000
Subject: [New-bugs-announce] [issue25349] Use _PyBytesWriter for bytes%args
Message-ID: <1444351825.62.0.273684816362.issue25349@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch is a work-in-progress patch to use the new private _PyBytesWriter API in bytes % args.

The usage of the _PyBytesWriter API will allow further optimization. For example, it avoids the creation of a temporary bytes object to format b'%f' % 1.2.

The _PyBytesWriter API allocates a small buffer of 512 bytes on the stack to delay the allocation of the final bytes objects. It can avoid the need to call _PyBytes_Resize() completly, or at least reduce the number of calls.

See also the issue #25318 which added the _PyBytesWriter API.

----------
files: bytes_format.patch
keywords: patch
messages: 252577
nosy: ethan.furman, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Use _PyBytesWriter for bytes%args
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file40724/bytes_format.patch

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

From report at bugs.python.org  Fri Oct  9 08:08:07 2015
From: report at bugs.python.org (John Michael Lafayette)
Date: Fri, 09 Oct 2015 06:08:07 +0000
Subject: [New-bugs-announce] [issue25350] Stronger type enforcement (feature
	request)
Message-ID: <1444370887.78.0.708610207347.issue25350@psf.upfronthosting.co.za>


New submission from John Michael Lafayette:

With a lot of languages, I can tell
that the type I am getting is an instance of the declared type I'm assigning it to.

Example:
Cat c = Factory.make("cat"
Animal d = Factory.make("dog")

Python:
val c = Factory.make("cat")

Problem with this is that it is not necessarily obvious to the reader what the type of c is. I suggest that you provide an option to strengthen python's type checking by allowing users to replace val with the expected type of the object and then allow the interpreter to check that the real type being assigned is an instance of the expected type. An option like -strong for strong typing.

----------
messages: 252588
nosy: John Michael Lafayette
priority: normal
severity: normal
status: open
title: Stronger type enforcement (feature request)
type: enhancement

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

From report at bugs.python.org  Fri Oct  9 09:23:57 2015
From: report at bugs.python.org (s-wakaba)
Date: Fri, 09 Oct 2015 07:23:57 +0000
Subject: [New-bugs-announce] [issue25351] pyvenv activate script failure
	with specific bash option
Message-ID: <1444375437.08.0.147131311455.issue25351@psf.upfronthosting.co.za>


New submission from s-wakaba:

When writing bash shellscripts, I always set options "set -ueC" for strict error checking. However, loading pyvenv's activate and deactivate scripts from bash with "-u" option, they are failure because they may refer undefined shell variables.

I hope activate script and deactivate function are enclosed like following block

_OLD_BASH_OPTIONS="$-"
set +u

### script body ##

set -$_OLD_BASH_OPTIONS
unset _OLD_BASH_OPTIONS


Another option, all shell-variables in the script change like

$SPAM -> ${SPAM:-}

----------
components: Library (Lib)
messages: 252593
nosy: s-wakaba
priority: normal
severity: normal
status: open
title: pyvenv activate script failure with specific bash option
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Fri Oct  9 11:13:25 2015
From: report at bugs.python.org (Laura Creighton)
Date: Fri, 09 Oct 2015 09:13:25 +0000
Subject: [New-bugs-announce] [issue25352] Add 'make this my default python'
 to windows installs for Python3.5 and later
Message-ID: <1444382005.62.0.6522456142.issue25352@psf.upfronthosting.co.za>


New submission from Laura Creighton:

webmaster is hearing from children who have downloaded 3.5 but who
are still getting 2.7 when they click on desktop Python icons, and
type python at a console prompt.

a checkbox on the installer saying 'make this my default python' that
would then go off any do all that is necessary in this regard would
make their lives easier.

----------
components: Installation, Windows
messages: 252595
nosy: lac, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Add 'make this my default python' to windows installs for Python3.5 and later
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Oct  9 14:13:42 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Oct 2015 12:13:42 +0000
Subject: [New-bugs-announce] [issue25353] Use _PyBytesWriter for unicode
 escape and raw unicode escape encoders
Message-ID: <1444392822.73.0.0714587534509.issue25353@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch modifies unicode escape and raw unicode escape encoders to use the new _PyBytesWriter API.

The patch is optimized to encode Latin1 characters: encoding Latin1 characters when no character is escaped should not have to call _PyByte_Resize() at all.

When characters are escaped or a BMP or non-BMP string is encoded, overallocation is used to reduce the number of _PyByte_Resize(). It uses _PyBytesWriter overallocation strategy instead of always overallocate for the worst case.

_PyBytesWriter also embeds a small buffer allocated on the stack which also avoids calls to _PyBytes_Resize() when the output fits into 512 bytes.

----------
files: unicode_escape.patch
keywords: patch
messages: 252599
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Use _PyBytesWriter for unicode escape and raw unicode escape encoders
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file40727/unicode_escape.patch

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

From report at bugs.python.org  Fri Oct  9 15:31:46 2015
From: report at bugs.python.org (shanmbic)
Date: Fri, 09 Oct 2015 13:31:46 +0000
Subject: [New-bugs-announce] [issue25354] test_datetime failing
Message-ID: <1444397506.38.0.258649046467.issue25354@psf.upfronthosting.co.za>


New submission from shanmbic:

The test for datetime module keeps failing. 

test test_datetime failed -- Traceback (most recent call last):
  File "/home/shantanu/cpython/Lib/test/datetimetester.py", line 215, in test_issue23600
    self.assertEqual(t - t.utcoffset(), u)
AssertionError: datet[22 chars]26, 11, 1, tzinfo=<test.datetimetester.TestTZI[63 chars]538>) != datet[22 chars]26, 12, 1, tzinfo=<test.datetimetester.TestTZI[63 chars]538>)

In datetimetester.py , in function test_issue23600 , line 196:
the variable DSTDIFF has been assigned timedelta of 1 hour, I guess it should be , 

DSTDIFF = timedelta(hours=0)

It passes the test then. 

The comment in the function code says -  
"""Simple time zone which pretends to always be in summer time, since that's what shows the failure.""" Was the test written to fail on purpose ?  

Thanks

----------
components: Extension Modules, ctypes
messages: 252609
nosy: shanmbic
priority: normal
severity: normal
status: open
title: test_datetime failing
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Oct  9 17:06:17 2015
From: report at bugs.python.org (Oscar Benjamin)
Date: Fri, 09 Oct 2015 15:06:17 +0000
Subject: [New-bugs-announce] [issue25355] Windows 3.5 installer does not add
 python to "App Paths" key
Message-ID: <1444403177.17.0.586172886506.issue25355@psf.upfronthosting.co.za>


New submission from Oscar Benjamin:

>From the mailing list:
https://mail.python.org/pipermail/python-list/2015-October/697744.html

'''
The new installer for 3.5 doesn't create an "App Paths" key for
"python.exe" like the old installer used to do (see the old
Tools/msi/msi.py). Without that, unless python.exe is in the search
PATH, "Win+R -> python" and running "start python" in the command
prompt won't work. You can of course add the key manually as the
default value for
"[HKLM|HKCU]\Software\Microsoft\Windows\CurrentVersion\App
Paths\python.exe". IMO, this makes it the 'system' Python.
'''

Is this an intentional change or an oversight?

----------
components: Installation
messages: 252618
nosy: oscarbenjamin
priority: normal
severity: normal
status: open
title: Windows 3.5 installer does not add python to "App Paths" key
versions: Python 3.5

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

From report at bugs.python.org  Fri Oct  9 17:29:20 2015
From: report at bugs.python.org (Gian Carlo Martinelli)
Date: Fri, 09 Oct 2015 15:29:20 +0000
Subject: [New-bugs-announce] [issue25356] Idle (Python 3.4 on Ubuntu) does
	not allow typing accents
Message-ID: <1444404560.14.0.409888700573.issue25356@psf.upfronthosting.co.za>


New submission from Gian Carlo Martinelli:

IDLE (using Python 3.4 on Ubuntu) does not recognize accent key presses (ex: ~, ^, ').

This makes it impossible to program in some languages.

----------
components: IDLE
messages: 252620
nosy: Gian Carlo Martinelli
priority: normal
severity: normal
status: open
title: Idle (Python 3.4 on Ubuntu) does not allow typing accents
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Oct  9 18:21:56 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Oct 2015 16:21:56 +0000
Subject: [New-bugs-announce] [issue25357] Add an optional newline parameter
 to binascii.b2a_base64() to not add a newline
Message-ID: <1444407716.89.0.315561333899.issue25357@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The base64.b64encode() function calls binascii.b2a_base64() and then strips the newline. It would be more efficient to directly not add a newline.

Attached patch adds an optional newline parameter to binascii.b2a_base64(). It also modifies base64.b64encode() to call binascii.b2a_base64() with newline=False.

----------
files: binascii_b2a_base64_newline.patch
keywords: patch
messages: 252625
nosy: haypo
priority: normal
severity: normal
status: open
title: Add an optional newline parameter to binascii.b2a_base64() to not add a newline
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file40731/binascii_b2a_base64_newline.patch

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

From report at bugs.python.org  Fri Oct  9 21:54:20 2015
From: report at bugs.python.org (Nicolas Primeau)
Date: Fri, 09 Oct 2015 19:54:20 +0000
Subject: [New-bugs-announce] [issue25358] Unexpected behaviour when
	converting large float to int
Message-ID: <1444420460.79.0.0573314564065.issue25358@psf.upfronthosting.co.za>


New submission from Nicolas Primeau:

Converting arbitrarily large float type numbers to integer type number results in a non trivially different number.

This can be repeated in all Python versions, same with Python 2 with longs.

Expected behaviour would be an integer representation of 1e+44, and some_number == int_version.

Example:
>>> some_number = 100000000000000000000000000000000000000000000
>>> type(some_number)
<class 'int'>
>>> float_version = float(some_number)
>>> float_version
1e+44
>>> type(float_version)
<class 'float'>
>>> int_version = int(float_version)
>>> type(int_version)
<class 'int'>
>>> int_version
100000000000000008821361405306422640701865984
>>> int_version == some_number
False
>>> int_version == float_version
True

----------
components: Interpreter Core
messages: 252642
nosy: Nicolas Primeau
priority: normal
severity: normal
status: open
title: Unexpected behaviour when converting large float to int
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sat Oct 10 00:38:34 2015
From: report at bugs.python.org (L)
Date: Fri, 09 Oct 2015 22:38:34 +0000
Subject: [New-bugs-announce] [issue25359] io.open() fails to open ascii file
	if LANG env not set
Message-ID: <1444430314.83.0.326403344466.issue25359@psf.upfronthosting.co.za>


Changes by L <digitalsentinel at gmail.com>:


----------
components: IO
files: io.openBugEx.py
nosy: sentinel
priority: normal
severity: normal
status: open
title: io.open() fails to open ascii file if LANG env not set
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file40737/io.openBugEx.py

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

From report at bugs.python.org  Sat Oct 10 05:21:46 2015
From: report at bugs.python.org (eryksun)
Date: Sat, 10 Oct 2015 03:21:46 +0000
Subject: [New-bugs-announce] [issue25360] pyw should search for pythonw to
 implement #!/usr/bin/env python
Message-ID: <1444447306.1.0.629967628506.issue25360@psf.upfronthosting.co.za>


New submission from eryksun:

The Windows launcher searches PATH to implement the shebang "#!/usr/bin/env". Given "#!/usr/bin/env python", it always searches for L"python" (see issue 17903), even in pyw.exe. maybe_handle_shebang in PC/launcher.c should instead use a macro that's conditionally defined as L"pythonw" when building pyw.exe and L"python" when building py.exe. This parallels the existing PYTHON_EXECUTABLE macro.

----------
components: Windows
messages: 252681
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pyw should search for pythonw to implement #!/usr/bin/env  python
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Oct 10 12:43:24 2015
From: report at bugs.python.org (Laura Creighton)
Date: Sat, 10 Oct 2015 10:43:24 +0000
Subject: [New-bugs-announce] [issue25361] Is python-3-5-0.exe compiled with
 SSE2 instrutions? If so should we mention this?
Message-ID: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>


New submission from Laura Creighton:

Another report in to webmaster:
I tried to install Python 3.5.0 from [1]https://www.python.org/ftp/python/
3.5.0/python-3.5.0.exe but I get an error and I'm not able to install, is
this exe compiled with SSE2 instructions? Apparently no msi available

Does this need a mention somewhere?

----------
assignee: docs at python
components: Documentation, Installation, Windows
messages: 252703
nosy: docs at python, lac, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Is python-3-5-0.exe compiled with SSE2 instrutions? If so should we mention this?
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Oct 10 16:37:40 2015
From: report at bugs.python.org (Nir Soffer)
Date: Sat, 10 Oct 2015 14:37:40 +0000
Subject: [New-bugs-announce] [issue25362] Use with instead of try finally
Message-ID: <1444487860.53.0.808291026774.issue25362@psf.upfronthosting.co.za>


New submission from Nir Soffer:

Using "with" is more clear and less error prone.

----------
components: Library (Lib)
files: 0001-Use-with-instead-of-try-finally.patch
keywords: patch
messages: 252716
nosy: nirs
priority: normal
severity: normal
status: open
title: Use with instead of try finally
versions: Python 3.6
Added file: http://bugs.python.org/file40740/0001-Use-with-instead-of-try-finally.patch

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

From report at bugs.python.org  Sat Oct 10 17:37:55 2015
From: report at bugs.python.org (grafika)
Date: Sat, 10 Oct 2015 15:37:55 +0000
Subject: [New-bugs-announce] [issue25363] x=[1,2,3].append([1,2,3]) bug
Message-ID: <1444491475.67.0.0313628985758.issue25363@psf.upfronthosting.co.za>


New submission from grafika:

>>> [1,2,3].append([1,2,3])  
>>>                          
>>> x=[1,2,3].append([1,2,3])
>>> x                        
>>> x                        
>>> type(x)                  
<class 'NoneType'>           
>>> x=[1,2,3]                
>>> x.append([1,2,3])        
>>> x                        
[1, 2, 3, [1, 2, 3]]         
>>>

----------
components: Windows
files: pybug.jpg
messages: 252718
nosy: lenivaya10001, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: x=[1,2,3].append([1,2,3]) bug
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file40742/pybug.jpg

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

From report at bugs.python.org  Sat Oct 10 17:45:02 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 10 Oct 2015 15:45:02 +0000
Subject: [New-bugs-announce] [issue25364] zipfile broken with
	--without-threads
Message-ID: <1444491902.09.0.108690377093.issue25364@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

zipfile module unconditionally requires threading module since revision 4973ccd46e32 (in Python >=3.5), which causes errors in over 50 Lib/test/test_*.py files.


[  1/399] test_cmd_line
test test_cmd_line crashed -- Traceback (most recent call last):
  File "/tmp/cpython/Lib/test/libregrtest/runtest.py", line 149, in runtest_inner
    the_module = importlib.import_module(abstest)
  File "/tmp/cpython/Lib/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 986, in _gcd_import
  File "<frozen importlib._bootstrap>", line 969, in _find_and_load
  File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 673, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 654, in exec_module
  File "<frozen importlib._bootstrap>", line 222, in _call_with_frames_removed
  File "/tmp/cpython/Lib/test/test_cmd_line.py", line 11, in <module>
    from test.support import script_helper
  File "/tmp/cpython/Lib/test/support/script_helper.py", line 14, in <module>
    import zipfile
  File "/tmp/cpython/Lib/zipfile.py", line 16, in <module>
    import threading
  File "/tmp/cpython/Lib/threading.py", line 4, in <module>
    import _thread
ImportError: No module named '_thread'

----------
components: Library (Lib)
keywords: 3.5regression
messages: 252720
nosy: Arfrever, alanmcintyre, serhiy.storchaka, twouters
priority: normal
severity: normal
status: open
title: zipfile broken with --without-threads
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Oct 10 18:01:35 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 10 Oct 2015 16:01:35 +0000
Subject: [New-bugs-announce] [issue25365] test_pickle fails with
	--without-threads
Message-ID: <1444492895.03.0.158264675245.issue25365@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

test.test_pickle.CompatPickleTests.test_exceptions() test introduced in revision 8d86dfe53b97 (in Python >=3.4) fails with --without-threads, because it unconditionally imports multiprocessing module, which is known to not work with --without-threads.
The last part of this test should probably be skipped when import of multiprocessing fails.

======================================================================
ERROR: test_exceptions (test.test_pickle.CompatPickleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/cpython/Lib/test/test_pickle.py", line 383, in test_exceptions
    import multiprocessing.context
  File "/tmp/cpython/Lib/multiprocessing/__init__.py", line 16, in <module>
    from . import context
  File "/tmp/cpython/Lib/multiprocessing/context.py", line 3, in <module>
    import threading
  File "/tmp/cpython/Lib/threading.py", line 4, in <module>
    import _thread
ImportError: No module named '_thread'

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

----------
components: Tests
messages: 252722
nosy: Arfrever, alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_pickle fails with --without-threads
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Oct 10 18:26:58 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 10 Oct 2015 16:26:58 +0000
Subject: [New-bugs-announce] [issue25366] test_venv fails with
	--without-threads
Message-ID: <1444494418.59.0.980856375099.issue25366@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

test.test_venv.EnsurePipTest.test_with_pip() fails with --without-threads, because some dependencies of PIP (cachecontrol, lockfile) unconditionally import threading module.

======================================================================
FAIL: test_with_pip (test.test_venv.EnsurePipTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/cpython/Lib/test/test_venv.py", line 356, in test_with_pip
    with_pip=True)
subprocess.CalledProcessError: Command '['/tmp/tmpgt_wdmiq/bin/python', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/tmp/cpython/Lib/test/test_venv.py", line 362, in test_with_pip
    self.fail(msg.format(exc, details))
AssertionError: Command '['/tmp/tmpgt_wdmiq/bin/python', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1

**Subprocess Output**
Traceback (most recent call last):
  File "/tmp/cpython/Lib/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/tmp/cpython/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/tmp/cpython/Lib/ensurepip/__main__.py", line 4, in <module>
    ensurepip._main()
  File "/tmp/cpython/Lib/ensurepip/__init__.py", line 209, in _main
    default_pip=args.default_pip,
  File "/tmp/cpython/Lib/ensurepip/__init__.py", line 116, in bootstrap
    _run_pip(args + [p[0] for p in _PROJECTS], additional_paths)
  File "/tmp/cpython/Lib/ensurepip/__init__.py", line 40, in _run_pip
    import pip
  File "/tmp/tmp1bl0s_61/pip-7.1.2-py2.py3-none-any.whl/pip/__init__.py", line 15, in <module>
  File "/tmp/tmp1bl0s_61/pip-7.1.2-py2.py3-none-any.whl/pip/vcs/mercurial.py", line 10, in <module>
  File "/tmp/tmp1bl0s_61/pip-7.1.2-py2.py3-none-any.whl/pip/download.py", line 44, in <module>
  File "/tmp/tmp1bl0s_61/pip-7.1.2-py2.py3-none-any.whl/pip/_vendor/cachecontrol/__init__.py", line 9, in <module>
  File "/tmp/tmp1bl0s_61/pip-7.1.2-py2.py3-none-any.whl/pip/_vendor/cachecontrol/wrapper.py", line 1, in <module>
  File "/tmp/tmp1bl0s_61/pip-7.1.2-py2.py3-none-any.whl/pip/_vendor/cachecontrol/adapter.py", line 5, in <module>
  File "/tmp/tmp1bl0s_61/pip-7.1.2-py2.py3-none-any.whl/pip/_vendor/cachecontrol/controller.py", line 11, in <module>
  File "/tmp/tmp1bl0s_61/pip-7.1.2-py2.py3-none-any.whl/pip/_vendor/cachecontrol/cache.py", line 5, in <module>
  File "/tmp/cpython/Lib/threading.py", line 4, in <module>
    import _thread
ImportError: No module named '_thread'


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

----------
components: Tests
messages: 252725
nosy: Arfrever, dstufft, ncoghlan, vinay.sajip
priority: normal
severity: normal
status: open
title: test_venv fails with --without-threads
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Oct 10 20:20:01 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 10 Oct 2015 18:20:01 +0000
Subject: [New-bugs-announce] [issue25367] test_coroutines fails with
	--without-threads
Message-ID: <1444501201.87.0.229985434953.issue25367@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

test.test_coroutines.CoroAsyncIOCompatTest.test_asyncio_1() fails with --without-threads, because it imports asyncio module, which is known to not work with --without-threads.
This test should be skipped when import of asyncio fails.

======================================================================
ERROR: test_asyncio_1 (test.test_coroutines.CoroAsyncIOCompatTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/cpython/Lib/test/test_coroutines.py", line 1325, in test_asyncio_1
    import asyncio
  File "/tmp/cpython/Lib/asyncio/__init__.py", line 21, in <module>
    from .base_events import *
  File "/tmp/cpython/Lib/asyncio/base_events.py", line 18, in <module>
    import concurrent.futures
  File "/tmp/cpython/Lib/concurrent/futures/__init__.py", line 8, in <module>
    from concurrent.futures._base import (FIRST_COMPLETED,
  File "/tmp/cpython/Lib/concurrent/futures/_base.py", line 8, in <module>
    import threading
  File "/tmp/cpython/Lib/threading.py", line 4, in <module>
    import _thread
ImportError: No module named '_thread'

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

----------
components: Tests
messages: 252735
nosy: Arfrever, giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov
priority: normal
severity: normal
status: open
title: test_coroutines fails with --without-threads
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Oct 10 20:41:18 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 10 Oct 2015 18:41:18 +0000
Subject: [New-bugs-announce] [issue25368] test_eintr
Message-ID: <1444502478.57.0.122084998013.issue25368@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

test.test_eintr.EINTRTests.test_all() fails with --without-threads since revision 10efb1797e7b (in Python >=3.6), because faulthandler.dump_traceback_later() and faulthandler.cancel_dump_traceback_later() are not available with --without-threads.

======================================================================
FAIL: test_all (test.test_eintr.EINTRTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/cpython/Lib/test/test_eintr.py", line 20, in test_all
    script_helper.assert_python_ok("-u", tester)
  File "/tmp/cpython/Lib/test/support/script_helper.py", line 135, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/tmp/cpython/Lib/test/support/script_helper.py", line 121, in _assert_python
    err))
AssertionError: Process return code is 1
command line: ['/tmp/cpython/python', '-X', 'faulthandler', '-I', '-u', '/tmp/cpython/Lib/test/eintrdata/eintr_tester.py']

stdout:
---
ERROR
ERROR
ERROR
ERROR
ERROR

======================================================================
ERROR: setUpClass (__main__.OSEINTRTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/cpython/Lib/test/eintrdata/eintr_tester.py", line 55, in setUpClass
    faulthandler.dump_traceback_later(10 * 60, exit=True)
AttributeError: module 'faulthandler' has no attribute 'dump_traceback_later'

======================================================================
ERROR: setUpClass (__main__.SocketEINTRTest)
----------------------------------------------------------------------
Traceback (most recent call last):           
  File "/tmp/cpython/Lib/test/eintrdata/eintr_tester.py", line 55, in setUpClass
    faulthandler.dump_traceback_later(10 * 60, exit=True)
AttributeError: module 'faulthandler' has no attribute 'dump_traceback_later'

======================================================================
ERROR: setUpClass (__main__.TimeEINTRTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/cpython/Lib/test/eintrdata/eintr_tester.py", line 55, in setUpClass
    faulthandler.dump_traceback_later(10 * 60, exit=True)
AttributeError: module 'faulthandler' has no attribute 'dump_traceback_later'

======================================================================
ERROR: setUpClass (__main__.SignalEINTRTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/cpython/Lib/test/eintrdata/eintr_tester.py", line 55, in setUpClass
    faulthandler.dump_traceback_later(10 * 60, exit=True)
AttributeError: module 'faulthandler' has no attribute 'dump_traceback_later'

======================================================================
ERROR: setUpClass (__main__.SelectEINTRTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/cpython/Lib/test/eintrdata/eintr_tester.py", line 55, in setUpClass
    faulthandler.dump_traceback_later(10 * 60, exit=True)
AttributeError: module 'faulthandler' has no attribute 'dump_traceback_later'

----------------------------------------------------------------------
Ran 0 tests in 0.004s

FAILED (errors=5)
---

stderr:
---
Traceback (most recent call last):
  File "/tmp/cpython/Lib/test/eintrdata/eintr_tester.py", line 474, in <module>
    test_main()
  File "/tmp/cpython/Lib/test/eintrdata/eintr_tester.py", line 470, in test_main
    SelectEINTRTest)
  File "/tmp/cpython/Lib/test/support/__init__.py", line 1809, in run_unittest
    _run_suite(suite)
  File "/tmp/cpython/Lib/test/support/__init__.py", line 1784, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: multiple errors occurred
---

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

----------
assignee: haypo
components: Tests
messages: 252736
nosy: Arfrever, haypo
priority: normal
severity: normal
status: open
title: test_eintr
versions: Python 3.6

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

From report at bugs.python.org  Sat Oct 10 21:08:52 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 10 Oct 2015 19:08:52 +0000
Subject: [New-bugs-announce] [issue25369] test_regrtest fails with
	--without-threads
Message-ID: <1444504132.12.0.946058661737.issue25369@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

6 tests of test.test_regrtest.ProgramsTestCase class introduced in revision 3393d86c3bb2 (in Python >=3.6) fail with --without-threads, because they unconditionally use -j4 option, but -jN where N != 1 is not supported with --without-threads. They also use --timeout option, which is also not supported with --without-threads.

======================================================================
FAIL: test_module_autotest (test.test_regrtest.ProgramsTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/cpython/Lib/test/test_regrtest.py", line 471, in test_module_autotest
    self.run_tests(args)
  File "/tmp/cpython/Lib/test/test_regrtest.py", line 445, in run_tests
    output = self.run_python(args)
  File "/tmp/cpython/Lib/test/test_regrtest.py", line 417, in run_python
    proc = self.run_command(args, **kw)
  File "/tmp/cpython/Lib/test/test_regrtest.py", line 411, in run_command
    self.fail(msg)
AssertionError: Command ['/tmp/cpython/python', '-X', 'faulthandler', '-I', '-Wd', '-E', '-bb', '-m', 'test.autotest', '-uall', '-rwW', '--timeout', '3600', '-j4', 'test_regrtest_21191_noop19', 'test_regrtest_21191_noop20', 'test_regrtest_21191_noop21', 'test_regrtest_21191_noop22'] failed with exit code 2

stdout:
---
Using random seed 5351037
Multiprocess option requires thread support

---

stderr:
---
Warning: The timeout option requires faulthandler.dump_traceback_later
---


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

----------
assignee: haypo
components: Tests
messages: 252737
nosy: Arfrever, haypo
priority: normal
severity: normal
status: open
title: test_regrtest fails with --without-threads
versions: Python 3.6

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

From report at bugs.python.org  Sat Oct 10 22:03:10 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Oct 2015 20:03:10 +0000
Subject: [New-bugs-announce] [issue25370] Add support of pickling very large
 bytes and str objects with protocol < 4
Message-ID: <1444507390.05.0.862514167793.issue25370@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Pickle protocols < 4 allow to pickle bytes and str object with 32-bit size. One of features of protocol 4 was the support of 64-bit sizes.

It is possible to add support of very large bytes and str objects with protocols 2 and 3. The idea is that the long string is splitted on chunks with 32-bit sizes and the resulting string is reconstructed with calling ''.join(). The main part of the feature can be implemented in Python as helpers in copyreg.

The question is: is it worthwhile to implement this feature? I already implemented two other features of protocol 4 for protocols 2 and 3: nested objects and __new__ with keyword arguments.

----------
components: Extension Modules, Library (Lib)
messages: 252745
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add support of pickling very large bytes and str objects with protocol < 4
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sun Oct 11 01:53:39 2015
From: report at bugs.python.org (Chris Angelico)
Date: Sat, 10 Oct 2015 23:53:39 +0000
Subject: [New-bugs-announce] [issue25371] select.select docstring needs comma
Message-ID: <1444521219.18.0.906188853689.issue25371@psf.upfronthosting.co.za>


New submission from Chris Angelico:

The grammar of the IMPORTANT NOTICE on the select module and the select.select function wants a comma, I think. Patch attached.

----------
assignee: docs at python
components: Documentation
files: add_comma.patch
keywords: patch
messages: 252750
nosy: Rosuav, docs at python
priority: normal
severity: normal
status: open
title: select.select docstring needs comma
Added file: http://bugs.python.org/file40745/add_comma.patch

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

From report at bugs.python.org  Sun Oct 11 04:47:12 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 11 Oct 2015 02:47:12 +0000
Subject: [New-bugs-announce] [issue25372] load_module() does not link
	submodule to parent package
Message-ID: <1444531632.83.0.513711320874.issue25372@psf.upfronthosting.co.za>


New submission from Martin Panter:

The load_module() API adds an entry to sys.modules when loading a submodule, but does not add the submodule as an attribute in the parent package. I am no expert on PEP 302 or the import system, but this feels like a bug to me:

>>> import sys, pkgutil
>>> loader = pkgutil.find_loader("xml.etree")
>>> loader.load_module("xml.etree")
<module 'xml.etree' from '/usr/lib/python3.4/xml/etree/__init__.py'>
>>> sys.modules["xml.etree"]  # Entry added, per documentation and PEP 302
<module 'xml.etree' from '/usr/lib/python3.4/xml/etree/__init__.py'>
>>> hasattr(sys.modules["xml"], "etree")  # But not linked to parent!
False
>>> import xml.etree
>>> xml.etree  # Broken :(
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'etree'

----------
messages: 252753
nosy: martin.panter
priority: normal
severity: normal
status: open
title: load_module() does not link submodule to parent package
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Oct 11 06:34:51 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 11 Oct 2015 04:34:51 +0000
Subject: [New-bugs-announce] [issue25373] test.regrtest: -jN (with N != 1) +
 --slow + child error or interruption = TypeError
Message-ID: <1444538091.0.0.0447780927267.issue25373@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

Function runtest() (used by single-process mode) always returns tuple with test result as integer and test time as float.
This tuple is passed as second argument to function accumulate_result(), which has (in Python 3.6):
    def accumulate_result(self, test, result):
        ok, test_time = result
        self.test_times.append((test_time, test))

test_times is later used by code, which expects that times are floats:
        if self.ns.print_slow:
            self.test_times.sort(reverse=True)
            print("10 slowest tests:")
            for time, test in self.test_times[:10]:
                print("%s: %.1fs" % (test, time))

Code used by multi-process mode can return tuple with integer and string (describing error in subprocess), which with --slow option would cause TypeError.


Example:

In terminal 1:
$ LD_LIBRARY_PATH="$(pwd)" ./python -m test.regrtest -j2 --slow test_lib2to3

In terminal 2 (sufficiently quickly):
$ kill -SIGINT $(ps aux | grep '"test_lib2to3"' | grep -v grep | awk '{print $2}')

Output in terminal 1:

Test suite interrupted by signal SIGINT.
1 test omitted:
    test_lib2to3
10 slowest tests:
Traceback (most recent call last):
  File "/tmp/cpython/Lib/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/tmp/cpython/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/tmp/cpython/Lib/test/regrtest.py", line 39, in <module>
    main_in_temp_cwd()
  File "/tmp/cpython/Lib/test/libregrtest/main.py", line 451, in main_in_temp_cwd
    main()
  File "/tmp/cpython/Lib/test/libregrtest/main.py", line 429, in main
    Regrtest().main(tests=tests, **kwargs)
  File "/tmp/cpython/Lib/test/libregrtest/main.py", line 389, in main
    self.display_result()
  File "/tmp/cpython/Lib/test/libregrtest/main.py", line 261, in display_result
    print("%s: %.1fs" % (test, time))
TypeError: a float is required


My suggested fix is to return string describing error as third element of that tuple.

----------
components: Tests
messages: 252757
nosy: Arfrever, haypo
priority: normal
severity: normal
status: open
title: test.regrtest: -jN (with N != 1) + --slow + child error or interruption = TypeError
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Oct 11 06:46:16 2015
From: report at bugs.python.org (John Michael Lafayette)
Date: Sun, 11 Oct 2015 04:46:16 +0000
Subject: [New-bugs-announce] [issue25374] Deficiencies in type hint usage in
 Python standard libraries
Message-ID: <1444538776.34.0.720036996405.issue25374@psf.upfronthosting.co.za>


New submission from John Michael Lafayette:

I love the new type hint feature in Jetbrains IDE (PEP 0484). Now when my user defined methods return a value, I can press (Crtl+space) and see the type of that value and all its methods. Also, when I pass the wrong type in, I get a warning. 

Oddly, this does not happen with Python standard library functions. I can't get the auto-complete on objects returned by the Python standard library. The Python standard library doesn't warn me in advance if I put the wrong type in a method. How does that make sense? Please support PEP 0484 by using it in the Python standard library where appropriate.

----------
assignee: docs at python
components: Documentation
messages: 252758
nosy: John Michael Lafayette, docs at python
priority: normal
severity: normal
status: open
title: Deficiencies in type hint usage in Python standard libraries
type: behavior

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

From report at bugs.python.org  Sun Oct 11 08:15:03 2015
From: report at bugs.python.org (Chris Angelico)
Date: Sun, 11 Oct 2015 06:15:03 +0000
Subject: [New-bugs-announce] [issue25375] Don't mention 2.2 in the 3.x docs
Message-ID: <1444544103.53.0.168517351377.issue25375@psf.upfronthosting.co.za>


New submission from Chris Angelico:

See: https://mail.python.org/pipermail/python-list/2015-October/697818.html

Saying "In Python 2.2" is not helpful in the 3.x docs. Even in the 2.x docs, it's pretty safe to assume by now that everyone's on 2.2+. (At very least, "Since" would be better than "If".) Patch attached.

I suspect that a lot of that FAQ is outdated now, though.

----------
assignee: docs at python
components: Documentation
files: no_mention_2.2.patch
keywords: patch
messages: 252769
nosy: Rosuav, docs at python
priority: normal
severity: normal
status: open
title: Don't mention 2.2 in the 3.x docs
Added file: http://bugs.python.org/file40750/no_mention_2.2.patch

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

From report at bugs.python.org  Sun Oct 11 14:32:24 2015
From: report at bugs.python.org (Miikka Salminen)
Date: Sun, 11 Oct 2015 12:32:24 +0000
Subject: [New-bugs-announce] [issue25376] KeyboardInterrupt handling and
 traceback broken on Windows 10
Message-ID: <1444566744.92.0.693006452936.issue25376@psf.upfronthosting.co.za>


New submission from Miikka Salminen:

Pressing Ctrl+C to raise a KeyboardInterrupt while waiting for user input in an input() call yields an incomplete traceback.

The behaviour appears in a Python REPL session started by issuing "python" without quotes in a Windows cmd session:

Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:27:37) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> input("Question: ")
Question: Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
>>>

When executing input_test.py (a single line Python source code file containing just an input("Question: ") call) from the cmd prompt by issuing "python input_test.py" without quotes, every other time the traceback is incomplete and every other time the Ctrl+C keypress yields, erroneously, an EOFError instead of a KeyboardInterrupt:

C:\x>python input_test.py
Question: Traceback (most recent call last):
  File "input_test.py", line 1, in <module>
    input("Question: ")
EOFError
^C
C:\x>python input_test.py
Question: Traceback (most recent call last):
  File "input_test.py", line 1, in <module>

C:\x>

----------
components: Interpreter Core, Windows
messages: 252800
nosy: mdf, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: KeyboardInterrupt handling and traceback broken on Windows 10
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Oct 11 17:36:26 2015
From: report at bugs.python.org (Karl Richter)
Date: Sun, 11 Oct 2015 15:36:26 +0000
Subject: [New-bugs-announce] [issue25377] Mention octal format of mode
	argument of os.chmod
Message-ID: <1444577786.91.0.966567920628.issue25377@psf.upfronthosting.co.za>


New submission from Karl Richter:

`help(os.chmod)` doesn't explain that it expects an octal number for its `mode` argument. This is very confusing for beginners and people who are not involved with filesystems and permissions every day. It doesn't need to be explained, just mentioned, maybe with a link to an extended explanation.

Example for confusion: http://stackoverflow.com/questions/15607903/python-module-os-chmodfile-664-does-not-change-the-permission-to-rw-rw-r-bu

----------
assignee: docs at python
components: Documentation
messages: 252817
nosy: docs at python, krichter
priority: normal
severity: normal
status: open
title: Mention octal format of mode argument of os.chmod
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Mon Oct 12 00:41:00 2015
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Jan_Warecki?=)
Date: Sun, 11 Oct 2015 22:41:00 +0000
Subject: [New-bugs-announce] [issue25378] Roundoff error on OS X
Message-ID: <1444603260.51.0.439677989725.issue25378@psf.upfronthosting.co.za>


New submission from Micha? Jan Warecki:

This should speak for itself:

>>> 3*4.35
13.049999999999999
>>> 

The error is reproducible, and applies to all decimal numbers ending with \.[0-9]5, and \.[0-4] as well as \.[6-9], when multiplied by 3. Examples:

>>> 3*4.1
12.299999999999999
>>> 3*4.4
13.200000000000001
>>> 3*4.6
13.799999999999999
>>> 3*4.8
14.399999999999999
>>> 3*4.9
14.700000000000001
>>> 4*3.1
12.4
>>> 4*4.1
16.4
>>> 3*4.1
12.299999999999999
>>> 6*4.1
24.599999999999998
>>> 6*4.4
26.400000000000002
>>>

----------
components: Macintosh
messages: 252828
nosy: Micha? Jan Warecki, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Roundoff error on OS X
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Mon Oct 12 06:42:20 2015
From: report at bugs.python.org (Bert JW Regeer)
Date: Mon, 12 Oct 2015 04:42:20 +0000
Subject: [New-bugs-announce] [issue25379] Changes in traceback broke
	existing code (Python 3.5)
Message-ID: <1444624940.12.0.845916385151.issue25379@psf.upfronthosting.co.za>


New submission from Bert JW Regeer:

One of the changes in Python 3.5's traceback functionality broke existing code compared to Python 3.4 by injecting an extra stack frame into the list when using traceback.extract_stack:

What this looks like on Python 3.5:

pyramid/tests/test_config/test_init.py 1108 includeme2 config.add_view(view2)
pyramid/util.py 526 wrapper return wrapped(self, *arg, **defaults)
pyramid/util.py 557 wrapper f = traceback.extract_stack(limit=4)
/Users/xistence/.pyenv/versions/3.5.0/lib/python3.5/traceback.py 201 extract_stack stack = StackSummary.extract(walk_stack(f), limit=limit)

What it used to look like on Python 3.4:

pyramid/config/__init__.py 798 include c(configurator)
pyramid/tests/test_config/test_init.py 1108 includeme2 config.add_view(view2)
pyramid/util.py 526 wrapper return wrapped(self, *arg, **defaults)
pyramid/util.py 557 wrapper f = traceback.extract_stack(limit=4)

Notice that in the Python 3.5 version:

/Users/xistence/.pyenv/versions/3.5.0/lib/python3.5/traceback.py 201 extract_stack stack = StackSummary.extract(walk_stack(f), limit=limit)

Is added.

We are tracking this issue here: https://github.com/Pylons/pyramid/issues/1973 on our side.

----------
messages: 252841
nosy: X-Istence
priority: normal
severity: normal
status: open
title: Changes in traceback broke existing code (Python 3.5)
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Oct 12 09:50:13 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Oct 2015 07:50:13 +0000
Subject: [New-bugs-announce] [issue25380] Incorrect protocol for the
	STACK_GLOBAL opcode
Message-ID: <1444636213.99.0.44021196254.issue25380@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Incorrect protocol (0 instead of 4) is specified for the STACK_GLOBAL opcode in pickletools.opcodes.

----------
assignee: serhiy.storchaka
components: Library (Lib)
files: pickletools_STACK_GLOBAL_proto.patch
keywords: patch
messages: 252847
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Incorrect protocol for the STACK_GLOBAL opcode
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40753/pickletools_STACK_GLOBAL_proto.patch

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

From report at bugs.python.org  Mon Oct 12 10:11:36 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 12 Oct 2015 08:11:36 +0000
Subject: [New-bugs-announce] [issue25381] Use old description of raise in
	Python3
Message-ID: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

In the first paragraph of https://docs.python.org/3/extending/extending.html#intermezzo-errors-and-exceptions,
it is wrong to use the sentence "the second argument to raise" since
the raise syntax has been changed in Python3.

----------
assignee: docs at python
components: Documentation
files: doc_extending.patch
keywords: patch
messages: 252848
nosy: docs at python, xiang.zhang
priority: normal
severity: normal
status: open
title: Use old description of raise in Python3
Added file: http://bugs.python.org/file40754/doc_extending.patch

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

From report at bugs.python.org  Mon Oct 12 11:57:08 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Oct 2015 09:57:08 +0000
Subject: [New-bugs-announce] [issue25382] pickletools.dis(): output memo id
	for MEMOIZE
Message-ID: <1444643828.19.0.0921700569142.issue25382@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch makes pickletools.dis() to output implicit memo id for the MEMOIZE opcode. This makes the output more readable.

----------
components: Library (Lib)
files: pickletools_dis_MEMOIZE_comment.patch
keywords: patch
messages: 252849
nosy: alexandre.vassalotti, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: pickletools.dis(): output memo id for MEMOIZE
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file40755/pickletools_dis_MEMOIZE_comment.patch

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

From report at bugs.python.org  Mon Oct 12 12:04:04 2015
From: report at bugs.python.org (Ilhan Sanli)
Date: Mon, 12 Oct 2015 10:04:04 +0000
Subject: [New-bugs-announce] [issue25383] Docs: Broken link
Message-ID: <1444644244.01.0.0650490218044.issue25383@psf.upfronthosting.co.za>


New submission from Ilhan Sanli:

This page (3.4 to dev):
https://docs.python.org/3.6/library/venv.html
Contains link with text:
See also: Python Packaging User Guide: Creating and using virtual environments
URL:
https://packaging.python.org/en/latest/installing.html#virtual-environments
Results in 404.
Guessing it should point to:
http://python-packaging-user-guide.readthedocs.org/en/latest/installing/#creating-virtual-environments
Might be a bigger issue regarding the domain: 
https://packaging.python.org
Googling "Python Packaging User Guide" gives broken links under https://packaging.python.org

----------
messages: 252850
nosy: ilhan
priority: normal
severity: normal
status: open
title: Docs: Broken link
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Oct 12 13:40:15 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Oct 2015 11:40:15 +0000
Subject: [New-bugs-announce] [issue25384] Use _PyBytesWriter in the binascii
	module
Message-ID: <1444650015.66.0.169778133218.issue25384@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch modifies the binascii module to use the new _PyBytesWriter API.

IMHO the patch makes the code more readable. The code may be faster because it avoids a call to _PyBytes_Resize() in some cases.

The change on binascii_rledecode_hqx_impl() should be carefully reviewed, the code is a little bit more complex. It uses a counter to decide when to enlarge the buffer. It calls _PyBytesWriter_Prepare() to enlarge the buffer which uses overallocation. It disables overallocation if we are going to write the last byte.

----------
files: binascii_writer.patch
keywords: patch
messages: 252852
nosy: haypo
priority: normal
severity: normal
status: open
title: Use _PyBytesWriter in the binascii module
versions: Python 3.6
Added file: http://bugs.python.org/file40756/binascii_writer.patch

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

From report at bugs.python.org  Mon Oct 12 19:35:17 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Oct 2015 17:35:17 +0000
Subject: [New-bugs-announce] [issue25385] Spurious warning when compiling
	extension module
Message-ID: <1444671317.42.0.28476348382.issue25385@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

I'm under Linux, but get the following warning when compiling an extension module.  This only happens with 3.5+.

$ python setup.py build_ext --inplace 
running build_ext
building 'numba._helperlib' extension
C compiler: gcc -pthread -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC

compile options: '-I/home/antoine/35/lib/python3.5/site-packages/numpy/core/include -I/home/antoine/35/include/python3.5m -c'
Warning: Can't read registry to find the necessary compiler setting
Make sure that Python modules winreg, win32api or win32con are installed.
gcc: numba/_helpermod.c
[...]

----------
components: Distutils
messages: 252875
nosy: dstufft, eric.araujo, pitrou, steve.dower
priority: normal
severity: normal
status: open
title: Spurious warning when compiling extension module
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Oct 13 01:50:45 2015
From: report at bugs.python.org (Alexander Riccio)
Date: Mon, 12 Oct 2015 23:50:45 +0000
Subject: [New-bugs-announce] [issue25386] msvcrt_putch/msvcrt_putwch don't
 check the return value of _putch/_putwch
Message-ID: <1444693845.85.0.133666844386.issue25386@psf.upfronthosting.co.za>


New submission from Alexander Riccio:

A minor issue (probably qualifies for the "easy" keyword):

All functions in msvcrtmodule.c (I'm looking at http://svn.python.org/projects/python/trunk/PC/msvcrtmodule.c) except msvcrt_putch and msvcrt_putwch properly check return values against error codes, and call one of the PyErr_Set* functions to properly bubble the error up the call stack.

_putch returns EOF on failure, and _putwch returns WEOF on failure.

Like the rest of the functions in that file, I imagine that the fix would involve something like:


if (_putch(ch) == EOF)
    return PyErr_SetFromErrno(PyExc_IOError);


Note: the Python msvcrt documentation (https://docs.python.org/3/library/msvcrt.html) says:

"Changed in version 3.3: Operations in this module now raise OSError where IOError was raised."

...so if you were to backport this minor fix, you need to consider that (not sure what difference that makes).

Should I take a stab at patching this myself (I've never done this for the Python project) or shall I leave that to the devs?

----------
components: Windows
messages: 252899
nosy: Alexander Riccio, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: msvcrt_putch/msvcrt_putwch don't check the return value of _putch/_putwch
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue Oct 13 02:23:20 2015
From: report at bugs.python.org (Alexander Riccio)
Date: Tue, 13 Oct 2015 00:23:20 +0000
Subject: [New-bugs-announce] [issue25387] sound_msgbeep doesn't check the
 return value of MessageBeep
Message-ID: <1444695800.89.0.134465569208.issue25387@psf.upfronthosting.co.za>


Changes by Alexander Riccio <test35965 at gmail.com>:


----------
components: Windows
nosy: Alexander Riccio, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: sound_msgbeep doesn't check the return value of MessageBeep
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue Oct 13 05:15:15 2015
From: report at bugs.python.org (Brian Cain)
Date: Tue, 13 Oct 2015 03:15:15 +0000
Subject: [New-bugs-announce] [issue25388] tokenizer crash/misbehavior
Message-ID: <1444706115.92.0.283351483962.issue25388@psf.upfronthosting.co.za>


New submission from Brian Cain:

This issue is similar to (but I believe distinct from) the one reported earlier as http://bugs.python.org/issue24022.  Tokenizer failures strike me as difficult to exploit, but risky nonetheless.

Attached is a test case that illustrates the problem and the output from ASan when it encounters the failure.

All of the versions below that I tested failed in one way or another (segfault, assertion failure, printing enormous blank output to console).  Some fail frequently and some exhibit this failure only occasionally.

Python 3.4.3 (default, Mar 26 2015, 22:03:40) 
Python 2.7.9 (default, Apr  2 2015, 15:33:21) [GCC 4.9.2] on linux2
Python 3.6.0a0 (default:2a8a39640aa2+, Jul  9 2015, 12:28:50) [GCC 4.9.2] on linux

----------
components: Interpreter Core
files: vuln.patch
keywords: patch
messages: 252905
nosy: Brian.Cain
priority: normal
severity: normal
status: open
title: tokenizer crash/misbehavior
versions: Python 2.7, Python 3.4, Python 3.6
Added file: http://bugs.python.org/file40764/vuln.patch

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

From report at bugs.python.org  Tue Oct 13 11:22:39 2015
From: report at bugs.python.org (IvenDong)
Date: Tue, 13 Oct 2015 09:22:39 +0000
Subject: [New-bugs-announce] [issue25389] It crashes as long as I press
	"(parenthese)
Message-ID: <1444728159.88.0.185583668011.issue25389@psf.upfronthosting.co.za>


New submission from IvenDong:

Process:               Python [1100]
Path:                  /Applications/Python 3.5/IDLE.app/Contents/MacOS/Python
Identifier:            org.python.IDLE
Version:               3.5.0rc4 (3.5.0rc4)
Code Type:             X86 (Native)
Parent Process:        ??? [1]
Responsible:           Python [1100]
User ID:               501

Date/Time:             2015-10-11 22:35:09.054 +0800
OS Version:            Mac OS X 10.11 (15A284)
Report Version:        11
Anonymous UUID:        4F4BFD63-E728-8F3C-E2C5-390C0FDD071E


Time Awake Since Boot: 9000 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BREAKPOINT (SIGTRAP)
Exception Codes:       0x0000000000000002, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Application Specific Information:
*** Terminating app due to uncaught exception 'NSRangeException', reason: '-[__NSCFConstantString characterAtIndex:]: Range or index out of bounds'

Application Specific Backtrace 1:
0   CoreFoundation                      0x9dbe59b9 __raiseError + 201
1   libobjc.A.dylib                     0x9def1f11 objc_exception_throw + 276
2   CoreFoundation                      0x9dbe58cd +[NSException raise:format:] + 141
3   CoreFoundation                      0x9dae0bcf -[__NSCFString characterAtIndex:] + 111
4   Tk                                  0x01b0dedd TkpInitKeymapInfo + 659
5   Tk                                  0x01b09aab TkpRedirectKeyEvent + 1270
6   Tk                                  0x01b14490 Tk_MacOSXSetupTkNotifier + 986
7   Tcl                                 0x019e77ac Tcl_DoOneEvent + 310
8   _tkinter.cpython-35m-darwin.so      0x0195d589 _tkinter_tkapp_mainloop + 233
9   Python                              0x00067dcd PyCFunction_Call + 237
10  Python                              0x000f3364 PyEval_EvalFrameEx + 31972
11  Python                              0x000f586c _PyEval_EvalCodeWithName + 2284
12  Python                              0x000f3ed5 PyEval_EvalFrameEx + 34901
13  Python                              0x000f586c _PyEval_EvalCodeWithName + 2284
14  Python                              0x000f3ed5 PyEval_EvalFrameEx + 34901
15  Python                              0x000f586c _PyEval_EvalCodeWithName + 2284
16  Python                              0x000f5a13 PyEval_EvalCode + 99
17  Python                              0x0012457e PyRun_FileExFlags + 206
18  Python                              0x001248a9 PyRun_SimpleFileExFlags + 505
19  Python                              0x0013e4b8 Py_Main + 3704
20  Python                              0x00001e97 main + 471
21  Python                              0x00001cb5 start + 53

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.apple.CoreFoundation          0x9dbe5d37 ___TERMINATING_DUE_TO_UNCAUGHT_EXCEPTION___ + 7
1   com.apple.CoreFoundation          0x9dbe5cc2 __raiseError + 978
2   libobjc.A.dylib                   0x9def1f11 objc_exception_throw + 276
3   com.apple.CoreFoundation          0x9dbe58cd +[NSException raise:format:] + 141
4   com.apple.CoreFoundation          0x9dae0bcf -[__NSCFString characterAtIndex:] + 111
5   Tk                                0x01b0dedd 0x1a4f000 + 782045
6   Tk                                0x01b09aab 0x1a4f000 + 764587
7   Tk                                0x01b14490 0x1a4f000 + 808080
8   Tcl                               0x019e77ac Tcl_DoOneEvent + 310
9   _tkinter.cpython-35m-darwin.so    0x0195d589 _tkinter_tkapp_mainloop + 233
10  org.python.python                 0x00067dcd PyCFunction_Call + 237
11  org.python.python                 0x000f3364 PyEval_EvalFrameEx + 31972
12  org.python.python                 0x000f586c _PyEval_EvalCodeWithName + 2284
13  org.python.python                 0x000f3ed5 PyEval_EvalFrameEx + 34901
14  org.python.python                 0x000f586c _PyEval_EvalCodeWithName + 2284
15  org.python.python                 0x000f3ed5 PyEval_EvalFrameEx + 34901
16  org.python.python                 0x000f586c _PyEval_EvalCodeWithName + 2284
17  org.python.python                 0x000f5a13 PyEval_EvalCode + 99
18  org.python.python                 0x0012457e PyRun_FileExFlags + 206
19  org.python.python                 0x001248a9 PyRun_SimpleFileExFlags + 505
20  org.python.python                 0x0013e4b8 Py_Main + 3704
21  Python                            0x00001e97 main + 471
22  Python                            0x00001cb5 start + 53

Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0   libsystem_kernel.dylib            0x9c34c8b2 kevent_qos + 10
1   libdispatch.dylib                 0x9bb91836 _dispatch_mgr_invoke + 234
2   libdispatch.dylib                 0x9bb9140a _dispatch_mgr_thread + 52

Thread 2:
0   libsystem_kernel.dylib            0x9c34be16 __workq_kernreturn + 10
1   libsystem_pthread.dylib           0x9c65d35f _pthread_wqthread + 1289
2   libsystem_pthread.dylib           0x9c65af82 start_wqthread + 34

Thread 3:
0   libsystem_kernel.dylib            0x9c34b7de __select + 10
1   Tcl                               0x01a1b613 0x1969000 + 730643
2   libsystem_pthread.dylib           0x9c65d794 _pthread_body + 138
3   libsystem_pthread.dylib           0x9c65d70a _pthread_start + 155
4   libsystem_pthread.dylib           0x9c65afa6 thread_start + 34

Thread 4:: com.apple.NSEventThread
0   libsystem_kernel.dylib            0x9c34507a mach_msg_trap + 10
1   libsystem_kernel.dylib            0x9c344464 mach_msg + 68
2   com.apple.CoreFoundation          0x9dae0096 __CFRunLoopServiceMachPort + 214
3   com.apple.CoreFoundation          0x9dadf4a1 __CFRunLoopRun + 1521
4   com.apple.CoreFoundation          0x9dadec46 CFRunLoopRunSpecific + 390
5   com.apple.CoreFoundation          0x9dadeaab CFRunLoopRunInMode + 123
6   com.apple.AppKit                  0x930721c2 _NSEventThread + 291
7   libsystem_pthread.dylib           0x9c65d794 _pthread_body + 138
8   libsystem_pthread.dylib           0x9c65d70a _pthread_start + 155
9   libsystem_pthread.dylib           0x9c65afa6 thread_start + 34

Thread 5:
0   libsystem_kernel.dylib            0x9c34be16 __workq_kernreturn + 10
1   libsystem_pthread.dylib           0x9c65d35f _pthread_wqthread + 1289
2   libsystem_pthread.dylib           0x9c65af82 start_wqthread + 34

Thread 6:
0   libsystem_kernel.dylib            0x9c34be16 __workq_kernreturn + 10
1   libsystem_pthread.dylib           0x9c65d35f _pthread_wqthread + 1289
2   libsystem_pthread.dylib           0x9c65af82 start_wqthread + 34

Thread 7:
0   libsystem_kernel.dylib            0x9c34be16 __workq_kernreturn + 10
1   libsystem_pthread.dylib           0x9c65d35f _pthread_wqthread + 1289
2   libsystem_pthread.dylib           0x9c65af82 start_wqthread + 34

Thread 0 crashed with X86 Thread State (32-bit):
 eax: 0x00000001  ebx: 0x006e1dc0  ecx: 0x00000000  edx: 0x00000000
 edi: 0x9dbe58fe  esi: 0x01336600  ebp: 0xbfffe3e8  esp: 0xbfffe3e0
  ss: 0x00000023  efl: 0x00000282  eip: 0x9dbe5d37   cs: 0x0000001b
  ds: 0x00000023   es: 0x00000023   fs: 0x00000000   gs: 0x0000000f
 cr2: 0xa25b32b8

Logical CPU:     0
Error Code:      0x00100170
Trap Number:     132


Binary Images:
   0x1000 -     0x1ff7 +Python (???) <BE1C29C1-D68A-B3C4-A08E-84725F131183> /Applications/Python 3.5/IDLE.app/Contents/MacOS/Python
   0x4000 -   0x1e0fff +org.python.python (3.5.0rc4, [c] 2001-2015 Python Software Foundation. - 3.5.0rc4) <3E39332A-4611-D515-9A7E-B998FF5FD530> /Library/Frameworks/Python.framework/Versions/3.5/Python
0x195a000 -  0x1961ff7 +_tkinter.cpython-35m-darwin.so (???) <405663B5-8D5B-260C-151B-2D7F0F23F08E> /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/lib-dynload/_tkinter.cpython-35m-darwin.so
0x1969000 -  0x1a38ffb  Tcl (8.5.9 - 8.5.9) <9036000D-B5B1-333A-8DAF-D46FE8FB0851> /System/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl
0x1a4f000 -  0x1b40ffb  Tk (8.5.9 - 8.5.9) <2D6048A7-33D6-3569-BE73-42B2E6BA36D2> /System/Library/Frameworks/Tk.framework/Versions/8.5/Tk
0x1ccf000 -  0x1cd0ff7 +_heapq.cpython-35m-darwin.so (???) <FB3421C1-8FD7-D40F-D37C-A198C1F00DF4> /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/lib-dynload/_heapq.cpython-35m-darwin.so
0x1cd4000 -  0x1cd8ff7 +_struct.cpython-35m-darwin.so (???) <34193787-9CF9-168E-08C9-61CC73549845> /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/lib-dynload/_struct.cpython-35m-darwin.so
0x1cdf000 -  0x1ce9ff7 +_socket.cpython-35m-darwin.so (???) <4DFCE924-C0C0-92D4-117B-4FABD1219CAC> /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/lib-dynload/_socket.cpython-35m-darwin.so
0x1cf4000 -  0x1cf9fe7 +math.cpython-35m-darwin.so (???) <4FBF164C-2D3B-708A-6F4B-F021680555E2> /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/lib-dynload/math.cpython-35m-darwin.so
0x3810000 -  0x3813ff7 +select.cpython-35m-darwin.so (???) <68F706BB-10A3-7CEA-9887-6AADB6C9C958> /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/lib-dynload/select.cpython-35m-darwin.so
0x3859000 -  0x385aff7 +_posixsubprocess.cpython-35m-darwin.so (???) <1E5E82D3-7A4E-F58B-622E-0F27B9EEF7E6> /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/lib-dynload/_posixsubprocess.cpython-35m-darwin.so
0x391d000 -  0x391dff7 +grp.cpython-35m-darwin.so (???) <3CD41683-D349-1B63-1B31-2C153D12644D> /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/lib-dynload/grp.cpython-35m-darwin.so
0x3920000 -  0x3921ff7 +_bz2.cpython-35m-darwin.so (???) <63451EA4-3A8E-83B6-3961-0186C591F4E9> /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/lib-dynload/_bz2.cpython-35m-darwin.so
0x3925000 -  0x394afe7 +_lzma.cpython-35m-darwin.so (???) <70955E17-1D0A-FD97-B71A-3FBC7E9750D6> /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/lib-dynload/_lzma.cpython-35m-darwin.so
0x3a13000 -  0x3a14ff7 +_hashlib.cpython-35m-darwin.so (???) <901D5B5E-DB6D-2C17-E57A-7E048535DEDD> /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/lib-dynload/_hashlib.cpython-35m-darwin.so
0x3a18000 -  0x3a19ff7 +_random.cpython-35m-darwin.so (???) <08BD141A-396F-3601-FC4F-0C22B13D6E5D> /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/lib-dynload/_random.cpython-35m-darwin.so
0x3a5c000 -  0x3a6bff7 +_pickle.cpython-35m-darwin.so (???) <62DA60C8-1BFF-2B02-99FC-35283123E16A> /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/lib-dynload/_pickle.cpython-35m-darwin.so
0x3b17000 -  0x3b17ff7 +_opcode.cpython-35m-darwin.so (???) <C30C2FB0-E1B3-9F54-9C13-5D4FD1AA87DD> /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/lib-dynload/_opcode.cpython-35m-darwin.so
0x69b4000 -  0x69b4ffd +cl_kernels (???) <EC8B6BAE-BAED-4242-8E2C-DE840F3CB816> cl_kernels
0x8feae000 - 0x8fee25bf  dyld (360.14) <9FE9CADA-7460-3F80-B881-42443C5FA2E1> /usr/lib/dyld
0x90064000 - 0x90064fff  com.apple.audio.units.AudioUnit (1.13 - 1.13) <E8BACF5C-F821-3947-856B-4B3623DF24E3> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
0x90065000 - 0x90117ff3  com.apple.Bluetooth (4.4.0 - 4.4.0f4) <70C78FD1-32A3-3081-BDF1-2256AB276959> /System/Library/Frameworks/IOBluetooth.framework/Versions/A/IOBluetooth
0x90118000 - 0x901adfff  libsystem_c.dylib (1081.1.3) <CB2DB808-E449-3696-AE97-CC7F442063F2> /usr/lib/system/libsystem_c.dylib
0x9025e000 - 0x90261ff7  libdyld.dylib (360.14) <76AFF9CC-4201-3035-BD86-3E3D73273E72> /usr/lib/system/libdyld.dylib
0x90262000 - 0x902b8ff7  libc++.1.dylib (120.1) <15A1445C-C3CD-3138-AC67-3638647BEAA9> /usr/lib/libc++.1.dylib
0x902b9000 - 0x9032cffb  com.apple.datadetectorscore (7.0 - 460) <FD9F2024-B678-3296-8158-BE864B462E69> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore
0x9032d000 - 0x90335fff  libcldcpuengine.dylib (2.6.4.1) <115CF846-4322-31AF-9C2E-A3FD0194DFB0> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libcldcpuengine.dylib
0x90a60000 - 0x90b04fff  libCoreStorage.dylib (517) <7ABB9050-5670-3F82-9CDC-A6CE200B0CA3> /usr/lib/libCoreStorage.dylib
0x90b05000 - 0x90bf5ffb  com.apple.DiskImagesFramework (10.11 - 414) <6876F729-A515-3E7C-A9E9-4FA37EE66C54> /System/Library/PrivateFrameworks/DiskImages.framework/Versions/A/DiskImages
0x90bf6000 - 0x90bf6fff  com.apple.ApplicationServices (48 - 48) <7173D2F6-1111-3DF5-AC2D-2AB27BC90B0B> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
0x90c03000 - 0x90c10fff  com.apple.SpeechRecognitionCore (2.2.7 - 2.2.7) <D5351D5B-8AEE-3568-A85A-74E096C31FD1> /System/Library/PrivateFrameworks/SpeechRecognitionCore.framework/Versions/A/SpeechRecognitionCore
0x90c11000 - 0x90c14fff  com.apple.xpc.ServiceManagement (1.0 - 1) <92CD227E-F8EC-3C15-BEA3-B7E04E04B345> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement
0x90c15000 - 0x90c56ff7  libauto.dylib (186) <E949F15F-A7DC-3FC1-9092-3251E9219BAD> /usr/lib/libauto.dylib
0x90c57000 - 0x90ddcffb  com.apple.UIFoundation (1.0 - 435) <365EBF8E-0AF1-3183-8325-956E00BA997B> /System/Library/PrivateFrameworks/UIFoundation.framework/Versions/A/UIFoundation
0x90ddd000 - 0x90de2ffb  libcompiler_rt.dylib (62) <424790B7-8170-379C-97FD-9ABF614C861A> /usr/lib/system/libcompiler_rt.dylib
0x90deb000 - 0x90dfbff7  com.apple.LangAnalysis (1.7.0 - 1.7.0) <D70CE4B8-C592-3AF8-8E13-0699DC1F546E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis
0x90e61000 - 0x90e67fff  com.apple.IOAccelerator (203.7.1 - 203.7.1) <9FC34BD7-15BD-3DF1-BEEF-A63EF0363910> /System/Library/PrivateFrameworks/IOAccelerator.framework/Versions/A/IOAccelerator
0x90f78000 - 0x90f78fff  libOpenScriptingUtil.dylib (169) <EB507B47-CA3B-3628-87B7-0244F1140DC1> /usr/lib/libOpenScriptingUtil.dylib
0x90f79000 - 0x91340ffb  com.apple.HIToolbox (2.1.1 - 806) <23EBD14A-1C31-3FCA-8265-59E29A89ED07> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
0x91341000 - 0x9134dff7  libkxld.dylib (3247.1.106) <8252A5FC-FECB-3EFB-BDB3-864D54955A2D> /usr/lib/system/libkxld.dylib
0x9134e000 - 0x915e3ff3  com.apple.security (7.0 - 57336.1.9) <73C78E41-9A2E-382B-B6A5-653D762DA77F> /System/Library/Frameworks/Security.framework/Versions/A/Security
0x915e4000 - 0x918dffff  com.apple.CoreServices.CarbonCore (1136 - 1136) <4BAC2C66-2CFF-306E-864D-04D17E24B454> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
0x91954000 - 0x91a52fff  com.apple.LaunchServices (728.4 - 728.4) <90CD2ABD-AD7E-30C6-B816-442BD3F18654> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
0x91a53000 - 0x91a9cff7  com.apple.coreservices.SharedFileList (24.2 - 24.2) <20063969-E95E-383C-83F2-5730B9120FAB> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SharedFileList.framework/Versions/A/SharedFileList
0x91c41000 - 0x91c6aff7  libsystem_info.dylib (476) <CFEE2535-E53C-39FA-8D7F-4DC036FA5B50> /usr/lib/system/libsystem_info.dylib
0x91c6b000 - 0x91ca7fff  com.apple.RemoteViewServices (2.0 - 99) <44A0D46C-2987-3316-A97C-B3B17244D577> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices
0x91ca8000 - 0x91ce2fff  com.apple.MediaKit (16 - 807) <DE88E406-DAB3-348F-B286-C76DE1B5EB1C> /System/Library/PrivateFrameworks/MediaKit.framework/Versions/A/MediaKit
0x91ce3000 - 0x91d49ff3  libsystem_network.dylib (582.1.4) <460E287E-BE20-3000-ADCB-46C2EADD3198> /usr/lib/system/libsystem_network.dylib
0x91d67000 - 0x91d70fff  libGFXShared.dylib (12.0.34.11) <D8394C7C-D29B-3771-B5C5-ACB6986F3C27> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib
0x91d71000 - 0x91d74fff  libScreenReader.dylib (425.4) <91474361-8C2D-3F28-8531-8B957F111D7E> /usr/lib/libScreenReader.dylib
0x91d75000 - 0x91d75fff  com.apple.Accelerate (1.10 - Accelerate 1.10) <C6EAF913-228A-3DAB-A63E-2CD44C6E648C> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
0x91d76000 - 0x91d9cffb  libPng.dylib (1432) <FA0B94F0-31EA-372F-BBD0-E1CF3AD30F73> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
0x91d9d000 - 0x91e13ffb  com.apple.ApplicationServices.ATS (377 - 394) <BFBF2C09-E4AD-3C72-8C02-91913C86B19C> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
0x92ebc000 - 0x93b95ffb  com.apple.AppKit (6.9 - 1404.11) <A82556A9-2B02-36FD-983F-10E4A3089524> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
0x93b96000 - 0x93ba0fff  libsystem_notify.dylib (149) <26CF3479-D54B-319E-BDB5-74C6669C666C> /usr/lib/system/libsystem_notify.dylib
0x93ba1000 - 0x93badff7  libcsfde.dylib (517) <9520F7E6-9B2F-3917-8A80-112FCC04D996> /usr/lib/libcsfde.dylib
0x93bae000 - 0x93c04fff  libcups.2.dylib (435) <83F935BB-1D51-3D9C-8789-9CE56C2FE0FF> /usr/lib/libcups.2.dylib
0x93c05000 - 0x93c09fff  libheimdal-asn1.dylib (452.1.1) <38AD52D5-ACD9-3B7F-BC4B-33E4C504B80E> /usr/lib/libheimdal-asn1.dylib
0x93c0a000 - 0x93c17ff7  com.apple.speech.synthesis.framework (5.4.12 - 5.4.12) <9F082B40-3CED-310B-808E-AD158EE8640D> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
0x93c18000 - 0x93c3bfff  libJPEG.dylib (1432) <E93ED0F7-4721-3158-B75D-82A4F40B92F7> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
0x93c3c000 - 0x93c7bfff  com.apple.NavigationServices (3.8 - 220) <15BDFD2F-5A32-3ACB-9E38-5EB5E5943B3B> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/NavigationServices.framework/Versions/A/NavigationServices
0x93c88000 - 0x93ce3fff  com.apple.print.framework.PrintCore (11.0 - 472) <A203DE55-E444-3B27-AF0F-99EC2E9241EE> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
0x93ce4000 - 0x93e3dff7  libBLAS.dylib (1159) <3F8CE2C9-FEEA-3611-BCE9-7887F9257C6E> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
0x93e3e000 - 0x93e6cfff  libarchive.2.dylib (32) <EC930FBD-D3FD-38A2-82E7-85D67844BFF5> /usr/lib/libarchive.2.dylib
0x93e6d000 - 0x9408bffb  libicucore.A.dylib (551.24) <FF758C9E-A237-3960-83BF-39D63CE7C50F> /usr/lib/libicucore.A.dylib
0x9408c000 - 0x94094fff  com.apple.NetFS (6.0 - 4.0) <7A265E8E-DAF0-349D-8818-80FB5771BA83> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
0x94095000 - 0x9409aff7  libmacho.dylib (875.1) <20C4FF2D-035C-3CDA-8DA2-F37EFCFBD3AF> /usr/lib/system/libmacho.dylib
0x9409b000 - 0x940aaff7  libxar.1.dylib (302) <9BDA6960-DF48-3AF2-AB05-89A0823210C5> /usr/lib/libxar.1.dylib
0x940ab000 - 0x940adffb  libsystem_secinit.dylib (20) <30529766-9A22-34B8-A521-5AD766833172> /usr/lib/system/libsystem_secinit.dylib
0x940c6000 - 0x940fcff7  com.apple.CoreVideo (1.8 - 191.1) <B365FA82-C14E-3E64-982E-DA4BF1B1E4F3> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
0x940fd000 - 0x94119ff7  com.apple.openscripting (1.7 - 169) <542F1C6C-CC7A-3961-ABC5-FA1CFFF9A8F8> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
0x9411a000 - 0x941d4ff7  com.apple.backup.framework (1.7 - 1.7) <DB5CF2B4-9508-36FF-A3C7-C7ACD0164E6F> /System/Library/PrivateFrameworks/Backup.framework/Versions/A/Backup
0x94209000 - 0x9421fff3  libLinearAlgebra.dylib (1159) <53D10FFA-13C9-3F04-8092-4FCBE9D311EB> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLinearAlgebra.dylib
0x942db000 - 0x942e7fff  com.apple.CrashReporterSupport (10.11 - 715) <FCF99740-4227-3E30-89C0-AC6AFD1DD4B0> /System/Library/PrivateFrameworks/CrashReporterSupport.framework/Versions/A/CrashReporterSupport
0x942f5000 - 0x9433dff7  libFontRegistry.dylib (155) <181B642E-A1B5-3006-9368-C302F762787E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib
0x94507000 - 0x9450cff3  com.apple.print.framework.Print (10.0 - 266) <D054CAC7-E116-36E1-B08F-89F63640CB96> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
0x9450d000 - 0x94601ff7  libxml2.2.dylib (29) <9200D707-0515-35B4-8CFD-2EA6F1855D7A> /usr/lib/libxml2.2.dylib
0x94602000 - 0x94608ff3  libsystem_platform.dylib (73.1.1) <8CB8B06A-D7CC-392B-8B97-20C53F36D39C> /usr/lib/system/libsystem_platform.dylib
0x94609000 - 0x947dcff7  com.apple.ImageIO.framework (3.3.0 - 1432) <72916854-050E-3146-875D-86885DD581F7> /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
0x950e2000 - 0x950e6fff  libcache.dylib (75) <B848C84B-4D15-3B5C-A716-960BE2849ACC> /usr/lib/system/libcache.dylib
0x951bd000 - 0x95216ff7  com.apple.AE (701 - 701) <7D28F479-36AC-3057-BAB7-C394E30C4BC2> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
0x95217000 - 0x95227fff  libGL.dylib (12.0.34.11) <156D269C-5A20-385E-A380-0428B0E34408> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
0x95228000 - 0x95228fff  com.apple.Accelerate.vecLib (3.10 - vecLib 3.10) <80141801-6727-3F69-8052-EA0C651DD8B2> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
0x95229000 - 0x9531aff3  libiconv.2.dylib (44) <00E509A9-A5BD-35FD-B310-957163D16EFA> /usr/lib/libiconv.2.dylib
0x95399000 - 0x9539dffb  libGIF.dylib (1432) <0FD862D3-1A47-3A36-A628-16C7BFD22B02> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
0x95848000 - 0x9588bff7  com.apple.Metal (54.26.3 - 54.26.3) <2E694D8B-B9B6-3EB1-A5F3-2403F286F68C> /System/Library/Frameworks/Metal.framework/Versions/A/Metal
0x9588c000 - 0x958bffff  libTrueTypeScaler.dylib (158) <DC084F69-79BB-33F6-9660-45118B2A5090> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libTrueTypeScaler.dylib
0x958c0000 - 0x958c8ffb  libsystem_dnssd.dylib (624.1.2) <4D23D7E4-3C2C-3D43-9659-2DB3B8FCAFAF> /usr/lib/system/libsystem_dnssd.dylib
0x95933000 - 0x959fcfff  com.apple.DiscRecording (9.0.1 - 9010.4.3) <EEF95782-4063-3B99-9173-D576666AEA74> /System/Library/Frameworks/DiscRecording.framework/Versions/A/DiscRecording
0x959fd000 - 0x95b3ffef  libvDSP.dylib (563.3) <96BD47A9-0422-3BE8-A04A-F545CC29E4A2> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
0x95b40000 - 0x95b44fff  com.apple.CommonPanels (1.2.6 - 96) <5FF25015-4948-388F-BD72-9FE7E6B1A1F1> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels
0x95b45000 - 0x95de6ff7  libmecabra.dylib (696) <1D9954F4-A31F-3432-85B8-5D3E12C0FD34> /usr/lib/libmecabra.dylib
0x95e15000 - 0x95f00ff7  unorm8_bgra.dylib (2.6.4.1) <7A9687DE-6F55-36C9-9A02-4CA0AD957B0F> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/ImageFormats/unorm8_bgra.dylib
0x95f01000 - 0x95f40ffb  libGLImage.dylib (12.0.34.11) <F18548CD-A9C1-3B59-BEDC-A376EC111609> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
0x95f41000 - 0x95fbbff7  com.apple.Heimdal (4.0 - 2.0) <6EB29AA3-FECC-36AA-8C86-5EDDA8D6F194> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal
0x95fc2000 - 0x95fc4fff  libsystem_coreservices.dylib (19) <DACCE5EF-A15F-3B94-8CE7-F1CC60593B6E> /usr/lib/system/libsystem_coreservices.dylib
0x95fc5000 - 0x95fc5fff  liblaunch.dylib (755.1.19) <25AA00BF-EF6C-3304-9A5D-BA37569F5FB4> /usr/lib/system/liblaunch.dylib
0x95fc6000 - 0x9601afff  com.apple.Symbolication (1.4 - 58044) <F15B957F-FF2E-34DA-9C71-8A9D89F3ECE8> /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication
0x96194000 - 0x961a2ff7  libz.1.dylib (60) <A80F1776-4F93-3982-8CF0-32B636511C5A> /usr/lib/libz.1.dylib
0x961a3000 - 0x961e6fff  libGLU.dylib (12.0.34.11) <C822018C-A7F6-3F59-A405-A2630E34A197> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
0x961e7000 - 0x965c1ff7  libLAPACK.dylib (1159) <339771A7-9D1D-37CC-8EF1-76A9380713DA> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
0x96617000 - 0x96620fff  libsystem_networkextension.dylib (384.1.2) <6575E989-C59A-377C-B3FB-BDD9DD53CA28> /usr/lib/system/libsystem_networkextension.dylib
0x96622000 - 0x9667eff7  libTIFF.dylib (1432) <BB638289-C02C-3C4A-BA2A-99D300CCEA08> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
0x9667f000 - 0x96692ff7  libcmph.dylib (6) <FBBA9247-E995-314E-BFC2-99B1F09D37EA> /usr/lib/libcmph.dylib
0x96704000 - 0x96737ffb  com.apple.GSS (4.0 - 2.0) <7F8EB8D1-43F0-3340-B436-E319FF960352> /System/Library/Frameworks/GSS.framework/Versions/A/GSS
0x96738000 - 0x9673afff  libquarantine.dylib (80) <9FA02799-B68E-315B-9102-9065C259B3DF> /usr/lib/system/libquarantine.dylib
0x96745000 - 0x96768ffb  com.apple.framework.Apple80211 (11.0 - 1101.30) <DA4363C1-ABEF-36A4-BAF3-DDBA29B56BD4> /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Apple80211
0x96769000 - 0x9676ffff  com.apple.speech.recognition.framework (5.1.1 - 5.1.1) <4EA65D82-3E4C-3C6E-AA1F-9286590F728D> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
0x96770000 - 0x967e2ffb  com.apple.framework.CoreWLAN (11.0 - 1100.19) <969284E1-673E-3C71-90EA-2C71AF13DA4D> /System/Library/Frameworks/CoreWLAN.framework/Versions/A/CoreWLAN
0x967e3000 - 0x967f1ff3  com.apple.opengl (12.0.34 - 12.0.34) <0913D5AD-789C-368D-9563-F5D8B75D5890> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
0x967f2000 - 0x967f8fff  libunwind.dylib (35.3) <7639935C-D618-343C-AC20-90A8C4665971> /usr/lib/system/libunwind.dylib
0x967f9000 - 0x96b7cffb  com.apple.Foundation (6.9 - 1252) <B3465590-63DF-3DD8-B9CE-456F331BB49F> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x96b7d000 - 0x96b8afff  com.apple.OpenDirectory (10.11 - 194) <BE7A08EE-6327-3A0C-9118-6E550D06A905> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
0x96b8b000 - 0x96bf6ff7  com.apple.framework.CoreWiFi (11.0 - 1100.19) <610FDBE6-0119-37E4-812B-DAF80C7933E3> /System/Library/PrivateFrameworks/CoreWiFi.framework/Versions/A/CoreWiFi
0x96bf7000 - 0x96c28fff  com.apple.DictionaryServices (1.2 - 250) <BBAA157D-1417-306A-81A4-27BFC006AC5B> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
0x96c29000 - 0x96ca7ff3  com.apple.framework.IOKit (2.0.2 - 1178.1.4) <92AFD42B-4CC9-3AEA-AC65-A9485F9C03A3> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
0x96ca9000 - 0x96d54ff7  com.apple.LanguageModeling (1.0 - 1) <983C9467-801B-38C1-BE9C-8A8A5BD71F17> /System/Library/PrivateFrameworks/LanguageModeling.framework/Versions/A/LanguageModeling
0x96d55000 - 0x96d58fff  libpam.2.dylib (20) <A40E466D-A81C-3807-AD43-73FA3AB2A114> /usr/lib/libpam.2.dylib
0x96e4e000 - 0x96e9dfff  com.apple.opencl (2.6.9 - 2.6.9) <4681DED1-F092-358E-B983-765A30C670CD> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
0x96e9e000 - 0x96ef5ff7  com.apple.HIServices (1.22 - 548) <B6A5F979-A0C4-3714-9FDA-EDB16815FE28> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
0x96ef6000 - 0x96f45fff  libcurl.4.dylib (90) <14A1CC25-00E2-3FF8-AD2C-F29441EA7627> /usr/lib/libcurl.4.dylib
0x97316000 - 0x975a5ff3  com.apple.CFNetwork (760.0.5 - 760.0.5) <D03AE31A-F9BC-343A-BCC3-201F15B7ABDD> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
0x976dc000 - 0x977cbff7  libcrypto.0.9.8.dylib (59) <23043903-1EFE-37AA-BCF1-F01F0C6D0C7C> /usr/lib/libcrypto.0.9.8.dylib
0x977cc000 - 0x97873fff  com.apple.Metadata (10.7.0 - 972.9) <6CA9963B-3D7B-3D23-83B1-1A08B88D8C63> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
0x97874000 - 0x97ca6ffb  com.apple.vision.FaceCore (3.3.1 - 3.3.1) <683CF36E-5679-3963-8A98-98C90B3D2BCF> /System/Library/PrivateFrameworks/FaceCore.framework/Versions/A/FaceCore
0x97ca7000 - 0x97ca9fff  libCVMSPluginSupport.dylib (12.0.34.11) <593EFE37-53E5-303E-A2EB-EAB85EDC5D9C> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib
0x97caa000 - 0x97cb3ff3  com.apple.AppleSRP (5.0 - 1) <B65E20EC-9D82-37D5-8AD8-5289B078EB93> /System/Library/PrivateFrameworks/AppleSRP.framework/Versions/A/AppleSRP
0x97cb4000 - 0x97cd1ff7  libCRFSuite.dylib (34) <DDC97E16-372C-350F-B975-5C952AB7F9A8> /usr/lib/libCRFSuite.dylib
0x97cd2000 - 0x97cd2fff  libmetal_timestamp.dylib (600.0.41.2) <162963C5-F33E-30FD-8157-B59DB8AB02D5> /System/Library/PrivateFrameworks/GPUCompiler.framework/libmetal_timestamp.dylib
0x97d09000 - 0x97d1afff  libbsm.0.dylib (34) <C3A788F0-E723-30AB-9C7F-C2852397370C> /usr/lib/libbsm.0.dylib
0x97d1b000 - 0x97d28ff7  libbz2.1.0.dylib (38) <336996D6-7CB4-30EF-B481-C803BC81031E> /usr/lib/libbz2.1.0.dylib
0x97d29000 - 0x97d31fff  com.apple.frameworks.CoreDaemon (1.3 - 1.3) <C93A2C7B-6CBF-3021-8CB8-3E08D3188A30> /System/Library/PrivateFrameworks/CoreDaemon.framework/Versions/B/CoreDaemon
0x97d32000 - 0x97d45ff7  libsasl2.2.dylib (209) <E004FD06-7D2D-3341-B60D-B4FE12795735> /usr/lib/libsasl2.2.dylib
0x97d46000 - 0x97f7fff7  libFosl_dynamic.dylib (16.24) <E2B557D9-EEF4-3C53-9B54-700A57270FE9> /usr/lib/libFosl_dynamic.dylib
0x97f80000 - 0x97f83fff  libextension.dylib (78) <03890482-1E02-3150-851D-C566814F643E> /usr/lib/libextension.dylib
0x97f84000 - 0x97f86ffb  libCGXType.A.dylib (934) <47B66CA1-577F-3BBA-872A-620742A5CEAF> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib
0x97f8b000 - 0x97f8dfff  libsystem_configuration.dylib (801.1.1) <D00EDC8E-6FC3-3A34-B05D-AA332DF67920> /usr/lib/system/libsystem_configuration.dylib
0x97fe1000 - 0x98044fff  com.apple.SystemConfiguration (1.14 - 1.14) <7D86EA8A-43EA-3F4E-9DA8-56F0955A6DFE> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
0x9867b000 - 0x9867efff  libCoreVMClient.dylib (119.5) <A69BA963-5DAA-3394-9337-14C668CFCE6A> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib
0x9867f000 - 0x98693ff7  com.apple.CoreBluetooth (1.0 - 1) <303DDADD-C5CE-3AD7-BFEF-9FBD21544046> /System/Library/Frameworks/CoreBluetooth.framework/Versions/A/CoreBluetooth
0x98694000 - 0x98698ffb  com.apple.IOSurface (108.0.1 - 108.0.1) <9A1D22B6-C77B-34C6-824B-6B860C9AD6A2> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface
0x986db000 - 0x986f1fe7  libcompression.dylib (23) <720A9F79-6ACE-381E-B2D1-FCFBB740775A> /usr/lib/libcompression.dylib
0x986fd000 - 0x9871bffb  libresolv.9.dylib (60) <7A625602-36E7-3B59-8519-399014FCFD63> /usr/lib/libresolv.9.dylib
0x9871c000 - 0x98842ff7  libsqlite3.dylib (216) <9D327AD2-B032-3765-A375-1195E465612E> /usr/lib/libsqlite3.dylib
0x98ad4000 - 0x98b28ffb  com.apple.audio.CoreAudio (4.3.0 - 4.3.0) <1BCCA5C9-97D3-3C16-9D9B-4307B9371AED> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
0x98b29000 - 0x99057fdf  com.apple.vImage (8.0 - 8.0) <1212ECA9-64D7-32E8-838F-7060FCE4B79E> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
0x99058000 - 0x99063fff  com.apple.NetAuth (6.0 - 6.0) <C515AAE7-3C54-3D85-8E5C-68AB6FB5BA31> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth
0x99064000 - 0x991ddff3  com.apple.audio.toolbox.AudioToolbox (1.13 - 1.13) <C5D2A642-30D0-37C6-9813-E1842C486378> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
0x99cb2000 - 0x99d19fff  libcorecrypto.dylib (334) <855C8E99-B0B9-35E4-B8AE-68972AC1CCA1> /usr/lib/system/libcorecrypto.dylib
0x99d21000 - 0x99d23fff  com.apple.securityhi (9.0 - 55006) <36C7F06B-9223-3457-9784-6B2DC166F722> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
0x99d24000 - 0x99f46fff  com.apple.CoreImage (11.0.0 - 366) <79C76FAC-BCD1-3337-9AEA-D9502AB229FC> /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage
0x99f4f000 - 0x99f89fff  com.apple.LDAPFramework (2.4.28 - 194.5) <7DA52065-1EBB-3226-964B-708CB9625B8A> /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP
0x9a03a000 - 0x9a045ff3  libcommonCrypto.dylib (60074) <448055DC-6EBC-3C23-ADBC-4C86ABC49A87> /usr/lib/system/libcommonCrypto.dylib
0x9a046000 - 0x9a047fff  libDiagnosticMessagesClient.dylib (100) <4764E284-2331-3250-92A0-0C9614AFDEE5> /usr/lib/libDiagnosticMessagesClient.dylib
0x9a048000 - 0x9a06afff  com.apple.ProtectedCloudStorage (1.0 - 1) <95CACD33-E314-368A-84C9-7FF883EA1CD5> /System/Library/PrivateFrameworks/ProtectedCloudStorage.framework/Versions/A/ProtectedCloudStorage
0x9a06b000 - 0x9a09efe3  libsystem_m.dylib (3105) <AB252034-37BA-3B50-93F3-480B459D7E49> /usr/lib/system/libsystem_m.dylib
0x9a09f000 - 0x9a0d7ff3  libssl.0.9.8.dylib (59) <F9F5F3AE-DF62-364F-9105-39EFD1C49F3B> /usr/lib/libssl.0.9.8.dylib
0x9a107000 - 0x9a107fff  libenergytrace.dylib (10) <D926368D-8A13-395E-871C-0A924A17A77B> /usr/lib/libenergytrace.dylib
0x9a108000 - 0x9a1a6ff7  com.apple.ColorSync (4.9.0 - 4.9.0) <C289AC4F-EE0D-3365-A996-977ED694DCFD> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync
0x9a1a7000 - 0x9a247ffb  com.apple.QD (3.12 - 302) <997FA347-62FA-3E2C-8117-DCC8026E4837> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
0x9a248000 - 0x9a253ff7  libChineseTokenizer.dylib (16) <A699162E-3910-3FBB-BC2C-DA7F2AEF56A3> /usr/lib/libChineseTokenizer.dylib
0x9a2af000 - 0x9a2b0fff  liblangid.dylib (122) <735C877E-DD4B-33BC-8FD5-22C15E1765F7> /usr/lib/liblangid.dylib
0x9a2b1000 - 0x9a314fff  com.apple.CoreServices.OSServices (728.4 - 728.4) <58F71C79-38AB-30D5-AAF9-55F2877B151D> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
0x9a315000 - 0x9a414ff7  libFontParser.dylib (158) <0C0FB00B-2749-3D64-A566-9DDA17353B60> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib
0x9a415000 - 0x9a41efff  com.apple.icloud.FindMyDevice (1.0 - 1) <FCEB3A69-A95A-3DE7-9240-8C818B332404> /System/Library/PrivateFrameworks/FindMyDevice.framework/Versions/A/FindMyDevice
0x9a41f000 - 0x9a41ffff  com.apple.Carbon (154 - 157) <30EAD78E-42E0-3877-8189-3CDBD6B69315> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
0x9ac2d000 - 0x9ad7bfe7  com.apple.coreui (2.1 - 362) <07795A6A-91DC-37D1-9379-D7C443796F71> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
0x9ad7f000 - 0x9adbffff  com.apple.AppleJPEG (1.0 - 1) <D9FD3BF9-A695-339C-85CC-E627193DEEE2> /System/Library/PrivateFrameworks/AppleJPEG.framework/Versions/A/AppleJPEG
0x9adc0000 - 0x9add5ffb  libsystem_coretls.dylib (82) <39CA721D-1FC1-3482-85ED-0FA23938C8D2> /usr/lib/system/libsystem_coretls.dylib
0x9add6000 - 0x9aec1feb  libvMisc.dylib (563.3) <8E1DDD83-4AE5-3519-A77B-1EFFC7F6D75A> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
0x9aec2000 - 0x9afe7ff3  com.apple.CoreText (352.0 - 494.3) <E074F3C1-1B62-3659-B151-280C51FE90FB> /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText
0x9afe8000 - 0x9b007fff  com.apple.GenerationalStorage (2.0 - 239) <698BD3D0-84AC-39D4-8028-07FCB156C21C> /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/GenerationalStorage
0x9b008000 - 0x9b023fff  com.apple.CFOpenDirectory (10.11 - 194) <BB851767-1A2B-3E17-B9ED-E21D5154C101> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
0x9b024000 - 0x9b037fff  com.apple.Sharing (438.0.1 - 438.0.1) <9955AA44-9255-39F6-93FE-C95CDFF9B16B> /System/Library/PrivateFrameworks/Sharing.framework/Versions/A/Sharing
0x9b038000 - 0x9b060ff7  com.apple.IconServices (68 - 68) <E4FD5EBF-EEC5-3A48-926E-E4A52956254A> /System/Library/PrivateFrameworks/IconServices.framework/Versions/A/IconServices
0x9b061000 - 0x9b165fff  libJP2.dylib (1432) <197B7BED-8FF9-337D-9A2A-278844315436> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib
0x9b166000 - 0x9b169ffb  libutil.dylib (43) <C21F57D3-533D-3102-8BC5-58036C2F1387> /usr/lib/libutil.dylib
0x9b16a000 - 0x9b17bfff  libsystem_trace.dylib (200) <6DF3B2E1-9DA9-37F1-9A6E-51393091D56C> /usr/lib/system/libsystem_trace.dylib
0x9b17c000 - 0x9b195fff  libsystem_asl.dylib (322) <D791C719-A838-3A13-922D-EC0149D2F11B> /usr/lib/system/libsystem_asl.dylib
0x9bb8a000 - 0x9bbb4fff  libdispatch.dylib (500.1.5) <D71F1AF2-63A0-359C-95F3-47936C5DEC76> /usr/lib/system/libdispatch.dylib
0x9bbb5000 - 0x9bbb7ff3  com.apple.EFILogin (2.0 - 2) <917ECD49-9A0F-350D-A5B9-34B2B7D12525> /System/Library/PrivateFrameworks/EFILogin.framework/Versions/A/EFILogin
0x9bbb9000 - 0x9bbc1fff  com.apple.CoreServices.FSEvents (1222.1.1 - 1222.1.1) <557E72FD-1EA6-373F-90BB-ECDE78885C59> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/FSEvents.framework/Versions/A/FSEvents
0x9bc0e000 - 0x9bc0ffff  com.apple.TrustEvaluationAgent (2.0 - 25) <C5A969DB-6332-3B0C-9779-05B8F491A81B> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent
0x9bebd000 - 0x9bec0fff  libCoreFSCache.dylib (119.5) <A600FB26-DBB9-3F98-8A52-3D9BA3CDD484> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreFSCache.dylib
0x9c237000 - 0x9c24cff3  libCGInterfaces.dylib (317.2) <29CE0354-A311-3D28-A9B8-9DAD679BBCA3> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/Libraries/libCGInterfaces.dylib
0x9c24d000 - 0x9c2eefff  com.apple.ink.framework (10.9 - 214) <4080C194-91A4-37F2-89B4-913F6EE199AA> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
0x9c2ef000 - 0x9c307ff7  libSparseBLAS.dylib (1159) <1101AE06-4107-3DCD-ADE0-06B42B32AA4B> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparseBLAS.dylib
0x9c308000 - 0x9c330ffb  libxpc.dylib (755.1.19) <E6BABCAF-E6DC-3475-BC47-8A79D54E0746> /usr/lib/system/libxpc.dylib
0x9c331000 - 0x9c351fff  libsystem_kernel.dylib (3247.1.106) <73C35AC7-93C0-3A7C-846B-AC5BBAB187EA> /usr/lib/system/libsystem_kernel.dylib
0x9c352000 - 0x9c35bffb  com.apple.CommonAuth (4.0 - 2.0) <ACDE23E4-444D-3A8E-B8ED-BD17E39CE775> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth
0x9c35c000 - 0x9c442ff7  unorm8_rgba.dylib (2.6.4.1) <D439AB49-BEFA-3377-ACF9-C5AC200AE971> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/ImageFormats/unorm8_rgba.dylib
0x9c443000 - 0x9c443fff  libunc.dylib (29) <6C251ECD-0449-384F-A5E3-D277C8DD9E13> /usr/lib/system/libunc.dylib
0x9c65a000 - 0x9c662ffb  libsystem_pthread.dylib (137.1.1) <C34AB3EC-25DB-325C-BA96-123772887436> /usr/lib/system/libsystem_pthread.dylib
0x9c663000 - 0x9c67aff7  libmarisa.dylib (4) <B75FD855-AFE1-3F8F-A9D4-AA2A2B268B43> /usr/lib/libmarisa.dylib
0x9c67b000 - 0x9c6a4fff  libRIP.A.dylib (934) <2C3D18A2-FF9D-301D-9805-D1E62AC95DE1> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib
0x9c6a5000 - 0x9c7befff  com.apple.desktopservices (1.10 - 1.10) <A10F7453-5488-3C34-8BDC-8A93BEDCFCF3> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
0x9c7bf000 - 0x9c7c8fff  libcopyfile.dylib (127) <C1D5D894-E71C-3E75-9639-82C846482A84> /usr/lib/system/libcopyfile.dylib
0x9c7c9000 - 0x9c7e3ff7  liblzma.5.dylib (10) <777FDB7B-D359-389C-AA0C-B1434D221643> /usr/lib/liblzma.5.dylib
0x9c7e4000 - 0x9c821ff7  com.apple.DebugSymbols (132 - 132) <1D10954E-12BA-363A-9D0B-99B4B1727D30> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols
0x9c822000 - 0x9c827fff  com.apple.TCC (1.0 - 1) <78AC9326-4E46-3E4F-99AD-2DD1F8F7349E> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC
0x9c82c000 - 0x9c82ffff  libsystem_sandbox.dylib (459.1.8) <D0347A44-B63A-3099-9F96-B6665F415B85> /usr/lib/system/libsystem_sandbox.dylib
0x9c830000 - 0x9c831fff  libSystem.B.dylib (1225.1.1) <B67A590D-E98C-3BE5-8FD7-9D786A7F2228> /usr/lib/libSystem.B.dylib
0x9c832000 - 0x9c85cfff  libxslt.1.dylib (14) <4B064877-1EC8-33E3-A62C-1655CC45C9CA> /usr/lib/libxslt.1.dylib
0x9c868000 - 0x9cc60ffb  com.apple.CoreGraphics (1.600.0 - 934) <C2B6D2FD-6F81-33CE-893A-462103FC305D> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
0x9cc61000 - 0x9ccf2fff  com.apple.CoreSymbolication (3.1 - 58048.1) <02DF7685-5F34-3D5B-9978-E2EA4599B877> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication
0x9ccf3000 - 0x9cd0cfff  com.apple.Kerberos (3.0 - 1) <13723710-0A71-3BD6-BC0E-07B6D61744E8> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
0x9cd0d000 - 0x9cd30ff3  libc++abi.dylib (125) <7F24A2B6-32BF-3129-8FF4-A7CCEB237BA1> /usr/lib/libc++abi.dylib
0x9cd31000 - 0x9cd57ffb  com.apple.MultitouchSupport.framework (304.9 - 304.9) <D8CC074C-6B51-3B8F-9531-702E01AD10EE> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport
0x9d057000 - 0x9d058fff  libremovefile.dylib (41) <59D0F532-1D12-3CB0-841A-E79E85616D70> /usr/lib/system/libremovefile.dylib
0x9d0e5000 - 0x9d0e5fff  libsystem_blocks.dylib (65) <044CF869-766A-3B8C-853B-D840F7E768D1> /usr/lib/system/libsystem_blocks.dylib
0x9d0e8000 - 0x9d101fff  libsystem_malloc.dylib (67) <01C0F706-2B84-3F46-935D-7C4A6FC557E3> /usr/lib/system/libsystem_malloc.dylib
0x9d102000 - 0x9d178ff3  com.apple.securityfoundation (6.0 - 55126) <F96764E4-0071-385E-82AD-B24B788940D4> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
0x9d179000 - 0x9d17bfff  com.apple.loginsupport (1.0 - 1) <7389284A-6636-36D8-8D49-1409B76BA651> /System/Library/PrivateFrameworks/login.framework/Versions/A/Frameworks/loginsupport.framework/Versions/A/loginsupport
0x9d17c000 - 0x9d210ff3  com.apple.PerformanceAnalysis (1.0 - 1) <D9BC2DF1-8114-30BF-919C-B1CF206B75B6> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis
0x9d524000 - 0x9d526ffb  libRadiance.dylib (1432) <3697C272-3F13-3555-9E1D-31D15DC7E22A> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
0x9d527000 - 0x9d527fff  com.apple.Cocoa (6.11 - 22) <7B03083A-B52A-3AE7-89C1-4449FBC2C303> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
0x9d528000 - 0x9d52efff  com.apple.ImageCapture (9.0 - 9.0) <25EECDAF-3C6D-3DFA-944C-A42E93028700> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture
0x9d53b000 - 0x9d5b0fff  com.apple.SearchKit (1.4.0 - 1.4.0) <8B43618A-1960-3210-A6D9-B01505DC7523> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
0x9d5b1000 - 0x9d792fff  com.apple.QuartzCore (1.11 - 410.7) <D4ADECED-78CB-38EE-9197-F617474B2A7E> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
0x9d793000 - 0x9da4eff7  com.apple.CoreData (120 - 640) <647744F2-D1A8-36BF-A4D9-CA0F0F917D58> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
0x9da4f000 - 0x9dee1fff  com.apple.CoreFoundation (6.9 - 1253) <2CD766DE-FF4A-3F76-B7B3-A11EA33DFF82> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x9dee2000 - 0x9e23d30b  libobjc.A.dylib (680) <79E434D9-37AB-333E-9568-05C72E246313> /usr/lib/libobjc.A.dylib
0x9e23e000 - 0x9e247fff  com.apple.DiskArbitration (2.7 - 2.7) <E57CBC87-8FCF-39F4-9637-0B6DA9D264EA> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
0x9e248000 - 0x9e248fff  com.apple.CoreServices (728.4 - 728.4) <70A9AE65-0F40-3B9E-8A64-4276FEB94D49> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
0x9e249000 - 0x9e24cff7  com.apple.help (1.3.3 - 46) <5C5CD61C-B698-35BD-A976-3AD57AF7E8D5> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
0x9e24d000 - 0x9e2a2ff7  com.apple.htmlrendering (77 - 1.1.4) <EA28C134-4C13-3C4A-A8EB-7AA38794C18A> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering
0x9e41a000 - 0x9e44bfff  com.apple.CoreServicesInternal (248 - 248) <AADC2C79-4DE7-3F99-8BDD-361927D4E4ED> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal
0x9e44c000 - 0x9e44cfff  libkeymgr.dylib (28) <37F88FF9-BB2F-3703-9283-5CC7BF7D84EA> /usr/lib/system/libkeymgr.dylib
0x9e458000 - 0x9e462ffb  com.apple.audio.SoundManager (4.2 - 4.2) <4DD24BFF-123C-3E9C-B255-1F85C4F81ADB> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CarbonSound.framework/Versions/A/CarbonSound

External Modification Summary:
 Calls made by other processes targeting this process:
   task_for_pid: 1
   thread_create: 0
   thread_set_state: 0
 Calls made by this process:
   task_for_pid: 0
   thread_create: 0
   thread_set_state: 0
 Calls made by all processes on this machine:
   task_for_pid: 3575
   thread_create: 0
   thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=170.8M resident=0K(0%) swapped_out_or_unallocated=170.8M(100%)
Writable regions: Total=72.7M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=72.7M(100%)

                               VIRTUAL   REGION 
REGION TYPE                        SIZE    COUNT (non-coalesced) 
===========                     =======  ======= 
Accelerate.framework               128K        2 
Activity Tracing                  2048K        2 
CG backing stores                 1728K        4 
CG image                            12K        4 
CG shared images                   240K        7 
CoreAnimation                       20K        5 
CoreUI image data                  236K        9 
CoreUI image file                  192K        4 
Kernel Alloc Once                    4K        2 
MALLOC                            31.0M       35 
MALLOC guard page                   48K       10 
MALLOC_LARGE (reserved)            512K        4         reserved VM address space (unallocated)
Memory Tag 242                      12K        2 
OpenCL                               8K        2 
Process Corpse Info               2048K        2 
Stack                             2712K        8 
Stack Guard                         28K        8 
VM_ALLOCATE                        148K       18 
__DATA                            8872K      222 
__IMAGE                            528K        2 
__LINKEDIT                        50.1M       22 
__OBJC                            2440K       59 
__TEXT                           120.6M      230 
__UNICODE                          552K        2 
__UNIXSTACK                       16.0M        2 
mapped file                      170.7M      142 
shared memory                     16.3M        7 
===========                     =======  ======= 
TOTAL                            426.7M      789 
TOTAL, minus reserved VM space   426.2M      789 

Model: MacBookPro7,1, BootROM MBP71.0039.B0E, 2 processors, Intel Core 2 Duo, 2.4 GHz, 4 GB, SMC 1.62f7
Graphics: NVIDIA GeForce 320M, NVIDIA GeForce 320M, PCI, 256 MB
Memory Module: BANK 0/DIMM0, 2 GB, DDR3, 1067 MHz, 0x80AD, 0x484D54313235533654465238432D47372020
Memory Module: BANK 1/DIMM0, 2 GB, DDR3, 1067 MHz, 0x80AD, 0x484D54313235533654465238432D47372020
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x8D), Broadcom BCM43xx 1.0 (5.106.98.100.24)
Bluetooth: Version 4.4.0f4 16320, 3 services, 27 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en1
Serial ATA Device: Hitachi HTS545025B9SA02, 250.06 GB
Serial ATA Device: MATSHITADVD-R   UJ-898
USB Device: USB 2.0 Bus
USB Device: Card Reader
USB Device: USB 2.0 Bus
USB Device: Built-in iSight
USB Device: USB Bus
USB Device: BRCM2046 Hub
USB Device: Bluetooth USB Host Controller
USB Device: IR Receiver
USB Device: Apple Internal Keyboard / Trackpad
USB Device: USB Bus
Thunderbolt Bus:

----------
components: Macintosh
messages: 252922
nosy: Ivendsz, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: It crashes as long as I press "(parenthese)
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Tue Oct 13 11:27:47 2015
From: report at bugs.python.org (=?utf-8?q?Mart=C3=AD_Congost_Tapias?=)
Date: Tue, 13 Oct 2015 09:27:47 +0000
Subject: [New-bugs-announce] [issue25390] Can't define a typing.Union
 containing a typing.re.Pattern
Message-ID: <1444728467.55.0.552197008785.issue25390@psf.upfronthosting.co.za>


New submission from Mart? Congost Tapias:

Defining a union of typing.re.Pattern and anything that isn't AnyStr raises a TypeError exception.

Example:

from typing import Union, re

def foo(pattern: Union[str, re.Pattern]) -> None:
    pass

Exception traceback:

Traceback (most recent call last):
  File "/tmp/testtyping.py", line 7, in <module>
    def foo(pattern: Union[str, re.Pattern]) -> None:
  File "/usr/local/lib/python3.5/typing.py", line 534, in __getitem__
    dict(self.__dict__), parameters, _root=True)
  File "/usr/local/lib/python3.5/typing.py", line 491, in __new__
    for t2 in all_params - {t1} if not isinstance(t2, TypeVar)):
  File "/usr/local/lib/python3.5/typing.py", line 491, in <genexpr>
    for t2 in all_params - {t1} if not isinstance(t2, TypeVar)):
TypeError: issubclass() arg 1 must be a class

----------
components: Interpreter Core
messages: 252923
nosy: Mart? Congost Tapias
priority: normal
severity: normal
status: open
title: Can't define a typing.Union containing a typing.re.Pattern
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Oct 13 13:07:40 2015
From: report at bugs.python.org (Lewis Haley)
Date: Tue, 13 Oct 2015 11:07:40 +0000
Subject: [New-bugs-announce] [issue25391] difflib.SequenceMatcher(...).ratio
 gives bad/wrong/unexpected low value with repetitous strings
Message-ID: <1444734460.53.0.30170524569.issue25391@psf.upfronthosting.co.za>


New submission from Lewis Haley:

Consider the following snippet:

import difflib

first = u'location,location,location'
for second in (
    u'location.location.location',  # two periods (no commas)
    u'location.location,location',  # period after first
    u'location,location.location',  # period after second
    u'location,location,location',  # perfect match
):
    edit_dist = difflib.SequenceMatcher(None, first, second).ratio()
    print("comparing %r vs. %r gives edit dist: %g" % (first, second, edit_dist))

I would expect the second and third tests to give the same result, but in reality:

comparing u'location,location,location' vs. u'location.location.location' gives edit dist: 0.923077
comparing u'location,location,location' vs. u'location.location,location' gives edit dist: 0.653846
comparing u'location,location,location' vs. u'location,location.location' gives edit dist: 0.961538
comparing u'location,location,location' vs. u'location,location,location' gives edit dist: 1

The same results are received from Python 3.4.

>From experimenting, it seems that when the period comes after the first "location", the longest match found is the final two "locations" from the first string against the first two "locations" from the second string.

In [31]: difflib.SequenceMatcher(None, u'location,location,location', u'location.location,location').ratio()
Out[31]: 0.6538461538461539

In [32]: difflib.SequenceMatcher(None, u'location,location,location', u'location.location,location').get_matching_blocks()
Out[32]: [Match(a=0, b=9, size=17), Match(a=26, b=26, size=0)]

In [33]: difflib.SequenceMatcher(None, u'location,location,location', u'location,location.location').ratio()Out[33]: 0.9615384615384616

In [34]: difflib.SequenceMatcher(None, u'location,location,location', u'location,location.location').get_matching_blocks()
Out[34]: 
[Match(a=0, b=0, size=17),
 Match(a=18, b=18, size=8),
 Match(a=26, b=26, size=0)]

Using `quick_ratio` instead of `ratio` gives (what I consider to be) the correct result.

----------
components: Library (Lib)
files: test.py
messages: 252925
nosy: Lewis Haley
priority: normal
severity: normal
status: open
title: difflib.SequenceMatcher(...).ratio gives bad/wrong/unexpected low value with repetitous strings
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file40767/test.py

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

From report at bugs.python.org  Tue Oct 13 13:45:29 2015
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 13 Oct 2015 11:45:29 +0000
Subject: [New-bugs-announce] [issue25392] setup.py --quiet doesn't silence
 "no previously-included directories" warnings from MANIFEST.in
Message-ID: <1444736729.8.0.451337139853.issue25392@psf.upfronthosting.co.za>


New submission from Ned Batchelder:

The MANIFEST.in file for coverage.py excludes directories line doc/_build.  If I run "python setup.py --quiet develop", I get output like this:

    python3.5 setup.py --quiet develop
    no previously-included directories found matching 'doc/_build'
    no previously-included directories found matching 'tests/eggsrc/dist'
    no previously-included directories found matching 'tests/eggsrc/*.egg-info'

This is because I'm running the command in a working tree that hasn't had the docs built yet.  But I need MANIFEST.in to exclude that directory for the case where I do run the command in dirty tree.

1) Why is it a warning to exclude directories that don't exist in the first place?  That's not a problem.

2) Why doesn't --quiet silence those warnings?

----------
messages: 252927
nosy: nedbat
priority: normal
severity: normal
status: open
title: setup.py --quiet doesn't silence "no previously-included directories" warnings from MANIFEST.in
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Oct 13 16:29:02 2015
From: report at bugs.python.org (=?utf-8?b?zqfPgc6uz4PPhM6/z4IgzpPOtc+Jz4HOs86vzr/PhSAoQ2hyaXN0b3MgR2Vv?= =?utf-8?q?rgiou=29?=)
Date: Tue, 13 Oct 2015 14:29:02 +0000
Subject: [New-bugs-announce] [issue25393] 'resource' module documentation
	error
Message-ID: <1444746542.39.0.814536865396.issue25393@psf.upfronthosting.co.za>


New submission from ??????? ???????? (Christos Georgiou):

https://docs.python.org/3.5/library/resource.html

https://docs.python.org/3.5/library/resource.html#resource.RLIMIT_FSIZE ends with the sentence "This only affects the stack of the main thread in a multi-threaded process."

I believe this sentence should be appended to https://docs.python.org/3.5/library/resource.html#resource.RLIMIT_STACK

This error also exists in previous versions of python documentation.

----------
assignee: docs at python
components: Documentation
messages: 252935
nosy: docs at python, tzot
priority: normal
severity: normal
status: open
title: 'resource' module documentation error
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Oct 13 19:32:29 2015
From: report at bugs.python.org (Chris Seto)
Date: Tue, 13 Oct 2015 17:32:29 +0000
Subject: [New-bugs-announce] [issue25394] CoroWrapper breaks gen.throw
Message-ID: <1444757549.53.0.051433336619.issue25394@psf.upfronthosting.co.za>


New submission from Chris Seto:

When asyncio.coroutines._DEBUG is set to True all coroutines are wrapped in a CoroWrapper.
The definition of CoroWrapper.throw only excepts a single argument, exc.
It should accept an exception info tuple as returned from sys.exc_info just as normal generators do.

----------
components: asyncio
files: example.py
messages: 252942
nosy: Chris Seto, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: CoroWrapper breaks gen.throw
type: crash
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40769/example.py

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

From report at bugs.python.org  Tue Oct 13 21:39:41 2015
From: report at bugs.python.org (Simonas Kazlauskas)
Date: Tue, 13 Oct 2015 19:39:41 +0000
Subject: [New-bugs-announce] [issue25395] SIGSEGV using json.tool
Message-ID: <1444765181.78.0.70980847428.issue25395@psf.upfronthosting.co.za>


New submission from Simonas Kazlauskas:

cat attachment | python -m json.tool

reliably makes python to SIGSEGV on Arch linux

$ python --version
Python 3.5.0
$ uname -a
Linux kumabox 4.2.2-1-ARCH #1 SMP PREEMPT Tue Sep 29 22:21:33 CEST 2015 x86_64 GNU/Linux

Does not fail on 2.7.10.

----------
components: Library (Lib)
files: ast.json
messages: 252954
nosy: nagisa
priority: normal
severity: normal
status: open
title: SIGSEGV using json.tool
type: crash
versions: Python 3.5
Added file: http://bugs.python.org/file40773/ast.json

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

From report at bugs.python.org  Tue Oct 13 21:41:49 2015
From: report at bugs.python.org (Brian)
Date: Tue, 13 Oct 2015 19:41:49 +0000
Subject: [New-bugs-announce] [issue25396] A Python runtime not could be
	located.
Message-ID: <1444765309.47.0.487032440124.issue25396@psf.upfronthosting.co.za>


New submission from Brian:

Hello - I'm new to this community and an system error brings me here.  Thank you all in advance for any help and support!

I'm using a MacBook Pro (Retina, 15-inch, Late 2013) with OS 10.11 El Capitan.  I receive the following error every 15-30 minutes:

--------------------
"Utility[601]: A Python runtime not could be located.  You may need to install a framework build of Python, or edit the PyRuntimeLocations array in this application's Info.plist file."

I have the option to "Open Console" or "Terminate" to clear the window.
--------------------


I wasn't aware of Python before the error popped up which leads me to believe a third party application used/uses Python in the background.

I installed Python 3.5.0 and I still received the error.  I removed Python 3.5.0 and I still received the error.  I installed Python 2.7.10 and I still received the error.  I removed Python 2.7.10 and I still received the error.

I'm at a loss for options moving forward and the error window popping up every 20 minutes is not the most ideal situation for teaching via PowerPoint.  

HELP :) If there's a diagnostic report I need to run, please let me know and I'll run it.

Thank you in advance,
Brian

----------
messages: 252955
nosy: bkbdrummer
priority: normal
severity: normal
status: open
title: A Python runtime not could be located.

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

From report at bugs.python.org  Wed Oct 14 00:50:58 2015
From: report at bugs.python.org (Mike Frysinger)
Date: Tue, 13 Oct 2015 22:50:58 +0000
Subject: [New-bugs-announce] [issue25397] improve
	ac_cv_have_long_long_format GCC fallback
Message-ID: <1444776658.15.0.414406307364.issue25397@psf.upfronthosting.co.za>


New submission from Mike Frysinger:

the ac_cv_have_long_long_format test has a nice compile-time fallback for gcc based compilers:
    CFLAGS="$CFLAGS -Werror -Wformat"
    AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
        #include <stdio.h>
        #include <stddef.h>
      ]], [[
      char *buffer;
      sprintf(buffer, "%lld", (long long)123);
      sprintf(buffer, "%lld", (long long)-123);
      sprintf(buffer, "%llu", (unsigned long long)123);
      ]])],
      ac_cv_have_long_long_format=yes
    )

unfortunately, this turns on the global -Werror flag in order to check things.  that means if the code triggers unrelated warnings, the test still fails ;(.  this comes up w/bionic which complains about unsafe use of the sprintf function, and can come up in general in this code because buffer is not initialized :).

the good news is that gcc-4.2 has supported a directed -Werror=format option.
https://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/Warning-Options.html

so instead of using -Werror -Wformat, you could use -Werror=format.  the downside is that the fallback no longer works with <=gcc-4.1, but maybe that's ok considering gcc-4.2 was released May 2007 (almost 9 years ago) ?

note: this also applies to various other tests in the configure file.

NB: landing a fix in py3.5+ (and ignoring 3.[0-4]) is fine, but please also to fix py2.7 :)

----------
components: Cross-Build
messages: 252968
nosy: vapier
priority: normal
severity: normal
status: open
title: improve ac_cv_have_long_long_format GCC fallback
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/issue25397>
_______________________________________

From report at bugs.python.org  Wed Oct 14 02:42:28 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Oct 2015 00:42:28 +0000
Subject: [New-bugs-announce] [issue25399] Optimize bytearray % args
Message-ID: <1444783348.44.0.280990123345.issue25399@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Optimize bytearray % args

Don't create temporary bytes objects: modify _PyBytes_Format() to create work
directly on bytearray objects.

* _PyBytesWriter: add use_bytearray attribute to use a bytearray buffer
* Rename _PyBytes_Format() to _PyBytes_FormatEx() just in case if something
  outside CPython uses it
* _PyBytes_FormatEx() now uses (char*, Py_ssize_t) for the input string, so
  bytearray_format() doesn't need tot create a temporary input bytes object
* Add use_bytearray parameter to _PyBytes_FormatEx() which is passed to
  _PyBytesWriter, to create a bytearray buffer instead of a bytes buffer

----------
files: bytearray_format.patch
keywords: patch
messages: 252970
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Optimize bytearray % args
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file40776/bytearray_format.patch

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

From report at bugs.python.org  Wed Oct 14 03:21:42 2015
From: report at bugs.python.org (Peter Wirtz)
Date: Wed, 14 Oct 2015 01:21:42 +0000
Subject: [New-bugs-announce] [issue25400] robotparser doesn't return crawl
	delay for default entry
Message-ID: <1444785702.73.0.849541373226.issue25400@psf.upfronthosting.co.za>


New submission from Peter Wirtz:

After changeset http://hg.python.org/lookup/dbed7cacfb7e, calling the crawl_delay method for a robots.txt files that has a crawl-delay for * useragents always returns None.

Ex:

Python 3.6.0a0 (default:1aae9b6a6929+, Oct  9 2015, 22:08:05)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib.robotparser
>>> parser = urllib.robotparser.RobotFileParser()
>>> parser.set_url('https://www.carthage.edu/robots.txt')
>>> parser.read()
>>> parser.crawl_delay('test_robotparser')
>>> parser.crawl_delay('*')
>>> print(parser.default_entry.delay)
120
>>>

Excerpt from https://www.carthage.edu/robots.txt:

User-agent: *
Crawl-Delay: 120
Disallow: /cgi-bin

I have written a patch that solves this. With patch, output is:

Python 3.6.0a0 (default:1aae9b6a6929+, Oct  9 2015, 22:08:05)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib.robotparser
>>> parser = urllib.robotparser.RobotFileParser()
>>> parser.set_url('https://www.carthage.edu/robots.txt')
>>> parser.read()
>>> parser.crawl_delay('test_robotparser')
120
>>> parser.crawl_delay('*')
120
>>> print(parser.default_entry.delay)
120
>>>

This also applies to the request_rate method.

----------
components: Library (Lib)
files: robotparser_crawl_delay.patch
keywords: patch
messages: 252971
nosy: pwirtz
priority: normal
severity: normal
status: open
title: robotparser doesn't return crawl delay for default entry
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file40777/robotparser_crawl_delay.patch

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

From report at bugs.python.org  Wed Oct 14 11:09:20 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Oct 2015 09:09:20 +0000
Subject: [New-bugs-announce] [issue25401] Optimize bytes.fromhex() and
	bytearray.fromhex()
Message-ID: <1444813760.4.0.225046078014.issue25401@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch optimizes bytes.fromhex() and bytearray.fromhex():

* Fast-path working on a char* string for ASCII string
* Slow-path for non-ASCII string
* Replace slow hex_digit_to_int() function with a O(1) lookup in _PyLong_DigitValue precomputed table
* Use _PyBytesWriter API to handle the buffer
* Check the error position in error messages

----------
files: fromhex.patch
keywords: patch
messages: 252979
nosy: haypo
priority: normal
severity: normal
status: open
title: Optimize bytes.fromhex() and bytearray.fromhex()
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file40779/fromhex.patch

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

From report at bugs.python.org  Wed Oct 14 13:42:43 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Oct 2015 11:42:43 +0000
Subject: [New-bugs-announce] [issue25402] Accurater estimation of the number
 of digits in int to decimal string conversion
Message-ID: <1444822963.9.0.112952407665.issue25402@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Int to decimal string conversion (function long_to_decimal_string_internal() at Objects/longobject.c:1583) has a limitation. On 32-bit platform you can't convert integers larger than 2**2**31 (10**646456993). Proposed patch removes this limitation [*].

It also decreases memory requirements for intermediate buffer on 10%. The size of intermediate buffer (in digits) depends on the size of the integer. Unpatched:

For 15-bit digits: size*15/4/3 = size*1.25
For 30-bit digits: size*30/9/3 = size*1.11

Patched:
For 15-bit digits: size*15/4/3.3 = size*1.14
For 30-bit digits: size*30/9/3.3 = size*1.01


[*] Converting such large integers to decimal string can be not finished for reasonable time, because it has quadratic complexity. On my netbook the estimated time of calculating str(2**2**31) is 5 years. But this is different issue.

----------
components: Interpreter Core
files: long_to_decimal_string_number_of_digits.patch
keywords: patch
messages: 252985
nosy: mark.dickinson, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Accurater estimation of the number of digits in int to decimal string conversion
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file40782/long_to_decimal_string_number_of_digits.patch

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

From report at bugs.python.org  Wed Oct 14 13:49:00 2015
From: report at bugs.python.org (Pavel Ivanov)
Date: Wed, 14 Oct 2015 11:49:00 +0000
Subject: [New-bugs-announce] [issue25403] urllib.parse.urljoin is broken in
	python 3.5
Message-ID: <1444823340.35.0.0533245258476.issue25403@psf.upfronthosting.co.za>


New submission from Pavel Ivanov:

urllib.parse.urljoin does not conform the RFC 1808 in case of joining relative URL?s containing ?..? path components anymore.

Examples:

Python 3.4: 
>>> urllib.parse.urljoin('http://a.com', '..')
'http://a.com/..'
Python 3.5:
>>> urllib.parse.urljoin('http://a.com', '..')
'http://a.com/'

Python 3.4: 
>>> urllib.parse.urljoin('a/?, '..')
''
Python 3.5:
>>> urllib.parse.urljoin('a/', '..')
'/'

Python 3.4: 
>>> urllib.parse.urljoin('a/?, '../..')
'..'
Python 3.5:
>>> urllib.parse.urljoin('a/', '../..')
'/'

Python 3.4 conforms RFC 1808 in these scenarios, but Python 3.5 does not.

----------
components: Interpreter Core, Library (Lib)
messages: 252986
nosy: Pavel Ivanov
priority: normal
severity: normal
status: open
title: urllib.parse.urljoin is broken in python 3.5
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Oct 14 14:36:27 2015
From: report at bugs.python.org (Michael Schlenker)
Date: Wed, 14 Oct 2015 12:36:27 +0000
Subject: [New-bugs-announce] [issue25404] ssl.SSLcontext.load_dh_params()
 does not handle unicode filenames properly
Message-ID: <1444826187.38.0.734586543163.issue25404@psf.upfronthosting.co.za>


New submission from Michael Schlenker:

The load_dh_params() method of SSLContext does not properly handle unicode filenames on Windows (like load_verify_location() does).

It should convert any passed unicode path to the filesystem encoding.

This is already fixed in the 3.x head revision, by loading the file via python instead of the OpenSSL BIO functions, but is broken in 2.7.10.

Currently it silently works for most files due to an implicit conversion to string, but with the wrong default encoding instead of filesystem encoding.

----------
components: Extension Modules
messages: 252987
nosy: schlenk
priority: normal
severity: normal
status: open
title: ssl.SSLcontext.load_dh_params() does not handle unicode filenames properly
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Oct 14 15:07:55 2015
From: report at bugs.python.org (Paul Moore)
Date: Wed, 14 Oct 2015 13:07:55 +0000
Subject: [New-bugs-announce] [issue25405] User install of 3.5 removes py.exe
	from C:\Windows
Message-ID: <1444828075.41.0.296808473589.issue25405@psf.upfronthosting.co.za>


New submission from Paul Moore:

I have had a user install of Python 3.5rc3 for some time on one of my PCs. It also had plenty of other versions on there - 3.4, 3.3, 2.7 and 2.6. The 3.5rc3 install was a user install.

I have my Python 3.4 install set up on PATH, and I've configured py.ini to run 3.4 by default. The py launcher was installed in C:\Windows and had version 3.5.123.1013. I can't honestly recall how it got there.

I just got round to upgrading to 3.5.0 final. I downloaded the installer and ran it, selecting the default "Upgrade my existing install" option. It ran fine, without elevation, but at the end it reported in the progress area "Previous Version" and requested elevation.

When it had finished, py.exe was gone, and I had no filetype associations for .py files.

This cannot be correct behaviour. Even for a user install I expect the launcher to work, and filetype associations to exist, by default.

Worse still, I then went into Add/Remove programs and selected "Modify" expecting to have to add these back. But the dialog showed them as already selected. When I ran the installer (which in theory should have done nothing, as I had made no changes) it requested elevation and ran, reinstating py.exe into C:\Windows (now at version 3.5.150.1013) and putting back the associations.

While I have a complex setup, and expect to do a certain amount of work to get the choices the way I want, the above is utterly confusing - there was no indication that the installer was going to do some of the things it did, and a "no modification" modify *certainly* shouldn't be making changes...

----------
assignee: steve.dower
components: Installation, Windows
messages: 252990
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: User install of 3.5 removes py.exe from C:\Windows
versions: Python 3.5

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

From report at bugs.python.org  Wed Oct 14 15:20:03 2015
From: report at bugs.python.org (Cruise Liu)
Date: Wed, 14 Oct 2015 13:20:03 +0000
Subject: [New-bugs-announce] [issue25406] OrderedDict.move_to_end may cause
	crash in python 3.5
Message-ID: <1444828803.02.0.823696555455.issue25406@psf.upfronthosting.co.za>


New submission from Cruise Liu:

Following code will crash python. Tested on linux and windows.

Python 3.5.0 (default, Sep 20 2015, 11:28:25) 
[GCC 5.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import collections
>>> x = collections.OrderedDict([ ('a', 1), ('b', 2), ('c', 3) ])
>>> x.move_to_end('c', last = False)
>>> x.move_to_end('a', last = False)
>>> x
Segmentation fault (core dumped)

----------
components: Library (Lib)
messages: 252991
nosy: Cruise Liu
priority: normal
severity: normal
status: open
title: OrderedDict.move_to_end may cause crash in python 3.5
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Wed Oct 14 17:59:16 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 14 Oct 2015 15:59:16 +0000
Subject: [New-bugs-announce] [issue25407] Update PEP 4 to keep modules in
	Python 3
Message-ID: <1444838356.16.0.900937210643.issue25407@psf.upfronthosting.co.za>


New submission from Brett Cannon:

In https://mail.python.org/pipermail/python-dev/2015-September/141499.html I asked if people thought it was okay to deprecate modules in Python 3 but to keep them around until Python 4. People agreed and so now I need to actually execute on that plan by updating PEP 4 and the various deprecation messages in the stdlib.

----------
assignee: brett.cannon
components: Documentation
messages: 253001
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Update PEP 4 to keep modules in Python 3

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

From report at bugs.python.org  Wed Oct 14 19:55:07 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 14 Oct 2015 17:55:07 +0000
Subject: [New-bugs-announce] [issue25408] Consider dropping html5lib and
 spambayes from the default benchmark set
Message-ID: <1444845307.71.0.511849152884.issue25408@psf.upfronthosting.co.za>


New submission from Brett Cannon:

The spambayes and html5lib benchmarks are not compatible with Python 3, so I think we should remove them from the default set (they can obviously stay in the benchmark suite).

And while I'm thinking about it, maybe pull etree since we already have the JSON tests in the default for serialization measurements?

----------
components: Benchmarks
messages: 253014
nosy: brett.cannon, pitrou
priority: normal
severity: normal
status: open
title: Consider dropping html5lib and spambayes from the default benchmark set

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

From report at bugs.python.org  Thu Oct 15 08:04:51 2015
From: report at bugs.python.org (Florian Bruhin)
Date: Thu, 15 Oct 2015 06:04:51 +0000
Subject: [New-bugs-announce] [issue25409] fnmatch.fnmatch normalizes
 slashes/backslashes on Windows
Message-ID: <1444889091.12.0.272630391848.issue25409@psf.upfronthosting.co.za>


New submission from Florian Bruhin:

On Windows 8:

>>> fnmatch.fnmatch(r'foo\bar', 'foo/bar')
True
>>> fnmatch.fnmatchcase(r'foo\bar', 'foo/bar')
False

This is due to fnmatch calling os.path.normpath on the arguments (to get the case-sensitivity of the filesystem), which on Windows *also* happens to normalize / to \.

It's probably a bad idea to change the behaviour now, but I think at least this should be clarified in the docs.

----------
components: Library (Lib)
messages: 253030
nosy: The Compiler, eric.araujo, ezio.melotti, georg.brandl, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: fnmatch.fnmatch normalizes slashes/backslashes on Windows
type: behavior
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Thu Oct 15 10:05:08 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Oct 2015 08:05:08 +0000
Subject: [New-bugs-announce] [issue25410] Clean up and fix OrderedDict
Message-ID: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch cleans up and fixes minor bugs in C implementation of OrderedDict.

1. Used the "p" format unit instead of manual calling PyObject_True() for parsing boolean parameters.

2. Used _Py_Identifier private API instead of char* API if appropriate.

3. Used Py_TYPE instead of the __class__ attribute as in other extension types.

4. Fixed od_fast_nodes size calculation in  __sizeof__().

5. Simplified __reduce__() taking into account that __dict__ is empty in C implementation of OrderedDict.

6. popitem() with wrong number of arguments now raises TypeError instead of KeyError for empty dictionary.

7. Python implementation of move_to_end() calls key comparing only once in common case. C implementation called key comparing twice, it first compares a key with first or last key. Now C implementation calls key comparing only once in common case.

8. Used PyUnicode_FromFormat() instead of str.__mod__ in __repr__().

9. update() now takes into account that args and kwargs are always tuple and dict (if not NULL).

10. Got rid of PyMapping_Items() in update(). PyMapping_Items() creates a copy of items as a list, this is not needed.

Also applied other cleanups. The size of sources is decreased by 105 lines.

 Objects/odictobject.c |  194 +-----------------------------!!!!!!!!!!!!!!!!!!
 1 file changed, 6 insertions(+), 111 deletions(-), 77 modifications(!)

----------
components: Extension Modules
files: odict_cleanup.patch
keywords: patch
messages: 253033
nosy: eric.snow, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Clean up and fix OrderedDict
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40785/odict_cleanup.patch

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

From report at bugs.python.org  Thu Oct 15 15:02:06 2015
From: report at bugs.python.org (simon04)
Date: Thu, 15 Oct 2015 13:02:06 +0000
Subject: [New-bugs-announce] [issue25411] SMTPHandler in the logging module
 fails with unicode strings
Message-ID: <1444914126.08.0.971116617077.issue25411@psf.upfronthosting.co.za>


New submission from simon04:

This relates to the unresolved issue9208 (Python 2).

SMTPHandler fails when receiving unicode strings.

Example (from msg109621):
import logging,logging.handlers
smtpHandler = logging.handlers.SMTPHandler(
    mailhost=("smtp.free.fr",25),
    fromaddr="from at free.fr", toaddrs="to at free.fr",
    subject=u"error message")
LOG = logging.getLogger()
LOG.addHandler(smtpHandler)
LOG.error(u"accentu\u00E9")

? fails:
--- Logging error ---
Traceback (most recent call last):
  File "/usr/lib/python3.5/logging/handlers.py", line 985, in emit
    smtp.sendmail(self.fromaddr, self.toaddrs, msg)
  File "/usr/lib/python3.5/smtplib.py", line 846, in sendmail
    msg = _fix_eols(msg).encode('ascii')
UnicodeEncodeError: 'ascii' codec can't encode character '\xe9' in position 108: ordinal not in range(128)
Call stack:
  File "/tmp/x.py", line 8, in <module>
    LOG.error(u"accentu\u00E9")
Message: 'accentu?'
Arguments: ()

As discussed in msg252928 and msg252931, EmailMessage/send_message should be used instead to resolve this issue.

Patch attached.

----------
files: SMTPHandler-unicode-v1.patch
keywords: patch
messages: 253043
nosy: simon04
priority: normal
severity: normal
status: open
title: SMTPHandler in the logging module fails with unicode strings
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40787/SMTPHandler-unicode-v1.patch

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

From report at bugs.python.org  Thu Oct 15 16:09:54 2015
From: report at bugs.python.org (Sergey Shashkov)
Date: Thu, 15 Oct 2015 14:09:54 +0000
Subject: [New-bugs-announce] [issue25412] __floordiv__ in module fraction
 fails with TypeError instead of returning NotImplemented
Message-ID: <1444918194.04.0.71189202918.issue25412@psf.upfronthosting.co.za>


New submission from Sergey Shashkov:

__floordiv__ in module fraction fails with TypeError instead of returning NotImplemented when modulo is a class without __rtruediv__ or __mul__.

Code sample:

class Foo(object):
    def __rdivmod__(self, other):
        return 'rdivmod works'

from fractions import Fraction
a = Fraction(1,1)
b = Foo()
print(divmod(1, b))
print(divmod(a, b))



__divmod__ in Fraction is inherited from class Real (numbers.py):
    def __divmod__(self, other):
        return (self // other, self % other)

So __floordiv__ and __mod__ are called. 

    def __floordiv__(a, b):
        """a // b"""
        return math.floor(a / b)

    def __mod__(a, b):
        """a % b"""
        div = a // b
        return a - b * div

__floordiv__ if fractions.py makes a true division, and __mod__ makes multiplication.



The following code will fix the problem:


    def __divmod__(self, other):
        if isinstance(a, numbers.Complex):
            return (self // other, self % other)
        else:
            return NotImplemented

----------
components: Library (Lib)
messages: 253046
nosy: ShashkovS
priority: normal
severity: normal
status: open
title: __floordiv__ in module fraction fails with TypeError instead of returning NotImplemented
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/issue25412>
_______________________________________

From report at bugs.python.org  Thu Oct 15 16:33:46 2015
From: report at bugs.python.org (Cristi Fati)
Date: Thu, 15 Oct 2015 14:33:46 +0000
Subject: [New-bugs-announce] [issue25413] ctypes (libffi) fails to compile
 on Solaris X86
Message-ID: <1444919626.01.0.242398686702.issue25413@psf.upfronthosting.co.za>


New submission from Cristi Fati:

2.7.10 regression (at least compared to 2.7.3), not sure which exact version between the 2 first introduced it.

Due to addition of `win32.S` in the list build on Solaris X86 (32bit which also identifies the platform as X86) fails.

Attaching a patch. After applying it, compiles and runs on Solaris X86 and Windowses.

----------
components: ctypes
files: Python-2.7.10-ux_x86_libffi.patch
keywords: patch
messages: 253048
nosy: CristiFati
priority: normal
severity: normal
status: open
title: ctypes (libffi) fails to compile on Solaris X86
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file40788/Python-2.7.10-ux_x86_libffi.patch

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

From report at bugs.python.org  Thu Oct 15 17:36:16 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 15 Oct 2015 15:36:16 +0000
Subject: [New-bugs-announce] [issue25414] Drop unnecessary size limit test
 from deques on builds with 64-bit numbers
Message-ID: <1444923376.04.0.306426728101.issue25414@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The following test can never succeed when PY_SSIZE_T_MAX is 63-bits (as that number of allocations would exceed possible time and memory).

    #define MAX_DEQUE_LEN (PY_SSIZE_T_MAX - 3*BLOCKLEN)

    if (len >= MAX_DEQUE_LEN) {
        PyErr_SetString(PyExc_OverflowError,
                        "cannot add more blocks to the deque");
        return NULL;
    }

Removing the test saves a recurring block of code through-out the module.  The block adds register pressure, triggers an unnecessary memory access and has a predictable test-and-jump.

Conditional compilation can leave the test in for builds with size_t under 64-bits.

----------
messages: 253053
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Drop unnecessary size limit test from deques on builds with 64-bit numbers
versions: Python 3.6

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

From report at bugs.python.org  Thu Oct 15 19:58:54 2015
From: report at bugs.python.org (Gerrit Holl)
Date: Thu, 15 Oct 2015 17:58:54 +0000
Subject: [New-bugs-announce] [issue25415] I can create instances of io.IOBase
Message-ID: <1444931934.97.0.280840323098.issue25415@psf.upfronthosting.co.za>


New submission from Gerrit Holl:

According to the [documentation](https://docs.python.org/3/library/io.html#io.IOBase), `io.IOBase` has no public constructors.  Yet I can create objects from it:

$ python3.5
Python 3.5.0 (default, Sep 13 2015, 17:20:05) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-16)] on linux
Type "help", "copyright", "credits" or "license" for more information.
Python are go!
>>> import io
>>> p = io.IOBase()
>>> p.readable()
False
>>> p.closed
False
# etc...

It doesn't do much, but the documentation is not consistent with the behaviour in practice.

----------
components: Library (Lib)
messages: 253059
nosy: Gerrit.Holl
priority: normal
severity: normal
status: open
title: I can create instances of io.IOBase
versions: Python 3.5

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

From report at bugs.python.org  Thu Oct 15 20:13:07 2015
From: report at bugs.python.org (Zack Weinberg)
Date: Thu, 15 Oct 2015 18:13:07 +0000
Subject: [New-bugs-announce] [issue25416] Add encoding aliases from the
 (HTML5) Encoding Standard
Message-ID: <1444932787.73.0.313042926579.issue25416@psf.upfronthosting.co.za>


New submission from Zack Weinberg:

The codecs registry (as of 3.4) is unaware of two of the canonical encoding names from <https://encoding.spec.whatwg.org/#names-and-labels>: "windows-874" and "x-mac-cyrillic".  For interoperability's sake, please make these aliases for "cp874" and "mac_cyrillic" respectively.

(For full interop, *every* name and label in that list should be understood by str.encode(), but the canonical names are most useful.  Lack of support for iso-8859-i is already reported as https://bugs.python.org/issue18624 .  I have not tested the full set of non-canonical labels.)

----------
messages: 253061
nosy: zwol
priority: normal
severity: normal
status: open
title: Add encoding aliases from the (HTML5) Encoding Standard
type: enhancement

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

From report at bugs.python.org  Fri Oct 16 02:17:06 2015
From: report at bugs.python.org (Antony Lee)
Date: Fri, 16 Oct 2015 00:17:06 +0000
Subject: [New-bugs-announce] [issue25417] Minor typo in Path.samefile
 docstring
Message-ID: <1444954626.12.0.126658123546.issue25417@psf.upfronthosting.co.za>


New submission from Antony Lee:

The output of pydoc for Path.samefile currently reads

pathlib.Path.samefile = samefile(self, other_path)
    Return whether `other_file` is the same or not as this file.
    (as returned by os.path.samefile(file, other_file)).

It should arguably be something like

pathlib.Path.samefile = samefile(self, other_path)
    Return whether `other_path` is the same or not as this file.
    (as returned by os.path.samefile(file, other_file)).

or

pathlib.Path.samefile = samefile(self, other_path)
    Return whether `other_path` is the same or not as this file.
    (as returned by os.path.samefile(str(self), str(other_path))).

----------
components: Library (Lib)
messages: 253066
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Minor typo in Path.samefile docstring
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Oct 16 08:16:42 2015
From: report at bugs.python.org (TAKASE Arihiro)
Date: Fri, 16 Oct 2015 06:16:42 +0000
Subject: [New-bugs-announce] [issue25418] Minor markup issue in
 reference/datamodel docs
Message-ID: <1444976202.25.0.459794059719.issue25418@psf.upfronthosting.co.za>


New submission from TAKASE Arihiro:

https://docs.python.org/3/reference/datamodel.html#object.__hash__

The closing parenthesis of "isinstance(obj, collections.Hashable)" is outside the markup.

The attached patch fixes it.

----------
assignee: docs at python
components: Documentation
files: datamodel.patch
keywords: patch
messages: 253068
nosy: artakase, docs at python
priority: normal
severity: normal
status: open
title: Minor markup issue in reference/datamodel docs
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40792/datamodel.patch

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

From report at bugs.python.org  Fri Oct 16 13:16:48 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 16 Oct 2015 11:16:48 +0000
Subject: [New-bugs-announce] [issue25419] Readline completion of module
 names in import statements
Message-ID: <1444994208.15.0.362897114106.issue25419@psf.upfronthosting.co.za>


New submission from Martin Panter:

As mentioned in Issue 25209, here is a patch to complete module and attribute names in import statements. This is a rewrite of some personal code I have had kicking around for a few years, but I have added extra features (parsing ?import x as alias?, supporting ?from .relative import x?).

All the existing completions should continue to work as long as the statement immediately preceding the cursor does not look like an ?import? statement. When an import statement is detected, these other completions are disabled.

When alternative completions are displayed, my code appends a dot (.) indicator to package names, but this is not inserted in the input line. Maybe people think this is a good idea or maybe not.

This illustrates what it looks like in action. Text in square brackets was automatically completed:

Python 3.6.0a0 (qbase qtip readline/complete-import.patch tip:65d2b721034a, Oct 16 2015, 10:02:3) 
[GCC 5.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import io, h<Tab><Tab>
hashlib  heapq    hmac     html.    http.    
>>> import io, htm[l].<Tab><Tab>
html.entities  html.parser    
>>> import io, html.e[ntities]
>>> from html import e<Tab><Tab>
entities  escape    
>>> from html import es[cape]

The code works around Issue 16182 (byte vs code point indexing) in a very simplistic way. It probably won?t give useful completions (if any) for non-ASCII input involving imports.

The patch currently does not complete built-in module names (sys.builtin_module_names). This should not be hard to add, but I need to decide whether the support should be added specially in rlcompleter, or generally in pkgutil.iter_modules() instead.

I also have code to complete the following, which I could try to make patches for if there is interest:

* keyword argument names to function calls, e.g. open("file", enc[oding=]
* attributes on constructor return types, e.g. ValueError("msg").__t[raceback__]

----------
components: Library (Lib)
files: complete-import.patch
keywords: patch
messages: 253072
nosy: martin.panter, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Readline completion of module names in import statements
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file40794/complete-import.patch

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

From report at bugs.python.org  Fri Oct 16 15:49:56 2015
From: report at bugs.python.org (jan matejek)
Date: Fri, 16 Oct 2015 13:49:56 +0000
Subject: [New-bugs-announce] [issue25420] "import random" blocks on entropy
 collection
Message-ID: <1445003396.34.0.246344104115.issue25420@psf.upfronthosting.co.za>


New submission from jan matejek:

When imported, the random module creates and seeds an implicit instance, even when it is never used.

The RNG is seeded from os.urandom, which as of python 3.5 uses the potentially blocking getrandom() call.

This causes problems e.g. on our build VMs that don't have true entropy, so getrandom() blocks forever -- unlike /dev/urandom, getrandom() in kernel waits until 128 bits of true entropy are available to reseed the RNG. And as it happens, the usual setup.py will very indirectly "import random" somewhere deep in its dependencies.

I can foresee a similar issue if someone uses python early in the boot process.

A possible workaround is to monkeypatch os.urandom (in this particular case, to return a string of zeroes and remove randomness entirely to get reproducible builds)

----------
components: Library (Lib)
messages: 253073
nosy: matejcik
priority: normal
severity: normal
status: open
title: "import random" blocks on entropy collection
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Oct 16 18:42:00 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Oct 2015 16:42:00 +0000
Subject: [New-bugs-announce] [issue25421] Make __sizeof__ for builtin types
 more subclass friendly
Message-ID: <1445013720.79.0.218203938843.issue25421@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Default __sizeof__() implementation uses tp_basicsize. This makes it to work correctly with most builtin types and types with __slots__ (using __slots__ increases tp_basicsize). But special implementations of __sizeof__() use static object size ('sizeof(XXXObject)'), and return incorrect result for subclasses that increase tp_basicsize. Proposed patch makes __sizeof__() for all subclassable builtin type that support changing object size (i.e. tp_itemsize == 0) to use dynamic size _PyObject_SIZE(Py_TYPE(self)).

Example (with patched code):
>>> class D(dict):
...     __slots__ = 'a', 'b', 'c'
... 
>>> sys.getsizeof({})
144
>>> sys.getsizeof(D())
156

In unpatched Python sys.getsizeof(D()) returns 144.

----------
components: Extension Modules, Interpreter Core
files: sizeof_dynamic.patch
keywords: patch
messages: 253074
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Make __sizeof__ for builtin types more subclass friendly
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40795/sizeof_dynamic.patch

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

From report at bugs.python.org  Fri Oct 16 18:42:29 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 16 Oct 2015 16:42:29 +0000
Subject: [New-bugs-announce] [issue25422] tokenize: add test for multi-line
 strings
Message-ID: <1445013749.49.0.456758504402.issue25422@psf.upfronthosting.co.za>


New submission from Eric V. Smith:

As part of fixing issue 25311, I'm going to change how the string pattern recognition works. I want to make sure I don't break anything that currently works, but there are no tests for multi-line strings. I'll add those first, under this issue.

I'm not positive that the multi-line string behavior is correct or makes sense, but that's not the point: I just want to first add tests for the existing functionality to make sure I don't break it.

----------
assignee: eric.smith
components: Library (Lib)
messages: 253075
nosy: eric.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: tokenize: add test for multi-line strings
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Oct 16 19:31:59 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 Oct 2015 17:31:59 +0000
Subject: [New-bugs-announce] [issue25423] Deprecate benchmarks that execute
 too quickly
Message-ID: <1445016719.35.0.429724365495.issue25423@psf.upfronthosting.co.za>


New submission from Brett Cannon:

I have seen both silent_logging and unpack_sequence reliably complete so quickly in fast mode as to be measured at 0 time. That indicates to me that the benchmarks are no longer measuring something of consequence.

----------
components: Benchmarks
messages: 253078
nosy: brett.cannon, pitrou
priority: normal
severity: normal
status: open
title: Deprecate benchmarks that execute too quickly

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

From report at bugs.python.org  Fri Oct 16 19:33:18 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 Oct 2015 17:33:18 +0000
Subject: [New-bugs-announce] [issue25424] Deprecate older versions of
 benchmarks
Message-ID: <1445016798.76.0.0686859610456.issue25424@psf.upfronthosting.co.za>


New submission from Brett Cannon:

The django, json_dump, and mako benchmarks all have v2 versions and have had such versions for quite some time. Perhaps it's time to retire them?

----------
components: Benchmarks
messages: 253079
nosy: brett.cannon, pitrou
priority: normal
severity: normal
status: open
title: Deprecate older versions of benchmarks

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

From report at bugs.python.org  Fri Oct 16 20:17:19 2015
From: report at bugs.python.org (pavan kumar Dharmavarapu)
Date: Fri, 16 Oct 2015 18:17:19 +0000
Subject: [New-bugs-announce] [issue25425] white-spaces encountered in 3.4
Message-ID: <1445019439.47.0.233830038143.issue25425@psf.upfronthosting.co.za>


New submission from pavan kumar Dharmavarapu:

need to resolved some white spaces that are encountered in this problem
where it need to be resolved by writing patch

----------
components: Windows
messages: 253082
nosy: paul.moore, pavan kumar Dharmavarapu, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: white-spaces encountered in 3.4
type: performance
versions: Python 3.4

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

From report at bugs.python.org  Fri Oct 16 21:28:26 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 Oct 2015 19:28:26 +0000
Subject: [New-bugs-announce] [issue25426] Deprecate the regex_compile
 benchmark
Message-ID: <1445023706.21.0.465528553225.issue25426@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Turns out it relies on internal APIs that either don't exist on other interpreters (e.g., IronPython), or they change which leads to breakage of the benchmark (e.g., already changed for Python 3.2 and 3.3). Probably best to retire it rather than continuing to try and prop it up.

----------
components: Benchmarks
messages: 253091
nosy: brett.cannon, pitrou
priority: normal
severity: normal
status: open
title: Deprecate the regex_compile benchmark

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

From report at bugs.python.org  Sat Oct 17 00:15:46 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 Oct 2015 22:15:46 +0000
Subject: [New-bugs-announce] [issue25427] Remove the pyvenv script in Python
 3.8
Message-ID: <1445033746.77.0.533143282748.issue25427@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Title explains it all.

----------
assignee: brett.cannon
components: Demos and Tools
messages: 253103
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Remove the pyvenv script in Python 3.8

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

From report at bugs.python.org  Sat Oct 17 03:34:14 2015
From: report at bugs.python.org (leewz)
Date: Sat, 17 Oct 2015 01:34:14 +0000
Subject: [New-bugs-announce] [issue25428] Have `datetime` understand integer
 arguments for timezones
Message-ID: <1445045654.46.0.202441860249.issue25428@psf.upfronthosting.co.za>


New submission from leewz:

Current: If I want to create a datetime object with a particular timezone offset, I have to do this:
    
    import datetime
    mytime = datetime.datetime(2015, 10, 16, 9, 13, 0, tzinfo=datetime.timezone(datetime.timedelta(hours=-7)))

Or with imports:

    from datetime import datetime, timezone, timedelta
    mytime = datetime(2015, 10, 16, 9, 13, 0, tzinfo=timezone(timedelta(hours=-7)))

That's two extra imports and two extra objects created.


Requested way:
    mytime = datetime(2015, 10, 16, 9, 13, 0, tzinfo=-7)
    # mytime.tzinfo == -7

Or if someone doesn't like the `tzinfo` keyword:
    mytime = datetime(2015, 10, 16, 9, 13, 0, tzhours=-7)
    # mytime.tzinfo == timezone(timedelta(-7))


For timezones, hours are the normal unit of time. At least, I think about time zones in hours, and I don't know who would think about them in minutes. There are half-hour offsets, so floats make sense to have.

Imagine you have about a year of experience dabbling in Python, and you're trying to do a relatively simple task, like reading PDT times and converting them to local time. You would go to the datetime docs, see that you need to pass in a tzinfo object. You look that up, and run into this:
"""tzinfo is an abstract base class, meaning that this class should not be instantiated directly. You need to derive a concrete subclass, and (at least) supply implementations of the standard tzinfo methods needed by the datetime methods you use."""

Well, great. If you want to convert times, you'll have to subclass an abstract base class, and implement five methods. You'd probably have to read the whole docs for this class, too. (The docs for tzinfo take nine Page Downs for me to scroll past.)

If you're not frightened off by the first two sentences, you'll see that there's the concrete subclass `datetime.timezone`. We're two levels down, now. Going there, you'll see that you need to pass in a timedelta object. Three levels. You need to learn about three classes just to specify an hour offset.

Timezones are something that many non-programmers understand, and the rules are pretty simple (barring DST, but the library doesn't really deal with it anyway). Ideally, it should be simple to do simple things.


PS: There seems to be unnecessary inconsistency with `.astimezone`, `fromtimestamp`, and `now` taking a `tz` kwarg rather than a `tzinfo` kwarg.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 253111
nosy: docs at python, leewz
priority: normal
severity: normal
status: open
title: Have `datetime` understand integer arguments for timezones
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Oct 17 04:11:53 2015
From: report at bugs.python.org (Evan Hubinger)
Date: Sat, 17 Oct 2015 02:11:53 +0000
Subject: [New-bugs-announce] [issue25429] Can segfault Python with
 itertools.chain.from_iterable
Message-ID: <1445047913.08.0.75860781244.issue25429@psf.upfronthosting.co.za>


New submission from Evan Hubinger:

The code

import itertools
it = itertools.chain.from_iterable((f() for f in [lambda: it]))
list(it)

definitely segfaults on Python 2.6, 2.7, 3.3, and 3.4, and probably segfaults on other versions as well. The code is clearly incorrect in that the lambda references the variable being defined, but it seems like it should raise an error instead of segfaulting.

----------
messages: 253112
nosy: Evan Hubinger
priority: normal
severity: normal
status: open
title: Can segfault Python with itertools.chain.from_iterable
type: crash
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Oct 17 13:57:18 2015
From: report at bugs.python.org (=?utf-8?b?0JDQu9C10LrRgdCw0L3QtNGAINCR0LDQu9C10LfQuNC9?=)
Date: Sat, 17 Oct 2015 11:57:18 +0000
Subject: [New-bugs-announce] [issue25430] speed up ipaddress __contain__
 method
Message-ID: <1445083038.14.0.911555841878.issue25430@psf.upfronthosting.co.za>


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

Current check "address in network" is seems a bit odd:
int(self.network_address) <= int(other._ip) < int(self.broadcast_address)
This patch make this in bit-operation manner. Perfomace test:

import ipaddress
import timeit


class IPv6Network2(ipaddress.IPv6Network):
    def __contains__(self, other):
        # always false if one is v4 and the other is v6.
        if self._version != other._version:
            return False
        # dealing with another network.
        if isinstance(other, ipaddress._BaseNetwork):
            return False
        else:
            # address
            return other._ip & self.netmask._ip == self.network_address._ip

class IPv4Network2(ipaddress.IPv4Network):
    def __contains__(self, other):
        # always false if one is v4 and the other is v6.
        if self._version != other._version:
            return False
        # dealing with another network.
        if isinstance(other, ipaddress._BaseNetwork):
            return False
        # dealing with another address
        else:
            # address
            return other._ip & self.netmask._ip == self.network_address._ip

ipv6_test_net = ipaddress.IPv6Network("::/0")
ipv6_test_net2 = IPv6Network2("::/0")
ipv4_test_net = ipaddress.IPv4Network("0.0.0.0/0")
ipv4_test_net2 = IPv4Network2("0.0.0.0/0")

dataipv6 = list()
dataipv4 = list()
for x in range(2000000):
    dataipv6.append(ipaddress.IPv6Address(x))
    dataipv4.append(ipaddress.IPv4Address(x))

def test():
    for d in dataipv6:
        d in ipv6_test_net

def test2():
    for d in dataipv6:
        d in ipv6_test_net2

def test3():
    for d in dataipv4:
        d in ipv4_test_net

def test4():
    for d in dataipv4:
        d in ipv4_test_net2

t = timeit.Timer("test()", "from __main__ import test")
print("ipv6 test origin __contains__", t.timeit(number=1))

t = timeit.Timer("test2()", "from __main__ import test2")
print("ipv6 test new __contains__", t.timeit(number=1))

t = timeit.Timer("test3()", "from __main__ import test3")
print("ipv4 test origin __contains__", t.timeit(number=1))

t = timeit.Timer("test4()", "from __main__ import test4")
print("ipv4 test new __contains__", t.timeit(number=1))

Output:

ipv6 test origin __contains__ 4.265904285013676
ipv6 test new __contains__ 1.551749340025708
ipv4 test origin __contains__ 3.689626455074176
ipv4 test new __contains__ 2.0175559649942443

----------
components: Library (Lib)
files: ipaddress_contains.patch
keywords: patch
messages: 253126
nosy: ?????????.???????
priority: normal
severity: normal
status: open
title: speed up ipaddress __contain__ method
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file40801/ipaddress_contains.patch

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

From report at bugs.python.org  Sat Oct 17 15:38:12 2015
From: report at bugs.python.org (=?utf-8?b?0JDQu9C10LrRgdCw0L3QtNGAINCR0LDQu9C10LfQuNC9?=)
Date: Sat, 17 Oct 2015 13:38:12 +0000
Subject: [New-bugs-announce] [issue25431] implement address in network in
 ipaddress module
Message-ID: <1445089092.67.0.311861464579.issue25431@psf.upfronthosting.co.za>


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

Current realization of _BaseNetwork.__contains__ always returns False if other is _BaseNetwork. This patch implements proper comparison of _BaseNetwork objects.

----------
components: Library (Lib)
files: ipaddress_contains_network.patch
keywords: patch
messages: 253128
nosy: ?????????.???????
priority: normal
severity: normal
status: open
title: implement address in network in ipaddress module
versions: Python 3.5
Added file: http://bugs.python.org/file40802/ipaddress_contains_network.patch

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

From report at bugs.python.org  Sat Oct 17 16:46:04 2015
From: report at bugs.python.org (Michael Crouch)
Date: Sat, 17 Oct 2015 14:46:04 +0000
Subject: [New-bugs-announce] [issue25432] isinstance documentation doesn't
 explain what happens when type is tuple
Message-ID: <1445093164.36.0.718439234598.issue25432@psf.upfronthosting.co.za>


New submission from Michael Crouch:

In the section on isinstance() in the Python Standard Library documentation Chapter 2 (https://docs.python.org/3.6/library/functions.html#isinstance) , it says that classinfo "may be a tuple of type objects", but it doesn't explain what the semantics are in that case (e.g., that it will return true iff it is an instance of any of the types in the tuple).

----------
assignee: docs at python
components: Documentation
messages: 253130
nosy: Michael Crouch, docs at python
priority: normal
severity: normal
status: open
title: isinstance documentation doesn't explain what happens when type is tuple
versions: Python 2.7, Python 3.6

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

From report at bugs.python.org  Sun Oct 18 14:15:36 2015
From: report at bugs.python.org (Dimitri Papadopoulos Orfanos)
Date: Sun, 18 Oct 2015 12:15:36 +0000
Subject: [New-bugs-announce] [issue25433] whitespace in
 strip()/lstrip()/rstrip()
Message-ID: <1445170536.34.0.94220475409.issue25433@psf.upfronthosting.co.za>


New submission from Dimitri Papadopoulos Orfanos:

The documentation of strip() / lstrip() / rstrip() should define "whitespace" more precisely.

The Python 3 documentation refers to "ASCII whitespace" for bytes.strip() / bytes.lstrip() / bytes.rstrip() and "whitespace" for str.strip() / str.lstrip() / str.rstrip(). I suggest the following improvements:
* add a link from "ASCII whitespace" to string.whitespace or bytes.isspace(),
* define plain "whitespace" more precisely (possibly with a link to str.isspace()).

The Python 2 documentation refers to plain "whitespace". As far as I know strip() removes ASCII whitespaces only. If so, please:
* add a link to string.whitespace or str.isspace(),
* improve the string.whitespace documentation and explain that it is locale-dependent (see documentation of str.isspace()).

----------
assignee: docs at python
components: Documentation
messages: 253152
nosy: Dimitri Papadopoulos Orfanos, docs at python
priority: normal
severity: normal
status: open
title: whitespace in strip()/lstrip()/rstrip()
type: enhancement
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Sun Oct 18 19:11:13 2015
From: report at bugs.python.org (Louis Sautier)
Date: Sun, 18 Oct 2015 17:11:13 +0000
Subject: [New-bugs-announce] [issue25434] Fix typo in whatsnew/3.5
Message-ID: <1445188273.65.0.786710324106.issue25434@psf.upfronthosting.co.za>


New submission from Louis Sautier:

Hi,
I noticed a typo in the doc for What?s New In Python 3.5, here's a patch.

----------
assignee: docs at python
components: Documentation
files: fixtypo.patch
keywords: patch
messages: 253155
nosy: docs at python, omelette
priority: normal
severity: normal
status: open
title: Fix typo in whatsnew/3.5
versions: Python 3.5
Added file: http://bugs.python.org/file40811/fixtypo.patch

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

From report at bugs.python.org  Sun Oct 18 20:49:49 2015
From: report at bugs.python.org (David Becher)
Date: Sun, 18 Oct 2015 18:49:49 +0000
Subject: [New-bugs-announce] [issue25435] Wrong function calls and referring
 to not removed concepts in descriptor HowTo (documentation)
Message-ID: <1445194189.09.0.0973348556564.issue25435@psf.upfronthosting.co.za>


New submission from David Becher:

Since Python 3 removed unbound methods, I found some references using the old terminology in this HowTo about descriptors (https://docs.python.org/3/howto/descriptor.html). Also, since unbound methods have been removed, the function call types.MethodType now only takes two arguments, namely the function to bind and the object to bind to. In the current documentation, however, the old function call with three arguments is still being used.

I made a pull request on github, then I realized that it is just a mirror repo. Attached you will see a patch file with some of the obvious changes that could me made to the document

----------
assignee: docs at python
components: Documentation
files: 21.diff.txt
messages: 253159
nosy: David Becher, docs at python
priority: normal
severity: normal
status: open
title: Wrong function calls and referring to not removed concepts in descriptor HowTo (documentation)
versions: Python 3.6
Added file: http://bugs.python.org/file40812/21.diff.txt

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

From report at bugs.python.org  Sun Oct 18 21:29:45 2015
From: report at bugs.python.org (Daniel Fortunov)
Date: Sun, 18 Oct 2015 19:29:45 +0000
Subject: [New-bugs-announce] [issue25436] argparse.ArgumentError missing
 error message in __repr__
Message-ID: <1445196585.11.0.0454648926496.issue25436@psf.upfronthosting.co.za>


New submission from Daniel Fortunov:

ArgumentError's __init__() fails to call super(), meaning
that the base exception doesn?t get a message, and thus repr() always
returns ?argparse.ArgumentError()? with no message.

Not very helpful if that repr gets logged, or included in another error message :-(

I've attached a patch that fixes this, and adds corresponding tests.

----------
components: Library (Lib)
files: cpython_ArgumentError_repr.patch
keywords: patch
messages: 253160
nosy: dfortunov
priority: normal
severity: normal
status: open
title: argparse.ArgumentError missing error message in __repr__
Added file: http://bugs.python.org/file40813/cpython_ArgumentError_repr.patch

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

From report at bugs.python.org  Sun Oct 18 21:44:18 2015
From: report at bugs.python.org (Daniel Waites)
Date: Sun, 18 Oct 2015 19:44:18 +0000
Subject: [New-bugs-announce] [issue25437] Issue with ftplib.FTP_TLS and
 server forcing SSL connection reuse
Message-ID: <1445197458.2.0.693285034257.issue25437@psf.upfronthosting.co.za>


New submission from Daniel Waites:

There is an issue with the python FTPS module in the standard library which appears to be related to SSL session reuse. I noticed when I updated to a recent version of Pure-FTPd (1.0.42), python's FTPS library client stopped working and generated an error in the ssl unwrap call when a data connection is opened after prot_p() is used. Checking the change log on that version of Pure-FTPd, there is this note:

- The ONLY_ACCEPT_REUSED_SSL_SESSIONS switch (introduced in Pure-FTPd
1.0.22 circa 2009, but disabled back then due to client compatibility
concerns) is now on by default, except in broken clients compatibility mode.

Turning on the broken clients compatibility mode in pure-ftpd makes the Python client work again, so I'm surmising this is related to pure-ftpd forcing SSL session reuse. My question is, is this something the Python standard library should detect, or is it a problem lower in the stack (i.e., libssl?) Incidentally, I can reproduce this behavior on Python 2.7 as well.


Steps to reproduce:

import ftplib
ftp = ftplib.FTP_TLS(ftphost, ftpuser, ftppass)
ftp.prot_p()
ftp.retrbinary('RETR ' + cmofile, infile.write)

Traceback (most recent call last): 
File "/home/dwaites/bin/mysqlload.py", line 212, in 
main() 
File "/home/dwaites/bin/mysqlload.py", line 155, in main 
site.retrbinary('RETR ' + cmofile, infile.write) 
File "/usr/lib/python3.4/ftplib.py", line 449, in retrbinary 
conn.unwrap() 
File "/usr/lib/python3.4/ssl.py", line 788, in unwrap 
s = self._sslobj.shutdown() 
OSError: [Errno 0] Error

----------
components: Library (Lib)
messages: 253161
nosy: dwaites
priority: normal
severity: normal
status: open
title: Issue with ftplib.FTP_TLS and server forcing SSL connection reuse
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Oct 19 08:42:04 2015
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 19 Oct 2015 06:42:04 +0000
Subject: [New-bugs-announce] [issue25438] document what codec PyMemberDef
 T_STRING decodes the char * as
Message-ID: <1445236924.11.0.92849861938.issue25438@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

https://docs.python.org/3/c-api/structures.html#c.PyMemberDef

T_STRING members are turned into str objects in Python.  The documentation needs updating to mention which codec the char * bytes are treated as.

Solving this issue involves code inspection and leaving pointers to that code here in the issue, then updating the docs to mention the requirements for the char * member data as well as what happens upon assignment for non-READONLY T_STRING data (a different restriction?  or encoding to the same codec?)

My _guess_ would be UTF-8 or ASCII but I'll let someone else dive in and find out.  This is a Python 3 specific documentation clarification.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 253172
nosy: docs at python, gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: document what codec PyMemberDef T_STRING decodes the char * as
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Oct 19 11:31:23 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 19 Oct 2015 09:31:23 +0000
Subject: [New-bugs-announce] [issue25439] Add type checks to
 urllib.request.Request
Message-ID: <1445247083.91.0.927080887762.issue25439@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

Currently urllib.request.Request seems to accept invalid types silently, only to fail later on with unhelpful errors when the request is passed to urlopen.

This might cause users to go through something similar:

>>> r = Request(b'https://www.python.org')
>>> # so far, so good
>>> urlopen(r)
Traceback (most recent call last):
  ...
urllib.error.URLError: <urlopen error unknown url type: b'https>

This unhelpful error might lead users to think https is not supported, whereas the problem is that the url should have been str, not bytes.

The same problem applies to post data:

>>> r = Request('https://www.python.org', {'post': 'data'})
>>> # so far, so good
>>> urlopen(r)
Traceback (most recent call last):
  ...
TypeError: memoryview: dict object does not have the buffer interface
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  ...
ValueError: Content-Length should be specified for iterable data of type <class 'dict'> {'post': 'data'}

This error seems to indicate that Content-Length should be specified somewhere, but AFAICT from the docs, the data should be bytes or None -- so let's try to urlencode them:

>>> r = Request('https://www.python.org', urlencode({'post': 'data'}))
>>> # so far, so good
>>> urlopen(r)
Traceback (most recent call last):
  ...
TypeError: POST data should be bytes or an iterable of bytes. It cannot be of type str.

OK, maybe I should use bytes in the dict:

>>> r = Request('https://www.python.org', urlencode({b'post': b'data'}))
>>> # so far, so good
>>> urlopen(r)
Traceback (most recent call last):
  ...
TypeError: POST data should be bytes or an iterable of bytes. It cannot be of type str.

That didn't work, I also needed to encode the output of urlencode().


Most of these problems could be prevented if Request() raised for non-str URLs, and non-bytes (and non-None) POST data.  Unless there some valid reason to accept invalid types, I think they should be rejected early.

----------
components: Library (Lib)
keywords: easy
messages: 253173
nosy: ezio.melotti
priority: normal
severity: normal
stage: needs patch
status: open
title: Add type checks to urllib.request.Request
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Mon Oct 19 14:04:46 2015
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 19 Oct 2015 12:04:46 +0000
Subject: [New-bugs-announce] [issue25440] python3.4-config
 --extension-suffix not expanded
Message-ID: <1445256286.32.0.301975796809.issue25440@psf.upfronthosting.co.za>


New submission from Matthias Klose:

$ python3.4-config --extension-suffix
@SO@

this is fallout from issue #16754. Use EXT_SUFFIX directly in the shell script, which then gets expanded by configure.

----------
messages: 253177
nosy: doko
priority: normal
severity: normal
status: open
title: python3.4-config --extension-suffix not expanded
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Oct 19 16:12:10 2015
From: report at bugs.python.org (Sebastien Bourdeauducq)
Date: Mon, 19 Oct 2015 14:12:10 +0000
Subject: [New-bugs-announce] [issue25441] StreamWriter.drain() unreliably
 reports closed sockets
Message-ID: <1445263930.02.0.0288344927045.issue25441@psf.upfronthosting.co.za>


New submission from Sebastien Bourdeauducq:

1. Open a listening socket:
$ nc6 -l -p 1066

2. Run the following (tested here on Linux):
import asyncio

async def bug():
    reader, writer = await asyncio.open_connection("::1", "1066")
    while True:
        writer.write("foo\n".encode())
        await writer.drain()
        # Uncommenting this makes drain() raise BrokenPipeError
        # when the server closes the connection.
        #await asyncio.sleep(0.1)

loop = asyncio.get_event_loop()
loop.run_until_complete(bug())

3. Terminate netcat with Ctrl-C. The program will go on a endless loop of "socket.send() raised exception." as writer.drain() fails to raise an exception to report the closed connection. Reducing the output rate of the program by using asyncio.sleep causes writer.drain() to raise BrokenPipeError (and shouldn't it be ConnectionResetError?)

----------
components: asyncio
messages: 253181
nosy: gvanrossum, haypo, sebastien.bourdeauducq, yselivanov
priority: normal
severity: normal
status: open
title: StreamWriter.drain() unreliably reports closed sockets
versions: Python 3.5

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

From report at bugs.python.org  Mon Oct 19 21:52:28 2015
From: report at bugs.python.org (Yanyan Jiang)
Date: Mon, 19 Oct 2015 19:52:28 +0000
Subject: [New-bugs-announce] [issue25442] Shelve consistency issues
Message-ID: <1445284348.45.0.829357698435.issue25442@psf.upfronthosting.co.za>


New submission from Yanyan Jiang:

I am currently working on the file system reliability issues. I have a disk driver that is able to simulate crash disk sites after injected power failures. This disk is totally compatible with the Linux block driver semantics (refer to  https://www.kernel.org/doc/Documentation/block/writeback_cache_control.txt), and may create many crash sites that pending blocks are partially flushed into the disk which is a common behavior of a commodity disk with write buffer.

Our automated tool confirms the corruptions could happen on a crash site at an unclean shutdown (Linux with default ext4 setting). We also found that there are some discussions on [Stackoverflow](http://stackoverflow.com/questions/4226580/prevent-python-shelve-corruption) concerning this issue. I am suggesting to explicitly remind the developers of such behaviors.

Suggested documentation enhancement
--------------------------------------
As a minimal database library, `shelve` does not offer as strong ACID (atomicity, consistency, isolation and durability) guarantee as a database (like SQLite). On certain system configurations, a system crash would lead to a corrupted shelve file. If you are using shelve to persistent precious data like user's document, we suggest using the following steps to ensure data is not lost:

1. Create a copy of the file, say, the temporary.
2. Operate on a copy of the temporary file. Closing a shelve db implies data to be flushed to the disk.
3. Rename the temporary file to replace the original file. Renaming is carefully treated by a journaled filesystem to be atomic.

----------
assignee: docs at python
components: Documentation
messages: 253188
nosy: Yanyan Jiang, docs at python
priority: normal
severity: normal
status: open
title: Shelve consistency issues
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/issue25442>
_______________________________________

From report at bugs.python.org  Tue Oct 20 00:14:55 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 19 Oct 2015 22:14:55 +0000
Subject: [New-bugs-announce] [issue25443] Add a count of how many benchmarks
 are left to run
Message-ID: <1445292895.24.0.0847947042448.issue25443@psf.upfronthosting.co.za>


New submission from Brett Cannon:

It would be nice to know when doing a long benchmark run -- i.e., running in rigorous mode with a lot of benchmarks -- how many benchmarks are left, much like how you know how many tests are left when running under regrtest.

----------
assignee: brett.cannon
components: Benchmarks
messages: 253199
nosy: brett.cannon, pitrou
priority: normal
severity: normal
status: open
title: Add a count of how many benchmarks are left to run

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

From report at bugs.python.org  Tue Oct 20 06:31:28 2015
From: report at bugs.python.org (Nils Lindemann)
Date: Tue, 20 Oct 2015 04:31:28 +0000
Subject: [New-bugs-announce] [issue25444] Py Launch Icon
Message-ID: <1445315488.63.0.0387362218843.issue25444@psf.upfronthosting.co.za>


New submission from Nils Lindemann:

Hi,

See attached screen for a list of alternative 16x16 icon suggestions to the current launcher symbol, which i dont like (Dudes, rockets are used in wars!). I copied them a few times to show how they look in groups. (while i was at it i also created an icon for idle, see the idle window in the Screenshot).

Actually i wonder why it is necessary at all to use more than the three default icons, but if, then my icons are better. Hopefully i can inspire the designer to do a redesign of the luncher icon :-)

Nils

----------
components: IDLE, Installation, Windows
files: (py icons, idle) screenshot.png
messages: 253203
nosy: Nils-Hero, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Py Launch Icon
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40815/(py icons, idle) screenshot.png

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

From report at bugs.python.org  Tue Oct 20 08:15:29 2015
From: report at bugs.python.org (Reema)
Date: Tue, 20 Oct 2015 06:15:29 +0000
Subject: [New-bugs-announce] [issue25445] type xterm in python
Message-ID: <1445321729.67.0.92223592464.issue25445@psf.upfronthosting.co.za>


New submission from Reema:

python xterm give output /usr/bin/xterm when used in unix shell script.
Need to get same output in python for:
type xterm
similarly for type textedit

When trying to do it with subprocess.Popen, i am getting an error:
type object 'type' has no attribute 'rfind'
or xterm not defined.
Kindly help urgently

----------
messages: 253207
nosy: reema
priority: normal
severity: normal
status: open
title: type xterm in python
versions: Python 2.7

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

From report at bugs.python.org  Tue Oct 20 17:41:32 2015
From: report at bugs.python.org (Oliver Merkel)
Date: Tue, 20 Oct 2015 15:41:32 +0000
Subject: [New-bugs-announce] [issue25446] smtplib.py AUTH LOGIN code messed
 up sending login and password data since 3.5
Message-ID: <1445355692.4.0.944252984253.issue25446@psf.upfronthosting.co.za>


New submission from Oliver Merkel:

class SMTP:
    def auth_login(self, challenge=None):

The self.docmd should use cmd "AUTH" with parameter "LOGIN" + encoded login like

        (code, resp) = self.docmd("AUTH", "LOGIN " +
            encode_base64(self.user.encode('ascii'), eol=''))

with

    def auth(self, mechanism, authobject, *, initial_response_ok=True):

that should not send a "AUTH" in self.docmd in case the mechanism is 'LOGIN' and

        if initial_response is not None:

meaning

            if mechanism == 'LOGIN':
                (code, resp) = self.docmd(response)
            else:
                (code, resp) = self.docmd("AUTH", mechanism + " " + response)

---

Could someone kindly review, evtly come up with better suggestion?

In short:
$ diff /c/Python35/Lib/smtplib-old.py /c/Python35/Lib/smtplib.py
630c630,633
<             (code, resp) = self.docmd("AUTH", mechanism + " " + response)
---
>             if mechanism == 'LOGIN':
>                 (code, resp) = self.docmd(response)
>             else:
>                 (code, resp) = self.docmd("AUTH", mechanism + " " + response)
660c663
<         (code, resp) = self.docmd(
---
>         (code, resp) = self.docmd("AUTH", "LOGIN " +

----------
components: email
messages: 253225
nosy: barry, merkel, r.david.murray
priority: normal
severity: normal
status: open
title: smtplib.py AUTH LOGIN code messed up sending login and password data since 3.5
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Oct 20 18:32:09 2015
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 20 Oct 2015 16:32:09 +0000
Subject: [New-bugs-announce] [issue25447] TypeError invoking deepcopy on
 lru_cache
Message-ID: <1445358729.12.0.473819832569.issue25447@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

Beginning with Python 3.5, an lru_cache no longer survives a deepcopy.

```
$ cat >> cache_copy.py
import copy
from functools import lru_cache
foo = lru_cache()(lambda: None)
copy.deepcopy(foo)
$ python3.5 cache_copy.py
Traceback (most recent call last):
  File "cache_copy.py", line 4, in <module>
    copy.deepcopy(foo)
  File "/usr/lib/python3.5/copy.py", line 182, in deepcopy
    y = _reconstruct(x, rv, 1, memo)
  File "/usr/lib/python3.5/copy.py", line 293, in _reconstruct
    y = callable(*args)
  File "/usr/lib/python3.5/copyreg.py", line 88, in __newobj__
    return cls.__new__(cls, *args)
TypeError: Required argument 'user_function' (pos 1) not found
```

I suspect this is due to the C implementation per issue14373.

I realize one's first reaction might be "why are you deep copying a function," so here's the [downstream bug](https://bitbucket.org/jaraco/jaraco.functools/issues/1/method_cache-causes-typeerror-when) and [offended code](https://bitbucket.org/jaraco/jaraco.functools/src/68d1fda21af7e7b4c36577f953f382270bdc1e05/jaraco/functools.py?at=default&fileviewer=file-view-default#functools.py-72:138). That decorator is designed to wrap a method and to store the cache on the instance object, an object which is liable to be deep copied. As a result, production code using this technique is failing on Python 3.5.

Although it was apparently an artifact of previous implementations that the cache happened to be deep-copyable, I hope this expectation can be restored with minimal fuss.

----------
assignee: rhettinger
components: Library (Lib)
keywords: 3.5regression
messages: 253233
nosy: jason.coombs, rhettinger
priority: high
severity: normal
status: open
title: TypeError invoking deepcopy on lru_cache
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Oct 20 21:32:31 2015
From: report at bugs.python.org (Medardo Rodriguez)
Date: Tue, 20 Oct 2015 19:32:31 +0000
Subject: [New-bugs-announce] [issue25448] Exception ABC doesn't work in
 Python 3 (but does in Python 2.7)
Message-ID: <1445369551.19.0.243396138359.issue25448@psf.upfronthosting.co.za>


New submission from Medardo Rodriguez:

When I run the next code in all my installed versions of Python 3 (and the equivalent code for PyPy and CPython 2.7):

- Runs OK in CPython 2.7 equivalent code (using `ABCMeta` as meta-class).

- Fails in PyPy and all versions of Python 3.

----------
files: tests.py
messages: 253246
nosy: merchise
priority: normal
severity: normal
status: open
title: Exception ABC doesn't work in Python 3 (but does in Python 2.7)
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file40823/tests.py

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

From report at bugs.python.org  Tue Oct 20 23:12:18 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 20 Oct 2015 21:12:18 +0000
Subject: [New-bugs-announce] [issue25449] Test OrderedDict subclass
Message-ID: <1445375538.53.0.781433530973.issue25449@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

C implementation of OrderedDict often has two paths. One for exact OrderedDict and other for subclasses. But only one of the paths is tested.
Proposed patch adds tests for a subclass of C implemented OrderedDict.

test_issue24347 is failed with OrderedDict subclass. Either there is a bug in OrderedDict implementation, or the test should be more lenient.

----------
components: Extension Modules, Tests
files: odict_subclass_test.patch
keywords: patch
messages: 253254
nosy: eric.smith, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Test OrderedDict subclass
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40827/odict_subclass_test.patch

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

From report at bugs.python.org  Tue Oct 20 23:31:56 2015
From: report at bugs.python.org (Maja Tomic)
Date: Tue, 20 Oct 2015 21:31:56 +0000
Subject: [New-bugs-announce] [issue25450] Save path automatically choses
 C:\Windows\system32
Message-ID: <1445376716.84.0.123418793499.issue25450@psf.upfronthosting.co.za>


New submission from Maja Tomic:

I'm teaching kids to code in Python. Today we had two boys, one with Windows 8, the other one with Windows 10. In both cases Python 3.5 was installed and the automatic path where files are saved was C:\Windows\system32. This wasn't possible, since it cannot be written to. Yet, the boys tried to save files to it. 

In the Windows 8-case the file did not get saved. Yet, IDLE still refered to the file as having an error (it couldn't find the turtle package because the file was called turtle.py - we got that right eventually). Even after reinstalling Python it still refered to the non-existing file and the error in it. 
We changed the path and it solved the problem. Hope this can be fixed.

----------
components: Installation
messages: 253257
nosy: Maja Tomic
priority: normal
severity: normal
status: open
title: Save path automatically choses C:\Windows\system32
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Oct 21 10:56:35 2015
From: report at bugs.python.org (None Becoming)
Date: Wed, 21 Oct 2015 08:56:35 +0000
Subject: [New-bugs-announce] [issue25451] PhotoImage transparency methods
Message-ID: <1445417795.5.0.279905447074.issue25451@psf.upfronthosting.co.za>


New submission from None Becoming:

The transparency methods of tkinter.PhotoImage seem to be missing.
Presumably, they would go something like:

def transparency_get(self, x, y):
    """Returns a boolean indicating if the pixel at (x,y) is transparent. """
    
    return self.tk.call(self.name, 'transparency', 'get', x, y)

def transparency_set(self, x, y, boolean=True):
    """Make pixel at (x,y) transparent if boolean is true, opaque otherwise. """
    
    self.tk.call(self.name, 'transparency', 'set', x, y, boolean)

----------
components: Tkinter
messages: 253281
nosy: None Becoming
priority: normal
severity: normal
status: open
title: PhotoImage transparency methods
type: enhancement

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

From report at bugs.python.org  Wed Oct 21 12:50:58 2015
From: report at bugs.python.org (Richard Neumann)
Date: Wed, 21 Oct 2015 10:50:58 +0000
Subject: [New-bugs-announce] [issue25452] Add __bool__() method to
 subprocess.CompletedProcess
Message-ID: <1445424658.54.0.134413313052.issue25452@psf.upfronthosting.co.za>


New submission from Richard Neumann:

The class subprocess.CompletedProcess is currently lacking a __bool__() method.

It might be a practical feature to have the possibility to evaluate a CompletedProcess instance in an if/else block without the necessity to handle the exception raised by CompletedProcess.check_returncode().

Hence, I suggest adding the method

def __bool__(self):
    return self.returncode == 0

to the class.

----------
components: Library (Lib)
messages: 253282
nosy: conqp
priority: normal
severity: normal
status: open
title: Add __bool__() method to subprocess.CompletedProcess
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Oct 21 14:20:43 2015
From: report at bugs.python.org (Francesco Biscani)
Date: Wed, 21 Oct 2015 12:20:43 +0000
Subject: [New-bugs-announce] [issue25453] Arithmetics with complex
 infinities is inconsistent with C/C++
Message-ID: <1445430043.57.0.625714416149.issue25453@psf.upfronthosting.co.za>


New submission from Francesco Biscani:

The C++11/C99 standards define a complex infinity as a complex number in which at least one of the components is inf. Consider the Python snippet:

>>> complex(float('inf'),float('nan'))*2
(nan+nanj)

This happens because complex multiplication in Python is implemented in the most straightforward way, but the presence of a nan component "infects" both components of the result and leads to a complex nan result. See also how complex multiplication is implemented in Annex G.5.1.6 of the C99 standard.

It feels wrong that a complex infinity multiplied by a real number results in a complex nan. By comparison, the result given here by C/C++ is inf+nan*j.

Note also this:

>>> complex(float('inf'),float('nan'))+2          
(inf+nanj)

That is, addition has a different behaviour because it does not require mixing up the components of the operands.

This behaviour has unexpected consequences when one interacts with math libraries implemented in C/C++ and accessed via Python through some wrapping tool. For instance, whereas 1./(inf+nan*j) is zero in C/C++, it becomes in Python

>>> 1./complex(float('inf'),float('nan'))  
(nan+nanj)

----------
messages: 253283
nosy: Francesco Biscani
priority: normal
severity: normal
status: open
title: Arithmetics with complex infinities is inconsistent with C/C++
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Wed Oct 21 20:53:39 2015
From: report at bugs.python.org (Evgeny Kapun)
Date: Wed, 21 Oct 2015 18:53:39 +0000
Subject: [New-bugs-announce] [issue25454] operator.methodcaller should
 accept additional arguments during the call
Message-ID: <1445453619.22.0.222588930326.issue25454@psf.upfronthosting.co.za>


New submission from Evgeny Kapun:

Currently, operator.methodcaller behaves like this:

    def methodcaller(name, *args, **kwargs):
        def caller(obj):
            return getattr(obj, name)(*args, **kwargs)
        return caller

That is, it is possible to supply arguments when the object is created but not during the call. I think that it will be more useful if it behaved like this:

    def methodcaller(name, *args, **kwargs):
        def caller(obj, *args2, **kwargs2):
            return getattr(obj, name)(*args, *args2, **kwargs, **kwargs2)
        return caller

----------
components: Extension Modules
messages: 253307
nosy: abacabadabacaba
priority: normal
severity: normal
status: open
title: operator.methodcaller should accept additional arguments during the call
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Oct 21 21:17:18 2015
From: report at bugs.python.org (Evgeny Kapun)
Date: Wed, 21 Oct 2015 19:17:18 +0000
Subject: [New-bugs-announce] [issue25455] Some repr implementations don't
 check for self-referential structures
Message-ID: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za>


New submission from Evgeny Kapun:

Implementations of repr for some of the types in the standard library doesn't check for self-referential structures. As a result, when calling repr() on such objects, Python crashes due to infinite recursion.

Example:
>>> import functools
>>> x = functools.partial(min)
>>> x.__setstate__((x, (), {}, {}))
>>> repr(x)
Segmentation fault

Another example:
>>> import xml.etree.ElementTree
>>> x = xml.etree.ElementTree.Element('')
>>> x.tag = x
>>> repr(x)
Segmentation fault

One more example:
>>> import io
>>> class X(io.TextIOWrapper): __slots__ = 'name'
>>> x = X(open('/dev/null'))
>>> x.name = x
>>> repr(x)
Segmentation fault

----------
components: Extension Modules
messages: 253309
nosy: abacabadabacaba
priority: normal
severity: normal
status: open
title: Some repr implementations don't check for self-referential structures
type: crash
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Oct 22 09:09:50 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 22 Oct 2015 07:09:50 +0000
Subject: [New-bugs-announce] [issue25456] 3.4 _tkinter build fails,
 Windows 10, no tcl.h
Message-ID: <1445497790.14.0.147176888356.issue25456@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Hg started crashing trying to update my 3.4 shared repository on Windows 10, so I deleted, rebuilt, and updated.  Ran get_externals.bat, then pcbuild.sln.  The one failure is _tkinter, which means no tkinter, no IDLE.

12>..\Modules\_tkinter.c(55): fatal error C1083: Cannot open include file: 'tcl.h': No such file or directory

tcl.h is in externals/tcl-8.6.1.0/generic and it opens in Notepad.  I believe (but cannot be sure) I last recompiled _tkinter just 9 days ago, before upgrading from Win7 to Win10.

----------
components: Build, Tkinter, Windows
messages: 253318
nosy: paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: 3.4 _tkinter build fails, Windows 10, no tcl.h
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Oct 22 10:01:01 2015
From: report at bugs.python.org (Christian Tanzer)
Date: Thu, 22 Oct 2015 08:01:01 +0000
Subject: [New-bugs-announce] [issue25457] json dump fails for mixed-type
 keys when sort_keys is specified
Message-ID: <1445500861.68.0.856599723102.issue25457@psf.upfronthosting.co.za>


New submission from Christian Tanzer:

In Python 3, trying to json-dump a dict with keys of different types fails with a TypeError when sort_keys is specified:

python2.7
===========

Python 2.7.10 (default, May 29 2015, 10:02:30) 
[GCC 4.8.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import json
>>> json.dumps({1 : 42, "foo" : "bar", None : "nada"}, sort_keys = True)
'{"null": "nada", "1": 42, "foo": "bar"}'

python3.5
============

Python 3.5.0 (default, Oct  5 2015, 12:03:13) 
[GCC 4.8.5] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import json
>>> json.dumps({1 : 42, "foo" : "bar", None : "nada"}, sort_keys = True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.5/json/__init__.py", line 237, in dumps
    **kw).encode(obj)
  File "/usr/lib64/python3.5/json/encoder.py", line 199, in encode
    chunks = self.iterencode(o, _one_shot=True)
  File "/usr/lib64/python3.5/json/encoder.py", line 257, in iterencode
    return _iterencode(o, 0)
TypeError: unorderable types: str() < int()

Note that the documentation explicitly allows keys of different, if basic, types:

  If skipkeys is True (default: False), then dict keys that are not of a basic type (str, int, float, bool, None) will be skipped instead of raising a TypeError.

As all they keys are dumped as strings, a simple solution would be to sort after converting to strings. Looking closely at the output of Python 2, the sort order is a bit strange!

----------
components: Library (Lib)
messages: 253324
nosy: tanzer at swing.co.at
priority: normal
severity: normal
status: open
title: json dump fails for mixed-type keys when sort_keys is specified
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Thu Oct 22 12:35:52 2015
From: report at bugs.python.org (Peter Pan)
Date: Thu, 22 Oct 2015 10:35:52 +0000
Subject: [New-bugs-announce] [issue25458] ftplib: command response shift -
 mismatch
Message-ID: <1445510152.74.0.829316001802.issue25458@psf.upfronthosting.co.za>


New submission from Peter Pan:

When handling the transfer socket manually the asynchronous status message "226 transfer complete" on the control socket is falsely taken as response for the last sent command.
ftplib reads the response too late and the command/response order becomes invalid.

I can avoid that by using the undocumented ftplib internal method FTP.getline() after the transfer socket is closed and not sending more commands while the transfer socket is open.

It would be useful, if ftplib empties the response socket buffer before sending the next command. But maybe the best solution is an optional function callback when the "226" response appears, while it is ignored when not matching the last sent command.

Example code that triggers the problem:

import ftplib
import socket
import re


ftp = ftplib.FTP()
ftp.set_debuglevel(1)
ftp.connect('ftp.debian.org', timeout=10)
ftp.login('anonymous','user at example.com')
ftp.sendcmd('TYPE A')

s = ftp.transfercmd('LIST')

'''
#manual transfer socket - should result in same behaviour
r = ftp.sendcmd('EPSV')
r = re.search('\|([0-9]+)\|', r)
port = int( r.group(1) )
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('ftp.debian.org', port))
ftp.sendcmd('LIST')
'''

fp = s.makefile('r')
fp.read()
fp.close()
s.close()

#ftplib falsely sees "226 transfer complete" as response to next command
ftp.sendcmd('NOOP')

----------
components: Library (Lib)
messages: 253326
nosy: peterpan
priority: normal
severity: normal
status: open
title: ftplib: command response shift - mismatch
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Oct 22 15:59:55 2015
From: report at bugs.python.org (Henrique Andrade)
Date: Thu, 22 Oct 2015 13:59:55 +0000
Subject: [New-bugs-announce] [issue25459] EAGAIN errors in Python logging
 module
Message-ID: <1445522395.9.0.458727890682.issue25459@psf.upfronthosting.co.za>


New submission from Henrique Andrade:

There is a particular bug we hit when using the Python logging module very consistently under the particular settings in which we run one of our applications.

We are using Python 2.7.10 on RHEL7/RHEL6/Ubuntu14.04.

Anyways, here is the symptom:

Traceback (most recent call last):
  File "/opt/continuum/anaconda/lib/python2.7/logging/__init__.py", line 880, in emit
    stream.write(fs % msg)
IOError: [Errno 11] Resource temporarily unavailable

Here is the suggested fix:

26c26
< import sys, os, time, cStringIO, traceback, warnings, weakref, collections, errno
---
> import sys, os, time, cStringIO, traceback, warnings, weakref, collections
880,886c880
<                         while True:
< 			    try:
<                                 stream.write(fs % msg)
< 				break
<                             except IOError as e:
<                                 if e.errno != errno.EAGAIN:
< 				   raise
---
>                         stream.write(fs % msg)

----------
components: Extension Modules
messages: 253329
nosy: henrique_andrade
priority: normal
severity: normal
status: open
title: EAGAIN errors in Python logging module
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct 22 17:13:55 2015
From: report at bugs.python.org (Phil Weir)
Date: Thu, 22 Oct 2015 15:13:55 +0000
Subject: [New-bugs-announce] [issue25460] Misc/.gdbinit uses preprocessor
 macro
Message-ID: <1445526835.22.0.109540938613.issue25460@psf.upfronthosting.co.za>


New submission from Phil Weir:

When using the sample .gdbinit, use of the _PyUnicode_AsString macro gives "No symbol "_PyUnicode_AsString" in current context." from GDB.

This was first noticed when using downstream (Ubuntu) CPython 3.4/3.5 with debug symbols, and was reproduced by building current HEAD without optimization (to ensure co object not optimized out) 'CFLAGS="-g -O0" ./configure --with-pydebug && make -j2', based on instructions here [1].

This is fixable by switching _PyUnicode_AtString to PyUnicode_AsUTF8, the target of the macro in './Include/unicodeobject.h' (see attached patch)

1 - https://docs.python.org/devguide/setup.html#unix

====

TEST FILE (loop.py)
=========
import time

time.sleep(100)


GDB OUTPUT WITHOUT PATCH
========================

> gdb -args /usr/local/bin/python3.6dm loop.py

GNU gdb (GDB) 7.9.50.20150218-cvs
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/python3.6dm...done.
(gdb) r
Starting program: /usr/local/bin/python3.6dm loop.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
^C
Program received signal SIGINT, Interrupt.
0x00007ffff71df723 in select () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007ffff71df723 in select () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x000000000065f9eb in pysleep (secs=100000000000) at ./Modules/timemodule.c:1408
#2  0x000000000065d9a1 in time_sleep (self=0x7ffff6d318d8, obj=0x9ce7f0 <small_ints+5040>) at ./Modules/timemodule.c:231
#3  0x00000000005d8c96 in call_function (pp_stack=0x7fffffffbde0, oparg=1) at Python/ceval.c:4636
#4  0x00000000005d0a59 in PyEval_EvalFrameEx (f=0xa82198, throwflag=0) at Python/ceval.c:3181
#5  0x00000000005d6154 in _PyEval_EvalCodeWithName (_co=0x7ffff7e1c280, globals=0x7ffff7f1de58, locals=0x7ffff7f1de58, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0,
    name=0x0, qualname=0x0) at Python/ceval.c:3962
#6  0x00000000005d629d in PyEval_EvalCodeEx (_co=0x7ffff7e1c280, globals=0x7ffff7f1de58, locals=0x7ffff7f1de58, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0)
    at Python/ceval.c:3983
#7  0x00000000005c05aa in PyEval_EvalCode (co=0x7ffff7e1c280, globals=0x7ffff7f1de58, locals=0x7ffff7f1de58) at Python/ceval.c:777
#8  0x0000000000428790 in run_mod (mod=0xac0968, filename=0x7ffff6dd7c08, globals=0x7ffff7f1de58, locals=0x7ffff7f1de58, flags=0x7fffffffd690, arena=0xade380) at Python/pythonrun.c:970
#9  0x00000000004284c3 in PyRun_FileExFlags (fp=0xab8210, filename_str=0x7ffff7f0bd80 "loop.py", start=257, globals=0x7ffff7f1de58, locals=0x7ffff7f1de58, closeit=1, flags=0x7fffffffd690)
    at Python/pythonrun.c:923
#10 0x00000000004263c1 in PyRun_SimpleFileExFlags (fp=0xab8210, filename=0x7ffff7f0bd80 "loop.py", closeit=1, flags=0x7fffffffd690) at Python/pythonrun.c:396
#11 0x0000000000425127 in PyRun_AnyFileExFlags (fp=0xab8210, filename=0x7ffff7f0bd80 "loop.py", closeit=1, flags=0x7fffffffd690) at Python/pythonrun.c:80
#12 0x0000000000441b4b in run_file (fp=0xab8210, filename=0x9ee270 L"loop.py", p_cf=0x7fffffffd690) at Modules/main.c:318
#13 0x0000000000442aeb in Py_Main (argc=2, argv=0x9ec020) at Modules/main.c:768
#14 0x000000000041c26f in main (argc=2, argv=0x7fffffffd948) at ./Programs/python.c:69
(gdb) f 4
#4  0x00000000005d0a59 in PyEval_EvalFrameEx (f=0xa82198, throwflag=0) at Python/ceval.c:3181
3181                res = call_function(&sp, oparg);
(gdb) pystack
No symbol "_PyUnicode_AsString" in current context.
(gdb)


GDB OUTPUT WITH PATCH
=====================

> gdb -args /usr/local/bin/python3.6dm loop.py 


GNU gdb (GDB) 7.9.50.20150218-cvs
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/python3.6dm...done.
(gdb) r
Starting program: /usr/local/bin/python3.6dm loop.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
^C
Program received signal SIGINT, Interrupt.
0x00007ffff71df723 in select () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007ffff71df723 in select () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x000000000065f9eb in pysleep (secs=100000000000) at ./Modules/timemodule.c:1408
#2  0x000000000065d9a1 in time_sleep (self=0x7ffff6d318d8, obj=0x9ce7f0 <small_ints+5040>) at ./Modules/timemodule.c:231
#3  0x00000000005d8c96 in call_function (pp_stack=0x7fffffffbde0, oparg=1) at Python/ceval.c:4636
#4  0x00000000005d0a59 in PyEval_EvalFrameEx (f=0xa82198, throwflag=0) at Python/ceval.c:3181
#5  0x00000000005d6154 in _PyEval_EvalCodeWithName (_co=0x7ffff7e1c280, globals=0x7ffff7f1de58, locals=0x7ffff7f1de58, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0,
    name=0x0, qualname=0x0) at Python/ceval.c:3962
#6  0x00000000005d629d in PyEval_EvalCodeEx (_co=0x7ffff7e1c280, globals=0x7ffff7f1de58, locals=0x7ffff7f1de58, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0)
    at Python/ceval.c:3983
#7  0x00000000005c05aa in PyEval_EvalCode (co=0x7ffff7e1c280, globals=0x7ffff7f1de58, locals=0x7ffff7f1de58) at Python/ceval.c:777
#8  0x0000000000428790 in run_mod (mod=0xac0928, filename=0x7ffff6dd7c08, globals=0x7ffff7f1de58, locals=0x7ffff7f1de58, flags=0x7fffffffd690, arena=0xab9470) at Python/pythonrun.c:970
#9  0x00000000004284c3 in PyRun_FileExFlags (fp=0xab81d0, filename_str=0x7ffff7f0bd80 "loop.py", start=257, globals=0x7ffff7f1de58, locals=0x7ffff7f1de58, closeit=1, flags=0x7fffffffd690)
    at Python/pythonrun.c:923
#10 0x00000000004263c1 in PyRun_SimpleFileExFlags (fp=0xab81d0, filename=0x7ffff7f0bd80 "loop.py", closeit=1, flags=0x7fffffffd690) at Python/pythonrun.c:396
#11 0x0000000000425127 in PyRun_AnyFileExFlags (fp=0xab81d0, filename=0x7ffff7f0bd80 "loop.py", closeit=1, flags=0x7fffffffd690) at Python/pythonrun.c:80
#12 0x0000000000441b4b in run_file (fp=0xab81d0, filename=0x9ee270 L"loop.py", p_cf=0x7fffffffd690) at Modules/main.c:318
#13 0x0000000000442aeb in Py_Main (argc=2, argv=0x9ec020) at Modules/main.c:768
#14 0x000000000041c26f in main (argc=2, argv=0x7fffffffd948) at ./Programs/python.c:69
(gdb) f 4
#4  0x00000000005d0a59 in PyEval_EvalFrameEx (f=0xa82198, throwflag=0) at Python/ceval.c:3181
3181                res = call_function(&sp, oparg);
(gdb) pystack
loop.py (3): <module>
loop.py (3): <module>
(gdb)

----------
components: Demos and Tools
files: gdbinit-PyUnicode_AsUTF8.patch
keywords: patch
messages: 253333
nosy: philtweir
priority: normal
severity: normal
status: open
title: Misc/.gdbinit uses preprocessor macro
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40835/gdbinit-PyUnicode_AsUTF8.patch

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

From report at bugs.python.org  Thu Oct 22 19:05:38 2015
From: report at bugs.python.org (=?utf-8?q?Bernt_R=C3=B8skar_Brenna?=)
Date: Thu, 22 Oct 2015 17:05:38 +0000
Subject: [New-bugs-announce] [issue25461] Unclear language (the word
 ineffective) in the documentation for os.walk
Message-ID: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za>


New submission from Bernt R?skar Brenna:

At least for me (non-english speaker), the following is confusing:

"Modifying dirnames when topdown is False is ineffective, because in bottom-up mode the directories in dirnames are generated before dirpath itself is generated."

I suggest to replace "is ineffective" with "has no effect".

Ineffective could also mean: "Has low performance", could it not?

----------
assignee: docs at python
components: Documentation
messages: 253338
nosy: Bernt.R?skar.Brenna, docs at python
priority: normal
severity: normal
status: open
title: Unclear language (the word ineffective) in the documentation for os.walk
type: enhancement
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Sat Oct 24 23:09:33 2015
From: report at bugs.python.org (Matt Chaput)
Date: Sun, 25 Oct 2015 03:09:33 +0000
Subject: [New-bugs-announce] [issue25472] Typing: Specialized subclasses of
 generics cannot be unpickled
Message-ID: <1445742573.23.0.0225018159767.issue25472@psf.upfronthosting.co.za>


New submission from Matt Chaput:

If I try to pickle and unpickle an object of a class that has specialized a generic superclass, when I try to unpickle I get this error:

TypeError: descriptor '__dict__' for 'A' objects doesn't apply to 'B' object

Test case:

from typing import Generic, TypeVar
import pickle

T = TypeVar("T")


class A(Generic[T]):
    def __init__(self, x: T):
        self.x = x


class B(A[str]):
    def __init__(self, x: str):
        self.x = x


b = B("hello")
z = pickle.dumps(b)
print(z)
_ = pickle.loads(z)

----------
messages: 253421
nosy: maatt
priority: normal
severity: normal
status: open
title: Typing: Specialized subclasses of generics cannot be unpickled
versions: Python 3.5

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

From report at bugs.python.org  Fri Oct 23 13:23:23 2015
From: report at bugs.python.org (Tony R.)
Date: Fri, 23 Oct 2015 17:23:23 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue25467=5D_Put_=E2=80=9Cdepre?=
 =?utf-8?q?cated=E2=80=9D_warnings_first?=
Message-ID: <1445621003.26.0.876373693451.issue25467@psf.upfronthosting.co.za>


New submission from Tony R.:

Python has wonderful, detailed documentation.  I love it!

Unfortunately, I have often found myself reading the otherwise-excellent documentation on a class/function/whatever, only to find out at the END of my reading that it is deprecated.

This is frustrating, and counter-intuitive.  If something is deprecated, I want to know it before I read any further.  

I have attached a patch with the relevant changes.  I hope it helps!

----------
assignee: docs at python
components: Documentation
files: 0001-Move-deprecated-blocks-to-the-beginning-of-their-doc.patch
keywords: patch
messages: 253391
nosy: Tony R., docs at python
priority: normal
severity: normal
status: open
title: Put ?deprecated? warnings first
type: enhancement
Added file: http://bugs.python.org/file40851/0001-Move-deprecated-blocks-to-the-beginning-of-their-doc.patch

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

From report at bugs.python.org  Sun Oct 25 07:37:55 2015
From: report at bugs.python.org (Alexey Gorshkov)
Date: Sun, 25 Oct 2015 11:37:55 +0000
Subject: [New-bugs-announce] [issue25473] socket.recv() raises correct code
 with the misleading description 'BlockingIOError: [Errno 11] Resource
 temporarily unavailable'
Message-ID: <1445773075.06.0.853655440523.issue25473@psf.upfronthosting.co.za>


New submission from Alexey Gorshkov:

(in continuation to bug https://bugs.python.org/issue25471 )

socket.recv() raises 'BlockingIOError: [Errno 11] Resource temporarily unavailable' in case, if setblocking(False) on socket returned by non-blocking socket's .accept() method and client does not sending data and didn't disconnected yet.

Not sure if I'm correct, but reading glibc doc on recv(), I think raised exception should be corrected: while code 11 correctly corresponds to EWOULDBLOCK, the misleading description 'Resource temporarily unavailable', probably, should be changed:
---
'EWOULDBLOCK'
          Nonblocking mode has been set on the socket, and the read
          operation would block.  (Normally, 'recv' blocks until there
          is input available to be read.)
---

attached file with testing server corrected for this issue

----------
files: s1.py
messages: 253425
nosy: animus
priority: normal
severity: normal
status: open
title: socket.recv() raises correct code with the misleading description 'BlockingIOError: [Errno 11] Resource temporarily unavailable'
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file40857/s1.py

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

From report at bugs.python.org  Sat Oct 24 10:06:12 2015
From: report at bugs.python.org (augustin rieunier)
Date: Sat, 24 Oct 2015 14:06:12 +0000
Subject: [New-bugs-announce] [issue25470] Random Malloc error raised
Message-ID: <1445695572.21.0.810479855368.issue25470@psf.upfronthosting.co.za>


New submission from augustin rieunier:

Hello there, 
I face random malloc error in my code.
I recently added lots of json dumps/loads operation as I plugged my application with redis.

Here's the error raised, and Valgrind information right after:

127.0.0.1 - - [24/Oct/2015 15:57:44] "DELETE /api/private/v1.0/contentcategories/ HTTP/1.1" 404 -
python: malloc.c:2372: sysmalloc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 *(sizeof(size_t))) - 1)) & ~((2 *(sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long) old_end & pagemask) == 0)' failed.
==18768== Invalid read of size 4
==18768==    at 0x55ACE1: PyObject_Free (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x52AB40: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x546605: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5BB178: _PyGC_CollectNoFail (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x566C18: PyImport_Cleanup (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469C8E: Py_Finalize (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469D82: Py_Exit (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EC0: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EDE: PyErr_PrintEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x47BE98: PyRun_SimpleFileExFlags (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5BF712: Py_Main (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x47E350: main (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==  Address 0x6d70020 is 1,536 bytes inside a block of size 1,568 free'd
==18768==    at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18768==    by 0x5540D5: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5465F4: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5BB178: _PyGC_CollectNoFail (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x566C18: PyImport_Cleanup (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469C8E: Py_Finalize (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469D82: Py_Exit (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EC0: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EDE: PyErr_PrintEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x47BE98: PyRun_SimpleFileExFlags (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5BF712: Py_Main (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x47E350: main (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768== 
==18768== Invalid read of size 4
==18768==    at 0x55ACE1: PyObject_Free (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x529CE6: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x553633: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x553728: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5465F4: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5BB178: _PyGC_CollectNoFail (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x566C18: PyImport_Cleanup (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469C8E: Py_Finalize (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469D82: Py_Exit (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EC0: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EDE: PyErr_PrintEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x47BE98: PyRun_SimpleFileExFlags (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==  Address 0x7dc6020 is 144 bytes inside a block of size 224 free'd
==18768==    at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18768==    by 0x553459: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x4B26B6: PyEval_EvalFrameEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5689DA: PyEval_EvalCodeEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x4B279F: PyEval_EvalFrameEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5689DA: PyEval_EvalCodeEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x4B279F: PyEval_EvalFrameEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5689DA: PyEval_EvalCodeEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x4B279F: PyEval_EvalFrameEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x4B234C: PyEval_EvalFrameEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x56A7EB: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x51A3D9: PyObject_Call (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768== 
==18768== Conditional jump or move depends on uninitialised value(s)
==18768==    at 0x55ACEA: PyObject_Free (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x529CE6: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x553633: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x553728: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5465F4: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5BB178: _PyGC_CollectNoFail (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x566C18: PyImport_Cleanup (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469C8E: Py_Finalize (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469D82: Py_Exit (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EC0: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EDE: PyErr_PrintEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x47BE98: PyRun_SimpleFileExFlags (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768== 
==18768== Use of uninitialised value of size 8
==18768==    at 0x55AD02: PyObject_Free (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x529CE6: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x553633: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x553728: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5465F4: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5BB178: _PyGC_CollectNoFail (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x566C18: PyImport_Cleanup (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469C8E: Py_Finalize (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469D82: Py_Exit (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EC0: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EDE: PyErr_PrintEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x47BE98: PyRun_SimpleFileExFlags (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768== 
==18768== Conditional jump or move depends on uninitialised value(s)
==18768==    at 0x55ACEA: PyObject_Free (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x553633: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5540D5: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5465F4: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5BB178: _PyGC_CollectNoFail (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x566C18: PyImport_Cleanup (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469C8E: Py_Finalize (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469D82: Py_Exit (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EC0: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EDE: PyErr_PrintEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x47BE98: PyRun_SimpleFileExFlags (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5BF712: Py_Main (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768== 
==18768== Use of uninitialised value of size 8
==18768==    at 0x55AD02: PyObject_Free (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x553633: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5540D5: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5465F4: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5BB178: _PyGC_CollectNoFail (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x566C18: PyImport_Cleanup (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469C8E: Py_Finalize (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469D82: Py_Exit (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EC0: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EDE: PyErr_PrintEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x47BE98: PyRun_SimpleFileExFlags (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5BF712: Py_Main (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768== 
==18768== Invalid read of size 4
==18768==    at 0x55ACE1: PyObject_Free (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x523F06: PyDict_SetItem (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x4D6F99: _PyModule_ClearDict (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x566CB4: PyImport_Cleanup (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469C8E: Py_Finalize (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469D82: Py_Exit (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EC0: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EDE: PyErr_PrintEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x47BE98: PyRun_SimpleFileExFlags (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5BF712: Py_Main (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x47E350: main (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==  Address 0x8de1020 is not stack'd, malloc'd or (recently) free'd
==18768== 
==18768== Conditional jump or move depends on uninitialised value(s)
==18768==    at 0x55ACEA: PyObject_Free (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x523F06: PyDict_SetItem (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x4D6F99: _PyModule_ClearDict (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x566CB4: PyImport_Cleanup (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469C8E: Py_Finalize (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469D82: Py_Exit (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EC0: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EDE: PyErr_PrintEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x47BE98: PyRun_SimpleFileExFlags (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5BF712: Py_Main (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x47E350: main (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768== 
==18768== Use of uninitialised value of size 8
==18768==    at 0x55AD02: PyObject_Free (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x523F06: PyDict_SetItem (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x4D6F99: _PyModule_ClearDict (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x566CB4: PyImport_Cleanup (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469C8E: Py_Finalize (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469D82: Py_Exit (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EC0: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EDE: PyErr_PrintEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x47BE98: PyRun_SimpleFileExFlags (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5BF712: Py_Main (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x47E350: main (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768== 
==18768== Invalid read of size 4
==18768==    at 0x55ACE1: PyObject_Free (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5AE6E0: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5532C7: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x553633: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x553459: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x523D65: PyDict_SetItem (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x4D6F57: _PyModule_ClearDict (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x566CB4: PyImport_Cleanup (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469C8E: Py_Finalize (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469D82: Py_Exit (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EC0: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EDE: PyErr_PrintEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==  Address 0x6ac7020 is not stack'd, malloc'd or (recently) free'd
==18768== 
==18768== Invalid read of size 4
==18768==    at 0x55ACE1: PyObject_Free (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x55982B: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x553633: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5540D5: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5465F4: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5BB178: _PyGC_CollectNoFail (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x566ABA: PyImport_Cleanup (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469C8E: Py_Finalize (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469D82: Py_Exit (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EC0: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EDE: PyErr_PrintEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x47BE98: PyRun_SimpleFileExFlags (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==  Address 0x8b29020 is 448 bytes inside a block of size 1,114 free'd
==18768==    at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18768==    by 0x554B1F: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x48E1A7: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x166F2906: __Pyx_PyObject_Call (lxml.etree.c:202589)
==18768==    by 0x166ED370: __Pyx__PyObject_CallOneArg (lxml.etree.c:202626)
==18768==    by 0x167F5F7A: PyInit_etree (lxml.etree.c:39754)
==18768==    by 0x58564F: _PyImport_LoadDynamicModule (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x585A39: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x4B3863: PyEval_EvalFrameEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5689DA: PyEval_EvalCodeEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x4B279F: PyEval_EvalFrameEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x56A7EB: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768== 
==18768== Invalid read of size 4
==18768==    at 0x55ACE1: PyObject_Free (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x553711: PyDict_Clear (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5540D5: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5465F4: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5BB178: _PyGC_CollectNoFail (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x566ABA: PyImport_Cleanup (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469C8E: Py_Finalize (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469D82: Py_Exit (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EC0: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EDE: PyErr_PrintEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x47BE98: PyRun_SimpleFileExFlags (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5BF712: Py_Main (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==  Address 0x6bf9020 is 96 bytes inside a block of size 224 free'd
==18768==    at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18768==    by 0x553459: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x552FB7: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x56A814: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x51A3D9: PyObject_Call (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x4B013E: PyEval_EvalFrameEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5689DA: PyEval_EvalCodeEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x4B279F: PyEval_EvalFrameEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5689DA: PyEval_EvalCodeEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x4B279F: PyEval_EvalFrameEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x4B234C: PyEval_EvalFrameEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x56A7EB: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768== 
==18768== Conditional jump or move depends on uninitialised value(s)
==18768==    at 0x55ACEA: PyObject_Free (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x52AB40: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x52983D: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x553584: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x529B9C: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5465F4: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5BB178: _PyGC_CollectNoFail (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x566ABA: PyImport_Cleanup (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469C8E: Py_Finalize (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469D82: Py_Exit (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EC0: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EDE: PyErr_PrintEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768== 
==18768== Use of uninitialised value of size 8
==18768==    at 0x55AD02: PyObject_Free (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x52AB40: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x52983D: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x553584: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x529B9C: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5465F4: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5BB178: _PyGC_CollectNoFail (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x566ABA: PyImport_Cleanup (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469C8E: Py_Finalize (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469D82: Py_Exit (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EC0: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EDE: PyErr_PrintEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768== 
==18768== Conditional jump or move depends on uninitialised value(s)
==18768==    at 0x55ACEA: PyObject_Free (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x55982B: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x553633: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5540D5: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5465F4: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5BB178: _PyGC_CollectNoFail (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x566ABA: PyImport_Cleanup (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469C8E: Py_Finalize (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469D82: Py_Exit (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EC0: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EDE: PyErr_PrintEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x47BE98: PyRun_SimpleFileExFlags (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768== 
==18768== Invalid read of size 4
==18768==    at 0x55ACE1: PyObject_Free (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x166FB5F6: __pyx_module_cleanup (lxml.etree.c:202116)
==18768==    by 0x4A5692: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x553633: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x553728: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5465F4: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5BB178: _PyGC_CollectNoFail (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x566ABA: PyImport_Cleanup (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469C8E: Py_Finalize (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469D82: Py_Exit (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EC0: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EDE: PyErr_PrintEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==  Address 0x7f25020 is 432 bytes inside a block of size 632 free'd
==18768==    at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18768==    by 0x52A02C: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5532C7: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x529F6F: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x529C39: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x523F06: PyDict_SetItem (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x4D6F99: _PyModule_ClearDict (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x566CB4: PyImport_Cleanup (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469C8E: Py_Finalize (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469D82: Py_Exit (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EC0: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EDE: PyErr_PrintEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768== 
==18768== Invalid read of size 4
==18768==    at 0x55ACE1: PyObject_Free (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5348FD: PyGrammar_RemoveAccelerators (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469D24: Py_Finalize (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469D82: Py_Exit (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EC0: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EDE: PyErr_PrintEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x47BE98: PyRun_SimpleFileExFlags (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5BF712: Py_Main (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x47E350: main (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==  Address 0x61d3020 is 144 bytes inside a block of size 664 free'd
==18768==    at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18768==    by 0x5348FD: PyGrammar_RemoveAccelerators (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469D24: Py_Finalize (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469D82: Py_Exit (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EC0: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EDE: PyErr_PrintEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x47BE98: PyRun_SimpleFileExFlags (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5BF712: Py_Main (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x47E350: main (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768== 
==18768== Conditional jump or move depends on uninitialised value(s)
==18768==    at 0x55ACEA: PyObject_Free (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5348FD: PyGrammar_RemoveAccelerators (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469D24: Py_Finalize (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469D82: Py_Exit (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EC0: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EDE: PyErr_PrintEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x47BE98: PyRun_SimpleFileExFlags (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5BF712: Py_Main (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x47E350: main (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768== 
==18768== Use of uninitialised value of size 8
==18768==    at 0x55AD02: PyObject_Free (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5348FD: PyGrammar_RemoveAccelerators (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469D24: Py_Finalize (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469D82: Py_Exit (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EC0: ??? (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x469EDE: PyErr_PrintEx (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x47BE98: PyRun_SimpleFileExFlags (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x5BF712: Py_Main (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768==    by 0x47E350: main (in /home/dev/Desktop/PROJ/git/api_clone/api/flask/bin/python3.4)
==18768== 
==18768== 
==18768== HEAP SUMMARY:
==18768==     in use at exit: 6,976,358 bytes in 14,343 blocks
==18768==   total heap usage: 275,841 allocs, 261,498 frees, 118,029,343 bytes allocated
==18768== 
==18768== LEAK SUMMARY:
==18768==    definitely lost: 0 bytes in 0 blocks
==18768==    indirectly lost: 0 bytes in 0 blocks
==18768==      possibly lost: 74,928 bytes in 127 blocks
==18768==    still reachable: 6,901,430 bytes in 14,216 blocks
==18768==         suppressed: 0 bytes in 0 blocks
==18768== Rerun with --leak-check=full to see details of leaked memory
==18768== 
==18768== For counts of detected and suppressed errors, rerun with: -v
==18768== Use --track-origins=yes to see where uninitialised values come from
==18768== ERROR SUMMARY: 8068 errors from 156 contexts (suppressed: 0 from 0)

----------
components: Interpreter Core
messages: 253405
nosy: augustin rieunier
priority: normal
severity: normal
status: open
title: Random Malloc error raised
versions: Python 3.4

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

From report at bugs.python.org  Sat Oct 24 06:09:55 2015
From: report at bugs.python.org (Vilnis Termanis)
Date: Sat, 24 Oct 2015 10:09:55 +0000
Subject: [New-bugs-announce] [issue25469] multiprocessing
 .Condition.notify(_all) function has O(N) time complexity where N is the
 number of wait() calls with a timeout since the last notify(_all) call
Message-ID: <1445681395.35.0.393874869917.issue25469@psf.upfronthosting.co.za>


New submission from Vilnis Termanis:

multiprocessing's Condition uses a couple of semaphores to keep track of
processes which are sleeping and have woken up whilst waiting for the
condition. These counters however are only ever decremented in the
notify(_all) functions, via a loop which results in somewhat unexpected
behaviour where said functions take longer to run than expected.

The proposed patch simplifies notify(_all) functions such that time complexity
is still O(N) but crucially N is the number of currently sleeping processes
only (rather than number of wait() calls since last notify(_all) call).

Note: This also affects Event.wait() & Event.set() in the same fashion since a
Condition is used under the hood.

I've attached mp_sync_condition.patch based on "in-development" branch as of
98840:2028aed246c0. I have run unit tests on said commit (via debug build)
using:

./python -bb -E -Wd -m test -r -v -uall\
    test_multiprocessing_fork\
    test_multiprocessing_fork\
    server test_multiprocessing_spawn

Additionally I've run condition_test.py before & after to illustrate performance
of the proposed change as well as demonstrate the issue.

----------
components: Library (Lib)
files: mp_sync_condition.patch
keywords: patch
messages: 253403
nosy: vilnis.termanis
priority: normal
severity: normal
status: open
title: multiprocessing .Condition.notify(_all) function has O(N) time complexity where N is the number of wait() calls with a timeout since the last notify(_all) call
type: performance
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/file40853/mp_sync_condition.patch

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

From report at bugs.python.org  Sat Oct 24 19:03:29 2015
From: report at bugs.python.org (Alexey Gorshkov)
Date: Sat, 24 Oct 2015 23:03:29 +0000
Subject: [New-bugs-announce] [issue25471] socket.recv() blocks while it's
 gettimeout() returns 0.0
Message-ID: <1445727809.94.0.696138695468.issue25471@psf.upfronthosting.co.za>


New submission from Alexey Gorshkov:

socket created with listening socket set to setblocking(False). gettimeout() of accept()-returned socket returns 0.0 , but recv() method blocks while client is connected and not sending any data. If client disconnects, socket returned by accept() starting return 0-length bytes string without blocking.

glibc doc on recv():
---
If nonblocking mode is set for SOCKET, and no data are available to be read, 'recv' fails immediately rather than waiting.
---

testing server and client code attached.

tested with Python 3.5.0 and Python 2.7.10

----------
files: s1.py
messages: 253418
nosy: animus
priority: normal
severity: normal
status: open
title: socket.recv() blocks while it's gettimeout() returns 0.0
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file40855/s1.py

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

From report at bugs.python.org  Sun Oct 25 13:16:29 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 25 Oct 2015 17:16:29 +0000
Subject: [New-bugs-announce] [issue25475] use argparse instead of getopt
Message-ID: <1445793389.31.0.201223450113.issue25475@psf.upfronthosting.co.za>


New submission from St?phane Wirtel:

not sure, but in the documentation, there is a note
"Module argparse: Alternative command line option and argument parsing library."

may be it's time to move from getopt to argparse and mark getopt as deprecated.

We have to modify 45 files, but I can submit a separated patch for each file.

ack "import getopt" -l | wc -l
      45

----------
components: Library (Lib)
messages: 253429
nosy: matrixise
priority: normal
severity: normal
status: open
title: use argparse instead of getopt
versions: Python 3.6

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

From report at bugs.python.org  Sun Oct 25 08:04:58 2015
From: report at bugs.python.org (Fred Gansevles)
Date: Sun, 25 Oct 2015 12:04:58 +0000
Subject: [New-bugs-announce] [issue25474] Weird behavior when setting
 f_trace in a context manager
Message-ID: <1445774698.38.0.095988844457.issue25474@psf.upfronthosting.co.za>


New submission from Fred Gansevles:

I'm playing with the idea of making a DSL based on anonynous code blocks

I discovered that the behaviour of the context manager is different in some cases if there are line-continuations in the 'with' command

I've attached a script that reproduces this behaviour.

With both Python 2.7.6 and Python 3.4.3 I get the same results.


Fred.

----------
files: as_context.py
messages: 253426
nosy: Fred Gansevles
priority: normal
severity: normal
status: open
title: Weird behavior when setting f_trace in a context manager
type: behavior
Added file: http://bugs.python.org/file40858/as_context.py

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

From report at bugs.python.org  Sat Oct 24 05:24:36 2015
From: report at bugs.python.org (Shiz)
Date: Sat, 24 Oct 2015 09:24:36 +0000
Subject: [New-bugs-announce] [issue25468]
 PyTraceBack_Print()/_Py_DisplaySourceLine() should take custom loaders into
 account
Message-ID: <1445678676.07.0.356698516003.issue25468@psf.upfronthosting.co.za>


New submission from Shiz:

Currently, when an error occurs in a module loaded through a loader in sys.meta_path with no direct file name correlation on the filesystem, the traceback source line is empty as such:

  File "/Users/mark/Development/Projects/Rave/rave/rave/game.py", line 65, in run   
    self.window.render(None)                                                        
  File "/.modules/sdl2/video/window.py", line 86, in render                         
  File "/.modules/sdl2/video/window.py", line 259, in swap                          
KeyboardInterrupt   

While the filename has no direct mapping on the file system, what it can do is just do the equivalent of module.__loader__.get_source('module') to retrieve the source code to find the appropriate line in, and only if that fails fall back on trying to interpret the module file name as a normal file system path.

----------
components: Interpreter Core
messages: 253400
nosy: shiz
priority: normal
severity: normal
status: open
title: PyTraceBack_Print()/_Py_DisplaySourceLine() should take custom loaders into account
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Oct 23 11:21:27 2015
From: report at bugs.python.org (alanf)
Date: Fri, 23 Oct 2015 15:21:27 +0000
Subject: [New-bugs-announce] [issue25466] offer "from __future__ import"
 option for "raise... from"
Message-ID: <1445613687.79.0.0523081768685.issue25466@psf.upfronthosting.co.za>


New submission from alanf:

There is no "from __future__ import" option that would allow Python 2x users the "raise... from" syntax that is provided with Python 3. This is especially unfortunate because even if the "raise... from" is included in a branch that is never executed, loading the code in 2.7 can cause a seemingly unrelated exception (in my case, an import error for StringIO). Since my code must work in 2.7, 3.3, and 3.4, this is a problem.

I have found a workaround. If I want to achieve the equivalent of "raise XXX from None", for instance, I can do it as follows:

    if hasattr(newExc, '__cause__'):
        newExc.__cause__ = None
    raise newExc

This works because the Exception class exists in all three Python versions, but only has a __cause__ attribute in Python 3. However, it's clumsier than I would like. Also, it's not obvious. 

I discovered that exception handling had changed when I saw that raising an exception when another one was active caused a "During handling of the above exception, another exception occurred" message on Python 3 (behavior that I didn't want) but was silently dropped in Python 2.7 (behavior that I did want). After I found a description of the "raise... from None" syntax in Python 3, I expected to find a "from __future__ import" statement that would handle this, but was disappointed. It took me a while longer to figure out the workaround above. I'd rather that other people didn't have to go through the process of figuring out the workaround.

----------
messages: 253384
nosy: alanf
priority: normal
severity: normal
status: open
title: offer "from __future__ import" option for "raise... from"
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Sun Oct 25 17:46:32 2015
From: report at bugs.python.org (David Beazley)
Date: Sun, 25 Oct 2015 21:46:32 +0000
Subject: [New-bugs-announce] [issue25476] close() behavior on non-blocking
 BufferedIO objects with sockets
Message-ID: <1445809592.17.0.674825265911.issue25476@psf.upfronthosting.co.za>


New submission from David Beazley:

First comment: In the I/O library, there is documented behavior for how things work in the presence of non-blocking I/O.  For example, read/write methods returning None on raw file objects.  Methods on BufferedIO instances raise a BlockingIOError for operations that can't complete. 

However, the implementation of close() is currently broken.  If buffered I/O is being used and a file is closed, it's possible that the close will fail due to a BlockingIOError occurring as buffered data is flushed to output.  However, in this case, the file is closed anyways and there is no possibility to retry.  Here is an example to illustrate:

>>> from socket import *
>>> s = socket(AF_INET, SOCK_STREAM)
>>> s.connect(('somehost', port))
>>> s.setblocking(False)
>>> f = s.makefile('wb', buffering=10000000)   # Large buffer
>>> f.write(b'x'*1000000)
>>>

Now, watch carefully

>>> f
<_io.BufferedWriter name=4>
>>> f.closed
False
>>> f.close()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
BlockingIOError: [Errno 35] write could not complete without blocking
>>> f
<_io.BufferedWriter name=-1>
>>> f.closed
True
>>>

I believe this can be fixed by changing a single line in Modules/_io/bufferedio.c:

--- bufferedio_orig.c	2015-10-25 16:40:22.000000000 -0500
+++ bufferedio.c	2015-10-25 16:40:35.000000000 -0500
@@ -530,10 +530,10 @@
     res = PyObject_CallMethodObjArgs((PyObject *)self, _PyIO_str_flush, NULL);
     if (!ENTER_BUFFERED(self))
         return NULL;
-    if (res == NULL)
-        PyErr_Fetch(&exc, &val, &tb);
-    else
-        Py_DECREF(res);
+    if (res == NULL) 
+      goto end;
+    else 
+      Py_DECREF(res);
 
     res = PyObject_CallMethodObjArgs(self->raw, _PyIO_str_close, NULL);

With this patch, the close() method can be retried as appropriate until all buffered data is successfully written.

----------
components: IO
messages: 253438
nosy: dabeaz
priority: normal
severity: normal
status: open
title: close() behavior on non-blocking BufferedIO objects with sockets
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sun Oct 25 20:27:30 2015
From: report at bugs.python.org (Antony Lee)
Date: Mon, 26 Oct 2015 00:27:30 +0000
Subject: [New-bugs-announce] [issue25477] text mode for pkgutil.get_data
Message-ID: <1445819250.09.0.301891559419.issue25477@psf.upfronthosting.co.za>


New submission from Antony Lee:

Initially suggested in #25330: it would be helpful to provide text mode support (returning unicode, and handling universal newlines) for pkgutil.get_data (either as a keyword argument, or as a separate function).

----------
components: Library (Lib)
messages: 253441
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: text mode for pkgutil.get_data
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Oct 25 22:24:40 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 26 Oct 2015 02:24:40 +0000
Subject: [New-bugs-announce] [issue25478] Consider adding a normalize()
 method to collections.Counter()
Message-ID: <1445826280.05.0.307309053044.issue25478@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Allen Downey suggested this at PyCon in Montreal and said it would be useful in his bayesian statistics courses.  Separately, Peter Norvig created a normalize() function in his probablity tutorial at In[45] in http://nbviewer.ipython.org/url/norvig.com/ipython/Probability.ipynb .

I'm creating this tracker item to record thoughts about the idea.  Right now, it isn't clear whether Counter is the right place to support this operation, how it should be designed, whether to use an in-place operation or an operation that creates a new counter, should it have rounding to make the result exactly equal to 1.0, should it use math.fsum() for float inputs?

Should it support other target totals besides 1.0?

  >>> Counter(red=11, green=5, blue=4).normalize(100) # percentage
  Counter(red=55, green=25, blue=20)

Also would it make sense to support something like this?

  sampled_gender_dist = Counter(male=405, female=421)
  world_gender_dist = Counter(male=0.51, female=0.50)
  cs = world_gender_dist.chi_squared(observed=sampled_gender_dist)

Would it be better to just have a general multiply-by-scalar operation for scaling?

  c = Counter(observations)
  c.scale_by(1.0 / sum(c.values())

Perhaps use an operator?

  c /= sum(c.values())

----------
assignee: rhettinger
components: Library (Lib)
messages: 253452
nosy: rhettinger
priority: low
severity: normal
status: open
title: Consider adding a normalize() method to collections.Counter()
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sun Oct 25 23:14:01 2015
From: report at bugs.python.org (Szymon Trapp)
Date: Mon, 26 Oct 2015 03:14:01 +0000
Subject: [New-bugs-announce] [issue25479] Increase unit test coverage for
 abc.py
Message-ID: <1445829241.77.0.00855893760535.issue25479@psf.upfronthosting.co.za>


New submission from Szymon Trapp:

Added a new function to unit tests for abc.py to increase the test coverage, specifically for the usage of __subclasshook__.

This will cover lines 209-214.

Note: this is my first submission to Python and I'm following the advice to start with the unit tests coverage.

----------
components: Tests
files: mywork.patch
keywords: patch
messages: 253453
nosy: szymon
priority: normal
severity: normal
status: open
title: Increase unit test coverage for abc.py
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file40860/mywork.patch

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

From report at bugs.python.org  Mon Oct 26 04:14:22 2015
From: report at bugs.python.org (tryme)
Date: Mon, 26 Oct 2015 08:14:22 +0000
Subject: [New-bugs-announce] [issue25480] string format in large number
Message-ID: <1445847262.11.0.792420097545.issue25480@psf.upfronthosting.co.za>


New submission from tryme:

I am new to python and I don't know if it really is a bug. But indeed when I see sth is not right it is worthwhile to point out.

Using fresh installed ubuntu desktop with build in python3.
typing the command line by line in terminal just for learning. below is the scene
it has automatically round down. Don't know if it is limit of float.


$ python3
Python 3.4.3 (default, Oct 14 2015, 20:28:29) 
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.

>>> "hello{0:5.2f}".format(100000000000000.234)
'hello100000000000000.23'
>>> "hello{0:5.2f}".format(4111111111111111117.234)
'hello4111111111111111168.00'
>>> "hello{0:5.2f}".format(1000000000000000000.234)
'hello1000000000000000000.00'

----------
components: Build
messages: 253459
nosy: tryme
priority: normal
severity: normal
status: open
title: string format in large number
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Oct 26 04:39:57 2015
From: report at bugs.python.org (jaystrict)
Date: Mon, 26 Oct 2015 08:39:57 +0000
Subject: [New-bugs-announce] [issue25481] PermissionError in
 subprocess.check_output() when running as a different user (not login
 shell)
Message-ID: <1445848797.06.0.600636578696.issue25481@psf.upfronthosting.co.za>


New submission from jaystrict:

When running subprocess.check_output(['doesnotexist']) as another user, I expect a FileNotFoundError, but a PermissionError is thrown.

How to reproduce:
============================================================
[user1 tmp]$ su --login user2
Password: 
[user2 ~]$ python
Python 3.5.0 (default, Sep 20 2015, 11:28:25) 
[GCC 5.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.check_output(['asdf'])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.5/subprocess.py", line 629, in check_output
    **kwargs).stdout
  File "/usr/lib/python3.5/subprocess.py", line 696, in run
    with Popen(*popenargs, **kwargs) as process:
  File "/usr/lib/python3.5/subprocess.py", line 950, in __init__
    restore_signals, start_new_session)
  File "/usr/lib/python3.5/subprocess.py", line 1540, in _execute_child
    raise child_exception_type(errno_num, err_msg)
FileNotFoundError: [Errno 2] No such file or directory: 'asdf'
>>> quit()
[user2 ~]$ exit
logout
[user1 tmp]$ su user2
Password: 
[user2 tmp]$ python
Python 3.5.0 (default, Sep 20 2015, 11:28:25) 
[GCC 5.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.check_output(['asdf'])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.5/subprocess.py", line 629, in check_output
    **kwargs).stdout
  File "/usr/lib/python3.5/subprocess.py", line 696, in run
    with Popen(*popenargs, **kwargs) as process:
  File "/usr/lib/python3.5/subprocess.py", line 950, in __init__
    restore_signals, start_new_session)
  File "/usr/lib/python3.5/subprocess.py", line 1540, in _execute_child
    raise child_exception_type(errno_num, err_msg)
PermissionError: [Errno 13] Permission denied
>>> quit()
[user2 tmp]$

----------
messages: 253462
nosy: jaystrict
priority: normal
severity: normal
status: open
title: PermissionError in subprocess.check_output() when running as a different user (not login shell)
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Oct 26 07:34:56 2015
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Mon, 26 Oct 2015 11:34:56 +0000
Subject: [New-bugs-announce] [issue25482] signal.set_wakeup_fd() doesn't
 work if the signal don't have handler
Message-ID: <1445859296.06.0.537058365711.issue25482@psf.upfronthosting.co.za>


New submission from Atsuo Ishimoto:

I expect following code prints '\x1c' when I resize terminal window on Linix/Mac terminal.

--------------------------------
import select, os, signal

rfd, wfd = os.pipe()
os.set_blocking(wfd, False)

signal.set_wakeup_fd(wfd)
select.select([rfd], [], [])
print(os.read(rfd, 2))
--------------------------------

Resizing terminal window make SIGWINCH signal sent to Python process. But nothing written to fd I specified to set_wakeup_fd().

I checked Modules/signalmodule.c and found I should assign signal handler for the signal I want to wakeup fd. So following code works as I expected.

--------------------------------
import select, os, signal

rfd, wfd = os.pipe()
os.set_blocking(wfd, False)

signal.set_wakeup_fd(wfd)

signal.signal(signal.SIGWINCH, lambda *args:0)
select.select([rfd], [], [])
print(os.read(rfd, 2))
--------------------------------

Is this an expected behavior of signal.set_wakeup_fd()?

----------
components: Library (Lib)
messages: 253468
nosy: ishimoto
priority: normal
severity: normal
status: open
title: signal.set_wakeup_fd() doesn't work if the signal don't have handler
versions: Python 3.5

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

From report at bugs.python.org  Mon Oct 26 11:44:59 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 26 Oct 2015 15:44:59 +0000
Subject: [New-bugs-announce] [issue25483] Improve f-string implementation:
 FORMAT_VALUE opcode
Message-ID: <1445874299.22.0.773155754186.issue25483@psf.upfronthosting.co.za>


New submission from Eric V. Smith:

Currently, the f-string f'a{3!r:10}' evaluates to bytecode that does the same thing as:

''.join(['a', format(repr(3), '10')])

That is, it literally calls the functions format() and repr(). The same holds true for str() and ascii() with !s and !a, respectively.

By redefining format, str, repr, and ascii, you can break or pervert the computation of the f-string's value:

>>> def format(v, fmt=None): return '42'
...
>>> f'{3}'
'42'

It's always been my intention to fix this. This patch adds an opcode FORMAT_VALUE, which instead of looking up format, etc., directly calls PyObject_Format, PyObject_Str, PyObject_Repr, and PyObject_ASCII. Thus, you can no longer modify what an f-string produces merely by overriding the named functions.


In addition, because I'm now saving the name lookups and function calls, performance is improved.

Here are the times without this patch:

$ ./python -m timeit -s 'x="test"' 'f"{x}"'
1000000 loops, best of 3: 0.3 usec per loop

$ ./python -m timeit -s 'x="test"' 'f"{x!s}"'
1000000 loops, best of 3: 0.511 usec per loop

$ ./python -m timeit -s 'x="test"' 'f"{x!r}"'
1000000 loops, best of 3: 0.497 usec per loop

$ ./python -m timeit -s 'x="test"' 'f"{x!a}"'
1000000 loops, best of 3: 0.461 usec per loop


And with this patch:

$ ./python -m timeit -s 'x="test"' 'f"{x}"'
10000000 loops, best of 3: 0.02 usec per loop

$ ./python -m timeit -s 'x="test"' 'f"{x!s}"'
100000000 loops, best of 3: 0.02 usec per loop

$ ./python -m timeit -s 'x="test"' 'f"{x!r}"'
10000000 loops, best of 3: 0.0896 usec per loop

$ ./python -m timeit -s 'x="test"' 'f"{x!a}"'
10000000 loops, best of 3: 0.0923 usec per loop


So a 90%+ speedup, for these simple cases.

Also, now f-strings are faster than %-formatting, at least for some types:

$ ./python -m timeit -s 'x="test"' '"%s"%x'
10000000 loops, best of 3: 0.0755 usec per loop

$ ./python -m timeit -s 'x="test"' 'f"{x}"'
10000000 loops, best of 3: 0.02 usec per loop


Note that people often "benchmark" %-formatting with code like the following. But the optimizer converts this to a constant string, so it's not a fair comparison:

$ ./python -m timeit '"%s"%"test"'
100000000 loops, best of 3: 0.0161 usec per loop


These microbenchmarks aren't the end of the story, since the string concatenation also takes some time. That's another optimization I might implement in the future.

Thanks to Mark and Larry for some advice on this.

----------
assignee: eric.smith
components: Interpreter Core
files: format-opcode.diff
keywords: patch
messages: 253476
nosy: Mark.Shannon, eric.smith, larry
priority: normal
severity: normal
stage: patch review
status: open
title: Improve f-string implementation: FORMAT_VALUE opcode
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file40863/format-opcode.diff

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

From report at bugs.python.org  Mon Oct 26 12:08:58 2015
From: report at bugs.python.org (Sapphire Becker)
Date: Mon, 26 Oct 2015 16:08:58 +0000
Subject: [New-bugs-announce] [issue25484] Operator issue with "in" on same
 level and preceding ==
Message-ID: <1445875738.33.0.0502599312232.issue25484@psf.upfronthosting.co.za>


New submission from Sapphire Becker:

So I found this while using == as xnor, here's a summary of the issue:

>>> "h" in ["h"] == True
False
>>> ("h" in ["h"]) == True
True
>>> "h" in (["h"] == True)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: argument of type 'bool' is not iterable

Now obviously #3 should error but I would expect #1 and #2 to be the same. I checked it out with dis (in Py 3.4) and it seems like a bug. In detail:

#2's is very clean, exactly what I would expect:
>>> dis.dis('("h" in ["h"]) == True')
  1           0 LOAD_CONST               0 ('h')
              3 LOAD_CONST               2 (('h',))
              6 COMPARE_OP               6 (in)
              9 LOAD_CONST               1 (True)
             12 COMPARE_OP               2 (==)
             15 RETURN_VALUE

#1's, however, looks like a mess:
>>> dis.dis('"h" in ["h"] == True')
  1           0 LOAD_CONST               0 ('h')
              3 LOAD_CONST               0 ('h')
              6 BUILD_LIST               1
              9 DUP_TOP
             10 ROT_THREE
             11 COMPARE_OP               6 (in)
             14 JUMP_IF_FALSE_OR_POP    24
             17 LOAD_CONST               1 (True)
             20 COMPARE_OP               2 (==)
             23 RETURN_VALUE
        >>   24 ROT_TWO
             25 POP_TOP
             26 RETURN_VALUE

I had to write out the stack to understand this:
1. ['h']
2. ['h', 'h']
3. ['h', ['h']]
4. ['h', ['h'], ['h']]
5. [['h'], 'h', ['h']]
6. [['h'], True] # True = result of in operation
7. [['h']]
8. [['h'], True] # True = =='s right-hand value
9. [False] # False = result of == operation

Therefore the way to actually get true in the first case is:

>>> "h" in ["h"] == ["h"]
True


I won't pretend to know how simple it is in Python's architecture but I imagine it's just setting a higher precedence for "in" than ==?

Not a huge deal, it's workaroundable, just awkward that there wasn't really any indication it was failing so it took a bit to debug.

----------
components: Interpreter Core
messages: 253478
nosy: Sapphire Becker
priority: normal
severity: normal
status: open
title: Operator issue with "in" on same level and preceding ==
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Mon Oct 26 14:20:19 2015
From: report at bugs.python.org (desbma)
Date: Mon, 26 Oct 2015 18:20:19 +0000
Subject: [New-bugs-announce] [issue25485] Add a context manager to
 telnetlib.Telnet
Message-ID: <1445883619.21.0.032521861016.issue25485@psf.upfronthosting.co.za>


New submission from desbma:

telnetlib.Telnet could have a context manager to call close() automatically.

I can provide a patch if the idea is approved, although I have never contributed to Python.

----------
components: Library (Lib)
messages: 253489
nosy: desbma
priority: normal
severity: normal
status: open
title: Add a context manager to telnetlib.Telnet
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Mon Oct 26 16:33:43 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 26 Oct 2015 20:33:43 +0000
Subject: [New-bugs-announce] [issue25486] Resurrect inspect.getargspec() in
 3.6
Message-ID: <1445891623.91.0.591196153919.issue25486@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

See issue #20438 for more details

----------
components: Library (Lib)
messages: 253499
nosy: yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: Resurrect inspect.getargspec() in 3.6
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Mon Oct 26 20:38:47 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 27 Oct 2015 00:38:47 +0000
Subject: [New-bugs-announce] [issue25487] imp module DeprecationWarning in
 test suite
Message-ID: <1445906327.87.0.677600064141.issue25487@psf.upfronthosting.co.za>


New submission from Martin Panter:

I typically run the test suite with the ?python -bWall? options enabled, and there is a new warning. I suspect it is a result of the DeprecationWarning upgrade in revision 5877c191b76e. When -Werror is enabled it causes test failure.

The fix is probably pretty easy; there are probably other deprecated modules tested in the test suite to copy from. I think there is a test.support function that can suppress deprecation warnings while importing a particular module.

$ make -s -j2 && LC_TIME= ./python -bWall -m test.regrtest -j0
. . .
[167/399] test_imp
/media/disk/home/proj/python/cpython/Lib/test/test_imp.py:16: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
  import imp
. . .
[207/399] test_modulefinder -- running: test_lzma (39 sec)
/media/disk/home/proj/python/cpython/Lib/modulefinder.py:14: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
  import imp
. . .
[335/399] test_threaded_import -- running: test_tarfile (36 sec), test_subprocess (62 sec)
/media/disk/home/proj/python/cpython/Lib/modulefinder.py:14: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
  import imp

----------
components: Tests
messages: 253509
nosy: brett.cannon, martin.panter
priority: normal
severity: normal
status: open
title: imp module DeprecationWarning in test suite
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue Oct 27 05:25:13 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 27 Oct 2015 09:25:13 +0000
Subject: [New-bugs-announce] [issue25488] IDLE: Remove idlelib from sys.path
 when added
Message-ID: <1445937913.03.0.194834202195.issue25488@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Problem: Consider module idlelib.run.  The following is correct.

C:\Users\Terry>python -c "import run"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named 'run'

But in IDLE started from icon or command line
>>> import run
>>> 

With respect to the goal of developing code that can run outside of IDLE, not raising ImportError is a bug. Suppose a user erroneously writes 'import run' or 'import help' (in repository IDLE).  The error could be that the file is 'runner' or 'helper' or that 'run' or 'help' is not in the same directory. The import should fail rather than the user getting a error later because the wrong file was imported.

Reason: When python runs 'somepath/file.py', it prepends 'somepath' to sys.path.  So when python runs '.../idlelib/whatever.py', it prepends '.../idlelib' to sys.path.  This occurs in both IDLE and user processes.

When 'somepath/file.py' is either on startup or from the editor, IDLE first prepends 'somepath' to sys.path just as python does.

We are planning to add perhaps 50 new short lowercase (PEP8) names to idlelib.  This will greatly increase the possibility of accidentally matching something users write, if only in error, or even of  masking a stdlib module.

Solution: In PyShell.main and run.main, remove the prepended idlelib entry *if it is there* (see below).  On Windows, at least, for installed python, sys.path would then be identical on startup whether a file is run with python or IDLE.  

Would this affect IDLE itself?  I am sure not. AFAIK, IDLE does not exploit the presence of idlelib on sys.path, and always imports idlelib files via idlelib.

Further more, when IDLE is started from console Python with 'import idlelib.idle', which I regularly do for the repository version, '.../idlelib' is *not* prepended.  This is why IDLE should not depend on its presence and why removal should check first.  This also means that whether a file runs in IDLE depends on how IDLE is started, whether directly or via '>>> import idlelib.idle' within console python.


Note 1. idlelib.idle prepends repository 'lib' even when already present; this could be fixed also.  Another issue to track down, probably not due to IDLE, is that at least on Windows the binary directory is present twice.)

Note 2: The contents of sys.modules would still be different, along with the problem that 'import tkinter; tkinter.font' runs in IDLE.  (This example comes from a Stackoverflow question.) But this is a different issue and I cannot see a fix for it.

----------
assignee: terry.reedy
messages: 253525
nosy: markroseman, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: Remove idlelib from sys.path when added
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Oct 27 07:25:56 2015
From: report at bugs.python.org (Brian Sutherland)
Date: Tue, 27 Oct 2015 11:25:56 +0000
Subject: [New-bugs-announce] [issue25489] sys.exit() caught in exception
 handler
Message-ID: <1445945156.1.0.415307859083.issue25489@psf.upfronthosting.co.za>


New submission from Brian Sutherland:

Running the attached file with python3 shows that SystemExit is caught rather than causing the process to stop. That's quite surprising.

----------
components: asyncio
files: test_sys_exit_in_exception_handler.py
messages: 253529
nosy: gvanrossum, haypo, jinty, yselivanov
priority: normal
severity: normal
status: open
title: sys.exit() caught in exception handler
versions: Python 3.5
Added file: http://bugs.python.org/file40867/test_sys_exit_in_exception_handler.py

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

From report at bugs.python.org  Tue Oct 27 09:52:10 2015
From: report at bugs.python.org (Anton Tagunov)
Date: Tue, 27 Oct 2015 13:52:10 +0000
Subject: [New-bugs-announce] [issue25490] small mistake in example for
 random.choice()
Message-ID: <1445953930.63.0.811107354907.issue25490@psf.upfronthosting.co.za>


New submission from Anton Tagunov:

Invalid example at this page: https://docs.python.org/3.6/library/random.html

'.items()' is missed in the line below:

>>> population = [val for val, cnt in weighted_choices for i in range(cnt)]


The correct variant:

>>> population = [val for val, cnt in weighted_choices.items() for i in range(cnt)]

----------
assignee: docs at python
components: Documentation
messages: 253537
nosy: Anton Tagunov, docs at python
priority: normal
severity: normal
status: open
title: small mistake in example for random.choice()
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Oct 27 10:39:48 2015
From: report at bugs.python.org (wozlaf)
Date: Tue, 27 Oct 2015 14:39:48 +0000
Subject: [New-bugs-announce] [issue25491] ftplib.sendcmd only accepts string
Message-ID: <1445956788.1.0.428769013447.issue25491@psf.upfronthosting.co.za>


New submission from wozlaf:

The FTP server (ProFTPD 1.3.5a) returns some file and folder names not properly encoded in UTF-8, when requesting with FTP command "MLSD" and "OPTS UTF8 ON".
To access I need to send them back to the server exactly as they came (bytes) with ftp.sendcmd(b"CWD" + path_bytes).

This results in an exception:
 File "C:\Python34\lib\ftplib.py", line 190, in putline
 line = line + CRLF
 TypeError: can't concat bytes to str

Sadly this makes ftplib only support sending of UTF-8 commands and file names. So I need to work around with my own version of "sendcmd" for now.

"ftplib.sendcmd()" should handle bytes and strings (UTF-8).

----------
components: Library (Lib)
messages: 253542
nosy: wozlaf
priority: normal
severity: normal
status: open
title: ftplib.sendcmd only accepts string
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Oct 27 11:33:14 2015
From: report at bugs.python.org (George Prekas)
Date: Tue, 27 Oct 2015 15:33:14 +0000
Subject: [New-bugs-announce] [issue25492] subprocess with redirection fails
 after FreeConsole
Message-ID: <1445959994.99.0.328533880523.issue25492@psf.upfronthosting.co.za>


New submission from George Prekas:

Under Windows, if I do FreeConsole and then subprocess.call with redirected stdin or stdout or stderr, then subprocess.call fails. The only solution is either DO NOT redirect any handle OR to redirect ALL of them. The problem lies in function _get_handles at subprocess.py:810 (Python 2.7.10), which does:
* GetStdHandle
* DuplicateHandle via _make_inheritable.

DuplicateHandle fails if called on stdin, stdout or stderr after FreeConsole.

$ cygstart /mnt/c/utils/Python35/python.exe testcase.py fails
$ cygstart /mnt/c/utils/Python35/python.exe testcase.py works1
$ cygstart /mnt/c/utils/Python35/python.exe testcase.py works2
$ cygstart /mnt/c/utils/Python35/python.exe testcase.py works3

----------
components: Library (Lib)
files: testcase.py
messages: 253547
nosy: George Prekas
priority: normal
severity: normal
status: open
title: subprocess with redirection fails after FreeConsole
type: behavior
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file40868/testcase.py

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

From report at bugs.python.org  Tue Oct 27 12:46:01 2015
From: report at bugs.python.org (=?utf-8?q?Michael_La=C3=9F?=)
Date: Tue, 27 Oct 2015 16:46:01 +0000
Subject: [New-bugs-announce] [issue25493] warnings.warn: wrong stacklevel
 causes import of local file "sys"
Message-ID: <1445964361.88.0.406365225673.issue25493@psf.upfronthosting.co.za>


New submission from Michael La?:

When there is a file called "sys" in the local directory of a python script and warning.warn is called with an invalid stacklevel, python tries to import that file and throws an error like the following:

>>> import warnings
>>> warnings.warn("foo", Warning, stacklevel=2)
Traceback (most recent call last):
  File "/usr/lib/python3.5/tokenize.py", line 392, in find_cookie
    line_string = line.decode('utf-8')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 24: invalid start byte

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.5/warnings.py", line 18, in showwarning
    file.write(formatwarning(message, category, filename, lineno, line))
  File "/usr/lib/python3.5/warnings.py", line 26, in formatwarning
    line = linecache.getline(filename, lineno) if line is None else line
  File "/usr/lib/python3.5/linecache.py", line 16, in getline
    lines = getlines(filename, module_globals)
  File "/usr/lib/python3.5/linecache.py", line 47, in getlines
    return updatecache(filename, module_globals)
  File "/usr/lib/python3.5/linecache.py", line 136, in updatecache
    with tokenize.open(fullname) as fp:
  File "/usr/lib/python3.5/tokenize.py", line 456, in open
    encoding, lines = detect_encoding(buffer.readline)
  File "/usr/lib/python3.5/tokenize.py", line 433, in detect_encoding
    encoding = find_cookie(first)
  File "/usr/lib/python3.5/tokenize.py", line 397, in find_cookie
    raise SyntaxError(msg)
SyntaxError: invalid or missing encoding declaration for 'sys'

In this case "sys" is a binary that belongs to openafs (/usr/bin/sys) and of course it is no valid python.

"import sys" produces no error though, so typically python is able to distinguish between its sys module and this file.

A workaround is to run python with the "-I" parameter.

Expected output:

>>> import warnings
>>> warnings.warn("foo", Warning, stacklevel=2)
sys:1: Warning: foo

This bug was spotted in Gnome's pygobject bindings. Here is the corresponding bug report:
https://bugzilla.gnome.org/show_bug.cgi?id=757184

----------
components: Interpreter Core
messages: 253551
nosy: bevan-bi-co
priority: normal
severity: normal
status: open
title: warnings.warn: wrong stacklevel causes import of local file "sys"
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Oct 27 17:48:58 2015
From: report at bugs.python.org (John Mark Vandenberg)
Date: Tue, 27 Oct 2015 21:48:58 +0000
Subject: [New-bugs-announce] [issue25494] Four quotes used to begin docstring
Message-ID: <1445982538.24.0.273551712863.issue25494@psf.upfronthosting.co.za>


New submission from John Mark Vandenberg:

Introduced in the initial version of statistics was """" starting a docstring

https://hg.python.org/cpython/annotate/685e044bed5e/Lib/statistics.py#l380

Somewhere the fourth quote is dropped, as it doesnt appear in the docs:

https://docs.python.org/3/library/statistics.html#statistics.median_grouped

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: cpython-statistics.patch
keywords: patch
messages: 253568
nosy: John.Mark.Vandenberg, docs at python
priority: normal
severity: normal
status: open
title: Four quotes used to begin docstring
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40871/cpython-statistics.patch

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

From report at bugs.python.org  Tue Oct 27 19:10:17 2015
From: report at bugs.python.org (Mouse)
Date: Tue, 27 Oct 2015 23:10:17 +0000
Subject: [New-bugs-announce] [issue25495] binascii documentation incorrect
Message-ID: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>


New submission from Mouse:

binascii b2a_base64() documentation says:

The length of data should be at most 57 to adhere to the base64 standard.

This is incorrect, because there is no base64 standard that restricts the length of input data, especially to such a small value.

What RFC4648 (that superseded RFC3548 that your documentation still keeps referring to) actually says is that MIME enforces the limit ofthe OUTPUT LINE length at 76, but NOT of the entire output, and certainly not of the entire input.

Please correct the documentation, making it conformant with what the ACTUAL base64 standard says.

See https://en.wikipedia.org/wiki/Base64 and
https://tools.ietf.org/html/rfc4648

Thanks!

----------
assignee: docs at python
components: Documentation
messages: 253572
nosy: docs at python, mouse07410
priority: normal
severity: normal
status: open
title: binascii documentation incorrect
versions: Python 3.5

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

From report at bugs.python.org  Wed Oct 28 04:39:27 2015
From: report at bugs.python.org (Sworddragon)
Date: Wed, 28 Oct 2015 08:39:27 +0000
Subject: [New-bugs-announce] [issue25496] Default value for compresslevel is
 not documented
Message-ID: <1446021567.06.0.820338275323.issue25496@psf.upfronthosting.co.za>


New submission from Sworddragon:

After ticket #21404 got solved I'm noticing that the default value for the compresslevel argument is not mentioned. Maybe this can be documented too.

----------
components: Library (Lib)
messages: 253592
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Default value for compresslevel is not documented
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Oct 28 10:05:50 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 28 Oct 2015 14:05:50 +0000
Subject: [New-bugs-announce] [issue25497] Rewrite test_robotparser
Message-ID: <1446041150.72.0.906837091061.issue25497@psf.upfronthosting.co.za>


New submission from Berker Peksag:

The attached patch rewrites test_robotparser to use a class based approach.

Other changes:

* Added support.reap_threads to PasswordProtectedSiteTestCase
* Reenabled testPythonOrg since the python.org problem has already been fixed

----------
components: Tests
files: test_robotparser.diff
keywords: patch
messages: 253599
nosy: berker.peksag
priority: normal
severity: normal
stage: patch review
status: open
title: Rewrite test_robotparser
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40875/test_robotparser.diff

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

From report at bugs.python.org  Wed Oct 28 14:06:12 2015
From: report at bugs.python.org (Jake Montgomery)
Date: Wed, 28 Oct 2015 18:06:12 +0000
Subject: [New-bugs-announce] [issue25498] Python 3.4.3 core dump with simple
 sample code
Message-ID: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za>


New submission from Jake Montgomery:

We are seeing a consistent "invalid memory access" crash in Python3.4.3. 

*Test setup* 
This is occurring on Ubuntu 14.04.1 LTS. It is occurring on multiple unrelated installs, but has not been tested with any other operating system. It occurs using the "Python 3.4.3 (default, Oct 14 2015, 20:28:29)" that is installed using apt-get. It does *not* appear to occur using Python 3.4.0. Other versions of python were not tested. 

*Reproducing*
I was able to reduce the code needed to a pretty minimal python program, which is attached. Running this as "pyton3 ./pythoncrash.py" will trigger the crash, and a core dump if enabled. 

If run under python3.4.3-dbg The error is:

    python3.4-dbg: ../Objects/memoryobject.c:115: mbuf_dealloc: Assertion `self->exports == 0' failed.

In some versions of this code, it had to be run twice, since it would only occur when the pyc files were already created. The attached version does not appear to have this behavior, but run it twice, at least, if you do not see the crash. 

The code supplied is "minimal", in that removing any line will cause the crash not to occur.

*More clues*
I suspect that the key is the multiprocessing.Value object, and its destruction. The other "import" statements may just be happenstance needed to create the correct memory conditions for the crash. I was able to start "stubbing out" the actual code in those imported packages, and the crash continued as long as the number of functions, classes, and class dependencies were maintained. But that became too tedious. In earlier versions of the test code, adding or removing significant numbers of function or classes could make the crash not manifest. 

*Stack trace*
Running under python3.4.3-dbg, gdb gives the following stack trace:

#0  0x00007fc0425b4cc9 in __GI_raise (sig=sig at entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007fc0425b80d8 in __GI_abort () at abort.c:89
#2  0x00007fc0425adb86 in __assert_fail_base (
    fmt=0x7fc0426fe830 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
    assertion=assertion at entry=0x707199 "self->exports == 0",
    file=file at entry=0x70715a "../Objects/memoryobject.c", line=line at entry=115,
    function=function at entry=0x708923 <__PRETTY_FUNCTION__.10355> "mbuf_dealloc") at assert.c:92
#3  0x00007fc0425adc32 in __GI___assert_fail (assertion=0x707199 "self->exports == 0",
    file=0x70715a "../Objects/memoryobject.c", line=115,
    function=0x708923 <__PRETTY_FUNCTION__.10355> "mbuf_dealloc") at assert.c:101
#4  0x00000000004beb92 in mbuf_dealloc (self=0x7fc042068058) at ../Objects/memoryobject.c:115
#5  0x00000000004cd67b in _Py_Dealloc (op=<managedbuffer at remote 0x7fc042068058>)
    at ../Objects/object.c:1749
#6  0x00000000004c0ec6 in memory_clear (self=0x7fc042026bf8) at ../Objects/memoryobject.c:1079
#7  0x00000000004409c3 in delete_garbage (collectable=0x7fff21065180,
    old=0x9a4f40 <generations+64>) at ../Modules/gcmodule.c:866
#8  0x0000000000440f56 in collect (generation=2, n_collected=0x7fff210651e8,
    n_uncollectable=0x7fff210651f0, nofail=0) at ../Modules/gcmodule.c:1032
#9  0x000000000044144e in collect_with_callback (generation=2) at ../Modules/gcmodule.c:1140
#10 0x00000000004421f2 in PyGC_Collect () at ../Modules/gcmodule.c:1616
#11 0x00000000004226a0 in Py_Finalize () at ../Python/pythonrun.c:607
#12 0x0000000000428f38 in Py_Exit (sts=0) at ../Python/pythonrun.c:2713
#13 0x0000000000426077 in handle_system_exit () at ../Python/pythonrun.c:1812
#14 0x00000000004260a2 in PyErr_PrintEx (set_sys_last_vars=1) at ../Python/pythonrun.c:1822
#15 0x0000000000425cef in PyErr_Print () at ../Python/pythonrun.c:1718
#16 0x00000000004255c4 in PyRun_SimpleFileExFlags (fp=0x29824c0,
    filename=0x7fc042442b68 "./pythoncrash.py", closeit=1, flags=0x7fff21065520)
    at ../Python/pythonrun.c:1611
#17 0x0000000000424418 in PyRun_AnyFileExFlags (fp=0x29824c0,
    filename=0x7fc042442b68 "./pythoncrash.py", closeit=1, flags=0x7fff21065520)
    at ../Python/pythonrun.c:1292
#18 0x000000000043e9fb in run_file (fp=0x29824c0, filename=0x28b62f0 L"./pythoncrash.py",
    p_cf=0x7fff21065520) at ../Modules/main.c:319
#19 0x000000000043f781 in Py_Main (argc=2, argv=0x28b5020) at ../Modules/main.c:751
#20 0x000000000041e6d6 in main (argc=2, argv=0x7fff21065798) at ../Modules/python.c:69

The full core dump is available, if it would help.

----------
components: Interpreter Core
files: pythoncrash.py
messages: 253613
nosy: JakeMont
priority: normal
severity: normal
status: open
title: Python 3.4.3 core dump with simple sample code
versions: Python 3.4
Added file: http://bugs.python.org/file40876/pythoncrash.py

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

From report at bugs.python.org  Wed Oct 28 15:39:01 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 28 Oct 2015 19:39:01 +0000
Subject: [New-bugs-announce] [issue25499] use argparse for the calendar
 module
Message-ID: <1446061141.61.0.20686802528.issue25499@psf.upfronthosting.co.za>


New submission from St?phane Wirtel:

optparse is marked as deprecated. 

I have moved argparse for the calendar module.

Need reviews.

----------
components: Library (Lib)
files: calendar_move_to_argparse.patch
keywords: patch
messages: 253619
nosy: matrixise
priority: normal
severity: normal
status: open
title: use argparse for the calendar module
versions: Python 3.6
Added file: http://bugs.python.org/file40877/calendar_move_to_argparse.patch

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

From report at bugs.python.org  Wed Oct 28 17:34:44 2015
From: report at bugs.python.org (Sergei Lebedev)
Date: Wed, 28 Oct 2015 21:34:44 +0000
Subject: [New-bugs-announce] [issue25500] _find_and_load_unlocked doesn't
 always use __import__
Message-ID: <1446068084.58.0.390651859443.issue25500@psf.upfronthosting.co.za>


New submission from Sergei Lebedev:

According to the current import system documentation

> When calling ``__import__()`` as part of an import statement, the import system first checks the module global namespace for a function by that name. If it is not found, then the standard builtin ``__import__()`` is called.

However, one can easily verify this isn't (always) the case::

    import sys

    assert "glob" not in sys.modules
    __import__ = print
   
    import glob  # Doesn't print anything.

I've traced the import statement from ``ceval.c`` to the frozen ``importlib._bootstrap`` and it seems the cause of the problem is in ``_find_and_load_unlocked``, which simply ignores the ``_import`` argument in the case above::

    def _find_and_load_unlocked(name, import_):
        path = None
        # ... parent processing ...
        spec = _find_spec(name, path)
        if spec is None:
            raise ImportError(_ERR_MSG.format(name), name=name)
        else:
            # XXX import_ is not used.
            module = _SpecMethods(spec)._load_unlocked()
        # ... more parent processing ...
        return module

I'm not sure if this is a bug in the documentation or implementation, so any feedback is appreciated.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 253635
nosy: docs at python, superbobry
priority: normal
severity: normal
status: open
title: _find_and_load_unlocked doesn't always use __import__
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Oct 28 18:30:53 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 28 Oct 2015 22:30:53 +0000
Subject: [New-bugs-announce] [issue25501] Use async/await through asyncio
 docs
Message-ID: <1446071453.74.0.752401915255.issue25501@psf.upfronthosting.co.za>


New submission from Brett Cannon:

The asyncio docs still use `yield from` and @asyncio.coroutine all over the place instead of async/await. It would be best to update the docs to follow best practices (unless there is some reason I can't think of as to why this hasn't happened yet).

----------
assignee: docs at python
components: Documentation
messages: 253636
nosy: brett.cannon, docs at python, giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: Use async/await through asyncio docs
versions: Python 3.6

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

From report at bugs.python.org  Wed Oct 28 21:55:45 2015
From: report at bugs.python.org (John Mark Vandenberg)
Date: Thu, 29 Oct 2015 01:55:45 +0000
Subject: [New-bugs-announce] [issue25502] unnecessary re-imports
Message-ID: <1446083745.57.0.702787363915.issue25502@psf.upfronthosting.co.za>


New submission from John Mark Vandenberg:

The following four modules re-import another module unnecessarily as it is already imported in the global scope.

Lib/getpass.py : msvcrt
Lib/pickletools.py : sys
Lib/smtplib.py : sys
PC/testpy.py : os

In each case, the import being removed in the attached patch existed in the source code before the import which now occurs first.  i.e. an import was added and the same import elsewhere in the module was not removed.

----------
components: Library (Lib)
files: re-imports.diff
keywords: patch
messages: 253651
nosy: John.Mark.Vandenberg
priority: normal
severity: normal
status: open
title: unnecessary re-imports
versions: Python 3.6
Added file: http://bugs.python.org/file40882/re-imports.diff

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

From report at bugs.python.org  Thu Oct 29 00:53:40 2015
From: report at bugs.python.org (John Mark Vandenberg)
Date: Thu, 29 Oct 2015 04:53:40 +0000
Subject: [New-bugs-announce] [issue25503] inspect.getdoc does find inherited
 property __doc__
Message-ID: <1446094420.64.0.595919822106.issue25503@psf.upfronthosting.co.za>


New submission from John Mark Vandenberg:

inspect.getdoc's helper _finddoc raises an AttributeError on encountering a property, which is silently discarded.

>>> class Foo(object):
...     @property
...     def foo(self):
...         """foobar."""
...         return 'foo'
... 
>>> class Bar(Foo):
...     @property
...     def foo(self):
...         return 'bar'
... 
>>> import inspect
>>> inspect.getdoc(Foo.foo)
'foobar.'
>>> inspect.getdoc(Bar.foo)
>>>

How I came upon this was doing static code analysis, and the f.fget on line 522 here looks very wrong.

http://bugs.python.org/review/15582/diff/14140/Lib/inspect.py

This code dedicated to supporting `property` does not work because of that, but also because a property is also a data descriptor so the 'property' branch is never executed.

>>> inspect.isdatadescriptor(property())
True

----------
components: Library (Lib)
files: getdoc-property.diff
keywords: patch
messages: 253653
nosy: John.Mark.Vandenberg
priority: normal
severity: normal
status: open
title: inspect.getdoc does find inherited property __doc__
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40885/getdoc-property.diff

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

From report at bugs.python.org  Thu Oct 29 02:00:38 2015
From: report at bugs.python.org (John Mark Vandenberg)
Date: Thu, 29 Oct 2015 06:00:38 +0000
Subject: [New-bugs-announce] [issue25504] undefined name 'modules' in
 Tools/freeze/checkextensions_win32.py
Message-ID: <1446098438.41.0.333583396079.issue25504@psf.upfronthosting.co.za>


New submission from John Mark Vandenberg:

All versions of Tools/freeze/checkextensions_win32.py have had an error due to accessing 'modules.sourceFiles' instead of 'module.sourceFiles'.

https://hg.python.org/cpython/diff/8e9d5e5103f5/Tools/freeze/checkextensions_win32.py#l1.96

Presumably there is something which makes this block of code rather infrequently used.

----------
components: Demos and Tools
files: checkextensions_win32.diff
keywords: patch
messages: 253656
nosy: John.Mark.Vandenberg, mhammond
priority: normal
severity: normal
status: open
title: undefined name 'modules' in Tools/freeze/checkextensions_win32.py
type: crash
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40887/checkextensions_win32.diff

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

From report at bugs.python.org  Thu Oct 29 02:37:50 2015
From: report at bugs.python.org (John Mark Vandenberg)
Date: Thu, 29 Oct 2015 06:37:50 +0000
Subject: [New-bugs-announce] [issue25505] undefined name 'window' in
 Tools/scripts/fixdiv.py
Message-ID: <1446100670.6.0.312090653047.issue25505@psf.upfronthosting.co.za>


New submission from John Mark Vandenberg:

Tools/scripts/fixdiv.py 's `FileContext.truncate` has used `window` since it was created, when it is supposed to use self.window.

https://hg.python.org/cpython/annotate/60f290a7eae8/Tools/scripts/fixdiv.py#l195

`truncate` is unused, so an alternative fix is to remove it, as it has never worked, and nobody has complained.

----------
components: Demos and Tools
files: fixdiv.diff
keywords: patch
messages: 253661
nosy: John.Mark.Vandenberg
priority: normal
severity: normal
status: open
title: undefined name 'window' in Tools/scripts/fixdiv.py
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40888/fixdiv.diff

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

From report at bugs.python.org  Thu Oct 29 03:25:35 2015
From: report at bugs.python.org (John Mark Vandenberg)
Date: Thu, 29 Oct 2015 07:25:35 +0000
Subject: [New-bugs-announce] [issue25506] test_pprint reuses test_user_dict
Message-ID: <1446103535.53.0.629816252417.issue25506@psf.upfronthosting.co.za>


New submission from John Mark Vandenberg:

test_pprint defined test_user_dict twice, once for UserDict, and the second for UserList.

----------
components: Library (Lib), Tests
files: test_pprint-fix.diff
keywords: patch
messages: 253663
nosy: John.Mark.Vandenberg, serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_pprint reuses test_user_dict
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40891/test_pprint-fix.diff

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

From report at bugs.python.org  Thu Oct 29 06:10:42 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Oct 2015 10:10:42 +0000
Subject: [New-bugs-announce] [issue25507] IDLE: user code 'import tkinter;
 tkinter.font' should fail
Message-ID: <1446113442.78.0.389498275803.issue25507@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

In python, 'import tkinter; tkinter.font' fails with AttributeError.  In IDLE, it does not, which is a bug,  This lead to a Stackoverflow question 'Why does my code run in IDLE but not with Python'?

The issue is that importing modules in a package has the side-effect of adding the module name to the package namespace.  IDLE's user process runs idlelib/run.py.  While *run* does not import tkinter submodules, it imports other modules that do, and the net effect is to add colorchooser, commondialog, dialog, filedialog, font, messagebox, and simpledialog to the tkinter namespace, linked to the corresponding module objects.  None are needed in normal operation.

My first thought was to refactor so that the additions, which run does not need, are not added.  My second thought seemed simpler.  Delete them (in run.py) after the imports.  But it turns out that after deleting a submodule attribute re-import does not work right; the name addition only happens when a module is created, not when found in the sys.modules cache.

>>> import tkinter; import tkinter.font  # imagine this in run.py
>>> tkinter.font
<module tkinter.font...>
>>> del tkinter.font  # and this in run also, after all imports
>>> import tkinter.font  # imagine this in user code
>>> tkinter.font  # and then this
Traceback (most recent call last):  # it does not work as it should
  File "<stdin>", line 1, in <module>
AttributeError: module 'tkinter' has no attribute 'font'

Scratch that idea, and return to refactoring.  An obvious culprit in run.py is the import of PyShell.  This leads to the import of nearly all of idlelib.  However, there are only 4 shared objects actually used, and I believe they could just as well be defined in run (or even in rpc.py or something) and imported from run into PyShell.  Then the PyShell import could be deleted.  I still need to look at the other imports.

On startup, user sys.modules also has about 50 other (non-idlelib) stdlib modules not imported by python itself.  Not importing PyShell in the 2nd process should reduce this number and speed up IDLE startup, which takes several seconds, first time after boot up, on Windows.  It would be good to only import into the user process what is actually needed.

(Initially importing into the idle process only what is needed to start would also be good, but a separate issue.)

In 2.7, Tkinter is not a package, so I do not believe it is directly affected by this issue.  On the other hand, it also imports too much.  So backporting changes to keep things mostly synchronized should benefit 2.7 startup time also.

----------
messages: 253671
nosy: markroseman, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: user code 'import tkinter; tkinter.font' should fail
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Oct 29 06:22:02 2015
From: report at bugs.python.org (Ondrej Sejvl)
Date: Thu, 29 Oct 2015 10:22:02 +0000
Subject: [New-bugs-announce] [issue25508] LogRecord attributes are not tuple,
 when logging only dict
Message-ID: <1446114122.71.0.187409652652.issue25508@psf.upfronthosting.co.za>


New submission from Ondrej Sejvl:

Hi,

in doc https://docs.python.org/3.4/library/logging.html#logrecord-attributes there is
args 	You shouldn?t need to format this yourself. 	The tuple of arguments merged into msg to produce message.

But when I log message with 1 arg - a dict - in record.args will be this dict

```
import logging

class H(logging.Handler):
    def emit(self, record):
        print(record.args, type(record.args))

lgr = logging.getLogger()
lgr.addHandler(H())
lgr.error("msg", 1)
lgr.error("msg", dict(a=1))
lgr.error("msg", dict(a=1), 2)
```
output:
```
(1,) <class 'tuple'>
{'a': 1} <class 'dict'>
({'a': 1}, 2) <class 'tuple'>
```

----------
messages: 253673
nosy: sejvlond
priority: normal
severity: normal
status: open
title: LogRecord attributes are not tuple, when logging only dict
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Thu Oct 29 08:06:44 2015
From: report at bugs.python.org (Memeplex)
Date: Thu, 29 Oct 2015 12:06:44 +0000
Subject: [New-bugs-announce] [issue25509] PyImport_ImportModule inaccurately
 described
Message-ID: <1446120404.56.0.248022316134.issue25509@psf.upfronthosting.co.za>


New submission from Memeplex:

The documentation (for 3.5) states that "[PyImport_ImportModule] is a simplified interface to PyImport_ImportModuleEx()" but the current implementation calls PyImport_Import instead, which is a higher level interface that takes into account import hooks. Older versions of PyImport_ImportModule (say 2.0) did call PyImport_ImportModuleEx, but that's no longer the case.

The PyImport_Import* naming convention got a bit messy with the years and maybe I'm not understanding the intention quite well, but it seems to me that the documentation is outdated and that there is a change in semantics for PyImport_ImportModule.

----------
assignee: docs at python
components: Documentation
messages: 253674
nosy: docs at python, memeplex
priority: normal
severity: normal
status: open
title: PyImport_ImportModule inaccurately described
versions: Python 3.5

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

From report at bugs.python.org  Thu Oct 29 10:12:19 2015
From: report at bugs.python.org (Ryosuke Ito)
Date: Thu, 29 Oct 2015 14:12:19 +0000
Subject: [New-bugs-announce] [issue25510] fileinput.FileInput.readline()
 always returns str object at the end even if in 'rb' mode
Message-ID: <1446127939.75.0.173725539565.issue25510@psf.upfronthosting.co.za>


New submission from Ryosuke Ito:

In Python3, fileinput.FileInput.readline() always returns str object at the end,
even if in 'rb' mode.
Here's a test code.

import fileinput

fi = fileinput.input('test_fileinput.py', mode='rb')

while True:
    line = fi.readline()
    assert isinstance(line, bytes)
    if not len(line):
        break

It fails in Python3.2 to 3.5.

I wrote a patch for this.
With it, the test above passes.

----------
files: fileinput.py.diff
keywords: patch
messages: 253675
nosy: Ryosuke Ito
priority: normal
severity: normal
status: open
title: fileinput.FileInput.readline() always returns str object at the end even if in 'rb' mode
Added file: http://bugs.python.org/file40895/fileinput.py.diff

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

From report at bugs.python.org  Thu Oct 29 11:28:51 2015
From: report at bugs.python.org (David Jones)
Date: Thu, 29 Oct 2015 15:28:51 +0000
Subject: [New-bugs-announce] [issue25511] multiprocessing pool blocks
 SIGTERM from being handled
Message-ID: <1446132531.63.0.0289004562765.issue25511@psf.upfronthosting.co.za>


New submission from David Jones:

This is probably related to #21913, but more specifically concerns the documentation. I have a sub process of a larger program that handles a SIGTERM sent by the main process for a clean shutdown. However, if I launch a parallel task in the sub process, via multiprocessing.Pool.imap_unordered, all signals are blocked until pool finishes running the task. 

If this isn't going to be fixed, then it ought to at least be clearly documented. It took a very long time to diagnose this problem. It requires a programmer to understand the underlying implementation of a high-level construct, thus defeating the purpose of using a high level construct.

Also, is there a way to work around this?

----------
assignee: docs at python
components: Documentation
messages: 253678
nosy: djones, docs at python
priority: normal
severity: normal
status: open
title: multiprocessing pool blocks SIGTERM from being handled
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct 29 15:16:36 2015
From: report at bugs.python.org (Martin Smith)
Date: Thu, 29 Oct 2015 19:16:36 +0000
Subject: [New-bugs-announce] [issue25512] apparent memory leak using ctypes
Message-ID: <1446146196.34.0.00289106474644.issue25512@psf.upfronthosting.co.za>


New submission from Martin Smith:

Attached file demonstrates a memory leak arising in ctypes (I think).  Leak occurs in both 2.7 and 3.5, though at different rates.

Humble apologies if I've screwed up somewhere.  Very nervous about submitting this.

----------
components: ctypes
files: ctype_stressor.py
messages: 253688
nosy: blindgoat
priority: normal
severity: normal
status: open
title: apparent memory leak using ctypes
type: resource usage
versions: Python 3.5
Added file: http://bugs.python.org/file40896/ctype_stressor.py

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

From report at bugs.python.org  Thu Oct 29 15:38:24 2015
From: report at bugs.python.org (yoch)
Date: Thu, 29 Oct 2015 19:38:24 +0000
Subject: [New-bugs-announce] [issue25513] collections.abc.Iterable don't
 implement __bool__
Message-ID: <1446147504.48.0.238943227833.issue25513@psf.upfronthosting.co.za>


New submission from yoch:

collections.abc.Iterable don't implement the __bool__ method. This may seriously degrade performance in case __len__ is not efficient.

I suggest to implement it as :

class Iterable:
    ...
    def __bool__(self):
        try:
            next(iter(self))
            return True
        except StopIteration:
            return False

----------
components: Library (Lib)
messages: 253690
nosy: yoch.melka
priority: normal
severity: normal
status: open
title: collections.abc.Iterable don't implement __bool__
type: enhancement

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

From report at bugs.python.org  Thu Oct 29 16:47:20 2015
From: report at bugs.python.org (Mark Roseman)
Date: Thu, 29 Oct 2015 20:47:20 +0000
Subject: [New-bugs-announce] [issue25514] better startup error messages in
 IDLE when stdlib modules shadowed
Message-ID: <1446151640.74.0.583734209916.issue25514@psf.upfronthosting.co.za>


New submission from Mark Roseman:

When we create e.g. string.py that shadows a stdlib module needed by IDLE, it would be nice if a better error message could be shown, pointing to that cause.

Original message:

lac at smartwheels:~/junk$ echo "print ('hello there')" >string.py
lac at smartwheels:~/junk$ idle-python3.5
hello there
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.5/idlelib/run.py", line 10, in <module>
    from idlelib import CallTips
  File "/usr/lib/python3.5/idlelib/CallTips.py", line 16, in <module>
    from idlelib.HyperParser import HyperParser
  File "/usr/lib/python3.5/idlelib/HyperParser.py", line 14, in <module>
    _ASCII_ID_CHARS = frozenset(string.ascii_letters + string.digits + "_")
AttributeError: module 'string' has no attribute 'ascii_letters'

IDLE then produces a popup that says:

IDLE's subprocess didn't make connection.  Either IDLE can't stat a subprocess por personal firewall software is blocking the connection. <ok>

--------

I think that life would be a whole lot easier for people if instead we got
a message:

Warning: local file /u/lac/junk/string.py shadows module named string in the 
Standard Library

I think that it is python exec that would have to do this -- though of
course the popup could also warn about shadowing in general, instead of
sending people on wild goose chases over their firewalls.

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

Laura, I think what you want should actually be more-or-less doable in IDLE.

The main routine that starts IDLE should be able to detect if it starts correctly (something unlikely to happen if a significant stdlib module is shadowed), watch for an attribute error of that form and try to determine if shadowing is the cause, and if so, reissue a saner error message.

The subprocess/firewall error is occurring because the ?string? problem in your example isn?t being hit right away so a few startup things already are happening. The point where we?re showing that error (as a result of a timeout) should be able to check as per the above that IDLE was able to start alright, and if not, change or ignore the timeout error.

There?ll probably be some cases (depending on exactly what gets shadowed) that may be difficult to get to work, but it should be able to handle most things.


See full thread starting at https://mail.python.org/pipermail/python-dev/2015-October/142061.html

----------
components: IDLE
messages: 253693
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: better startup error messages in IDLE when stdlib modules shadowed
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Oct 29 18:30:56 2015
From: report at bugs.python.org (Alex Gaynor)
Date: Thu, 29 Oct 2015 22:30:56 +0000
Subject: [New-bugs-announce] [issue25515] Always use os.urandom for
 generating uuid4s
Message-ID: <1446157856.8.0.141271153447.issue25515@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

Right now uuid4 can be implemented one of 3 ways:

- If there's a libuuid (and it's not OS X's) it uses that.
- Fallback to os.urandom
- If that raises an exception, fall back to the random module

I propose to simplify this to _just_ use os.urandom always. Reasons:

- Its security properties are more obviously correct. (There's a large comment in uuid.py about how libuuid doees the wrong thing with fork on OS X, who knows if it's correct on other platforms)
- It's simpler.
- It's faster:

a_gaynor at miranda:~$ python -mtimeit -s "import uuid; import os; import ctypes" "_buffer = ctypes.create_string_buffer(16); uuid._uuid_generate_random(_buffer); bytes(_buffer.raw)"
100000 loops, best of 3: 10 usec per loop
a_gaynor at miranda:~$ python -mtimeit -s "import uuid; import os; import ctypes" "_buffer = ctypes.create_string_buffer(16); uuid._uuid_generate_random(_buffer); bytes(_buffer.raw)"
100000 loops, best of 3: 10.3 usec per loop
a_gaynor at miranda:~$ python -mtimeit -s "import uuid; import os; import ctypes" "_buffer = ctypes.create_string_buffer(16); uuid._uuid_generate_random(_buffer); bytes(_buffer.raw)"
100000 loops, best of 3: 9.99 usec per loop
a_gaynor at miranda:~$ python -mtimeit -s "import uuid; import os; import ctypes" "_buffer = ctypes.create_string_buffer(16); uuid._uuid_generate_random(_buffer); bytes(_buffer.raw)"
100000 loops, best of 3: 10.2 usec per loop
a_gaynor at miranda:~$ python -mtimeit -s "import uuid; import os; import ctypes" "_buffer = ctypes.create_string_buffer(16); uuid._uuid_generate_random(_buffer); bytes(_buffer.raw)"
100000 loops, best of 3: 10.2 usec per loop
a_gaynor at miranda:~$
a_gaynor at miranda:~$
a_gaynor at miranda:~$
a_gaynor at miranda:~$
a_gaynor at miranda:~$ python -mtimeit -s "import uuid; import os; import ctypes" "os.urandom(16)"
100000 loops, best of 3: 8.94 usec per loop
a_gaynor at miranda:~$ python -mtimeit -s "import uuid; import os; import ctypes" "os.urandom(16)"
100000 loops, best of 3: 8.92 usec per loop
a_gaynor at miranda:~$ python -mtimeit -s "import uuid; import os; import ctypes" "os.urandom(16)"
100000 loops, best of 3: 8.97 usec per loop
a_gaynor at miranda:~$ python -mtimeit -s "import uuid; import os; import ctypes" "os.urandom(16)"
100000 loops, best of 3: 8.93 usec per loop
a_gaynor at miranda:~$ python -mtimeit -s "import uuid; import os; import ctypes" "os.urandom(16)"
100000 loops, best of 3: 8.94 usec per loop
a_gaynor at miranda:~$
a_gaynor at miranda:~$
a_gaynor at miranda:~$ python --version
Python 2.7.3

----------
components: Library (Lib)
files: uuid.diff
keywords: needs review, patch
messages: 253697
nosy: alex, dstufft
priority: normal
severity: normal
status: open
title: Always use os.urandom for generating uuid4s
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40899/uuid.diff

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

From report at bugs.python.org  Thu Oct 29 20:36:32 2015
From: report at bugs.python.org (Nir Soffer)
Date: Fri, 30 Oct 2015 00:36:32 +0000
Subject: [New-bugs-announce] [issue25516] threading.Condition._is_owned() is
 wrong when using threading.Lock
Message-ID: <1446165392.31.0.717642417411.issue25516@psf.upfronthosting.co.za>


New submission from Nir Soffer:

When using threading.Lock, threading.Condition._is_owned is assuming that the calling thread is owning the condition lock if the lock cannot be acquired. This check is completely wrong if another thread owns the lock.

>>> cond = threading.Condition(threading.Lock())
>>> threading.Thread(target=cond.acquire).start()
>>> cond._is_owned()
True
>>> cond.notify()
>>> cond.wait(0)
False

Careful users that acquire the condition before calling wait() or notify() are not effected. Careless users that should have been warned by RuntimeError are.

Tested on Python 2.7 and 3.4.2 and 3.6.0a0.

----------
components: Library (Lib)
messages: 253703
nosy: nirs
priority: normal
severity: normal
status: open
title: threading.Condition._is_owned() is wrong when using threading.Lock
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/issue25516>
_______________________________________

From report at bugs.python.org  Fri Oct 30 06:07:26 2015
From: report at bugs.python.org (Pavel)
Date: Fri, 30 Oct 2015 10:07:26 +0000
Subject: [New-bugs-announce] [issue25517] regex howto example in "Lookahead
 Assertions"
Message-ID: <1446199646.71.0.249231376897.issue25517@psf.upfronthosting.co.za>


New submission from Pavel:

The example advises ".*[.](?!bat$).*$" expression "to match filenames where the extension is not bat". But here is an example which passes such check:

>>> re.match("(.*)[.](?!bat$).*$", "test.a.bat")
<_sre.SRE_Match object at 0x7ff221996f30>

To my mind use of negative lookbehind expressions (not covered so far in the HOWTO) is better:

>>> re.match("(.*)[.].*(?<!.bat)$", "test.a.bat")
>>>

----------
assignee: docs at python
components: Documentation
messages: 253725
nosy: Pavel, docs at python
priority: normal
severity: normal
status: open
title: regex howto example in "Lookahead Assertions"
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/issue25517>
_______________________________________

From report at bugs.python.org  Fri Oct 30 12:12:03 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 30 Oct 2015 16:12:03 +0000
Subject: [New-bugs-announce] [issue25518] Investigate implementation of
 PyOS_CheckStack on OSX
Message-ID: <1446221523.82.0.826583812688.issue25518@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

On OSX 10.4 or later the following functions are available:

size_t pthread_get_stacksize_np(pthread_t);
void* pthread_get_stackaddr_np(pthread_t);

These functions could be used to implement PyOS_CheckStack on OSX. The advantage of this would be that it would get less likely that recursion causes hard crashes when the recursion limit is not optimally tuned to the stack size on OSX. (Note that OSX has a fixed size stack for the main thread as well, AFAIK unlike linux).

The disadvantage of implementing this is that a naive implementation might have a negative performance impact. It should be possible to avoid this by caching the return values of these functions in the thread state.

Another disadvantage according to a quick search on Google: ``pthread_get_stacksize_np`` appears to be buggy on some OSX versions, which requires workarounds to get the right behavior.

----------
components: Interpreter Core, Macintosh
messages: 253742
nosy: ned.deily, ronaldoussoren
priority: low
severity: normal
stage: test needed
status: open
title: Investigate implementation of PyOS_CheckStack on OSX
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Oct 30 12:21:40 2015
From: report at bugs.python.org (Andrew Scheller)
Date: Fri, 30 Oct 2015 16:21:40 +0000
Subject: [New-bugs-announce] [issue25519] Minor difflib documentation bug
Message-ID: <1446222100.88.0.105008703897.issue25519@psf.upfronthosting.co.za>


New submission from Andrew Scheller:

In the documentation for difflib.HtmlDiff.__init__ there's a couple of references to ``ndiff()``. I believe these should be modified to :func:`ndiff` (as used elsewhere in the difflib documentation) so that they get nicely hyperlinked in the HTML documentation.

See e.g. https://docs.python.org/2/library/difflib.html#difflib.HtmlDiff.__init__ and https://docs.python.org/3/library/difflib.html#difflib.HtmlDiff.__init__
where 'ndiff()' isn't hyperlinked, and https://docs.python.org/3/library/difflib.html#difflib.restore where 'ndiff()' *is* hyperlinked.

----------
assignee: docs at python
components: Documentation
messages: 253743
nosy: docs at python, lurchman
priority: normal
severity: normal
status: open
title: Minor difflib documentation bug
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/issue25519>
_______________________________________

From report at bugs.python.org  Fri Oct 30 17:15:02 2015
From: report at bugs.python.org (Stefan Seefeld)
Date: Fri, 30 Oct 2015 21:15:02 +0000
Subject: [New-bugs-announce] [issue25520] unittest load_tests protocol not
 working as documented
Message-ID: <1446239702.03.0.964231995407.issue25520@psf.upfronthosting.co.za>


New submission from Stefan Seefeld:

As described in the README contained in the attached tarball, I'm observing wrong behavior. I have based this code on my understanding of https://docs.python.org/2/library/unittest.html#load-tests-protocol, but the effect isn't as expected (I see duplicate appearances of tests whenever I use the load_tests() mechanism.)

----------
files: unittest_bug.tgz
messages: 253757
nosy: stefan
priority: normal
severity: normal
status: open
title: unittest load_tests protocol not working as documented
type: behavior
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file40905/unittest_bug.tgz

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

From report at bugs.python.org  Fri Oct 30 19:22:34 2015
From: report at bugs.python.org (John Hagen)
Date: Fri, 30 Oct 2015 23:22:34 +0000
Subject: [New-bugs-announce] [issue25521] optparse module does not emit
 DeprecationWarning
Message-ID: <1446247354.16.0.386152814173.issue25521@psf.upfronthosting.co.za>


New submission from John Hagen:

According to the Python docs, optparse has been deprecated since Python 3.2, but it does not emit a DeprecationWarning when imported Python 3.2+.

https://docs.python.org/3/library/optparse.html

PyCharm can uses these DeprecationWarnings to provide helpful alerts the user: https://youtrack.jetbrains.com/issue/PY-16589

----------
components: Library (Lib)
messages: 253768
nosy: John Hagen
priority: normal
severity: normal
status: open
title: optparse module does not emit DeprecationWarning
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Oct 31 01:41:42 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 31 Oct 2015 05:41:42 +0000
Subject: [New-bugs-announce] [issue25522] IDLE: warn if save-as name matches
 stdlib name
Message-ID: <1446270102.89.0.424617028731.issue25522@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

When users 'saveas', warn if name matches that of a stdlib modules. Note that shadowing is opposite for lib and binary (builtin) modules, so message needs to be different.  I am not worrying about 3rd party modules on the search path (ie, site-packages), which would be shadowed like lib modules. Rough outline of code to add to IOBinding.

from os,path import dirname
import sys

# this part on initiallzation or first saveas call
def libmodules():
    with open(dirname(dirname(__file__))) as lib:
        for f in lib:
            if <directory containing __init__.py#> or f.endswith(.py):
                yield f
# test.test__all__ has this code

islibmodule = frozenset(libmodules()).__contains__
isbinmodule = frozenset(sys.builtin_module_names).__contains__

# this part after saveas dialog returns
if islibmodule(name):
    go = warn("This name matches a stdlib name in /Lib. If you run python in this directory, you will not be able to import the stdlib module.  Continue?".)
elif isbinmodule(name):
    go = warn("This name matches a builtin stdlib name.  You will not be able to import this file.  Continue?".)
else:
    go = True
if go:
    <save as requested>
else:
   (get name again>  # or put in while not go loop

----------
messages: 253775
nosy: lac, markroseman, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: warn if save-as name matches stdlib name
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/issue25522>
_______________________________________

From report at bugs.python.org  Sat Oct 31 08:32:09 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 31 Oct 2015 12:32:09 +0000
Subject: [New-bugs-announce] [issue25523] Correct "a" article to "an" article
Message-ID: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za>


New submission from Martin Panter:

This patch generally changes ?a? to ?an? where appropriate in the main documentation, doc strings, source code comments, and a couple error messages in the test suite. Since it touches so many files, I thought it would be good to get a quick review.

----------
assignee: docs at python
components: Documentation
files: a-an.patch
keywords: patch
messages: 253784
nosy: docs at python, martin.panter
priority: normal
severity: normal
stage: patch review
status: open
title: Correct "a" article to "an" article
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40909/a-an.patch

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

From report at bugs.python.org  Sat Oct 31 10:21:04 2015
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 31 Oct 2015 14:21:04 +0000
Subject: [New-bugs-announce] [issue25524] Add
 PyMemoryView_FromObjectWithFlags()
Message-ID: <1446301264.7.0.598429050935.issue25524@psf.upfronthosting.co.za>


New submission from Stefan Krah:

See for example #25498.

----------
messages: 253787
nosy: skrah
priority: normal
severity: normal
status: open
title: Add PyMemoryView_FromObjectWithFlags()
versions: Python 3.6

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

From report at bugs.python.org  Sat Oct 31 15:14:22 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Oct 2015 19:14:22 +0000
Subject: [New-bugs-announce] [issue25525] Deallocation scheme for memoryview
 is unsafe
Message-ID: <1446318862.67.0.0722395026507.issue25525@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Deallocation scheme for memoryview is complex and unsafe. It crashes with chained memoryviews (issue25498), but I suppose deallocating unchained memoryview can crash too if the memoryview itself had exported buffers (self->exports != 0).

Both memoryview and ManagedBuffer support garbage collector. If there is a reference to memoryview from reference loop, memoryview becomes a part of the reference loop.

    refloop -> memoryview -> ManagedBuffer -> obj

First garbage collector calls tp_clear for all objects in the loop (memory_clear() for memoryview).
If self->exports != 0 for memoryview, _memory_release() fails and the _Py_MEMORYVIEW_RELEASED flag is not set. However following Py_CLEAR(self->mbuf) deallocates ManagedBuffer and set self->mbuf to NULL. Then memoryview's owner releases memoryview, and it is deallocated (memory_dealloc). _memory_release reads self->mbuf->exports, but self->mbuf is NULL. Segmentation fault.

Following patch makes deallocation scheme for memoryview simpler and more reliable.

1) memory_clear does nothing if self->exports != 0. The buffer will be released when memoryview's owner release the memoryview.

2) ManagedBuffer no longer supports garbage collector. This prevents buffer releasing before memoryview or its owner are cleared.

----------
components: Interpreter Core
messages: 253803
nosy: serhiy.storchaka, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Deallocation scheme for memoryview is unsafe
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Oct 31 22:22:47 2015
From: report at bugs.python.org (nanxiu)
Date: Sun, 01 Nov 2015 02:22:47 +0000
Subject: [New-bugs-announce] [issue25526] (python2.7.10)ImportError: No
 module named _ssl
Message-ID: <1446344567.35.0.253230006676.issue25526@psf.upfronthosting.co.za>


New submission from nanxiu:

After I install python2.7.10
I run:import ssl,then I find this error:

Python 2.7.10 (default, Oct 29 2015, 04:13:03) 
[GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ssl
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/bae/nanxiu/software/Python-2.7.10/Lib/ssl.py", line 97, in <module>
    import _ssl             # if we can't import it, let the error propagate
ImportError: No module named _ssl
>>>

----------
components: Extension Modules
messages: 253820
nosy: a568953256
priority: normal
severity: normal
status: open
title: (python2.7.10)ImportError: No module named _ssl
type: behavior
versions: Python 2.7

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