From report at bugs.python.org  Thu Oct  1 00:42:27 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Sep 2015 22:42:27 +0000
Subject: [issue25274] "./python -m test test_sys": Fatal Python error: Cannot
 recover from stack overflow
In-Reply-To: <1443570348.5.0.971307491137.issue25274@psf.upfronthosting.co.za>
Message-ID: <1443652947.17.0.85524233417.issue25274@psf.upfronthosting.co.za>


STINNER Victor added the comment:

At revision 281ab7954d7c, the test_recursionlimit_recovery() test of test_sys is executed at depth 36.

The overflowed flag is reset when the depth becomes smaller than 50 * 3 // 4 = 37, so when Py_LeaveRecursiveCall() is called with depth level 36.

The test raises a RecursionError once which sets the overflowed flag. Then it tries again to raise the RecursionError, but instead Py_FatalError() is called because the overflowed flag was not reset.

----------

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

From report at bugs.python.org  Thu Oct  1 00:43:49 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Sep 2015 22:43:49 +0000
Subject: [issue25276] test_decimal sometimes crash on PPC64 AIX 3.x
In-Reply-To: <1443605165.97.0.433720501229.issue25276@psf.upfronthosting.co.za>
Message-ID: <1443653029.92.0.848359594827.issue25276@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +skrah

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

From report at bugs.python.org  Thu Oct  1 00:47:48 2015
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 30 Sep 2015 22:47:48 +0000
Subject: [issue24820] IDLE themes for light on dark
In-Reply-To: <1438923257.49.0.103520260228.issue24820@psf.upfronthosting.co.za>
Message-ID: <1443653268.88.0.442255219398.issue24820@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Hi Marc, you're correct that is an error in the theme. To correct it, change the setting for 'break-background' to be something like #666622. Thanks!

----------

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

From report at bugs.python.org  Thu Oct  1 00:54:55 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 30 Sep 2015 22:54:55 +0000
Subject: [issue25260] python -m test --coverage doesn't work on Windows
In-Reply-To: <1443478802.75.0.02674996421.issue25260@psf.upfronthosting.co.za>
Message-ID: <20150930225451.9955.37171@psf.io>


Roundup Robot added the comment:

New changeset 0f10e0b3e76d by Victor Stinner in branch 'default':
Fix regrtest --coverage on Windows
https://hg.python.org/cpython/rev/0f10e0b3e76d

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Oct  1 00:55:16 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Sep 2015 22:55:16 +0000
Subject: [issue25260] python -m test --coverage doesn't work on Windows
In-Reply-To: <1443478802.75.0.02674996421.issue25260@psf.upfronthosting.co.za>
Message-ID: <1443653716.75.0.191160107721.issue25260@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ok, I fixed the issue by removing the list of ignored directories.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Thu Oct  1 01:16:13 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Sep 2015 23:16:13 +0000
Subject: [issue25256] Add sys.debug_build public variable to check if Python
 was compiled in debug mode
In-Reply-To: <1443446100.69.0.307482207939.issue25256@psf.upfronthosting.co.za>
Message-ID: <1443654973.38.0.29680813276.issue25256@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Updated patch:

* replace sys.is_debug_build() function with sys.debug_build variable
* use also sys.debug_build in test_regrtest.py
* remove the paragraph on how the debug module can be enabled when compiling CPython: it's too specific to CPython, and not really interesting in the (sys) library doc.
* mention the new function in What's New in Python 3.6

----------
title: Add sys.is_debug_build() public function to check if Python was compiled in debug mode -> Add sys.debug_build public variable to check if Python was compiled in debug mode
Added file: http://bugs.python.org/file40633/debug_build-2.patch

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

From report at bugs.python.org  Thu Oct  1 01:36:29 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 30 Sep 2015 23:36:29 +0000
Subject: [issue24820] IDLE themes for light on dark
In-Reply-To: <1438923257.49.0.103520260228.issue24820@psf.upfronthosting.co.za>
Message-ID: <1443656189.7.0.30786931049.issue24820@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Marc, thanks for unlurking.  I like something a bit brighter, such as #808000, though it does not matter much in this color area.  We are revising the highlight tab and should add a line [     breakpoint     ] to the sample box.

----------
Added file: http://bugs.python.org/file40634/idle-dark.cfg

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

From report at bugs.python.org  Thu Oct  1 01:36:46 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 30 Sep 2015 23:36:46 +0000
Subject: [issue24820] IDLE themes for light on dark
In-Reply-To: <1438923257.49.0.103520260228.issue24820@psf.upfronthosting.co.za>
Message-ID: <1443656206.83.0.985868108172.issue24820@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


Removed file: http://bugs.python.org/file40582/idle-dark.cfg

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

From report at bugs.python.org  Thu Oct  1 01:54:09 2015
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 30 Sep 2015 23:54:09 +0000
Subject: [issue20580] IDLE should support platform-specific default config
 defaults
In-Reply-To: <1392027551.21.0.533992391985.issue20580@psf.upfronthosting.co.za>
Message-ID: <1443657249.04.0.267181803981.issue20580@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Before creating another layer on top of the existing layers of configuration handling, can I suggest for now at least just hard-coding the few things that are needed in the code itself? 

For example, in configHandler.py, after calling LoadCfgFiles, we could call a routine like, e.g.

    def AdjustPlatformDefaults(self):
        if sys.platform == 'darwin':
            self.defaultCfg['main'].set('Keys', 'name', 'IDLE Classic OSX')
        ...

An appropriate comment could be added to config-main.def about this default option being overridden.

That would allow getting rid of the Makefile hack.

----------

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

From report at bugs.python.org  Thu Oct  1 02:10:18 2015
From: report at bugs.python.org (Mark Roseman)
Date: Thu, 01 Oct 2015 00:10:18 +0000
Subject: [issue24820] IDLE themes for light on dark
In-Reply-To: <1438923257.49.0.103520260228.issue24820@psf.upfronthosting.co.za>
Message-ID: <1443658218.64.0.0368614777469.issue24820@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Attached a patch to the current config dialog to add breakpoint to the window, and have updated the same thing in my newer dialog.

----------
keywords: +patch
Added file: http://bugs.python.org/file40635/breakpoint-prefs.patch

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

From report at bugs.python.org  Thu Oct  1 02:29:42 2015
From: report at bugs.python.org (Mark Roseman)
Date: Thu, 01 Oct 2015 00:29:42 +0000
Subject: [issue25254] Idle: debugger source line highlighting fails again
In-Reply-To: <1443410161.14.0.45288371975.issue25254@psf.upfronthosting.co.za>
Message-ID: <1443659382.82.0.447602121042.issue25254@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Was the 'source' checkbox in the debugger checked?

----------

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

From report at bugs.python.org  Thu Oct  1 02:34:29 2015
From: report at bugs.python.org (Ashley Anderson)
Date: Thu, 01 Oct 2015 00:34:29 +0000
Subject: [issue12006] strptime should implement %G, %V and %u directives
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1443659669.87.0.14941100931.issue12006@psf.upfronthosting.co.za>


Ashley Anderson added the comment:

Another *ping* for a patch review since it's been almost a month since the last one.

----------

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

From report at bugs.python.org  Thu Oct  1 02:40:54 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 01 Oct 2015 00:40:54 +0000
Subject: [issue25272] asyncio tests are getting noisy
In-Reply-To: <1443553151.38.0.791479091232.issue25272@psf.upfronthosting.co.za>
Message-ID: <1443660054.48.0.940561400662.issue25272@psf.upfronthosting.co.za>


Martin Panter added the comment:

Another source of noise is this warning about a task being slow to respond. I briefly investigated this a while back. I concluded that it only happens when other tests are run before it; it does not happen when test_asyncio is run alone. It is caused by the garbage collector, because I was able to stop it by invoking gc.collect() at a particular point in the test.

$ make -s -j2 && LC_TIME= ./python -bWall -m test -j0
[. . .]
[ 36/399] test_bytes
[ 37/399] test_bz2 -- running: test_buffer (32 sec), test_asyncore (42 sec), test_asyncio (44 sec)
[ 38/399] test_buffer (33 sec) -- running: test_asyncore (43 sec), test_asyncio (45 sec)
[ 39/399] test_asyncio (44 sec) -- running: test_asyncore (43 sec)
Executing <Task finished coro=<CoroutineTests.test_async_def_wrapped.<locals>.start() done, defined at /media/disk/home/proj/python/cpython/Lib/test/test_asyncio/test_pep492.py:146> result=None created at /media/disk/home/proj/python/cpython/Lib/asyncio/base_events.py:323> took 0.177 seconds
returning true from eof_received() has no effect when using ssl
returning true from eof_received() has no effect when using ssl

----------
nosy: +martin.panter

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

From report at bugs.python.org  Thu Oct  1 02:49:41 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 01 Oct 2015 00:49:41 +0000
Subject: [issue25184] "python -m pydoc -w" fails in nondecodable directory
In-Reply-To: <1442696845.13.0.851195404942.issue25184@psf.upfronthosting.co.za>
Message-ID: <1443660581.51.0.177414600587.issue25184@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a patch that implements my IRI (Unicode URL) proposal. Differences compared to Serhiy?s patches:

* ?file:? URLs use Unicode if possible. Percent encode encoding only used for reserved ASCII characters and undecodable bytes.

* HTTP URLs use UTF-8 and retain surrogate escaping. This means that the links generated by ?getobj? pages to ?getfile? pages work with troublesome paths.

* Displayed file names are get an ASCII question mark thanks to the ?replace? error handler. This means that the generated HTML is now encodable to UTF-8. Serhiy?s path would be displayed something like:

/home/serhiy/py/cpy?thon-3.5/Lib/pydoc.py (invalid filename encoding)

* Added some missing html.escape() calls.

----------
Added file: http://bugs.python.org/file40636/pydoc_iri.patch

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

From report at bugs.python.org  Thu Oct  1 03:24:03 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 01 Oct 2015 01:24:03 +0000
Subject: [issue12006] strptime should implement %G, %V and %u directives
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1443662643.27.0.478093335298.issue12006@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Ashley,

You don't have to be a committer to review a patch.  Given that it is unlikely that any of the committers is an expert on ISO calendar, an external review will be most welcome.  Would you complete one?

----------

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

From report at bugs.python.org  Thu Oct  1 04:05:15 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 01 Oct 2015 02:05:15 +0000
Subject: [issue25258] HtmlParser doesn't handle void element tags correctly
In-Reply-To: <1443468394.25.0.617953373069.issue25258@psf.upfronthosting.co.za>
Message-ID: <1443665115.49.0.126579485236.issue25258@psf.upfronthosting.co.za>


Martin Panter added the comment:

My thinking is that the knowledge that <img> does not have a closing tag is at a higher level than the current HTMLParser class. It is similar to knowing where the following HTML implicitly closes the <li> elements:

<ul><li>Item A<li>Item B</ul>

In both cases I would not expect the HTMLParser to report ?virtual? empty or closing tags. I don?t think it should report an empty <img/> or closing </img> tag just because that is easy to do, because it would be inconsistent with other implied HTML tags. But maybe see what other people say.

I don?t know your particular use case, but I would suggest if you need to parse non-XML HTML <img> tags, use the handle_starttag() method and don?t rely on the end tag :)

----------

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

From report at bugs.python.org  Thu Oct  1 04:18:09 2015
From: report at bugs.python.org (Ashley Anderson)
Date: Thu, 01 Oct 2015 02:18:09 +0000
Subject: [issue12006] strptime should implement %G, %V and %u directives
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1443665889.46.0.691438978598.issue12006@psf.upfronthosting.co.za>


Ashley Anderson added the comment:

Thanks Alexander, but I think the latest patch is still mine. It seems strange to review my own patch. I'll do it if that's common, but since this will (hopefully, eventually) be my first accepted patch I would appreciate the feedback from another reviewer.

----------

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

From report at bugs.python.org  Thu Oct  1 04:35:52 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 01 Oct 2015 02:35:52 +0000
Subject: [issue25270] codecs.escape_encode systemerror on empty byte string
In-Reply-To: <1443542758.27.0.114315188103.issue25270@psf.upfronthosting.co.za>
Message-ID: <1443666952.91.0.950971601367.issue25270@psf.upfronthosting.co.za>


Martin Panter added the comment:

The patch looks sufficient to fix the problem, though I do like Serhiy?s suggestions.

For the record, because I was curious: Function codecs.escape_encode() is not documented, and barely tested. It was used for the documented ?string_escape? codec in Python 2, but this codec was removed for Python 3 in revision bc90fc9b70b7. The function was apparently added to support pickling, but I don?t see any evidence that it was ever used. Only the decode counterpart was used. I wonder if the encode function could be removed at some point.

----------
nosy: +martin.panter

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

From report at bugs.python.org  Thu Oct  1 04:58:37 2015
From: report at bugs.python.org (Vinson Lee)
Date: Thu, 01 Oct 2015 02:58:37 +0000
Subject: [issue24841] Some test_ssl network tests fail if svn.python.org is
 not accessible.
In-Reply-To: <1439252941.43.0.787973342114.issue24841@psf.upfronthosting.co.za>
Message-ID: <1443668317.25.0.689191641682.issue24841@psf.upfronthosting.co.za>


Vinson Lee added the comment:

I tested the attached patch on latest cpython master and it works for me.

test_ciphers (test.test_ssl.NetworkedTests) ... skipped "Resource 'svn.python.org' is not available"
test_connect (test.test_ssl.NetworkedTests) ... skipped "Resource 'svn.python.org' is not available"
test_connect_cadata (test.test_ssl.NetworkedTests) ... skipped "Resource 'svn.python.org' is not available"
test_connect_capath (test.test_ssl.NetworkedTests) ... skipped "Resource 'svn.python.org' is not available"
test_connect_ex (test.test_ssl.NetworkedTests) ... skipped 'svn.python.org cannot be reached: Connection refused'
test_connect_with_context (test.test_ssl.NetworkedTests) ... skipped "Resource 'svn.python.org' is not available"
test_context_setget (test.test_ssl.NetworkedTests) ... skipped "Resource 'svn.python.org' is not available"
test_get_ca_certs_capath (test.test_ssl.NetworkedTests) ... skipped "Resource 'svn.python.org' is not available"
test_get_server_certificate (test.test_ssl.NetworkedTests) ... skipped "Resource 'svn.python.org' is not available"
test_makefile_close (test.test_ssl.NetworkedTests) ... skipped "Resource 'svn.python.org' is not available"
test_non_blocking_connect_ex (test.test_ssl.NetworkedTests) ... skipped "Resource 'svn.python.org' is not available"
test_non_blocking_handshake (test.test_ssl.NetworkedTests) ... skipped "Resource 'svn.python.org' is not available"
test_timeout_connect_ex (test.test_ssl.NetworkedTests) ... skipped 'svn.python.org cannot be reached: Connection refused'
test_handshake (test.test_ssl.NetworkedBIOTests) ... skipped "Resource 'svn.python.org' is not available"
test_read_write_data (test.test_ssl.NetworkedBIOTests) ... skipped "Resource 'svn.python.org' is not available"

Tested-by: Vinson Lee <vlee at twitter.com>

----------

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

From report at bugs.python.org  Thu Oct  1 06:07:07 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 01 Oct 2015 04:07:07 +0000
Subject: [issue25275] Documentation v/s behaviour mismatch wrt integer
 literals containing non-ASCII characters
In-Reply-To: <1443590385.97.0.810723896221.issue25275@psf.upfronthosting.co.za>
Message-ID: <1443672427.44.0.203367539851.issue25275@psf.upfronthosting.co.za>


Martin Panter added the comment:

Related discussion and background in Issue 10581, although that report seems to be geared at extending the Unicode support even further (disallowing mixed scripts, allowing proper minus signs, full-width characters, Roman numerals, etc).

The existing support is actually documented if you know where to look; see the sixth note under the table at <https://docs.python.org/dev/library/stdtypes.html#typesnumeric>. I agree that the references for each constructor should also document this as well.

----------
nosy: +martin.panter

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

From report at bugs.python.org  Thu Oct  1 06:31:46 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Oct 2015 04:31:46 +0000
Subject: [issue25276] test_decimal sometimes crash on PPC64 AIX 3.x
In-Reply-To: <1443605165.97.0.433720501229.issue25276@psf.upfronthosting.co.za>
Message-ID: <1443673906.86.0.978095456022.issue25276@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
components: +Extension Modules
type:  -> crash

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

From report at bugs.python.org  Thu Oct  1 06:35:28 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Oct 2015 04:35:28 +0000
Subject: [issue25274] "./python -m test test_sys": Fatal Python error: Cannot
 recover from stack overflow
In-Reply-To: <1443570348.5.0.971307491137.issue25274@psf.upfronthosting.co.za>
Message-ID: <1443674128.84.0.36312568004.issue25274@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue25222. _Py_CheckRecursiveCall may be being called recursively through Py_FatalError.

----------
components: +Interpreter Core, Tests
nosy: +serhiy.storchaka
type:  -> crash

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

From report at bugs.python.org  Thu Oct  1 07:18:01 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 01 Oct 2015 05:18:01 +0000
Subject: [issue16701] Docs missing the behavior of += (in-place add) for lists.
In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za>
Message-ID: <1443676681.7.0.199385994899.issue16701@psf.upfronthosting.co.za>


Martin Panter added the comment:

?For the most part? works for me. Here is the patch.

----------
Added file: http://bugs.python.org/file40637/seq-inplace.v3.patch

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

From report at bugs.python.org  Thu Oct  1 07:19:16 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 01 Oct 2015 05:19:16 +0000
Subject: [issue22413] Bizarre StringIO(newline="\r\n") translation
In-Reply-To: <1410750243.44.0.979805676788.issue22413@psf.upfronthosting.co.za>
Message-ID: <1443676756.24.0.474495799915.issue22413@psf.upfronthosting.co.za>


Martin Panter added the comment:

I understand it may not be worth changing the behaviour. Would you instead accept a change to the documentation to point out that ?newline? does _not_ actually work like TextIOWrapper? Or perhaps even deprecating or recommending against using ?newline??

----------

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

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: [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:16:58 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 01 Oct 2015 06:16:58 +0000
Subject: [issue25286] views are not sequences
In-Reply-To: <1443677491.48.0.268151687155.issue25286@psf.upfronthosting.co.za>
Message-ID: <1443680218.81.0.892974449691.issue25286@psf.upfronthosting.co.za>


Martin Panter added the comment:

If changing the glossary heading, make sure it is kept in alphabetical order and incoming links still work (e.g. look for `view` and <view>). And maybe ?dictionary view? (full spelling, and singular) would be a more accurate heading.

The text changes look good however.

----------
nosy: +martin.panter
stage:  -> patch review

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

From report at bugs.python.org  Thu Oct  1 08:39:15 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 06:39:15 +0000
Subject: [issue25272] asyncio tests are getting noisy
In-Reply-To: <1443660054.48.0.940561400662.issue25272@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwafK9BD5rP9X-=6NRb9M4953R9-KFAswcs2HqYvRJmLHw@mail.gmail.com>


STINNER Victor added the comment:

> Executing <Task finished coro=<CoroutineTests.test_async_def_wrapped.<locals>.start() done, defined at /media/disk/home/proj/python/cpython/Lib/test/test_asyncio/test_pep492.py:146> result=None created at /media/disk/home/proj/python/cpython/Lib/asyncio/base_events.py:323> took 0.177 seconds

This one is trivial to fix: set loop.slow_callback_duration to 1.0
(second) or more in TestCase.set_event_loop() of asyncio.test_utils.

----------

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

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: [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 08:50:11 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 06:50:11 +0000
Subject: [issue25287] test_crypt fails on OpenBSD
In-Reply-To: <1443682191.0.0.229033947807.issue25287@psf.upfronthosting.co.za>
Message-ID: <1443682211.6.0.0958553182127.issue25287@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +rpointel

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

From report at bugs.python.org  Thu Oct  1 08:50:33 2015
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 01 Oct 2015 06:50:33 +0000
Subject: [issue25284] Spec for BaseEventLoop.run_in_executor(executor, callback,
 *args) is outdated in documentation
In-Reply-To: <1443645237.96.0.144397118323.issue25284@psf.upfronthosting.co.za>
Message-ID: <1443682233.61.0.400493315103.issue25284@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Fixed in 9a10055e12fa d7d18ef3e05c 1465b18ef4fc

----------
nosy: +asvetlov
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.4, Python 3.6

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

From report at bugs.python.org  Thu Oct  1 08:50:59 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 06:50:59 +0000
Subject: [issue25171] does not build on OpenBSD with no value defined for
 PY_GETENTROPY
In-Reply-To: <1442618175.28.0.599214895418.issue25171@psf.upfronthosting.co.za>
Message-ID: <1443682259.23.0.975375496905.issue25171@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Thanks Remi for your fix, the compilation succeeded on the buildbot. Sorry for the regression.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Thu Oct  1 08:57:37 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Oct 2015 06:57:37 +0000
Subject: [issue25274] "./python -m test test_sys": Fatal Python error: Cannot
 recover from stack overflow
In-Reply-To: <1443570348.5.0.971307491137.issue25274@psf.upfronthosting.co.za>
Message-ID: <20151001065733.98352.62653@psf.io>


Roundup Robot added the comment:

New changeset 60c4fd84ef92 by Victor Stinner in branch '3.4':
Issue #25274: test_recursionlimit_recovery() of test_sys now checks
https://hg.python.org/cpython/rev/60c4fd84ef92

New changeset 898a9a959927 by Victor Stinner in branch '3.5':
(Merge 3.4) Issue #25274: test_recursionlimit_recovery() of test_sys now checks
https://hg.python.org/cpython/rev/898a9a959927

New changeset bae0912dd160 by Victor Stinner in branch 'default':
(Merge 3.5) Issue #25274: test_recursionlimit_recovery() of test_sys now checks
https://hg.python.org/cpython/rev/bae0912dd160

----------

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

From report at bugs.python.org  Thu Oct  1 09:34:36 2015
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 01 Oct 2015 07:34:36 +0000
Subject: [issue25270] codecs.escape_encode systemerror on empty byte string
In-Reply-To: <1443666952.91.0.950971601367.issue25270@psf.upfronthosting.co.za>
Message-ID: <560CE1FC.4030409@egenix.com>


Marc-Andre Lemburg added the comment:

On 01.10.2015 04:35, Martin Panter wrote:
> For the record, because I was curious: Function codecs.escape_encode() is not documented, and barely tested. It was used for the documented ?string_escape? codec in Python 2, but this codec was removed for Python 3 in revision bc90fc9b70b7. The function was apparently added to support pickling, but I don?t see any evidence that it was ever used. Only the decode counterpart was used. I wonder if the encode function could be removed at some point.

It's a codec, so either we remove both functions or leave both
functions in. It's still used in pickletools and serves a useful
purpose there (to unescape embedded escapes in byte streams).

----------

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

From report at bugs.python.org  Thu Oct  1 09:40:46 2015
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 01 Oct 2015 07:40:46 +0000
Subject: [issue25270] codecs.escape_encode systemerror on empty byte string
In-Reply-To: <1443618686.96.0.686852832064.issue25270@psf.upfronthosting.co.za>
Message-ID: <560CE36E.8000508@egenix.com>


Marc-Andre Lemburg added the comment:

On 30.09.2015 15:11, Serhiy Storchaka wrote:
> May be better to test a condition "size > 0" before calling _PyBytes_Resize(), as in many other case where _PyBytes_Resize() is used.
> 
> Or accept shared objects in _PyBytes_Resize() if new size is equal to old size. This will allow to getrid of additional tests before calling _PyBytes_Resize().

Agreed. It would be good to make _PyBytes_Resize() more robust for
shared objects.

----------

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

From report at bugs.python.org  Thu Oct  1 09:41:09 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 07:41:09 +0000
Subject: [issue25274] sys.setrecursionlimit() must fail if the current
 recursion depth is higher than the new low-water mark
In-Reply-To: <1443570348.5.0.971307491137.issue25274@psf.upfronthosting.co.za>
Message-ID: <1443685269.2.0.525362214495.issue25274@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Attached patch raises a ValueError if the current recursion depth is higher than the new "low-water mark". The low-water mark is the value computed by _Py_MakeEndRecCheck() in Py_LeaveRecursiveCall() to decide if we can reset the overflowed field of the thread state to 0.

Example of error with the patch:

$ ./python -c 'import sys; sys.setrecursionlimit(2)'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ValueError: cannot set recursion limit to 2: the minimum recursion limit is 1 at the recursion depth 1

----------
keywords: +patch
title: "./python -m test test_sys": Fatal Python error: Cannot recover from stack overflow -> sys.setrecursionlimit() must fail if the current recursion depth is higher than the new low-water mark
Added file: http://bugs.python.org/file40640/sys_setrecursionlimit.patch

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

From report at bugs.python.org  Thu Oct  1 09:42:19 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 07:42:19 +0000
Subject: [issue25274] sys.setrecursionlimit() must fail if the current
 recursion depth is higher than the new low-water mark
In-Reply-To: <1443570348.5.0.971307491137.issue25274@psf.upfronthosting.co.za>
Message-ID: <1443685339.41.0.285260152843.issue25274@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Oct  1 09:51:55 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Oct 2015 07:51:55 +0000
Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2)
 on Solaris 11.3 and newer
In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za>
Message-ID: <20151001075152.98364.64322@psf.io>


Roundup Robot added the comment:

New changeset 835085cc28cd by Victor Stinner in branch '3.5':
Issue #25003: On Solaris 11.3 or newer, os.urandom() now uses the getrandom()
https://hg.python.org/cpython/rev/835085cc28cd

----------

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

From report at bugs.python.org  Thu Oct  1 10:00:30 2015
From: report at bugs.python.org (Robin Roth)
Date: Thu, 01 Oct 2015 08:00:30 +0000
Subject: [issue2466] os.path.ismount doesn't work for mounts the user doesn't
 have permission to see
In-Reply-To: <1206293428.96.0.660613140218.issue2466@psf.upfronthosting.co.za>
Message-ID: <1443686430.81.0.428811489511.issue2466@psf.upfronthosting.co.za>


Robin Roth added the comment:

This bug is still present and annoying.
For me it appeared when running ismount on a nfs-mounted directory, when the user who runs python has no read permission inside the directory. Therefore the lstat on /mntdir/.. fails.
Attached a patch that fixes this by running abspath on the path.

Symlinks will also work because they are checked/excluded before the part of the code where the patch is in.

msg222528 is not related to the original bug and should be opened separately.

----------
keywords: +patch
nosy: +Robin Roth
Added file: http://bugs.python.org/file40641/ismount-permission.patch

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

From report at bugs.python.org  Thu Oct  1 10:02:03 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Oct 2015 08:02:03 +0000
Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2)
 on Solaris 11.3 and newer
In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za>
Message-ID: <20151001080200.82652.71080@psf.io>


Roundup Robot added the comment:

New changeset 202c827f86df by Victor Stinner in branch '2.7':
Issue #25003: os.urandom() doesn't use getentropy() on Solaris because
https://hg.python.org/cpython/rev/202c827f86df

New changeset 83dc79eeaf7f by Victor Stinner in branch '3.4':
Issue #25003: os.urandom() doesn't use getentropy() on Solaris because
https://hg.python.org/cpython/rev/83dc79eeaf7f

----------

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

From report at bugs.python.org  Thu Oct  1 10:06:26 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 08:06:26 +0000
Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2)
 on Solaris 11.3 and newer
In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za>
Message-ID: <1443686786.5.0.228634821984.issue25003@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ok, I pushed fixes for Python 2.7, 3.4, 3.5 and 3.6.

Summary for Solaris:

- Python 2.7, 3.4: read from /dev/urandom (use a private file descriptor)
- Python 3.5, 3.6: use the getrandom() function on Solaris 11.3 and newer (no file descriptor), or fallback on reading from /dev/urandom (use a private file descriptor)

getentropy() is no more used on Solaris.

@John Beck: It would be great if you could run test_os on the development branches 2.7, 3.4, 3.5 and default (3.6).

----------

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

From report at bugs.python.org  Thu Oct  1 10:57:07 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Oct 2015 08:57:07 +0000
Subject: [issue25280] Message can be formatted twice in importlib
In-Reply-To: <1443619937.76.0.139042721481.issue25280@psf.upfronthosting.co.za>
Message-ID: <20151001085703.9945.67240@psf.io>


Roundup Robot added the comment:

New changeset da42b38f7470 by Serhiy Storchaka in branch '3.4':
Issue #25280: Import trace messages emitted in verbose (-v) mode are no
https://hg.python.org/cpython/rev/da42b38f7470

New changeset 10c13441bf8d by Serhiy Storchaka in branch '3.5':
Issue #25280: Import trace messages emitted in verbose (-v) mode are no
https://hg.python.org/cpython/rev/10c13441bf8d

New changeset e377d568928b by Serhiy Storchaka in branch 'default':
Issue #25280: Import trace messages emitted in verbose (-v) mode are no
https://hg.python.org/cpython/rev/e377d568928b

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Oct  1 11:19:31 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Oct 2015 09:19:31 +0000
Subject: [issue25274] sys.setrecursionlimit() must fail if the current
 recursion depth is higher than the new low-water mark
In-Reply-To: <1443570348.5.0.971307491137.issue25274@psf.upfronthosting.co.za>
Message-ID: <1443691171.8.0.597152484532.issue25274@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> ValueError: cannot set recursion limit to 2: the minimum recursion limit is 1 at the recursion depth 1

This message looks confusing to me. 2 > 1, isn't?

The dependency of min_limit from new_limit is not monotonic:

new_limit = 99 => min_limit = 74
new_limit = 100 => min_limit = 75
new_limit = 101 => min_limit = 51

----------

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

From report at bugs.python.org  Thu Oct  1 11:20:34 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Oct 2015 09:20:34 +0000
Subject: [issue25280] Message can be formatted twice in importlib
In-Reply-To: <1443619937.76.0.139042721481.issue25280@psf.upfronthosting.co.za>
Message-ID: <1443691234.77.0.16369817321.issue25280@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Brett for your review.

----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

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: [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 11:33:09 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Oct 2015 09:33:09 +0000
Subject: [issue21995] Idle: pseudofiles have no buffer attribute.
In-Reply-To: <1405550850.77.0.279876996055.issue21995@psf.upfronthosting.co.za>
Message-ID: <1443691989.62.0.780395123508.issue21995@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yet one example of test stream that has no buffer - stdprinter used as sys.stderr on early stage of Python startup.

----------

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

From report at bugs.python.org  Thu Oct  1 11:57:11 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 09:57:11 +0000
Subject: [issue25274] sys.setrecursionlimit() must fail if the current
 recursion depth is higher than the new low-water mark
In-Reply-To: <1443570348.5.0.971307491137.issue25274@psf.upfronthosting.co.za>
Message-ID: <1443693431.73.0.988396465643.issue25274@psf.upfronthosting.co.za>


STINNER Victor added the comment:

sys_setrecursionlimit-2.patch: fix error message, exchange the last 2 PyErr_Format() parameters.

----------
Added file: http://bugs.python.org/file40642/sys_setrecursionlimit-2.patch

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

From report at bugs.python.org  Thu Oct  1 12:19:20 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 01 Oct 2015 10:19:20 +0000
Subject: [issue25288] readline.py file in current directory caused unexpected
 code execution.
In-Reply-To: <1443691601.94.0.65090362489.issue25288@psf.upfronthosting.co.za>
Message-ID: <1443694760.66.0.447436387371.issue25288@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I can reproduce this action on Ubuntu.

The forged readline.py in python's execution directory can steal the
permission of python and do something dangerous.

----------
nosy: +xiang.zhang

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

From report at bugs.python.org  Thu Oct  1 12:28:53 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Oct 2015 10:28:53 +0000
Subject: [issue25185] Inconsistency between venv and site
In-Reply-To: <1442698159.95.0.304023821424.issue25185@psf.upfronthosting.co.za>
Message-ID: <20151001102849.94113.87505@psf.io>


Roundup Robot added the comment:

New changeset d927c6cae05f by Vinay Sajip in branch '3.4':
Closes #25185: Use UTF-8 encoding when reading pyvenv.cfg.
https://hg.python.org/cpython/rev/d927c6cae05f

New changeset eaf9220bdee3 by Vinay Sajip in branch '3.5':
Closes #25185: merged fix from 3.4.
https://hg.python.org/cpython/rev/eaf9220bdee3

New changeset 69dd42cef190 by Vinay Sajip in branch 'default':
Closes #25185: merged fix from 3.5.
https://hg.python.org/cpython/rev/69dd42cef190

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Oct  1 12:55:04 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 10:55:04 +0000
Subject: [issue25274] sys.setrecursionlimit() must fail if the current
 recursion depth is higher than the new low-water mark
In-Reply-To: <1443570348.5.0.971307491137.issue25274@psf.upfronthosting.co.za>
Message-ID: <1443696904.09.0.831310175726.issue25274@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Serhiy wrote:
> This message looks confusing to me. 2 > 1, isn't?
> The dependency of min_limit from new_limit is not monotonic: (...)

Ok, now I'm confused too :-)

First of all, I propose to change the exception type to RecursionError because it's really strange to get a ValueError depending on the current recursion depth.

I would prefer to have an hardcoded minimum limit instead of a minimum depending on the current recursion depth, but I'm not sure that it's technically possible according to current constraints in CPython.

Updated patch (version 3) doesn't mention the computed "minimum limit" in the error message since it's hard to compute it for the user (and even for me :-)). For the user, it's hard to estimate (or compute) the current recursion depth.

Updated example:

$ ./python -c 'import sys; sys.setrecursionlimit(0)'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ValueError: recursion limit must be greater or equal than 1

$ ./python -c 'import sys; sys.setrecursionlimit(1)'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
RecursionError: cannot set recursion limit to 1 at the recursion depth 1: the limit is too low

$ ./python -c 'import sys; sys.setrecursionlimit(2)'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
RecursionError: cannot set recursion limit to 2 at the recursion depth 1: the limit is too low

$ ./python -c 'import sys; sys.setrecursionlimit(3)'

(A limit of 3 is valid.)

----------
Added file: http://bugs.python.org/file40643/sys_setrecursionlimit-3.patch

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

From report at bugs.python.org  Thu Oct  1 13:06:35 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 11:06:35 +0000
Subject: [issue25274] sys.setrecursionlimit() must fail if the current
 recursion depth is higher than the new low-water mark
In-Reply-To: <1443570348.5.0.971307491137.issue25274@psf.upfronthosting.co.za>
Message-ID: <1443697595.88.0.73821831815.issue25274@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The dependency of min_limit from new_limit is not monotonic: (...)

Right, _Py_MakeEndRecCheck() is not monotonic.

Let me try to make it monotonic:

def f1(x): return x * 3 // 4
def f2(x): return x - 50

f1() > f2() for x <= 196
f1() == f2() for x in 198..200
f1() < f2() for x > 201

So I propose to switch between f1() and f2() at x>200 for _Py_MakeEndRecCheck(). It gives:

recursion depth => low-water mark

25 => 18
...
50 => 37
...
75 => 56
...
100 => 75
...
125 => 93
...
150 => 112
...
175 => 131
...
198 => 148 -- use f1 (x*3/4)
199 => 149
200 => 150 
201 => 151 -- switch to f2 (x-50)
202 => 152
203 => 153

Attached end_rec_check.patch makes _Py_MakeEndRecCheck() monotonic.

----------
Added file: http://bugs.python.org/file40644/end_rec_check.patch

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

From report at bugs.python.org  Thu Oct  1 13:15:33 2015
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 01 Oct 2015 11:15:33 +0000
Subject: [issue25123] Logging Documentation - dictConfig
 disable_existing_loggers
In-Reply-To: <1442312912.97.0.962237041326.issue25123@psf.upfronthosting.co.za>
Message-ID: <1443698133.71.0.117045233493.issue25123@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

This is mentioned in the documentation for dictConfig - see the bottom of the section at https://docs.python.org/2.7/library/logging.config.html#dictionary-schema-details

----------
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Thu Oct  1 13:17:17 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Oct 2015 11:17:17 +0000
Subject: [issue25277] test_eintr hangs on randomly on "AMD64 FreeBSD 9.x 3.x"
In-Reply-To: <1443605568.0.0.865946740877.issue25277@psf.upfronthosting.co.za>
Message-ID: <20151001111713.115545.11463@psf.io>


Roundup Robot added the comment:

New changeset 10efb1797e7b by Victor Stinner in branch 'default':
Issue #25277: Set a timeout of 10 minutes in test_eintr using faulthandler to
https://hg.python.org/cpython/rev/10efb1797e7b

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Oct  1 13:58:15 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 11:58:15 +0000
Subject: [issue25267] Optimize UTF-8 encoder with error handlers
In-Reply-To: <1443526234.91.0.845116536507.issue25267@psf.upfronthosting.co.za>
Message-ID: <1443700695.31.0.859158021892.issue25267@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Added file: http://bugs.python.org/file40645/bench.py

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

From report at bugs.python.org  Thu Oct  1 14:01:26 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 12:01:26 +0000
Subject: [issue25267] Optimize UTF-8 encoder with error handlers
In-Reply-To: <1443526234.91.0.845116536507.issue25267@psf.upfronthosting.co.za>
Message-ID: <1443700886.89.0.860875517275.issue25267@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, there is a bug in utf8_encoder() (not in my patch!), newpos was not used after calling the error handler. It's now fixed in the new patch.

----------
Added file: http://bugs.python.org/file40646/utf8_encoder_errors-2.patch

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

From report at bugs.python.org  Thu Oct  1 14:04:37 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 12:04:37 +0000
Subject: [issue25267] Optimize UTF-8 encoder with error handlers
In-Reply-To: <1443526234.91.0.845116536507.issue25267@psf.upfronthosting.co.za>
Message-ID: <1443701077.09.0.0972316313695.issue25267@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Benchmark results. Sorry for the very long output.

There are some (corner?) cases where the patched Python is a little bit slower. I consider that it's ok since it's *much* faster in the other cases.

What do you think?


Common platform:
Timer info: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09)
Bits: int=32, long=64, long long=64, size_t=64, void*=64
CPU model: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
Python unicode implementation: PEP 393
Timer: time.perf_counter
SCM: hg revision=10efb1797e7b+ tag=tip branch=default date="2015-10-01 13:16 +0200"
Platform: Linux-4.1.6-200.fc22.x86_64-x86_64-with-fedora-22-Twenty_Two
CFLAGS: -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes

Platform of campaign before:
Date: 2015-10-01 13:30:07
Timer precision: 61 ns
Python version: 3.6.0a0 (default:10efb1797e7b, Oct 1 2015, 13:30:06) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)]

Platform of campaign after:
Timer precision: 63 ns
Date: 2015-10-01 13:54:14
Python version: 3.6.0a0 (default:10efb1797e7b+, Oct 1 2015, 13:53:51) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)]

--------------------------+-------------+----------------
ignore: "\udcff" * length |      before |           after
--------------------------+-------------+----------------
length=10**1              | 3.16 us (*) |   279 ns (-91%)
length=10**3              |  241 us (*) | 1.08 us (-100%)
length=10**2              | 23.9 us (*) |   346 ns (-99%)
length=10**4              | 2.39 ms (*) | 6.48 us (-100%)
--------------------------+-------------+----------------
Total                     | 2.66 ms (*) | 8.19 us (-100%)
--------------------------+-------------+----------------

--------------------------------+-------------+---------------
ignore: "a" * length + "\udcff" |      before |          after
--------------------------------+-------------+---------------
length=10**1                    | 1.12 us (*) |  295 ns (-74%)
length=10**3                    |  2.2 us (*) | 1.57 us (-29%)
length=10**2                    | 1.21 us (*) |  408 ns (-66%)
length=10**4                    | 10.4 us (*) | 12.3 us (+18%)
--------------------------------+-------------+---------------
Total                           |   15 us (*) |        14.6 us
--------------------------------+-------------+---------------

--------------------------------------------+-------------+---------------
ignore: ("a" * 99 + "\udcff" * 99) * length |      before |          after
--------------------------------------------+-------------+---------------
length=10**1                                |  238 us (*) | 2.46 us (-99%)
length=10**3                                | 23.7 ms (*) |  234 us (-99%)
length=10**2                                | 2.38 ms (*) | 20.8 us (-99%)
length=10**4                                |  238 ms (*) | 2.56 ms (-99%)
--------------------------------------------+-------------+---------------
Total                                       |  265 ms (*) | 2.82 ms (-99%)
--------------------------------------------+-------------+---------------

---------------------------------------+-------------+----------------
ignore: ("\udcff" * 99 + "a") * length |      before |           after
---------------------------------------+-------------+----------------
length=10**1                           |  239 us (*) |  1.29 us (-99%)
length=10**3                           | 23.8 ms (*) | 80.9 us (-100%)
length=10**2                           |  2.4 ms (*) | 8.44 us (-100%)
length=10**4                           |  236 ms (*) |  839 us (-100%)
---------------------------------------+-------------+----------------
Total                                  |  263 ms (*) |  930 us (-100%)
---------------------------------------+-------------+----------------

--------------------------------+-------------+---------------
ignore: "\udcff" + "a" * length |      before |          after
--------------------------------+-------------+---------------
length=10**1                    | 1.09 us (*) |  297 ns (-73%)
length=10**3                    | 2.19 us (*) | 1.58 us (-28%)
length=10**2                    | 1.19 us (*) |  409 ns (-66%)
length=10**4                    | 10.5 us (*) | 12.3 us (+17%)
--------------------------------+-------------+---------------
Total                           | 14.9 us (*) |        14.6 us
--------------------------------+-------------+---------------

---------------------------+-------------+----------------
replace: "\udcff" * length |      before |           after
---------------------------+-------------+----------------
length=10**1               | 3.47 us (*) |   317 ns (-91%)
length=10**3               |  263 us (*) | 1.07 us (-100%)
length=10**2               | 26.4 us (*) |   383 ns (-99%)
length=10**4               | 2.65 ms (*) | 6.75 us (-100%)
---------------------------+-------------+----------------
Total                      | 2.94 ms (*) | 8.52 us (-100%)
---------------------------+-------------+----------------

---------------------------------+-------------+---------------
replace: "a" * length + "\udcff" |      before |          after
---------------------------------+-------------+---------------
length=10**1                     | 1.16 us (*) |  319 ns (-72%)
length=10**3                     | 2.25 us (*) | 1.62 us (-28%)
length=10**2                     | 1.25 us (*) |  432 ns (-65%)
length=10**4                     | 13.4 us (*) |  12.4 us (-7%)
---------------------------------+-------------+---------------
Total                            |   18 us (*) | 14.7 us (-18%)
---------------------------------+-------------+---------------

---------------------------------------------+-------------+---------------
replace: ("a" * 99 + "\udcff" * 99) * length |      before |          after
---------------------------------------------+-------------+---------------
length=10**1                                 |  267 us (*) | 2.52 us (-99%)
length=10**3                                 | 26.2 ms (*) |  210 us (-99%)
length=10**2                                 | 2.63 ms (*) | 21.3 us (-99%)
length=10**4                                 |  264 ms (*) | 2.98 ms (-99%)
---------------------------------------------+-------------+---------------
Total                                        |  293 ms (*) | 3.21 ms (-99%)
---------------------------------------------+-------------+---------------

----------------------------------------+-------------+----------------
replace: ("\udcff" * 99 + "a") * length |      before |           after
----------------------------------------+-------------+----------------
length=10**1                            |  263 us (*) | 1.29 us (-100%)
length=10**3                            | 26.1 ms (*) | 86.6 us (-100%)
length=10**2                            | 2.63 ms (*) | 9.02 us (-100%)
length=10**4                            |  261 ms (*) |  925 us (-100%)
----------------------------------------+-------------+----------------
Total                                   |  290 ms (*) | 1.02 ms (-100%)
----------------------------------------+-------------+----------------

---------------------------------+-------------+---------------
replace: "\udcff" + "a" * length |      before |          after
---------------------------------+-------------+---------------
length=10**1                     | 1.14 us (*) |  317 ns (-72%)
length=10**3                     | 2.24 us (*) |  1.6 us (-28%)
length=10**2                     | 1.23 us (*) |  428 ns (-65%)
length=10**4                     | 10.5 us (*) | 12.3 us (+17%)
---------------------------------+-------------+---------------
Total                            | 15.1 us (*) |        14.7 us
---------------------------------+-------------+---------------

-----------------------------------+-------------+---------------
surrogateescape: "\udcff" * length |      before |          after
-----------------------------------+-------------+---------------
length=10**1                       | 3.48 us (*) |  281 ns (-92%)
length=10**3                       |  267 us (*) | 1.77 us (-99%)
length=10**2                       | 26.7 us (*) |  424 ns (-98%)
length=10**4                       | 2.67 ms (*) | 13.9 us (-99%)
-----------------------------------+-------------+---------------
Total                              | 2.97 ms (*) | 16.3 us (-99%)
-----------------------------------+-------------+---------------

-----------------------------------------+-------------+---------------
surrogateescape: "a" * length + "\udcff" |      before |          after
-----------------------------------------+-------------+---------------
length=10**1                             | 1.14 us (*) |  277 ns (-76%)
length=10**3                             | 2.32 us (*) | 1.57 us (-32%)
length=10**2                             | 1.24 us (*) |  391 ns (-68%)
length=10**4                             | 10.6 us (*) | 12.3 us (+17%)
-----------------------------------------+-------------+---------------
Total                                    | 15.3 us (*) |        14.6 us
-----------------------------------------+-------------+---------------

-----------------------------------------------------+-------------+---------------
surrogateescape: ("a" * 99 + "\udcff" * 99) * length |      before |          after
-----------------------------------------------------+-------------+---------------
length=10**1                                         |  266 us (*) | 3.26 us (-99%)
length=10**3                                         | 26.4 ms (*) |  285 us (-99%)
length=10**2                                         | 2.65 ms (*) | 28.9 us (-99%)
length=10**4                                         |  266 ms (*) | 3.73 ms (-99%)
-----------------------------------------------------+-------------+---------------
Total                                                |  295 ms (*) | 4.04 ms (-99%)
-----------------------------------------------------+-------------+---------------

------------------------------------------------+-------------+---------------
surrogateescape: ("\udcff" * 99 + "a") * length |      before |          after
------------------------------------------------+-------------+---------------
length=10**1                                    |  265 us (*) | 2.04 us (-99%)
length=10**3                                    | 26.2 ms (*) |  165 us (-99%)
length=10**2                                    | 2.64 ms (*) |   17 us (-99%)
length=10**4                                    |  263 ms (*) | 1.75 ms (-99%)
------------------------------------------------+-------------+---------------
Total                                           |  292 ms (*) | 1.93 ms (-99%)
------------------------------------------------+-------------+---------------

-----------------------------------------+-------------+---------------
surrogateescape: "\udcff" + "a" * length |      before |          after
-----------------------------------------+-------------+---------------
length=10**1                             | 1.12 us (*) |  278 ns (-75%)
length=10**3                             | 2.25 us (*) | 1.59 us (-29%)
length=10**2                             | 1.21 us (*) |  389 ns (-68%)
length=10**4                             | 10.5 us (*) | 12.3 us (+17%)
-----------------------------------------+-------------+---------------
Total                                    | 15.1 us (*) |        14.6 us
-----------------------------------------+-------------+---------------

---------------------------------+-------------+---------------
surrogatepass: "\udcff" * length |      before |          after
---------------------------------+-------------+---------------
length=10**1                     | 3.71 us (*) |  306 ns (-92%)
length=10**3                     |  289 us (*) | 2.61 us (-99%)
length=10**2                     | 28.9 us (*) |  532 ns (-98%)
length=10**4                     | 2.88 ms (*) | 22.4 us (-99%)
---------------------------------+-------------+---------------
Total                            |  3.2 ms (*) | 25.8 us (-99%)
---------------------------------+-------------+---------------

---------------------------------------+-------------+---------------
surrogatepass: "a" * length + "\udcff" |      before |          after
---------------------------------------+-------------+---------------
length=10**1                           | 1.16 us (*) |  299 ns (-74%)
length=10**3                           | 2.36 us (*) | 1.59 us (-32%)
length=10**2                           | 1.27 us (*) |  413 ns (-68%)
length=10**4                           | 10.6 us (*) | 12.3 us (+16%)
---------------------------------------+-------------+---------------
Total                                  | 15.4 us (*) |  14.6 us (-5%)
---------------------------------------+-------------+---------------

---------------------------------------------------+-------------+---------------
surrogatepass: ("a" * 99 + "\udcff" * 99) * length |      before |          after
---------------------------------------------------+-------------+---------------
length=10**1                                       |  289 us (*) | 3.99 us (-99%)
length=10**3                                       | 28.5 ms (*) |  362 us (-99%)
length=10**2                                       | 2.86 ms (*) | 36.7 us (-99%)
length=10**4                                       |  287 ms (*) | 5.18 ms (-98%)
---------------------------------------------------+-------------+---------------
Total                                              |  319 ms (*) | 5.59 ms (-98%)
---------------------------------------------------+-------------+---------------

----------------------------------------------+-------------+---------------
surrogatepass: ("\udcff" * 99 + "a") * length |      before |          after
----------------------------------------------+-------------+---------------
length=10**1                                  |  288 us (*) | 2.91 us (-99%)
length=10**3                                  | 28.5 ms (*) |  242 us (-99%)
length=10**2                                  | 2.86 ms (*) | 24.7 us (-99%)
length=10**4                                  |  284 ms (*) | 2.53 ms (-99%)
----------------------------------------------+-------------+---------------
Total                                         |  316 ms (*) |  2.8 ms (-99%)
----------------------------------------------+-------------+---------------

---------------------------------------+-------------+---------------
surrogatepass: "\udcff" + "a" * length |      before |          after
---------------------------------------+-------------+---------------
length=10**1                           | 1.13 us (*) |  301 ns (-73%)
length=10**3                           |  2.3 us (*) | 1.59 us (-31%)
length=10**2                           | 1.24 us (*) |  409 ns (-67%)
length=10**4                           | 10.6 us (*) | 12.1 us (+15%)
---------------------------------------+-------------+---------------
Total                                  | 15.2 us (*) |  14.4 us (-5%)
---------------------------------------+-------------+---------------

------------------------------------+-------------+---------------
backslashreplace: "\udcff" * length |      before |          after
------------------------------------+-------------+---------------
length=10**1                        | 4.28 us (*) | 1.58 us (-63%)
length=10**3                        |  320 us (*) | 11.1 us (-97%)
length=10**2                        | 32.3 us (*) | 2.56 us (-92%)
length=10**4                        | 3.17 ms (*) | 96.6 us (-97%)
------------------------------------+-------------+---------------
Total                               | 3.52 ms (*) |  112 us (-97%)
------------------------------------+-------------+---------------

------------------------------------------+-------------+---------------
backslashreplace: "a" * length + "\udcff" |      before |          after
------------------------------------------+-------------+---------------
length=10**1                              | 1.44 us (*) |        1.47 us
length=10**3                              | 2.43 us (*) | 2.77 us (+14%)
length=10**2                              | 1.52 us (*) |  1.64 us (+8%)
length=10**4                              | 10.6 us (*) | 13.3 us (+25%)
------------------------------------------+-------------+---------------
Total                                     |   16 us (*) | 19.2 us (+20%)
------------------------------------------+-------------+---------------

------------------------------------------------------+-------------+---------------
backslashreplace: ("a" * 99 + "\udcff" * 99) * length |      before |          after
------------------------------------------------------+-------------+---------------
length=10**1                                          |  316 us (*) |   16 us (-95%)
length=10**3                                          | 31.3 ms (*) | 1.46 ms (-95%)
length=10**2                                          | 3.14 ms (*) |  147 us (-95%)
length=10**4                                          |  313 ms (*) | 15.3 ms (-95%)
------------------------------------------------------+-------------+---------------
Total                                                 |  347 ms (*) | 16.9 ms (-95%)
------------------------------------------------------+-------------+---------------

-------------------------------------------------+-------------+---------------
backslashreplace: ("\udcff" * 99 + "a") * length |      before |          after
-------------------------------------------------+-------------+---------------
length=10**1                                     |  317 us (*) | 14.7 us (-95%)
length=10**3                                     | 31.3 ms (*) | 1.34 ms (-96%)
length=10**2                                     | 3.17 ms (*) |  135 us (-96%)
length=10**4                                     |  313 ms (*) | 13.8 ms (-96%)
-------------------------------------------------+-------------+---------------
Total                                            |  347 ms (*) | 15.3 ms (-96%)
-------------------------------------------------+-------------+---------------

------------------------------------------+-------------+---------------
backslashreplace: "\udcff" + "a" * length |      before |          after
------------------------------------------+-------------+---------------
length=10**1                              | 1.43 us (*) |        1.45 us
length=10**3                              | 2.36 us (*) |  2.58 us (+9%)
length=10**2                              | 1.51 us (*) |        1.57 us
length=10**4                              | 10.5 us (*) | 13.2 us (+26%)
------------------------------------------+-------------+---------------
Total                                     | 15.8 us (*) | 18.8 us (+19%)
------------------------------------------+-------------+---------------

------------------------------------------------------+--------------+----------------
Summary                                               |       before |           after
------------------------------------------------------+--------------+----------------
ignore: "\udcff" * length                             |  2.66 ms (*) | 8.19 us (-100%)
ignore: "a" * length + "\udcff"                       |    15 us (*) |         14.6 us
ignore: ("a" * 99 + "\udcff" * 99) * length           |   265 ms (*) |  2.82 ms (-99%)
ignore: ("\udcff" * 99 + "a") * length                |   263 ms (*) |  930 us (-100%)
ignore: "\udcff" + "a" * length                       |  14.9 us (*) |         14.6 us
replace: "\udcff" * length                            |  2.94 ms (*) | 8.52 us (-100%)
replace: "a" * length + "\udcff"                      |    18 us (*) |  14.7 us (-18%)
replace: ("a" * 99 + "\udcff" * 99) * length          |   293 ms (*) |  3.21 ms (-99%)
replace: ("\udcff" * 99 + "a") * length               |   290 ms (*) | 1.02 ms (-100%)
replace: "\udcff" + "a" * length                      |  15.1 us (*) |         14.7 us
surrogateescape: "\udcff" * length                    |  2.97 ms (*) |  16.3 us (-99%)
surrogateescape: "a" * length + "\udcff"              |  15.3 us (*) |         14.6 us
surrogateescape: ("a" * 99 + "\udcff" * 99) * length  |   295 ms (*) |  4.04 ms (-99%)
surrogateescape: ("\udcff" * 99 + "a") * length       |   292 ms (*) |  1.93 ms (-99%)
surrogateescape: "\udcff" + "a" * length              |  15.1 us (*) |         14.6 us
surrogatepass: "\udcff" * length                      |   3.2 ms (*) |  25.8 us (-99%)
surrogatepass: "a" * length + "\udcff"                |  15.4 us (*) |   14.6 us (-5%)
surrogatepass: ("a" * 99 + "\udcff" * 99) * length    |   319 ms (*) |  5.59 ms (-98%)
surrogatepass: ("\udcff" * 99 + "a") * length         |   316 ms (*) |   2.8 ms (-99%)
surrogatepass: "\udcff" + "a" * length                |  15.2 us (*) |   14.4 us (-5%)
backslashreplace: "\udcff" * length                   |  3.52 ms (*) |   112 us (-97%)
backslashreplace: "a" * length + "\udcff"             |    16 us (*) |  19.2 us (+20%)
backslashreplace: ("a" * 99 + "\udcff" * 99) * length |   347 ms (*) |  16.9 ms (-95%)
backslashreplace: ("\udcff" * 99 + "a") * length      |   347 ms (*) |  15.3 ms (-96%)
backslashreplace: "\udcff" + "a" * length             |  15.8 us (*) |  18.8 us (+19%)
------------------------------------------------------+--------------+----------------
Total                                                 | 3.04 sec (*) |  54.9 ms (-98%)
------------------------------------------------------+--------------+----------------

----------

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

From report at bugs.python.org  Thu Oct  1 14:15:11 2015
From: report at bugs.python.org (Mathieu Sornay)
Date: Thu, 01 Oct 2015 12:15:11 +0000
Subject: [issue23749] asyncio missing wrap_socket (starttls)
In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za>
Message-ID: <1443701711.25.0.285818076215.issue23749@psf.upfronthosting.co.za>


Changes by Mathieu Sornay <msornay at gmail.com>:


----------
nosy: +msornay

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

From report at bugs.python.org  Thu Oct  1 14:36:49 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 01 Oct 2015 12:36:49 +0000
Subject: [issue25256] Add sys.debug_build public variable to check if Python
 was compiled in debug mode
In-Reply-To: <1443446100.69.0.307482207939.issue25256@psf.upfronthosting.co.za>
Message-ID: <1443703009.43.0.509479061403.issue25256@psf.upfronthosting.co.za>


Berker Peksag added the comment:

LGTM

> Alternative: Add a new sys.implementation.debug_build flag.

According to the sys.implementation documentation and PEP 421, we can only add a private attribute without writing a PEP. But I find sys.implementation._debug_build too long and ``from sys import implementation; implementation._debug_build``(or ``from sys import implementation as i; i._debug_build``) is also not easy to write. So I'm +1 to sys.debug_build.

I left two trivial review comments on Rietveld.

----------
nosy: +berker.peksag
stage: patch review -> commit review

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

From report at bugs.python.org  Thu Oct  1 14:47:04 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 12:47:04 +0000
Subject: [issue25267] Optimize UTF-8 encoder with error handlers
In-Reply-To: <1443526234.91.0.845116536507.issue25267@psf.upfronthosting.co.za>
Message-ID: <1443703624.45.0.207735763052.issue25267@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, the default handler for errror handlers uses a loop to check for non-ASCII characters. It can be replaced with PyUnicode_IS_ASCII(str) which has a complexity O(1). Done in new patch.

----------
Added file: http://bugs.python.org/file40647/utf8_encoder_errors-3.patch

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

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: [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 15:46:08 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 01 Oct 2015 13:46:08 +0000
Subject: [issue16701] Docs missing the behavior of += (in-place add) for lists.
In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za>
Message-ID: <1443707168.38.0.937438747369.issue16701@psf.upfronthosting.co.za>


R. David Murray added the comment:

Looks good to me.

----------

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

From report at bugs.python.org  Thu Oct  1 15:55:34 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 01 Oct 2015 13:55:34 +0000
Subject: [issue25288] readline.py file in current directory caused unexpected
 code execution.
In-Reply-To: <1443691601.94.0.65090362489.issue25288@psf.upfronthosting.co.za>
Message-ID: <1443707734.67.0.991529779458.issue25288@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is not a bug, this is the way python works.  When running in interactive mode (only) the current directory is first on the path.

Now, should this behavior be changed?  I think we've discussed this before and decided not to change it (for backward compatibility reasons), but I think there was dissent and that increasing emphasis on security since that discussion might argue for a different outcome.  It's a python-dev mailing list level issue, in any case.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Thu Oct  1 16:03:10 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 01 Oct 2015 14:03:10 +0000
Subject: [issue25288] readline.py file in current directory caused unexpected
 code execution.
In-Reply-To: <1443691601.94.0.65090362489.issue25288@psf.upfronthosting.co.za>
Message-ID: <1443708190.15.0.161320190764.issue25288@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, so much for my memory :(.

The actual discussion was in issue 12238, where *my* conclusion was that this should be fixed (readline should be special cased), but the issue is still open.

Patches welcome :)

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Readline module loading in interactive mode

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

From report at bugs.python.org  Thu Oct  1 16:03:50 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 01 Oct 2015 14:03:50 +0000
Subject: [issue12238] Readline module loading in interactive mode
In-Reply-To: <1307015860.03.0.129842780518.issue12238@psf.upfronthosting.co.za>
Message-ID: <1443708230.13.0.110185874234.issue12238@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> needs patch
versions: +Python 3.5, Python 3.6 -Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Oct  1 16:05:34 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 01 Oct 2015 14:05:34 +0000
Subject: [issue12238] Readline module loading in interactive mode
In-Reply-To: <1307015860.03.0.129842780518.issue12238@psf.upfronthosting.co.za>
Message-ID: <1443708334.09.0.493148814927.issue12238@psf.upfronthosting.co.za>


R. David Murray added the comment:

This issue was reported again in issue 25288.

To summarize: the cwd should only be used for imports *after* the command prompt is displayed, and readline is imported *before* the prompt is displayed but currently is imported from the cwd.  This should be fixed.

----------

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

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: [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 16:58:55 2015
From: report at bugs.python.org (Jeremy Kloth)
Date: Thu, 01 Oct 2015 14:58:55 +0000
Subject: [issue25289] test_strptime hangs sometimes on AMD64 Windows7 SP1 3.x
 buildbot
In-Reply-To: <1443704109.85.0.472487491984.issue25289@psf.upfronthosting.co.za>
Message-ID: <1443711535.81.0.817034341721.issue25289@psf.upfronthosting.co.za>


Jeremy Kloth added the comment:

The system is a dedicated Quad CPU @2.66GHz with 8GB RAM and running the tests on an SSD.  I doubt it is the hardware.

Please note, it is the only 64-bit Windows buildbot AND the only multi-core Windows buildbot.  So it catches lots of things that most others do not.

Last chance I had to find the missing test, it was test__locale.

Also note that 3.5 is passing just fine, so it is something particular to the 3.x branch.

----------
nosy: +jkloth

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

From report at bugs.python.org  Thu Oct  1 17:46:45 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 15:46:45 +0000
Subject: [issue25289] test_strptime hangs sometimes on AMD64 Windows7 SP1 3.x
 buildbot
In-Reply-To: <1443704109.85.0.472487491984.issue25289@psf.upfronthosting.co.za>
Message-ID: <1443714405.94.0.512612713635.issue25289@psf.upfronthosting.co.za>


STINNER Victor added the comment:

By the way, I'm surprised how slow is this buildbot. On Linux, running the whole test suite (399 tests) takes less than 5 minutes with -j4 on my PC (Intel i7-2600 @ 3.40GHz with 12 GB of RAM).

Is Python much slower on Windows? Or the buildbot CPU is *much* slower than mine?

----------

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

From report at bugs.python.org  Thu Oct  1 17:58:23 2015
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 01 Oct 2015 15:58:23 +0000
Subject: [issue25289] test_strptime hangs sometimes on AMD64 Windows7 SP1 3.x
 buildbot
In-Reply-To: <1443704109.85.0.472487491984.issue25289@psf.upfronthosting.co.za>
Message-ID: <1443715103.17.0.536301983865.issue25289@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Jeremy Kloth wrote:
> Please note, it is the only 64-bit Windows buildbot

That's not true anymore; in fact, all but David Bolen's XP and Windows 7 bots are 64-bit.  Yours is the one one in the 'stable' set, but that classification is a bit out of date for the whole set.  Current 64-bit Windows bots are yours, David Bolen's Windows8 and Windows10 bots, and my Windows8.1 Non-Debug bot.

> AND the only multi-core Windows buildbot.

This is still true, though.

Victor Stinner wrote:
> Is Python much slower on Windows?

I think the test suite is significantly slower on Windows; I'm not certain about Python itself.  It routinely takes well over 20 minutes on my Windows machines.  The fact that the bot in question compiles in Debug configuration may also be playing into it; Debug config links with the debug CRT, which enables a bunch of extra checks at the CRT level.

----------

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

From report at bugs.python.org  Thu Oct  1 18:07:58 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 01 Oct 2015 16:07:58 +0000
Subject: [issue15663] Investigate providing Tcl/Tk 8.6 with OS X installers
In-Reply-To: <1345022434.53.0.691858342769.issue15663@psf.upfronthosting.co.za>
Message-ID: <1443715678.05.0.579467098747.issue15663@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

W.r.t. install_name_tool: macholib (PyPI project) contains functionality to do this work in pure python.   

I do not propose to include macholib in the stdlib, it is too special purpose and not everyone that has provided patches is a CPython contributor (although the majority of the work was done by Bob Ippolito)

----------

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

From report at bugs.python.org  Thu Oct  1 18:08:58 2015
From: report at bugs.python.org (John Beck)
Date: Thu, 01 Oct 2015 16:08:58 +0000
Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2)
 on Solaris 11.3 and newer
In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za>
Message-ID: <1443715738.4.0.0659646192796.issue25003@psf.upfronthosting.co.za>


John Beck added the comment:

Confirmed that test_os runs cleanly on Solaris 12, for each of:
* 2.7.10 (plus your patch from 98454:202c827f86df)
* 3.4.3 (plus your patch from 98455:83dc79eeaf7f)
* 3.5.0 (plus your patch from 98452:835085cc28cd)
* 3.6 (tip)

----------

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

From report at bugs.python.org  Thu Oct  1 18:13:32 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 16:13:32 +0000
Subject: [issue25289] test_strptime hangs sometimes on AMD64 Windows7 SP1 3.x
 buildbot
In-Reply-To: <1443715103.17.0.536301983865.issue25289@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbtREcfYue=KQohTO7yQ570BjsPrbpy61-SLCeCLHhDVA@mail.gmail.com>


STINNER Victor added the comment:

On Linux, I also run the Python test suite with Python compiled in
debug mode. I'm forcing the -O0 flag to disable *all* compilation
optimization. All assertions are kept, etc.

Maybe the slowness comes from CRT checks, maybe.

----------

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

From report at bugs.python.org  Thu Oct  1 18:13:39 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 16:13:39 +0000
Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2)
 on Solaris 11.3 and newer
In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za>
Message-ID: <1443716019.68.0.791859077619.issue25003@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Thanks! I close the issue, it's now fixed.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Thu Oct  1 18:36:09 2015
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 01 Oct 2015 16:36:09 +0000
Subject: [issue25289] test_strptime hangs sometimes on AMD64 Windows7 SP1 3.x
 buildbot
In-Reply-To: <1443704109.85.0.472487491984.issue25289@psf.upfronthosting.co.za>
Message-ID: <1443717369.09.0.753130274347.issue25289@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I was curious, so I checked:

C:\Users\Zachary\code\hg.python.org\3.5>python.bat -m test.pystone
Running Debug|x64 interpreter...
Pystone(1.2) time for 50000 passes = 1.14142
This machine benchmarks at 43805 pystones/second

C:\Users\Zachary\code\hg.python.org\3.5>python.bat -m test.pystone
Running Release|x64 interpreter...
Pystone(1.2) time for 50000 passes = 0.421115
This machine benchmarks at 118732 pystones/second

C:\Users\Zachary\code\hg.python.org\3.5>python.bat -m test.pystone
Running PGUpdate|x64 interpreter...
Pystone(1.2) time for 50000 passes = 0.281218
This machine benchmarks at 177798 pystones/second

These were run on a Windows 8.1 Virtualbox VM on a Mac.  For reference, here's the results for the host machine using python3.5.0 from python.org:

$ python3 -m test.pystone
Pystone(1.2) time for 50000 passes = 0.413982
This machine benchmarks at 120778 pystones/second

----------

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

From report at bugs.python.org  Thu Oct  1 18:47:41 2015
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 01 Oct 2015 16:47:41 +0000
Subject: [issue25276] test_decimal sometimes crash on PPC64 AIX 3.x
In-Reply-To: <1443605165.97.0.433720501229.issue25276@psf.upfronthosting.co.za>
Message-ID: <1443718061.15.0.760690455638.issue25276@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Usually these segfaults are toolchain bugs (I've had at least 8,
including gcc, suncc, libc...).


Just a couple of observations:

  - The bot builds with -DCONFIG_32=1 -DANSI=1 despite being PPC64.

  - When we had an AIX snakebite machine, the xlc compile worked on
    AIX (using about 50 obscure command line arguments).

  - In the default build, libmpdec functions use a lot of stack
    memory (for optimization while avoiding alloca). But there are
    no recursive tests, so a stack overflow would seem unlikely.

----------
nosy: +David.Edelsohn

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

From report at bugs.python.org  Thu Oct  1 19:32:35 2015
From: report at bugs.python.org (John Gray)
Date: Thu, 01 Oct 2015 17:32:35 +0000
Subject: [issue14576] IDLE: inconsistent use of HOMEDRIVE, HOMEPATH,
 and USERPROFILE on Windows
In-Reply-To: <1334400065.92.0.605072928338.issue14576@psf.upfronthosting.co.za>
Message-ID: <1443720755.36.0.837711620796.issue14576@psf.upfronthosting.co.za>


John Gray added the comment:

I hit this issue with an "H:" homedrive that is on a network share, and then in Windows is using "offline files" to keep a local copy.   .idlerc was not cached so IDLE worked when online/connected to my work network but not when I was offline. 

The temporary workaround was to mark .idlerc as "available offline" when connected.  I wanted to document this in case others hit this scenario.  

I also noticed that there is a .idlerc directory created in my local user directory c:\users\[username\.idlerc.  This one has the recent-files.lst in it.  So IDLE is creating two copies of .idlerc - one in the environment-variable-defined (and roaming) home directory, and one in the default local user directory.   I would suggest that as this bug is investigated, you keep track of both instances of .idlerc.

----------
nosy: +John Gray

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

From report at bugs.python.org  Thu Oct  1 19:35:22 2015
From: report at bugs.python.org (John Gray)
Date: Thu, 01 Oct 2015 17:35:22 +0000
Subject: [issue14576] IDLE: inconsistent use of HOMEDRIVE, HOMEPATH,
 and USERPROFILE on Windows
In-Reply-To: <1334400065.92.0.605072928338.issue14576@psf.upfronthosting.co.za>
Message-ID: <1443720922.47.0.564054096877.issue14576@psf.upfronthosting.co.za>


John Gray added the comment:

For the h: drive issue mentioned above:  This was on Python 2.7.10.

----------

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

From report at bugs.python.org  Thu Oct  1 19:40:20 2015
From: report at bugs.python.org (John Gray)
Date: Thu, 01 Oct 2015 17:40:20 +0000
Subject: [issue8231] Unable to run IDLE without write-access to home directory
In-Reply-To: <1269531569.44.0.352644957859.issue8231@psf.upfronthosting.co.za>
Message-ID: <1443721220.25.0.857053898394.issue8231@psf.upfronthosting.co.za>


John Gray added the comment:

See Issue14576 which is the same underlying issue.

----------
nosy: +John Gray

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

From report at bugs.python.org  Thu Oct  1 20:05:32 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 01 Oct 2015 18:05:32 +0000
Subject: [issue25272] asyncio tests are getting noisy
In-Reply-To: <1443553151.38.0.791479091232.issue25272@psf.upfronthosting.co.za>
Message-ID: <1443722732.27.0.849648918745.issue25272@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Or call gc.collect() in that TestCase.setUp()?

----------

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

From report at bugs.python.org  Thu Oct  1 20:35:53 2015
From: report at bugs.python.org (Steven Barker)
Date: Thu, 01 Oct 2015 18:35:53 +0000
Subject: [issue23447] Import fails when doing a circular import involving an
 `import *`
In-Reply-To: <1423679925.56.0.995999383567.issue23447@psf.upfronthosting.co.za>
Message-ID: <1443724553.05.0.145990084922.issue23447@psf.upfronthosting.co.za>


Steven Barker added the comment:

Thanks for looking at the issue Brett.

I think you're right that your patch has incorrect semantics, since it doesn't save the value to the provided namespace if it had to go through the special path to find the name. I think my patch got that part right (though I definitely missed one PyUnicode_Check).

I've just noticed that our patches may not always do the right thing in all error situations. They may return -1 without setting an exception (or perhaps passing on a strange one from an internal call) if there's something weird going on like `__name__` not existing or not being a string.

I'm attaching a new version of my patch that moves the PyErr_Format call down to the later check for `value == NULL`. This handles both the basic case where nothing strange goes on but the requested name is not found, and the weird cases where unexpected stuff goes wrong. It will replace any errors raised by the earlier code with an ImportError. I think an ImportError is the appropriate exception for most error cases, but perhaps some internal errors should not be overwritten and more complicated error logic is needed.

I also notice that the code in the "import_from" function (from which I borrowed heavily for my patch) was changed in one of the 3.5rc patches to have new error handling (it raises ImportError more often I think). I don't see an obvious way to copy its new error logic to import_all_from, but my C coding skills are rather rusty so I could be missing an easy approach.

----------
Added file: http://bugs.python.org/file40649/23447_4.diff

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

From report at bugs.python.org  Thu Oct  1 20:42:59 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 01 Oct 2015 18:42:59 +0000
Subject: [issue22413] Bizarre StringIO(newline="\r\n") translation
In-Reply-To: <1410750243.44.0.979805676788.issue22413@psf.upfronthosting.co.za>
Message-ID: <1443724979.44.0.281242591082.issue22413@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I don't see a reason to deprecate anything. Can you write up in one paragraph how StringIO's newline flag differs from the one to TextIOWrapper? (What happens to the initial value is a separate issue AFAIC.)

----------

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

From report at bugs.python.org  Thu Oct  1 21:39:52 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Oct 2015 19:39:52 +0000
Subject: [issue25097] test_logging may fail with 'Access is denied' when
 pywin32 is installed
In-Reply-To: <1442204467.58.0.479620846783.issue25097@psf.upfronthosting.co.za>
Message-ID: <20151001193949.81635.71831@psf.io>


Roundup Robot added the comment:

New changeset 72c57c120c19 by Vinay Sajip in branch '3.4':
Fixes #25097: Windows test is skipped if there are insufficient privileges, rather than failing.
https://hg.python.org/cpython/rev/72c57c120c19

New changeset b54528d8d8c3 by Vinay Sajip in branch '3.5':
Fixes #25097: Merged fi from 3.4.
https://hg.python.org/cpython/rev/b54528d8d8c3

New changeset 757baaedc043 by Vinay Sajip in branch 'default':
Fixes #25097: Merged fix from 3.5.
https://hg.python.org/cpython/rev/757baaedc043

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Oct  1 21:54:18 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Oct 2015 19:54:18 +0000
Subject: [issue25256] Add sys.debug_build public variable to check if Python
 was compiled in debug mode
In-Reply-To: <1443446100.69.0.307482207939.issue25256@psf.upfronthosting.co.za>
Message-ID: <1443729258.26.0.0844543421142.issue25256@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I don't like this. The sys module is one of most used module, but it has too many members, and adding yet one makes the situation worse.

>>> len(dir(sys))
81

Checking for debug mode is not often needed, and mainly in tests. Current way ``hasattr(sys, 'gettotalrefcount')`` works good. You also can check ``'d' in sys.abiflags`` if it looks cleaner to you. Or add a member to test.support.

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Thu Oct  1 21:55:03 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Oct 2015 19:55:03 +0000
Subject: [issue24884] Add method reopenFile() in WatchedFileHandler class
In-Reply-To: <1439890614.7.0.380949664782.issue24884@psf.upfronthosting.co.za>
Message-ID: <20151001195500.31193.76561@psf.io>


Roundup Robot added the comment:

New changeset 6d61b057c375 by Vinay Sajip in branch 'default':
Closes #24884: refactored WatchedFileHandler file reopening into a separate method, based on a suggestion and patch by Marian Horban.
https://hg.python.org/cpython/rev/6d61b057c375

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

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: [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:04:44 2015
From: report at bugs.python.org (Oleg)
Date: Thu, 01 Oct 2015 20:04:44 +0000
Subject: [issue25291] ssl socket gets into broken state when client exits
 during handshake
In-Reply-To: <1443729479.04.0.835148542508.issue25291@psf.upfronthosting.co.za>
Message-ID: <1443729884.49.0.791488246249.issue25291@psf.upfronthosting.co.za>


Oleg added the comment:

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.

----------
title: better Exception message for certain task termination scenario -> ssl socket gets into broken state when client exits during handshake
type: enhancement -> 
Added file: http://bugs.python.org/file40651/example_files.tar.gz

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

From report at bugs.python.org  Thu Oct  1 22:05:42 2015
From: report at bugs.python.org (Oleg)
Date: Thu, 01 Oct 2015 20:05:42 +0000
Subject: [issue25291] ssl socket gets into broken state when client exits
 during handshake
In-Reply-To: <1443729479.04.0.835148542508.issue25291@psf.upfronthosting.co.za>
Message-ID: <1443729942.57.0.84942083493.issue25291@psf.upfronthosting.co.za>


Oleg added the comment:

Please disregard previous comment!(or delete it),
i wanted to create new issue instead!

----------

_______________________________________
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: [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  Thu Oct  1 22:07:47 2015
From: report at bugs.python.org (Oleg)
Date: Thu, 01 Oct 2015 20:07:47 +0000
Subject: [issue25291] better Exception message for certain task termination
 scenario
In-Reply-To: <1443729479.04.0.835148542508.issue25291@psf.upfronthosting.co.za>
Message-ID: <1443730067.18.0.0360356672355.issue25291@psf.upfronthosting.co.za>


Changes by Oleg <email at olegk.ca>:


----------
title: ssl socket gets into broken state when client exits during handshake -> better Exception message for certain task termination scenario

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

From report at bugs.python.org  Thu Oct  1 22:09:22 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 01 Oct 2015 20:09:22 +0000
Subject: [issue25291] better Exception message for certain task termination
 scenario
In-Reply-To: <1443729479.04.0.835148542508.issue25291@psf.upfronthosting.co.za>
Message-ID: <1443730162.9.0.00672458707043.issue25291@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Can you fix the issue title or do you want me to fix it? And did you also add a file you meant to go to a different issue? (Maybe link to the new issue and I can figure it out.)

----------

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

From report at bugs.python.org  Thu Oct  1 22:10:08 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 01 Oct 2015 20:10:08 +0000
Subject: [issue25291] better Exception message for certain task termination
 scenario
In-Reply-To: <1443729479.04.0.835148542508.issue25291@psf.upfronthosting.co.za>
Message-ID: <1443730208.35.0.246390276926.issue25291@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


Removed file: http://bugs.python.org/file40651/example_files.tar.gz

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

From report at bugs.python.org  Thu Oct  1 22:10:22 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 01 Oct 2015 20:10:22 +0000
Subject: [issue25291] better Exception message for certain task termination
 scenario
In-Reply-To: <1443729479.04.0.835148542508.issue25291@psf.upfronthosting.co.za>
Message-ID: <1443730222.93.0.794208271509.issue25291@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
Removed message: http://bugs.python.org/msg252050

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

From report at bugs.python.org  Thu Oct  1 22:10:37 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 01 Oct 2015 20:10:37 +0000
Subject: [issue25291] better Exception message for certain task termination
 scenario
In-Reply-To: <1443729479.04.0.835148542508.issue25291@psf.upfronthosting.co.za>
Message-ID: <1443730237.03.0.797025353804.issue25291@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
Removed message: http://bugs.python.org/msg252051

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

From report at bugs.python.org  Thu Oct  1 22:11:20 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 01 Oct 2015 20:11:20 +0000
Subject: [issue25291] better Exception message for certain task termination
 scenario
In-Reply-To: <1443729479.04.0.835148542508.issue25291@psf.upfronthosting.co.za>
Message-ID: <1443730280.77.0.399247297072.issue25291@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
Removed message: http://bugs.python.org/msg252053

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

From report at bugs.python.org  Thu Oct  1 22:11:55 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 01 Oct 2015 20:11:55 +0000
Subject: [issue25291] better Exception message for certain task termination
 scenario
In-Reply-To: <1443729479.04.0.835148542508.issue25291@psf.upfronthosting.co.za>
Message-ID: <1443730315.26.0.127373996187.issue25291@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

(OK, issue should be all cleaned up. :-)

----------

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

From report at bugs.python.org  Thu Oct  1 22:12:12 2015
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 01 Oct 2015 20:12:12 +0000
Subject: [issue25097] test_logging may fail with 'Access is denied' when
 pywin32 is installed
In-Reply-To: <1442204467.58.0.479620846783.issue25097@psf.upfronthosting.co.za>
Message-ID: <1443730332.79.0.263248838593.issue25097@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Thu Oct  1 22:15:05 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 20:15:05 +0000
Subject: [issue25256] Add sys.debug_build public variable to check if Python
 was compiled in debug mode
In-Reply-To: <1443446100.69.0.307482207939.issue25256@psf.upfronthosting.co.za>
Message-ID: <1443730505.1.0.815684499235.issue25256@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I don't like this. The sys module is one of most used module, but it has too many members, and adding yet one makes the situation worse.

Hum, what is the problem of adding a symbol? How does it make the module less usable?

> Checking for debug mode is not often needed, and mainly in tests.

My patch changes distutils, sysconfig and warnings modules, I agree that other changes are only in tests.

>  Current way ``hasattr(sys, 'gettotalrefcount')`` works good.

For me it looks more like an hack than a reliable check.

> You also can check ``'d' in sys.abiflags`` if it looks cleaner to you.

For me, it doesn't look correct to have various ways to check if python was compiled in debug mode. It doesn't look portable neither. I prefer to use a flag which works on any version of Python (>= 3.6) and any implementation of Python.

I don't think that PyPy wants to implement sys.gettotalrefcount() for example, but PyPy may want to mimick CPython when it's compiled in debug mode. For example, display warnings by default in debug mode.

----------

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

From report at bugs.python.org  Thu Oct  1 22:15:45 2015
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 01 Oct 2015 20:15:45 +0000
Subject: [issue25097] test_logging may fail with 'Access is denied' when
 pywin32 is installed
In-Reply-To: <1442204467.58.0.479620846783.issue25097@psf.upfronthosting.co.za>
Message-ID: <1443730545.88.0.932244844944.issue25097@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thanks, Vinay!

----------
stage: needs patch -> resolved
versions: +Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Oct  1 22:27:16 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Oct 2015 20:27:16 +0000
Subject: [issue25274] sys.setrecursionlimit() must fail if the current
 recursion depth is higher than the new low-water mark
In-Reply-To: <1443570348.5.0.971307491137.issue25274@psf.upfronthosting.co.za>
Message-ID: <1443731236.91.0.680334629351.issue25274@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

_Py_MakeEndRecCheck() was changed in issue5392 (noised Antoine as a committer). There are many ways to make it monotonic.

#define _Py_MakeEndRecCheck(x) \
	(--(x) < ((_Py_CheckRecursionLimit > 200) \
		? (_Py_CheckRecursionLimit - 25) \
		: (3 * (_Py_CheckRecursionLimit >> 2))))

#define _Py_MakeEndRecCheck(x) \
	(--(x) < ((_Py_CheckRecursionLimit > 100) \
		? (_Py_CheckRecursionLimit - 50) \
		: (_Py_CheckRecursionLimit >> 1)))

Since the formula is so complex, it would be worth to extract common part from _Py_MakeEndRecCheck() and sys_setrecursionlimit(). Otherwise the code can become desynchronized.

The error message still looks confusing to me. May be short it to "limit is too low"? Noised David as grammar expert.

Why not have an hardcoded minimum limit? Current recursion depth and therefore minimal recursion limit are implementation defined and can depend on a way how the module is executed (run a script, import a module, run with runpy or IDLE, etc). May be interpret the limit relatively to current recursion depth?

----------
nosy: +pitrou, r.david.murray

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

From report at bugs.python.org  Thu Oct  1 23:20:10 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Oct 2015 21:20:10 +0000
Subject: [issue25267] Optimize UTF-8 encoder with error handlers
In-Reply-To: <1443526234.91.0.845116536507.issue25267@psf.upfronthosting.co.za>
Message-ID: <20151001212007.3650.32826@psf.io>


Roundup Robot added the comment:

New changeset 2b5357b38366 by Victor Stinner in branch 'default':
Issue #25267: The UTF-8 encoder is now up to 75 times as fast for error
https://hg.python.org/cpython/rev/2b5357b38366

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Oct  1 23:24:45 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 21:24:45 +0000
Subject: [issue24870] Optimize ascii and latin1 decoder with surrogateescape
 and surrogatepass error handlers
In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za>
Message-ID: <1443734685.05.0.915953255039.issue24870@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I just pushed my patch to optimize the UTF-8 encoder with error handlers: see the issue #25267. It's up to 70 times as fast. The patch was based on Serhiy's work: faster_surrogates_hadling.patch attached to this issue.

----------

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

From report at bugs.python.org  Thu Oct  1 23:27:18 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 21:27:18 +0000
Subject: [issue25267] Optimize UTF-8 encoder with error handlers
In-Reply-To: <1443526234.91.0.845116536507.issue25267@psf.upfronthosting.co.za>
Message-ID: <1443734838.34.0.382449859637.issue25267@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I pushed my optimization.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Thu Oct  1 23:50:17 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 21:50:17 +0000
Subject: [issue25274] sys.setrecursionlimit() must fail if the current
 recursion depth is higher than the new low-water mark
In-Reply-To: <1443570348.5.0.971307491137.issue25274@psf.upfronthosting.co.za>
Message-ID: <1443736216.99.0.647483176399.issue25274@psf.upfronthosting.co.za>


STINNER Victor added the comment:

sys_setrecursionlimit-4.patch:

- enhance documentation and comments
- combined with end_rec_check.patch: make the lower-water mark monotonic
- add _Py_RecursionLimitLowerWaterMark() macro used by _Py_MakeEndRecCheck() and sys.setrecursionlimit()

----------
Added file: http://bugs.python.org/file40653/sys_setrecursionlimit-4.patch

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

From report at bugs.python.org  Thu Oct  1 23:54:33 2015
From: report at bugs.python.org (Steve Dower)
Date: Thu, 01 Oct 2015 21:54:33 +0000
Subject: [issue23546] Windows, 'Edit with IDLE',
 and multiple installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1443736473.17.0.54612830949.issue23546@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
assignee:  -> steve.dower
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Oct  1 23:55:03 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 01 Oct 2015 21:55:03 +0000
Subject: [issue14576] IDLE: inconsistent use of HOMEDRIVE, HOMEPATH,
 and USERPROFILE on Windows
In-Reply-To: <1334400065.92.0.605072928338.issue14576@psf.upfronthosting.co.za>
Message-ID: <1443736503.71.0.880113941312.issue14576@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

John, thank you for the additional information.  2 copies of .idlerc is definitely bad.

----------
versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Oct  1 23:55:05 2015
From: report at bugs.python.org (Steve Dower)
Date: Thu, 01 Oct 2015 21:55:05 +0000
Subject: [issue25125] "Edit with IDLE" does not work for shortcuts
In-Reply-To: <1442318370.13.0.116980940121.issue25125@psf.upfronthosting.co.za>
Message-ID: <1443736505.51.0.206184102458.issue25125@psf.upfronthosting.co.za>


Steve Dower added the comment:

Terry (nosied) made the request for the context menu in issue 23546, so if you want it removed you'll need to convince him.

Personally I prefer the context menu, but I typically replace the default file association with one that's better for me anyway so I'm not really bothered either way.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Thu Oct  1 23:59:08 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 21:59:08 +0000
Subject: [issue25274] sys.setrecursionlimit() must fail if the current
 recursion depth is higher than the new low-water mark
In-Reply-To: <1443570348.5.0.971307491137.issue25274@psf.upfronthosting.co.za>
Message-ID: <1443736748.0.0.463261410017.issue25274@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> _Py_MakeEndRecCheck() was changed in issue5392 (noised Antoine as a committer).

Oh, I didn't know this issue. If I am right, it's a duplicate of this issue, even if it was a little bit different because the lower-water mark was computed differently.

> There are many ways to make it monotonic.

Since I don't understand well this issue, I prefer to keep the formula unchanged for low limit (smaller than 100, or smaller than 200 with my patch) to keep the 3/4 ratio.

> Since the formula is so complex, it would be worth to extract common part from _Py_MakeEndRecCheck() and sys_setrecursionlimit(). Otherwise the code can become desynchronized.

Right, it's now done in my new patch.

> The error message still looks confusing to me. May be short it to "limit is too low"? Noised David as grammar expert.

I prefer to really explain the fact that the RecursionError is raised depending on the current recursion depth. Otherwise, I'm quite sure that someone will complain that "too low" have different values on the same PC but on two different applications.

> Why not have an hardcoded minimum limit? Current recursion depth and therefore minimal recursion limit are implementation defined and can depend on a way how the module is executed (run a script, import a module, run with runpy or IDLE, etc).

I'm not sure that you understood correctly the issue. The root cause is that you cannot call sys.setrecursionlimit(X) at recursion depth Y. There is no constant "minimum limit": it depends on the recusion depth because of how Python handles recursion error (the overflowed flag).

An alternative would be to remove completly the overflowed flag with its fatal error. It was introduced during large refactoring of Python, maybe the bug cannot occur anymore?

Again, since I don't know the whole history of how Python handles recursion error, I prefer the conservative approach of changing the minimum amount of code.

> May be interpret the limit relatively to current recursion depth?

Hum, I dislike this idea. I prefer to keep an absolute value. Otherwise, it would make Python more surprising.

----------

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

From report at bugs.python.org  Fri Oct  2 00:03:54 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 22:03:54 +0000
Subject: [issue25274] sys.setrecursionlimit() must fail if the current
 recursion depth is higher than the new low-water mark
In-Reply-To: <1443570348.5.0.971307491137.issue25274@psf.upfronthosting.co.za>
Message-ID: <1443737034.43.0.287709591548.issue25274@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> An alternative would be to remove completly the overflowed flag with its fatal error. It was introduced during large refactoring of Python, maybe the bug cannot occur anymore?

By the way, it doesn't exist in Python 2 at all. Try attached double_recursion_error.py program.


$ python2 double_recursion_error.py 
first recursion error
second recursion error


$ python3 double_recursion_error.py 
first recursion error
Fatal Python error: Cannot recover from stack overflow.

Current thread 0x00007f80a6985700 (most recent call first):
  File "double_recursion_error.py", line 5 in f
  File "double_recursion_error.py", line 5 in f
  File "double_recursion_error.py", line 5 in f
  File "double_recursion_error.py", line 5 in f
  ...
Abandon (core dumped)

----------

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

From report at bugs.python.org  Fri Oct  2 00:07:11 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 22:07:11 +0000
Subject: [issue25274] sys.setrecursionlimit() must fail if the current
 recursion depth is higher than the new low-water mark
In-Reply-To: <1443570348.5.0.971307491137.issue25274@psf.upfronthosting.co.za>
Message-ID: <1443737231.0.0.347741262835.issue25274@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The overflowed flag was introduced 8 years ago (near the release of Python 3.0) by the following changeset:

changeset:   42013:cd125fe83051
user:        Martin v. L?wis <martin at v.loewis.de>
date:        Sun Jun 10 09:51:05 2007 +0000
files:       Include/ceval.h Include/pystate.h Include/stringobject.h Include/unicodeobject.h Lib/test/test_frozen.py Lib/test/test_new.py Lib/test/test
description:
Make identifiers str (not str8) objects throughout.
This affects the parser, various object implementations,
and all places that put identifiers into C string literals.

In testing, a number of crashes occurred as code would
fail when the recursion limit was reached (such as the
Unicode interning dictionary having key/value pairs where
key is not value). To solve these, I added an overflowed
flag, which allows for 50 more recursions after the
limit was reached and the exception was raised, and
a recursion_critical flag, which indicates that recursion
absolutely must be allowed, i.e. that a certain call
must not cause a stack overflow exception.

There are still some places where both str and str8 are
accepted as identifiers; these should eventually be
removed.

----------

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

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: [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 00:20:35 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Oct 2015 22:20:35 +0000
Subject: [issue25165] Windows uninstallation should not remove launcher if
 other versions remain
In-Reply-To: <1442566984.06.0.904088337084.issue25165@psf.upfronthosting.co.za>
Message-ID: <20151001222032.3664.8755@psf.io>


Roundup Robot added the comment:

New changeset a2d30dfa46a7 by Steve Dower in branch '3.5':
Issue #25165: Windows uninstallation should not remove launcher if other versions remain
https://hg.python.org/cpython/rev/a2d30dfa46a7

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Oct  2 00:21:01 2015
From: report at bugs.python.org (Steve Dower)
Date: Thu, 01 Oct 2015 22:21:01 +0000
Subject: [issue25165] Windows uninstallation should not remove launcher if
 other versions remain
In-Reply-To: <1442566984.06.0.904088337084.issue25165@psf.upfronthosting.co.za>
Message-ID: <1443738061.85.0.316209396761.issue25165@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Oct  2 00:27:05 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 22:27:05 +0000
Subject: [issue25256] Add sys.debug_build public variable to check if Python
 was compiled in debug mode
In-Reply-To: <1443446100.69.0.307482207939.issue25256@psf.upfronthosting.co.za>
Message-ID: <1443738425.17.0.0900750608662.issue25256@psf.upfronthosting.co.za>


STINNER Victor added the comment:

FYI the sys module has 5 more symbols when CPython is compiled in debug mode:

* getobjects()
* gettotalrefcount()
* last_traceback, last_type, last_value

----------

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

From report at bugs.python.org  Fri Oct  2 00:33:26 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Oct 2015 22:33:26 +0000
Subject: [issue25256] Add sys.debug_build public variable to check if Python
 was compiled in debug mode
In-Reply-To: <1443446100.69.0.307482207939.issue25256@psf.upfronthosting.co.za>
Message-ID: <1443738806.36.0.807225334682.issue25256@psf.upfronthosting.co.za>


STINNER Victor added the comment:

>> You also can check ``'d' in sys.abiflags`` if it looks cleaner to you.

> For me, it doesn't look correct to have various ways to check if python was compiled in debug mode. It doesn't look portable neither. (...)

Oops, I didn't notice that sys.abiflags is not available on Windows!

It's the same issue with 2 solutions to this question:

http://stackoverflow.com/questions/646518/python-how-to-detect-debug-interpreter

* Checking for '_d.pyd' in imp.get_suffixes() => specific to Windows
* sys.executable.endswith("_d.exe") => again, specific to Windows :-(

That's part of my rationale in my first message, we need a portable and reliable flag to check if Python was compiled in debug mode.

By the way, the StackOverflow question comes from an user who is probably not writing a test, but an application. It means that the flag is also helpful to final users.

----------

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

From report at bugs.python.org  Fri Oct  2 00:38:58 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 01 Oct 2015 22:38:58 +0000
Subject: [issue10487] http.server doesn't process Status header from CGI
 scripts
In-Reply-To: <1290325843.93.0.000870454658653.issue10487@psf.upfronthosting.co.za>
Message-ID: <1443739138.11.0.871938945428.issue10487@psf.upfronthosting.co.za>


Martin Panter added the comment:

Issue 13893 was closed as a duplicate of this issue. There are patches and modified code there that may be worth looking at though.

----------
nosy: +martin.panter
superseder: Make CGIHTTPServer capable of redirects (and status other than 200) -> 

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

From report at bugs.python.org  Fri Oct  2 00:41:14 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 01 Oct 2015 22:41:14 +0000
Subject: [issue10485] http.server fails when query string contains addition
 '?' characters
In-Reply-To: <1290325094.43.0.114667735532.issue10485@psf.upfronthosting.co.za>
Message-ID: <1443739274.64.0.988214275526.issue10485@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> CGIRequestHandler behave incorrectly with query component consisting mutliple ?

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

From report at bugs.python.org  Fri Oct  2 01:10:21 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 01 Oct 2015 23:10:21 +0000
Subject: [issue25125] "Edit with IDLE" does not work for shortcuts
In-Reply-To: <1442318370.13.0.116980940121.issue25125@psf.upfronthosting.co.za>
Message-ID: <1443741021.67.0.752952214977.issue25125@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

In #23546, I requested a separate 'Edit with IDLE x.y' (I mis-said 'Open') on the context menu for each installed version.  I said I would be OK with one 'Edit with IDLE' entry and a submenu, as proposed by someone else.  I agree that this will be better in the long run.  In the meanwhile, I have 'Edit with IDLE' which happens to be connected to 3.4 and 'Edit with IDLE >' with a submenu with 3.5, and no option to edit with 2.7.

Thijs: The editor is basically the same in the most recent 2.7, 3.4, and 3.5 versions. So it does not matter much which Python version is used to *edit*.  But it does matter which Python version is used to *run* the file with F5. And there are bug fixes in the next 3.4 version that will make editing easier for some people.  And there will be even more changes coming in future 2.7 and 3.5 releases.

Perhaps the submenu should give the full x.y.z release number, as Idle can have new or changed features in micro releases.

----------

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

From report at bugs.python.org  Fri Oct  2 01:29:55 2015
From: report at bugs.python.org (Eric Snow)
Date: Thu, 01 Oct 2015 23:29:55 +0000
Subject: [issue12238] Readline module loading in interactive mode
In-Reply-To: <1307015860.03.0.129842780518.issue12238@psf.upfronthosting.co.za>
Message-ID: <1443742195.17.0.583833215012.issue12238@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

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

From report at bugs.python.org  Fri Oct  2 01:59:25 2015
From: report at bugs.python.org (Akira Li)
Date: Thu, 01 Oct 2015 23:59:25 +0000
Subject: [issue25286] views are not sequences
In-Reply-To: <1443677491.48.0.268151687155.issue25286@psf.upfronthosting.co.za>
Message-ID: <1443743965.6.0.192048380226.issue25286@psf.upfronthosting.co.za>


Akira Li added the comment:

Thank you for `view`, <view> hint. I did look for :term:`view` that was
obviously not enough.

The new patch contains the renamed entry in the correct place. All `view`, <view>`
occurrences dictionary view are updated now.

----------
Added file: http://bugs.python.org/file40654/dict-views-glossary-2.patch

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

From report at bugs.python.org  Fri Oct  2 02:00:10 2015
From: report at bugs.python.org (David Edelsohn)
Date: Fri, 02 Oct 2015 00:00:10 +0000
Subject: [issue25276] test_decimal sometimes crash on PPC64 AIX 3.x
In-Reply-To: <1443605165.97.0.433720501229.issue25276@psf.upfronthosting.co.za>
Message-ID: <1443744010.7.0.954776242084.issue25276@psf.upfronthosting.co.za>


David Edelsohn added the comment:

The system has 128GB of memory.  The process limits are set to unlimited for data.  AIX defaults to 32 bit, although all processors are 64 bit, so the buildbot runs as 32 bit.  What does low free memory in the buildbot mean?

I'm surprised that Python requires a huge amount of memory for the tests.  It's possible that Python needs to be built with special options to allow additional malloc space (-bmaxdata:0xN0000000).

----------

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

From report at bugs.python.org  Fri Oct  2 02:47:18 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 02 Oct 2015 00:47:18 +0000
Subject: [issue14566] run_cgi reverts to using unnormalized path
In-Reply-To: <1334257271.24.0.449019497726.issue14566@psf.upfronthosting.co.za>
Message-ID: <1443746838.71.0.029851530921.issue14566@psf.upfronthosting.co.za>


Martin Panter added the comment:

This was also reported in Issue 19435. The combination changes for Issue 19435 + Issue 21323 looks essentially like the proposed change here.

Issue 14567 remains about the double processing of paths.

----------
nosy: +martin.panter
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Directory traversal attack for CGIHTTPRequestHandler

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

From report at bugs.python.org  Fri Oct  2 03:02:47 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 02 Oct 2015 01:02:47 +0000
Subject: [issue14565] Allow multilevel subdirectories in cgi_directories
In-Reply-To: <1334254866.64.0.659489278184.issue14565@psf.upfronthosting.co.za>
Message-ID: <1443747767.66.0.366647600257.issue14565@psf.upfronthosting.co.za>


Martin Panter added the comment:

This smells like a new feature to me, because it is clearly not supported by the existing code. If you wanted to fix the existing released versions of Python, I think it would be better to clarify the documentation.

----------
nosy: +martin.panter
title: is_cgi doesn't function as documented for cgi_directories -> Allow multilevel subdirectories in cgi_directories
type: behavior -> enhancement
versions: +Python 3.6 -Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Oct  2 03:04:04 2015
From: report at bugs.python.org (Hiroki Kiyohara)
Date: Fri, 02 Oct 2015 01:04:04 +0000
Subject: [issue25288] readline.py file in current directory caused unexpected
 code execution.
In-Reply-To: <1443691601.94.0.65090362489.issue25288@psf.upfronthosting.co.za>
Message-ID: <1443747844.89.0.444610638742.issue25288@psf.upfronthosting.co.za>


Hiroki Kiyohara added the comment:

I see. Thank you very much, guys.

----------

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

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: [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:05:55 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 02 Oct 2015 03:05:55 +0000
Subject: [issue5714] http.server._url_collapse_path should live elsewhere
In-Reply-To: <1239063845.81.0.120232947257.issue5714@psf.upfronthosting.co.za>
Message-ID: <1443755155.11.0.581958086658.issue5714@psf.upfronthosting.co.za>


Martin Panter added the comment:

Some ideas for this sort of function (or perhaps a few related functions):

* Allow OS-independent handling of the path. E.g. the CGI server still has to check if each segment is a CGI script, the rest becomes PATH_INFO. Perhaps return a sequence of path segments rather than a string.
* Allow easy conversion to a valid OS path (or perhaps a pathlib object)
* Ensure that invalid and special OS filenames trigger an error (e.g. "NUL" or unsupported characters, including backslashes \, on Windows). Like a stricter version of pathlib?s is_reserved().
* Handle percent decoding

Also, see the SimpleHTTPRequestHandler.translate_path() method, and Issue 14567. There seems to be a lot of redundancy.

----------

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

From report at bugs.python.org  Fri Oct  2 05:24:37 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 02 Oct 2015 03:24:37 +0000
Subject: [issue14567] http.server query string handling is incorrect and
 inefficient
In-Reply-To: <1334260387.16.0.632012029633.issue14567@psf.upfronthosting.co.za>
Message-ID: <1443756277.21.0.00645095007107.issue14567@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think the decision on how to parse the ?path? attribute has to be left up to each request handler implementation, rather than being done blindly in BaseHTTPRequestHandler.parse_request(). The reason is there are various forms of HTTP request target that don?t actually have a path:

OPTIONS *  # Asterisk form
OPTIONS http://example.net  # Absolute form with no path nor query
CONNECT example.net:443  # Authority form

I agree that the current situation is far from ideal, and a function or method to parse a URL path should be very useful. Functions urlparse() and urlsplit() can already help with splitting off the query.

Currently there is double percent-decoding going on in the CGI server. ?GET /cgi-bin/%2574est.py? decodes to ?test.py?, when it should only decode as ?%74est.py?. This is probably a side-effect of fixing Issue 14566 and related bugs.

Also, see Issue 5714 about making this function a public API.

----------
nosy: +martin.panter
stage:  -> needs patch
versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Oct  2 05:25:52 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 02 Oct 2015 03:25:52 +0000
Subject: [issue25232] CGIRequestHandler behave incorrectly with query
 component consisting mutliple ?
In-Reply-To: <1443195881.69.0.030953923686.issue25232@psf.upfronthosting.co.za>
Message-ID: <1443756352.02.0.589948227159.issue25232@psf.upfronthosting.co.za>


Martin Panter added the comment:

The test case looks okay to me. IMO using numbers for variable names (cgi_file4 etc) is a terrible idea, but I understand you are just conforming to the existing code :)

----------

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

From report at bugs.python.org  Fri Oct  2 05:42:41 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 02 Oct 2015 03:42:41 +0000
Subject: [issue24657] CGIHTTPServer module discard continuous '/' letters from
 params given by GET method.
In-Reply-To: <1437187776.37.0.855244973055.issue24657@psf.upfronthosting.co.za>
Message-ID: <1443757361.47.0.233730613343.issue24657@psf.upfronthosting.co.za>


Martin Panter added the comment:

The patch looks like it will fix this particular bug without much negative impact. However there are plenty of other problems with this module?s URL handling, see Issue 14567. I think the translate_path(), _url_collapse_path(), is_cgi(), run_cgi(), etc functions all need a good rewrite.

Anyway it might be worth going ahead and committing this straight away, whether or not anyone is motivated to fix the wider issue later on.

----------

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

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: [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 06:43:43 2015
From: report at bugs.python.org (aj guy)
Date: Fri, 02 Oct 2015 04:43:43 +0000
Subject: [issue20476] If new email policies are used,
 default message factory should be EmailMessage
In-Reply-To: <1391292485.67.0.381493162498.issue20476@psf.upfronthosting.co.za>
Message-ID: <1443761023.85.0.099458474174.issue20476@psf.upfronthosting.co.za>


Changes by aj guy <ftfr4life at aol.com>:


----------
assignee:  -> docs at python
components: +Documentation, Library (Lib)
nosy: +aj guy, docs at python
type: behavior -> resource usage

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

From report at bugs.python.org  Fri Oct  2 07:13:48 2015
From: report at bugs.python.org (Aaron Meurer)
Date: Fri, 02 Oct 2015 05:13:48 +0000
Subject: [issue25295] functools.lru_cache raises KeyError
In-Reply-To: <1443758314.48.0.0379621558494.issue25295@psf.upfronthosting.co.za>
Message-ID: <1443762828.24.0.108805400376.issue25295@psf.upfronthosting.co.za>


Changes by Aaron Meurer <asmeurer at gmail.com>:


----------
nosy: +Aaron.Meurer

_______________________________________
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: [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 08:09:56 2015
From: report at bugs.python.org (Matt C)
Date: Fri, 02 Oct 2015 06:09:56 +0000
Subject: [issue25294] Absolute imports fail in some cases where relative
 imports would work
In-Reply-To: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>
Message-ID: <1443766196.74.0.393785141022.issue25294@psf.upfronthosting.co.za>


Changes by Matt C <matt at engineered.software>:


----------
nosy: +freshquiz

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

From report at bugs.python.org  Fri Oct  2 08:50:14 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 02 Oct 2015 06:50:14 +0000
Subject: [issue25296] Simple End-of-life guide covering all unsupported
 versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1443768614.46.0.91930377637.issue25296@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Adding Georg directly to the nosy, as I think this kind of structural question falls under his domain as the docs lead :)

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Fri Oct  2 09:09:50 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 07:09:50 +0000
Subject: [issue25296] Simple End-of-life guide covering all unsupported
 versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1443769790.56.0.973730183073.issue25296@psf.upfronthosting.co.za>


STINNER Victor added the comment:

We now putting the such page on python.org website, as PHP did?

I like the idea of being very explicit on EOL. It's a FAQ on mailing lists. Even for me, being involved in Python developments, it's not always easy to know the status of each branch. For example, I recently asked the question for Python 3.4 :-) The answer was that it will switch to security fixes only after the next 3.4.x release.

The EOL page must explain each stage of maintenance:

* development branch: any kind of change including new features
* bugfix: no new feature, only bugfixes including security fixes
* security fixes only: no more binary release, only source code release, only security fixes and some execeptional bugfixes (sorry, I don't know the exact rule for bugfixes at this stage)
* end of life: dead, no change at all

Python 2.6 reached its EOL or security fixes are still accepted?

I guess that Python <= 2.5, Python 3.0 and Python 3.1 are dead, right?

----------
nosy: +haypo

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

From report at bugs.python.org  Fri Oct  2 09:30:29 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 02 Oct 2015 07:30:29 +0000
Subject: [issue25296] Simple End-of-life guide covering all unsupported
 versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1443771029.01.0.938305595516.issue25296@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The branch status is captured in the release PEPs:

2.6 (& 3.0): https://www.python.org/dev/peps/pep-0361/
2.7: https://www.python.org/dev/peps/pep-0373/
3.1: https://www.python.org/dev/peps/pep-0375/
3.2: https://www.python.org/dev/peps/pep-0392/
3.3: https://www.python.org/dev/peps/pep-0398/
3.4: https://www.python.org/dev/peps/pep-0429/
3.5: https://www.python.org/dev/peps/pep-0478/
3.6: https://www.python.org/dev/peps/pep-0494/

The "devcycle" page in the developer guide captures the details of the difference phases: https://docs.python.org/devguide/devcycle.html

So perhaps the expedient near term solution would be to put this info on the devcycle page, and move it later?

----------

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

From report at bugs.python.org  Fri Oct  2 09:33:57 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 02 Oct 2015 07:33:57 +0000
Subject: [issue25296] Simple End-of-life guide covering all unsupported
 versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1443771237.06.0.260762882378.issue25296@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Items to capture for each unsupported or security fix only release series:

* date & version of last binary release (maintenance -> security fix only transition)
* date & version of last source-only security release (commercial redistributors are on their own for ongoing support from this point)
* link to the release PEP
* link to the upgrade guide in the next What's New doc once the next version is released

----------

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

From report at bugs.python.org  Fri Oct  2 09:55:10 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Oct 2015 07:55:10 +0000
Subject: [issue25296] Simple End-of-life guide covering all unsupported
 versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1443772510.49.0.365939557651.issue25296@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> - the main docs are version specific, while this kind of page
> should be version independent

They could still be included in the main docs with a clear link at the top that says "For the most-recently updated schedule see d.p.o/3/eol.html.".  Each version should still be correct -- it will just lack the eol dates for the newest releases.
The Unicode Consortium and the W3C do something similar (see e.g. http://www.unicode.org/reports/tr29/tr29-23.html and http://www.w3.org/TR/2014/WD-html5-20140617/).

Another option is to create a new repo where to put version-independent docs (e.g. the whatsnew, maybe even Misc/NEWS).  It shouldn't be difficult to then include these pages in the main docs.

----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Fri Oct  2 10:05:09 2015
From: report at bugs.python.org (Thijs van Dien)
Date: Fri, 02 Oct 2015 08:05:09 +0000
Subject: [issue25125] "Edit with IDLE" does not work for shortcuts
In-Reply-To: <1442318370.13.0.116980940121.issue25125@psf.upfronthosting.co.za>
Message-ID: <1443773109.96.0.42201364112.issue25125@psf.upfronthosting.co.za>


Thijs van Dien added the comment:

Terry, I'll write here not to open the old ticket (yet). I'd argue listing all IDLE's under "Open with" is still the best option, rather than yet another menu option. First of all, there is nothing conceptually different about opening the file with IDLE vs. editing it with IDLE; .txt-files open with Notepad, .ppt-files open with Powerpoint, et cetera, and the later offers both editing and "running" as well. Second, it will probably solve this issue with shortcuts because I expect "Open with" not to have the same issue as our own submenu. If we do keep the direct "Edit with IDLE" option as well, it should be quick and direct. Perhaps it would be best just to revert to the old behavior. Otherwise, we can always use the latest available IDLE and improve IDLE to offer an option to choose which version of Python to run with. A next logical step would then be to make it respect the shebang if present, and make it the default version to run with.

----------

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

From report at bugs.python.org  Fri Oct  2 10:14:41 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 02 Oct 2015 08:14:41 +0000
Subject: [issue25295] functools.lru_cache raises KeyError
In-Reply-To: <1443758314.48.0.0379621558494.issue25295@psf.upfronthosting.co.za>
Message-ID: <1443773681.38.0.0494425550971.issue25295@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +rhettinger, serhiy.storchaka
type:  -> behavior
versions: +Python 3.6

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

From report at bugs.python.org  Fri Oct  2 10:16:07 2015
From: report at bugs.python.org (ashutosh)
Date: Fri, 02 Oct 2015 08:16:07 +0000
Subject: [issue23640] int.from_bytes() is broken for subclasses
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1443773767.06.0.13987773824.issue23640@psf.upfronthosting.co.za>


ashutosh added the comment:

hi

i am ashutosh. I am running kubuntu 14.04.
before applying the patch. It failed in 2 test i.e

test___all__ 
test_re

After applying patch. It again gave me 2 error
test___all__ 
test_re

So,it worked for me.

----------
nosy: +singh_jug

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

From report at bugs.python.org  Fri Oct  2 10:23:19 2015
From: report at bugs.python.org (Nicholas H.Tollervey)
Date: Fri, 02 Oct 2015 08:23:19 +0000
Subject: [issue19006] UnitTest docs should have a single list of assertions
In-Reply-To: <1378914335.13.0.0543263347661.issue19006@psf.upfronthosting.co.za>
Message-ID: <1443774199.8.0.36280833434.issue19006@psf.upfronthosting.co.za>


Changes by Nicholas H.Tollervey <ntoll at ntoll.org>:


----------
nosy: +kushal.das, ntoll

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

From report at bugs.python.org  Fri Oct  2 10:32:24 2015
From: report at bugs.python.org (Yogesh Joshi)
Date: Fri, 02 Oct 2015 08:32:24 +0000
Subject: [issue23640] int.from_bytes() is broken for subclasses
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1443774744.54.0.635600536081.issue23640@psf.upfronthosting.co.za>


Yogesh Joshi added the comment:

I applied patch to module and ran all the tested on Mac Os El Captain, only 4 tests were failing with or without applying patch, following are the tests failing:
test___all__ test_calendar test_re test_socket

----------
nosy: +iyogeshjoshi

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

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: [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 10:59:28 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 02 Oct 2015 08:59:28 +0000
Subject: [issue25125] "Edit with IDLE" does not work for shortcuts
In-Reply-To: <1442318370.13.0.116980940121.issue25125@psf.upfronthosting.co.za>
Message-ID: <1443776368.8.0.221082333801.issue25125@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Putting them under the current 'Open with >' would also be alright.  (It currently lists Notepad, Wordpad, and Py launcher for Windows (console), which I presume means run with default for Py.  What I was requesting is that the version be included with the entry wherever it is put.  The technical details of the different choices are not my concern.

----------

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

From report at bugs.python.org  Fri Oct  2 11:03:33 2015
From: report at bugs.python.org (Alexander)
Date: Fri, 02 Oct 2015 09:03:33 +0000
Subject: [issue25297] max_help_position is not works in argparse library
In-Reply-To: <1443776113.96.0.923054986589.issue25297@psf.upfronthosting.co.za>
Message-ID: <1443776613.61.0.642222496911.issue25297@psf.upfronthosting.co.za>


Alexander added the comment:

Problem also described on http://stackoverflow.com/questions/32888815/

----------

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

From report at bugs.python.org  Fri Oct  2 11:15:11 2015
From: report at bugs.python.org (Yogesh Joshi)
Date: Fri, 02 Oct 2015 09:15:11 +0000
Subject: [issue19884] Importing readline produces erroneous output
In-Reply-To: <1386158776.45.0.265770743985.issue19884@psf.upfronthosting.co.za>
Message-ID: <1443777311.65.0.531402556596.issue19884@psf.upfronthosting.co.za>


Yogesh Joshi added the comment:

I tried applying this patch and its failing and throwing the following error:

patching file Lib/test/test_readline.py
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 43.
2 out of 2 hunks FAILED -- saving rejects to file Lib/test/test_readline.py.rej
patching file Modules/readline.c
Hunk #1 FAILED at 1019.
1 out of 1 hunk FAILED -- saving rejects to file Modules/readline.c.rej

I'm using Mac Os El Captain

----------
nosy: +iyogeshjoshi

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

From report at bugs.python.org  Fri Oct  2 11:42:50 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 02 Oct 2015 09:42:50 +0000
Subject: [issue25295] functools.lru_cache raises KeyError
In-Reply-To: <1443758314.48.0.0379621558494.issue25295@psf.upfronthosting.co.za>
Message-ID: <1443778970.65.0.732742398964.issue25295@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Issue24483 fixes this issue.

----------
dependencies: +Avoid repeated hash calculation in C implementation of functools.lru_cache()

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

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: [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 11:45:02 2015
From: report at bugs.python.org (Davey Shafik)
Date: Fri, 02 Oct 2015 09:45:02 +0000
Subject: [issue25296] Simple End-of-life guide covering all unsupported
 versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1443779102.17.0.0448662950062.issue25296@psf.upfronthosting.co.za>


Davey Shafik added the comment:

We (PHP) also have a more visual guide at http://php.net/supported-versions.php which updates dynamically to show the current status.

It shows the current status (EOL, Security only, Active) of releases from PHP 5.3, which is still the default for many LTS distros and still in common use.

----------
nosy: +dshafik

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

From report at bugs.python.org  Fri Oct  2 11:48:21 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 09:48:21 +0000
Subject: [issue25296] Simple End-of-life guide covering all unsupported
 versions
In-Reply-To: <1443779102.17.0.0448662950062.issue25296@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwb5CQ8gisKZ32M2cw8_qcegBA9hefwDpK43PcR9vHRHrQ@mail.gmail.com>


STINNER Victor added the comment:

Davey Shafik added the comment:
> We (PHP) also have a more visual guide at http://php.net/supported-versions.php which updates dynamically to show the current status.

Great job! It's much easier to see the status with the summary in a
single picture.

----------

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

From report at bugs.python.org  Fri Oct  2 11:51:11 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Oct 2015 09:51:11 +0000
Subject: [issue24483] Avoid repeated hash calculation in C implementation of
 functools.lru_cache()
In-Reply-To: <1434890042.2.0.0991345110525.issue24483@psf.upfronthosting.co.za>
Message-ID: <20151002095106.31203.13418@psf.io>


Roundup Robot added the comment:

New changeset 3f4c319a822f by Serhiy Storchaka in branch '3.5':
Issue #24483: C implementation of functools.lru_cache() now calculates key's
https://hg.python.org/cpython/rev/3f4c319a822f

New changeset 5758b85627c9 by Serhiy Storchaka in branch 'default':
Issue #24483: C implementation of functools.lru_cache() now calculates key's
https://hg.python.org/cpython/rev/5758b85627c9

----------
nosy: +python-dev

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

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


New submission from Nir Soffer:

Same patch works also for 2.7

----------

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

From report at bugs.python.org  Fri Oct  2 12:04:25 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Oct 2015 10:04:25 +0000
Subject: [issue25296] Simple End-of-life guide covering all unsupported
 versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1443780265.85.0.153446133276.issue25296@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I like that, in fact I used the same format in my talk "The development process of Python": http://wolfprojects.altervista.org/talks/development-process-of-python-2011/ (slides 20/21).

The main problem is where to put all this though.

----------

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

From report at bugs.python.org  Fri Oct  2 12:15:43 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Oct 2015 10:15:43 +0000
Subject: [issue24848] Warts in UTF-7 error handling
In-Reply-To: <1439364965.73.0.526700604341.issue24848@psf.upfronthosting.co.za>
Message-ID: <20151002101540.31183.12155@psf.io>


Roundup Robot added the comment:

New changeset 3c13567ea642 by Serhiy Storchaka in branch '3.4':
Issue #24848: Fixed bugs in UTF-7 decoding of misformed data:
https://hg.python.org/cpython/rev/3c13567ea642

New changeset a61fa2b08f87 by Serhiy Storchaka in branch '3.5':
Issue #24848: Fixed bugs in UTF-7 decoding of misformed data:
https://hg.python.org/cpython/rev/a61fa2b08f87

New changeset 037253b7cd6d by Serhiy Storchaka in branch 'default':
Issue #24848: Fixed bugs in UTF-7 decoding of misformed data:
https://hg.python.org/cpython/rev/037253b7cd6d

New changeset c6eaa722e2c1 by Serhiy Storchaka in branch '2.7':
Issue #24848: Fixed bugs in UTF-7 decoding of misformed data:
https://hg.python.org/cpython/rev/c6eaa722e2c1

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Oct  2 12:16:19 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 02 Oct 2015 10:16:19 +0000
Subject: [issue24483] Avoid repeated hash calculation in C implementation of
 functools.lru_cache()
In-Reply-To: <1434890042.2.0.0991345110525.issue24483@psf.upfronthosting.co.za>
Message-ID: <1443780979.89.0.766387532128.issue24483@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Oct  2 12:18:39 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 02 Oct 2015 10:18:39 +0000
Subject: [issue25295] functools.lru_cache raises KeyError
In-Reply-To: <1443758314.48.0.0379621558494.issue25295@psf.upfronthosting.co.za>
Message-ID: <1443781119.02.0.823471123962.issue25295@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I don't know what was the actual cause of the error and if issue24483 fixed it or mask.

----------

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

From report at bugs.python.org  Fri Oct  2 12:27:08 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 10:27:08 +0000
Subject: [issue24483] Avoid repeated hash calculation in C implementation of
 functools.lru_cache()
In-Reply-To: <1443780979.97.0.210477181059.issue24483@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYYYFqUDsL4LT3_A1ef3fQ86r9Lq3JHUq-xzSH1RcNs6Q@mail.gmail.com>


STINNER Victor added the comment:

> New changeset 3f4c319a822f by Serhiy Storchaka in branch '3.5':
> Issue #24483: C implementation of functools.lru_cache() now calculates key's
> https://hg.python.org/cpython/rev/3f4c319a822f

I didn't follow this issue, but I like the change. Good job :)

----------

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

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: [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 13:27:12 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 02 Oct 2015 11:27:12 +0000
Subject: [issue25278] Unexpected socket exception on SFTP 'STOR' command
In-Reply-To: <1443619244.64.0.188831758146.issue25278@psf.upfronthosting.co.za>
Message-ID: <1443785232.25.0.351301947122.issue25278@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

You'll need to reproduce this in a smaller piece of code that demonstrates the problem. The code you've included is very large, and imports libraries we don't have access to.

Otherwise, we can't reproduce it and we can't help.

----------

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

From report at bugs.python.org  Fri Oct  2 13:47:13 2015
From: report at bugs.python.org (Bar Harel)
Date: Fri, 02 Oct 2015 11:47:13 +0000
Subject: [issue16802] fileno argument to socket.socket() undocumented
In-Reply-To: <1356711151.76.0.423836721045.issue16802@psf.upfronthosting.co.za>
Message-ID: <1443786433.86.0.857244499736.issue16802@psf.upfronthosting.co.za>


Bar Harel added the comment:

Here you go.

----------
nosy: +bar.harel
Added file: http://bugs.python.org/file40656/Issue16802_rev2.patch

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

From report at bugs.python.org  Fri Oct  2 14:09:53 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 12:09:53 +0000
Subject: [issue24848] Warts in UTF-7 error handling
In-Reply-To: <1439364965.73.0.526700604341.issue24848@psf.upfronthosting.co.za>
Message-ID: <1443787793.79.0.0594261211997.issue24848@psf.upfronthosting.co.za>


STINNER Victor added the comment:

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


======================================================================
FAIL: test_errors (test.test_codecs.UTF7Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\test\test_codecs.py", line 709, in test_errors
    self.assertEqual(raw.decode('utf-7', 'replace'), expected)
AssertionError: u'a\u20ac\ufffd' != u'a\u20ac\ufffdb'
- a\u20ac\ufffd
+ a\u20ac\ufffdb
?    +


======================================================================
FAIL: test_lone_surrogates (test.test_codecs.UTF7Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\test\test_codecs.py", line 743, in test_lone_surrogates
    self.assertEqual(raw.decode('utf-7', 'replace'), expected)
AssertionError: u'a\ufffd' != u'a\ufffdb'
- a\ufffd
+ a\ufffdb
?   +

----------

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

From report at bugs.python.org  Fri Oct  2 14:13:36 2015
From: report at bugs.python.org (J Richard Snape)
Date: Fri, 02 Oct 2015 12:13:36 +0000
Subject: [issue25294] Absolute imports fail in some cases where relative
 imports would work
In-Reply-To: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>
Message-ID: <1443788016.4.0.0596570420021.issue25294@psf.upfronthosting.co.za>


Changes by J Richard Snape <snapey1979 at googlemail.com>:


----------
nosy: +J Richard Snape

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

From report at bugs.python.org  Fri Oct  2 14:22:40 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 02 Oct 2015 12:22:40 +0000
Subject: [issue25294] Absolute imports fail in some cases where relative
 imports would work
In-Reply-To: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>
Message-ID: <1443788560.19.0.54907302061.issue25294@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +brett.cannon, eric.snow, ncoghlan

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

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: [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 14:25:54 2015
From: report at bugs.python.org (Florin Papa)
Date: Fri, 02 Oct 2015 12:25:54 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1443788754.89.0.865453280753.issue25300@psf.upfronthosting.co.za>


Changes by Florin Papa <florin.papa at intel.com>:


Added file: http://bugs.python.org/file40658/mpx_enable_2_7.patch

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

From report at bugs.python.org  Fri Oct  2 14:28:16 2015
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 02 Oct 2015 12:28:16 +0000
Subject: [issue25276] test_decimal sometimes crash on PPC64 AIX 3.x
In-Reply-To: <1443605165.97.0.433720501229.issue25276@psf.upfronthosting.co.za>
Message-ID: <1443788896.62.0.799006161704.issue25276@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I've checked:  test_decimal does not require abnormal amounts of
memory or stack. On Linux/x86 a stack size of 256 (default 8192)
is sufficient, and memory requirements aren't that high.

We assumed that there is some memory limit on the buildbot, since
in a later run test #pwmx330 failed with MemoryError.


The easiest way to debug this is to rerun the whole test suite
under gdb with the same random seed as in


http://buildbot.python.org/all/builders/PPC64%20AIX%203.x/builds/4173/steps/test/logs/stdio

----------

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

From report at bugs.python.org  Fri Oct  2 14:30:59 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 02 Oct 2015 12:30:59 +0000
Subject: [issue24657] CGIHTTPServer module discard continuous '/' letters from
 params given by GET method.
In-Reply-To: <1437187776.37.0.855244973055.issue24657@psf.upfronthosting.co.za>
Message-ID: <1443789059.61.0.727058918607.issue24657@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Yes, there seems to still exist some defects not conforming to the
specification. I would like to investigate it. Maybe I can propose
a patch for it.

----------

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

From report at bugs.python.org  Fri Oct  2 14:33:48 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 12:33:48 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1443789228.75.0.0479492218974.issue25300@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

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

From report at bugs.python.org  Fri Oct  2 14:37:03 2015
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 02 Oct 2015 12:37:03 +0000
Subject: [issue25276] Intermittent segfaults on PPC64 AIX 3.x
In-Reply-To: <1443605165.97.0.433720501229.issue25276@psf.upfronthosting.co.za>
Message-ID: <1443789423.69.0.812664920817.issue25276@psf.upfronthosting.co.za>


Stefan Krah added the comment:

And the segfaults are apparently somewhat random. This is beginning
to look like an issue unrelated to decimal that was perhaps recently
introduced (in which case "hg bisect" would be the fastest
way to debug).


http://buildbot.python.org/all/builders/PPC64%20AIX%203.x/builds/4183/steps/test/logs/stdio

[129/399/3] test_email
Fatal Python error: Segmentation fault

Current thread 0x00000001 (most recent call first):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/email/utils.py", line 57 in _has_surrogates
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/email/message.py", line 264 in get_payload
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_email/test_email.py", line 3463 in test_long_lines
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/case.py", line 600 in run
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/case.py", line 648 in __call__
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 122 in run
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 122 in run
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 122 in run
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 122 in run
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 122 in run
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/runner.py", line 176 in run
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/support/__init__.py", line 1775 in _run_suite
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/support/__init__.py", line 1809 in run_unittest
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/runtest.py", line 159 in test_runner
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/runtest.py", line 160 in runtest_inner
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/runtest.py", line 113 in runtest
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/main.py", line 289 in run_tests_sequential
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/main.py", line 331 in run_tests
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/main.py", line 362 in main
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/main.py", line 404 in main
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/main.py", line 426 in main_in_temp_cwd
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/__main__.py", line 3 in <module>
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/runpy.py", line 85 in _run_code
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/runpy.py", line 170 in _run_module_as_main

----------
title: test_decimal sometimes crash on PPC64 AIX 3.x -> Intermittent segfaults on PPC64 AIX 3.x

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

From report at bugs.python.org  Fri Oct  2 15:42:46 2015
From: report at bugs.python.org (David Edelsohn)
Date: Fri, 02 Oct 2015 13:42:46 +0000
Subject: [issue25276] Intermittent segfaults on PPC64 AIX 3.x
In-Reply-To: <1443605165.97.0.433720501229.issue25276@psf.upfronthosting.co.za>
Message-ID: <1443793366.04.0.112510780022.issue25276@psf.upfronthosting.co.za>


David Edelsohn added the comment:

As we have seen with similar issues on other targets, this likely is due to the random order of tests.  In another case, the timezone was not being restored properly by GLIBC.  Another test is leaving the process in a state that somehow evokes this failure from test_decimal.

----------

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

From report at bugs.python.org  Fri Oct  2 15:44:35 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 13:44:35 +0000
Subject: [issue25276] Intermittent segfaults on PPC64 AIX 3.x
In-Reply-To: <1443605165.97.0.433720501229.issue25276@psf.upfronthosting.co.za>
Message-ID: <1443793475.31.0.445632121279.issue25276@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I suggest to isolate tests using -j1: see my issue #25285.

(Currently, -j1 doesn't use subprocesses.)

----------

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

From report at bugs.python.org  Fri Oct  2 15:52:49 2015
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 02 Oct 2015 13:52:49 +0000
Subject: [issue25276] Intermittent segfaults on PPC64 AIX 3.x
In-Reply-To: <1443605165.97.0.433720501229.issue25276@psf.upfronthosting.co.za>
Message-ID: <1443793969.9.0.263809929782.issue25276@psf.upfronthosting.co.za>


Stefan Krah added the comment:

If you have time, you could use an explicit seed (and gdb):

# test_email segfault:
./python -m test -j 1 -u all -W --randseed 5634141

----------

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

From report at bugs.python.org  Fri Oct  2 15:58:49 2015
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 02 Oct 2015 13:58:49 +0000
Subject: [issue25296] Simple End-of-life guide covering all unsupported
 versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1443794329.39.0.0178416557486.issue25296@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

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

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: [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 16:45:19 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 14:45:19 +0000
Subject: [issue24870] Optimize ascii and latin1 decoder with surrogateescape
 and surrogatepass error handlers
In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za>
Message-ID: <1443797119.94.0.0751183026964.issue24870@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I created issue #25301: "Optimize UTF-8 decoder with error handlers".

----------

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

From report at bugs.python.org  Fri Oct  2 16:45:48 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 02 Oct 2015 14:45:48 +0000
Subject: [issue25296] Simple End-of-life guide covering all unsupported
 versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1443797148.28.0.78535777665.issue25296@psf.upfronthosting.co.za>


R. David Murray added the comment:

It seems to me a link to this version independent info could logically appear on the docs front page.  I think we ought to add the devguide there already, for instance.  The 'Meta information' section seems perfectly appropriate...even though all the docs currently in there are maintained in the Docs directory, both 'about' and 'reporting bugs' are currently version-independent information.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Fri Oct  2 16:52:52 2015
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 02 Oct 2015 14:52:52 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1443797572.28.0.194013081313.issue25300@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan at bytereef.org>:


----------
nosy: +skrah

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

From report at bugs.python.org  Fri Oct  2 16:55:15 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 02 Oct 2015 14:55:15 +0000
Subject: [issue25299] TypeError: __init__() takes at least 4 arguments (4
 given)
In-Reply-To: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za>
Message-ID: <1443797715.28.0.835497360735.issue25299@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, the python2 TypeErrors for mimatched arguments are sub-optimal.  This has been fixed in python3:

>>> parser.add_argument('--foo', help="foo", action='store_const')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/rdmurray/python/p36/Lib/argparse.py", line 1336, in add_argument
    action = action_class(**kwargs)
TypeError: __init__() missing 1 required positional argument: 'const'

----------
nosy: +r.david.murray
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Oct  2 16:56:25 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 02 Oct 2015 14:56:25 +0000
Subject: [issue25299] TypeError: __init__() takes at least 4 arguments (4
 given)
In-Reply-To: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za>
Message-ID: <1443797785.45.0.13722669499.issue25299@psf.upfronthosting.co.za>


R. David Murray added the comment:

Oops, sorry, I missed the fact that you were pointing out a doc issue.

----------
resolution: out of date -> 
stage: resolved -> needs patch
status: closed -> open

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

From report at bugs.python.org  Fri Oct  2 16:57:47 2015
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 02 Oct 2015 14:57:47 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1443797867.56.0.340411393318.issue25300@psf.upfronthosting.co.za>


Stefan Krah added the comment:

In principle adding the option is fine, but do we have a buildbot
with a Skylake processor?  We have lots of options that are untested
and that break periodically.

----------
nosy: +zach.ware

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

From report at bugs.python.org  Fri Oct  2 17:02:11 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 02 Oct 2015 15:02:11 +0000
Subject: [issue25299] TypeError: __init__() takes at least 4 arguments (4
 given)
In-Reply-To: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za>
Message-ID: <1443798131.13.0.650301520877.issue25299@psf.upfronthosting.co.za>


R. David Murray added the comment:

Hmm.  After looking at the code, it may also be desirable to improve that error message at the argparse level, since there's a bit of not-immediately-obvious indirection going on there.

----------

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

From report at bugs.python.org  Fri Oct  2 17:05:34 2015
From: report at bugs.python.org (A. Skrobov)
Date: Fri, 02 Oct 2015 15:05:34 +0000
Subject: [issue25299] TypeError: __init__() takes at least 4 arguments (4
 given)
In-Reply-To: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za>
Message-ID: <1443798334.09.0.268723874893.issue25299@psf.upfronthosting.co.za>


A. Skrobov added the comment:

Thank you for confirming that the mismatch between the documentation and the behaviour is preserved in Python 3!

Adding it to the list of affected versions.

----------
versions: +Python 3.5

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

From report at bugs.python.org  Fri Oct  2 17:08:33 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 02 Oct 2015 15:08:33 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1443798513.56.0.762651427413.issue25300@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think Intel will make sure we do have one.

Florin: how does one determine if a processor supports mxp?  I don't know if the mac mini running the ICC buildbot is new enough to have a Skylake processor, but I suppose there's at least some chance it does.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Fri Oct  2 17:10:54 2015
From: report at bugs.python.org (Peter Brady)
Date: Fri, 02 Oct 2015 15:10:54 +0000
Subject: [issue25295] functools.lru_cache raises KeyError
In-Reply-To: <1443758314.48.0.0379621558494.issue25295@psf.upfronthosting.co.za>
Message-ID: <1443798654.2.0.891454221163.issue25295@psf.upfronthosting.co.za>


Peter Brady added the comment:

As a sanity check I removed the stored hashvalue in Raymond Hettinger's backported lru_cache (which we use to support 2.6-3.2) and end up with errors as well.  So it seems like 24483 is the appropriate fix to restore the old behavior.  Thanks for looking into this.

----------

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

From report at bugs.python.org  Fri Oct  2 17:15:15 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 02 Oct 2015 15:15:15 +0000
Subject: [issue25299] TypeError: __init__() takes at least 4 arguments (4
 given)
In-Reply-To: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za>
Message-ID: <1443798915.31.0.393790807771.issue25299@psf.upfronthosting.co.za>


R. David Murray added the comment:

To clarify this for other readers: the issue here is that the arguments to add_argument are passed through the action routine, which in this case is store_const, and store_const is the one that requires 'const' be specified...which isn't made clear by either the docs or the error message.

----------

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

From report at bugs.python.org  Fri Oct  2 17:16:16 2015
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 02 Oct 2015 15:16:16 +0000
Subject: [issue25296] Simple End-of-life guide covering all unsupported
 versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1443798976.83.0.883335575857.issue25296@psf.upfronthosting.co.za>


Georg Brandl added the comment:

> It seems to me a link to this version independent info could logically appear on the docs front page.

Yes, that sounds good. I do like the PHP graph of versions too...

----------

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

From report at bugs.python.org  Fri Oct  2 17:21:46 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 15:21:46 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1443799306.2.0.898135450806.issue25300@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Why not enablind the option by default if GCC 5.1 or newer is detected? Is there a risk of breaking third-party extensions?

Should we pass the MPX compiler options to third-party extensions by way?

I'm not sure that it's ok to add such change to Python 2.7. It's border line between new feature and supporting a new architecture.

I would suggest to only modify Python 3.6.

----------

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

From report at bugs.python.org  Fri Oct  2 17:25:01 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 02 Oct 2015 15:25:01 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1443799501.98.0.575259401892.issue25300@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, since it is arguably security related, I think that pushes it toward the "yes" side.  And yes, I think we could end up "breaking" third party code, as well as python (thus the need for a buildbot), but that may not be a bad thing in this case (that security business again :).

----------

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

From report at bugs.python.org  Fri Oct  2 17:32:16 2015
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 02 Oct 2015 15:32:16 +0000
Subject: [issue25296] Simple End-of-life guide covering all unsupported
 versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1443799936.48.0.184309641255.issue25296@psf.upfronthosting.co.za>


Georg Brandl added the comment:

It should also be linked from the downloads page.

----------

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

From report at bugs.python.org  Fri Oct  2 17:33:20 2015
From: report at bugs.python.org (Florin Papa)
Date: Fri, 02 Oct 2015 15:33:20 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1443800000.06.0.599663112426.issue25300@psf.upfronthosting.co.za>


Florin Papa added the comment:

> Why not enablind the option by default if GCC 5.1 or newer is detected? Is there a risk of breaking third-party extensions?
> Should we pass the MPX compiler options to third-party extensions by way?
On a processor that does not support MPX technology, MPX specific instructions will be replaced by nop's and will introduce a performance loss. Also, third party extensions might need to be patched in order to work with MPX. One example is the math module, which needed the bnd_legacy attribute to disable instrumentation when calling libc functions (which are not instrumented and generated compile errors).

> I'm not sure that it's ok to add such change to Python 2.7. It's border line between new feature and supporting a new architecture.
I believe that Python 2.7 should benefit from this change, since it is still used in real life applications, one example being Openstack Swift.

----------

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

From report at bugs.python.org  Fri Oct  2 17:55:00 2015
From: report at bugs.python.org (paul j3)
Date: Fri, 02 Oct 2015 15:55:00 +0000
Subject: [issue25299] TypeError: __init__() takes at least 4 arguments (4
 given)
In-Reply-To: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za>
Message-ID: <1443801300.59.0.437002145254.issue25299@psf.upfronthosting.co.za>


paul j3 added the comment:

A related issue is

http://bugs.python.org/issue24754
argparse add_argument with action="store_true", type=bool should not crash

In this case the user specified a parameter that the 'store_true' subclass did not accept.

In both cases, 'parser.add_argument' does minimal error checking (or catching), so the user ends up seeing the '__init__' argument error.

This line in the 'store_const' documentation is clearly wrong.  There's no default.

    (Note that the const keyword argument defaults to the rather
    unhelpful None.)

Possible fixes to the bigger issue:

- major addition to the documentation, documenting allowable subclass parameters (but the subclasses aren't part of the API).

- major addition to add_argument that filters parameters before passing them to the subclasses.  But can that be done without replicating information that is implicit in the subclass __init__?  Can we use advanced inspection?  What about user defined Action classes?

- minor addition to add_argument that catches the __init__ parameter errors and adds a mollifing explanation.

- somehow make Action (and its subclasses) responsible for a nice error message.  But how do you override the normal behavior of Python regarding function parameters?

----------
nosy: +paul.j3

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

From report at bugs.python.org  Fri Oct  2 17:56:14 2015
From: report at bugs.python.org (Aaron Meurer)
Date: Fri, 02 Oct 2015 15:56:14 +0000
Subject: [issue25295] functools.lru_cache raises KeyError
In-Reply-To: <1443758314.48.0.0379621558494.issue25295@psf.upfronthosting.co.za>
Message-ID: <1443801374.84.0.0623400145001.issue25295@psf.upfronthosting.co.za>


Aaron Meurer added the comment:

Does this mean that some SymPy object is giving different hash values on successive calls to hash()? We definitely need to look into this on the SymPy side.

----------

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

From report at bugs.python.org  Fri Oct  2 17:58:16 2015
From: report at bugs.python.org (paul j3)
Date: Fri, 02 Oct 2015 15:58:16 +0000
Subject: [issue25297] max_help_position is not works in argparse library
In-Reply-To: <1443776113.96.0.923054986589.issue25297@psf.upfronthosting.co.za>
Message-ID: <1443801496.34.0.533958380313.issue25297@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


----------
nosy: +paul.j3

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

From report at bugs.python.org  Fri Oct  2 17:58:55 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 02 Oct 2015 15:58:55 +0000
Subject: [issue25299] TypeError: __init__() takes at least 4 arguments (4
 given)
In-Reply-To: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za>
Message-ID: <1443801535.5.0.755186326243.issue25299@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think your second to last choice (catch the error) is the only practical solution.  It is also probably the best, since we need to support user-written action routines.

----------

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

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: [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  Fri Oct  2 18:11:01 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 16:11:01 +0000
Subject: [issue25302] Memory Leaks with Address Sanitizer
In-Reply-To: <1443801865.56.0.796405543991.issue25302@psf.upfronthosting.co.za>
Message-ID: <1443802261.2.0.293016609858.issue25302@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

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

From report at bugs.python.org  Fri Oct  2 18:15:53 2015
From: report at bugs.python.org (Carol Willing)
Date: Fri, 02 Oct 2015 16:15:53 +0000
Subject: [issue25296] Simple End-of-life guide covering all unsupported
 versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1443802553.39.0.447260758735.issue25296@psf.upfronthosting.co.za>


Carol Willing added the comment:

+1 to adding the EOF info to the Docs front page and a link from the downloads page.

Also, +1 to David's suggestion to adding the devguide as well to the front page. In the future, it would be nice to add the devguide to the CPython repo instead of having it as a standalone. It would consolidate things in to one workflow instead of a different workflow for the devguide.

P.S. Ezio - nice slide deck content :)

----------
nosy: +willingc

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

From report at bugs.python.org  Fri Oct  2 18:17:12 2015
From: report at bugs.python.org (Carol Willing)
Date: Fri, 02 Oct 2015 16:17:12 +0000
Subject: [issue25296] Simple End-of-life guide covering all unsupported
 versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1443802632.18.0.478757698931.issue25296@psf.upfronthosting.co.za>


Carol Willing added the comment:

And that would be EOL (end of life) not EOF. More coffee please...

----------

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

From report at bugs.python.org  Fri Oct  2 18:22:40 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 02 Oct 2015 16:22:40 +0000
Subject: [issue12006] strptime should implement %G, %V and %u directives
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1443802960.56.0.406672301105.issue12006@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

My bad.  In this case, maybe Erik can review your latest patch?

----------

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

From report at bugs.python.org  Fri Oct  2 18:24:06 2015
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 02 Oct 2015 16:24:06 +0000
Subject: [issue25097] test_logging may fail with 'Access is denied' when
 pywin32 is installed
In-Reply-To: <1442204467.58.0.479620846783.issue25097@psf.upfronthosting.co.za>
Message-ID: <1443803046.12.0.186166755982.issue25097@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

I'm not able to build on Windows at the moment, unfortunately - did the change actually work for you?

----------

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

From report at bugs.python.org  Fri Oct  2 18:25:57 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Oct 2015 16:25:57 +0000
Subject: [issue25290] csv.reader: minor docstring typo
In-Reply-To: <1443710545.32.0.660901120379.issue25290@psf.upfronthosting.co.za>
Message-ID: <20151002162553.81394.31165@psf.io>


Roundup Robot added the comment:

New changeset 3940f480ea16 by Berker Peksag in branch '3.4':
Issue #25290: Fix typo in csv.reader() docstring
https://hg.python.org/cpython/rev/3940f480ea16

New changeset 3b565295eba0 by Berker Peksag in branch '3.5':
Issue #25290: Fix typo in csv.reader() docstring
https://hg.python.org/cpython/rev/3b565295eba0

New changeset 7a3073921687 by Berker Peksag in branch 'default':
Issue #25290: Fix typo in csv.reader() docstring
https://hg.python.org/cpython/rev/7a3073921687

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Oct  2 18:30:07 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Oct 2015 16:30:07 +0000
Subject: [issue25290] csv.reader: minor docstring typo
In-Reply-To: <1443710545.32.0.660901120379.issue25290@psf.upfronthosting.co.za>
Message-ID: <20151002163004.11700.79774@psf.io>


Roundup Robot added the comment:

New changeset ceff1babf66e by Berker Peksag in branch '2.7':
Issue #25290: Fix typo in csv.reader() docstring
https://hg.python.org/cpython/rev/ceff1babf66e

----------

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

From report at bugs.python.org  Fri Oct  2 18:31:37 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 02 Oct 2015 16:31:37 +0000
Subject: [issue25290] csv.reader: minor docstring typo
In-Reply-To: <1443710545.32.0.660901120379.issue25290@psf.upfronthosting.co.za>
Message-ID: <1443803497.01.0.406647830906.issue25290@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Johannes! I forgot to update 2.7 docs, but should be OK now.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +berker.peksag, docs at python
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type: enhancement -> behavior
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Oct  2 18:40:17 2015
From: report at bugs.python.org (paul j3)
Date: Fri, 02 Oct 2015 16:40:17 +0000
Subject: [issue25297] max_help_position is not works in argparse library
In-Reply-To: <1443776113.96.0.923054986589.issue25297@psf.upfronthosting.co.za>
Message-ID: <1443804017.98.0.237844632688.issue25297@psf.upfronthosting.co.za>


paul j3 added the comment:

My testing shows that it's a problem with the subparsers listing.  When regular arguments are long, 'max_help_position' works (within limits allowed by 'width').

----------

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

From report at bugs.python.org  Fri Oct  2 18:52:07 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 02 Oct 2015 16:52:07 +0000
Subject: [issue16802] fileno argument to socket.socket() undocumented
In-Reply-To: <1356711151.76.0.423836721045.issue16802@psf.upfronthosting.co.za>
Message-ID: <1443804727.81.0.441739667079.issue16802@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Patch looks good.

----------

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

From report at bugs.python.org  Fri Oct  2 19:04:42 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 02 Oct 2015 17:04:42 +0000
Subject: [issue25293] Hooking Thread/Process instantiation in
 concurrent.futures.
In-Reply-To: <1443737352.06.0.289026067314.issue25293@psf.upfronthosting.co.za>
Message-ID: <1443805482.37.0.350994531201.issue25293@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy: +yselivanov

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

From report at bugs.python.org  Fri Oct  2 19:15:16 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 02 Oct 2015 17:15:16 +0000
Subject: [issue12006] strptime should implement %G, %V and %u directives
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1443806116.61.0.270491076715.issue12006@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> Also please let me know if this is not the proper way to respond to the code review!

I believe Rietveld gives you a "done" button on each reviewer comment.  If all you do is to take the reviewer suggestion, you can just press it.

Responding with an issue note as you did is perfectly fine as well.

----------

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

From report at bugs.python.org  Fri Oct  2 19:31:02 2015
From: report at bugs.python.org (Ashley Anderson)
Date: Fri, 02 Oct 2015 17:31:02 +0000
Subject: [issue12006] strptime should implement %G, %V and %u directives
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1443807062.15.0.724330900422.issue12006@psf.upfronthosting.co.za>


Changes by Ashley Anderson <aganders3 at gmail.com>:


Added file: http://bugs.python.org/file40660/issue12006_10_complete.patch

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

From report at bugs.python.org  Fri Oct  2 20:05:00 2015
From: report at bugs.python.org (eryksun)
Date: Fri, 02 Oct 2015 18:05:00 +0000
Subject: [issue22080] Add windows_helper module helper
In-Reply-To: <1406378373.46.0.337360125553.issue22080@psf.upfronthosting.co.za>
Message-ID: <1443809100.42.0.652701877343.issue22080@psf.upfronthosting.co.za>


Changes by eryksun <eryksun at gmail.com>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden
versions: +Python 3.6

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

From report at bugs.python.org  Fri Oct  2 20:29:47 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 02 Oct 2015 18:29:47 +0000
Subject: [issue24848] Warts in UTF-7 error handling
In-Reply-To: <1439364965.73.0.526700604341.issue24848@psf.upfronthosting.co.za>
Message-ID: <1443810587.0.0.355165236618.issue24848@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Have no ideas why tests are failed and only on this buildbot.

----------

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

From report at bugs.python.org  Fri Oct  2 20:45:04 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Oct 2015 18:45:04 +0000
Subject: [issue25266] mako benchmark not working in Python 3.6
In-Reply-To: <1443525661.77.0.371661807917.issue25266@psf.upfronthosting.co.za>
Message-ID: <20151002184459.81392.65039@psf.io>


Roundup Robot added the comment:

New changeset 85edb638dce6 by Brett Cannon in branch 'default':
Issue #25266: the mako benchmark does not work in Python 3.6.
https://hg.python.org/benchmarks/rev/85edb638dce6

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Oct  2 20:45:23 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 02 Oct 2015 18:45:23 +0000
Subject: [issue25266] mako benchmark not working in Python 3.6
In-Reply-To: <1443525661.77.0.371661807917.issue25266@psf.upfronthosting.co.za>
Message-ID: <1443811523.42.0.0839479703523.issue25266@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks for the patch!

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Oct  2 21:18:01 2015
From: report at bugs.python.org (Chenyun Yang)
Date: Fri, 02 Oct 2015 19:18:01 +0000
Subject: [issue25258] HtmlParser doesn't handle void element tags correctly
In-Reply-To: <1443665115.49.0.126579485236.issue25258@psf.upfronthosting.co.za>
Message-ID: <CAJZGQB471E26pn7sx5UV9QLZYCZ=KSctugdrdn80gfW_KrmfAQ@mail.gmail.com>


Chenyun Yang added the comment:

the example you give for <li> is a different case.

<img>, <link> are void elements which are allowed to have no close tag;
<li> without </li> is a browser implementation detail, most browser
autocompletes </li>.

Without the parser calls the handle_endtag(), the client code which uses
HTMLParser won't be able to know whether the a traversal is finished.

Do you have a strong reason why we should include the knowledge of  void
elements into the HTMLParser at this line?

https://github.com/python/cpython/blob/bdfb14c688b873567d179881fc5bb67363a6074c/Lib/html/parser.py#L341

if end.endswith('/>') or (end.endswith('>') and tag in VOID_ELEMENTS)

On Wed, Sep 30, 2015 at 7:05 PM, Martin Panter <report at bugs.python.org>
wrote:

>
> Martin Panter added the comment:
>
> My thinking is that the knowledge that <img> does not have a closing tag
> is at a higher level than the current HTMLParser class. It is similar to
> knowing where the following HTML implicitly closes the <li> elements:
>
> <ul><li>Item A<li>Item B</ul>
>
> In both cases I would not expect the HTMLParser to report ?virtual? empty
> or closing tags. I don?t think it should report an empty <img/> or closing
> </img> tag just because that is easy to do, because it would be
> inconsistent with other implied HTML tags. But maybe see what other people
> say.
>
> I don?t know your particular use case, but I would suggest if you need to
> parse non-XML HTML <img> tags, use the handle_starttag() method and don?t
> rely on the end tag :)
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue25258>
> _______________________________________
>

----------

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

From report at bugs.python.org  Fri Oct  2 21:29:37 2015
From: report at bugs.python.org (Florin Papa)
Date: Fri, 02 Oct 2015 19:29:37 +0000
Subject: [issue25266] mako benchmark not working in Python 3.6
In-Reply-To: <1443525661.77.0.371661807917.issue25266@psf.upfronthosting.co.za>
Message-ID: <1443814177.54.0.861661168596.issue25266@psf.upfronthosting.co.za>


Florin Papa added the comment:

No problem. The name is Florin Papa :)

----------

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

From report at bugs.python.org  Fri Oct  2 21:42:35 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Oct 2015 19:42:35 +0000
Subject: [issue25258] HtmlParser doesn't handle void element tags correctly
In-Reply-To: <1443468394.25.0.617953373069.issue25258@psf.upfronthosting.co.za>
Message-ID: <1443814955.71.0.661863376895.issue25258@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Note that HTMLParser tries to follow the HTML5 specs, and for this case they say [0]:
"Set the self-closing flag of the current tag token. Switch to the data state. Emit the current tag token."

So it seems that for <img />, only the <img> (and not the closing </img>) should be emitted.  HTMLParser has no way to set the self-closing flag, so calling handle_startendtag seems the most reasonable things to do, since it allows tree-builders to set the flag themselves.  That said, the default implementation of handle_startendtag should indeed just call handle_starttag, however this would be a backward-incompatible change.

[0]: http://www.w3.org/TR/html5/syntax.html#self-closing-start-tag-state

----------
type:  -> behavior

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

From report at bugs.python.org  Fri Oct  2 21:45:37 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 02 Oct 2015 19:45:37 +0000
Subject: [issue25266] mako benchmark not working in Python 3.6
In-Reply-To: <1443525661.77.0.371661807917.issue25266@psf.upfronthosting.co.za>
Message-ID: <1443815137.52.0.422642630773.issue25266@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Sorry about that. Confusion of last name with Claudiu Popa from pylint.

----------

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

From report at bugs.python.org  Fri Oct  2 22:16:02 2015
From: report at bugs.python.org (Chenyun Yang)
Date: Fri, 02 Oct 2015 20:16:02 +0000
Subject: [issue25258] HtmlParser doesn't handle void element tags correctly
In-Reply-To: <1443814955.71.0.661863376895.issue25258@psf.upfronthosting.co.za>
Message-ID: <CAJZGQB6YCdF6YpODSa-2FOnOG01ZV8ms1Adc-_ppBpe3-ahHMA@mail.gmail.com>


Chenyun Yang added the comment:

I am fine with either handle_startendtag or handle_starttag,

The issue is that the behavior is consistent for the two equally valid
syntax (<img> and <img/> are handled differently); this inconsistent cannot
be fixed from the inherited class as (handle_* calls are dispatched in the
internal method of HTMLParser)

On Fri, Oct 2, 2015 at 12:42 PM, Ezio Melotti <report at bugs.python.org>
wrote:

>
> Ezio Melotti added the comment:
>
> Note that HTMLParser tries to follow the HTML5 specs, and for this case
> they say [0]:
> "Set the self-closing flag of the current tag token. Switch to the data
> state. Emit the current tag token."
>
> So it seems that for <img />, only the <img> (and not the closing </img>)
> should be emitted.  HTMLParser has no way to set the self-closing flag, so
> calling handle_startendtag seems the most reasonable things to do, since it
> allows tree-builders to set the flag themselves.  That said, the default
> implementation of handle_startendtag should indeed just call
> handle_starttag, however this would be a backward-incompatible change.
>
> [0]: http://www.w3.org/TR/html5/syntax.html#self-closing-start-tag-state
>
> ----------
> type:  -> behavior
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue25258>
> _______________________________________
>

----------

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

From report at bugs.python.org  Fri Oct  2 22:19:23 2015
From: report at bugs.python.org (Florin Papa)
Date: Fri, 02 Oct 2015 20:19:23 +0000
Subject: [issue25266] mako benchmark not working in Python 3.6
In-Reply-To: <1443525661.77.0.371661807917.issue25266@psf.upfronthosting.co.za>
Message-ID: <1443817163.98.0.858746258507.issue25266@psf.upfronthosting.co.za>


Florin Papa added the comment:

It's OK. I just saw one of Claudiu Popa's issues and figured we have similar last names.

----------

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

From report at bugs.python.org  Fri Oct  2 22:21:29 2015
From: report at bugs.python.org (Chenyun Yang)
Date: Fri, 02 Oct 2015 20:21:29 +0000
Subject: [issue25258] HtmlParser doesn't handle void element tags correctly
In-Reply-To: <CAJZGQB6YCdF6YpODSa-2FOnOG01ZV8ms1Adc-_ppBpe3-ahHMA@mail.gmail.com>
Message-ID: <CAJZGQB6X9g+uyqOamMXP56JCLFptWZSN_X-h1E0ye1iLakcp2Q@mail.gmail.com>


Chenyun Yang added the comment:

Correct for previous comment, consistent -> not consistent

On Fri, Oct 2, 2015 at 1:16 PM, Chenyun Yang <report at bugs.python.org> wrote:

>
> Chenyun Yang added the comment:
>
> I am fine with either handle_startendtag or handle_starttag,
>
> The issue is that the behavior is consistent for the two equally valid
> syntax (<img> and <img/> are handled differently); this inconsistent cannot
> be fixed from the inherited class as (handle_* calls are dispatched in the
> internal method of HTMLParser)
>
> On Fri, Oct 2, 2015 at 12:42 PM, Ezio Melotti <report at bugs.python.org>
> wrote:
>
> >
> > Ezio Melotti added the comment:
> >
> > Note that HTMLParser tries to follow the HTML5 specs, and for this case
> > they say [0]:
> > "Set the self-closing flag of the current tag token. Switch to the data
> > state. Emit the current tag token."
> >
> > So it seems that for <img />, only the <img> (and not the closing </img>)
> > should be emitted.  HTMLParser has no way to set the self-closing flag,
> so
> > calling handle_startendtag seems the most reasonable things to do, since
> it
> > allows tree-builders to set the flag themselves.  That said, the default
> > implementation of handle_startendtag should indeed just call
> > handle_starttag, however this would be a backward-incompatible change.
> >
> > [0]: http://www.w3.org/TR/html5/syntax.html#self-closing-start-tag-state
> >
> > ----------
> > type:  -> behavior
> >
> > _______________________________________
> > Python tracker <report at bugs.python.org>
> > <http://bugs.python.org/issue25258>
> > _______________________________________
> >
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue25258>
> _______________________________________
>

----------

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

From report at bugs.python.org  Fri Oct  2 22:25:01 2015
From: report at bugs.python.org (Florin Papa)
Date: Fri, 02 Oct 2015 20:25:01 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1443817501.59.0.230413226041.issue25300@psf.upfronthosting.co.za>


Florin Papa added the comment:

Hi David,

If you are not sure about MPX hardware support, you can find out the processor model with the following commands:

Linux - cat /proc/cpuinfo | grep model
Mac   - sysctl -n machdep.cpu.brand_string

If the processor code is one of the following - i7-6xxx, i7-6xxxT, i5-6xxx, i5-6xxxT, i3-6xxx, i3-6xxxT - it is definitely part of the 6th Generation Intel processors and it supports MPX. Otherwise, it does not.

Whether the hardware is MPX enabled is irrelevant for the build process. GCC 5.1 and higher will generate the MPX specific instructions, which will be turned into nop's at runtime if the processor is not MPX enabled.

----------

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

From report at bugs.python.org  Fri Oct  2 22:58:05 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 02 Oct 2015 20:58:05 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1443819485.29.0.918249250228.issue7897@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
versions: +Python 3.6 -Python 3.5

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

From report at bugs.python.org  Fri Oct  2 23:02:42 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Oct 2015 21:02:42 +0000
Subject: [issue25287] test_crypt fails on OpenBSD
In-Reply-To: <1443682191.0.0.229033947807.issue25287@psf.upfronthosting.co.za>
Message-ID: <20151002210230.81374.73546@psf.io>


Roundup Robot added the comment:

New changeset 4da7edbf78d4 by Victor Stinner in branch 'default':
Issue #25287: Don't add crypt.METHOD_CRYPT to crypt.methods if it's not
https://hg.python.org/cpython/rev/4da7edbf78d4

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Oct  2 23:04:08 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 21:04:08 +0000
Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py
 to a package)
In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za>
Message-ID: <1443819848.83.0.378565705037.issue25220@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It's not perfect, but libregrtest looks better than Python 3.5 regrtest.py. I close the issue.

----------

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

From report at bugs.python.org  Fri Oct  2 23:06:01 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 21:06:01 +0000
Subject: [issue22324] Use PyUnicode_AsWideCharString() instead of
 PyUnicode_AsUnicode()
In-Reply-To: <1409611190.39.0.820072774539.issue22324@psf.upfronthosting.co.za>
Message-ID: <1443819961.79.0.343305572869.issue22324@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Fri Oct  2 23:06:09 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 21:06:09 +0000
Subject: [issue22323] Rewrite PyUnicode_AsWideChar() and
 PyUnicode_AsWideCharString(): don't cache the result
In-Reply-To: <1409607134.14.0.210351686888.issue22323@psf.upfronthosting.co.za>
Message-ID: <1443819969.5.0.456328345169.issue22323@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Fri Oct  2 23:07:03 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 21:07:03 +0000
Subject: [issue20964] Add support.check_time_delta()
In-Reply-To: <1395098594.14.0.725869658921.issue20964@psf.upfronthosting.co.za>
Message-ID: <1443820023.1.0.479346400626.issue20964@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Fri Oct  2 23:07:13 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 21:07:13 +0000
Subject: [issue20910] Make sleep configurable in tests
In-Reply-To: <1394716737.96.0.403349621392.issue20910@psf.upfronthosting.co.za>
Message-ID: <1443820033.24.0.373030602172.issue20910@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Fri Oct  2 23:08:08 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 21:08:08 +0000
Subject: [issue19835] Add a MemoryError singleton to fix an unlimited loop
 when the memory is exhausted
In-Reply-To: <1385745842.98.0.409110544048.issue19835@psf.upfronthosting.co.za>
Message-ID: <1443820088.0.0.624367670906.issue19835@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Fri Oct  2 23:08:14 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 21:08:14 +0000
Subject: [issue19817] tracemalloc add a memory limit feature
In-Reply-To: <1385575392.84.0.858805099832.issue19817@psf.upfronthosting.co.za>
Message-ID: <1443820094.35.0.982438729749.issue19817@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Fri Oct  2 23:09:19 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 21:09:19 +0000
Subject: [issue19519] Parser: don't transcode input string to UTF-8 if it is
 already encoded to UTF-8
In-Reply-To: <1383828055.35.0.303135915018.issue19519@psf.upfronthosting.co.za>
Message-ID: <1443820159.25.0.431061332645.issue19519@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Fri Oct  2 23:09:44 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 21:09:44 +0000
Subject: [issue19518] Add new PyRun_xxx() functions to not encode the filename
In-Reply-To: <1383824880.09.0.781641455514.issue19518@psf.upfronthosting.co.za>
Message-ID: <1443820184.77.0.719870774822.issue19518@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Fri Oct  2 23:10:37 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 21:10:37 +0000
Subject: [issue17548] unittest.mock: test_create_autospec_unbound_methods is
 skipped
In-Reply-To: <1364255908.36.0.236092443385.issue17548@psf.upfronthosting.co.za>
Message-ID: <1443820237.35.0.622803527037.issue17548@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Fri Oct  2 23:11:42 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 21:11:42 +0000
Subject: [issue12939] Add new io.FileIO using the native Windows API
In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za>
Message-ID: <1443820302.82.0.352440792546.issue12939@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Lack of interest, I'm not convinced that it's *really* needed. We survived 8 years with the current io module in Python 3, it's probably enough. I close the issue.

----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Fri Oct  2 23:11:58 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 21:11:58 +0000
Subject: [issue11365] Integrate Buildroot patches (cross-compilation)
In-Reply-To: <1299015633.09.0.58407944374.issue11365@psf.upfronthosting.co.za>
Message-ID: <1443820318.12.0.994498070747.issue11365@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Fri Oct  2 23:12:14 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 21:12:14 +0000
Subject: [issue9769] PyUnicode_FromFormatV() doesn't handle non-ascii text
 correctly
In-Reply-To: <1283557981.28.0.85027629308.issue9769@psf.upfronthosting.co.za>
Message-ID: <1443820334.86.0.590111568115.issue9769@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Fri Oct  2 23:13:52 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 21:13:52 +0000
Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py
 to a package)
In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za>
Message-ID: <1443820432.19.0.492047576129.issue25220@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Oct  2 23:15:51 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 21:15:51 +0000
Subject: [issue22806] regrtest: add switch -c to run only modified tests
In-Reply-To: <1415285956.81.0.19215825371.issue22806@psf.upfronthosting.co.za>
Message-ID: <1443820551.12.0.267784895339.issue22806@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm now closing this issue because Antoine, Serhiy and me dislike the idea.

> An alternate suggestion would be to allow filenames like "Lib/test/test_foo.py" as arguments to regrtest.

This sounds like a better plan. Please open a new issue if you still need that.

FYI I refactoring regrtest.py into libregrtest, it might be easier to enhance it now.

----------
nosy: +haypo
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Fri Oct  2 23:21:30 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 21:21:30 +0000
Subject: [issue10967] move regrtest over to using more unittest infrastructure
In-Reply-To: <1295567145.8.0.568957178125.issue10967@psf.upfronthosting.co.za>
Message-ID: <1443820890.92.0.213702033029.issue10967@psf.upfronthosting.co.za>


STINNER Victor added the comment:

This issue was opened 4 years ago and has no activity since 2 years :-/ Even if yes, it would be nice to enhance regrtest and unittest, this issue doesn't propose any concrete plan with a concrete patch. I understand that the current situation is not perfect but it's acceptable :-) I close the issue as out of date.

If someone is still motivated, please open a new issue with a concrete plan and maybe summarize this one.

In the meanwhile, the work on relying on unittest test discovery is still ongoing and made good progress last... years (see issue #16748).

----------
dependencies:  -Make CPython test package discoverable
nosy: +haypo
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Fri Oct  2 23:23:34 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 21:23:34 +0000
Subject: [issue13954] Add regrtest option to record test results to a file
In-Reply-To: <1328560515.13.0.686472532234.issue13954@psf.upfronthosting.co.za>
Message-ID: <1443821014.46.0.574471355983.issue13954@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Fri Oct  2 23:24:02 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 21:24:02 +0000
Subject: [issue12314] regrtest checks (os.environ, sys.path,
 etc.) are hard to use
In-Reply-To: <1307722749.85.0.48203387339.issue12314@psf.upfronthosting.co.za>
Message-ID: <1443821042.75.0.66037572138.issue12314@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Fri Oct  2 23:25:03 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 02 Oct 2015 21:25:03 +0000
Subject: [issue22444] Floor divide should return int
In-Reply-To: <1411145815.79.0.695099073811.issue22444@psf.upfronthosting.co.za>
Message-ID: <1443821103.23.0.0408405799651.issue22444@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Fri Oct  2 23:27:07 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 02 Oct 2015 21:27:07 +0000
Subject: [issue13466] new timezones
In-Reply-To: <1322078448.54.0.772868924392.issue13466@psf.upfronthosting.co.za>
Message-ID: <1443821227.54.0.013087899898.issue13466@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Since nobody responded, I am closing this issue.

----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Fri Oct  2 23:27:09 2015
From: report at bugs.python.org (paul j3)
Date: Fri, 02 Oct 2015 21:27:09 +0000
Subject: [issue25297] max_help_position is not works in argparse library
In-Reply-To: <1443776113.96.0.923054986589.issue25297@psf.upfronthosting.co.za>
Message-ID: <1443821229.48.0.358807326396.issue25297@psf.upfronthosting.co.za>


paul j3 added the comment:

There's a bug in the HelpFormatter.add_argument method.  It does not take into account the extra indentation of subactions (sub parsers) when calculating self._action_max_length.

The corrected method and a test case is in the attached file.

class MyFormatter(argparse.HelpFormatter):
    """
    Corrected _max_action_length for the indenting of subactions
    """
    def add_argument(self, action):
        if action.help is not argparse.SUPPRESS:

            # find all invocations
            get_invocation = self._format_action_invocation
            invocations = [get_invocation(action)]
            current_indent = self._current_indent
            for subaction in self._iter_indented_subactions(action):
                # compensate for the indent that will be added
                indent_chg = self._current_indent - current_indent
                added_indent = 'x'*indent_chg
                invocations.append(added_indent + get_invocation( subaction) )
            # print('inv', invocations)

            # update the maximum item length
            invocation_length = max([len(s) for s in invocations])
            action_length = invocation_length + self._current_indent
            self._action_max_length = max(self._action_max_length,
                                          action_length)

            # add the item to the list
            self._add_item(self._format_action, [action])

Without this correction self._action_max_length is off by 2 if a subparser has the longest invocation.  Normally that wouldn't be an issue since normally subparser names are short and easy to use.  But with the 'aliases' that newer argparse allows, the invocation could be longer, and possibly longer than regular arguments.

I haven't passed this correction through test_argparse.py.  It also would need a test case or two.  I don't think it need a documentation change.

I don't know if this correction will work with the subparser grouping proposed in http://bugs.python.org/issue9341.

----------
Added file: http://bugs.python.org/file40661/issue25297.py

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

From report at bugs.python.org  Fri Oct  2 23:30:21 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 02 Oct 2015 21:30:21 +0000
Subject: [issue762963] timemodule.c: Python loses current timezone
Message-ID: <1443821421.09.0.554743765309.issue762963@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
resolution:  -> out of date
status: open -> closed
superseder:  -> Time zone-capable variant of time.localtime

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

From report at bugs.python.org  Fri Oct  2 23:38:35 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 02 Oct 2015 21:38:35 +0000
Subject: [issue10021] Format parser is too permissive
In-Reply-To: <1286209446.65.0.698670214161.issue10021@psf.upfronthosting.co.za>
Message-ID: <1443821915.29.0.805003531383.issue10021@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
stage:  -> needs patch
versions: +Python 3.6 -Python 3.2

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

From report at bugs.python.org  Fri Oct  2 23:43:06 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 02 Oct 2015 21:43:06 +0000
Subject: [issue13305] datetime.strftime("%Y") not consistent for years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <1443822186.69.0.531985777228.issue13305@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Can someone recap the status of this issue?  It is classified as a documentation bug, but I don't see a clear statement of what is wrong with the documentation.

----------
versions: +Python 3.6 -Python 3.3

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

From report at bugs.python.org  Sat Oct  3 00:00:19 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 02 Oct 2015 22:00:19 +0000
Subject: [issue14423] Getting the starting date of iso week from a week number
 and a year.
In-Reply-To: <1332849673.66.0.0828799259938.issue14423@psf.upfronthosting.co.za>
Message-ID: <1443823219.54.0.6145814661.issue14423@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I am rejecting this in favor of #12006.

----------
resolution:  -> rejected
status: open -> closed
superseder:  -> strptime should implement %G, %V and %u directives

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

From report at bugs.python.org  Sat Oct  3 00:00:23 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 02 Oct 2015 22:00:23 +0000
Subject: [issue25188] regrtest.py improvement for Profile Guided Optimization
 builds
In-Reply-To: <1442726782.64.0.586742420801.issue25188@psf.upfronthosting.co.za>
Message-ID: <1443823223.4.0.894841757915.issue25188@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Here is a patch for Python 3.6. I'll commit this after I eat before Victor changes something else. =)

----------
Added file: http://bugs.python.org/file40662/issue25188-py36.diff

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

From report at bugs.python.org  Sat Oct  3 00:13:55 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Oct 2015 22:13:55 +0000
Subject: [issue25258] HtmlParser doesn't handle void element tags correctly
In-Reply-To: <1443468394.25.0.617953373069.issue25258@psf.upfronthosting.co.za>
Message-ID: <1443824035.29.0.188037367081.issue25258@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> this inconsistent cannot be fixed from the inherited class as (handle_* 
> calls are dispatched in the internal method of HTMLParser)

You can override handle_startendtag() like this:

>>> class MyHTMLParser(HTMLParser):
...     def handle_starttag(self, tag, attrs):
...         print('start', tag)
...     def handle_endtag(self, tag):
...         print('end', tag)
...     def handle_startendtag(self, tag, attrs):
...         self.handle_starttag(tag, attrs)
... 
>>> parser = MyHTMLParser()
>>> parser.feed('<link rel="import"/><img src="som"/>')
start link
start img


(P.S. please don't quote the whole message in your reply)

----------

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

From report at bugs.python.org  Sat Oct  3 00:47:44 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Oct 2015 22:47:44 +0000
Subject: [issue22806] regrtest: add switch -c to run only modified tests
In-Reply-To: <1415285956.81.0.19215825371.issue22806@psf.upfronthosting.co.za>
Message-ID: <20151002224741.81380.11463@psf.io>


Roundup Robot added the comment:

New changeset 1005573e6a74 by Victor Stinner in branch 'default':
Issue #22806: Add ``python -m test --list-tests`` command to list tests.
https://hg.python.org/cpython/rev/1005573e6a74

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Oct  3 00:47:44 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Oct 2015 22:47:44 +0000
Subject: [issue18174] Make regrtest with --huntrleaks check for fd leaks
In-Reply-To: <1370807273.91.0.83033499223.issue18174@psf.upfronthosting.co.za>
Message-ID: <20151002224741.81380.90182@psf.io>


Roundup Robot added the comment:

New changeset 72129c767c92 by Victor Stinner in branch 'default':
Issue #18174: "python -m test --huntrleaks ..." now also checks for leak of
https://hg.python.org/cpython/rev/72129c767c92

----------

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

From report at bugs.python.org  Sat Oct  3 00:48:59 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 22:48:59 +0000
Subject: [issue22806] regrtest: add switch -c to run only modified tests
In-Reply-To: <1415285956.81.0.19215825371.issue22806@psf.upfronthosting.co.za>
Message-ID: <1443826139.19.0.194301053207.issue22806@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I added "python -m test --list-tests". It's not perfect but it's better than nothing :-p

----------

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

From report at bugs.python.org  Sat Oct  3 00:49:56 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 22:49:56 +0000
Subject: [issue18174] Make regrtest with --huntrleaks check for fd leaks
In-Reply-To: <20151002224741.81380.90182@psf.io>
Message-ID: <CAMpsgwYkxxOdHgdKqv8iF91bTC5qubBsjdPvjn5BC9Vv0MqY8w@mail.gmail.com>


STINNER Victor added the comment:

I commited the first part to check for file descriptor leak.

I didn't commit the second part, to check for Windows handle leak.

----------

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

From report at bugs.python.org  Sat Oct  3 00:52:15 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 22:52:15 +0000
Subject: [issue24848] Warts in UTF-7 error handling
In-Reply-To: <1439364965.73.0.526700604341.issue24848@psf.upfronthosting.co.za>
Message-ID: <1443826335.57.0.420744849857.issue24848@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Have no ideas why tests are failed and only on this buildbot.

test_codecs always crash on Python 3.6 with Python compiled in debug mode:

test_errors (test.test_codecs.UTF7Test) ... python: Objects/unicodeobject.c:1263: _copy_characters: Assertion `ch <= to_maxchar' failed.
Fatal Python error: Aborted

Current thread 0x00007f1489057700 (most recent call first):
  File "/home/haypo/prog/python/default/Lib/encodings/utf_7.py", line 12 in decode
  File "/home/haypo/prog/python/default/Lib/test/test_codecs.py", line 1021 in test_errors
  File "/home/haypo/prog/python/default/Lib/unittest/case.py", line 600 in run
  File "/home/haypo/prog/python/default/Lib/unittest/case.py", line 648 in __call__
  File "/home/haypo/prog/python/default/Lib/unittest/suite.py", line 122 in run
  File "/home/haypo/prog/python/default/Lib/unittest/suite.py", line 84 in __call__
  File "/home/haypo/prog/python/default/Lib/unittest/suite.py", line 122 in run
  File "/home/haypo/prog/python/default/Lib/unittest/suite.py", line 84 in __call__
  File "/home/haypo/prog/python/default/Lib/unittest/suite.py", line 122 in run
  File "/home/haypo/prog/python/default/Lib/unittest/suite.py", line 84 in __call__
  File "/home/haypo/prog/python/default/Lib/unittest/runner.py", line 176 in run
  File "/home/haypo/prog/python/default/Lib/test/support/__init__.py", line 1775 in _run_suite
  File "/home/haypo/prog/python/default/Lib/test/support/__init__.py", line 1809 in run_unittest
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/runtest.py", line 159 in test_runner
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/runtest.py", line 160 in runtest_inner
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/runtest.py", line 124 in runtest
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 285 in run_tests_sequential
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 344 in run_tests
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 380 in main
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 421 in main
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 443 in main_in_temp_cwd
  File "/home/haypo/prog/python/default/Lib/test/__main__.py", line 3 in <module>
  File "/home/haypo/prog/python/default/Lib/runpy.py", line 85 in _run_code
  File "/home/haypo/prog/python/default/Lib/runpy.py", line 170 in _run_module_as_main
Abandon (core dumped)

----------

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

From report at bugs.python.org  Sat Oct  3 00:54:07 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Oct 2015 22:54:07 +0000
Subject: [issue24848] Warts in UTF-7 error handling
In-Reply-To: <1439364965.73.0.526700604341.issue24848@psf.upfronthosting.co.za>
Message-ID: <1443826447.98.0.907042259372.issue24848@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oops, ignore my comment, I forgot to recompile Python. "make" and the bug is done :-)

----------

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

From report at bugs.python.org  Sat Oct  3 01:10:10 2015
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 02 Oct 2015 23:10:10 +0000
Subject: [issue14565] Allow multilevel subdirectories in cgi_directories
In-Reply-To: <1334254866.64.0.659489278184.issue14565@psf.upfronthosting.co.za>
Message-ID: <1443827410.81.0.00511755246354.issue14565@psf.upfronthosting.co.za>


Glenn Linderman added the comment:

Martin, thanks for the recent activity in this area. Sorry I've not yet learned how to submit patches. python_dev keeps busy changing the process and tools, and I keep busy with other projects, having patched a version of http-server well enough for my personal needs.

Your analysis that this is a new feature because the code doesn't support it, and the documentation is vague has some merit. 

On the other hand, the reason I called it a behavior bug in the first place is comparison to other web servers that support multi-part paths to cgi scripts indicates it is clearly deficient by comparison... and the documentation isn't explicit enough to say so, so it can be considered a "deficient" if not "buggy" implementation. Certainly, any attempt to port a real web site that depends heavily on cgi scripts to http-server would be extremely likely to fail due to this deficiency, that is not documented as a limitation of the "generally expected" abilities of a web server.

It'd sure be nice to fix it, whether it is called a bug or an enhancement, and the fix is in the comments above.

----------

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

From report at bugs.python.org  Sat Oct  3 01:20:58 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Oct 2015 23:20:58 +0000
Subject: [issue25188] regrtest.py improvement for Profile Guided Optimization
 builds
In-Reply-To: <1442726782.64.0.586742420801.issue25188@psf.upfronthosting.co.za>
Message-ID: <20151002232054.31187.14212@psf.io>


Roundup Robot added the comment:

New changeset fb90425017e3 by Brett Cannon in branch '3.5':
Issue #25188: Add a -P/--pgo flag to regrtest to silence error output.
https://hg.python.org/cpython/rev/fb90425017e3

New changeset c1ecb258003b by Brett Cannon in branch 'default':
Merge from 3.5 for issue #25188.
https://hg.python.org/cpython/rev/c1ecb258003b

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Oct  3 01:22:44 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Oct 2015 23:22:44 +0000
Subject: [issue25188] regrtest.py improvement for Profile Guided Optimization
 builds
In-Reply-To: <1442726782.64.0.586742420801.issue25188@psf.upfronthosting.co.za>
Message-ID: <20151002232241.55482.61200@psf.io>


Roundup Robot added the comment:

New changeset 136ad559fa4f by Brett Cannon in branch '2.7':
Issue #25188: Add -P/--pgo to test.regrtest for PGO building.
https://hg.python.org/cpython/rev/136ad559fa4f

----------

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

From report at bugs.python.org  Sat Oct  3 01:23:41 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 02 Oct 2015 23:23:41 +0000
Subject: [issue25188] regrtest.py improvement for Profile Guided Optimization
 builds
In-Reply-To: <1442726782.64.0.586742420801.issue25188@psf.upfronthosting.co.za>
Message-ID: <1443828221.55.0.80620208633.issue25188@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks for the initial patch, Alecsandru! May I not have to touch regrtest until after Victor is done doing whatever he is doing to it in 3.6. =)

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Oct  3 01:24:35 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 02 Oct 2015 23:24:35 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1443828275.28.0.919265799728.issue24915@psf.upfronthosting.co.za>


Brett Cannon added the comment:

regrtest changes are now in 2.7, 3.5, and default in spite of Victor changing everything underneath me constantly in default. =) That should make the buildbot happy again.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sat Oct  3 01:25:41 2015
From: report at bugs.python.org (Akira Li)
Date: Fri, 02 Oct 2015 23:25:41 +0000
Subject: [issue25288] readline.py file in current directory caused unexpected
 code execution.
In-Reply-To: <1443691601.94.0.65090362489.issue25288@psf.upfronthosting.co.za>
Message-ID: <1443828341.74.0.500208769423.issue25288@psf.upfronthosting.co.za>


Akira Li added the comment:

python3 -I

could be used as a workaround.

----------
nosy: +akira

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

From report at bugs.python.org  Sat Oct  3 02:01:15 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Oct 2015 00:01:15 +0000
Subject: [issue25301] Optimize UTF-8 decoder with error handlers
In-Reply-To: <1443797082.73.0.711354360874.issue25301@psf.upfronthosting.co.za>
Message-ID: <1443830475.82.0.913366822978.issue25301@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Here is a first patch. It is written to keep best performances for valid UTF-8 encoded string, but speedup strings with a few undecodable bytes.

----------
keywords: +patch
Added file: http://bugs.python.org/file40663/utf8_decoder.patch

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

From report at bugs.python.org  Sat Oct  3 02:02:58 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Oct 2015 00:02:58 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1443828275.28.0.919265799728.issue24915@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwY3h--kFNuCDFg8Hb7AV24LOvGnPKE6D6ASNp83R0N8oA@mail.gmail.com>


STINNER Victor added the comment:

> regrtest changes are now in 2.7, 3.5, and default in spite of Victor changing everything underneath me constantly in default. =) That should make the buildbot happy again.

Yeah sorry, it was my regrtest week :-)

----------

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

From report at bugs.python.org  Sat Oct  3 02:22:28 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Oct 2015 00:22:28 +0000
Subject: [issue18174] Make regrtest with --huntrleaks check for fd leaks
In-Reply-To: <1370807273.91.0.83033499223.issue18174@psf.upfronthosting.co.za>
Message-ID: <20151003002216.18390.99086@psf.io>


Roundup Robot added the comment:

New changeset ec2ef7525fa5 by Victor Stinner in branch 'default':
Issue #18174: Fix test_regrtest when Python is compiled in release mode
https://hg.python.org/cpython/rev/ec2ef7525fa5

----------

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

From report at bugs.python.org  Sat Oct  3 02:25:36 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 03 Oct 2015 00:25:36 +0000
Subject: [issue24915] Profile Guided Optimization improvements (better
 training, llvm support, etc)
In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za>
Message-ID: <1443831936.15.0.309295565074.issue24915@psf.upfronthosting.co.za>


Brett Cannon added the comment:

It's fine. =) Glad it was for good reasons. Just took quite a while to manually apply the old patch to the new layout and then fix merges.

----------

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

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: [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 04:13:24 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Oct 2015 02:13:24 +0000
Subject: [issue24820] IDLE themes for light on dark
In-Reply-To: <1438923257.49.0.103520260228.issue24820@psf.upfronthosting.co.za>
Message-ID: <20151003021321.20777.31432@psf.io>


Roundup Robot added the comment:

New changeset e67da755d614 by Terry Jan Reedy in branch '2.7':
Issue #24820: Users can now set breakpoint colors in Settings ->
https://hg.python.org/cpython/rev/e67da755d614

New changeset d874a6157223 by Terry Jan Reedy in branch '3.4':
Issue #24820: Users can now set breakpoint colors in Settings ->
https://hg.python.org/cpython/rev/d874a6157223

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Oct  3 04:23:24 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 03 Oct 2015 02:23:24 +0000
Subject: [issue24820] IDLE themes for light on dark
In-Reply-To: <1438923257.49.0.103520260228.issue24820@psf.upfronthosting.co.za>
Message-ID: <1443839004.21.0.502981855017.issue24820@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I was going to push both a version of the breakpoint patch and the new theme, but noticed a problem.  If someone selects IDLE Dark and saves that choice and then run an older Python+IDLE, then the older IDLE will not find 'IDLE Dark' and will run a backup default black and white theme, possibly with some error messages.  The solution is to select IDLE Dark and then immediately hit [Save as New Custom Theme] and enter a different name.  IDLE will then change Select: from (o) a Built-in Theme to (o) a Custom Theme, with the saved name selected.  I want to add a popup to say this before adding the theme.

----------

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

From report at bugs.python.org  Sat Oct  3 05:26:23 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Oct 2015 03:26:23 +0000
Subject: [issue25224] Replace Idle's README.txt with annotated file list
In-Reply-To: <1443045409.48.0.261448310489.issue25224@psf.upfronthosting.co.za>
Message-ID: <20151003032620.70981.52111@psf.io>


Roundup Robot added the comment:

New changeset 4e62989e3688 by Terry Jan Reedy in branch '2.7':
Issue #25224: README.txt is now an idlelib index for IDLE developers and
https://hg.python.org/cpython/rev/4e62989e3688

New changeset bb1a8d3dd4a1 by Terry Jan Reedy in branch '3.4':
Issue #25224: README.txt is now an idlelib index for IDLE developers and
https://hg.python.org/cpython/rev/bb1a8d3dd4a1

----------

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

From report at bugs.python.org  Sat Oct  3 05:28:46 2015
From: report at bugs.python.org (Stuart Bishop)
Date: Sat, 03 Oct 2015 03:28:46 +0000
Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation)
In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za>
Message-ID: <1443842926.92.0.418894633262.issue24773@psf.upfronthosting.co.za>


Changes by Stuart Bishop <stuart at stuartbishop.net>:


----------
nosy: +stub

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

From report at bugs.python.org  Sat Oct  3 05:29:29 2015
From: report at bugs.python.org (chris laws)
Date: Sat, 03 Oct 2015 03:29:29 +0000
Subject: [issue23972] Asyncio reuseport
In-Reply-To: <1429185135.77.0.485030290106.issue23972@psf.upfronthosting.co.za>
Message-ID: <1443842969.19.0.684670105832.issue23972@psf.upfronthosting.co.za>


chris laws added the comment:

Updates addressing review comments.

----------
Added file: http://bugs.python.org/file40664/23972_cjl_v004.patch

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

From report at bugs.python.org  Sat Oct  3 06:07:42 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 03 Oct 2015 04:07:42 +0000
Subject: [issue19917] [httplib] logging information for request is not pretty
 printed
In-Reply-To: <1386413080.92.0.351429113589.issue19917@psf.upfronthosting.co.za>
Message-ID: <1443845262.57.0.934916944722.issue19917@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Closing as a duplicate of issue 24255.

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage: test needed -> resolved
status: open -> closed
superseder:  -> Replace debuglevel-related logic with logging

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

From report at bugs.python.org  Sat Oct  3 06:17:08 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Oct 2015 04:17:08 +0000
Subject: [issue25238] Version added of context parameter for
 xmlrpc.client.ServerProxy incorrect
In-Reply-To: <1443268662.53.0.0661786105223.issue25238@psf.upfronthosting.co.za>
Message-ID: <1443845828.8.0.587326264441.issue25238@psf.upfronthosting.co.za>


Martin Panter added the comment:

What are you proposing? I think you will find both cases are true. The change was made in 3.4 (but only in time for 3.4.3+) and 3.5 (starting at 3.5.0). If the documentation failed to mention 3.5 and only mentioned 3.4.3, it would not be obvious if that change made it into 3.5.0, or only the upcoming 3.5.1, etc.

See the ?Changed in version 3.3.1? notice at <https://docs.python.org/3/library/subprocess.html#subprocess.Popen> for a similar case, which mentions both versions.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, martin.panter

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

From report at bugs.python.org  Sat Oct  3 06:20:18 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 03 Oct 2015 04:20:18 +0000
Subject: [issue24177] Add https?_proxy support to http.client
In-Reply-To: <1431533065.95.0.88567271375.issue24177@psf.upfronthosting.co.za>
Message-ID: <1443846018.2.0.543046366253.issue24177@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

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

From report at bugs.python.org  Sat Oct  3 06:53:45 2015
From: report at bugs.python.org (paul j3)
Date: Sat, 03 Oct 2015 04:53:45 +0000
Subject: [issue25299] TypeError: __init__() takes at least 4 arguments (4
 given)
In-Reply-To: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za>
Message-ID: <1443848025.64.0.420161293456.issue25299@psf.upfronthosting.co.za>


paul j3 added the comment:

A fix that I am exploring would wrap the Action instantiation call in add_argument with a try/except block

That is replace:

    def add_argument(...)
        ....
        action = action_class(**kwargs)
        ...

with

        ....
        try:
            action = action_class(**kwargs)
        except TypeError:
            msg = str(_sys.exc_info()[1])
            msg = msg.replace('__init__','add_argument')
            msg = [msg]
            msg.append('Wrong argument(s) for Action subclass: %s'%action_class.__name__)
            # action_class is now a class, rather than the input string
            msg.append('kwargs: %s'%kwargs)
            sig = getattr(action_class, 'action_sig',None)
            if sig is not None:
                msg = sig(msg)
            raise ValueError(msg)
       ....

This collects information on the error, the action class and arguments, and passes them to a class method of the Action.  That customizes the message, and returns it for reraising.

In 'class Action' I define:

    @classmethod
    def action_sig(cls, msg=[]):
        # return the signature
        # subclasses may return custom version
        import inspect
        try:
            name = cls.__name__
            sig = inspect.signature(cls.__init__)
            sig = str(sig)
        except AttributeError:
            spec = inspect.getfullargspec(cls.__init__)
            sig = inspect.formatargspec(*spec)
        # remove self, option_strings, dest
        dstr='dest,'
        ind = sig.find(dstr)
        if ind>=0:
            sig = '(...'+sig[(ind+len(dstr)+1):]
        sig = 'class args: %s'%sig
        msg.append(sig)
        return '\n'.join(msg)

This adds inspect.signature information from the subclass __init__ method to the message from add_argument.  Subclasses (including the user defined ones) could customize this.

So a missing 'const' error would display as:

ValueError: add_argument() missing 1 required positional argument: 'const'
Wrong argument(s) for Action subclass: _StoreConstAction
kwargs: {'option_strings': ['--bar'], 'dest': 'bar'}
class args: (...const, default=None, required=False, help=None, metavar=None)

This may be overkill, but it gives an idea of the information that we can add to the original TypeError.

Done right this action_sig() could also serve as a usage function for an Action class.

----------
keywords: +3.5regression

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

From report at bugs.python.org  Sat Oct  3 07:13:10 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Oct 2015 05:13:10 +0000
Subject: [issue25228] Regression in cookie parsing with brackets and quotes
In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za>
Message-ID: <1443849190.04.0.309054368267.issue25228@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the test case. It looks like the commit in question was done as a security fix in 3.2.6 and 3.3.6. I?m not sure on the policy, but maybe that justifies putting any fixes into 3.2+.

I?m not familiar with HTTP cookies. Is this a case of a 100% specification-compiliant cookie, or a technically invalid one that would be nice to handle better? If the second case, maybe it is an instance of Issue 22983.

----------
keywords: +3.2regression
nosy: +martin.panter
stage:  -> needs patch

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

From report at bugs.python.org  Sat Oct  3 07:27:13 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Oct 2015 05:27:13 +0000
Subject: [issue25232] CGIRequestHandler behave incorrectly with query
 component consisting mutliple ?
In-Reply-To: <1443195881.69.0.030953923686.issue25232@psf.upfronthosting.co.za>
Message-ID: <1443850033.64.0.0458199339798.issue25232@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
assignee:  -> martin.panter
nosy: +berker.peksag
stage: patch review -> commit review

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

From report at bugs.python.org  Sat Oct  3 07:27:55 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Oct 2015 05:27:55 +0000
Subject: [issue24657] CGIHTTPServer module discard continuous '/' letters from
 params given by GET method.
In-Reply-To: <1437187776.37.0.855244973055.issue24657@psf.upfronthosting.co.za>
Message-ID: <1443850075.68.0.589162380921.issue24657@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
assignee:  -> martin.panter
nosy: +berker.peksag
stage: patch review -> commit review

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

From report at bugs.python.org  Sat Oct  3 08:41:14 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Oct 2015 06:41:14 +0000
Subject: [issue24177] Add https?_proxy support to http.client
In-Reply-To: <1431533065.95.0.88567271375.issue24177@psf.upfronthosting.co.za>
Message-ID: <1443854474.51.0.266044944305.issue24177@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think this would have a serious chance of breaking stuff unless it was only enabled with a new flag or similar. Also, I guess it would probably be limited to Basic authentication.

The wget and curl programs both support different URL protocols, HTTP redirects (if curl --location is enabled), etc. In my mind they operate at a higher level, like urlopen(), and http.client is a more lower-level client. Are there many use cases where you would want proxy support for a HTTP request, but wouldn?t want to use urlopen() or some other high-level library like Requests?

----------
nosy: +martin.panter

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

From report at bugs.python.org  Sat Oct  3 08:44:36 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Oct 2015 06:44:36 +0000
Subject: [issue25232] CGIRequestHandler behave incorrectly with query
 component consisting mutliple ?
In-Reply-To: <1443195881.69.0.030953923686.issue25232@psf.upfronthosting.co.za>
Message-ID: <20151003064433.55458.83728@psf.io>


Roundup Robot added the comment:

New changeset 969afbf501af by Martin Panter in branch '3.4':
Issue #25232: Fix CGIRequestHandler's splitting of URL query
https://hg.python.org/cpython/rev/969afbf501af

New changeset ba1e3c112e42 by Martin Panter in branch '3.5':
Issues #25232, #24657: Merge two CGI server fixes from 3.4 into 3.5
https://hg.python.org/cpython/rev/ba1e3c112e42

New changeset 88918f2a54df by Martin Panter in branch '3.5':
Issues #25232, #24657: Use new enum status to match rest of tests
https://hg.python.org/cpython/rev/88918f2a54df

New changeset 0f03023d4318 by Martin Panter in branch 'default':
Issues #25232, #24657: Merge two CGI server fixes from 3.5
https://hg.python.org/cpython/rev/0f03023d4318

New changeset 3c006ee38287 by Martin Panter in branch 'default':
Issues #25232, #24657: Add NEWS to 3.6.0a1 section
https://hg.python.org/cpython/rev/3c006ee38287

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Oct  3 08:44:36 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Oct 2015 06:44:36 +0000
Subject: [issue24657] CGIHTTPServer module discard continuous '/' letters from
 params given by GET method.
In-Reply-To: <1437187776.37.0.855244973055.issue24657@psf.upfronthosting.co.za>
Message-ID: <20151003064433.55458.33438@psf.io>


Roundup Robot added the comment:

New changeset 634fe6a90e0c by Martin Panter in branch '3.4':
Issue #24657: Prevent CGIRequestHandler from collapsing the URL query
https://hg.python.org/cpython/rev/634fe6a90e0c

New changeset ba1e3c112e42 by Martin Panter in branch '3.5':
Issues #25232, #24657: Merge two CGI server fixes from 3.4 into 3.5
https://hg.python.org/cpython/rev/ba1e3c112e42

New changeset 88918f2a54df by Martin Panter in branch '3.5':
Issues #25232, #24657: Use new enum status to match rest of tests
https://hg.python.org/cpython/rev/88918f2a54df

New changeset 0f03023d4318 by Martin Panter in branch 'default':
Issues #25232, #24657: Merge two CGI server fixes from 3.5
https://hg.python.org/cpython/rev/0f03023d4318

New changeset 3c006ee38287 by Martin Panter in branch 'default':
Issues #25232, #24657: Add NEWS to 3.6.0a1 section
https://hg.python.org/cpython/rev/3c006ee38287

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Oct  3 09:27:40 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Oct 2015 07:27:40 +0000
Subject: [issue25232] CGIRequestHandler behave incorrectly with query
 component consisting mutliple ?
In-Reply-To: <1443195881.69.0.030953923686.issue25232@psf.upfronthosting.co.za>
Message-ID: <20151003072736.128854.2058@psf.io>


Roundup Robot added the comment:

New changeset b12b30dc8617 by Martin Panter in branch '2.7':
Issue #25232: Fix CGIRequestHandler's splitting of URL query
https://hg.python.org/cpython/rev/b12b30dc8617

----------

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

From report at bugs.python.org  Sat Oct  3 09:27:40 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Oct 2015 07:27:40 +0000
Subject: [issue24657] CGIHTTPServer module discard continuous '/' letters from
 params given by GET method.
In-Reply-To: <1437187776.37.0.855244973055.issue24657@psf.upfronthosting.co.za>
Message-ID: <20151003072736.128854.19756@psf.io>


Roundup Robot added the comment:

New changeset a4302005f9a2 by Martin Panter in branch '2.7':
Issue #24657: Prevent CGIRequestHandler from collapsing the URL query
https://hg.python.org/cpython/rev/a4302005f9a2

----------

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

From report at bugs.python.org  Sat Oct  3 09:38:07 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Oct 2015 07:38:07 +0000
Subject: [issue16701] Docs missing the behavior of += (in-place add) for lists.
In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za>
Message-ID: <1443857887.09.0.488332081795.issue16701@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
assignee: docs at python -> martin.panter
nosy: +berker.peksag
stage: patch review -> commit review

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

From report at bugs.python.org  Sat Oct  3 09:39:42 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Oct 2015 07:39:42 +0000
Subject: [issue24657] CGIHTTPServer module discard continuous '/' letters from
 params given by GET method.
In-Reply-To: <1437187776.37.0.855244973055.issue24657@psf.upfronthosting.co.za>
Message-ID: <1443857982.18.0.995262232465.issue24657@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks everyone for the reports and patches. There were a couple of subtle compatibility tweaks needed for the 3.4 and 2.7 branches, but I think I got them all.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sat Oct  3 09:39:53 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Oct 2015 07:39:53 +0000
Subject: [issue24657] CGIHTTPServer module discard continuous '/' letters from
 params given by GET method.
In-Reply-To: <1437187776.37.0.855244973055.issue24657@psf.upfronthosting.co.za>
Message-ID: <1443857993.8.0.328329931926.issue24657@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
stage: commit review -> resolved

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

From report at bugs.python.org  Sat Oct  3 09:40:56 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Oct 2015 07:40:56 +0000
Subject: [issue25232] CGIRequestHandler behave incorrectly with query
 component consisting mutliple ?
In-Reply-To: <1443195881.69.0.030953923686.issue25232@psf.upfronthosting.co.za>
Message-ID: <1443858056.58.0.252920718389.issue25232@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Oct  3 10:02:24 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Oct 2015 08:02:24 +0000
Subject: [issue16701] Docs missing the behavior of += (in-place add) for lists.
In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za>
Message-ID: <20151003080221.483.288@psf.io>


Roundup Robot added the comment:

New changeset ec373d762213 by Martin Panter in branch '2.7':
Issue #16701: Document += and *= for mutable sequences
https://hg.python.org/cpython/rev/ec373d762213

New changeset f83db23bec7f by Martin Panter in branch '3.4':
Issue #16701: Document += and *= for mutable sequences
https://hg.python.org/cpython/rev/f83db23bec7f

New changeset 6e43a3833293 by Martin Panter in branch '3.5':
Issue #16701: Merge sequence docs from 3.4 into 3.5
https://hg.python.org/cpython/rev/6e43a3833293

New changeset a92466bf16cc by Martin Panter in branch 'default':
Issue #16701: Merge sequence docs from 3.5
https://hg.python.org/cpython/rev/a92466bf16cc

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Oct  3 10:05:10 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Oct 2015 08:05:10 +0000
Subject: [issue16701] Docs missing the behavior of += (in-place add) for lists.
In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za>
Message-ID: <1443859510.88.0.186626500001.issue16701@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Oct  3 10:26:55 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sat, 03 Oct 2015 08:26:55 +0000
Subject: [issue25188] regrtest.py improvement for Profile Guided Optimization
 builds
In-Reply-To: <1442726782.64.0.586742420801.issue25188@psf.upfronthosting.co.za>
Message-ID: <1443860815.74.0.924253456455.issue25188@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

Thank you Brett for your effort to merge all the changes made to regrtest despite the changes appeared on the way!

----------

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

From report at bugs.python.org  Sat Oct  3 11:23:14 2015
From: report at bugs.python.org (desbma)
Date: Sat, 03 Oct 2015 09:23:14 +0000
Subject: [issue25238] Version added of context parameter for
 xmlrpc.client.ServerProxy incorrect
In-Reply-To: <1443268662.53.0.0661786105223.issue25238@psf.upfronthosting.co.za>
Message-ID: <1443864194.28.0.535173916385.issue25238@psf.upfronthosting.co.za>


desbma added the comment:

In my mind 3.4.3 < 3.5, so unless mentioned otherwise it is implied that  the change is in all versions of the 3.5 branch.

----------

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

From report at bugs.python.org  Sat Oct  3 11:24:40 2015
From: report at bugs.python.org (desbma)
Date: Sat, 03 Oct 2015 09:24:40 +0000
Subject: [issue25238] Version added of context parameter for
 xmlrpc.client.ServerProxy incorrect
In-Reply-To: <1443268662.53.0.0661786105223.issue25238@psf.upfronthosting.co.za>
Message-ID: <1443864280.91.0.371594524181.issue25238@psf.upfronthosting.co.za>


desbma added the comment:

Previous sentence is if we only mention 3.4.3 of course.

----------

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

From report at bugs.python.org  Sat Oct  3 11:45:41 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Oct 2015 09:45:41 +0000
Subject: [issue22413] Bizarre StringIO(newline="\r\n") translation
In-Reply-To: <1410750243.44.0.979805676788.issue22413@psf.upfronthosting.co.za>
Message-ID: <1443865541.34.0.824782680508.issue22413@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a suggested patch. I did include details of the initializer and getvalue(); this is the heart of the problem IMO. In a limited sense the newline flag _is_ similar to TextIOWrapper, but more broadly this implied to me that newlines should be encoded in the buffer, just like in TextIOWrapper?s wrapped ?buffer? and on disk.

My patch also adds to a comment in the C code and removes another comment made out of date by Argument Clinic.

In the documentation I didn?t mention the problem with split CRLFs; I think that is a separate bug.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage:  -> patch review
status: closed -> open
versions: +Python 2.7, Python 3.6
Added file: http://bugs.python.org/file40665/newline-doc.patch

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

From report at bugs.python.org  Sat Oct  3 13:35:55 2015
From: report at bugs.python.org (Alex Warhawk)
Date: Sat, 03 Oct 2015 11:35:55 +0000
Subject: [issue19500] Error when connecting to FTPS servers not supporting SSL
 session resuming
In-Reply-To: <1383624130.64.0.185541289049.issue19500@psf.upfronthosting.co.za>
Message-ID: <1443872155.98.0.443625489183.issue19500@psf.upfronthosting.co.za>


Alex Warhawk added the comment:

I encountered this problem recently and could not find a fix, so i tried fixing it myself.

Note that the patch attached is my first contribution to cpython as well as the first time I used the C extension mechanism. Therefore I do not consider the patch polished enough to be just merged upstream.

Maybe it helps in solving this issue.

The attached patch is based on:
changeset:   79113:ec373d762213
branch:      2.7

----------
keywords: +patch
nosy: +Alex Warhawk
Added file: http://bugs.python.org/file40666/reuse_session.diff

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

From report at bugs.python.org  Sat Oct  3 13:46:04 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Oct 2015 11:46:04 +0000
Subject: [issue14565] Allow multilevel subdirectories in cgi_directories
In-Reply-To: <1334254866.64.0.659489278184.issue14565@psf.upfronthosting.co.za>
Message-ID: <1443872764.82.0.769718223604.issue14565@psf.upfronthosting.co.za>


Martin Panter added the comment:

The patch looks like it also adds support for individual script file names in cgi_directories. If that is the case, I suspect it would be tricked by a query string (e.g. /some.cgi?query).

I object to removing the final ?return False?. The return value of is_cgi() is significant, and it good to be explicit about what it is returning.

It would be helpful to get a test case. Or multiple test cases if I am right about the individual file support.

And the documentation needs updating saying what is supported, with a ?Version changed? notice. It would also be good to be specific about the syntax for cgi_directories. E.g. must start with a slash, cannot use Windows backslashes, must be a normalized path, not URL encoded. Is the root directory allowed?

----------
stage:  -> patch review

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

From report at bugs.python.org  Sat Oct  3 14:19:59 2015
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 03 Oct 2015 12:19:59 +0000
Subject: [issue25302] Memory Leaks with Address Sanitizer
In-Reply-To: <1443801865.56.0.796405543991.issue25302@psf.upfronthosting.co.za>
Message-ID: <1443874799.53.0.478103929318.issue25302@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Static types leak memory on finalization, see PEP 3121. Normally it
does not matter, but you see it when embedding Python.

PEP 3121 isn't widely implemented because a) it complicates the
code for large modules and b) there are some performance issues.


There are several other open issues for the problem, so I'm closing
this one.

----------
nosy: +skrah
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Oct  3 14:26:43 2015
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 03 Oct 2015 12:26:43 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1443875203.9.0.0479933635489.issue25300@psf.upfronthosting.co.za>


Stefan Krah added the comment:

> Whether the hardware is MPX enabled is irrelevant for the build process.


The build process is only one part of the equation.  Compilers do have
bugs (Python has been affected by gcc, Visual Studio and suncc bugs),
and we should test the actual generated MPX code.

----------

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

From report at bugs.python.org  Sat Oct  3 14:54:38 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 03 Oct 2015 12:54:38 +0000
Subject: [issue25294] Absolute imports fail in some cases where relative
 imports would work
In-Reply-To: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>
Message-ID: <1443876878.67.0.147066133898.issue25294@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Issue 992389 is the previous incarnation of this bug report, while issue 17636 made the change so that from imports will resolve in some situations where this error will occur.

That fact that "from x.y.b import foo" may now resolve in cases where "import x.y.b; foo = x.y.b.foo" will fail should indeed be covered in the documentation.

If PEP 8 were to be updated at all, it should just say "Don't use circular imports. If you can't refactor your design to move the common components out to a shared helper module, then move everything into the same module - the irremovable circular dependency indicates the code is too tightly coupled to live in different modules".

----------

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

From report at bugs.python.org  Sat Oct  3 15:56:30 2015
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 03 Oct 2015 13:56:30 +0000
Subject: [issue25276] Intermittent segfaults on PPC64 AIX 3.x
In-Reply-To: <1443605165.97.0.433720501229.issue25276@psf.upfronthosting.co.za>
Message-ID: <1443880590.86.0.885590107553.issue25276@psf.upfronthosting.co.za>


Stefan Krah added the comment:

> It's possible that Python needs to be built with special options to allow additional malloc space (-bmaxdata:0xN0000000).

It seems to be the case, see Misc/README.AIX.  This could explain the
MemoryErrors, but not the segfaults.


Are computed-gotos stable on gcc-AIX?  The README recommends disabling
them for xlc.


I'm also not sure how well Python supports threads on AIX. Often
these problems go away on unsupported platforms when configuring
--without-threads.

----------

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

From report at bugs.python.org  Sat Oct  3 16:06:53 2015
From: report at bugs.python.org (David Edelsohn)
Date: Sat, 03 Oct 2015 14:06:53 +0000
Subject: [issue25276] Intermittent segfaults on PPC64 AIX 3.x
In-Reply-To: <1443605165.97.0.433720501229.issue25276@psf.upfronthosting.co.za>
Message-ID: <1443881213.93.0.589379452071.issue25276@psf.upfronthosting.co.za>


David Edelsohn added the comment:

Misc/README.AIX comments about XLC do not apply to GCC.

One can adjust the memory space at normal link time with -Wl,-bmaxdata:0xN0000000. This trades off heap for shared memory segments. One does not need the extra ldedit stop, which stuffs the same value into the application header.

----------

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

From report at bugs.python.org  Sat Oct  3 16:30:04 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 03 Oct 2015 14:30:04 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1443882604.77.0.650331552713.issue25300@psf.upfronthosting.co.za>


R. David Murray added the comment:

No go on the ICC mac buildbot then, it's an i7-4578U, so not even gen 5.

----------

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

From report at bugs.python.org  Sat Oct  3 16:45:51 2015
From: report at bugs.python.org (Tim Graham)
Date: Sat, 03 Oct 2015 14:45:51 +0000
Subject: [issue25228] Regression in cookie parsing with brackets and quotes
In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za>
Message-ID: <1443883551.74.0.958655344412.issue25228@psf.upfronthosting.co.za>


Tim Graham added the comment:

It might be a case of issue22983. I'll try to look into the details and offer a patch next week.

For what it's worth, there are other regressions in Python 3.2 cookie parsing that makes the latest patch release (3.2.6) unusable with Django (issue22758), so from my perspective fixing this issue there isn't as high priority as that one.

----------

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

From report at bugs.python.org  Sat Oct  3 16:47:47 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 03 Oct 2015 14:47:47 +0000
Subject: [issue25258] HtmlParser doesn't handle void element tags correctly
In-Reply-To: <1443468394.25.0.617953373069.issue25258@psf.upfronthosting.co.za>
Message-ID: <1443883667.05.0.503790260445.issue25258@psf.upfronthosting.co.za>


R. David Murray added the comment:

I suspect that calling startendtag is also backward incompatible, in that there may be parsers out there that are depending on starttag getting called for <img>, and endtag not getting called (that is, endtag getting called for it will cause them to break).  I would hope that this would not be the case, but I'm worried about it.

----------
nosy: +r.david.murray

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

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: [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 17:26:10 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 03 Oct 2015 15:26:10 +0000
Subject: [issue25304] Add run_coroutine_threadsafe() to asyncio
In-Reply-To: <1443885833.8.0.0767295795531.issue25304@psf.upfronthosting.co.za>
Message-ID: <1443885970.3.0.62711536713.issue25304@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy: +vxgmichel

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

From report at bugs.python.org  Sat Oct  3 17:34:31 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 03 Oct 2015 15:34:31 +0000
Subject: [issue25303] py_compile disregards PYTHONDONTWRITEBYTECODE and -B
In-Reply-To: <1443833531.37.0.101836027368.issue25303@psf.upfronthosting.co.za>
Message-ID: <1443886471.31.0.351047969982.issue25303@psf.upfronthosting.co.za>


R. David Murray added the comment:

The only reason to call py_compile is to get byte code.  Honoring PYTHONDONTWRITEBYTECODE would, IMO, be a bug, at least according to its documentation (by implication, it isn't explicit about it, and perhaps it should be).

Your use case could be added as a feature by adding a command line option to py_compile, but that would be 3.6 only.

On the other hand, you can achieve your use case via the following:

    python -B -c 'import $MYFILE'

(without the '.py' on the end, obviously).

which is actually shorter, so at first I was inclined to just reject that as unneeded.  (In a Makefile you'd want to CD to the directory or put the directory on the PYTHONPATH, which makes it slightly longer but not much.)

py_compile has an interesting little bug, though: if you pass it a script name, it will happily create an *invalid* .pyc file (eg: python -m py_compile results in a tempcpython-36.pyc file).  compileall on the other hand just ignores files that don't end in .py, which is also a bit odd when the file is named explicitly on the path.  So I suppose that's a bug too.

But absent py_compile's bug, there's no easy way that I know of to "syntax check" a *script* without executing it.  So this is probably a worthwhile enhancement.

Note: if we were designing this from scratch we might decide that honoring -B/PYTHONDONTWRITEBYTECODE was the right way to spell this, but since we are not, I don't think we can change py_compile's behavior in this regard for backward compatibility reasons, so adding an option to py_compile seems the best course.

----------
nosy: +r.david.murray
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.6 -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:35:58 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Oct 2015 15:35:58 +0000
Subject: [issue25304] Add run_coroutine_threadsafe() to asyncio
In-Reply-To: <1443885833.8.0.0767295795531.issue25304@psf.upfronthosting.co.za>
Message-ID: <20151003153555.20753.54611@psf.io>


Roundup Robot added the comment:

New changeset 25e05b3e1869 by Guido van Rossum in branch '3.4':
Issue #25304: Add asyncio.run_coroutine_threadsafe(). By Vincent Michel.
https://hg.python.org/cpython/rev/25e05b3e1869

New changeset e0db10d8c95e by Guido van Rossum in branch '3.5':
Issue #25304: Add asyncio.run_coroutine_threadsafe(). By Vincent Michel. (Merge 3.4->3.5.)
https://hg.python.org/cpython/rev/e0db10d8c95e

New changeset 69829a7fccde by Guido van Rossum in branch 'default':
Issue #25304: Add asyncio.run_coroutine_threadsafe(). By Vincent Michel. (Merge 3.5->3.6.)
https://hg.python.org/cpython/rev/69829a7fccde

----------
nosy: +python-dev

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

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


Guido van Rossum added the comment:

It's done. But I am hoping you (or someone) will add docs.

----------

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

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


Changes by Guido van Rossum <guido at python.org>:


----------
stage:  -> commit review
type:  -> behavior

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

From report at bugs.python.org  Sat Oct  3 17:38:48 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 03 Oct 2015 15:38:48 +0000
Subject: [issue25238] Version added of context parameter for
 xmlrpc.client.ServerProxy incorrect
In-Reply-To: <1443268662.53.0.0661786105223.issue25238@psf.upfronthosting.co.za>
Message-ID: <1443886728.16.0.92905098817.issue25238@psf.upfronthosting.co.za>


R. David Murray added the comment:

I agree with desbma, but would not consider it unreasonable to mention both versions in the 3.5+ docs in order to avoid any ambiguity.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Sat Oct  3 17:41:43 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 03 Oct 2015 15:41:43 +0000
Subject: [issue24177] Add https?_proxy support to http.client
In-Reply-To: <1431533065.95.0.88567271375.issue24177@psf.upfronthosting.co.za>
Message-ID: <1443886903.95.0.134144417057.issue24177@psf.upfronthosting.co.za>


R. David Murray added the comment:

I agree, I think that any proxy support in http.client would need to be opt-in and not on-by-default, exactly because it is a lower level library.

----------

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

From report at bugs.python.org  Sat Oct  3 17:42:53 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 03 Oct 2015 15:42:53 +0000
Subject: [issue24177] Add https?_proxy support to http.client
In-Reply-To: <1431533065.95.0.88567271375.issue24177@psf.upfronthosting.co.za>
Message-ID: <1443886973.47.0.484874494254.issue24177@psf.upfronthosting.co.za>


R. David Murray added the comment:

And it should only be added if it actually makes *sense* in the architecture of http.client, which I haven't reviewed with this in mind.

----------

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

From report at bugs.python.org  Sat Oct  3 17:51:13 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 03 Oct 2015 15:51:13 +0000
Subject: [issue25278] Unexpected socket exception on SFTP 'STOR' command
In-Reply-To: <1443619244.64.0.188831758146.issue25278@psf.upfronthosting.co.za>
Message-ID: <1443887473.54.0.644804990861.issue25278@psf.upfronthosting.co.za>


R. David Murray added the comment:

I wonder if this has any relationship to issue 19500.

----------

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

From report at bugs.python.org  Sat Oct  3 18:23:08 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 03 Oct 2015 16:23:08 +0000
Subject: [issue23972] Asyncio reuseport
In-Reply-To: <1429185135.77.0.485030290106.issue23972@psf.upfronthosting.co.za>
Message-ID: <1443889388.18.0.359074098421.issue23972@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I'm adding a rebased version of Chris's v4 patch to see if I can get the code review to trigger.

----------
Added file: http://bugs.python.org/file40667/23972_cjl_v005.patch

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

From report at bugs.python.org  Sat Oct  3 20:44:55 2015
From: report at bugs.python.org (Yauheni Kaliuta)
Date: Sat, 03 Oct 2015 18:44:55 +0000
Subject: [issue14916] PyRun_InteractiveLoop fails to run interactively when
 using a Linux pty that's not tied to stdin/stdout
In-Reply-To: <1337960558.56.0.442179213708.issue14916@psf.upfronthosting.co.za>
Message-ID: <1443897895.63.0.591529432389.issue14916@psf.upfronthosting.co.za>


Yauheni Kaliuta added the comment:

Any progress with the problem? I just wanted to use the feature, but it looks like the bug.sh is still reproduces the bug.

----------
nosy: +Yauheni Kaliuta

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

From report at bugs.python.org  Sat Oct  3 20:54:55 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Oct 2015 18:54:55 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1443898495.51.0.860398430473.issue25300@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This presents the risk of breaking third-party extensions, right?

----------
nosy: +pitrou

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

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: [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:18:05 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 03 Oct 2015 19:18:05 +0000
Subject: [issue25305] Windows: python opens a popup and flood stderr with
 assertion error on FD error
In-Reply-To: <1443899838.3.0.138123456513.issue25305@psf.upfronthosting.co.za>
Message-ID: <1443899885.69.0.332466215012.issue25305@psf.upfronthosting.co.za>


STINNER Victor added the comment:

By the way, these warnings are flooding buildbot output, it became really hard to read these logs :-( Extract:


minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false
minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1182) : Assertion failed: false

----------

_______________________________________
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: [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 21:21:22 2015
From: report at bugs.python.org (Patrick Maupin)
Date: Sat, 03 Oct 2015 19:21:22 +0000
Subject: [issue25294] Absolute imports fail in some cases where relative
 imports would work
In-Reply-To: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>
Message-ID: <1443900082.33.0.0454540957331.issue25294@psf.upfronthosting.co.za>


Patrick Maupin added the comment:

The PEP 8 recommendation to "use absolute imports" is completely, totally, unambiguously meaningless absent the expectation that packages refer to parts of themselves.  And it works, too!  (For a single level of package.)

As soon as packages are nested, this recommendation falls over, with the most innocuous code:

    x/__init__.py: import x.y
    x/y/__init__.py: import x.y.z; x.y.z
    x/y/z/__init__.py: <empty>

The ability to nest packages is an attractive nuisance from a programmer's perspective.  He's neatly organized his code, and now he finds that there are two ways to make it work:  (1) Use the disparaged relative imports; or (2) flatten his package to a single level, because importing X.Z from within X.Y will work fine.

IMO, the language that Nick proposes for PEP 8 will either (a) not be understood at all by the frustrated junior programmer -- sure, the import system views it as a circular import, but he's not seeing it that way; or (b) be understood to expose a huge wart on the side of Python:  Even though Z is only used by Y/__init__, and doesn't itself use anything else in Y, it cannot live alongside Y/__init__. Instead, unless Y is a top level module or the programmer uses denigrated relative imports, he will now have to move it to a different place, so that from Y he can then "import X.Y_HELPER.Z".

Another PEP 8 prescription is that "Standard library code should avoid complex package layouts and always use absolute imports."  Here's a serious offer -- I'll give $200 to whoever gets the patch accepted that makes lib2to3 conformant without breaking it.

----------

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

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


STINNER Victor added the comment:

See also the issue #25306 "test_huntrleaks_fd_leak() of test_regrtest hangs on Windows". It may be caused by this issue.

----------

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

From report at bugs.python.org  Sat Oct  3 21:22:51 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Oct 2015 19:22:51 +0000
Subject: [issue25306] test_huntrleaks_fd_leak() of test_regrtest hangs on
 Windows
In-Reply-To: <1443899963.15.0.405890831726.issue25306@psf.upfronthosting.co.za>
Message-ID: <20151003192247.20757.21619@psf.io>


Roundup Robot added the comment:

New changeset fd915645627a by Victor Stinner in branch 'default':
Issue #25306: Skip test_huntrleaks_fd_leak() of test_regrtest until the bug is
https://hg.python.org/cpython/rev/fd915645627a

----------
nosy: +python-dev

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

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


STINNER Victor added the comment:

See also issue #23919, this issue may be a duplicate of this one.

----------

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

From report at bugs.python.org  Sat Oct  3 21:41:04 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Oct 2015 19:41:04 +0000
Subject: [issue25306] test_huntrleaks_fd_leak() of test_regrtest hangs on
 Windows
In-Reply-To: <1443899963.15.0.405890831726.issue25306@psf.upfronthosting.co.za>
Message-ID: <20151003194101.7238.33012@psf.io>


Roundup Robot added the comment:

New changeset 850efcc9155c by Victor Stinner in branch 'default':
Issue #25306: Try to fix test_huntrleaks_fd_leak() on Windows
https://hg.python.org/cpython/rev/850efcc9155c

----------

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

From report at bugs.python.org  Sat Oct  3 21:43:29 2015
From: report at bugs.python.org (Chenyun Yang)
Date: Sat, 03 Oct 2015 19:43:29 +0000
Subject: [issue25258] HtmlParser doesn't handle void element tags correctly
In-Reply-To: <1443883667.05.0.503790260445.issue25258@psf.upfronthosting.co.za>
Message-ID: <CAJZGQB4-veHLs1cKXnr-sL-0CwzZGaPY3YRUS8+NFUyjsfU6=Q@mail.gmail.com>


Chenyun Yang added the comment:

handle_startendtag is also called for non-void elements, such as <a/>, so
the override example will break in those situation.

The compatible patch I proposed right now is just one liner checker:

# http://www.w3.org/TR/html5/syntax.html#void-elements
<https://www.google.com/url?q=http://www.w3.org/TR/html5/syntax.html%23void-elements&usg=AFQjCNFVtfyZ53NDOHlPq896qmX5b8fPTA>_VOID_ELEMENT_TAGS
= frozenset([    'area', 'base', 'br', 'col', 'embed', 'hr', 'img',
'input', 'keygen',    'link', 'meta', 'param', 'source', 'track',
'wbr'])class HTMLParser.HTMLParser:  # Internal -- handle starttag,
return end or -1 if not terminated  def parse_starttag(self, i):
#...    if end.endswith('/>'):      # XHTML-style empty tag: <span
attr="value" />      self.handle_startendtag(tag, attrs)
#############    PATCH    #################    elif end.endswith('>')
and tag in _VOID_ELEMENT_TAGS:      self.handle_startendtag(tag,
attrs)    #############    PATCH    #################

----------

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

From report at bugs.python.org  Sat Oct  3 22:11:10 2015
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sat, 03 Oct 2015 20:11:10 +0000
Subject: [issue12939] Add new io.FileIO using the native Windows API
In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za>
Message-ID: <1443903070.82.0.72706529973.issue12939@psf.upfronthosting.co.za>


???? ????????? added the comment:

Please reopen. I still have interest for that. Fact that we survive 8 years is not enough for closing bugs as "Won't fix".

This fact point only on that ther are no good specialists that can fix that bug, since it is Windows-only, actually.

----------

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

From report at bugs.python.org  Sat Oct  3 22:12:25 2015
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sat, 03 Oct 2015 20:12:25 +0000
Subject: [issue12939] Add new io.FileIO using the native Windows API
In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za>
Message-ID: <1443903145.67.0.464807750053.issue12939@psf.upfronthosting.co.za>


???? ????????? added the comment:

Sorry, for the "there are no good specialist". I mean "There are no well motivated good specialist" :)

----------

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

From report at bugs.python.org  Sat Oct  3 22:12:34 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 03 Oct 2015 20:12:34 +0000
Subject: [issue25305] Windows: python opens a popup and flood stderr with
 assertion error on FD error
In-Reply-To: <1443899838.3.0.138123456513.issue25305@psf.upfronthosting.co.za>
Message-ID: <1443903154.6.0.449743126386.issue25305@psf.upfronthosting.co.za>


Steve Dower added the comment:

It is a direct duplicate of multiple issues.

The assertion is coming from the CRT, because their definition of "undefined behaviour" includes displaying an assert dialog in debug mode, and last time we tried disabling them completely we upset people. (I'm not 100% clear how you get from "closing an already-closed fd" to "undefined behaviour", but I assume it's an interpretation of invalid parameters.)

I'll get the patch for issue 23919 together, based on what Zach described in issue 25001.

----------
resolution:  -> duplicate
status: open -> closed

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

From report at bugs.python.org  Sat Oct  3 22:24:10 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 03 Oct 2015 20:24:10 +0000
Subject: [issue23919] [Windows] test_os fails several C-level assertions
In-Reply-To: <1428806067.72.0.786420001732.issue23919@psf.upfronthosting.co.za>
Message-ID: <1443903850.1.0.0149111825507.issue23919@psf.upfronthosting.co.za>


Steve Dower added the comment:

This patch:

* defaults to no assert dialogs and no stderr output
* enables stderr output for assertions on "-vv" (or more)
* displays a deprecation message on "-n"

----------
assignee:  -> steve.dower
keywords: +patch
versions: +Python 3.6
Added file: http://bugs.python.org/file40668/23919_1.patch

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

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: [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:13:17 2015
From: report at bugs.python.org (paul j3)
Date: Sat, 03 Oct 2015 21:13:17 +0000
Subject: [issue25299] TypeError: __init__() takes at least 4 arguments (4
 given)
In-Reply-To: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za>
Message-ID: <1443906797.23.0.140315886069.issue25299@psf.upfronthosting.co.za>


paul j3 added the comment:

The unittest file test_argparse.py tests add_argument parameters in 

    class TestInvalidArgumentConstructors(TestCase)

It looks at a dozen different categories of errors, mostly checking that they return the correct TypeError or ValueError.  It does not check the content of error messages.  

If I change the code I described yesterday to return a TypeError again (but with an enhanced message), it passes this unittest.

Most of the test_argparse.py tests just check for error type.  There just a couple of late additions that check error message content:

    TestMessageContentError
    TestAddArgumentMetavar

----------

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

From report at bugs.python.org  Sat Oct  3 23:29:10 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 03 Oct 2015 21:29:10 +0000
Subject: [issue12939] Add new io.FileIO using the native Windows API
In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za>
Message-ID: <1443907750.41.0.154128198701.issue12939@psf.upfronthosting.co.za>


R. David Murray added the comment:

Since Guido voted in favor and there's a patch proposal, I think we should keep this open in the hopes that someone will come along who can move it forward.  I don't know enough to know what moving it forward would look like, though.

(I know you opened the issue originally, Victor, and you aren't interested in it any more, but obviously others are.)

----------
nosy: +r.david.murray
versions: +Python 3.6 -Python 3.5

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

From report at bugs.python.org  Sat Oct  3 23:30:55 2015
From: report at bugs.python.org (paul j3)
Date: Sat, 03 Oct 2015 21:30:55 +0000
Subject: [issue25297] max_help_position is not works in argparse library
In-Reply-To: <1443776113.96.0.923054986589.issue25297@psf.upfronthosting.co.za>
Message-ID: <1443907855.79.0.799153368445.issue25297@psf.upfronthosting.co.za>


paul j3 added the comment:

The unittest test_argparse.py has one related test

class TestAddSubparsers
   def test_alias_help

has a long enough subparser invocation (with aliases) to produce wrapping with the default 24 max position:


            commands:
              COMMAND
                1 (1alias1, 1alias2)
                                    1 help
                2                   2 help

I don't see anything in the test file that tries to vary the max_help_position parameter.

----------

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

From report at bugs.python.org  Sat Oct  3 23:42:49 2015
From: report at bugs.python.org (paul j3)
Date: Sat, 03 Oct 2015 21:42:49 +0000
Subject: [issue25307] Enhancing the argparse help output
In-Reply-To: <1443905883.43.0.512702237453.issue25307@psf.upfronthosting.co.za>
Message-ID: <1443908569.23.0.61645388857.issue25307@psf.upfronthosting.co.za>


paul j3 added the comment:

I don't recall other issues or discussions about lining up short and long option strings.

Producing a more compact invocation has raised in StackOverflow questions.  I don't recall if there has been bug/issue on the same.

If I recall correctly it isn't hard to identify and change the Formatter method that produces the action invocation.  So such a change could be implemented as a Formatter subclass.  A SO search should produce that.

You can also play with the metavar of an argument to produce a more command invocation.

The formatting of choices has been discussed in other bug/issues. 

The ultimate help formatting method is to SUPPRESS the argument help, and write your own in a (RAW) description.

----------
nosy: +paul.j3

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

From report at bugs.python.org  Sat Oct  3 23:50:24 2015
From: report at bugs.python.org (paul j3)
Date: Sat, 03 Oct 2015 21:50:24 +0000
Subject: [issue25307] Enhancing the argparse help output
In-Reply-To: <1443905883.43.0.512702237453.issue25307@psf.upfronthosting.co.za>
Message-ID: <1443909024.45.0.960129026844.issue25307@psf.upfronthosting.co.za>


paul j3 added the comment:

http://stackoverflow.com/questions/18275023/dont-show-long-options-twice-in-print-help-from-argparse

http://stackoverflow.com/questions/9366369/python-argparse-lots-of-choices-results-in-ugly-help-output

http://stackoverflow.com/questions/23936145/python-argparse-help-message-disable-metavar-for-short-options

http://stackoverflow.com/questions/13479513/how-can-i-get-python-argparse-to-list-choices-only-once

----------

_______________________________________
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: [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 00:07:47 2015
From: report at bugs.python.org (Sworddragon)
Date: Sat, 03 Oct 2015 22:07:47 +0000
Subject: [issue25307] Enhancing the argparse help output
In-Reply-To: <1443905883.43.0.512702237453.issue25307@psf.upfronthosting.co.za>
Message-ID: <1443910067.16.0.431894185233.issue25307@psf.upfronthosting.co.za>


Sworddragon added the comment:

> The formatting of choices has been discussed in other bug/issues.

What was the reason showing the choices only once at default was not chosen?

----------

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

From report at bugs.python.org  Sun Oct  4 00:49:41 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 03 Oct 2015 22:49:41 +0000
Subject: [issue12939] Add new io.FileIO using the native Windows API
In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za>
Message-ID: <1443912581.15.0.539919952857.issue12939@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

If ???? ????????? (mmarkk) is interested, they should move it forward.  If they're not interested, move it too "languishing", where it can sit happily for ever and a day.  Pay your money, take your choice?

----------

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

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: [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 02:17:15 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 04 Oct 2015 00:17:15 +0000
Subject: [issue25309] askopenfilename crashes on XP with "Show pop-up
 description for folder and desktop items" on
In-Reply-To: <1443914921.38.0.807954520295.issue25309@psf.upfronthosting.co.za>
Message-ID: <1443917835.13.0.128157569187.issue25309@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +martin.panter

_______________________________________
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: [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 03:29:54 2015
From: report at bugs.python.org (paul j3)
Date: Sun, 04 Oct 2015 01:29:54 +0000
Subject: [issue25307] Enhancing the argparse help output
In-Reply-To: <1443905883.43.0.512702237453.issue25307@psf.upfronthosting.co.za>
Message-ID: <1443922194.65.0.796168381909.issue25307@psf.upfronthosting.co.za>


paul j3 added the comment:

Formatter _format_action_invocation(self, action) is the key function.  Notice how it treats positionals and optionals separately.  Also it calls

    default = self._get_default_metavar_for_optional(action)
    args_string = self._format_args(action, default)

to get the string that is placed after each option_string.

'choices' are incorporated via the _metavar_formatter() method (through several function calls).  They do not get their own separate consideration.  Tracing this calling stack is not a trivial task.

But if you want custom behavior at this point in the help, _format_action_invocation() is the function to play with.  You could even add the space for a nonexistent short option at this point.


http://bugs.python.org/issue16468 is an example of a 'choices' thread.  Note that a formatted list of choices is also shown in the 'usage' and error messages.  It's about formatting the choices string, not about where to show it.

----------

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

From report at bugs.python.org  Sun Oct  4 04:13:41 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 04 Oct 2015 02:13:41 +0000
Subject: [issue25160] Stop using deprecated imp module;
 imp should now emit a real DeprecationWarning
In-Reply-To: <1442559979.71.0.954965412351.issue25160@psf.upfronthosting.co.za>
Message-ID: <1443924821.87.0.860256973344.issue25160@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Sun Oct  4 04:14:25 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 04 Oct 2015 02:14:25 +0000
Subject: [issue20020] "modernize" the modulefinder module
In-Reply-To: <1387425925.56.0.593354940747.issue20020@psf.upfronthosting.co.za>
Message-ID: <1443924865.68.0.118919955521.issue20020@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Sun Oct  4 04:14:40 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 04 Oct 2015 02:14:40 +0000
Subject: [issue20021] "modernize" makeopcodetargets.py
In-Reply-To: <1387426285.76.0.769422966502.issue20021@psf.upfronthosting.co.za>
Message-ID: <1443924880.54.0.493297264247.issue20021@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Sun Oct  4 05:03:41 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 04 Oct 2015 03:03:41 +0000
Subject: [issue9232] Allow trailing comma in any function argument list.
In-Reply-To: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za>
Message-ID: <20151004030338.485.80218@psf.io>


Roundup Robot added the comment:

New changeset 6db349fac3ec by Terry Jan Reedy in branch 'default':
Issue #9232: Escape rst markup char in NEWS entry to avoid Sphinx warning.
https://hg.python.org/cpython/rev/6db349fac3ec

----------

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

From report at bugs.python.org  Sun Oct  4 05:03:41 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 04 Oct 2015 03:03:41 +0000
Subject: [issue24791] *args regression
In-Reply-To: <1438746144.94.0.696860700578.issue24791@psf.upfronthosting.co.za>
Message-ID: <20151004030338.485.57405@psf.io>


Roundup Robot added the comment:

New changeset 20e0906a808e by Terry Jan Reedy in branch '3.5':
Issue #24791: Escape rst markup char in NEWS entry to avoid Sphinx warning.
https://hg.python.org/cpython/rev/20e0906a808e

----------

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

From report at bugs.python.org  Sun Oct  4 05:43:37 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Oct 2015 03:43:37 +0000
Subject: [issue25294] Absolute imports fail in some cases where relative
 imports would work
In-Reply-To: <1443900082.33.0.0454540957331.issue25294@psf.upfronthosting.co.za>
Message-ID: <CADiSq7eWwvGds0R8UmZun1stQ8N3zNmJpNn7wX-698bn3q5J5A@mail.gmail.com>


Nick Coghlan added the comment:

If that's the concern, then the relevant guidance is to avoid running code
at package import time (which many new developers will now do by default
with __init__.py becoming optional).

----------

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

From report at bugs.python.org  Sun Oct  4 06:25:12 2015
From: report at bugs.python.org (Patrick Maupin)
Date: Sun, 04 Oct 2015 04:25:12 +0000
Subject: [issue25294] Absolute imports fail in some cases where relative
 imports would work
In-Reply-To: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>
Message-ID: <1443932712.32.0.293585846769.issue25294@psf.upfronthosting.co.za>


Patrick Maupin added the comment:

I'm a big fan of stitching things together at the top myself -- maybe that's partly an unconscious reaction to this very issue.

But I'm not sanguine about how easy it is to express this practice in the docs.

This issue arose in the context of me answering a question on Stack Overflow.  My initial response was "well, duh, obviously relative imports are more Pythonic here because that's the obvious way to do it (that works)."

But then, of course, PEP 8 disagrees.

For that actual question on Stack Overflow, you would have to carefully define the scope of "executing" so that it was fully understood to include "subclassing a class defined in a peer module or submodule" -- because that's what was breaking.

Just as most people don't think of imports that can be placed in a DAG as circular, most people also don't think of subclassing as "executing."

But the Python interpreter sometimes vehemently disagrees in both cases.  I'm not surprised at its behavior, but I'm also not surprised that some people who haven't thought deeply about the behavior find it surprising.

I'm not fully convinced that this even can be documented in a way that renders observed behavior unsurprising in the general case, but I am convinced that doing so would require a lot of care.

----------

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

From report at bugs.python.org  Sun Oct  4 06:32:07 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 04 Oct 2015 04:32:07 +0000
Subject: [issue24820] IDLE themes for light on dark
In-Reply-To: <1438923257.49.0.103520260228.issue24820@psf.upfronthosting.co.za>
Message-ID: <20151004043202.128840.98698@psf.io>


Roundup Robot added the comment:

New changeset afa95f032de1 by Terry Jan Reedy in branch '2.7':
Issue #24820: Add 'IDLE Dark' text color theme, warning, and solution.
https://hg.python.org/cpython/rev/afa95f032de1

New changeset 1de01a63f360 by Terry Jan Reedy in branch '3.4':
Issue #24820: Add 'IDLE Dark' text color theme, warning, and solution.
https://hg.python.org/cpython/rev/1de01a63f360

----------

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

From report at bugs.python.org  Sun Oct  4 06:46:00 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 04 Oct 2015 04:46:00 +0000
Subject: [issue24820] IDLE themes for light on dark
In-Reply-To: <1438923257.49.0.103520260228.issue24820@psf.upfronthosting.co.za>
Message-ID: <1443933960.32.0.333347987805.issue24820@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

See patch for message.  Merely displaying a message, and not trying to do anything fancy, like cancelling the selection, avoids any possible problem in interaction with other methods.  I leave it to users to decide if action is needed, and if so, whether to switch or save as custom.

Mark's original post had two issues.  The first, a dark background theme, is now committed and this issue closed.  Thanks for the push for something requested by others.  I am using it myself.  

The second, the ability to simultaneously change all default backgrounds, such as white to off-white, is or will be either a new issue or part of the highlight tab rewrite, #24781.

----------
assignee:  -> terry.reedy
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Oct  4 06:58:03 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Oct 2015 04:58:03 +0000
Subject: [issue20021] "modernize" makeopcodetargets.py
In-Reply-To: <1387426285.76.0.769422966502.issue20021@psf.upfronthosting.co.za>
Message-ID: <1443934683.06.0.608978697765.issue20021@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Some of the buildbots have Python 2.5 as their system Python.

Here is a patch that is compatible with older Python versions.

----------
nosy: +serhiy.storchaka
versions: +Python 3.6 -Python 3.5
Added file: http://bugs.python.org/file40670/issue20021_2.diff

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

From report at bugs.python.org  Sun Oct  4 07:03:35 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Oct 2015 05:03:35 +0000
Subject: [issue25309] askopenfilename crashes on XP with "Show pop-up
 description for folder and desktop items" on
In-Reply-To: <1443914921.38.0.807954520295.issue25309@psf.upfronthosting.co.za>
Message-ID: <1443935015.08.0.129658841663.issue25309@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +terry.reedy

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

From report at bugs.python.org  Sun Oct  4 07:07:33 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 04 Oct 2015 05:07:33 +0000
Subject: [issue25310] End mark argument for StreamReader.readline() method
In-Reply-To: <1443921747.34.0.642955426854.issue25310@psf.upfronthosting.co.za>
Message-ID: <1443935253.05.0.737057018617.issue25310@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

You should not be using readline() for that use case. (Note that *no* sequence of characters can be guaranteed not to occur in a binary protocol like pickle.)

----------
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Sun Oct  4 07:20:03 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 04 Oct 2015 05:20:03 +0000
Subject: [issue24820] IDLE themes for light on dark
In-Reply-To: <1438923257.49.0.103520260228.issue24820@psf.upfronthosting.co.za>
Message-ID: <20151004052000.20765.83335@psf.io>


Roundup Robot added the comment:

New changeset 739cc9ca55cd by Terry Jan Reedy in branch '2.7':
Issue #24820: Update IDLE NEWS items.
https://hg.python.org/cpython/rev/739cc9ca55cd

New changeset 233974dfda03 by Terry Jan Reedy in branch '3.4':
Issue #24820: Update IDLE NEWS items.
https://hg.python.org/cpython/rev/233974dfda03

New changeset 89a1e03b4639 by Terry Jan Reedy in branch '3.5':
Issue #24820: Update IDLE NEWS items.
https://hg.python.org/cpython/rev/89a1e03b4639

----------

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

From report at bugs.python.org  Sun Oct  4 08:27:46 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 04 Oct 2015 06:27:46 +0000
Subject: [issue25309] askopenfilename crashes on XP with "Show pop-up
 description for folder and desktop items" on
In-Reply-To: <1443914921.38.0.807954520295.issue25309@psf.upfronthosting.co.za>
Message-ID: <1443940066.28.0.815698349874.issue25309@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Your report is good except for defining what you mean by crash and how you ran pickfile.py.  (I assume 3.4 with tk 8.6 from your version selection.).

(There is also the comment-per-line style.  I know that some nasty books and profs inflict this style on new programmers, but you will be better off to avoid it.  Discuss on python-list if you want.)

Win 7: Organize -> Folder and search options -> View tab - Show ... selection.  I already had this selected, and have never had problem that I know of, using askopenfile daily from Idle.

On Win 7, 3.4, tk 8.6, from command line or IDLE, I cannot reproduce the problem.  The popup pop up within a second and there is no hourglass.

The last maintenance release of 3.4 will be this month, so unless a problem is visible with post XP and 3.5, this should be closed when 3.4.4 is out.

----------
stage:  -> test needed
type: crash -> behavior

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

From report at bugs.python.org  Sun Oct  4 09:49:51 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 04 Oct 2015 07:49:51 +0000
Subject: [issue12939] Add new io.FileIO using the native Windows API
In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za>
Message-ID: <1443944991.52.0.895179178946.issue12939@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I reopen the issue. The patch is outdated. Richard Oudkerk doens't seem to be active last weeks :-/

----------
resolution: out of date -> 
status: closed -> open

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

From report at bugs.python.org  Sun Oct  4 10:10:15 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 04 Oct 2015 08:10:15 +0000
Subject: [issue23919] [Windows] test_os fails several C-level assertions
In-Reply-To: <1428806067.72.0.786420001732.issue23919@psf.upfronthosting.co.za>
Message-ID: <1443946215.49.0.0501470428457.issue23919@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I would prefer to disable the popups and messages to stderr by default in Python directly. If some users want to see them, we can add a -X option to enable them. Example: -X enable_mscrt_checks. What do you think? Do you recall who complain that Python hides MSCRT warnings? And why he/she complained?

I don't want these warnings, especially popups blocking my program, on my own applications. Python already raises OSError on errors.

The problem in tests is also that some tests use subprocesses and regrtest only configures the test runner, not subprocesses. For example, I had to modify a subprocess started by the test. Otherwise, the test *hangs* :-(

Popups are annoying because it's not possible to ignore them all by a single click. I have to click N times for N errors, with N>100 it's just a nightmare...

For me, it's a regression compared to older Python versions. I don't remember to have to click on so much popups or have stderr flooded by warnings when working on Windows, when I worked on Python 3.4 or older.

----------

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

From report at bugs.python.org  Sun Oct  4 10:11:13 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 04 Oct 2015 08:11:13 +0000
Subject: [issue23919] [Windows] test_os fails several C-level assertions
In-Reply-To: <1428806067.72.0.786420001732.issue23919@psf.upfronthosting.co.za>
Message-ID: <1443946273.79.0.00316898078024.issue23919@psf.upfronthosting.co.za>


STINNER Victor added the comment:

23919_1.patch looks good to me.

----------

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

From report at bugs.python.org  Sun Oct  4 10:21:20 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 04 Oct 2015 08:21:20 +0000
Subject: [issue25301] Optimize UTF-8 decoder with error handlers
In-Reply-To: <1443797082.73.0.711354360874.issue25301@psf.upfronthosting.co.za>
Message-ID: <1443946880.37.0.601065173904.issue25301@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Added file: http://bugs.python.org/file40671/bench.py

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

From report at bugs.python.org  Sun Oct  4 10:30:32 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 04 Oct 2015 08:30:32 +0000
Subject: [issue25301] Optimize UTF-8 decoder with error handlers
In-Reply-To: <1443797082.73.0.711354360874.issue25301@psf.upfronthosting.co.za>
Message-ID: <1443947432.21.0.263826556264.issue25301@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Results of the microbenchmark on the UTF-8 decoder.

As expected, performances on valid UTF-8 is unchanged, which was an important goal for me.

Decoding with error handlers optimized by the patch are *much* faster.

backslashreplace is still slow, because I didn't optimize it.

Common platform:
Python unicode implementation: PEP 393
Timer: time.perf_counter
Platform: Linux-4.1.5-200.fc22.x86_64-x86_64-with-fedora-22-Twenty_Two
CPU model: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz
Timer info: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09)
Bits: int=32, long=64, long long=64, size_t=64, void*=64
CFLAGS: -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
Timer precision: 55 ns

Platform of campaign before:
SCM: hg revision=f51921883f50 tag=tip branch=default date="2015-10-04 01:19 -0400"
Python version: 3.6.0a0 (default:f51921883f50, Oct 4 2015, 10:19:37) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)]
Date: 2015-10-04 10:19:44

Platform of campaign after:
SCM: hg revision=f51921883f50+ tag=tip branch=default date="2015-10-04 01:19 -0400"
Python version: 3.6.0a0 (default:f51921883f50+, Oct 4 2015, 10:14:05) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)]
Date: 2015-10-04 10:18:55

---------------------+-------------+--------
valid UTF-8 (strict) |      before |   after
---------------------+-------------+--------
100 x 10**1 bytes    |  297 ns (*) |  297 ns
100 x 10**3 bytes    |  7.4 us (*) | 7.44 us
100 x 10**2 bytes    |  929 ns (*) |  924 ns
100 x 10**4 bytes    | 80.4 us (*) | 80.4 us
---------------------+-------------+--------
Total                | 89.1 us (*) |   89 us
---------------------+-------------+--------

------------------+-------------+---------------
ignore            |      before |          after
------------------+-------------+---------------
100 x 10**1 bytes | 6.68 us (*) |  743 ns (-89%)
100 x 10**3 bytes |  561 us (*) | 42.6 us (-92%)
100 x 10**2 bytes | 56.8 us (*) | 4.55 us (-92%)
100 x 10**4 bytes | 6.02 ms (*) |  425 us (-93%)
------------------+-------------+---------------
Total             | 6.65 ms (*) |  473 us (-93%)
------------------+-------------+---------------

------------------+-------------+---------------
replace           |      before |          after
------------------+-------------+---------------
100 x 10**1 bytes | 7.61 us (*) |  890 ns (-88%)
100 x 10**3 bytes |  639 us (*) | 50.3 us (-92%)
100 x 10**2 bytes | 64.8 us (*) | 5.37 us (-92%)
100 x 10**4 bytes | 7.09 ms (*) |  505 us (-93%)
------------------+-------------+---------------
Total             | 7.81 ms (*) |  561 us (-93%)
------------------+-------------+---------------

------------------+-------------+---------------
surrogateescape   |      before |          after
------------------+-------------+---------------
100 x 10**1 bytes | 7.96 us (*) |  855 ns (-89%)
100 x 10**3 bytes |  674 us (*) | 50.2 us (-93%)
100 x 10**2 bytes | 68.8 us (*) | 5.35 us (-92%)
100 x 10**4 bytes | 7.38 ms (*) |  504 us (-93%)
------------------+-------------+---------------
Total             | 8.13 ms (*) |  560 us (-93%)
------------------+-------------+---------------

------------------+-------------+--------
backslashreplace  |      before |   after
------------------+-------------+--------
100 x 10**1 bytes | 7.66 us (*) | 7.89 us
100 x 10**3 bytes |  633 us (*) |  633 us
100 x 10**2 bytes | 64.1 us (*) | 64.6 us
100 x 10**4 bytes |  6.9 ms (*) | 6.93 ms
------------------+-------------+--------
Total             | 7.61 ms (*) | 7.64 ms
------------------+-------------+--------

---------------------+-------------+---------------
Summary              |      before |          after
---------------------+-------------+---------------
valid UTF-8 (strict) | 89.1 us (*) |          89 us
ignore               | 6.65 ms (*) |  473 us (-93%)
replace              | 7.81 ms (*) |  561 us (-93%)
surrogateescape      | 8.13 ms (*) |  560 us (-93%)
backslashreplace     | 7.61 ms (*) |        7.64 ms
---------------------+-------------+---------------
Total                | 30.3 ms (*) | 9.32 ms (-69%)
---------------------+-------------+---------------

----------

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

From report at bugs.python.org  Sun Oct  4 12:21:51 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Oct 2015 10:21:51 +0000
Subject: [issue24848] Warts in UTF-7 error handling
In-Reply-To: <1439364965.73.0.526700604341.issue24848@psf.upfronthosting.co.za>
Message-ID: <1443954111.56.0.616150242463.issue24848@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Test failure is random. With build 3435 tests are successful, with all other are failed. The same with other buildbot: http://buildbot.python.org/all/builders/x86%20Windows7%202.7/ . 3345 and 3347 are green, others are red.

----------

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

From report at bugs.python.org  Sun Oct  4 14:52:04 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 04 Oct 2015 12:52:04 +0000
Subject: [issue23919] [Windows] test_os fails several C-level assertions
In-Reply-To: <1428806067.72.0.786420001732.issue23919@psf.upfronthosting.co.za>
Message-ID: <1443963124.71.0.0837514961026.issue23919@psf.upfronthosting.co.za>


Steve Dower added the comment:

I referred to the issues that had -n added in the first place many times while adding the IPH handlers, but I don't have them handy now on my phone.

The rationale was that people who cause assertions in their C extensions should see them and not have Python suppress them. All cases where an assert is raised in a debug build is a coding error - the test suite deliberately causes some but this is not normal development and should not dictate normal configuration.

----------

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

From report at bugs.python.org  Sun Oct  4 15:31:09 2015
From: report at bugs.python.org (Vincent Michel)
Date: Sun, 04 Oct 2015 13:31:09 +0000
Subject: [issue25304] Add run_coroutine_threadsafe() to asyncio
In-Reply-To: <1443885833.8.0.0767295795531.issue25304@psf.upfronthosting.co.za>
Message-ID: <1443965469.97.0.481952038235.issue25304@psf.upfronthosting.co.za>


Vincent Michel added the comment:

While I was working on the documentation update, I realized that what we called `run_coroutine_threadsafe` is actually a thread-safe version of `ensure_future`. What about renaming it to `ensure_future_threadsafe`? It might be a bit late since `run_coroutine_threadsafe` has been committed, but I think it is worth to be considered. I can see two benefits:

- it is less confusing, because it has the same name and using the same prototype as `ensure_future`
- it accepts futures and awaitables

The docstring would be "Wrap a coroutine, an awaitable or a future in a concurrent.futures.Future.". The documentation would explain that it works like `ensure_future` except:
1. its execution is threadsafe
2. it provides a thread-safe future instead of a regular future

I attached an implementation of it. Also, note that I added a `try-except` in the callback, which is not mandatory but probably a good thing have.

In any case, I'll keep working on the documentation update.

----------
Added file: http://bugs.python.org/file40672/ensure_future_threadsafe.py

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

From report at bugs.python.org  Sun Oct  4 17:21:44 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Oct 2015 15:21:44 +0000
Subject: [issue25308] Multiple names can target the same namespace
In-Reply-To: <1443909316.53.0.827518024147.issue25308@psf.upfronthosting.co.za>
Message-ID: <1443972104.86.0.484865251037.issue25308@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'd be willing to bet there are people using this as a feature.  I don't think we should make any change here.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Sun Oct  4 17:29:04 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 04 Oct 2015 15:29:04 +0000
Subject: [issue25304] Add run_coroutine_threadsafe() to asyncio
In-Reply-To: <1443885833.8.0.0767295795531.issue25304@psf.upfronthosting.co.za>
Message-ID: <1443972544.78.0.612831378819.issue25304@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> - it is less confusing, because it has the same name and using the same prototype as `ensure_future`
> - it accepts futures and awaitables

I like this idea.

----------

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

From report at bugs.python.org  Sun Oct  4 17:59:30 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 04 Oct 2015 15:59:30 +0000
Subject: [issue25304] Add run_coroutine_threadsafe() to asyncio
In-Reply-To: <1443885833.8.0.0767295795531.issue25304@psf.upfronthosting.co.za>
Message-ID: <1443974370.94.0.211082401568.issue25304@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I'm against that idea. I don't really see a great important future for this method either way: It's just a little bit of glue between the threaded and asyncio worlds, and people will learn how to use it by finding an example.

The existing ensure_future() function is mostly meant as an internal helper, with the understanding that libraries written on top of asyncio might also need this functionality. Basically I want people writing asyncio code not to have to worry about the difference between futures and coroutines, because they can both be awaited for; ensure_future() helps preserve that illusion for code that really needs a future (usually to add a callback).

But honestly I *don't* want to encourage flipping back and forth between threads and event loops; I see it as a necessary evil. The name we currently have is fine from the POV of someone coding in the threaded world who wants to hand off something to the asyncio world.

Why would someone in the threaded world have an asyncio.future that they need to wait for? That sounds like they're mixing up the two worlds -- or they should be writing asyncio code instead of threaded code.

OTOH, I would love to see the documentation update!

----------

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

From report at bugs.python.org  Sun Oct  4 18:04:12 2015
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 04 Oct 2015 16:04:12 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1443974652.79.0.622399389952.issue25300@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Wouldn't setting CFLAGS be sufficient?

./configure CFLAGS="-fcheck-pointer-bounds -mmpx"


Otherwise we could also add --with-stack-protector and --with-fortify-source and others. I'm not sure if we should add a special --with*
option for every gcc flag.

----------

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

From report at bugs.python.org  Sun Oct  4 18:19:18 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Oct 2015 16:19:18 +0000
Subject: [issue25304] Add run_coroutine_threadsafe() to asyncio
In-Reply-To: <1443885833.8.0.0767295795531.issue25304@psf.upfronthosting.co.za>
Message-ID: <1443975558.35.0.181726493569.issue25304@psf.upfronthosting.co.za>


R. David Murray added the comment:

I thought you might be interested to know what the name suggests to a relative newcomer to asyncio.

When I saw this issue opened, I though "oh, good, an easy way to submit a coroutine from a thread in my test code, now I don't have to write 'loop.call_soon_threadsafe(loop.create_task, my_coroutine(loop=loop))".  Which I suspect you are going to tell me is stupid code, but the point is that that's what the name 'call_coroutine_threadsafe' made me think it was going to do.  After reading the linked issue I was very confused about what it was actually going to do, as I've never gotten around to looking up what ensure_future does.

If I'm understanding correctly now, I think my assumption was pretty much correct, and the only difference is that I get back something I can actually manipulate if I need to, making it even better, and which the documentation should make clear when I get to read it :)

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Sun Oct  4 18:46:39 2015
From: report at bugs.python.org (alex wieder)
Date: Sun, 04 Oct 2015 16:46:39 +0000
Subject: [issue25309] askopenfilename crashes on XP with "Show pop-up
 description for folder and desktop items" on
In-Reply-To: <1443914921.38.0.807954520295.issue25309@psf.upfronthosting.co.za>
Message-ID: <1443977199.87.0.049895386065.issue25309@psf.upfronthosting.co.za>


alex wieder added the comment:

Terry, thanks for your feedback.

By crash, I mean python crashing with a Windows c0000005 error. I can't even capture that exception in a try...except structure.

This is on an Intel Core2Duo 2.7GHz with 4 GB of RAM, with Acrobat Reader X installed, which might account for Windows Explorer's delay in gathering the pdfs' information and presenting it in the pop-up. It also happens on a virtual XP machine I use at my office (VirtualBox running on an i7-based linux box).

I ran pickfile.py every way I could think of: with python's console interpreter, with the windows-based interpreter (no black console window showing up). In both cases I tried compiled and interpreted versions of it (.py & .pyc), and also from within Eclipse (regular run and debugger).

As long as a user double-clicks on a file while Windows is still gathering information to display in the pop-up, it crashes.

I will have access to win7 i5-based computers next week, so I can test  then, but these will be much faster computers, so this issue might be moot.

Python 3.4.3. I don't know how to check tkinter version, but it's the one that comes with the 3.4.3 python installer.

Comment-per-line... I know, but I need to be able to read my own code six months from now (I still maintain code written by me 25 years ago and if it weren't for those, I'd be screwed sometimes). I realize that this particular program is quite obvious, but pickfile.py is just a slice of a much longer file. I'll remove obvious comments if I have to post again.

----------

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

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: [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 19:34:49 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 04 Oct 2015 17:34:49 +0000
Subject: [issue25311] Add f-string support to tokenize.py
In-Reply-To: <1443979407.62.0.707305717475.issue25311@psf.upfronthosting.co.za>
Message-ID: <1443980089.53.0.845909259806.issue25311@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Thanks for noticing tokenize.py. And thanks for the kind note!

----------
assignee:  -> eric.smith

_______________________________________
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: [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:13:44 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 04 Oct 2015 18:13:44 +0000
Subject: [issue25304] Add run_coroutine_threadsafe() to asyncio
In-Reply-To: <1443974370.94.0.211082401568.issue25304@psf.upfronthosting.co.za>
Message-ID: <809A780E-CBFE-4FFD-A21F-D7FCFF9066DA@gmail.com>


Yury Selivanov added the comment:

> But honestly I *don't* want to encourage flipping back and forth between threads and event loops; I see it as a necessary evil. The name we currently have is fine from the POV of someone coding in the threaded world who wants to hand off something to the asyncio world.

I agree, but on the other hand supporting awaitables in addition to coroutines would be great. Can we at least add that?

----------
nosy: +Yury.Selivanov

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

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: [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 20:25:36 2015
From: report at bugs.python.org (Mark Roseman)
Date: Sun, 04 Oct 2015 18:25:36 +0000
Subject: [issue24820] IDLE themes for light on dark
In-Reply-To: <1438923257.49.0.103520260228.issue24820@psf.upfronthosting.co.za>
Message-ID: <1443983136.04.0.257334502507.issue24820@psf.upfronthosting.co.za>


Mark Roseman added the comment:

FYI, the change multiple backgrounds thing is in my working version for the new dialog. Added new issue #25313 to remind us that the warning message is something we'd love to get rid of in the future and as quickly as possible make it unnecessary if we add more new themes and/or new features in themes.

----------

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

From report at bugs.python.org  Sun Oct  4 20:31:53 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Oct 2015 18:31:53 +0000
Subject: [issue25309] askopenfilename crashes on XP with "Show pop-up
 description for folder and desktop items" on
In-Reply-To: <1443914921.38.0.807954520295.issue25309@psf.upfronthosting.co.za>
Message-ID: <1443983513.88.0.668644386932.issue25309@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Please test Tcl version of your example.

    wish pickfile.tcl

----------
nosy: +serhiy.storchaka
Added file: http://bugs.python.org/file40673/pickfile.tcl

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

From report at bugs.python.org  Sun Oct  4 20:41:40 2015
From: report at bugs.python.org (alex wieder)
Date: Sun, 04 Oct 2015 18:41:40 +0000
Subject: [issue25309] askopenfilename crashes on XP with "Show pop-up
 description for folder and desktop items" on
In-Reply-To: <1443914921.38.0.807954520295.issue25309@psf.upfronthosting.co.za>
Message-ID: <1443984100.24.0.255025125046.issue25309@psf.upfronthosting.co.za>


alex wieder added the comment:

wish pickfile.tcl? Sorry. Too cryptic for me.

I ran the following code from the python interpreter:

import tkinter as tk

tk.TclVersion 
tk.TkVersion

Both return 8.6.

----------

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

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


Mark Roseman added the comment:

Actually, I think we may be able to get away without the warning message when you select a 'new' theme, and still maintain backwards compatibility.

For 'new' themes (i.e. IDLE Dark and any more builtins we add in the future), we write the theme out to the user configuration file, keeping the same name, and perhaps adding an extra field, i.e. 'builtin=1', so that we can recognize it in newer versions, along with a comment if possible.

The existing code looks up theme names by checking if its in the default list, and if not, looks in the user list. For older versions without IDLE Dark, it will then find it in the user list.

Besides writing out the theme to user config file, the only other change that would be needed in the code is to modify GetSectionList so that when it's looking in a user config file, it doesn't include sections that either have the builtin=1 from above, or just have the same name as things in the default file.

----------

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

From report at bugs.python.org  Sun Oct  4 21:46:06 2015
From: report at bugs.python.org (Mark Roseman)
Date: Sun, 04 Oct 2015 19:46:06 +0000
Subject: [issue25313] IDLE: gracefully handle themes (or keysets,
 or ...) not present
In-Reply-To: <1443983028.38.0.330062493222.issue25313@psf.upfronthosting.co.za>
Message-ID: <1443987966.81.0.420076629347.issue25313@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Patch write-new-defaults.patch attached so that we write 'newer' default themes to config-highlight.cfg if selected, and ignore them if we already have a default by that name.

----------
keywords: +patch
Added file: http://bugs.python.org/file40674/write-new-defaults.patch

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

From report at bugs.python.org  Sun Oct  4 21:58:24 2015
From: report at bugs.python.org (shanmbic)
Date: Sun, 04 Oct 2015 19:58:24 +0000
Subject: [issue24954] No way to generate or parse timezone as produced by
 datetime.isoformat()
In-Reply-To: <1440801281.72.0.545558404714.issue24954@psf.upfronthosting.co.za>
Message-ID: <1443988704.88.0.673835644146.issue24954@psf.upfronthosting.co.za>


shanmbic added the comment:

I modified the "format_utcoffset" function in "_datetimemodule.c", to accept one more parameter "secondsrequired" . It is a boolean variable (PyObject) , which when set to true, the function will return the offset formatted as "+HH:MM:SS" or "-HH:MM:SS". I also modified the "wrap_strftime" function to also accept the strings "%:z" and "%::z" as format specifiers. This is my first contribution to python , so my approach of modifying a function's default parameters might not be correct. Any help is appreciated 
Thanks

----------
components: +ctypes
hgrepos: +319
keywords: +patch
nosy: +shanmbic
Added file: http://bugs.python.org/file40675/datetime.patch

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

From report at bugs.python.org  Sun Oct  4 22:15:16 2015
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 04 Oct 2015 20:15:16 +0000
Subject: [issue25008] Deprecate smtpd (based on deprecated asyncore/asynchat):
 write a new smtp server with asyncio
In-Reply-To: <1441472893.95.0.412611892234.issue25008@psf.upfronthosting.co.za>
Message-ID: <1443989716.97.0.876335777652.issue25008@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

I'm liking RDM's port of smtpd.py.  I've done some clean ups, bug fixes, and added some debugging.  See this branch over on gitlab:

https://gitlab.com/python-smtpd-hackers/aiosmtpd/tree/issue25508

Try `python3 server.py` then run client.py in another terminal (it uses smtplib) or just telnet.

I plan to continue pursuing this approach; please comment over there.

----------

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

From report at bugs.python.org  Sun Oct  4 22:21:40 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 04 Oct 2015 20:21:40 +0000
Subject: [issue25304] Add run_coroutine_threadsafe() to asyncio
In-Reply-To: <1443885833.8.0.0767295795531.issue25304@psf.upfronthosting.co.za>
Message-ID: <1443990100.4.0.131180192663.issue25304@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

@rdm: thanks, you nailed it. :-)

@yury: but where would you have gotten the awaitable in the first place? It's easy to see how to get a coroutine -- just define it (with either @coroutine or async def) and call it -- and I think that's the only use case that matters here.

I'm unclear how you could have gotten another awaitable (e.g. an asyncio.Future instance) in another thread -- except by an utterly confused user.

----------

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

From report at bugs.python.org  Sun Oct  4 22:34:29 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 04 Oct 2015 20:34:29 +0000
Subject: [issue25304] Add run_coroutine_threadsafe() to asyncio
In-Reply-To: <1443885833.8.0.0767295795531.issue25304@psf.upfronthosting.co.za>
Message-ID: <1443990869.66.0.656928917577.issue25304@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> @yury: but where would you have gotten the awaitable in the first place? It's easy to see how to get a coroutine -- just define it (with either @coroutine or async def) and call it -- and I think that's the only use case that matters here.

Just a few days ago Andrew Svetlov raised a question on github -- how could he refactor `aiohttp.get()` coroutine to be a coroutine (compatible with coroutine ABC) *and* an async context manager.  With my recent commit, `ensure_future()` now accepts not just coroutines or futures, but all objects with `__await__`.

So if you have a library with an API exposed through coroutines, it would be great if you have some freedom do refactor it and keep it compatible with asyncio functions such as `run_coroutine_threadsafe()`

----------

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

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: [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  Sun Oct  4 23:29:50 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 04 Oct 2015 21:29:50 +0000
Subject: [issue25309] askopenfilename crashes on XP with "Show pop-up
 description for folder and desktop items" on
In-Reply-To: <1443914921.38.0.807954520295.issue25309@psf.upfronthosting.co.za>
Message-ID: <1443994190.5.0.752679857014.issue25309@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The Windows error, as opposed to Python traceback, is a crash. My machine is probably too fast even if it did have XP.

Serhiy: 'wish' is not a normal Windows command.

https://social.msdn.microsoft.com/Forums/en-US/2a65c068-4bf7-42ff-94b1-283105d5548d/fatal-errorexception-error-c0000005?forum=visualfoxprogeneral

says C0000005 is an
"Exception Error that occurs when a process (application, driver, etc.) tries to execute a processor command that references memory outside the space allocated to that process by the Operating System. 

There are many possible causes ranging from corrupt data tables, to a bad network connection, ActiveX controls, or  Printer or Video driver errors. WIthout knowing what type of error you are seeing, it is impossible to guess what the cause may be."

It can result either from corrupt system files on a particular machine or a bug in a particular application or a particular use of an application. Searching 'Windows c0000005 error tcl tk' lead to a stackoverflow answer reporting that running Tk.mainloop in a non-main thread without a command queue could lead to this error.

tkinter.filedialog.askopenfilename ends up running tcl command "tk_getSaveFile".  See tkinter.commondialog.  Searching "Windows c0000005 tk_getOpenFile" leads to

http://comp.lang.tcl.narkive.com/miTBmbe1/crash-in-tk-getopenfile
which ends on 2014-11-14 with "fixed in the trunk*. Even in the released 8.6.3 you should see the problem only if you are on a Windows version prior to Vista AND pass the same string to -typevariable and -filetypes." *8.6.4, delivered with 3.5.

So until there is a problem with tk 8.6.4+ on Vista+ on more than one machine, I am going to assume that you either have a bad file on your machine or that you ran into this known now-fixed tk bug.  Hence closing.

----------
resolution:  -> third party
stage: test needed -> resolved
status: open -> closed
type: behavior -> crash

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

From report at bugs.python.org  Mon Oct  5 00:11:55 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Oct 2015 22:11:55 +0000
Subject: [issue25314] Documentation: argparse's actions store_{true,
 false} default to False/True (undocumented)
In-Reply-To: <1443992693.14.0.504421256983.issue25314@psf.upfronthosting.co.za>
Message-ID: <1443996715.79.0.364672789948.issue25314@psf.upfronthosting.co.za>


R. David Murray added the comment:

There is another issue to fix the documentation for store_const, which does not in fact default to anything.  The 'default" in this case is the default for the value stored when the option is specified.  So if store_true also implies 'default=False', that should indeed be documented.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Mon Oct  5 00:28:59 2015
From: report at bugs.python.org (Julien Baley)
Date: Sun, 04 Oct 2015 22:28:59 +0000
Subject: [issue25314] Documentation: argparse's actions store_{true,
 false} default to False/True (undocumented)
In-Reply-To: <1443992693.14.0.504421256983.issue25314@psf.upfronthosting.co.za>
Message-ID: <1443997739.66.0.901449929584.issue25314@psf.upfronthosting.co.za>


Julien Baley added the comment:

That's true, store_const has no default and will throw an exception if const is not provided. Updated the patch consequently.

----------
Added file: http://bugs.python.org/file40677/store_const_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 00:29:22 2015
From: report at bugs.python.org (Julien Baley)
Date: Sun, 04 Oct 2015 22:29:22 +0000
Subject: [issue25314] Documentation: argparse's actions store_{true,
 false} default to False/True (undocumented)
In-Reply-To: <1443992693.14.0.504421256983.issue25314@psf.upfronthosting.co.za>
Message-ID: <1443997762.08.0.980529736313.issue25314@psf.upfronthosting.co.za>


Changes by Julien Baley <julien.baley at gmail.com>:


Removed 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 01:42:06 2015
From: report at bugs.python.org (Lance Warrior)
Date: Sun, 04 Oct 2015 23:42:06 +0000
Subject: [issue8550] Expose SSL contexts
In-Reply-To: <1272401803.32.0.54226209996.issue8550@psf.upfronthosting.co.za>
Message-ID: <1444002126.98.0.679149147246.issue8550@psf.upfronthosting.co.za>


Changes by Lance Warrior <lancewarrior523 at gmail.com>:


Added file: http://bugs.python.org/file40678/entry.tbp

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

From report at bugs.python.org  Mon Oct  5 02:27:02 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 05 Oct 2015 00:27:02 +0000
Subject: [issue25313] IDLE: gracefully handle themes (or keysets,
 or ...) not present
In-Reply-To: <1443983028.38.0.330062493222.issue25313@psf.upfronthosting.co.za>
Message-ID: <1444004822.02.0.0625496131442.issue25313@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

There over-arching issue is that IDLE was not built to allow addition of new builtin themes.  IDLE New is currently identical to IDLE Classic, so maybe that was intended to allow a revision of IDLE Classic (and I have an idea for that), but IDLE Dark is too drastically different to have added it as IDLE New. There are two sub-issues here.

1. Theme loading: I experienced the multiple error messages to console behavior once, but only once.  This is the 'or worse' in the new message.  I could not find out why only once, or know that the same would be true on other machines. If possible, there should only be one message. Whether it goes to console or messagebox is a different issue, part of revisiting the configure error message system.

The first fallback should be to existing and accessible builtins, namely IDLE Classic, rather than a default of no colors.  This strikes me as a buggy design.

2. New theme addition and selection: This has to take into account that we cannot patch existing releases and that all IDLEs used by one user use the same user configuration files.  (There is an issue post that suggests maybe changing this, but I cannot find it now.)  This is a minus in that we cannot currently restrict selection of IDLE Dark to new IDLEs (but see below).  This is a plus in that IDLE Dark can be 'backported' by saving as a custom theme.  We may always need some sort of message.

I thought about automatically saving as a custom theme, but besides the presumed deadline for 3.4.4 (see below), there are potential problems. A) It is magical and potentially confusing enough that I might want a message anyway. B) It may not be possible (no writable .idlerc).  I am not sure what happens if not. C) If we write with the same name, 'IDLE Dark', then two things have the same name but may or may not be identical. (Users could modify the custom version of IDLE Dark.)  This is why the interface demands a new name. Your patch assumes that they stay identical. D) If we write as a different name, users need to be notified anyway.  Might as well let them choose, so they remember. E) A custom version is not needed for students in a class with only one IDLE on the machine. F) We would have to look at possible interactions with other parts of the dialog's behavior.

"See below", time pressure: I though 3.4.4c1 was due out today.  It has not appeared, and there have been no pydev messages for 20 hours, since I posted an enquiry out the release.  If the release is a week away, we can potentially change the patch, though I would want to test very carefully.

"See below", date-specific user config: because all releases after today will have IDLE Dark, the needed marker is date rather than version.  Right now, selecting 'IDLE Dark' as a built-in theme results in user config-main.cfg having this section.

[Theme]
default = True
name = IDLE Dark

Suppose instead the result were

[Theme]
default = True
name2 = IDLE Dark
#or
[Theme]
default = True
name = IDLE New
name2 = IDLE Dark

I tested with 2.7.10 and it starts fine with either of the above, and just as important, writes the above when Classic or New are selected if the name2 line is there.  I expect the both should be true of all versions that recognize user config files, especially the startup part.

The challenge would be to have new IDLEs add the name2 line when IDLE Dark is selected and have it replace name with name2 when fetching the name.  The message could then be something to the effect of "IDLE Dark only comes with IDLE releases in Oct, 2015 and later.  To make it available to older releases, save it as a custom theme (with a new name)."

This is a bit clumsy, and would have to be generalized for further theme (but YAGNI for now), but would eliminate errors and no color with old versions.  What do you think?

----------

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

From report at bugs.python.org  Mon Oct  5 02:30:29 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 05 Oct 2015 00:30:29 +0000
Subject: [issue25304] Add run_coroutine_threadsafe() to asyncio
In-Reply-To: <1443885833.8.0.0767295795531.issue25304@psf.upfronthosting.co.za>
Message-ID: <1444005029.2.0.987747139049.issue25304@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Well, I still worry that this is just going to encourage more people to try and call awaitables from threaded code, and through some circuitous path of misunderstandings (probably involving StackOverflow :-) end up using this function.

(Pretty much the worst-case scenario would be calling run_coroutine_threadsafe() targeting the *current* loop, and then blocking the thread waiting for its result. Deadlock!)

----------

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

From report at bugs.python.org  Mon Oct  5 02:39:01 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 05 Oct 2015 00:39:01 +0000
Subject: [issue24954] No way to generate or parse timezone as produced by
 datetime.isoformat()
In-Reply-To: <1440801281.72.0.545558404714.issue24954@psf.upfronthosting.co.za>
Message-ID: <1444005541.81.0.315681068579.issue24954@psf.upfronthosting.co.za>


Martin Panter added the comment:

I added some comments on Rietveld. I guess the documentation should get notices and What?s New entries saying it is new in 3.6. Test cases would be good, including negative ones to check error handling is sensible if the Z is missing. Also shanmbic, perhaps look at signing the contributor agreement <https://www.python.org/psf/contrib/> if you haven?t already.

Adding to the list of format codes means that the statement at the top of the list about them all being required by C89 will need fixing.

For parsing, perhaps the existing %z code could be extended to accept colons, without needing to specify a new %:z code. Although if %:z is added for formatting, it should also be supported for parsing.

I am not convinced that it is worth adding %::z or %:::z to Python. The documentation of tzinfo.utcoffset() says it returns the offset ?in minutes?, hinting that sub-minute offsets are not supported. RFC 3339 acknowledges that sub-minute offsets exist in history, but AFAIK neither RFC 3339 nor ISO 8601 support them. So I think it is too specialized to build %::z into Python. And I don?t imagine the %:::z necessary precision version would be used much either.

----------
nosy: +martin.panter
stage: needs patch -> patch review

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

From report at bugs.python.org  Mon Oct  5 02:39:47 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 05 Oct 2015 00:39:47 +0000
Subject: [issue24954] No way to generate or parse timezone as produced by
 datetime.isoformat()
In-Reply-To: <1440801281.72.0.545558404714.issue24954@psf.upfronthosting.co.za>
Message-ID: <1444005587.16.0.74943089367.issue24954@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
components: +Extension Modules -ctypes

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

From report at bugs.python.org  Mon Oct  5 02:42:55 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 05 Oct 2015 00:42:55 +0000
Subject: [issue25311] Add f-string support to tokenize.py
In-Reply-To: <1443979407.62.0.707305717475.issue25311@psf.upfronthosting.co.za>
Message-ID: <1444005775.76.0.843631837472.issue25311@psf.upfronthosting.co.za>


Martin Panter added the comment:

I was just about to make the same bug report :) I guess it would be fine to tokenize F-strings as the same string objects as others, it probably just needs adding an F to the right regular expression.

$ ./python -btWall -m tokenize
"string"
1,0-1,8:            STRING         '"string"'     
1,8-1,9:            NEWLINE        '\n'           
b"string"
3,0-3,9:            STRING         'b"string"'    
3,9-3,10:           NEWLINE        '\n'           
f"string"
4,0-4,1:            NAME           'f'            
4,1-4,9:            STRING         '"string"'     
4,9-4,10:           NEWLINE        '\n'

----------
keywords: +easy
nosy: +martin.panter

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

From report at bugs.python.org  Mon Oct  5 03:18:33 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 05 Oct 2015 01:18:33 +0000
Subject: [issue8550] Expose SSL contexts
In-Reply-To: <1272401803.32.0.54226209996.issue8550@psf.upfronthosting.co.za>
Message-ID: <1444007913.5.0.779330616633.issue8550@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


Removed file: http://bugs.python.org/file40678/entry.tbp

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

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: [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 04:10:31 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 05 Oct 2015 02:10:31 +0000
Subject: [issue17061] tokenize unconditionally emits NL after comment lines &
 blank lines
In-Reply-To: <1359371668.59.0.445577508897.issue17061@psf.upfronthosting.co.za>
Message-ID: <1444011031.92.0.750774995283.issue17061@psf.upfronthosting.co.za>


Martin Panter added the comment:

The plain Python shell does respond to lines with only a comment and/or horizontal space with a continuation prompt. It only treats completely blank lines without any horizontal space specially:

>>>     
... # Indented blank line above; completely blank line below:
... 
>>> 

Meador: The documentation already says what you proposed: ?NL tokens are generated when a logical line of code is continued over multiple physical lines? <https://docs.python.org/dev/library/tokenize.html#tokenize.NL>.

Thomas: It sounds like you actually want to differentiate newlines inside bracketed expressions from newlines outside of statements. I think this would require a new feature.

Also, I noticed that an escaped continued newline doesn?t seem to generate any token at all. Not sure if this is a bug or intended, but it does seem inconsistent with the other uses of the NL token.

$ ./python -btWall -m tokenize
1 + \
1,0-1,1:            NUMBER         '1'            
1,2-1,3:            OP             '+'            
1
2,0-2,1:            NUMBER         '1'            
2,1-2,2:            NEWLINE        '\n'           
3,0-3,0:            ENDMARKER      ''

----------
nosy: +martin.panter
type: behavior -> enhancement
versions: +Python 3.6 -Python 2.6, Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Oct  5 04:28:33 2015
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 05 Oct 2015 02:28:33 +0000
Subject: [issue25315] OrderedDict mangled private attribute is inaccessible
In-Reply-To: <1444010587.49.0.504903152106.issue25315@psf.upfronthosting.co.za>
Message-ID: <1444012113.72.0.538538926196.issue25315@psf.upfronthosting.co.za>


Zachary Ware added the comment:

This is a side-effect of 3.5 having a C implementation of OrderedDict, and will not be fixed.

In the standard library, even just having a single trailing underscore is a clear indication of "if you use this, expect it to break without warning at any time."  Mangled names in the standard library are more of an indication of "you *really* shouldn't use this".

----------
nosy: +eric.snow, zach.ware
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Oct  5 05:27:26 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 05 Oct 2015 03:27:26 +0000
Subject: [issue9969] tokenize: add support for tokenizing 'str' objects
In-Reply-To: <1285679839.5.0.180278126855.issue9969@psf.upfronthosting.co.za>
Message-ID: <1444015646.03.0.786858802315.issue9969@psf.upfronthosting.co.za>


Martin Panter added the comment:

I left some comments. Also, it would be nice to use the new function in the documentation example, which currently suggests tunnelling through UTF-8 but not adding an encoding comment. And see the patch for Issue 12486, which highlights a couple of other places that would benefit from this function.

----------
nosy: +martin.panter

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

From report at bugs.python.org  Mon Oct  5 05:27:56 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 05 Oct 2015 03:27:56 +0000
Subject: [issue12486] tokenize module should have a unicode API
In-Reply-To: <1309751897.67.0.332272921906.issue12486@psf.upfronthosting.co.za>
Message-ID: <1444015676.89.0.631468630308.issue12486@psf.upfronthosting.co.za>


Martin Panter added the comment:

I agree it would be very useful to be able to tokenize arbitrary text without worrying about encoding tokens. I left some suggestions for the documentation changes. Also some test cases for it would be good.

However I wonder if a separate function would be better for the text mode tokenization. It would make it clearer when an ENCODING token is expected and when it isn?t, and would avoid any confusion about what happens when readline() returns a byte string one time and a text string another time. Also, having untokenize() changes its output type depending on the ENCODING token seems like bad design to me.

Why not just bless the existing generate_tokens() function as a public API, perhaps renaming it to something clearer like tokenize_text() or tokenize_text_lines() at the same time?

----------
nosy: +martin.panter
stage:  -> patch review

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

From report at bugs.python.org  Mon Oct  5 06:01:30 2015
From: report at bugs.python.org (Mark Roseman)
Date: Mon, 05 Oct 2015 04:01:30 +0000
Subject: [issue25313] IDLE: gracefully handle themes (or keysets,
 or ...) not present
In-Reply-To: <1443983028.38.0.330062493222.issue25313@psf.upfronthosting.co.za>
Message-ID: <1444017690.84.0.518305811799.issue25313@psf.upfronthosting.co.za>


Mark Roseman added the comment:

I see the 3.4.4 is not an immediate concern, so that's good.

FYI, I get the (multiple) error messages on console consistently on Mac, but it probably depends how it was launched. Agree the code for future versions should do a better job to detect the theme isn't present and switch back to a default theme rather than just puking out error messages as it tries to get each element of the non-existent theme. :-)

I still think the approach I took may be viable. It doesn't require changes to old versions, and relies on the fact that a user theme with the same name as a default theme is effectively hidden by the default theme. 

If a 'new' theme is selected, it's always written out to config-highlight, so it will be present for older versions (not errors and the internal default colors). Given that, I need help understanding what the 'name' vs. 'name2' etc. solution gives us?

(Not being able to write .idlerc wouldn't be an issue, because then you wouldn't be able to write out the change to say that is the theme to use anyway).

The only drawback I see is that a user running a previous version can customize IDLE Dark and those changes would not appear when using a newer versions of IDLE that had IDLE Dark as a default.

This would negatively affect only those users who change to IDLE Dark, actually modify the theme, and switch back and forth between versions of IDLE. The consequences of this occurring are only that the changes don't show up. In other words, I feel this affects a very tiny number of people, in a relatively minor way.

The existing warning on choosing themes will be encountered by anyone who might switch themes in the new version, and particularly for the non-hardcore, would be at the least surprising if not confusing or alarming. I think it's safe to assume that far more people try existing themes vs. create custom themes and use multiple versions of IDLE.

Given the very minor consequences and how few people it would affect, vs. how many people would encounter that warning and the impression it would leave, this seems a case of I'd rather be unobtrusive and 98+% correct then obtrusive and 100% correct. 

If it were my product, there's no question I'd drop the warning under those circumstances, and if it were a choice between including the warning or not including a new theme, I'd personally choose to not include the new theme. 

Anyway, it seems we have time to think more about this...

----------

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

From report at bugs.python.org  Mon Oct  5 06:58:00 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 05 Oct 2015 04:58:00 +0000
Subject: [issue15280] Don't use builtins as variable names in urllib.request
In-Reply-To: <1341675187.35.0.731342856867.issue15280@psf.upfronthosting.co.za>
Message-ID: <1444021080.16.0.957413710271.issue15280@psf.upfronthosting.co.za>


Martin Panter added the comment:

The name changes to the function parameters should be avoided without a good reason.

I would recommend rejecting all of the changes in this patch. They are basically changing one person?s coding style to another person?s style. I happen to prefer list() and map() over the list comprehension syntax.

I don?t have a problem with a variable named ?type? in a small function. For instance, open_unknown() is only four lines, including signature and doc string! If you can?t easily predict all the variables in a larger function, then I suggest dividing it into smaller components. PEP 8 doesn?t seem to mention the issue of shadowing variable names that I can see anyway.

----------
nosy: +martin.panter
stage:  -> patch review
type:  -> enhancement

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

From report at bugs.python.org  Mon Oct  5 07:14:30 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 05 Oct 2015 05:14:30 +0000
Subject: [issue9969] tokenize: add support for tokenizing 'str' objects
In-Reply-To: <1285679839.5.0.180278126855.issue9969@psf.upfronthosting.co.za>
Message-ID: <1444022070.6.0.0240550131815.issue9969@psf.upfronthosting.co.za>


Martin Panter added the comment:

Actually maybe Issue 12486 is good enough to fix this too. With the patch proposed there, tokenize_basestring("source") would just be equivalent to

tokenize(StringIO("source").readline)

----------

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

From report at bugs.python.org  Mon Oct  5 07:29:27 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Oct 2015 05:29:27 +0000
Subject: [issue15280] Don't use builtins as variable names in urllib.request
In-Reply-To: <1341675187.35.0.731342856867.issue15280@psf.upfronthosting.co.za>
Message-ID: <1444022967.48.0.892421939354.issue15280@psf.upfronthosting.co.za>


R. David Murray added the comment:

I agree.  The one change that has a non-style motivation (type) is one that should not be made for backward compatibility reasons.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Oct  5 08:01:59 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Oct 2015 06:01:59 +0000
Subject: [issue12486] tokenize module should have a unicode API
In-Reply-To: <1309751897.67.0.332272921906.issue12486@psf.upfronthosting.co.za>
Message-ID: <1444024919.05.0.251260632776.issue12486@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your review Martin.

Here is rebased patch that addresses Matin's comments.

I agree that having untokenize() changes its output type depending on the ENCODING token is bad design and we should change this. But this is perhaps other issue.

----------
versions: +Python 3.6 -Python 3.4

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

From report at bugs.python.org  Mon Oct  5 08:04:47 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Oct 2015 06:04:47 +0000
Subject: [issue12486] tokenize module should have a unicode API
In-Reply-To: <1309751897.67.0.332272921906.issue12486@psf.upfronthosting.co.za>
Message-ID: <1444025087.26.0.337945018615.issue12486@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file40679/tokenize_str_2.diff

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

From report at bugs.python.org  Mon Oct  5 08:25:14 2015
From: report at bugs.python.org (Florin Papa)
Date: Mon, 05 Oct 2015 06:25:14 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1444026314.52.0.558245102852.issue25300@psf.upfronthosting.co.za>


Florin Papa added the comment:

Hi Antoine,

Third party modules might need patching to work with MPX, as did the math module, included in this patch. Everything else worked fine in Python 2.7.10+ and 3.6 when running the Grand Unified Python Benchmarks suite and Openstack Swift ssbench benchmark (ssbench supports only 2.7.10+).

----------

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

From report at bugs.python.org  Mon Oct  5 08:46:02 2015
From: report at bugs.python.org (Florin Papa)
Date: Mon, 05 Oct 2015 06:46:02 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1444027562.3.0.431425250094.issue25300@psf.upfronthosting.co.za>


Florin Papa added the comment:

Hi Stefan,

When activating the "--with-mpx" flag in ./configure, a check is also performed to see if the compiler is GCC version 5.1 or higher in order to support MPX (and an appropriate error is shown, indicating that the compiler version is wrong). Setting the flags manually will only result in a compiler error.

Also, it might not be obvious for the user from the GCC documentation that both "-fcheck-pointer-bounds" and "-mmpx" flags are needed to enable MPX instrumentation, so adding the "--with-mpx" flag to configure will make it easier to use this feature.

----------

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

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: [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 09:35:53 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 05 Oct 2015 07:35:53 +0000
Subject: [issue12486] tokenize module should have a unicode API
In-Reply-To: <1309751897.67.0.332272921906.issue12486@psf.upfronthosting.co.za>
Message-ID: <1444030553.7.0.00234911547938.issue12486@psf.upfronthosting.co.za>


Martin Panter added the comment:

I didn?t notice that this dual untokenize() behaviour already existed. Taking that into account weakens my argument for having separate text and bytes tokenize() functions.

----------

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

From report at bugs.python.org  Mon Oct  5 10:15:29 2015
From: report at bugs.python.org (Peter Funk)
Date: Mon, 05 Oct 2015 08:15:29 +0000
Subject: [issue20658] os.environ.clear() fails with empty keys (posix.unsetenv)
In-Reply-To: <1392642368.27.0.300660634921.issue20658@psf.upfronthosting.co.za>
Message-ID: <1444032929.46.0.206269310094.issue20658@psf.upfronthosting.co.za>


Changes by Peter Funk <pefu at users.sourceforge.net>:


----------
nosy: +pefu

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

From report at bugs.python.org  Mon Oct  5 10:16:48 2015
From: report at bugs.python.org (Peter Funk)
Date: Mon, 05 Oct 2015 08:16:48 +0000
Subject: [issue4926] putenv() accepts names containing '=',
 return value of unsetenv() not checked
In-Reply-To: <1231803037.62.0.52390349364.issue4926@psf.upfronthosting.co.za>
Message-ID: <1444033008.49.0.706247590728.issue4926@psf.upfronthosting.co.za>


Changes by Peter Funk <pefu at users.sourceforge.net>:


----------
nosy: +pefu

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

From report at bugs.python.org  Mon Oct  5 10:19:34 2015
From: report at bugs.python.org (Serge Matveenko)
Date: Mon, 05 Oct 2015 08:19:34 +0000
Subject: [issue25315] OrderedDict mangled private attribute is inaccessible
In-Reply-To: <1444010587.49.0.504903152106.issue25315@psf.upfronthosting.co.za>
Message-ID: <1444033174.41.0.596618499574.issue25315@psf.upfronthosting.co.za>


Serge Matveenko added the comment:

Zach, ok I got your point. But there is Python implementation in the library still which does not conform the one done in C. Such a behavior is tremendously confusing.

If there is both Python and C implementation in the library they must conform each other. And there is nothing with "you *really* shouldn't use this" when you need to especially when it is there. If it is there it must work as it written. Otherwise why Python does have this peace of code while it is completely useless as reference?

----------
resolution: wont fix -> 
status: closed -> open

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

From report at bugs.python.org  Mon Oct  5 10:31:28 2015
From: report at bugs.python.org (Serge Matveenko)
Date: Mon, 05 Oct 2015 08:31:28 +0000
Subject: [issue25315] OrderedDict mangled private attribute is inaccessible
In-Reply-To: <1444010587.49.0.504903152106.issue25315@psf.upfronthosting.co.za>
Message-ID: <1444033888.41.0.537369385932.issue25315@psf.upfronthosting.co.za>


Serge Matveenko added the comment:

If Python source does conform the one in C, it will be completely fine and understandable to have such a change and to rely on it in using version checks or whatever.

----------

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

From report at bugs.python.org  Mon Oct  5 11:38:00 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Oct 2015 09:38:00 +0000
Subject: [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 11:40:15 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Oct 2015 09:40:15 +0000
Subject: [issue25315] OrderedDict mangled private attribute is inaccessible
In-Reply-To: <1444010587.49.0.504903152106.issue25315@psf.upfronthosting.co.za>
Message-ID: <1444038015.92.0.359825811867.issue25315@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> rhettinger
nosy: +rhettinger
priority: normal -> low

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

From report at bugs.python.org  Mon Oct  5 11:40:53 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Oct 2015 09:40:53 +0000
Subject: [issue25317] Convert test_tokenize to unittests
In-Reply-To: <1444037877.91.0.0285113512794.issue25317@psf.upfronthosting.co.za>
Message-ID: <1444038053.93.0.692491832028.issue25317@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
title: Convert test_ -> Convert test_tokenize to unittests

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

From report at bugs.python.org  Mon Oct  5 12:07:22 2015
From: report at bugs.python.org (Florin Papa)
Date: Mon, 05 Oct 2015 10:07:22 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1444039642.64.0.521524209939.issue25300@psf.upfronthosting.co.za>


Florin Papa added the comment:

Hi all,

Thank you for your feedback on the code I submitted.

I added the MPX flags to CFLAGS, not CFLAGS_NODIST, because they also need to be included in LDFLAGS.

Please see the new set of patches.

Thank you,
Florin

----------
Added file: http://bugs.python.org/file40681/mpx_enable_3_6_v2.patch

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

From report at bugs.python.org  Mon Oct  5 12:07:33 2015
From: report at bugs.python.org (Florin Papa)
Date: Mon, 05 Oct 2015 10:07:33 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1444039653.11.0.515024235265.issue25300@psf.upfronthosting.co.za>


Changes by Florin Papa <florin.papa at intel.com>:


Added file: http://bugs.python.org/file40682/mpx_enable_2_7_v2.patch

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

From report at bugs.python.org  Mon Oct  5 12:13:54 2015
From: report at bugs.python.org (Bar Harel)
Date: Mon, 05 Oct 2015 10:13:54 +0000
Subject: [issue25175] Documentation-Tkinter Clarify module spelling change in
 Python 3 docs
In-Reply-To: <1442656864.32.0.801468754438.issue25175@psf.upfronthosting.co.za>
Message-ID: <1444040034.15.0.332921572134.issue25175@psf.upfronthosting.co.za>


Bar Harel added the comment:

I guess you're correct, a simple mistake one time mistake shouldn't require the changing of the docs.

----------

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

From report at bugs.python.org  Mon Oct  5 12:31:46 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Oct 2015 10:31:46 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1444041106.04.0.714896900613.issue25300@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This looks ok to me as long as it's disabled by default.

----------
type: security -> enhancement

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

From report at bugs.python.org  Mon Oct  5 12:43:51 2015
From: report at bugs.python.org (=?utf-8?q?Mi=C8=99u_Moldovan?=)
Date: Mon, 05 Oct 2015 10:43:51 +0000
Subject: [issue20981] ssl doesn't build anymore with OpenSSL 0.9.7 or older:
 X509_check_ca
In-Reply-To: <1395247121.79.0.24713590698.issue20981@psf.upfronthosting.co.za>
Message-ID: <1444041831.17.0.718365981592.issue20981@psf.upfronthosting.co.za>


Mi?u Moldovan added the comment:

For the record, this is an issue in Red Hat Enterprise Linux 4 too. For RHEL 4, "Extended" support ends on March 31, 2017, according to https://access.redhat.com/support/policy/updates/errata

----------

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

From report at bugs.python.org  Mon Oct  5 13:19:50 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 05 Oct 2015 11:19:50 +0000
Subject: [issue25317] Convert test_tokenize to unittests
In-Reply-To: <1444037877.91.0.0285113512794.issue25317@psf.upfronthosting.co.za>
Message-ID: <1444043990.94.0.260004867992.issue25317@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

+1

----------
nosy: +eric.smith

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

From report at bugs.python.org  Mon Oct  5 13:36:16 2015
From: report at bugs.python.org (Emanuel Barry)
Date: Mon, 05 Oct 2015 11:36:16 +0000
Subject: [issue25315] OrderedDict mangled private attribute is inaccessible
In-Reply-To: <1444010587.49.0.504903152106.issue25315@psf.upfronthosting.co.za>
Message-ID: <1444044976.45.0.326006713508.issue25315@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

The same is true of the decimal and datetime modules. Names starting with an underscore are an implementation detail, and you shouldn't rely on these in production code.

----------
nosy: +ebarry

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

From report at bugs.python.org  Mon Oct  5 13:44:03 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 05 Oct 2015 11:44:03 +0000
Subject: [issue25301] Optimize UTF-8 decoder with error handlers
In-Reply-To: <1443797082.73.0.711354360874.issue25301@psf.upfronthosting.co.za>
Message-ID: <20151005114359.471.76729@psf.io>


Roundup Robot added the comment:

New changeset 3152e4038d97 by Victor Stinner in branch 'default':
Issue #25301: The UTF-8 decoder is now up to 15 times as fast for error
https://hg.python.org/cpython/rev/3152e4038d97

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Oct  5 13:44:37 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Oct 2015 11:44:37 +0000
Subject: [issue25301] Optimize UTF-8 decoder with error handlers
In-Reply-To: <1443797082.73.0.711354360874.issue25301@psf.upfronthosting.co.za>
Message-ID: <1444045477.74.0.691820642791.issue25301@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I pushed my optimization. I close the issue.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Mon Oct  5 13:49:36 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 05 Oct 2015 11:49:36 +0000
Subject: [issue25301] Optimize UTF-8 decoder with error handlers
In-Reply-To: <1443797082.73.0.711354360874.issue25301@psf.upfronthosting.co.za>
Message-ID: <20151005114933.2681.60586@psf.io>


Roundup Robot added the comment:

New changeset 5b9ffea7e7c3 by Victor Stinner in branch 'default':
Issue #25301: Fix compatibility with ISO C90
https://hg.python.org/cpython/rev/5b9ffea7e7c3

----------

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

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: [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 14:02:50 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Oct 2015 12:02:50 +0000
Subject: [issue25318] Add _PyBytesWriter API to optimize Unicode encoders
In-Reply-To: <1444046488.88.0.905297361267.issue25318@psf.upfronthosting.co.za>
Message-ID: <1444046570.26.0.468610133892.issue25318@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Result of  bench.py attached to issue #25267: attached bench_utf8_result.txt.

------------------------------------------------------+-------------+---------------
Summary?????????????????????????????????????????????? | utf8_before | ????utf8_after
------------------------------------------------------+-------------+---------------
ignore: "\udcff" * length???????????????????????????? | 7.63 us (*) | ???????7.91 us
ignore: "a" * length + "\udcff"?????????????????????? | 10.7 us (*) | ???????10.8 us
ignore: ("a" * 99 + "\udcff" * 99) * length?????????? | 2.17 ms (*) | ???????2.16 ms
ignore: ("\udcff" * 99 + "a") * length??????????????? | ?843 us (*) | ????????866 us
ignore: "\udcff" + "a" * length?????????????????????? | 10.7 us (*) | ?????????11 us
replace: "\udcff" * length??????????????????????????? | 7.87 us (*) | ?8.43 us (+7%)
replace: "a" * length + "\udcff"????????????????????? | 10.8 us (*) | ???????10.9 us
replace: ("a" * 99 + "\udcff" * 99) * length????????? | 2.46 ms (*) | ???????2.46 ms
replace: ("\udcff" * 99 + "a") * length?????????????? | ?907 us (*) | ????????939 us
replace: "\udcff" + "a" * length????????????????????? | 10.9 us (*) | ?????????11 us
surrogateescape: "\udcff" * length??????????????????? | 14.2 us (*) | 17.2 us (+21%)
surrogateescape: "a" * length + "\udcff"????????????? | 10.6 us (*) | ???????10.7 us
surrogateescape: ("a" * 99 + "\udcff" * 99) * length? | 3.19 ms (*) | ??3.4 ms (+7%)
surrogateescape: ("\udcff" * 99 + "a") * length?????? | 1.64 ms (*) | 1.87 ms (+13%)
surrogateescape: "\udcff" + "a" * length????????????? | 10.6 us (*) | ???????10.7 us
surrogatepass: "\udcff" * length????????????????????? | 23.1 us (*) | ???????23.5 us
surrogatepass: "a" * length + "\udcff"??????????????? | 10.7 us (*) | ???????10.8 us
surrogatepass: ("a" * 99 + "\udcff" * 99) * length??? | 4.39 ms (*) | ???????4.44 ms
surrogatepass: ("\udcff" * 99 + "a") * length???????? | 2.43 ms (*) | ???????2.47 ms
surrogatepass: "\udcff" + "a" * length??????????????? | 10.6 us (*) | ???????10.8 us
backslashreplace: "\udcff" * length?????????????????? | 65.7 us (*) | ???????64.3 us
backslashreplace: "a" * length + "\udcff"???????????? | 15.7 us (*) | ?????????15 us
backslashreplace: ("a" * 99 + "\udcff" * 99) * length | ??12 ms (*) | 15.9 ms (+32%)
backslashreplace: ("\udcff" * 99 + "a") * length????? | 11.1 ms (*) | 13.5 ms (+22%)
backslashreplace: "\udcff" + "a" * length???????????? | 16.4 us (*) | ?15.1 us (-8%)
------------------------------------------------------+-------------+---------------
Total???????????????????????????????????????????????? | 41.4 ms (*) | 48.3 ms (+17%)
------------------------------------------------------+-------------+---------------

----------
Added file: http://bugs.python.org/file40683/bench_utf8_result.txt

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

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


STINNER Victor added the comment:

Results of bench.py attached to issue #25227 (ASCII and Latin1 encoders): attached bench_ucs1_result.txt file.

--------+-------------+-----------
Summary | ucs1_before | ucs1_after
--------+-------------+-----------
ascii   | 1.69 ms (*) |    1.69 ms
latin1  |  1.7 ms (*) |    1.69 ms
--------+-------------+-----------
Total   | 3.39 ms (*) |    3.39 ms
--------+-------------+-----------

----------

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

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


Changes by STINNER Victor <victor.stinner at gmail.com>:


Added file: http://bugs.python.org/file40684/bench_ucs1_result.txt

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

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


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file40685/bytes_writer.patch

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

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


STINNER Victor added the comment:

A few months ago, I wrote a previous implementation of the _PyBytesWriter API which embedded the "current pointer" inside _PyBytesWriter API. The problem was that GCC produced less efficient code than expect for the hotspot of the encoder.

In the new implementation (attached patch), the "current pointer" is unchanged: it's still a variable local to the encoder function. Instead, the current pointer became a *parameter* to all _PyBytesWriter *functions*.

I expect to not touch performances of encoders for valid encoded strings (when the code calling error handlers is not used), which is important since we have very good performance here.

_PyBytesWriter is not restricted to the code to allocate the buffer.

--

bytes_writer.patch:

+    char stackbuf[256];

Oh, I forgot to mention this other small optimization. I also added a small buffer allocated on the C stack for the UCS1 encoder (ASCII, Latin1). It may optimize a little bit encoding when the output string is smaller than 256 bytes when the error handler is used.

The optimization comes from the very efficient UTF-8 encoder.

----------

_______________________________________
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: [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 16:01:35 2015
From: report at bugs.python.org (Nir Soffer)
Date: Mon, 05 Oct 2015 14:01:35 +0000
Subject: [issue25319] Keep lock type when reseting internal locks
In-Reply-To: <1444051403.68.0.196001867236.issue25319@psf.upfronthosting.co.za>
Message-ID: <1444053695.69.0.0264263046973.issue25319@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file40687/0001-Keep-lock-type-when-reseting-internal-locks-2.7.patch

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

From report at bugs.python.org  Mon Oct  5 16:06:56 2015
From: report at bugs.python.org (Nir Soffer)
Date: Mon, 05 Oct 2015 14:06:56 +0000
Subject: [issue25319] Keep lock type when reseting internal locks
In-Reply-To: <1444051403.68.0.196001867236.issue25319@psf.upfronthosting.co.za>
Message-ID: <1444054016.81.0.900980623948.issue25319@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file40688/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 16:19:09 2015
From: report at bugs.python.org (Patrick Maupin)
Date: Mon, 05 Oct 2015 14:19:09 +0000
Subject: [issue25294] Absolute imports fail in some cases where relative
 imports would work
In-Reply-To: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>
Message-ID: <1444054749.88.0.333634324057.issue25294@psf.upfronthosting.co.za>


Patrick Maupin added the comment:

concurrent/futures/__init__.py may be a better example than 2to3 for this issue.  It's relatively new code, it's part of the standard library, it's fairly small and self-contained, and it doesn't follow the promulgated standard.

If it's bad code, it should be modified.  If it's not bad code, then the docs shouldn't denigrate the coding style (especially not to the extent of requiring absolute imports in standard library code), because a lot of newbies take the docs to heart and spend a lot of time and energy beating up themselves and others about conformance.

----------

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

From report at bugs.python.org  Mon Oct  5 16:19:16 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Oct 2015 14:19:16 +0000
Subject: [issue25315] OrderedDict mangled private attribute is inaccessible
In-Reply-To: <1444010587.49.0.504903152106.issue25315@psf.upfronthosting.co.za>
Message-ID: <1444054756.39.0.0116760379221.issue25315@psf.upfronthosting.co.za>


R. David Murray added the comment:

A method that starts with an '_' is not part of the API unless documented to be so (as with namedtuple), and a non-special method that starts with two is purposefully mangled so that you cannot accidentally rely on it.  The C implementation is an implementation of the API and the behavior when that API is used (as vetted by the tests that are run against both implementations); it is not otherwise required to "conform" to the python implementation or vice versa.

----------
nosy: +r.david.murray
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Mon Oct  5 17:14:11 2015
From: report at bugs.python.org (Bar Harel)
Date: Mon, 05 Oct 2015 15:14:11 +0000
Subject: [issue24505] shutil.which wrong result on Windows
In-Reply-To: <1435183779.2.0.13075721906.issue24505@psf.upfronthosting.co.za>
Message-ID: <1444058051.57.0.900077003259.issue24505@psf.upfronthosting.co.za>


Bar Harel added the comment:

Unfortunately that patch will not help for files like "python.exe.exe", and double ext which sometimes happens.
I'm on it. Should take me a day or two, more problems might arise along the way. Thanks Bob for alerting.

Regarding the uppercase, I believe it is better to leave the casing as it is. It should be up to the user to mess with it as converting case is a one way ticket. If someone entered an uppercase, perhaps he wants it like that. Also it's less prune to errors and behaves the same for Unix and Windows.

----------
nosy: +bar.harel

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

From report at bugs.python.org  Mon Oct  5 17:32:34 2015
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 05 Oct 2015 15:32:34 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1444059154.92.0.961633367232.issue25300@psf.upfronthosting.co.za>


Stefan Krah added the comment:

> Third party modules might need patching to work with MPX...

If the flags go into CFLAGS, these modules won't compile with
distutils.  Perhaps we should also add LDFLAGS_NODIST, if that
would solve your problem.

----------

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

From report at bugs.python.org  Mon Oct  5 18:05:52 2015
From: report at bugs.python.org (Pathangi Jatinshravan)
Date: Mon, 05 Oct 2015 16:05:52 +0000
Subject: [issue25228] Regression in cookie parsing with brackets and quotes
In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za>
Message-ID: <1444061152.01.0.738200291565.issue25228@psf.upfronthosting.co.za>


Pathangi Jatinshravan added the comment:

Hi, can I be assigned to this behaviour issue?

----------
nosy: +Pathangi Jatinshravan

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

From report at bugs.python.org  Mon Oct  5 18:06:51 2015
From: report at bugs.python.org (Tim Graham)
Date: Mon, 05 Oct 2015 16:06:51 +0000
Subject: [issue25228] Regression in cookie parsing with brackets and quotes
In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za>
Message-ID: <1444061211.17.0.438516215062.issue25228@psf.upfronthosting.co.za>


Tim Graham added the comment:

Sure, feel free to propose a patch.

----------

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

From report at bugs.python.org  Mon Oct  5 18:09:49 2015
From: report at bugs.python.org (Pathangi Jatinshravan)
Date: Mon, 05 Oct 2015 16:09:49 +0000
Subject: [issue25228] Regression in cookie parsing with brackets and quotes
In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za>
Message-ID: <1444061389.1.0.656664026911.issue25228@psf.upfronthosting.co.za>


Pathangi Jatinshravan added the comment:

This is the first ever bug I will be working on so there might be a bit of a learning curve, but I'll do my best to come out with something by this week.

----------

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

From report at bugs.python.org  Mon Oct  5 18:12:39 2015
From: report at bugs.python.org (Vincent Michel)
Date: Mon, 05 Oct 2015 16:12:39 +0000
Subject: [issue25304] Add run_coroutine_threadsafe() to asyncio
In-Reply-To: <1443885833.8.0.0767295795531.issue25304@psf.upfronthosting.co.za>
Message-ID: <1444061559.1.0.711185040308.issue25304@psf.upfronthosting.co.za>


Vincent Michel added the comment:

I attached the first version of the documentation for `run_coroutine_threadsafe`. The `Concurrency and multithreading` section also needs to be updated but I could already use some feedback.

Also, I think we should add a `try-except` in the callback function, especially since users can set their own task factory. For instance:
  
loop.set_task_factory(lambda loop, coro: i_raise_an_exception)

will cause the future returned by `run_coroutine_threadsafe` to wait forever. Instead, we could have:

    except Exception as exc:
        if future.set_running_or_notify_cancel():
            future.set_exception(exc)

inside the callback to notify the future.

----------
keywords: +patch
Added file: http://bugs.python.org/file40689/run_coroutine_threadsafe_doc.patch

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

From report at bugs.python.org  Mon Oct  5 18:17:29 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Oct 2015 16:17:29 +0000
Subject: [issue25318] Add _PyBytesWriter API to optimize Unicode encoders
In-Reply-To: <1444046488.88.0.905297361267.issue25318@psf.upfronthosting.co.za>
Message-ID: <1444061849.35.0.621229334835.issue25318@psf.upfronthosting.co.za>


STINNER Victor added the comment:

My previous abandonned attempt was the issue #17742.

"Add _PyBytesWriter API to optimize Unicode encoders"

Oh, I forgot to mention and it may also be used to optimize bytes % args. More generally, any code generating a bytes object with an unknown length is advance. Said differently: _PyBytesWriter can be used when precomputing the output length is more expensive.

str % args now uses _PyUnicodeWriter but building an Unicode string is even more complex because of the different Unicode "kinds": 1, 2 or 4 bytes per character.

----------

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

From report at bugs.python.org  Mon Oct  5 18:23:44 2015
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 05 Oct 2015 16:23:44 +0000
Subject: [issue25316] distutils: broken error reporting about vcvarsall.bat
In-Reply-To: <1444029585.13.0.59398621181.issue25316@psf.upfronthosting.co.za>
Message-ID: <1444062224.7.0.439074050258.issue25316@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +steve.dower -eric.araujo

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

From report at bugs.python.org  Mon Oct  5 18:28:27 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 05 Oct 2015 16:28:27 +0000
Subject: [issue25304] Add run_coroutine_threadsafe() to asyncio
In-Reply-To: <1443885833.8.0.0767295795531.issue25304@psf.upfronthosting.co.za>
Message-ID: <1444062507.5.0.903139923626.issue25304@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

The docs look good. (I assume you've generated the HTML and checked that the output looks good, links are clickable etc.) What do you need to add to the concurrency and multithreading section?

I agree on the try/except; can you add that to the same diff? (Merging diffs into three different branches is a pain so I want to have to do as little as possible of it.)

----------

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

From report at bugs.python.org  Mon Oct  5 18:30:32 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 05 Oct 2015 16:30:32 +0000
Subject: [issue25294] Absolute imports fail in some cases where relative
 imports would work
In-Reply-To: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>
Message-ID: <1444062632.45.0.509504940006.issue25294@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I don't quite follow what you think is wrong with https://hg.python.org/cpython/file/tip/Lib/concurrent/futures/__init__.py . It looks totally fine to me.

And I should mention that you shouldn't follow PEP 8 like it's in stone and the only way to format code. The PEP is a set of guidelines only and not rules (this is a long-standing position of python-dev on PEP 8). For instance, I don't agree with the absolute import recommendation and do not follow it in my own code nor in importlib (it makes vendoring impossible without modifying the import statements).

I think the key thing to take away from this whole discussion is "don't have circular imports" is the key practice to follow. And if someone wants to propose a patch to update some documentation to point out that `from ... import ...` may work in some situations where `import ...; ... = ...` doesn't then I will personally review such a patch.

----------

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

From report at bugs.python.org  Mon Oct  5 18:30:49 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 05 Oct 2015 16:30:49 +0000
Subject: [issue23972] Asyncio reuseport
In-Reply-To: <1429185135.77.0.485030290106.issue23972@psf.upfronthosting.co.za>
Message-ID: <20151005163044.7262.23375@psf.io>


Roundup Robot added the comment:

New changeset 5e7e9b131904 by Guido van Rossum in branch '3.4':
Issue #23972: updates to asyncio datagram API. By Chris Laws.
https://hg.python.org/cpython/rev/5e7e9b131904

New changeset ba956289fe66 by Guido van Rossum in branch '3.5':
Issue #23972: updates to asyncio datagram API. By Chris Laws. (Merge 3.4->3.5.)
https://hg.python.org/cpython/rev/ba956289fe66

New changeset c0f1f882737c by Guido van Rossum in branch 'default':
Issue #23972: updates to asyncio datagram API. By Chris Laws. (Merge 3.5->3.6.)
https://hg.python.org/cpython/rev/c0f1f882737c

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Oct  5 18:33:28 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 05 Oct 2015 16:33:28 +0000
Subject: [issue23972] Asyncio reuseport
In-Reply-To: <1429185135.77.0.485030290106.issue23972@psf.upfronthosting.co.za>
Message-ID: <1444062808.41.0.948898384696.issue23972@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Thanks for the patch! It's live now. Closing. Watch the buildbots for me please!

----------
assignee:  -> gvanrossum
resolution:  -> fixed
status: open -> closed
versions: +Python 3.6

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

From report at bugs.python.org  Mon Oct  5 18:38:20 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 05 Oct 2015 16:38:20 +0000
Subject: [issue22413] Bizarre StringIO(newline="\r\n") translation
In-Reply-To: <1410750243.44.0.979805676788.issue22413@psf.upfronthosting.co.za>
Message-ID: <1444063100.36.0.58652618349.issue22413@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

The patch fails to apply in the 2.7 branch. It works in 3.4. Could you look into the 2.7 issue?

----------

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

From report at bugs.python.org  Mon Oct  5 18:39:58 2015
From: report at bugs.python.org (eryksun)
Date: Mon, 05 Oct 2015 16:39:58 +0000
Subject: [issue24505] shutil.which wrong result on Windows
In-Reply-To: <1435183779.2.0.13075721906.issue24505@psf.upfronthosting.co.za>
Message-ID: <1444063198.08.0.193016019963.issue24505@psf.upfronthosting.co.za>


eryksun added the comment:

Please don't default to searching the current directory:

    if is_windows:
        # The current directory takes precedence on Windows.
        if not os.curdir in path:
            path.insert(0, os.curdir)

Add a keyword option to enable this, with a warning that including the current directory isn't secure. This option should not be able to override the environment variable [NoDefaultCurrentDirectoryInExePath][1].

[1]: https://msdn.microsoft.com/en-us/library/ms684269

----------
components: +Windows
nosy: +eryksun, paul.moore, steve.dower, tim.golden, zach.ware
versions: +Python 3.6 -Python 3.5

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

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: [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  Mon Oct  5 18:50:42 2015
From: report at bugs.python.org (Vincent Michel)
Date: Mon, 05 Oct 2015 16:50:42 +0000
Subject: [issue25304] Add run_coroutine_threadsafe() to asyncio
In-Reply-To: <1443885833.8.0.0767295795531.issue25304@psf.upfronthosting.co.za>
Message-ID: <1444063842.9.0.00175516982773.issue25304@psf.upfronthosting.co.za>


Vincent Michel added the comment:

> The docs look good.

Should I add a note to explain why the loop argument has to be explicitly passed? (there is a note at the beginning of the `task functions` section stating "In the functions below, the optional loop argument ...")

> What do you need to add to the concurrency and multithreading section?

This section provides an example to schedule a coroutine from a different thread using `ensure_future` and `call_soon_threadsafe`. This example should be replaced with another usage of `call_soon_threadsafe` and another paragraph about `run_coroutine_threadsafe` should be added.

> I agree on the try/except

Do you think the exception should be re-raised for the logger?

> can you add that to the same diff? 

All right, should I make another PR on the asyncio github repo as well?

----------

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

From report at bugs.python.org  Mon Oct  5 18:55:55 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 05 Oct 2015 16:55:55 +0000
Subject: [issue25304] Add run_coroutine_threadsafe() to asyncio
In-Reply-To: <1444063842.9.0.00175516982773.issue25304@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJ+95cS9_Q5zipqq-Ma7gCnPcYoof-22dKwtJvRESyw4Pg@mail.gmail.com>


Guido van Rossum added the comment:

> Should I add a note to explain why the loop argument has to be explicitly
passed? (there is a note at the beginning of the `task functions` section
stating "In the functions below, the optional loop argument ...")

Oh, that's a good idea. It's sort of clear because it starts with "from a
different thread" but it doesn't hurt to say the same thing in different
ways, because it's an easy mistake to make.

>> What do you need to add to the concurrency and multithreading section?

> This section provides an example to schedule a coroutine from a different
thread using `ensure_future` and `call_soon_threadsafe`. This example
should be replaced with another usage of `call_soon_threadsafe` and another
paragraph about `run_coroutine_threadsafe` should be added.

Oh, yes, definitely update that!

> > I agree on the try/except
>
> Do you think the exception should be re-raised for the logger?
>

Yes.

> > can you add that to the same diff?
>
> All right, should I make another PR on the asyncio github repo as well?
>

No, it's easier for me to copy the changes from CPython into the asyncio
repo.

----------

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

From report at bugs.python.org  Mon Oct  5 18:59:10 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 05 Oct 2015 16:59:10 +0000
Subject: [issue25304] Add run_coroutine_threadsafe() to asyncio
In-Reply-To: <1443885833.8.0.0767295795531.issue25304@psf.upfronthosting.co.za>
Message-ID: <1444064350.95.0.369173594366.issue25304@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

>> Should I add a note to explain why the loop argument has to be explicitly
passed? (there is a note at the beginning of the `task functions` section
stating "In the functions below, the optional loop argument ...")

> Oh, that's a good idea. It's sort of clear because it starts with "from a
different thread" but it doesn't hurt to say the same thing in different
ways, because it's an easy mistake to make.

Can we make 'loop' a required argument (no default None value)?

----------

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

From report at bugs.python.org  Mon Oct  5 19:11:44 2015
From: report at bugs.python.org (Patrick Maupin)
Date: Mon, 05 Oct 2015 17:11:44 +0000
Subject: [issue25294] Absolute imports fail in some cases where relative
 imports would work
In-Reply-To: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>
Message-ID: <1444065104.49.0.886294230925.issue25294@psf.upfronthosting.co.za>


Patrick Maupin added the comment:

I don't think anything is wrong with that code.  But PEP 8 prescribes a way of doing something that often won't work (which is unusual for PEP 8), with no discussion of this fact.

> I think the key thing to take away from this whole discussion is "don't have circular imports" is the key practice to follow.

If this is a "key practice" then why the heck is the recommended way to do things the one that is guaranteed to break it?

I have empirical evidence that it is surprising to some users that the semantics of "from .z import foo" and "from x.y.z import foo" are not identical -- in other words, some of them have a hard time classifying the second as a circular import but not the first.  And the documentation is silent on this.

> And if someone wants to propose a patch to update some documentation

I'll try to get to this in the next couple of weeks.

Thanks,
Pat

----------

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

From report at bugs.python.org  Mon Oct  5 19:12:04 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 05 Oct 2015 17:12:04 +0000
Subject: [issue22413] Bizarre StringIO(newline="\r\n") translation
In-Reply-To: <1410750243.44.0.979805676788.issue22413@psf.upfronthosting.co.za>
Message-ID: <1444065124.24.0.673160480681.issue22413@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

It looks like we don't merge 2.7 into 3.4 any more, so that will have to be a separate patch anyway.

So you can commit the patch to 3.4, merge into 3.5 and 3.6. Good luck! And thanks for your perseverance.

----------

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

From report at bugs.python.org  Mon Oct  5 19:15:43 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 05 Oct 2015 17:15:43 +0000
Subject: [issue25304] Add run_coroutine_threadsafe() to asyncio
In-Reply-To: <1443885833.8.0.0767295795531.issue25304@psf.upfronthosting.co.za>
Message-ID: <1444065343.75.0.656977742605.issue25304@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

loop *is* required for this function. It's just that there's an earlier, general comment describing it as optional for all functions in this section.

----------

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

From report at bugs.python.org  Mon Oct  5 19:29:52 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 05 Oct 2015 17:29:52 +0000
Subject: [issue25316] distutils: broken error reporting about vcvarsall.bat
In-Reply-To: <1444029585.13.0.59398621181.issue25316@psf.upfronthosting.co.za>
Message-ID: <1444066192.2.0.92312789875.issue25316@psf.upfronthosting.co.za>


Steve Dower added the comment:

Do you have a full stack trace for that exception? I don't see anywhere that should be able to raise WinError in _find_vcvarsall.

----------

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

From report at bugs.python.org  Mon Oct  5 19:30:35 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 05 Oct 2015 17:30:35 +0000
Subject: [issue25316] distutils: broken error reporting about vcvarsall.bat
In-Reply-To: <1444029585.13.0.59398621181.issue25316@psf.upfronthosting.co.za>
Message-ID: <1444066235.67.0.12785634947.issue25316@psf.upfronthosting.co.za>


Steve Dower added the comment:

Ah, found it in the linked thread. I'll fix for 3.5.1.

----------

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

From report at bugs.python.org  Mon Oct  5 19:30:46 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 05 Oct 2015 17:30:46 +0000
Subject: [issue25316] distutils: broken error reporting about vcvarsall.bat
In-Reply-To: <1444029585.13.0.59398621181.issue25316@psf.upfronthosting.co.za>
Message-ID: <1444066246.46.0.856593690273.issue25316@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
assignee:  -> steve.dower
components: +Windows
keywords: +3.5regression
nosy: +eric.araujo, paul.moore, tim.golden, zach.ware

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

From report at bugs.python.org  Mon Oct  5 19:35:48 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 05 Oct 2015 17:35:48 +0000
Subject: [issue25316] distutils: broken error reporting about vcvarsall.bat
In-Reply-To: <1444029585.13.0.59398621181.issue25316@psf.upfronthosting.co.za>
Message-ID: <20151005173544.55476.27033@psf.io>


Roundup Robot added the comment:

New changeset a2016b29762c by Steve Dower in branch '3.5':
Issue #25316: distutils raises OSError instead of DistutilsPlatformError when MSVC is not installed.
https://hg.python.org/cpython/rev/a2016b29762c

New changeset 07161dd8a078 by Steve Dower in branch 'default':
Issue #25316: distutils raises OSError instead of DistutilsPlatformError when MSVC is not installed.
https://hg.python.org/cpython/rev/07161dd8a078

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Oct  5 19:35:59 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 05 Oct 2015 17:35:59 +0000
Subject: [issue25316] distutils: broken error reporting about vcvarsall.bat
In-Reply-To: <1444029585.13.0.59398621181.issue25316@psf.upfronthosting.co.za>
Message-ID: <1444066559.56.0.738703653236.issue25316@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Oct  5 19:45:08 2015
From: report at bugs.python.org (Serge Matveenko)
Date: Mon, 05 Oct 2015 17:45:08 +0000
Subject: [issue25315] OrderedDict mangled private attribute is inaccessible
In-Reply-To: <1444010587.49.0.504903152106.issue25315@psf.upfronthosting.co.za>
Message-ID: <1444067108.82.0.365915416094.issue25315@psf.upfronthosting.co.za>


Serge Matveenko added the comment:

Ok, then the OrderedDict is useless for any advanced hacking like altering the order in which __setitem__ stores items.

It is just useless Python code and so much appliances missed for this class:(

Thank you all for these completely helpful answers.

----------

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

From report at bugs.python.org  Mon Oct  5 19:53:31 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 05 Oct 2015 17:53:31 +0000
Subject: [issue25294] Absolute imports fail in some cases where relative
 imports would work
In-Reply-To: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>
Message-ID: <1444067611.63.0.465301215049.issue25294@psf.upfronthosting.co.za>


Brett Cannon added the comment:

You have to realize, Patrick, that the ability for `from ... import ...` to work in some situations that `import ...` won't is an age-old problem -- they are different at the bytecode level as well as how __import__ handles them -- and starting in Python 3.5 it got tweaked to potentially make the differences more pronounced by making a certain situation involving circular imports not trip users up as much where it was technically feasible to make the change without backwards-compatibility issues. It was a "practicality over purity" decision.

You also said that "PEP 8 prescribes a way of doing something that often won't work" which I disagree with. I think you're reading "absolute import" as synonymous with `import ...` which is not what the term means. In actuality, absolute imports means no leading dot in the name, e.g. `from .x import y` is a relative import while `from z.x import y` is an absolute one (as is `import z.x.y`). If you are using the term "absolute import" in the correct way then I still don't see how PEP 8 is suggesting any practice "that won't often work".

Circular imports are just plain hard to deal with. Due to the long-standing design of import being nothing more than syntactic sugar around exec() we don't get to know statically that a circular import is going to happen, so we can't error out early to tell the user that they *may* be in trouble. And not everyone gets themselves in a position where a circular import dependencies is a problem since it only causes issues when module-level code depends on each other in a circular way (which does include import statements which is where people typically trip themselves up when they get in this situation). I realize you're trying to do the right thing here and get the docs clarified to help newcomers out, but please realize it's just a difficult subject to explain succinctly, especially since a vast majority of people don't get themselves into a position where they have to deal with a circular import.

----------

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

From report at bugs.python.org  Mon Oct  5 20:22:43 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Oct 2015 18:22:43 +0000
Subject: [issue20981] ssl doesn't build anymore with OpenSSL 0.9.7 or older:
 X509_check_ca
In-Reply-To: <1395247121.79.0.24713590698.issue20981@psf.upfronthosting.co.za>
Message-ID: <1444069363.32.0.0550363497514.issue20981@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

For ancient OSes such as RHEL 4, I would suggest people request backports from the OS vendor if desired.

----------

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

From report at bugs.python.org  Mon Oct  5 20:26:46 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Oct 2015 18:26:46 +0000
Subject: [issue24505] shutil.which wrong result on Windows
In-Reply-To: <1435183779.2.0.13075721906.issue24505@psf.upfronthosting.co.za>
Message-ID: <1444069606.01.0.851056943167.issue24505@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, that's a newish situation for Windows, something I certainly wasn't aware of.  Which is trying to find the executable that would be found if typed at the prompt.  So, what is the correct algorithm for emulating how Windows does that search?  (Or some way to hook directly in to Windows search...)

----------

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

From report at bugs.python.org  Mon Oct  5 20:31:37 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Oct 2015 18:31:37 +0000
Subject: [issue25315] OrderedDict mangled private attribute is inaccessible
In-Reply-To: <1444010587.49.0.504903152106.issue25315@psf.upfronthosting.co.za>
Message-ID: <1444069897.55.0.134205349265.issue25315@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, that would be correct.  OrderedDict is designed to keep things in insertion order, so supporting changing that order is not part of its mission.  Sorry about that, you'll have to write your own class.

Now, Raymond might find the idea of supporting other orders interesting.  If so I'm sure he'll comment on the issue eventually.

----------

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

From report at bugs.python.org  Mon Oct  5 20:44:22 2015
From: report at bugs.python.org (Nir Soffer)
Date: Mon, 05 Oct 2015 18:44:22 +0000
Subject: [issue25319] Keep lock type when reseting internal locks
In-Reply-To: <1444051403.68.0.196001867236.issue25319@psf.upfronthosting.co.za>
Message-ID: <1444070662.26.0.942728925578.issue25319@psf.upfronthosting.co.za>


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


----------
nosy: +gregory.p.smith

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

From report at bugs.python.org  Mon Oct  5 20:47:24 2015
From: report at bugs.python.org (Nir Soffer)
Date: Mon, 05 Oct 2015 18:47:24 +0000
Subject: [issue25298] Add lock and rlock weakref tests
In-Reply-To: <1443779607.92.0.0397508107511.issue25298@psf.upfronthosting.co.za>
Message-ID: <1444070844.76.0.0476417498041.issue25298@psf.upfronthosting.co.za>


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


----------
nosy: +pitrou

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

From report at bugs.python.org  Mon Oct  5 20:55:25 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 05 Oct 2015 18:55:25 +0000
Subject: [issue25175] Documentation-Tkinter Clarify module spelling change in
 Python 3 docs
In-Reply-To: <1442656864.32.0.801468754438.issue25175@psf.upfronthosting.co.za>
Message-ID: <1444071325.43.0.710458863271.issue25175@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Oct  5 21:51:32 2015
From: report at bugs.python.org (Hristo Venev)
Date: Mon, 05 Oct 2015 19:51:32 +0000
Subject: [issue23609] Export PyModuleObject in moduleobject.h
In-Reply-To: <1425832317.75.0.265889084011.issue23609@psf.upfronthosting.co.za>
Message-ID: <1444074692.45.0.845001234507.issue23609@psf.upfronthosting.co.za>


Hristo Venev added the comment:

Quote from PEP 489:
The Py_mod_create slot is used to support custom module subclasses.

There is no way to subclass PyModuleObject from C.

----------
versions: +Python 3.5 -Python 3.4

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

From report at bugs.python.org  Mon Oct  5 21:58:56 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 05 Oct 2015 19:58:56 +0000
Subject: [issue24505] shutil.which wrong result on Windows
In-Reply-To: <1435183779.2.0.13075721906.issue24505@psf.upfronthosting.co.za>
Message-ID: <1444075136.28.0.336877578087.issue24505@psf.upfronthosting.co.za>


Steve Dower added the comment:

The Win32 API function linked by eryksun is the correct way to determine whether to include the current directory in the search - the doc specifically refers to matching cmd.exe's behaviour (searching ".;%PATH%" vs. just "%PATH%").

The PATHEXT behaviour should be to look for the name as provided first, followed be appending each extension. So looking for "python" will look for ["python", *("python" + p for p in getenv('PATHEXT').split(';'))] in that order.

----------

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

From report at bugs.python.org  Mon Oct  5 22:43:31 2015
From: report at bugs.python.org (eryksun)
Date: Mon, 05 Oct 2015 20:43:31 +0000
Subject: [issue24505] shutil.which wrong result on Windows
In-Reply-To: <1435183779.2.0.13075721906.issue24505@psf.upfronthosting.co.za>
Message-ID: <1444077811.17.0.968407586856.issue24505@psf.upfronthosting.co.za>


eryksun added the comment:

My suggestion is only for 3.5 / 3.6, because Windows XP is no longer supported. Starting with Windows Vista, both cmd.exe and CreateProcess support this behavior. I realize that disabling searching the current director by default is going beyond what cmd.exe does, which is to require opting in via the environment variable. But Python can choose to follow the more-modern behavior of PowerShell as a precedent here. 

As Steve mentioned, technically a program isn't supposed to check for the environment variable, but instead call NeedCurrentDirectoryForExePath. This would require either adding a built-in function, e.g. to the _winapi module, or require ctypes:

    >>> kernel32.NeedCurrentDirectoryForExePathW('command')
    1
    >>> os.environ['NoDefaultCurrentDirectoryInExePath'] = '1'
    >>> kernel32.NeedCurrentDirectoryForExePathW('command')
    0

Note that it requires first normalizing the path to replace slashes with backslashes, which is unusual for the Windows API.

    >>> kernel32.NeedCurrentDirectoryForExePathW(r'.\command')
    1
    >>> kernel32.NeedCurrentDirectoryForExePathW('./command')
    0

----------

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

From report at bugs.python.org  Mon Oct  5 23:05:42 2015
From: report at bugs.python.org (Patrick Maupin)
Date: Mon, 05 Oct 2015 21:05:42 +0000
Subject: [issue25294] Absolute imports fail in some cases where relative
 imports would work
In-Reply-To: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>
Message-ID: <1444079142.05.0.394464571167.issue25294@psf.upfronthosting.co.za>


Patrick Maupin added the comment:

You are correct that I have conflated two issues, but they are not orthogonal -- if you choose to use relative imports, you will never encounter this issue, because your imports will all be of the 'from ... import' form.

(And, as you point out, the fact that you don't have this issue with absolute "from ... import" statements is due to some special-casing in the import logic that doesn't help the other kind of import statement.)

But PEP 8 denigrates relative imports, and then goes on to describe the use of the "import x.y.z; x.y.z.foo" form as a way to avoid name clashes.

So PEP 8 promotes absolute imports, and then it presents using "import" instead of "from ... import" as a solution to some problems.  It never mentions that the 'as' clause could also solve those problems, and also never mentions that "import x.y.z" can actually cause problems in some cases.

And the importlib documentation is also a bit sparse on where things can fail.

We're in agreement that it will be difficult to document properly, and maybe I overstated my case, but my opinion remains that the current documentation promotes practices that _will_ sometimes get people in trouble.

----------

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

From report at bugs.python.org  Mon Oct  5 23:23:25 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Oct 2015 21:23:25 +0000
Subject: [issue25266] mako benchmark not working in Python 3.6
In-Reply-To: <1443525661.77.0.371661807917.issue25266@psf.upfronthosting.co.za>
Message-ID: <1444080205.82.0.899475770495.issue25266@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thanks, Brett and Florin!

----------

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

From report at bugs.python.org  Tue Oct  6 00:09:30 2015
From: report at bugs.python.org (Vincent Michel)
Date: Mon, 05 Oct 2015 22:09:30 +0000
Subject: [issue25304] Add run_coroutine_threadsafe() to asyncio
In-Reply-To: <1443885833.8.0.0767295795531.issue25304@psf.upfronthosting.co.za>
Message-ID: <1444082970.06.0.678805709296.issue25304@psf.upfronthosting.co.za>


Vincent Michel added the comment:

I attached a patch that should sum up all the points we discussed.

I replaced the `call_soon_threadsafe` example with:
  loop.call_soon_threadsafe(callback, *args)
cause I couldn't find a simple specific usage. Let me know if you think of a better example.

----------
Added file: http://bugs.python.org/file40691/run_coroutine_threadsafe_2.patch

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

From report at bugs.python.org  Tue Oct  6 00:34:55 2015
From: report at bugs.python.org (eryksun)
Date: Mon, 05 Oct 2015 22:34:55 +0000
Subject: [issue4926] putenv() accepts names containing '=',
 return value of unsetenv() not checked
In-Reply-To: <1231803037.62.0.52390349364.issue4926@psf.upfronthosting.co.za>
Message-ID: <1444084494.99.0.656211650259.issue4926@psf.upfronthosting.co.za>


eryksun added the comment:

AFAICT, on Windows using the posix_putenv_garbage dict is unnecessary. The Windows C runtime creates a private copy of the string, so there's no need to keep a reference. Moreover, since there's no unsetenv, deleting a variable is accomplished by calling putenv with an empty value, e.g. putenv('foo', ''). This leaks an item in posix_putenv_garbage, which is left set as ('foo', 'foo=').

----------
nosy: +eryksun
versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Oct  6 00:44:11 2015
From: report at bugs.python.org (shanmbic)
Date: Mon, 05 Oct 2015 22:44:11 +0000
Subject: [issue24954] No way to generate or parse timezone as produced by
 datetime.isoformat()
In-Reply-To: <1440801281.72.0.545558404714.issue24954@psf.upfronthosting.co.za>
Message-ID: <1444085051.47.0.826024187542.issue24954@psf.upfronthosting.co.za>


shanmbic added the comment:

Yeah , I agree that including '%:::z' might not be necessary at all . Including '%:z' and '%::z' format specifiers will give an upper edge to Python. Although , if not going with '%::z' or seconds offset, for now only '%:z' can be a valuable addition . 
I have rectified my code, corrected the indentations and have added cases , where it will also handle any strings of form '%:z' and '%::z' i.e. any character other than 'z' also raising exceptions for cases "%:" or "%::", where no character is specified (Invalid string).   
In case , if we only go with '%:z' format specifier , I will remove the code for '%::z'. 
P.S. I have filled the contributor agreement form. Thanks for the awesome help here. :)

----------
Added file: http://bugs.python.org/file40692/datetime2.patch

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

From report at bugs.python.org  Tue Oct  6 01:16:22 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 05 Oct 2015 23:16:22 +0000
Subject: [issue25304] Add run_coroutine_threadsafe() to asyncio
In-Reply-To: <1443885833.8.0.0767295795531.issue25304@psf.upfronthosting.co.za>
Message-ID: <1444086982.47.0.586798827296.issue25304@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I think it's fine. I'm going to commit this now. Thanks again!

----------

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

From report at bugs.python.org  Tue Oct  6 01:16:36 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 05 Oct 2015 23:16:36 +0000
Subject: [issue24954] No way to generate or parse timezone as produced by
 datetime.isoformat()
In-Reply-To: <1440801281.72.0.545558404714.issue24954@psf.upfronthosting.co.za>
Message-ID: <1444086996.29.0.153157832496.issue24954@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I think it is very likely that issue 5288 will result in at least seconds being allowed in UTC offsets in Python 3.6.  I am assuming that much in my PEP 495 work in issue 24773.

----------
nosy: +tim.peters

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

From report at bugs.python.org  Tue Oct  6 01:18:07 2015
From: report at bugs.python.org (Bar Harel)
Date: Mon, 05 Oct 2015 23:18:07 +0000
Subject: [issue24505] shutil.which wrong result on Windows
In-Reply-To: <1444077811.17.0.968407586856.issue24505@psf.upfronthosting.co.za>
Message-ID: <CAMsGuynYio8xBeA9OqeQHOdH2RJUgCZYQxz82afaXWc7HxnQUw@mail.gmail.com>


Bar Harel added the comment:

Thanks eryksun.

Regarding the slashes, it should be fine as the input should be with
backslashes anyway. We don't need to fix the input as fixing it would
result in inaccurate data. Just as it won't work without backslashes on
CMD, it shouldn't work here.

On Mon, Oct 5, 2015 at 11:43 PM eryksun <report at bugs.python.org> wrote:

>
> eryksun added the comment:
>
> My suggestion is only for 3.5 / 3.6, because Windows XP is no longer
> supported. Starting with Windows Vista, both cmd.exe and CreateProcess
> support this behavior. I realize that disabling searching the current
> director by default is going beyond what cmd.exe does, which is to require
> opting in via the environment variable. But Python can choose to follow the
> more-modern behavior of PowerShell as a precedent here.
>
> As Steve mentioned, technically a program isn't supposed to check for the
> environment variable, but instead call NeedCurrentDirectoryForExePath. This
> would require either adding a built-in function, e.g. to the _winapi
> module, or require ctypes:
>
>     >>> kernel32.NeedCurrentDirectoryForExePathW('command')
>     1
>     >>> os.environ['NoDefaultCurrentDirectoryInExePath'] = '1'
>     >>> kernel32.NeedCurrentDirectoryForExePathW('command')
>     0
>
> Note that it requires first normalizing the path to replace slashes with
> backslashes, which is unusual for the Windows API.
>
>     >>> kernel32.NeedCurrentDirectoryForExePathW(r'.\command')
>     1
>     >>> kernel32.NeedCurrentDirectoryForExePathW('./command')
>     0
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue24505>
> _______________________________________
>

----------

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

From report at bugs.python.org  Tue Oct  6 01:27:07 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 05 Oct 2015 23:27:07 +0000
Subject: [issue25304] Add run_coroutine_threadsafe() to asyncio
In-Reply-To: <1443885833.8.0.0767295795531.issue25304@psf.upfronthosting.co.za>
Message-ID: <20151005232703.2671.45400@psf.io>


Roundup Robot added the comment:

New changeset 54c77fdcdb2e by Guido van Rossum in branch '3.4':
Docs and one small improvement for issue #25304, by Vincent Michel.
https://hg.python.org/cpython/rev/54c77fdcdb2e

New changeset 28fcd7f13613 by Guido van Rossum in branch '3.5':
Docs and one small improvement for issue #25304, by Vincent Michel. (Merge 3.4->3.5.)
https://hg.python.org/cpython/rev/28fcd7f13613

New changeset cba27498a2f7 by Guido van Rossum in branch 'default':
Docs and one small improvement for issue #25304, by Vincent Michel. (Merge 3.5->3.6.)
https://hg.python.org/cpython/rev/cba27498a2f7

----------

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

From report at bugs.python.org  Tue Oct  6 01:27:47 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 05 Oct 2015 23:27:47 +0000
Subject: [issue25304] Add run_coroutine_threadsafe() to asyncio
In-Reply-To: <1443885833.8.0.0767295795531.issue25304@psf.upfronthosting.co.za>
Message-ID: <1444087667.15.0.140112392275.issue25304@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Thanks!

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Tue Oct  6 02:22:41 2015
From: report at bugs.python.org (Mark Roseman)
Date: Tue, 06 Oct 2015 00:22:41 +0000
Subject: [issue25313] IDLE: gracefully handle themes (or keysets,
 or ...) not present
In-Reply-To: <1443983028.38.0.330062493222.issue25313@psf.upfronthosting.co.za>
Message-ID: <1444090961.5.0.475586918758.issue25313@psf.upfronthosting.co.za>


Mark Roseman added the comment:

On a more direct note, have attached missingtheme.patch, which ensures that all queries for the active theme go through CurrentTheme(), which has been modified to verify that the theme exists; if not, it returns 'IDLE Classic'

----------
Added file: http://bugs.python.org/file40693/missingtheme.patch

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

From report at bugs.python.org  Tue Oct  6 02:42:57 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 06 Oct 2015 00:42:57 +0000
Subject: [issue22726] Idle: add help to config dialogs
In-Reply-To: <1414212383.94.0.847086482603.issue22726@psf.upfronthosting.co.za>
Message-ID: <1444092177.44.0.385921729125.issue22726@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This patch does two things: 1. restore the Help button and make it display something; 2. lower case the method names.  The latter is a separate issue, best done in a new file.  What is needed for #25313 is tab-specific text.

Also, now that Config Extenstion uses a list rather than tabs, it couldn be added as a tab to the main dialog, and only one set of button event handlers would be needed.  Tab-specific text would be needed first.

----------
nosy: +markroseman

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

From report at bugs.python.org  Tue Oct  6 03:12:10 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 06 Oct 2015 01:12:10 +0000
Subject: [issue25313] IDLE: gracefully handle themes (or keysets,
 or ...) not present
In-Reply-To: <1443983028.38.0.330062493222.issue25313@psf.upfronthosting.co.za>
Message-ID: <1444093930.61.0.851101222352.issue25313@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Schedule update: 3.4.4 will be delayed untill after 3.5.1, which will be much sooner than the original minimum of 4 months after 3.5.0.  Larry promises at least two weeks notice before 3.5.1rc1 but will give no hint of when notice might be given.  So we have at least two week to do something correct.

I am against duplicating names because it is wrong in principle.  On the other hand, I understand the objection to a popup always and forever.  It is past time anyway to enable a working [Help] button, #22726.  The current popup help text should go there as tab-specific text.  The only automatic notice on selecting a new builtin theme would be 'New theme, see Help', maybe in orange (warning color, but not emergency red ;-) added in the empty space below.

I believe one new 'name2 = new_theme' addition to config-main would be enough for future additions.  We add to configHandler 'new_themes, a set, currently {'IDLE Dark'}.  If a selected builtin is in the set, the message is displayed and name2 is written.  On reading, if name2 is present but not recognized, revert to IDLE Classic, which is present on all systems now.

Intended result: all IDLEs keep working, new releases get a minimally intrusive notice pointing to a full explanation.

----------

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

From report at bugs.python.org  Tue Oct  6 04:31:00 2015
From: report at bugs.python.org (chris laws)
Date: Tue, 06 Oct 2015 02:31:00 +0000
Subject: [issue23972] Asyncio reuseport
In-Reply-To: <1429185135.77.0.485030290106.issue23972@psf.upfronthosting.co.za>
Message-ID: <1444098660.53.0.958759611355.issue23972@psf.upfronthosting.co.za>


chris laws added the comment:

I've checked the Buildbot results and observed a few errors related to this change. Specifically the issues affect Windows and Debian.

Builder AMD64 Debian root 3.x build #2772 - http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.x/builds/2772
Builder AMD64 Windows7 SP1 3.x build #6808 - http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/6808

In test_create_datagram_endpoint_sock the Windows-based buildbot raises an error related to using sock.getsockname(). This issue has been observed before on Windows using Python.

Refs:
https://mail.python.org/pipermail/python-list/2015-January/683777.html
http://stackoverflow.com/questions/15638214/socket-error-invalid-argument-supplied

In this test the socket is not really used so I was trying to get away with minimal actions to set up the test. The suggested solution would be to bind the socket before using it in the test.

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind(('0.0.0.0', 0))


In test_create_datagram_endpoint_sockopts we can't use the (else clause at line 1310) because if SO_REUSEPORT is not defined it can not be used in a check. This affects Windows and Debian where SO_REUSEPORT is not defined.

From:
if reuseport_supported:
    self.assertTrue(
        sock.getsockopt(
            socket.SOL_SOCKET, socket.SO_REUSEPORT))
else:
    self.assertFalse(
        sock.getsockopt(
            socket.SOL_SOCKET, socket.SO_REUSEPORT))

To:

if reuseport_supported:
    self.assertTrue(
        sock.getsockopt(
            socket.SOL_SOCKET, socket.SO_REUSEPORT))

I'll submit a patch to resolve these issues later today.

----------

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

From report at bugs.python.org  Tue Oct  6 05:21:13 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 06 Oct 2015 03:21:13 +0000
Subject: [issue14373] C implementation of functools.lru_cache
In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za>
Message-ID: <1444101673.94.0.497858172366.issue14373@psf.upfronthosting.co.za>


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


----------
assignee: rhettinger -> 
status: pending -> open

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

From report at bugs.python.org  Tue Oct  6 05:45:50 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 06 Oct 2015 03:45:50 +0000
Subject: [issue1644818] Allow built-in packages and submodules as well as
 top-level modules
Message-ID: <1444103150.89.0.567152547168.issue1644818@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Petr, this could be an interesting issue to take a look at from the point of view of the builtin and extension module import changes in Python 3.5.

Given the extent of the import system changes across 3.3/4/5, it's even conceivable we may have made this work somewhere along the line. In that case we'd still need a new regression test to ensure it keeps working - we didn't even have a regression test to ensure extension module imports from inside a package worked, so we definitely don't have one for builtin submodules.

----------
nosy: +encukou

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

From report at bugs.python.org  Tue Oct  6 06:20:50 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 06 Oct 2015 04:20:50 +0000
Subject: [issue14373] C implementation of functools.lru_cache
In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za>
Message-ID: <1444105250.02.0.66022850828.issue14373@psf.upfronthosting.co.za>


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


----------
assignee:  -> serhiy.storchaka
status: open -> pending

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

From report at bugs.python.org  Tue Oct  6 06:39:23 2015
From: report at bugs.python.org (Mauro S. M. Rodrigues)
Date: Tue, 06 Oct 2015 04:39:23 +0000
Subject: [issue25024] Allow passing "delete=False" to TemporaryDirectory
In-Reply-To: <1441690580.39.0.270846340544.issue25024@psf.upfronthosting.co.za>
Message-ID: <1444106363.88.0.227322215075.issue25024@psf.upfronthosting.co.za>


Mauro S. M. Rodrigues added the comment:

Hi everybody!
This is my second patch on the community, although the first one is not merged, so any feedback is appreciated. 

I've added tests to cover this new situation and docs to let people know about the possibility of keeping their temporary directories for debugging purposes. 

Regarding the code itself, I've also made a 'design decision' to remove the directory even when created with delete=False if cleanup method is called explicitly, so I would like to hear your thoughts on that matter specially if you don't agree with it.

----------
keywords: +patch
nosy: +maurosr
Added file: http://bugs.python.org/file40694/TemporaryDirectory_delete_false.patch

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

From report at bugs.python.org  Tue Oct  6 07:01:40 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 06 Oct 2015 05:01:40 +0000
Subject: [issue25319] Keep lock type when reseting internal locks
In-Reply-To: <1444051403.68.0.196001867236.issue25319@psf.upfronthosting.co.za>
Message-ID: <20151006050136.20759.39202@psf.io>


Roundup Robot added the comment:

New changeset 69a26f0800b3 by Benjamin Peterson in branch '2.7':
reinitialize an Event's Condition with a regular lock (closes #25319)
https://hg.python.org/cpython/rev/69a26f0800b3

New changeset 6108d30dde21 by Benjamin Peterson in branch '3.4':
reinitialize an Event's Condition with a regular lock (closes #25319)
https://hg.python.org/cpython/rev/6108d30dde21

New changeset 3719e842a7b1 by Benjamin Peterson in branch '3.5':
merge 3.4 (#25319)
https://hg.python.org/cpython/rev/3719e842a7b1

New changeset 41f29bbf520d by Benjamin Peterson in branch 'default':
merge 3.5 (#25319)
https://hg.python.org/cpython/rev/41f29bbf520d

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

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: [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 07:57:41 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 06 Oct 2015 05:57:41 +0000
Subject: [issue25321] Null Dereference  "subname" in zipimport.c
In-Reply-To: <1444110436.55.0.477379741136.issue25321@psf.upfronthosting.co.za>
Message-ID: <1444111061.82.0.235240442832.issue25321@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I don't think get_subname can return NULL.

----------

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

From report at bugs.python.org  Tue Oct  6 10:00:06 2015
From: report at bugs.python.org (chris laws)
Date: Tue, 06 Oct 2015 08:00:06 +0000
Subject: [issue23972] Asyncio reuseport
In-Reply-To: <1429185135.77.0.485030290106.issue23972@psf.upfronthosting.co.za>
Message-ID: <1444118406.51.0.575638499926.issue23972@psf.upfronthosting.co.za>


chris laws added the comment:

This patch contains minor updates to resolve the Buildbot issues observed on the Windows and Debian platforms after the initial #23972 change set was committed.

----------
Added file: http://bugs.python.org/file40696/23972_cjl_v006.patch

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

From report at bugs.python.org  Tue Oct  6 10:42:22 2015
From: report at bugs.python.org (Radek Novacek)
Date: Tue, 06 Oct 2015 08:42:22 +0000
Subject: [issue21295] Python 3.4 gives wrong col_offset for Call nodes
 returned from ast.parse
In-Reply-To: <1397818180.59.0.739018200129.issue21295@psf.upfronthosting.co.za>
Message-ID: <1444120942.7.0.850849402448.issue21295@psf.upfronthosting.co.za>


Radek Novacek added the comment:

There is still problem with col_offset is some situations, for example col_offset of the ast.Attribute should be 4 but is 0 instead:

>>> for x in ast.walk(ast.parse('foo.bar')):
...     if hasattr(x, 'col_offset'):
...         print("%s: %d" % (x, x.col_offset))
... 
<_ast.Expr object at 0x7fcdc84722b0>: 0
<_ast.Attribute object at 0x7fcdc84723c8>: 0
<_ast.Name object at 0x7fcdc8472438>: 0

Is there any solution to this problem? It causes problems in python support in KDevelop (kdev-python).

----------

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

From report at bugs.python.org  Tue Oct  6 11:00:15 2015
From: report at bugs.python.org (Aivar Annamaa)
Date: Tue, 06 Oct 2015 09:00:15 +0000
Subject: [issue21295] Python 3.4 gives wrong col_offset for Call nodes
 returned from ast.parse
In-Reply-To: <1397818180.59.0.739018200129.issue21295@psf.upfronthosting.co.za>
Message-ID: <1444122015.74.0.988322416882.issue21295@psf.upfronthosting.co.za>


Aivar Annamaa added the comment:

Radek, the source corresponding to Attribute node does start at col 0 in your example

----------

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

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: [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:26:27 2015
From: report at bugs.python.org (Erik Cederstrand)
Date: Tue, 06 Oct 2015 10:26:27 +0000
Subject: [issue12006] strptime should implement %G, %V and %u directives
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1444127187.19.0.693226234178.issue12006@psf.upfronthosting.co.za>


Erik Cederstrand added the comment:

I have reviewed the latest patch, and it looks good to me. There are tests for the tricky conversions around Jan 1, and the docs are brief and succinct. Until the full set of new c99 strftime directives are supported, I think it's overkill to include a lecture about the origin of these new directives and their support in the underlying OS.

There are a number of foot-shooting possibilities when parsing date strings with the directives supported by strptime(), but at least this patch does not make it worse. It validates the input nicely when using the new directives and prints useful error messages it input is ambiguous.

I'm not a committer, but I approve of the patch as-is.

----------

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

From report at bugs.python.org  Tue Oct  6 12:37:16 2015
From: report at bugs.python.org (Radek Novacek)
Date: Tue, 06 Oct 2015 10:37:16 +0000
Subject: [issue21295] Python 3.4 gives wrong col_offset for Call nodes
 returned from ast.parse
In-Reply-To: <1397818180.59.0.739018200129.issue21295@psf.upfronthosting.co.za>
Message-ID: <1444127836.49.0.0872176787389.issue21295@psf.upfronthosting.co.za>


Radek Novacek added the comment:

Aivar, I have to admit that my knowledge of this is limited, but as I understand it, the attribute is "bar" in the "foo.bar" expression.

I can get beginning of the assignment by 
>>> ast.parse('foo.bar').body[0].value.value.col_offset
0

But how can I get position of the 'bar'? My guess is this:
>>> ast.parse('foo.bar').body[0].value.col_offset
but it still returns 0.

Why this two col_offsets returns the same value? How can I get the position of 'bar' in 'foo.bar'?

----------

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

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: [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 12:56:59 2015
From: report at bugs.python.org (Aivar Annamaa)
Date: Tue, 06 Oct 2015 10:56:59 +0000
Subject: [issue21295] Python 3.4 gives wrong col_offset for Call nodes
 returned from ast.parse
In-Reply-To: <1397818180.59.0.739018200129.issue21295@psf.upfronthosting.co.za>
Message-ID: <1444129018.99.0.0687907360799.issue21295@psf.upfronthosting.co.za>


Aivar Annamaa added the comment:

ast.Attribute node actually means "the atribute of something", ie. the node includes this "something" as subnode. 

> How can I get the position of 'bar' in 'foo.bar'?

I don't know a good way for this, because bar is not an AST node for Python. If Python AST nodes included the information about where a node ends in source, I would take the ending col of node.value (foo in your example), and added 2. 

In my own program (http://thonny.cs.ut.ee, it's a Python IDE for beginners) I'm using a really contrived algorithm for determining the end positions of nodes. See function mark_text_ranges here: https://bitbucket.org/plas/thonny/src/b8860704c99d47760ffacfaa335d2f8772721ba4/thonny/ast_utils.py?at=master&fileviewer=file-view-default

I'm not happy with my solution, but I don't know any other ways.

----------

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

From report at bugs.python.org  Tue Oct  6 14:12:07 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Oct 2015 12:12:07 +0000
Subject: [issue25323] Bus error: 10 when executing recursive program
In-Reply-To: <1444128171.82.0.123240917074.issue25323@psf.upfronthosting.co.za>
Message-ID: <1444133527.36.0.083553232453.issue25323@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Well, Python tries to protect you against stack overflow, but the protection is not perfect. You may have to enlarge the C stack, but I don't know how.

Workaround: try to rewrite your algorithm to use a lower recursion depth.

----------
nosy: +haypo

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

From report at bugs.python.org  Tue Oct  6 14:36:33 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Oct 2015 12:36:33 +0000
Subject: [issue25323] Bus error: 10 when executing recursive program
In-Reply-To: <1444128171.82.0.123240917074.issue25323@psf.upfronthosting.co.za>
Message-ID: <1444134993.61.0.0407498261058.issue25323@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> You may have to enlarge the C stack

The following might work (e.g., in bash shell)

    ulimit -s 60000

Here the count is in KiB, so that's setting a stack size of about 58.6 MiB.  There appears to be a system-wide limit of close to 64 MiB, so pushing past that could be hard.

Regardless, this isn't really a Python bug: the recursion limit is a safeguard that's there precisely to stop you from running into a hard crash.  If you remove that safeguard (especially without increasing your process stack size), you shouldn't be surprised to get a crash.

As Victor says, you probably need to rework your algorithm.

Suggest closing as "wont fix".

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Tue Oct  6 14:39:12 2015
From: report at bugs.python.org (Florin Papa)
Date: Tue, 06 Oct 2015 12:39:12 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1444135152.23.0.56762129497.issue25300@psf.upfronthosting.co.za>


Florin Papa added the comment:

Hi all,

I added LDFLAGS_NODIST in order to avoid distutils problems. Please see the updated patches.

Thank you,
Florin

----------
type: enhancement -> security
Added file: http://bugs.python.org/file40697/mpx_enable_3_6_v3.patch

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

From report at bugs.python.org  Tue Oct  6 14:39:23 2015
From: report at bugs.python.org (Florin Papa)
Date: Tue, 06 Oct 2015 12:39:23 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1444135163.45.0.774827041215.issue25300@psf.upfronthosting.co.za>


Changes by Florin Papa <florin.papa at intel.com>:


Added file: http://bugs.python.org/file40698/mpx_enable_2_7_v3.patch

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

From report at bugs.python.org  Tue Oct  6 15:04:37 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 06 Oct 2015 13:04:37 +0000
Subject: [issue25322] contextlib.suppress not tested for nested usage
In-Reply-To: <1444123306.69.0.0149294325224.issue25322@psf.upfronthosting.co.za>
Message-ID: <1444136677.55.0.263815233542.issue25322@psf.upfronthosting.co.za>


R. David Murray added the comment:

Hah.  I predicted this thing was going to attract bug reports :)

The behavior you observe is how context managers in general and this one in particular work.  I'll let Nick explain it, since he wrote it.  Maybe there is an doc improvement that would help.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Tue Oct  6 15:08:31 2015
From: report at bugs.python.org (Frazer McLean)
Date: Tue, 06 Oct 2015 13:08:31 +0000
Subject: [issue25322] contextlib.suppress not tested for nested usage
In-Reply-To: <1444123306.69.0.0149294325224.issue25322@psf.upfronthosting.co.za>
Message-ID: <1444136911.14.0.309468746877.issue25322@psf.upfronthosting.co.za>


Frazer McLean added the comment:

I may not have been clear?I understand how context managers work with exceptions.

I'm just pointing out that the nested context manager isn't called, so those final two lines aren't testing anything, right?

----------

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

From report at bugs.python.org  Tue Oct  6 15:25:55 2015
From: report at bugs.python.org (eryksun)
Date: Tue, 06 Oct 2015 13:25:55 +0000
Subject: [issue25323] Bus error: 10 when executing recursive program
In-Reply-To: <1444128171.82.0.123240917074.issue25323@psf.upfronthosting.co.za>
Message-ID: <1444137955.04.0.986485820438.issue25323@psf.upfronthosting.co.za>


eryksun added the comment:

I don't know about OS X, but in 64-bit Linux I can increase the recursion limit to 100000 if I allow the main thread to grow to 64 MiB by setting the RLIMIT_STACK soft limit. For example:

    soft, hard = resource.getrlimit(resource.RLIMIT_STACK)
    soft = max(soft, 64 << 20)
    if hard != resource.RLIM_INFINITY:
        soft = min(soft, hard)
    resource.setrlimit(resource.RLIMIT_STACK, (soft, hard))

Alternatively it also works to use a worker thread with a fixed 64 MiB stack size, set as follows:

    old_size = threading.stack_size(64 << 20)
    # create worker thread
    threading.stack_size(old_size)

----------
nosy: +eryksun

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

From report at bugs.python.org  Tue Oct  6 15:26:51 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 06 Oct 2015 13:26:51 +0000
Subject: [issue25322] contextlib.suppress not tested for nested usage
In-Reply-To: <1444123306.69.0.0149294325224.issue25322@psf.upfronthosting.co.za>
Message-ID: <1444138011.23.0.888963819285.issue25322@psf.upfronthosting.co.za>


R. David Murray added the comment:

Oh, I didn't read your message carefully enough. But that makes this bug report even more ironic.

----------

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

From report at bugs.python.org  Tue Oct  6 16:09:11 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Oct 2015 14:09:11 +0000
Subject: [issue23543] encoding error trying to save string to file
In-Reply-To: <1425071599.87.0.548743835483.issue23543@psf.upfronthosting.co.za>
Message-ID: <1444140551.76.0.883947588893.issue23543@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Indeed, the name that looks as ASCII actually contains non-ASCII characters.

>>> print(ascii('LKC.6558?100?HD?P?101_C.xlsx\n'))
'LKC.6558\u2010100\u2010HD\u2010P\u2010101_C.xlsx\n'

Martin suggests correct solution.

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: crash -> behavior

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

From report at bugs.python.org  Tue Oct  6 16:53:11 2015
From: report at bugs.python.org (Laura Creighton)
Date: Tue, 06 Oct 2015 14:53:11 +0000
Subject: [issue25157] Installing Python 3.5.0 32bit on Windows 8.1 64bit
 system gives Error 0x80240017
In-Reply-To: <1442526643.4.0.412457342038.issue25157@psf.upfronthosting.co.za>
Message-ID: <1444143191.97.0.131010191102.issue25157@psf.upfronthosting.co.za>


Laura Creighton added the comment:

Got another log of an Error 0x802400

This is a windows 7 user reporting it to webmaster.

----------
Added file: http://bugs.python.org/file40699/bad_win7_install_log.txt

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

From report at bugs.python.org  Tue Oct  6 17:25:58 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 06 Oct 2015 15:25:58 +0000
Subject: [issue23972] Asyncio reuseport
In-Reply-To: <1429185135.77.0.485030290106.issue23972@psf.upfronthosting.co.za>
Message-ID: <20151006152549.2685.94797@psf.io>


Roundup Robot added the comment:

New changeset aebbf205ef6f by Guido van Rossum in branch '3.4':
Issue #23972: Fix tests for Windows and Debian.
https://hg.python.org/cpython/rev/aebbf205ef6f

New changeset 4d643c5df2a5 by Guido van Rossum in branch '3.5':
Issue #23972: Fix tests for Windows and Debian. (Merge 3.4->3.5)
https://hg.python.org/cpython/rev/4d643c5df2a5

New changeset 3e2218a4e629 by Guido van Rossum in branch 'default':
Issue #23972: Fix tests for Windows and Debian. (Merge 3.5->3.6)
https://hg.python.org/cpython/rev/3e2218a4e629

----------

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

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: [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 17:39:00 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Oct 2015 15:39:00 +0000
Subject: [issue25324] Importing tokenize modifies token
In-Reply-To: <1444145798.79.0.176080140328.issue25324@psf.upfronthosting.co.za>
Message-ID: <1444145940.25.0.137900178094.issue25324@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I agree :-) Do you want to work on a patch?

----------
nosy: +haypo

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

From report at bugs.python.org  Tue Oct  6 17:54:00 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 06 Oct 2015 15:54:00 +0000
Subject: [issue25317] Convert test_tokenize to unittests
In-Reply-To: <1444037877.91.0.0285113512794.issue25317@psf.upfronthosting.co.za>
Message-ID: <20151006155346.20759.87234@psf.io>


Roundup Robot added the comment:

New changeset 7b2af8ee6dfa by Serhiy Storchaka in branch '2.7':
Issue #25317: Converted doctests in test_tokenize to unittests.
https://hg.python.org/cpython/rev/7b2af8ee6dfa

New changeset d272f3cbae05 by Serhiy Storchaka in branch '3.4':
Issue #25317: Converted doctests in test_tokenize to unittests.
https://hg.python.org/cpython/rev/d272f3cbae05

New changeset bff40616d2a5 by Serhiy Storchaka in branch '3.5':
Issue #25317: Converted doctests in test_tokenize to unittests.
https://hg.python.org/cpython/rev/bff40616d2a5

New changeset 66d239660997 by Serhiy Storchaka in branch 'default':
Issue #25317: Converted doctests in test_tokenize to unittests.
https://hg.python.org/cpython/rev/66d239660997

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Oct  6 17:55:15 2015
From: report at bugs.python.org (Pathangi Jatinshravan)
Date: Tue, 06 Oct 2015 15:55:15 +0000
Subject: [issue25228] Regression in cookie parsing with brackets and quotes
In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za>
Message-ID: <1444146915.69.0.228185047478.issue25228@psf.upfronthosting.co.za>


Pathangi Jatinshravan added the comment:

Hi I have made a patch for this, can anyone review and let me know?

----------
versions:  -Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40700/patch.diff

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

From report at bugs.python.org  Tue Oct  6 17:56:23 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Oct 2015 15:56:23 +0000
Subject: [issue25317] Convert test_tokenize to unittests
In-Reply-To: <1444037877.91.0.0285113512794.issue25317@psf.upfronthosting.co.za>
Message-ID: <1444146983.22.0.0585912986618.issue25317@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Oct  6 18:01:07 2015
From: report at bugs.python.org (Pathangi Jatinshravan)
Date: Tue, 06 Oct 2015 16:01:07 +0000
Subject: [issue25228] Regression in cookie parsing with brackets and quotes
In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za>
Message-ID: <1444147267.16.0.350479493433.issue25228@psf.upfronthosting.co.za>


Pathangi Jatinshravan added the comment:

Oops, sorry looks like a unit test is failing. I will fix it and submit another one soon.

----------

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

From report at bugs.python.org  Tue Oct  6 18:21:12 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 06 Oct 2015 16:21:12 +0000
Subject: [issue25157] Installing Python 3.5.0 32bit on Windows 8.1 64bit
 system gives Error 0x80240017
In-Reply-To: <1442526643.4.0.412457342038.issue25157@psf.upfronthosting.co.za>
Message-ID: <1444148472.41.0.967688382356.issue25157@psf.upfronthosting.co.za>


Steve Dower added the comment:

The new log looks like Win7 SP1 is needed.

I suspect in the original case there was some other update that was required as well, but I don't know what it was. The prerequisites are the latest service packs for Win7/WinS2K8 and earlier, and https://support.microsoft.com/en-us/kb/2919355 for Win8 and later (found on https://support.microsoft.com/en-us/kb/2999226).

I'll see if I can easily detect these requirements in setup. I need to add detection for WinXP anyway, so these are a logical extension.

----------
assignee:  -> steve.dower

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

From report at bugs.python.org  Tue Oct  6 18:23:45 2015
From: report at bugs.python.org (Shirshendu Bhowmick)
Date: Tue, 06 Oct 2015 16:23:45 +0000
Subject: [issue25157] Installing Python 3.5.0 32bit on Windows 8.1 64bit
 system gives Error 0x80240017
In-Reply-To: <1442526643.4.0.412457342038.issue25157@psf.upfronthosting.co.za>
Message-ID: <1444148625.01.0.634179409269.issue25157@psf.upfronthosting.co.za>


Shirshendu Bhowmick added the comment:

I have tried downloading and installing the updates from Microsoft, but the system said that the updates are already installed.

----------

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

From report at bugs.python.org  Tue Oct  6 18:26:35 2015
From: report at bugs.python.org (Pathangi Jatinshravan)
Date: Tue, 06 Oct 2015 16:26:35 +0000
Subject: [issue25228] Regression in cookie parsing with brackets and quotes
In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za>
Message-ID: <1444148795.68.0.564317559741.issue25228@psf.upfronthosting.co.za>


Pathangi Jatinshravan added the comment:

Hi Tim, I have submitted a patch for this issue (patch_final.diff, the earlier one failed a UT). Now all UTs are passing. Can you take a look at this?

----------
Added file: http://bugs.python.org/file40701/patch_final.diff

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

From report at bugs.python.org  Tue Oct  6 18:36:42 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 06 Oct 2015 16:36:42 +0000
Subject: [issue25157] Installing Python 3.5.0 32bit on Windows 8.1 64bit
 system gives Error 0x80240017
In-Reply-To: <1442526643.4.0.412457342038.issue25157@psf.upfronthosting.co.za>
Message-ID: <1444149402.11.0.331925462144.issue25157@psf.upfronthosting.co.za>


Steve Dower added the comment:

Do you still get the same error from the Python installer?

----------

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

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: [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:39:18 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Oct 2015 16:39:18 +0000
Subject: [issue25324] Importing tokenize modifies token
In-Reply-To: <1444145798.79.0.176080140328.issue25324@psf.upfronthosting.co.za>
Message-ID: <1444149558.87.0.67932852544.issue25324@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I left the decision for modules maintainers.

----------

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

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: [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 18:46:13 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 06 Oct 2015 16:46:13 +0000
Subject: [issue25326] Improve error message for "character buffer objects"
Message-ID: <1444149973.59.0.309061962173.issue25326@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Python 2.7.10+ (2.7:fc6d62db8d42+, Oct  6 2015, 11:55:10) 
[GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.72)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> s = 'the tale of two cities'
>>> s.count(('a', 'z'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: expected a character buffer object (such as a string)

   new text ---------------------------------^^^^^^^^^^^^^^^^^^^

----------

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

From report at bugs.python.org  Tue Oct  6 19:02:11 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 06 Oct 2015 17:02:11 +0000
Subject: [issue25326] Improve error message for "character buffer objects"
In-Reply-To: <1444149973.59.0.309061962173.issue25326@psf.upfronthosting.co.za>
Message-ID: <1444150931.53.0.231286173291.issue25326@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Another alternative
-------------------

TypeError: expected a string or other character buffer object

----------

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

From report at bugs.python.org  Tue Oct  6 19:04:23 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Oct 2015 17:04:23 +0000
Subject: [issue13348] test_unicode_file fails: shutil.copy2 says "same file"
In-Reply-To: <1320490682.69.0.905628343655.issue13348@psf.upfronthosting.co.za>
Message-ID: <1444151063.0.0.837640175152.issue13348@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
status: open -> pending

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

From report at bugs.python.org  Tue Oct  6 19:09:45 2015
From: report at bugs.python.org (Tim Graham)
Date: Tue, 06 Oct 2015 17:09:45 +0000
Subject: [issue25228] Regression in cookie parsing with brackets and quotes
In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za>
Message-ID: <1444151385.39.0.106443082204.issue25228@psf.upfronthosting.co.za>


Tim Graham added the comment:

Could you please integrate my unit test into your patch?

You also need to sign the PSF Contributor Agreement:
https://www.python.org/psf/contrib/contrib-form/

----------

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

From report at bugs.python.org  Tue Oct  6 19:21:01 2015
From: report at bugs.python.org (eryksun)
Date: Tue, 06 Oct 2015 17:21:01 +0000
Subject: [issue25157] Installing Python 3.5.0 32bit on Windows 8.1 64bit
 system gives Error 0x80240017
In-Reply-To: <1442526643.4.0.412457342038.issue25157@psf.upfronthosting.co.za>
Message-ID: <1444152061.97.0.984604094521.issue25157@psf.upfronthosting.co.za>


eryksun added the comment:

Error code WU_E_NOT_APPLICABLE (0x80240017) just tells us that "there are no applicable updates". Perhaps the Windows Update log has more information. 

Shirshendu, try directly installing the [Universal CRT update][1] from the command prompt. Run it with the /log option, e.g.

    Windows8.1-KB2999226-x64.msu /log:kb2999226.evtx

You can view this log in the Windows event viewer, or convert it to text XML on the command line as follows:

    wevtutil qe kb2999226.evtx /lf:true /f:XML /e:MSULog > kb2999226.xml

If the update fails, please attach the XML log to this issue. 

[1]: http://www.microsoft.com/en-us/download/details.aspx?id=48234

----------
nosy: +eryksun

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

From report at bugs.python.org  Tue Oct  6 19:21:03 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Oct 2015 17:21:03 +0000
Subject: [issue13535] Improved two's complement arithmetic support:
 to_signed() and to_unsigned()
In-Reply-To: <1323132574.65.0.0748252638501.issue13535@psf.upfronthosting.co.za>
Message-ID: <1444152063.72.0.915836440505.issue13535@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm for closing this issue. This is not the common operation.

----------
nosy: +serhiy.storchaka
status: open -> pending

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

From report at bugs.python.org  Tue Oct  6 19:30:06 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 06 Oct 2015 17:30:06 +0000
Subject: [issue12006] strptime should implement %G, %V and %u directives
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <20151006173002.7236.34572@psf.io>


Roundup Robot added the comment:

New changeset acdebfbfbdcf by Alexander Belopolsky in branch 'default':
Closes issue #12006: Add ISO 8601 year, week, and day directives to strptime.
https://hg.python.org/cpython/rev/acdebfbfbdcf

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Oct  6 19:32:47 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 06 Oct 2015 17:32:47 +0000
Subject: [issue12006] strptime should implement %G, %V and %u directives
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1444152767.39.0.130238708163.issue12006@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I've committed the latest patch.  Thank you Ashley and Erik for your work and perseverance.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Oct  6 19:37:22 2015
From: report at bugs.python.org (Pathangi Jatinshravan)
Date: Tue, 06 Oct 2015 17:37:22 +0000
Subject: [issue25228] Regression in cookie parsing with brackets and quotes
In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za>
Message-ID: <1444153042.0.0.132569355854.issue25228@psf.upfronthosting.co.za>


Pathangi Jatinshravan added the comment:

Added a patch where unit test has been modified to include the above case. I have signed the agreement.

----------
Added file: http://bugs.python.org/file40703/patch_unittest.diff

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

From report at bugs.python.org  Tue Oct  6 19:40:24 2015
From: report at bugs.python.org (Shirshendu Bhowmick)
Date: Tue, 06 Oct 2015 17:40:24 +0000
Subject: [issue25157] Installing Python 3.5.0 32bit on Windows 8.1 64bit
 system gives Error 0x80240017
In-Reply-To: <1442526643.4.0.412457342038.issue25157@psf.upfronthosting.co.za>
Message-ID: <1444153224.52.0.307717486213.issue25157@psf.upfronthosting.co.za>


Shirshendu Bhowmick added the comment:

Yes still the same error, even i have tried on a different system with different configurations running Windows 8.1 there is also i faced the same error.

----------

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

From report at bugs.python.org  Tue Oct  6 19:41:05 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Oct 2015 17:41:05 +0000
Subject: [issue14126] Speed up list comprehensions by preallocating the list
 where possible
In-Reply-To: <1330212567.11.0.0699848649478.issue14126@psf.upfronthosting.co.za>
Message-ID: <1444153265.9.0.629547734084.issue14126@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
status: open -> pending
versions: +Python 3.6 -Python 3.3

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

From report at bugs.python.org  Tue Oct  6 19:44:14 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Oct 2015 17:44:14 +0000
Subject: [issue12346] Python source code build fails with old mercurial
In-Reply-To: <1308212064.93.0.160132143903.issue12346@psf.upfronthosting.co.za>
Message-ID: <1444153454.68.0.795102764009.issue12346@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
status: open -> pending

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

From report at bugs.python.org  Tue Oct  6 19:55:39 2015
From: report at bugs.python.org (Tim Graham)
Date: Tue, 06 Oct 2015 17:55:39 +0000
Subject: [issue25228] Regression in cookie parsing with brackets and quotes
In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za>
Message-ID: <1444154139.62.0.235850885966.issue25228@psf.upfronthosting.co.za>


Tim Graham added the comment:

I had already proposed a test, see cookie-bracket-quotes-test.diff. What I meant was that the fix and the test should be combined into a single patch.

----------

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

From report at bugs.python.org  Tue Oct  6 20:01:42 2015
From: report at bugs.python.org (eryksun)
Date: Tue, 06 Oct 2015 18:01:42 +0000
Subject: [issue25325] UTF-16LE, UTF-16BE, UTF-32LE,
 and UTF-32BE encodings don't add/remove BOM on encode/decode
In-Reply-To: <1444149549.66.0.600836718737.issue25325@psf.upfronthosting.co.za>
Message-ID: <1444154502.09.0.481790777725.issue25325@psf.upfronthosting.co.za>


eryksun added the comment:

Yes, if you explicitly use big-ending or little-endian UTF, then you need to manually include a BOM if that's required. That said, if a file format or data field is specified with a particular byte order, then using a BOM is strictly incorrect. See the UTF BOM FAQ:

    http://www.unicode.org/faq/utf_bom.html#BOM

For regular text documents, in which the byte order doesn't really matter, use the native byte order of your platform via UTF-16 or UTF-32. Also, instead of manually encoding strings, use the "encoding" parameter of the built-in open function, or io.open or codecs.open in Python 2. This only writes a single BOM, even when writing to a file multiple times.

----------
nosy: +eryksun
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Oct  6 20:14:50 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 06 Oct 2015 18:14:50 +0000
Subject: [issue25325] UTF-16LE, UTF-16BE, UTF-32LE,
 and UTF-32BE encodings don't add/remove BOM on encode/decode
In-Reply-To: <1444149549.66.0.600836718737.issue25325@psf.upfronthosting.co.za>
Message-ID: <1444155290.16.0.0243657829179.issue25325@psf.upfronthosting.co.za>


R. David Murray added the comment:

eryksun beat me to the answer, but I'm going to post mine anyway :)

If I understand the codecs docs correctly, this is because if you are specifying the endianess you want, it is a sign that you are only going to interpret it as that endianness, so there's no need for a BOM.  If you want a BOM, use utf-16/32.

In short, what is your use case for producing a UTF string with non-native byte order?  But as eryksun said, the Python supported way to do that and include a BOM is to write the BOM yourself.

----------
nosy: +lemburg, r.david.murray -eryksun
resolution: not a bug -> 
stage: resolved -> 
status: closed -> open

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

From report at bugs.python.org  Tue Oct  6 20:16:32 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 06 Oct 2015 18:16:32 +0000
Subject: [issue25325] UTF-16LE, UTF-16BE, UTF-32LE,
 and UTF-32BE encodings don't add/remove BOM on encode/decode
In-Reply-To: <1444149549.66.0.600836718737.issue25325@psf.upfronthosting.co.za>
Message-ID: <1444155392.03.0.94754926014.issue25325@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Tue Oct  6 20:16:38 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 06 Oct 2015 18:16:38 +0000
Subject: [issue25325] UTF-16LE, UTF-16BE, UTF-32LE,
 and UTF-32BE encodings don't add/remove BOM on encode/decode
In-Reply-To: <1444149549.66.0.600836718737.issue25325@psf.upfronthosting.co.za>
Message-ID: <1444155398.41.0.93500784967.issue25325@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> resolved

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

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


Daniel Blanchard added the comment:

Thanks for straightening me out there! I had not noticed this in the Unicode FAQ before:

>  Where the data has an associated type, such as a field in a database, a BOM is unnecessary. In particular, if a text data stream is marked as UTF-16BE, UTF-16LE, UTF-32BE or UTF-32LE, a BOM is neither necessary nor permitted. Any U+FEFF would be interpreted as a ZWNBSP.

Anyway, the thing that brought this up is that in chardet we detect codecs of files for people and we've been returning UTF-16BE or UTF-16LE when we detect the BOM at the front of the file, but we recently learned that if people tried to decode with those codecs things don't work as expected.  It seems the correct behavior in our case is to just return UTF-16 in these cases.

----------

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

From report at bugs.python.org  Tue Oct  6 20:28:21 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Oct 2015 18:28:21 +0000
Subject: [issue8256] input() doesn't catch _PyUnicode_AsString() exception;
 io.StringIO().encoding is None
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1444156101.15.0.609372543425.issue8256@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I would fallback to PyFile_WriteObject(prompt, fout, Py_PRINT_RAW) if the stdout has no the encoding attribute or it is not a string.

----------
nosy: +serhiy.storchaka
versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Oct  6 21:01:03 2015
From: report at bugs.python.org (Adam)
Date: Tue, 06 Oct 2015 19:01:03 +0000
Subject: [issue24821] The optimization of string search can cause pessimization
In-Reply-To: <1438927886.02.0.407236930114.issue24821@psf.upfronthosting.co.za>
Message-ID: <1444158063.16.0.48259826891.issue24821@psf.upfronthosting.co.za>


Changes by Adam <azsorkin at gmail.com>:


----------
nosy: +azsorkin

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

From report at bugs.python.org  Tue Oct  6 21:09:04 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Oct 2015 19:09:04 +0000
Subject: [issue8256] input() doesn't catch _PyUnicode_AsString() exception;
 io.StringIO().encoding is None
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1444158544.92.0.174504699004.issue8256@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch.

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file40704/input_fallback.patch

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

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: [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:18:11 2015
From: report at bugs.python.org (Max Farrell)
Date: Tue, 06 Oct 2015 19:18:11 +0000
Subject: [issue25327] Python 3.5 Windows 10 Installation Fails With Corrupt
 Directory Error
In-Reply-To: <1444158929.17.0.958529864841.issue25327@psf.upfronthosting.co.za>
Message-ID: <1444159091.72.0.157641111565.issue25327@psf.upfronthosting.co.za>


Max Farrell added the comment:

Windows 10 64-Bit Educational Edition.
Python 3.5 64-bit Installation failed. Directory is corrupt.
Log included.

----------
title: Windows 10 Installation Fails With Corrupt Directory Error -> Python 3.5 Windows 10 Installation Fails With Corrupt Directory Error
Added file: http://bugs.python.org/file40706/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:34:21 2015
From: report at bugs.python.org (eryksun)
Date: Tue, 06 Oct 2015 19:34:21 +0000
Subject: [issue25327] Python 3.5 Windows 10 Installation Fails With Corrupt
 Directory Error
In-Reply-To: <1444158929.17.0.958529864841.issue25327@psf.upfronthosting.co.za>
Message-ID: <1444160061.03.0.314036724261.issue25327@psf.upfronthosting.co.za>


Changes by eryksun <eryksun at gmail.com>:


Removed file: http://bugs.python.org/file40706/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:35:09 2015
From: report at bugs.python.org (eryksun)
Date: Tue, 06 Oct 2015 19:35:09 +0000
Subject: [issue25327] Python 3.5 Windows 10 Installation Fails With Corrupt
 Directory Error
In-Reply-To: <1444158929.17.0.958529864841.issue25327@psf.upfronthosting.co.za>
Message-ID: <1444160109.55.0.589694897064.issue25327@psf.upfronthosting.co.za>


Changes by eryksun <eryksun at gmail.com>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

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

From report at bugs.python.org  Tue Oct  6 21:44:59 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 06 Oct 2015 19:44:59 +0000
Subject: [issue25327] Python 3.5 Windows 10 Installation Fails With Corrupt
 Directory Error
In-Reply-To: <1444158929.17.0.958529864841.issue25327@psf.upfronthosting.co.za>
Message-ID: <1444160699.96.0.707470474083.issue25327@psf.upfronthosting.co.za>


Steve Dower added the comment:

Looks like you need to download the installer again (clear your internet cache first to avoid getting the same corrupted file).

----------
type: compile error -> 

_______________________________________
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: [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:16:23 2015
From: report at bugs.python.org (paul j3)
Date: Tue, 06 Oct 2015 20:16:23 +0000
Subject: [issue25314] Documentation: argparse's actions store_{true,
 false} default to False/True (undocumented)
In-Reply-To: <1443992693.14.0.504421256983.issue25314@psf.upfronthosting.co.za>
Message-ID: <1444162583.26.0.352775518515.issue25314@psf.upfronthosting.co.za>


paul j3 added the comment:

I have seen questions on StackOverflow with 'store_true' and explicit `default=False` parameters.  I don't recall any where this was a problem.  Usually it's as harmless as users specifying other defaults like `action='store'`, or a dest that echos a long option, etc.

But if we are going to fix the wrong default statement in `store_const`, we might as well clarify this case as well.

I wonder if this is the time and place to add a note that specifying 'type' is not necessary (and even wrong) - re. this closed issue: http://bugs.python.org/issue24754 

Is the line  'These are special cases of ``'store_const'``' useful?   The statement echos the class definition

    class _StoreTrueAction(_StoreConstAction)

but I'm not sure it adds much to the user's understanding.  'store_true' and 'store_false' are used frequently; 'store_const' is much less common (based on SO questions).

----------
nosy: +paul.j3

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

From report at bugs.python.org  Tue Oct  6 22:23:30 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 06 Oct 2015 20:23:30 +0000
Subject: [issue25097] test_logging may fail with 'Access is denied' when
 pywin32 is installed
In-Reply-To: <1442204467.58.0.479620846783.issue25097@psf.upfronthosting.co.za>
Message-ID: <20151006202326.3295.42260@psf.io>


Roundup Robot added the comment:

New changeset 4e7697ccceeb by Zachary Ware in branch '3.4':
Issue #25097: fix Windows error number access
https://hg.python.org/cpython/rev/4e7697ccceeb

New changeset 440d4da352fa by Zachary Ware in branch '3.5':
Issue #25097: Merge with 3.4
https://hg.python.org/cpython/rev/440d4da352fa

New changeset d91f9fc7b85d by Zachary Ware in branch 'default':
Issue #25097: Merge with 3.5
https://hg.python.org/cpython/rev/d91f9fc7b85d

----------

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

From report at bugs.python.org  Tue Oct  6 22:26:25 2015
From: report at bugs.python.org (John)
Date: Tue, 06 Oct 2015 20:26:25 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1444163185.33.0.549519157891.issue22906@psf.upfronthosting.co.za>


John added the comment:

Consider the following generator function similar to the one that started this issue:

    from __future__ import generator_stop

    def myzip(*seqs):
        its = (iter(seq) for seq in seqs)
        while True:
            try:        
                yield tuple(next(it) for it in its)
            except RuntimeError:
                return

    g = myzip('abc', 'xyz')
    print([next(g) for i in range(5)]) # prints: [('a', 'x'), (), (), (), ()]

A print(list(g)) would cause a hang.

----------
nosy: +john.black.3k

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

From report at bugs.python.org  Tue Oct  6 22:29:19 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 06 Oct 2015 20:29:19 +0000
Subject: [issue25097] test_logging may fail with 'Access is denied' when
 pywin32 is installed
In-Reply-To: <1442204467.58.0.479620846783.issue25097@psf.upfronthosting.co.za>
Message-ID: <20151006202915.7252.81949@psf.io>


Roundup Robot added the comment:

New changeset 03a569eb0e0e by Zachary Ware in branch '3.4':
Issue #25097: Re-raise any other pywin32 error
https://hg.python.org/cpython/rev/03a569eb0e0e

New changeset 95a26798819b by Zachary Ware in branch '3.5':
Issue #25097: Merge with 3.4
https://hg.python.org/cpython/rev/95a26798819b

New changeset db782c81bba9 by Zachary Ware in branch 'default':
Issue #25097: Merge with 3.5
https://hg.python.org/cpython/rev/db782c81bba9

----------

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

From report at bugs.python.org  Tue Oct  6 22:33:41 2015
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 06 Oct 2015 20:33:41 +0000
Subject: [issue25097] test_logging may fail with 'Access is denied' when
 pywin32 is installed
In-Reply-To: <1442204467.58.0.479620846783.issue25097@psf.upfronthosting.co.za>
Message-ID: <1444163621.71.0.317845749706.issue25097@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Turned out that your change didn't quite do it, but it was just the method you used to try to access the errno (which looks like it ought to work from the formatting of the error message).

Mere moments after pushing the fix for that, I realized that the new try/except was silently swallowing any other win32 errors that weren't permission errors, so that's the second batch of commits from me.

----------

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

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: [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  Tue Oct  6 22:50:14 2015
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 06 Oct 2015 20:50:14 +0000
Subject: [issue25329] test_json crashes with stack overflow on Windows
In-Reply-To: <1444164061.67.0.762118597604.issue25329@psf.upfronthosting.co.za>
Message-ID: <1444164614.44.0.531766054322.issue25329@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Note that this is not a consistent failure, see for example build 223[1] where test_json passes.  I've noticed that the sooner test_json starts, the more likely it is to pass (it's the 28th test in 223, 117th in 224).

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

----------

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

From report at bugs.python.org  Tue Oct  6 23:03:02 2015
From: report at bugs.python.org (paul j3)
Date: Tue, 06 Oct 2015 21:03:02 +0000
Subject: [issue25308] Multiple names can target the same namespace
In-Reply-To: <1443909316.53.0.827518024147.issue25308@psf.upfronthosting.co.za>
Message-ID: <1444165382.95.0.0877495504724.issue25308@psf.upfronthosting.co.za>


paul j3 added the comment:

What you are asking about is the fact that different arguments can share a 'dest'.

https://docs.python.org/3/library/argparse.html#dest

The 'append_const' action has an example of shared 'dest'.  It says:

    The 'append_const' action is typically useful when multiple    
    arguments need to store constants to the same list. 

I've suggested 'dest' sharing in some SO questions.

Shared 'dest' may be a nuisance in the case of regular 'store' actions, since only the last value is retained.  But that also happens if a user repeats an argument.  Usually errors like this become apparent during development testing, and can be easily fixed with changes to the 'dest' parameter.

The 'conflict handler' mechanism does prevent conflicts in the option strings.  But it does not check the 'dest'.  In fact the parser does not maintain a list or dictionary of 'dest'.  It looks that up on the Actions as needed.

A simple function that would collect actions by 'dest' could use:

     dd = collections.defaultdict(list)
     for a in parser._actions:
         dd[a.dest].append(a)

Or the developer could collect their own list of Actions.  So it is easy to test for repeated 'dest', but I don't think it is generally needed or useful.

Custom Action classes can also be used to test for repeat assignments to a given 'dest' (objecting, for example, if the existing value in the Namespace is not the default).

----------
nosy: +paul.j3

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

From report at bugs.python.org  Tue Oct  6 23:29:36 2015
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 06 Oct 2015 21:29:36 +0000
Subject: [issue25325] UTF-16LE, UTF-16BE, UTF-32LE,
 and UTF-32BE encodings don't add/remove BOM on encode/decode
In-Reply-To: <1444149549.66.0.600836718737.issue25325@psf.upfronthosting.co.za>
Message-ID: <1444166976.43.0.0452251296834.issue25325@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

Just to add some more background:

The LE and BE codecs are meant to be used when you already know the endianness of the platform you are targeting, e.g. in case you work on strings that were read after the initial BOM, or write to an output string in chunks after having written the initial BOM. As such, they don't treat the BOM special, since it is a valid code point, and pass it through as-is.

If you do want BOM handling, the UTF-16 codec is the right choice. It defaults to the platform's endianness and uses the BOM to indicate which choice it made.

----------

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

From report at bugs.python.org  Wed Oct  7 00:58:42 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 06 Oct 2015 22:58:42 +0000
Subject: [issue24402] input() uses sys.__stdout__ instead of sys.stdout for
 prompt
In-Reply-To: <1433669452.09.0.930876867216.issue24402@psf.upfronthosting.co.za>
Message-ID: <1444172322.52.0.511163603062.issue24402@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch itself looks good.

----------
nosy: +martin.panter
stage: needs patch -> patch review

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

From report at bugs.python.org  Wed Oct  7 01:04:35 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 06 Oct 2015 23:04:35 +0000
Subject: [issue8256] input() doesn't catch _PyUnicode_AsString() exception;
 io.StringIO().encoding is None
In-Reply-To: <1269807316.51.0.487538621224.issue8256@psf.upfronthosting.co.za>
Message-ID: <1444172675.82.0.203280329666.issue8256@psf.upfronthosting.co.za>


Martin Panter added the comment:

Serhiy, your patch looks like a worthwhile improvement because it adds proper error checking and handling. However I suspect this original bug is actually a side effect of Issue 24402. The code in question shouldn?t even be running, because sys.stdout is not the original output file descriptor, and is not a terminal.

----------
dependencies: +input() uses sys.__stdout__ instead of sys.stdout for prompt
nosy: +martin.panter

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

From report at bugs.python.org  Wed Oct  7 01:21:43 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 06 Oct 2015 23:21:43 +0000
Subject: [issue25322] contextlib.suppress not tested for nested usage
In-Reply-To: <1444123306.69.0.0149294325224.issue25322@psf.upfronthosting.co.za>
Message-ID: <1444173703.39.0.083622486106.issue25322@psf.upfronthosting.co.za>


Martin Panter added the comment:

My suggested fix would look like:

with ignore_exceptions:
    with ignore_exceptions:  # Check nested usage 
        len(5)
    ignored = True
    1/0
self.assertTrue(ignored)

----------
nosy: +martin.panter

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

From report at bugs.python.org  Wed Oct  7 01:30:46 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 06 Oct 2015 23:30:46 +0000
Subject: [issue25324] Importing tokenize modifies token
In-Reply-To: <1444145798.79.0.176080140328.issue25324@psf.upfronthosting.co.za>
Message-ID: <1444174246.29.0.193305473956.issue25324@psf.upfronthosting.co.za>


Martin Panter added the comment:

I would fix this by making tokenize.tok_name a copy. It looks like this behaviour dates back to 1997 (see revision 1efc4273fdb7).

----------
nosy: +martin.panter

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

From report at bugs.python.org  Wed Oct  7 01:56:07 2015
From: report at bugs.python.org (Mark Roseman)
Date: Tue, 06 Oct 2015 23:56:07 +0000
Subject: [issue22726] Idle: add help to config dialogs
In-Reply-To: <1414212383.94.0.847086482603.issue22726@psf.upfronthosting.co.za>
Message-ID: <1444175767.25.0.998874414717.issue22726@psf.upfronthosting.co.za>


Mark Roseman added the comment:

I'm not against online help, but I feel that what's there wouldn't be helpful to someone using IDLE. 

Once this would be extended to per-tab, what are the problem areas that people really need help with?  Also keeping in mind we're going to be replacing this dialog (at least for people with tk > 8.4) in the not too distant future.

----------

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

From report at bugs.python.org  Wed Oct  7 02:00:29 2015
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 07 Oct 2015 00:00:29 +0000
Subject: [issue25313] IDLE: gracefully handle themes (or keysets,
 or ...) not present
In-Reply-To: <1443983028.38.0.330062493222.issue25313@psf.upfronthosting.co.za>
Message-ID: <1444176029.25.0.230769844535.issue25313@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Okay, that's reasonable enough for me.  :-) I'd still be for nuking the warning so that nothing gets displayed unless you go looking in online help.

----------

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

From report at bugs.python.org  Wed Oct  7 02:33:28 2015
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 07 Oct 2015 00:33:28 +0000
Subject: [issue14576] IDLE: inconsistent use of HOMEDRIVE, HOMEPATH,
 and USERPROFILE on Windows
In-Reply-To: <1334400065.92.0.605072928338.issue14576@psf.upfronthosting.co.za>
Message-ID: <1444178008.78.0.73318706585.issue14576@psf.upfronthosting.co.za>


Changes by Mark Roseman <mark at markroseman.com>:


----------
nosy: +markroseman

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

From report at bugs.python.org  Wed Oct  7 03:05:00 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 07 Oct 2015 01:05:00 +0000
Subject: [issue25322] contextlib.suppress not tested for nested usage
In-Reply-To: <1444123306.69.0.0149294325224.issue25322@psf.upfronthosting.co.za>
Message-ID: <1444179900.09.0.904710753358.issue25322@psf.upfronthosting.co.za>


R. David Murray added the comment:

Looks good to me.  I hope I never see anything like that in real code, though :)

----------

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

From report at bugs.python.org  Wed Oct  7 03:43:49 2015
From: report at bugs.python.org (John)
Date: Wed, 07 Oct 2015 01:43:49 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1444182229.59.0.769852073991.issue22906@psf.upfronthosting.co.za>


John added the comment:

Please ignore my previous comment - now I understood what is going on. The `its` generator is a one-shot iterator so is exhausted the first time the while loop is run. Therefore, on subsequent loops, only empty tuples are yielded.

Still learning about generators... :)

----------

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

From report at bugs.python.org  Wed Oct  7 03:51:04 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 07 Oct 2015 01:51:04 +0000
Subject: [issue22865] Document how to make pty.spawn not copy data
In-Reply-To: <1415901686.09.0.50650588621.issue22865@psf.upfronthosting.co.za>
Message-ID: <1444182664.57.0.925523025009.issue22865@psf.upfronthosting.co.za>


Martin Panter added the comment:

If you return null bytes, they will be written to the parent process?s stdout file descriptor, rather than being ignored. I do not think it is possible to ignore output with the spawn() API, unless perhaps you previously set up stdout write to /dev/null or similar.

Do you have a reference for your fact about terminals ignoring null input bytes? I?m skeptical because a basic serial terminal can send arbitrary data including nulls, but I am not so familiar with pseudo-terminals.

However the bit about interpreting an empty string could be useful. I would drop the ?or any falsey value?; is that a typo? I suspect that the functions have to return byte strings (not text). It would be nice to say what the consequences of the EOF condition is, e.g. I can see for the child?s output it would stop copying, but not actually close the parent?s stdout to signal EOF. What about in the other direction? Can you signal multiple EOFs with data in between?

----------
nosy: +martin.panter
stage:  -> patch review
versions:  -Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Oct  7 04:11:53 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 07 Oct 2015 02:11:53 +0000
Subject: [issue25321] Null Dereference  "subname" in zipimport.c
In-Reply-To: <1444110436.55.0.477379741136.issue25321@psf.upfronthosting.co.za>
Message-ID: <1444183913.21.0.172690781048.issue25321@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Wed Oct  7 04:13:22 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 07 Oct 2015 02:13:22 +0000
Subject: [issue25323] Bus error: 10 when executing recursive program
In-Reply-To: <1444128171.82.0.123240917074.issue25323@psf.upfronthosting.co.za>
Message-ID: <1444184002.65.0.391533471917.issue25323@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Wed Oct  7 04:20:17 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 07 Oct 2015 02:20:17 +0000
Subject: [issue17824] pty.spawn handles errors improperly
In-Reply-To: <1366772370.17.0.184801312009.issue17824@psf.upfronthosting.co.za>
Message-ID: <1444184417.66.0.492376386382.issue17824@psf.upfronthosting.co.za>


Martin Panter added the comment:

The spawn() function has this code outside of any error handler:

pid, master_fd = fork()
if pid == CHILD:
    os.execlp(argv[0], *argv)

If fork() succeeds, there will actually be a parent Python process and a child Python process. If exec() then fails, an exception will escape the spawn() function in the child process, while the parent process will carry on as if all is well. Maybe it would be worthwhile studying how the ?subprocess? module handles exec() failure in the child process.

----------
nosy: +martin.panter
stage:  -> needs patch

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

From report at bugs.python.org  Wed Oct  7 04:34:43 2015
From: report at bugs.python.org (Geoff Shannon)
Date: Wed, 07 Oct 2015 02:34:43 +0000
Subject: [issue22865] Document how to make pty.spawn not copy data
In-Reply-To: <1415901686.09.0.50650588621.issue22865@psf.upfronthosting.co.za>
Message-ID: <1444185283.54.0.821676340433.issue22865@psf.upfronthosting.co.za>


Geoff Shannon added the comment:

Hmm, I spoke improperly.  I think you are entirely correct in your statements.  What I meant by "terminals ignore null bytes" is that returning a string consisting of only a null byte doesn't cause anything observable to happen, including anything to be written to the screen.  But I have no idea why this is.

My basis for this is limited to empirical observation of how my terminal behaves (I use the iTerm2 terminal emulator on Mac OS X), and I don't recall whether I checked it with other terminals like the regular terminal on Mac and terminal emulators on Linux.

Re: "or any falsey value".  In general, the _read_ functions should return byte strings yes, but since the check for EOF in python is whether a stream returned an empty string, and the way that pty.spawn() currently checks for that is `if not data` then any falsey value will cause pty.spawn to think that the underlying fd was closed.

I agree that the documentation on this could use more fleshing out in general, especially regarding what happens when certain values are returned.  I'm not very familiar with this code any more, but I might have time to play with it and try to add some more information in the coming weeks.

----------

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

From report at bugs.python.org  Wed Oct  7 04:43:12 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 07 Oct 2015 02:43:12 +0000
Subject: [issue24806] Inheriting from NoneType does not fail consistently
In-Reply-To: <1438844411.04.0.216994777179.issue24806@psf.upfronthosting.co.za>
Message-ID: <20151007024256.20765.46629@psf.io>


Roundup Robot added the comment:

New changeset c46ccfac8763 by Benjamin Peterson in branch '2.7':
prevent unacceptable bases from becoming bases through multiple inheritance (#24806)
https://hg.python.org/cpython/rev/c46ccfac8763

New changeset e670b37e7b14 by Benjamin Peterson in branch '3.4':
prevent unacceptable bases from becoming bases through multiple inheritance (#24806)
https://hg.python.org/cpython/rev/e670b37e7b14

New changeset e02e4afcce6a by Benjamin Peterson in branch '3.5':
merge 3.4 (#24806)
https://hg.python.org/cpython/rev/e02e4afcce6a

New changeset 4b2a2688d2ad by Benjamin Peterson in branch 'default':
merge 3.5 (closes #24806)
https://hg.python.org/cpython/rev/4b2a2688d2ad

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Oct  7 04:50:01 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 07 Oct 2015 02:50:01 +0000
Subject: [issue25308] Multiple names can target the same namespace
In-Reply-To: <1443909316.53.0.827518024147.issue25308@psf.upfronthosting.co.za>
Message-ID: <1444186201.79.0.238238655495.issue25308@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Wed Oct  7 04:50:51 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 07 Oct 2015 02:50:51 +0000
Subject: [issue12346] Python source code build fails with old mercurial
In-Reply-To: <1308212064.93.0.160132143903.issue12346@psf.upfronthosting.co.za>
Message-ID: <1444186251.39.0.723502470918.issue12346@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> fixed
status: pending -> closed

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

From report at bugs.python.org  Wed Oct  7 04:58:47 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 07 Oct 2015 02:58:47 +0000
Subject: [issue25322] contextlib.suppress not tested for nested usage
In-Reply-To: <1444123306.69.0.0149294325224.issue25322@psf.upfronthosting.co.za>
Message-ID: <1444186727.07.0.455369352615.issue25322@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

That patch looks correct.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Wed Oct  7 04:59:56 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 07 Oct 2015 02:59:56 +0000
Subject: [issue24954] No way to generate or parse timezone as produced by
 datetime.isoformat()
In-Reply-To: <1440801281.72.0.545558404714.issue24954@psf.upfronthosting.co.za>
Message-ID: <1444186796.39.0.127906008354.issue24954@psf.upfronthosting.co.za>


Martin Panter added the comment:

Okay I am happy to be wrong about Python allowing seconds resolution.

I notice that Issue 12006 was committed, which adds a second table of Python-only codes for ISO 8601 values. The proposed entries here could be incorporated into that table, and the text above it modified to suit. That would solve my C89 library problem.

----------

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

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: [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 05:52:06 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 07 Oct 2015 03:52:06 +0000
Subject: [issue25294] Absolute imports fail in some cases where relative
 imports would work
In-Reply-To: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>
Message-ID: <1444189926.83.0.233354206198.issue25294@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

We seem to be talking past each other, so let's take a step back and ensure we have a common understanding of the absolute/relative terminology:

"import x.y.z" is an absolute import
"from x.y import z" is still an absolute import.
"from . import z" is an explicit relative import of a child or sibling module
"from .y import z" is also an explicit relative import

The relevant change in behaviour is between the "import x.y.z" form and the "from x.y import z" form due to the change in the way the related name binding (and name lookup in 3.5+) works, not between absolute and relative imports.

The relevant terminology to distinguish between "from ... import ..." vs "import ..." is just "from import" vs "non-from import", and there are definitely cases where from imports will work, but non-from imports will fail. That's not a style issue, it's a use-whichever-one-works for your code issue.

----------

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

From report at bugs.python.org  Wed Oct  7 06:08:36 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 07 Oct 2015 04:08:36 +0000
Subject: [issue25294] Absolute imports fail in some cases where relative
 imports would work
In-Reply-To: <1443752624.23.0.127590380632.issue25294@psf.upfronthosting.co.za>
Message-ID: <1444190916.13.0.862692679891.issue25294@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

(Oops, it seems Brett already clarified the terminology. My apologies for the noise).

Modularity and module design is hard. It's one of the hardest problems in software engineering, which is why folks invent entire new vocabularies to attempt to describe the problem space effectively: http://connascence.io/

The simplest way to avoid these kinds of import related problems as a beginner in Python is to just put all your code in one module, and only factor it out into multiple modules when the single file becomes difficult to maintain.

Unfortunately, Java's "one public class per file" restriction, it's lack of standalone module level functions, and it's popularity as a university level teaching level has given a lot of people a lot of bad ideas as to what good multi-level modularity looks like, as Java throws out the notion of using modules to group closely related public classes and standalone functions into a single file, and instead makes you jump almost directly from classes to packages.

So perhaps that's the currently unwritten rule that would be worth documenting? That Python has 3 levels of namespacing (classes, modules, packages), and that flat namespaces are preferred in the standard library. If the namespace is broken up internally into multiple files for maintainability reasons, we prefer to still present a flat *public* API, as unittest, asyncio and concurrent.futures do.

----------

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

From report at bugs.python.org  Wed Oct  7 08:46:27 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 07 Oct 2015 06:46:27 +0000
Subject: [issue22865] Document how to make pty.spawn not copy data
In-Reply-To: <1415901686.09.0.50650588621.issue22865@psf.upfronthosting.co.za>
Message-ID: <1444200387.06.0.572230946001.issue22865@psf.upfronthosting.co.za>


Martin Panter added the comment:

I would avoid suggesting one can return non-byte-strings; treat that as an implementation detail. Maybe something like:

The functions *master_read* and *stdin_read* are passed a file descriptor which they should read from, and should return a byte string. The defaults try to read 1024 bytes each time they are called. Returning an empty string is be interpreted as an EOF condition, and the *_read* function will no longer be called.

----------

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

From report at bugs.python.org  Wed Oct  7 10:02:52 2015
From: report at bugs.python.org (Maxim Egorushkin)
Date: Wed, 07 Oct 2015 08:02:52 +0000
Subject: [issue7352] pythonx.y-config --ldflags out of /usr and missing
 -L<install_lib_dir>
In-Reply-To: <1258578467.08.0.137292547946.issue7352@psf.upfronthosting.co.za>
Message-ID: <1444204972.09.0.297149213666.issue7352@psf.upfronthosting.co.za>


Maxim Egorushkin added the comment:

I encountered this issue when compiling gdb against my own build of Python 2.7 in a non-standard location. gdb could not locate libpython2.7.so.

The solution is to configure Python with LINKFORSHARED variable which contains additional linker flags required to link against libpython2.7.so. Here are the relevant bits (in Makefile syntax):

	prefix := /opt/toolchain
	python_version := 2.7.10
	PREFIX := ${prefix}/python-${python_version}
	CPPFLAGS := -fmessage-length=0
	LINKFORSHARED := -L${PREFIX}/lib64 -Wl,-rpath=${PREFIX}/lib64
	
	./configure --prefix=${PREFIX} --libdir=${PREFIX}/lib64 --enable-shared --enable-unicode=ucs4 CPPFLAGS="${cppflags}" LDFLAGS="${LDFLAGS}" LINKFORSHARED="${LINKFORSHARED}"

After Python is built and installed verify the flags:
	
	$ /opt/toolchain/python-2.7.10/bin/python-config --ldflags
	-lpython2.7 -lpthread -ldl -lutil -lm -L/opt/toolchain/python-2.7.10/lib64 -Wl,-rpath=/opt/toolchain/python-2.7.10/lib64

----------
nosy: +max0x7ba

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

From report at bugs.python.org  Wed Oct  7 11:28:43 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 07 Oct 2015 09:28:43 +0000
Subject: [issue24402] input() uses sys.__stdout__ instead of sys.stdout for
 prompt
In-Reply-To: <1433669452.09.0.930876867216.issue24402@psf.upfronthosting.co.za>
Message-ID: <1444210123.11.0.998421090503.issue24402@psf.upfronthosting.co.za>


Martin Panter added the comment:

This patch includes a test case using pty.fork() to ensure stdin is a terminal, so the bug would be triggered. It is a bit tricky, but hopefully works on Unix platforms. I have only tested it on Linux.

----------
Added file: http://bugs.python.org/file40707/input-terminal.patch

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

From report at bugs.python.org  Wed Oct  7 11:47:54 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 07 Oct 2015 09:47:54 +0000
Subject: [issue25286] views are not sequences
In-Reply-To: <1443677491.48.0.268151687155.issue25286@psf.upfronthosting.co.za>
Message-ID: <1444211274.62.0.952625737442.issue25286@psf.upfronthosting.co.za>


Martin Panter added the comment:

Will commit this patch, except for the :dfn:`view` part. That isn?t a hyperlink, it just emphasizes the term.

----------
assignee: docs at python -> martin.panter
nosy: +berker.peksag
stage: patch review -> commit review

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

From report at bugs.python.org  Wed Oct  7 12:09:32 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 07 Oct 2015 10:09:32 +0000
Subject: [issue25286] views are not sequences
In-Reply-To: <1443677491.48.0.268151687155.issue25286@psf.upfronthosting.co.za>
Message-ID: <20151007100928.97710.72773@psf.io>


Roundup Robot added the comment:

New changeset 92429e01f444 by Martin Panter in branch '3.4':
Issue #25286: Dictionary views are not sequences
https://hg.python.org/cpython/rev/92429e01f444

New changeset c29f1114ef65 by Martin Panter in branch '3.5':
Issue #25286: Merge dictionary view glossary from 3.4 into 3.5
https://hg.python.org/cpython/rev/c29f1114ef65

New changeset d43c33f032a2 by Martin Panter in branch '3.5':
Issue #25286: Update dictionary view link; patch by Akira Li
https://hg.python.org/cpython/rev/d43c33f032a2

New changeset 7067420c3e72 by Martin Panter in branch 'default':
Issue #25286: Merge dictionary view glossary from 3.5
https://hg.python.org/cpython/rev/7067420c3e72

----------
nosy: +python-dev

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

From report at bugs.python.org  Wed Oct  7 12:22:40 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Oct 2015 10:22:40 +0000
Subject: [issue24402] input() uses sys.__stdout__ instead of sys.stdout for
 prompt
In-Reply-To: <1433669452.09.0.930876867216.issue24402@psf.upfronthosting.co.za>
Message-ID: <1444213360.34.0.187422661098.issue24402@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM. See also minor note on Rietveld.

I think it is worth to extract all input() tests to separate class.

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Wed Oct  7 12:24:01 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 07 Oct 2015 10:24:01 +0000
Subject: [issue25286] views are not sequences
In-Reply-To: <1443677491.48.0.268151687155.issue25286@psf.upfronthosting.co.za>
Message-ID: <20151007102357.18382.80158@psf.io>


Roundup Robot added the comment:

New changeset 41e1f2500047 by Martin Panter in branch '2.7':
Issue #25286: Dictionary views are not sequences
https://hg.python.org/cpython/rev/41e1f2500047

----------

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

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: [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:40:55 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 07 Oct 2015 10:40:55 +0000
Subject: [issue25286] views are not sequences
In-Reply-To: <1443677491.48.0.268151687155.issue25286@psf.upfronthosting.co.za>
Message-ID: <20151007104052.70994.13482@psf.io>


Roundup Robot added the comment:

New changeset 04815b55227f by Martin Panter in branch '2.7':
Issue #25286: Accidentally dropped "the"
https://hg.python.org/cpython/rev/04815b55227f

----------

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

From report at bugs.python.org  Wed Oct  7 12:46:32 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 07 Oct 2015 10:46:32 +0000
Subject: [issue25286] views are not sequences
In-Reply-To: <1443677491.48.0.268151687155.issue25286@psf.upfronthosting.co.za>
Message-ID: <1444214792.5.0.838066607573.issue25286@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks Akira

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
versions: +Python 2.7

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

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: [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 13:33:03 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 07 Oct 2015 11:33:03 +0000
Subject: [issue5380] pty.read raises IOError when slave pty device is closed
In-Reply-To: <1235721814.23.0.522352333065.issue5380@psf.upfronthosting.co.za>
Message-ID: <1444217583.53.0.487633546171.issue5380@psf.upfronthosting.co.za>


Martin Panter added the comment:

I don?t think it is right to assume pseudo-terminals behave exactly like pipes. I suspect the behaviour when the slave is closed is undefined, or at best platform-specific, and there is no bug to fix in Python.

Also, it looks like array.fromfile() assumes any short read implies EOF, so the unbuffered workaround may not work in all cases. The documentation is vague on what it accepts, but I suspect it only works properly with a binary ?buffered? file in general.

----------
nosy: +martin.panter

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

From report at bugs.python.org  Wed Oct  7 13:46:37 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 07 Oct 2015 11:46:37 +0000
Subject: [issue25332] [Errno 10035] A non-blocking socket operation could not
 be completed immediately on python 3.1.2
In-Reply-To: <1444214920.55.0.915956514334.issue25332@psf.upfronthosting.co.za>
Message-ID: <1444218397.39.0.528493032547.issue25332@psf.upfronthosting.co.za>


Martin Panter added the comment:

According to Issue 9090, this was already fixed in 3.2 and 2.7. I think the 3.1 branch is closed. Are you seeing the same problem in newer version of Python, or just 3.1.2? If only 3.1.2, I think you may be on your own.

----------
nosy: +martin.panter

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

From report at bugs.python.org  Wed Oct  7 13:49:20 2015
From: report at bugs.python.org (Serge Matveenko)
Date: Wed, 07 Oct 2015 11:49:20 +0000
Subject: [issue25315] OrderedDict mangled private attribute is inaccessible
In-Reply-To: <1444010587.49.0.504903152106.issue25315@psf.upfronthosting.co.za>
Message-ID: <1444218560.83.0.240844350872.issue25315@psf.upfronthosting.co.za>


Serge Matveenko added the comment:

Sorry for reopening. I completely agree with the point that is it not necessary for Python and C implementations to duplicate each other.

But then the Python OrderedDict implementation should be dropped from the library source. The code that is there now is nothing more than confusing. For some one not aware of C implementation it is very hard to get from documentation that the code she sees via "Go to definition" feature of her IDE is not meant to be executing at all.

----------
resolution: not a bug -> 
status: closed -> open

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

From report at bugs.python.org  Wed Oct  7 13:51:46 2015
From: report at bugs.python.org (Alex Warhawk)
Date: Wed, 07 Oct 2015 11:51:46 +0000
Subject: [issue19500] Error when connecting to FTPS servers not supporting SSL
 session resuming
In-Reply-To: <1383624130.64.0.185541289049.issue19500@psf.upfronthosting.co.za>
Message-ID: <1444218706.57.0.155211202601.issue19500@psf.upfronthosting.co.za>


Alex Warhawk added the comment:

Based on the proof-of-concept patch I submitted a few days ago I have built a more sophisticated patch. Please review it and let me know about necessary changes.

----------
Added file: http://bugs.python.org/file40708/implement_ssl_session_reuse.patch

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

From report at bugs.python.org  Wed Oct  7 13:55:48 2015
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 07 Oct 2015 11:55:48 +0000
Subject: [issue19500] Error when connecting to FTPS servers not supporting SSL
 session resuming
In-Reply-To: <1383624130.64.0.185541289049.issue19500@psf.upfronthosting.co.za>
Message-ID: <1444218948.87.0.787283959792.issue19500@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

This is supposed to be a new feature hence the patch should be targeted against Python 3.6, definitively not 2.7.

----------
versions: +Python 3.6 -Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Oct  7 14:53:14 2015
From: report at bugs.python.org (Pathangi Jatinshravan)
Date: Wed, 07 Oct 2015 12:53:14 +0000
Subject: [issue25228] Regression in cookie parsing with brackets and quotes
In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za>
Message-ID: <1444222394.52.0.175540293444.issue25228@psf.upfronthosting.co.za>


Pathangi Jatinshravan added the comment:

Is this what you wanted?

----------
Added file: http://bugs.python.org/file40709/patch_with_test.diff

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

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: [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:05:36 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 07 Oct 2015 13:05:36 +0000
Subject: [issue25333] .1 + .2 == .3 should be True
In-Reply-To: <1444222732.46.0.826515110458.issue25333@psf.upfronthosting.co.za>
Message-ID: <1444223136.95.0.189741176007.issue25333@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

This is not a bug. See: https://docs.python.org/3.5/tutorial/floatingpoint.html

----------
nosy: +eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
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: [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 15:31:56 2015
From: report at bugs.python.org (Emanuel Barry)
Date: Wed, 07 Oct 2015 13:31:56 +0000
Subject: [issue25315] OrderedDict mangled private attribute is inaccessible
In-Reply-To: <1444010587.49.0.504903152106.issue25315@psf.upfronthosting.co.za>
Message-ID: <1444224716.86.0.184421136469.issue25315@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

The Python implementation will stay for two main reasons, one to provide a working implementation for all those who wish to use a modified version (you, for example, if you want to use a version that lets you alter order), and two for alternate implementations which don't have OrderedDict in the _collections module (a comment even hints at that in the source).

I fully agree on the confusing part, however. Maybe a comment could be added regarding this.

----------

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

From report at bugs.python.org  Wed Oct  7 17:05:48 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 07 Oct 2015 15:05:48 +0000
Subject: [issue25315] OrderedDict mangled private attribute is inaccessible
In-Reply-To: <1444010587.49.0.504903152106.issue25315@psf.upfronthosting.co.za>
Message-ID: <1444230348.36.0.497429085053.issue25315@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is a general policy: we have python modules for as many stdlib modules as we can (which is most of them), and for some stdlib modules we also have C accelerators.

I will agree that the fact that the documentation has a link to the source code of the collections module, which includes the OrderedDict python source, can be misleading if you do not understand the implication of the import at the end.  So adding a comment at the top of the OrderedDict source would, I think, be reasonable.

----------
components: +Documentation -Library (Lib)
stage: resolved -> needs patch
versions: +Python 3.6

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

From report at bugs.python.org  Wed Oct  7 17:06:40 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 07 Oct 2015 15:06:40 +0000
Subject: [issue25315] Make it clear in the OrderedDict source that it may be
 overridden
In-Reply-To: <1444010587.49.0.504903152106.issue25315@psf.upfronthosting.co.za>
Message-ID: <1444230400.85.0.107059210205.issue25315@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
title: OrderedDict mangled private attribute is inaccessible -> Make it clear in the OrderedDict source that it may be overridden

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

From report at bugs.python.org  Wed Oct  7 17:07:42 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 07 Oct 2015 15:07:42 +0000
Subject: [issue25315] Make it clear in the collections Python source code that
 OrderedDict may be overridden
In-Reply-To: <1444010587.49.0.504903152106.issue25315@psf.upfronthosting.co.za>
Message-ID: <1444230462.81.0.495293697261.issue25315@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
title: Make it clear in the OrderedDict source that it may be overridden -> Make it clear in the collections Python source code that OrderedDict may be overridden

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

From report at bugs.python.org  Wed Oct  7 17:09:23 2015
From: report at bugs.python.org (Adam)
Date: Wed, 07 Oct 2015 15:09:23 +0000
Subject: [issue17908] Unittest runner needs an option to call gc.collect()
 after each test
In-Reply-To: <1367720444.87.0.21268529715.issue17908@psf.upfronthosting.co.za>
Message-ID: <1444230563.05.0.556770754455.issue17908@psf.upfronthosting.co.za>


Changes by Adam <azsorkin at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file40711/unittest-add-gc.patch

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

From report at bugs.python.org  Wed Oct  7 17:19:29 2015
From: report at bugs.python.org (raghu prasad)
Date: Wed, 07 Oct 2015 15:19:29 +0000
Subject: [issue25332] [Errno 10035] A non-blocking socket operation could not
 be completed immediately on python 3.1.2
In-Reply-To: <1444214920.55.0.915956514334.issue25332@psf.upfronthosting.co.za>
Message-ID: <1444231169.9.0.0725289772441.issue25332@psf.upfronthosting.co.za>


raghu prasad added the comment:

HI Martin,

Thanks for the immediate reply
i m sure about the version 3.2 

we are using 3.1.2 in our project so thought if it was missed in this version

Oh if 3.1.2 is closed then its bad luck 

can you provide some inputs on how to proceed further on this 
i heard 2.7 and 3.1.2 are completely different codes 

Any help on this could be useful for us

----------

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

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: [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  Wed Oct  7 18:08:47 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 07 Oct 2015 16:08:47 +0000
Subject: [issue25335] ast.literal_eval fails to parse numbers with leading "+"
In-Reply-To: <1444231519.35.0.84058018345.issue25335@psf.upfronthosting.co.za>
Message-ID: <1444234127.87.0.905973011826.issue25335@psf.upfronthosting.co.za>


R. David Murray added the comment:

This works in python3.  I'm not sure why the two pythons are different, there's no obvious issue about this being changed in python3, so perhaps it was something that "just happened" while changing other things.  

literal_eval is *not* a general expression evaluator, so I'm actually surprised this works in python3...apparently support for + and - is required for evaling complex numbers, but there must be something different about the parse trees generated in python2 vs python3, since python2 literal_eval handles complex numbers fine.

I'm not sure this is a bug, but *if* we decide it is something we'd should make work the same in python2 and python3, someone will probably have to invest the time in figuring out what the difference between the two is.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Wed Oct  7 18:30:49 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 07 Oct 2015 16:30:49 +0000
Subject: [issue5380] pty.read raises IOError when slave pty device is closed
In-Reply-To: <1235721814.23.0.522352333065.issue5380@psf.upfronthosting.co.za>
Message-ID: <1444235449.84.0.77985736172.issue5380@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Indeed, ptys and pipes behave very differently (that's why we have both -- they serve different purposes).

More relevant question: we should find a way to decide whether to either apply Antoine's patch or close this issue.

Finally, maybe array.fromfile() can be fixed to deal better with short reads (if that's a real issue)? (However *empty* reads should still instantly stop it. Otherwise you end up busy-waiting.)

----------

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

From report at bugs.python.org  Wed Oct  7 19:02:48 2015
From: report at bugs.python.org (Nan Wu)
Date: Wed, 07 Oct 2015 17:02:48 +0000
Subject: [issue25311] Add f-string support to tokenize.py
In-Reply-To: <1443979407.62.0.707305717475.issue25311@psf.upfronthosting.co.za>
Message-ID: <1444237368.16.0.245108997469.issue25311@psf.upfronthosting.co.za>


Nan Wu added the comment:

Added 'f'/'F' to the StringPrefix regex and also update the quote dictionary.

----------
keywords: +patch
nosy: +Nan Wu
Added file: http://bugs.python.org/file40712/tokenize.patch

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

From report at bugs.python.org  Wed Oct  7 19:38:36 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 07 Oct 2015 17:38:36 +0000
Subject: [issue25330] Docs for pkgutil.get_data inconsistent with semantics
In-Reply-To: <1444187174.4.0.432847594977.issue25330@psf.upfronthosting.co.za>
Message-ID: <1444239516.39.0.0921382627988.issue25330@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Changing this to be a single issue about the difference between the docs and the semantics of pkgutil.

The feature request can be made into a separate issue, but there are plans to replace the API with a more stringently defined one in importlib.

----------
nosy: +brett.cannon
title: Two issues with pkgutil.get_data -> Docs for pkgutil.get_data inconsistent with semantics

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

From report at bugs.python.org  Wed Oct  7 20:03:55 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 07 Oct 2015 18:03:55 +0000
Subject: [issue25335] ast.literal_eval fails to parse numbers with leading "+"
In-Reply-To: <1444231519.35.0.84058018345.issue25335@psf.upfronthosting.co.za>
Message-ID: <1444241035.57.0.130625701998.issue25335@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Digging into the history, it looks as though changeset 884c71cd8dc6 is responsible for the difference between Python 2 and Python 3.

More background: in Python 2, there was the oddity that an expression like `-34` is parsed as a single AST node: in a sense.  In Python 3, it's parsed as an unary minus applied to a literal.  (So in a sense, Python 2 sorta kinda has negative literals, but Python 3 doesn't.) So the old `ast.literal_eval` stopped working for those negative literals in Python 3.  It looks as though Raymond fixed that regression and added support for unary plus at the same time.

I'd agree that this isn't a bug in Python 2.7.

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Wed Oct  7 20:35:56 2015
From: report at bugs.python.org (Xavier Combelle)
Date: Wed, 07 Oct 2015 18:35:56 +0000
Subject: [issue18595] zipfile: symlinks etc.
In-Reply-To: <1375170318.76.0.496081120587.issue18595@psf.upfronthosting.co.za>
Message-ID: <1444242956.14.0.368403540453.issue18595@psf.upfronthosting.co.za>


Xavier Combelle added the comment:

about the readlink functionnality, I would like to point that it might lead to security issues see for example https://security.stackexchange.com/questions/73718/how-zip-symlink-works

At least, the standard read should not do it by default.

----------
nosy: +xcombelle

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

From report at bugs.python.org  Wed Oct  7 22:01:21 2015
From: report at bugs.python.org (Nikolay Bogoychev)
Date: Wed, 07 Oct 2015 20:01:21 +0000
Subject: [issue16099] robotparser doesn't support request rate and crawl delay
 parameters
In-Reply-To: <1349096305.17.0.983395980337.issue16099@psf.upfronthosting.co.za>
Message-ID: <1444248081.72.0.64762868337.issue16099@psf.upfronthosting.co.za>


Nikolay Bogoychev added the comment:

Hey,

Friendly reminder that there has been no activity on this issue for more than an year.

Cheers,

Nick

----------

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

From report at bugs.python.org  Wed Oct  7 22:53:54 2015
From: report at bugs.python.org (Nan Wu)
Date: Wed, 07 Oct 2015 20:53:54 +0000
Subject: [issue25322] contextlib.suppress not tested for nested usage
In-Reply-To: <1444123306.69.0.0149294325224.issue25322@psf.upfronthosting.co.za>
Message-ID: <1444251234.5.0.367029727023.issue25322@psf.upfronthosting.co.za>


Nan Wu added the comment:

Added a patch with Martina's idea. Isn't ignored better set as false instead ? Since interpreter did not ignore it.

----------
keywords: +patch
nosy: +Nan Wu
Added file: http://bugs.python.org/file40713/fix_reentrant_cm_test.patch

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

From report at bugs.python.org  Wed Oct  7 23:08:48 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 07 Oct 2015 21:08:48 +0000
Subject: [issue25311] Add f-string support to tokenize.py
In-Reply-To: <1443979407.62.0.707305717475.issue25311@psf.upfronthosting.co.za>
Message-ID: <1444252128.61.0.580176767048.issue25311@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the patch. Do you want to try adding a test case. See TokenizeTest.test_string() at /Lib/test/test_tokenize.py:189 for a guide, though I would suggest a new test_fstring() method.

Also, F-strings can be combined with the raw string syntax. I wonder if you need to add support for things like rf". . ." and FR'''. . .'''.

----------
stage: needs patch -> patch review

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

From report at bugs.python.org  Wed Oct  7 23:19:27 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 07 Oct 2015 21:19:27 +0000
Subject: [issue25332] [Errno 10035] A non-blocking socket operation could not
 be completed immediately on python 3.1.2
In-Reply-To: <1444214920.55.0.915956514334.issue25332@psf.upfronthosting.co.za>
Message-ID: <1444252767.56.0.365450880309.issue25332@psf.upfronthosting.co.za>


Martin Panter added the comment:

See <https://bugs.python.org/issue9090#msg117549>, which is why I thought the problem should be fixed in 3.2. Specifically, that commit went into v3.2a3.

If you can demonstrate the problem exists in 3.4 or newer, you might be able to get more people interested in fixing it. (Not me however; I don?t have Windows.)

----------

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

From report at bugs.python.org  Wed Oct  7 23:56:15 2015
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 07 Oct 2015 21:56:15 +0000
Subject: [issue25332] [Errno 10035] A non-blocking socket operation could not
 be completed immediately on python 3.1.2
In-Reply-To: <1444214920.55.0.915956514334.issue25332@psf.upfronthosting.co.za>
Message-ID: <1444254975.63.0.313567891702.issue25332@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Python 3.1 is long since dead, and 3.1.2 isn't even the latest 3.1.  Is there a particular reason why you're using it?  I highly recommend upgrading to a newer Python, either 3.4.3 or 3.5.0.  3.5.0 if you're on anything newer than Windows XP, 3.4.3 if you're on XP or Server 2003.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Oct  8 01:50:49 2015
From: report at bugs.python.org (Pathangi Jatinshravan)
Date: Wed, 07 Oct 2015 23:50:49 +0000
Subject: [issue25228] Regression in cookie parsing with brackets and quotes
In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za>
Message-ID: <1444261849.33.0.522943537309.issue25228@psf.upfronthosting.co.za>


Pathangi Jatinshravan added the comment:

Hi Tim, I have submitted a patch (patch_with_test.diff). Can you take a look at this?

----------

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

From report at bugs.python.org  Thu Oct  8 01:51:55 2015
From: report at bugs.python.org (Scott Sanderson)
Date: Wed, 07 Oct 2015 23:51:55 +0000
Subject: [issue14611] inspect.getargs fails on some anonymous tuples
In-Reply-To: <1334738109.2.0.700206080535.issue14611@psf.upfronthosting.co.za>
Message-ID: <1444261915.2.0.819896739583.issue14611@psf.upfronthosting.co.za>


Scott Sanderson added the comment:

This issue is the root cause of at least two open issues in IPython:

https://github.com/ipython/ipython/issues/8293
https://github.com/ipython/ipython/issues/8205

Testing locally, the patch supplied here fixes both of those issues.  Is there still work that needs to be done here?

----------
nosy: +Scott Sanderson

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

From report at bugs.python.org  Thu Oct  8 01:54:04 2015
From: report at bugs.python.org (Tim Graham)
Date: Wed, 07 Oct 2015 23:54:04 +0000
Subject: [issue25228] Regression in cookie parsing with brackets and quotes
In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za>
Message-ID: <1444262044.03.0.173284893818.issue25228@psf.upfronthosting.co.za>


Tim Graham added the comment:

Yes, when I have some time.

By the way, did you intentionally remove all the "Python 3.X" versions on the issue?

----------

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

From report at bugs.python.org  Thu Oct  8 01:54:34 2015
From: report at bugs.python.org (Scott Sanderson)
Date: Wed, 07 Oct 2015 23:54:34 +0000
Subject: [issue14611] inspect.getargs fails on some anonymous tuples
In-Reply-To: <1334738109.2.0.700206080535.issue14611@psf.upfronthosting.co.za>
Message-ID: <1444262074.07.0.880018906978.issue14611@psf.upfronthosting.co.za>


Scott Sanderson added the comment:

Note also that a much simpler repro for this issue is:

inspect.getargs(((x for _ in [0]) for x in [0]).gi_code)

This triggers the same issue because the inner generator expression closes over the loop variable of the outer expression, which causes us to hit the STORE_DEREF case instead of the STORE_FAST case.

----------

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

From report at bugs.python.org  Thu Oct  8 02:27:50 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 08 Oct 2015 00:27:50 +0000
Subject: [issue25315] Make it clear in the collections Python source code that
 OrderedDict may be overridden
In-Reply-To: <1444010587.49.0.504903152106.issue25315@psf.upfronthosting.co.za>
Message-ID: <1444264070.78.0.240028589578.issue25315@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

In general, the __attributes and _attributes are already considered to be private, so I don't see the point.  Aside from this one user that is never been necessary and he already knows that it doesn't work. 

Re-reading the thread, the issue isn't that he doesn't like the design choice, not that he didn't understand it.

The collections module isn't the only place the implementation has been made private (see fractions.py) for example.   Maybe a general note in the docs about private APIs or a FAQ entry would be appropriate, but there isn't anything specific to OrderedDicts (especially now that there is a C implementation, it should go without saying).

----------

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

From report at bugs.python.org  Thu Oct  8 02:28:58 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 08 Oct 2015 00:28:58 +0000
Subject: [issue25315] Make it clear in the collections Python source code that
 OrderedDict may be overridden
In-Reply-To: <1444010587.49.0.504903152106.issue25315@psf.upfronthosting.co.za>
Message-ID: <1444264138.4.0.276188750688.issue25315@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

FWIW, the decision to use __ to make the implementation more private was done at Guido's recommendation.

----------

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

From report at bugs.python.org  Thu Oct  8 02:37:51 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 08 Oct 2015 00:37:51 +0000
Subject: [issue25315] Make it clear in the collections Python source code that
 OrderedDict may be overridden
In-Reply-To: <1444010587.49.0.504903152106.issue25315@psf.upfronthosting.co.za>
Message-ID: <1444264671.16.0.446953332576.issue25315@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

One other thought:  The purpose of the source links is to help people learn.  It in no way every implies that someone should hack private implementation details.   We have a number of modules that have both a pure python implementation and a replacement with a C accelerator (heapq, counter, bisect, decimal, etc) they are all done in the same way as the OrderedDict.

I believe this report should be re-closed as the OP has consistently adopted unreasonable positions as has been unwilling to accept the responses from the devs volunteering their time to explain the basics of private, non-guaranteed implementation details.

----------

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

From report at bugs.python.org  Thu Oct  8 03:06:11 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 08 Oct 2015 01:06:11 +0000
Subject: [issue25315] Make it clear in the collections Python source code that
 OrderedDict may be overridden
In-Reply-To: <1444010587.49.0.504903152106.issue25315@psf.upfronthosting.co.za>
Message-ID: <1444266371.71.0.772669113168.issue25315@psf.upfronthosting.co.za>


R. David Murray added the comment:

What I'm suggesting it would be worth adding to the source code is a simple comment before the class definition for OrderedDict that says "This Python code may be overridden by an accelerated version of this class."  The idea being to prevent confusion if someone is exploring the source code for learning purposes but discovers it doesn't match what python actually does.

If you read all the way through the class and realize that the import after it does the override, you don't need the comment...but a learner exploring the source code is exactly the kind of person who might miss that, either by doing experiments before reading through the whole class or missing the implication of the import.

----------

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

From report at bugs.python.org  Thu Oct  8 03:18:25 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 08 Oct 2015 01:18:25 +0000
Subject: [issue25315] Make it clear in the collections Python source code that
 OrderedDict may be overridden
In-Reply-To: <1444010587.49.0.504903152106.issue25315@psf.upfronthosting.co.za>
Message-ID: <1444267105.32.0.207194099117.issue25315@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> What I'm suggesting it would be worth adding to the source code is
> a simple comment before the class definition for OrderedDict that
> says  "This Python code may be overridden by an accelerated 
> version of this class." 

Sorry, I disagree.  We've never had to do that for any of the C accelerator code in Python's history.  Also, we already have a comment at the point the import is done (and that didn't seem to matter to the OP who is just mad about the design choice itself).  The comment is in the same place as it is in heapq.py for example.  If you want to add a general FAQ entry, that would be fine.  Also, keep in mind that that the code is tested in our test suite, and it is active in other versions of Python (it is not useless as the OP suggests).

----------

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

From report at bugs.python.org  Thu Oct  8 03:22:30 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 08 Oct 2015 01:22:30 +0000
Subject: [issue25298] Add lock and rlock weakref tests
In-Reply-To: <1443779607.92.0.0397508107511.issue25298@psf.upfronthosting.co.za>
Message-ID: <1444267350.58.0.4241160233.issue25298@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This looks reasonable, though I don't see a need to backport it.

----------
assignee:  -> rhettinger
nosy: +rhettinger

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

From report at bugs.python.org  Thu Oct  8 03:41:10 2015
From: report at bugs.python.org (Peter Donis)
Date: Thu, 08 Oct 2015 01:41:10 +0000
Subject: [issue25045] smtplib throws exception TypeError: readline()
In-Reply-To: <1441813159.97.0.113522893348.issue25045@psf.upfronthosting.co.za>
Message-ID: <1444268470.22.0.646741136329.issue25045@psf.upfronthosting.co.za>


Peter Donis added the comment:

I am having the same problem; the error occurs in the call to the login method of the smtplib.SMTP object. That method takes two arguments, username and password, and that is what I am calling it with.

----------
nosy: +pdonis

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

From report at bugs.python.org  Thu Oct  8 03:43:48 2015
From: report at bugs.python.org (Pathangi Jatinshravan)
Date: Thu, 08 Oct 2015 01:43:48 +0000
Subject: [issue25228] Regression in cookie parsing with brackets and quotes
In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za>
Message-ID: <1444268628.81.0.452038936831.issue25228@psf.upfronthosting.co.za>


Pathangi Jatinshravan added the comment:

Oh not intentional. Must have clicked something by mistake

----------
versions: +Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Oct  8 03:50:32 2015
From: report at bugs.python.org (Peter Donis)
Date: Thu, 08 Oct 2015 01:50:32 +0000
Subject: [issue25045] smtplib throws exception TypeError: readline()
In-Reply-To: <1441813159.97.0.113522893348.issue25045@psf.upfronthosting.co.za>
Message-ID: <1444269032.92.0.742645703477.issue25045@psf.upfronthosting.co.za>


Peter Donis added the comment:

Investigating further, the problem appears to be with the SSLFakeFile object used for SSL/TLS connections. Here is a console session showing the issue (I have redacted the host name and port number used for privacy reasons):

>>> import smtplib
>>> smtp = smtplib.SMTP(hostname, portnum)
>>> smtp.file
<_io.BufferedReader name=3>
>>> smtp.starttls()
(220, b'2.0.0 Ready to start TLS')
>>> smtp.file
<smtplib.SSLFakeFile object at 0x1cdb3d0>
>>> smtp.file.readline(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: readline() takes exactly 1 positional argument (2 given)

----------

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

From report at bugs.python.org  Thu Oct  8 03:59:04 2015
From: report at bugs.python.org (Peter Donis)
Date: Thu, 08 Oct 2015 01:59:04 +0000
Subject: [issue25045] smtplib throws exception TypeError: readline()
In-Reply-To: <1441813159.97.0.113522893348.issue25045@psf.upfronthosting.co.za>
Message-ID: <1444269544.1.0.87149828045.issue25045@psf.upfronthosting.co.za>


Peter Donis added the comment:

It looks like this was fixed some time in between my Python 3.2 version (3.2.3) and the current one (3.2.6); the code in the current 3.2 head in the repository has a size parameter in the readline function for SSLFakeFile:

https://hg.python.org/cpython/file/3.2/Lib/smtplib.py

----------

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

From report at bugs.python.org  Thu Oct  8 04:08:11 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 08 Oct 2015 02:08:11 +0000
Subject: [issue25045] smtplib throws exception TypeError: readline()
In-Reply-To: <1441813159.97.0.113522893348.issue25045@psf.upfronthosting.co.za>
Message-ID: <1444270091.62.0.861048577341.issue25045@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks for figuring out the cause and that it has already been fixed.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

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

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: [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 04:23:06 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 08 Oct 2015 02:23:06 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1444270986.6.0.131287903537.issue25300@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Is there a runtime cost or does the hardware run the bounds checks in parallel with memory accesses?   Are the bounds set when malloc() is called or elsewhere?  I read the provided links but can't say I fully understand how it works exactly (which memory blocks are protected, where the bounds get set, when the registers are loaded, etc).

Also, I'm curious about whether we have direct controls over the bounds.  For example, in a listobject.c or _collections.c object could the bounds be tightened to only include the active data and excluded the unused part of the overallocation?

----------
nosy: +rhettinger

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

From report at bugs.python.org  Thu Oct  8 04:33:50 2015
From: report at bugs.python.org (Ned Deily)
Date: Thu, 08 Oct 2015 02:33:50 +0000
Subject: [issue25336] Segmentation fault on Mavericks consistent crashing of
 software: Please HELP!!!!!
In-Reply-To: <1444263912.5.0.0566907258707.issue25336@psf.upfronthosting.co.za>
Message-ID: <1444271630.39.0.732003574002.issue25336@psf.upfronthosting.co.za>


Ned Deily added the comment:

Without more information or a reproducible test case, it is very difficult to say what's going on.  But, from some of the file paths in the crash report, I'm guessing you are using a third-party package called OOF2 with a MacPorts-installed Python 2.7 and oof2 seems to have some extensions modules calling external libraries, like liboof2common.dylib.  There's very little to go on but it seems very unlikely that the crash is being caused by a bug in the Python interpreter or the Python standard library.  It might be due to something your program is doing or it might be some problem with the apparently complex mix of third-party libraries and Python.  You *might* have more success asking on an OOF mailing list or a MacPorts list but even so I would guess that, without a simple reproducible test case that you can share, it may be tough to get help.  You also might try running under a debugger like lldb.  Please re-open this issue if you are able to isolate the problem to the Python interpreter or Python standard library.  Good luck!

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Oct  8 05:10:42 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 08 Oct 2015 03:10:42 +0000
Subject: [issue25228] Regression in cookie parsing with brackets and quotes
In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za>
Message-ID: <1444273842.88.0.944738374492.issue25228@psf.upfronthosting.co.za>


Martin Panter added the comment:

Instead of the while loop, can?t you use something like str.find(";", i)?

----------
stage: needs patch -> patch review

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

From report at bugs.python.org  Thu Oct  8 05:35:07 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Oct 2015 03:35:07 +0000
Subject: [issue16802] fileno argument to socket.socket() undocumented
In-Reply-To: <1356711151.76.0.423836721045.issue16802@psf.upfronthosting.co.za>
Message-ID: <20151008033504.3281.97119@psf.io>


Roundup Robot added the comment:

New changeset f4606117d571 by Berker Peksag in branch '3.4':
Issue #16802: Document fileno parameter of socket.socket()
https://hg.python.org/cpython/rev/f4606117d571

New changeset 1d14675c6050 by Berker Peksag in branch '3.5':
Issue #16802: Document fileno parameter of socket.socket()
https://hg.python.org/cpython/rev/1d14675c6050

New changeset 9115c63cf3d2 by Berker Peksag in branch 'default':
Issue #16802: Document fileno parameter of socket.socket()
https://hg.python.org/cpython/rev/9115c63cf3d2

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Oct  8 05:36:07 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 08 Oct 2015 03:36:07 +0000
Subject: [issue16802] fileno argument to socket.socket() undocumented
In-Reply-To: <1356711151.76.0.423836721045.issue16802@psf.upfronthosting.co.za>
Message-ID: <1444275367.4.0.843577896842.issue16802@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6

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

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: [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 07:06:28 2015
From: report at bugs.python.org (Jung-chih Wei)
Date: Thu, 08 Oct 2015 05:06:28 +0000
Subject: [issue25338] urllib fail to check host whether it should be bypassed
In-Reply-To: <1444280721.33.0.78593437261.issue25338@psf.upfronthosting.co.za>
Message-ID: <1444280788.11.0.25262030937.issue25338@psf.upfronthosting.co.za>


Jung-chih Wei added the comment:

patch for default branch

----------
keywords: +patch
Added file: http://bugs.python.org/file40714/cpython_98592.patch

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

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


Jung-chih Wei added the comment:

patch for 2.7 branch

----------
Added file: http://bugs.python.org/file40715/cpython_98593.patch

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

From report at bugs.python.org  Thu Oct  8 07:43:54 2015
From: report at bugs.python.org (Elizabeth Myers)
Date: Thu, 08 Oct 2015 05:43:54 +0000
Subject: [issue23749] asyncio missing wrap_socket (starttls)
In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za>
Message-ID: <1444283034.04.0.544349917326.issue23749@psf.upfronthosting.co.za>


Elizabeth Myers added the comment:

> Therefore, the most convenient place to add the new API are *transports*.

I had an inkling this was the case, but I didn't know how to go about the creation of a new protocol and transport pair.

> I'm hesitant to add this API to Transport; it somehow feels wrong to put such an implementation-specific thing there. E.g. I presume you can't do this for an UDP transport.

DTLS (basically TLS over any datagram-oriented protocol, including UDP, SCTP, etc.) exists, so this makes sense, although I don't know if asyncio supports it, but the only major protocol I can think of that uses DTLS is WebRTC.

In any case, it could potentially make sense for other transport types, if not now, then in the future.

----------
nosy: +Elizacat

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

From report at bugs.python.org  Thu Oct  8 08:00:09 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Oct 2015 06:00:09 +0000
Subject: [issue24402] input() uses sys.__stdout__ instead of sys.stdout for
 prompt
In-Reply-To: <1433669452.09.0.930876867216.issue24402@psf.upfronthosting.co.za>
Message-ID: <1444284009.59.0.122827059025.issue24402@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> martin.panter
stage: patch review -> commit review

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

From report at bugs.python.org  Thu Oct  8 08:36:41 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Oct 2015 06:36:41 +0000
Subject: [issue19058] test_sys.test_ioencoding_nonascii() fails with ASCII
 locale encoding
In-Reply-To: <1379712575.68.0.606220974648.issue19058@psf.upfronthosting.co.za>
Message-ID: <1444286201.67.0.899162983753.issue19058@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What could you say about the recent patch Victor?

----------

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

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: [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:06:45 2015
From: report at bugs.python.org (Florin Papa)
Date: Thu, 08 Oct 2015 07:06:45 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1444288005.97.0.796360356323.issue25300@psf.upfronthosting.co.za>


Florin Papa added the comment:

> Is there a runtime cost or does the hardware run the bounds checks in parallel with memory accesses?   Are the bounds set when malloc() is called or elsewhere?  I read the provided links but can't say I fully understand how it works exactly (which memory blocks are protected, where the bounds get set, when the registers are loaded, etc).

There is a runtime cost associated with MPX instrumentation, which is kept to a minimum due to the use of hardware instructions and registers. When "fcheck-pointer-bounds -mmpx" compilation flags are set, instrumentation is enabled for _all_ memory acceses in the code. This means that when you perform a malloc, the pointer bounds will be set inside the malloc call, and then passed on to your variable. Alternatively, you can manually instrument only regions of interest in your code using GCC functions described here [1].

> Also, I'm curious about whether we have direct controls over the bounds.  For example, in a listobject.c or _collections.c object could the bounds be tightened to only include the active data and excluded the unused part of the overallocation?

Please see __bnd_set_ptr_bounds here [1] for bound manipulation. In order to have a better understanding of what happens when using MPX, I suggest writing a simple C program and look at the assembly code generated (MPX instructions and registers begin with bnd). You can use the following steps:

gcc -g -c test.c -O2 -fcheck-pointer-bounds -mmpx
objdump -d -M intel -S test.o


[1] https://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler#Compiler_intrinsics_and_attributes

----------

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

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: [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: [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 10:02:32 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 08 Oct 2015 08:02:32 +0000
Subject: [issue21373] robotparser: Automatically call modified function in
 read()
In-Reply-To: <1398689725.23.0.532137440879.issue21373@psf.upfronthosting.co.za>
Message-ID: <1444291352.89.0.878795425333.issue21373@psf.upfronthosting.co.za>


Berker Peksag added the comment:

This is already fixed by changeset 4ea86cd87f95 in issue 21469 (2.7 and 3.4+). Thanks for the report and for the patch.

----------
nosy: +berker.peksag
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Oct  8 11:17:46 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Oct 2015 09:17:46 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1444295866.08.0.420592499787.issue25300@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> This means that when you perform a malloc, the pointer bounds will be set inside the malloc call, and then passed on to your variable.

For this to be useful in Python, you would have to annotate Python's small object allocator to designate it as a malloc()-like function, no?

----------

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

From report at bugs.python.org  Thu Oct  8 11:27:17 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Oct 2015 09:27:17 +0000
Subject: [issue16099] robotparser doesn't support request rate and crawl delay
 parameters
In-Reply-To: <1349096305.17.0.983395980337.issue16099@psf.upfronthosting.co.za>
Message-ID: <20151008092710.55456.47848@psf.io>


Roundup Robot added the comment:

New changeset dbed7cacfb7e by Berker Peksag in branch 'default':
Issue #16099: RobotFileParser now supports Crawl-delay and Request-rate
https://hg.python.org/cpython/rev/dbed7cacfb7e

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Oct  8 11:28:38 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 08 Oct 2015 09:28:38 +0000
Subject: [issue25311] Add f-string support to tokenize.py
In-Reply-To: <1443979407.62.0.707305717475.issue25311@psf.upfronthosting.co.za>
Message-ID: <1444296518.17.0.410127414042.issue25311@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Yes, both 'fr' and 'rf' need to be supported (and all upper/lower variants). And in the future, maybe 'fb' (and 'rfb', 'bfr', ...).

Unfortunately, the regex doesn't scale well for all of the combinations.

----------

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

From report at bugs.python.org  Thu Oct  8 11:29:39 2015
From: report at bugs.python.org (Florin Papa)
Date: Thu, 08 Oct 2015 09:29:39 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1444296579.84.0.74729825377.issue25300@psf.upfronthosting.co.za>


Florin Papa added the comment:

No modifications need to be made to the small object allocator. The malloc situation was just an example, it does not mean that setting pointer bounds occurs only in a malloc call. It also occurs when you declare a static array or when you initialize a new pointer:

int *x = (int*)malloc(10 * sizeof(int));
int *y = x; // the bounds for x will be passed on to y

When using "fcheck-pointer-bounds -mmpx" _all_ memory accesses will be instrumented.

----------

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

From report at bugs.python.org  Thu Oct  8 11:34:07 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Oct 2015 09:34:07 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1444296847.14.0.668795886911.issue25300@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The small object allocator uses large mmap-allocated arenas of 256 KB (IIRC) and carves small objects out of it.  So unless the pointer returned by PyObject_Malloc() has its bounds set manually using one of the intrinsic functions (*), MPX would believe the bounds of small objects are the bounds of the 256 KB arenas containing them, right?

(*) I'm assuming __bnd_set_ptr_bounds()

----------

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

From report at bugs.python.org  Thu Oct  8 11:34:21 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 08 Oct 2015 09:34:21 +0000
Subject: [issue16099] robotparser doesn't support request rate and crawl delay
 parameters
In-Reply-To: <1349096305.17.0.983395980337.issue16099@psf.upfronthosting.co.za>
Message-ID: <1444296861.57.0.291050443198.issue16099@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I've finally committed your patch to default. Thank you for not giving up, Nikolay :)

Note that currently the link in the example section doesn't work. I will open a new issue for that.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6 -Python 3.5

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

From report at bugs.python.org  Thu Oct  8 11:37:42 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Oct 2015 09:37:42 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1444296847.14.0.668795886911.issue25300@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbZXP7Mc+Hpuu7U0UoOP3=Rauwwnwf7Zn61t_QfE4mjaQ@mail.gmail.com>


STINNER Victor added the comment:

FYI In the discussion of the PEP 445 "Add new APIs to customize Python
memory allocators" it was proposed to add runtime option to choose the
memory allocator. At least for debug purpose, it would help to be able
to use malloc() for *all* Python memory allocations. Would it help to
find more bugs with MPX?

It's not possible to disable our fast allocator for small objects,
disabling it has a high cost on performances (Python would be much
slower).

----------

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

From report at bugs.python.org  Thu Oct  8 11:40:24 2015
From: report at bugs.python.org (Mahmoud Hashemi)
Date: Thu, 08 Oct 2015 09:40:24 +0000
Subject: [issue25341] File mode wb+ appears as rb+
In-Reply-To: <1444290178.48.0.0607111061258.issue25341@psf.upfronthosting.co.za>
Message-ID: <1444297224.54.0.239776512798.issue25341@psf.upfronthosting.co.za>


Changes by Mahmoud Hashemi <mahmoud at hatnote.com>:


----------
nosy: +mahmoud

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

From report at bugs.python.org  Thu Oct  8 11:40:46 2015
From: report at bugs.python.org (Alex Warhawk)
Date: Thu, 08 Oct 2015 09:40:46 +0000
Subject: [issue19500] Error when connecting to FTPS servers not supporting SSL
 session resuming
In-Reply-To: <1383624130.64.0.185541289049.issue19500@psf.upfronthosting.co.za>
Message-ID: <1444297246.67.0.695183733661.issue19500@psf.upfronthosting.co.za>


Alex Warhawk added the comment:

I have re-targeted the patch for 3.6. It is not a 1 to 1 port of the prior one, but quite similar.

----------
Added file: http://bugs.python.org/file40716/implement_ssl_session_reuse_3.6.patch

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

From report at bugs.python.org  Thu Oct  8 12:09:09 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 08 Oct 2015 10:09:09 +0000
Subject: [issue21475] Support the Sitemap extension in robotparser
In-Reply-To: <1399858557.27.0.633505879036.issue21475@psf.upfronthosting.co.za>
Message-ID: <1444298949.77.0.658501963653.issue21475@psf.upfronthosting.co.za>


Berker Peksag added the comment:

The Crawl-delay part(issue 16099) is now committed.

----------
stage:  -> needs patch
title: Support the Sitemap and Crawl-delay extensions in robotparser -> Support the Sitemap extension in robotparser
versions: +Python 3.6 -Python 3.5

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

From report at bugs.python.org  Thu Oct  8 12:10:52 2015
From: report at bugs.python.org (Florin Papa)
Date: Thu, 08 Oct 2015 10:10:52 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1444299052.57.0.610076498405.issue25300@psf.upfronthosting.co.za>


Florin Papa added the comment:

Hi Antoine,

I understand the problem with the small object allocator now. I will have a closer look at it and come back with a solution. Thank you for pointing this out.

----------

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

From report at bugs.python.org  Thu Oct  8 12:35:05 2015
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 08 Oct 2015 10:35:05 +0000
Subject: [issue19500] Error when connecting to FTPS servers not supporting SSL
 session resuming
In-Reply-To: <1383624130.64.0.185541289049.issue19500@psf.upfronthosting.co.za>
Message-ID: <1444300505.19.0.976099020136.issue19500@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thanks for your patch. There might be a simpler way. By default a SSLContext only caches server sessions. You can enable client session caching with:

  SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_CLIENT)

This may be sufficient for FTP over TLS since both sockets are created from the same context.

 
The new patch has a flaw. With the new SSLSession object a user could attempt to reuse a SSLSession with a different SSLContext. That's going to break OpenSSL.

>From SSL_set_session(3)

NOTES
       SSL_SESSION objects keep internal link information about the session cache list, when being inserted into one SSL_CTX object's session cache.  One SSL_SESSION object, regardless of its reference count, must therefore only be used with one SSL_CTX object (and the SSL objects created from this SSL_CTX object).

----------

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

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: [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 13:59:16 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Thu, 08 Oct 2015 11:59:16 +0000
Subject: [issue25342] json
In-Reply-To: <1444305459.69.0.847555547745.issue25342@psf.upfronthosting.co.za>
Message-ID: <0E4C8DEA-DAE2-4EF7-9976-BD099157F9F8@wirtel.be>


New submission from St?phane Wirtel:

What the details of this issue?
On 8 Oct 2015, at 13:57, Remi Pointel wrote:

> 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>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/stephane%40wirtel.be

----------
nosy: +matrixise

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

From report at bugs.python.org  Thu Oct  8 14:00:29 2015
From: report at bugs.python.org (Remi Pointel)
Date: Thu, 08 Oct 2015 12:00:29 +0000
Subject: [issue25342] json
In-Reply-To: <0E4C8DEA-DAE2-4EF7-9976-BD099157F9F8@wirtel.be>
Message-ID: <1444305629.38.0.989121403094.issue25342@psf.upfronthosting.co.za>


Remi Pointel added the comment:

Sorry I clicked on "create" before adding info in comment.

When I run the test_json suite on OpenBSD, I have a segfault:

$ egdb ./python            
GNU gdb (GDB) 7.10
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-openbsd5.8".
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 ./python...done.
(gdb) set env PYTHONPATH ./Lib
(gdb) set env LD_LIBRARY_PATH .
(gdb) set args ./Lib/test/test_json/
(gdb) r
Starting program: /home/remi/dev/cpython/python ./Lib/test/test_json/
.............................................s......................................................
Program received signal SIGSEGV, Segmentation fault.
0x00001dd119cf9e0d in PyEval_EvalFrameEx (f=<error reading variable: Cannot access memory at address 0x7f7fffbda518>, throwflag=<error reading variable: Cannot access memory at address 0x7f7fffbda514>) at Python/ceval.c:798
(gdb) bt
#0  0x00001dd119cf9e0d in PyEval_EvalFrameEx (f=<error reading variable: Cannot access memory at address 0x7f7fffbda518>, throwflag=<error reading variable: Cannot access memory at address 0x7f7fffbda514>)
    at Python/ceval.c:798
#1  0x00001dd119dedbe3 in gen_send_ex (gen=0x1dd35dc11c90, arg=None, exc=0) at Objects/genobject.c:125
#2  0x00001dd119dee6af in _PyGen_Send (gen=0x1dd35dc11c90, arg=None) at Objects/genobject.c:223
#3  0x00001dd119d0267b in PyEval_EvalFrameEx (
    f=Frame 0x1dd32e645c38, for file /home/remi/dev/cpython/Lib/json/encoder.py, line 324, in _iterencode_list (lst=[<complex at remote 0x1dd3de8f74f0>], _current_indent_level=0, buf='[', newline_indent=None, separator=', ', first=False, value=<complex at remote 0x1dd3de8f74f0>, chunks=<generator at remote 0x1dd35dc11c90>), throwflag=0) at Python/ceval.c:2038
#4  0x00001dd119dedbe3 in gen_send_ex (gen=0x1dd35dc11c08, arg=None, exc=0) at Objects/genobject.c:125
#5  0x00001dd119dee6af in _PyGen_Send (gen=0x1dd35dc11c08, arg=None) at Objects/genobject.c:223
#6  0x00001dd119d0267b in PyEval_EvalFrameEx (f=Frame 0x1dd39a980c38, for file /home/remi/dev/cpython/Lib/json/encoder.py, line 427, in _iterencode (o=[<complex at remote 0x1dd3de8f74f0>], _current_indent_level=0), 
    throwflag=0) at Python/ceval.c:2038
#7  0x00001dd119dedbe3 in gen_send_ex (gen=0x1dd35dc11b80, arg=None, exc=0) at Objects/genobject.c:125
#8  0x00001dd119dee6af in _PyGen_Send (gen=0x1dd35dc11b80, arg=None) at Objects/genobject.c:223
#9  0x00001dd119d0267b in PyEval_EvalFrameEx (f=Frame 0x1dd39a980838, for file /home/remi/dev/cpython/Lib/json/encoder.py, line 437, in _iterencode (o=[<complex at remote 0x1dd3de8f74f0>], _current_indent_level=0), 
    throwflag=0) at Python/ceval.c:2038
#10 0x00001dd119dedbe3 in gen_send_ex (gen=0x1dd35dc11af8, arg=None, exc=0) at Objects/genobject.c:125
#11 0x00001dd119dee6af in _PyGen_Send (gen=0x1dd35dc11af8, arg=None) at Objects/genobject.c:223
#12 0x00001dd119d0267b in PyEval_EvalFrameEx (
    f=Frame 0x1dd3b9e32c38, for file /home/remi/dev/cpython/Lib/json/encoder.py, line 324, in _iterencode_list (lst=[<complex at remote 0x1dd3de8f74f0>], _current_indent_level=0, buf='[', newline_indent=None, separator=', ', first=False, value=<complex at remote 0x1dd3de8f74f0>, chunks=<generator at remote 0x1dd35dc11af8>), throwflag=0) at Python/ceval.c:2038
#13 0x00001dd119dedbe3 in gen_send_ex (gen=0x1dd35dc11a70, arg=None, exc=0) at Objects/genobject.c:125
#14 0x00001dd119dee6af in _PyGen_Send (gen=0x1dd35dc11a70, arg=None) at Objects/genobject.c:223
#15 0x00001dd119d0267b in PyEval_EvalFrameEx (f=Frame 0x1dd32e645838, for file /home/remi/dev/cpython/Lib/json/encoder.py, line 427, in _iterencode (o=[<complex at remote 0x1dd3de8f74f0>], _current_indent_level=0), 
    throwflag=0) at Python/ceval.c:2038
#16 0x00001dd119dedbe3 in gen_send_ex (gen=0x1dd35dc119e8, arg=None, exc=0) at Objects/genobject.c:125
#17 0x00001dd119dee6af in _PyGen_Send (gen=0x1dd35dc119e8, arg=None) at Objects/genobject.c:223
#18 0x00001dd119d0267b in PyEval_EvalFrameEx (f=Frame 0x1dd39a980438, for file /home/remi/dev/cpython/Lib/json/encoder.py, line 437, in _iterencode (o=[<complex at remote 0x1dd3de8f74f0>], _current_indent_level=0), 
    throwflag=0) at Python/ceval.c:2038
#19 0x00001dd119dedbe3 in gen_send_ex (gen=0x1dd35dc11960, arg=None, exc=0) at Objects/genobject.c:125
#20 0x00001dd119dee6af in _PyGen_Send (gen=0x1dd35dc11960, arg=None) at Objects/genobject.c:223
#21 0x00001dd119d0267b in PyEval_EvalFrameEx (
    f=Frame 0x1dd3b9e32838, for file /home/remi/dev/cpython/Lib/json/encoder.py, line 324, in _iterencode_list (lst=[<complex at remote 0x1dd3de8f74f0>], _current_indent_level=0, buf='[', newline_indent=None, separator=', ', first=False, value=<complex at remote 0x1dd3de8f74f0>, chunks=<generator at remote 0x1dd35dc11960>), throwflag=0) at Python/ceval.c:2038
#22 0x00001dd119dedbe3 in gen_send_ex (gen=0x1dd35dc118d8, arg=None, exc=0) at Objects/genobject.c:125
#23 0x00001dd119dee6af in _PyGen_Send (gen=0x1dd35dc118d8, arg=None) at Objects/genobject.c:223
#24 0x00001dd119d0267b in PyEval_EvalFrameEx (f=Frame 0x1dd3b9e32038, for file /home/remi/dev/cpython/Lib/json/encoder.py, line 427, in _iterencode (o=[<complex at remote 0x1dd3de8f74f0>], _current_indent_level=0), 
    throwflag=0) at Python/ceval.c:2038
#25 0x00001dd119dedbe3 in gen_send_ex (gen=0x1dd35dc11850, arg=None, exc=0) at Objects/genobject.c:125
#26 0x00001dd119dee6af in _PyGen_Send (gen=0x1dd35dc11850, arg=None) at Objects/genobject.c:223
#27 0x00001dd119d0267b in PyEval_EvalFrameEx (f=Frame 0x1dd3a36ba438, for file /home/remi/dev/cpython/Lib/json/encoder.py, line 437, in _iterencode (o=[<complex at remote 0x1dd3de8f74f0>], _current_indent_level=0), 
    throwflag=0) at Python/ceval.c:2038
#28 0x00001dd119dedbe3 in gen_send_ex (gen=0x1dd35dc117c8, arg=None, exc=0) at Objects/genobject.c:125
#29 0x00001dd119dee6af in _PyGen_Send (gen=0x1dd35dc117c8, arg=None) at Objects/genobject.c:223
#30 0x00001dd119d0267b in PyEval_EvalFrameEx (
    f=Frame 0x1dd32e645438, for file /home/remi/dev/cpython/Lib/json/encoder.py, line 324, in _iterencode_list (lst=[<complex at remote 0x1dd3de8f74f0>], _current_indent_level=0, buf='[', newline_indent=None, separator=', ', first=False, value=<complex at remote 0x1dd3de8f74f0>, chunks=<generator at remote 0x1dd35dc117c8>), throwflag=0) at Python/ceval.c:2038
#31 0x00001dd119dedbe3 in gen_send_ex (gen=0x1dd35dc11740, arg=None, exc=0) at Objects/genobject.c:125
#32 0x00001dd119dee6af in _PyGen_Send (gen=0x1dd35dc11740, arg=None) at Objects/genobject.c:223
#33 0x00001dd119d0267b in PyEval_EvalFrameEx (f=Frame 0x1dd3b9e32438, for file /home/remi/dev/cpython/Lib/json/encoder.py, line 427, in _iterencode (o=[<complex at remote 0x1dd3de8f74f0>], _current_indent_level=0), 
    throwflag=0) at Python/ceval.c:2038
#34 0x00001dd119dedbe3 in gen_send_ex (gen=0x1dd35dc116b8, arg=None, exc=0) at Objects/genobject.c:125
#35 0x00001dd119dee6af in _PyGen_Send (gen=0x1dd35dc116b8, arg=None) at Objects/genobject.c:223
#36 0x00001dd119d0267b in PyEval_EvalFrameEx (f=Frame 0x1dd3a36ba038, for file /home/remi/dev/cpython/Lib/json/encoder.py, line 437, in _iterencode (o=[<complex at remote 0x1dd3de8f74f0>], _current_indent_level=0), 
    throwflag=0) at Python/ceval.c:2038
#37 0x00001dd119dedbe3 in gen_send_ex (gen=0x1dd35dc11630, arg=None, exc=0) at Objects/genobject.c:125
#38 0x00001dd119dee6af in _PyGen_Send (gen=0x1dd35dc11630, arg=None) at Objects/genobject.c:223

----------
versions: +Python 3.6

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

From report at bugs.python.org  Thu Oct  8 14:02:00 2015
From: report at bugs.python.org (Remi Pointel)
Date: Thu, 08 Oct 2015 12:02:00 +0000
Subject: [issue25342] test_json segfault on OpenBSD
In-Reply-To: <0E4C8DEA-DAE2-4EF7-9976-BD099157F9F8@wirtel.be>
Message-ID: <1444305720.99.0.971435501956.issue25342@psf.upfronthosting.co.za>


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


----------
title: json -> test_json segfault on OpenBSD

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

From report at bugs.python.org  Thu Oct  8 02:25:14 2015
From: report at bugs.python.org (CM)
Date: Thu, 08 Oct 2015 00:25:14 +0000
Subject: [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 14:11:09 2015
From: report at bugs.python.org (Remi Pointel)
Date: Thu, 08 Oct 2015 12:11:09 +0000
Subject: [issue25342] test_json segfault on OpenBSD
In-Reply-To: <0E4C8DEA-DAE2-4EF7-9976-BD099157F9F8@wirtel.be>
Message-ID: <1444306269.0.0.0308781799696.issue25342@psf.upfronthosting.co.za>


Remi Pointel added the comment:

It fails on test_endless_recursion:

$ LD_LIBRARY_PATH=. PYTHONPATH=./Lib/ ./python ./Lib/test/test_json -v

test_endless_recursion (test.test_json.test_recursion.TestPyRecursion) ... zsh: segmentation fault (core dumped)

----------

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

From report at bugs.python.org  Thu Oct  8 14:18:59 2015
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 08 Oct 2015 12:18:59 +0000
Subject: [issue25342] test_json segfault on OpenBSD
In-Reply-To: <0E4C8DEA-DAE2-4EF7-9976-BD099157F9F8@wirtel.be>
Message-ID: <1444306739.04.0.0509690323846.issue25342@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Try setting the stack size to 8MB (the default on Linux) in login.conf.

----------
nosy: +skrah

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

From report at bugs.python.org  Thu Oct  8 14:32:53 2015
From: report at bugs.python.org (Remi Pointel)
Date: Thu, 08 Oct 2015 12:32:53 +0000
Subject: [issue25342] test_json segfault on OpenBSD
In-Reply-To: <0E4C8DEA-DAE2-4EF7-9976-BD099157F9F8@wirtel.be>
Message-ID: <1444307573.51.0.69912839835.issue25342@psf.upfronthosting.co.za>


Remi Pointel added the comment:

It's good when I entered "ulimit -s 8192". Sorry for the noise...

----------

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

From report at bugs.python.org  Thu Oct  8 14:39:11 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 08 Oct 2015 12:39:11 +0000
Subject: [issue25338] urllib bypasses all hosts if proxyoverride includes an
 empty element
In-Reply-To: <1444280721.33.0.78593437261.issue25338@psf.upfronthosting.co.za>
Message-ID: <1444307951.45.0.782593913988.issue25338@psf.upfronthosting.co.za>


R. David Murray added the comment:

How does IE itself behave in this case?

Also, we should have a test to go along with the fix.

----------
nosy: +r.david.murray
stage:  -> test needed
title: urllib fail to check host whether it should be bypassed -> urllib bypasses all hosts if proxyoverride includes an empty element
versions:  -Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Oct  8 14:43:10 2015
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 08 Oct 2015 12:43:10 +0000
Subject: [issue25342] test_json segfault on OpenBSD
In-Reply-To: <0E4C8DEA-DAE2-4EF7-9976-BD099157F9F8@wirtel.be>
Message-ID: <1444308190.42.0.238935198209.issue25342@psf.upfronthosting.co.za>


Stefan Krah added the comment:

It's not noise, we also have problems on Windows with test_json.

In theory we should set Py_DEFAULT_RECURSION_LIMIT in Python/ceval.c
to appropriate values for the default OS stack sizes in order to get
a proper RuntimeError instead of a segfault.

For OpenBSD it's clearly too high for the default.  Could you try
to find a safe value (perhaps 500 instead of 1000) for OpenBSD's
default?

----------

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

From report at bugs.python.org  Thu Oct  8 14:55:12 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Oct 2015 12:55:12 +0000
Subject: [issue25342] test_json segfault on OpenBSD
In-Reply-To: <0E4C8DEA-DAE2-4EF7-9976-BD099157F9F8@wirtel.be>
Message-ID: <1444308912.27.0.335676483332.issue25342@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Would it be possible to compute the recursion limit depending on the current maximum C stack size? At least estimate it? I guess the sys.getdefaultlimit() is 1000 is an arbitrary value. I also know that the effective limit depends on the memory allocated on the stack by C functions. Calling a Python function and a function implemented in C is different :-/

----------
nosy: +haypo

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

From report at bugs.python.org  Thu Oct  8 15:16:25 2015
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 08 Oct 2015 13:16:25 +0000
Subject: [issue25342] test_json segfault on OpenBSD
In-Reply-To: <0E4C8DEA-DAE2-4EF7-9976-BD099157F9F8@wirtel.be>
Message-ID: <1444310185.95.0.546862941859.issue25342@psf.upfronthosting.co.za>


Stefan Krah added the comment:

The ratio (1000/8MB) seems to be stable on Linux. Perhaps we could
write a getrlimit program for ./configure to get the stack size and
adjust the recursion limit to keep the ratio the same.

It's just an estimate of course.

----------

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

From report at bugs.python.org  Thu Oct  8 15:20:41 2015
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 08 Oct 2015 13:20:41 +0000
Subject: [issue25342] test_json segfault on OpenBSD
In-Reply-To: <0E4C8DEA-DAE2-4EF7-9976-BD099157F9F8@wirtel.be>
Message-ID: <1444310441.55.0.0638598998232.issue25342@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Or did you want to compute it at runtime?  Actually, why not?

----------

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

From report at bugs.python.org  Thu Oct  8 16:10:37 2015
From: report at bugs.python.org (Sebastian Rittau)
Date: Thu, 08 Oct 2015 14:10:37 +0000
Subject: [issue20504] cgi.FieldStorage, multipart, missing Content-Length
In-Reply-To: <1391463199.17.0.394387661768.issue20504@psf.upfronthosting.co.za>
Message-ID: <1444313437.12.0.258856129146.issue20504@psf.upfronthosting.co.za>


Sebastian Rittau added the comment:

Is there any progress on this? The fix seems trivial.

----------

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

From report at bugs.python.org  Thu Oct  8 16:19:50 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Oct 2015 14:19:50 +0000
Subject: [issue20504] cgi.FieldStorage, multipart, missing Content-Length
In-Reply-To: <1391463199.17.0.394387661768.issue20504@psf.upfronthosting.co.za>
Message-ID: <1444313990.4.0.81631942428.issue20504@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

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

From report at bugs.python.org  Thu Oct  8 16:26:19 2015
From: report at bugs.python.org (Pathangi Jatinshravan)
Date: Thu, 08 Oct 2015 14:26:19 +0000
Subject: [issue25228] Regression in cookie parsing with brackets and quotes
In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za>
Message-ID: <1444314379.96.0.528791790251.issue25228@psf.upfronthosting.co.za>


Pathangi Jatinshravan added the comment:

Hi, I've made the change to use str.find() and removed the while loop, can you take a look at it?

----------
Added file: http://bugs.python.org/file40717/patch.diff

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

From report at bugs.python.org  Thu Oct  8 16:57:57 2015
From: report at bugs.python.org (Alex Warhawk)
Date: Thu, 08 Oct 2015 14:57:57 +0000
Subject: [issue19500] Error when connecting to FTPS servers not supporting SSL
 session resuming
In-Reply-To: <1383624130.64.0.185541289049.issue19500@psf.upfronthosting.co.za>
Message-ID: <1444316277.02.0.487323775715.issue19500@psf.upfronthosting.co.za>


Alex Warhawk added the comment:

Thanks for the heads up Christian I'll try enabling client session caching. If this does not work I'll try to adapt the patch to only allow session reusing within the same context.

----------

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

From report at bugs.python.org  Thu Oct  8 17:02:58 2015
From: report at bugs.python.org (neic)
Date: Thu, 08 Oct 2015 15:02:58 +0000
Subject: [issue25008] Deprecate smtpd (based on deprecated asyncore/asynchat):
 write a new smtp server with asyncio
In-Reply-To: <1441472893.95.0.412611892234.issue25008@psf.upfronthosting.co.za>
Message-ID: <1444316578.79.0.0786904269835.issue25008@psf.upfronthosting.co.za>


Changes by neic <neic at neic.dk>:


----------
nosy: +neic

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

From report at bugs.python.org  Thu Oct  8 17:34:21 2015
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 08 Oct 2015 15:34:21 +0000
Subject: [issue5380] pty.read raises IOError when slave pty device is closed
In-Reply-To: <1235721814.23.0.522352333065.issue5380@psf.upfronthosting.co.za>
Message-ID: <1444318461.12.0.0251922423267.issue5380@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

TLPI (The Linux Programming Interface book) says about the pty implementation on linux, at section 5 of chapter 64:

    If we close all file descriptors referring to the pseudoterminal slave, then:
    a) A read() from the master device fails with the error EIO. (On some other UNIX implementations, a read() returns end-of-file in this case.)

and also adds this (which is slightly off topic here):

    b)  A write() to the master device succeeds, unless the input queue of the slave device is full, in which case the write() blocks. If the slave device is subsequently reopened, these bytes can be read.

    UNIX implementations vary widely in their behavior for the last case. On some UNIX implementations, write() fails with the error EIO. On other implementations, write() succeeds, but the output bytes are discarded (i.e., they can?t be read if the slave is reopened). In general, these variations don?t present a problem. Normally, the process on the master side detects that the slave has been closed because a read() from the master returns end-of-file or fails. At this point, the process performs no further writes to the master.

----------
nosy: +xdegaye

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

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: [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 17:43:17 2015
From: report at bugs.python.org (Dima Tisnek)
Date: Thu, 08 Oct 2015 15:43:17 +0000
Subject: [issue25343] Document atomic operations on builtin types
In-Reply-To: <1444318986.11.0.257913016756.issue25343@psf.upfronthosting.co.za>
Message-ID: <1444318997.91.0.0449053053677.issue25343@psf.upfronthosting.co.za>


Changes by Dima Tisnek <dimaqq at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
type:  -> enhancement

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

From report at bugs.python.org  Thu Oct  8 17:43:57 2015
From: report at bugs.python.org (Steve Dower)
Date: Thu, 08 Oct 2015 15:43:57 +0000
Subject: [issue25157] Installing Python 3.5.0 32bit on Windows 8.1 64bit
 system gives Error 0x80240017
In-Reply-To: <1442526643.4.0.412457342038.issue25157@psf.upfronthosting.co.za>
Message-ID: <1444319037.65.0.698650196119.issue25157@psf.upfronthosting.co.za>


Steve Dower added the comment:

Shirshendu - any luck with eryksun's suggestions?

----------

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

From report at bugs.python.org  Thu Oct  8 17:52:53 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Oct 2015 15:52:53 +0000
Subject: [issue25342] test_json segfault on OpenBSD
In-Reply-To: <1444310441.55.0.0638598998232.issue25342@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZYfynZZS=O4u3ouZ+6-86tH__FSYi7UYROWOM-QmxpWQ@mail.gmail.com>


STINNER Victor added the comment:

Stefan Krah added the comment:
> Or did you want to compute it at runtime?  Actually, why not?

I'm asking to adjust the limit at _runtime_. getrlimit() is not
something static, it's common to modify them manually for the current
shell process (and child process), or system-wide.

----------

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

From report at bugs.python.org  Thu Oct  8 17:55:46 2015
From: report at bugs.python.org (TAKASE Arihiro)
Date: Thu, 08 Oct 2015 15:55:46 +0000
Subject: [issue25161] Missing periods at the end of sentences
In-Reply-To: <1442560890.27.0.253223646248.issue25161@psf.upfronthosting.co.za>
Message-ID: <1444319746.95.0.768076912444.issue25161@psf.upfronthosting.co.za>


TAKASE Arihiro added the comment:

Thank you for reviewing.

This is an updated patch for 3.x.

----------
Added file: http://bugs.python.org/file40718/periods_v2.patch

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

From report at bugs.python.org  Thu Oct  8 17:56:00 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Oct 2015 15:56:00 +0000
Subject: [issue24848] Warts in UTF-7 error handling
In-Reply-To: <1439364965.73.0.526700604341.issue24848@psf.upfronthosting.co.za>
Message-ID: <1444319760.22.0.608534188949.issue24848@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The difference between 2.7 and 3.x is that 2.7 uses isalnum() in IS_BASE64, and 3.x test concrete ranges. Therefore depending on platform and locale 2.7 can accept wrong bytes as BASE64 characters and return incorrect result. Following patch makes 2.7 code the same as 3.x. Tests are changed to fail with large probability with unpatched code ('\xe1' is an alnum on almost all 8-bit locales).

----------
Added file: http://bugs.python.org/file40719/decode_utf7_locale-2.7.patch

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

From report at bugs.python.org  Thu Oct  8 18:03:51 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Oct 2015 16:03:51 +0000
Subject: [issue25342] test_json segfault on OpenBSD
In-Reply-To: <0E4C8DEA-DAE2-4EF7-9976-BD099157F9F8@wirtel.be>
Message-ID: <1444320231.88.0.382995598516.issue25342@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Duplicates and related issues: issue25329, issue25222, issue24999, issue22984, issue18075, issue12980.

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Thu Oct  8 18:04:59 2015
From: report at bugs.python.org (TAKASE Arihiro)
Date: Thu, 08 Oct 2015 16:04:59 +0000
Subject: [issue25161] Missing periods at the end of sentences
In-Reply-To: <1442560890.27.0.253223646248.issue25161@psf.upfronthosting.co.za>
Message-ID: <1444320299.18.0.929378291444.issue25161@psf.upfronthosting.co.za>


TAKASE Arihiro added the comment:

And this is an updated patch for 2.7.

----------
Added file: http://bugs.python.org/file40720/periods-2.7_v2.patch

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

From report at bugs.python.org  Thu Oct  8 18:08:17 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Oct 2015 16:08:17 +0000
Subject: [issue23919] [Windows] test_os fails several C-level assertions
In-Reply-To: <1428806067.72.0.786420001732.issue23919@psf.upfronthosting.co.za>
Message-ID: <20151008160804.128834.18917@psf.io>


Roundup Robot added the comment:

New changeset 69c4fa62b608 by Steve Dower in branch '3.5':
Issue #23919: Prevents assert dialogs appearing in the test suite.
https://hg.python.org/cpython/rev/69c4fa62b608

New changeset 62897db9ae51 by Steve Dower in branch 'default':
Issue #23919: Prevents assert dialogs appearing in the test suite.
https://hg.python.org/cpython/rev/62897db9ae51

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Oct  8 18:15:11 2015
From: report at bugs.python.org (Steve Dower)
Date: Thu, 08 Oct 2015 16:15:11 +0000
Subject: [issue23919] [Windows] test_os fails several C-level assertions
In-Reply-To: <1428806067.72.0.786420001732.issue23919@psf.upfronthosting.co.za>
Message-ID: <1444320911.41.0.0279507048753.issue23919@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Oct  8 18:25:15 2015
From: report at bugs.python.org (Shirshendu Bhowmick)
Date: Thu, 08 Oct 2015 16:25:15 +0000
Subject: [issue25157] Installing Python 3.5.0 32bit on Windows 8.1 64bit
 system gives Error 0x80240017
In-Reply-To: <1442526643.4.0.412457342038.issue25157@psf.upfronthosting.co.za>
Message-ID: <1444321515.19.0.158039064866.issue25157@psf.upfronthosting.co.za>


Shirshendu Bhowmick added the comment:

Installing that update the system says this update is not applicable for your computer and it does not generates any .evtx file.

----------

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

From report at bugs.python.org  Thu Oct  8 18:29:14 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 08 Oct 2015 16:29:14 +0000
Subject: [issue5380] pty.read raises IOError when slave pty device is closed
In-Reply-To: <1235721814.23.0.522352333065.issue5380@psf.upfronthosting.co.za>
Message-ID: <1444321754.74.0.125461992355.issue5380@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Honestly, Antoine's patch looks reasonable to me (except that the names of the test modules perpetuate the confusion that pipes and ptys are similar).

Can someone just port that to 3.6? (The change in semantics is big enough that I don't think we should shove it into a bugfix release.)

In other news, the pty.py module is pretty pathetic. Kill or improve? It feels like one of those "included" batteries that runs out of juice after 5 minutes.

----------

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

From report at bugs.python.org  Thu Oct  8 19:01:25 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Oct 2015 17:01:25 +0000
Subject: [issue25089] Can't run Python Launcher on Windows
In-Reply-To: <1442184297.36.0.379341480925.issue25089@psf.upfronthosting.co.za>
Message-ID: <20151008170113.97720.57578@psf.io>


Roundup Robot added the comment:

New changeset 1e99ba6b7c98 by Steve Dower in branch '3.5':
Issue #25089: Adds logging to installer for case where launcher is not selected on upgrade.
https://hg.python.org/cpython/rev/1e99ba6b7c98

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Oct  8 19:02:44 2015
From: report at bugs.python.org (Steve Dower)
Date: Thu, 08 Oct 2015 17:02:44 +0000
Subject: [issue25089] Can't run Python Launcher on Windows
In-Reply-To: <1442184297.36.0.379341480925.issue25089@psf.upfronthosting.co.za>
Message-ID: <1444323764.81.0.699443458732.issue25089@psf.upfronthosting.co.za>


Steve Dower added the comment:

Hopefully with the extra logging we'll be able to see if something is failing at the point of detection. Any failure here (permissions in registry, etc.) will cause the launcher to not be installed on upgrade (which might be the same as removing it... I need to spend more time working through the dependencies involved here because they are messy).

----------

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

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: [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:07:52 2015
From: report at bugs.python.org (eryksun)
Date: Thu, 08 Oct 2015 17:07:52 +0000
Subject: [issue25157] Installing Python 3.5.0 32bit on Windows 8.1 64bit
 system gives Error 0x80240017
In-Reply-To: <1442526643.4.0.412457342038.issue25157@psf.upfronthosting.co.za>
Message-ID: <1444324072.71.0.172302060348.issue25157@psf.upfronthosting.co.za>


eryksun added the comment:

> it does not generates any .evtx file

Start a command prompt; change to the directory that has the MSU, and run it with the option "/log:kb2999226.evtx". For me this creates kb2999226.evtx in the current directory, which can be converted to XML using wevtutil. If this doesn't create a log file, then possibly the .msu file association is incorrect. In that case, try running wusa.exe directly, e.g.

    "%SystemRoot%\System32\wusa.exe" Windows8.1-KB2999226-x64.msu /log:kb2999226.evtx

----------

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

From report at bugs.python.org  Thu Oct  8 19:14:46 2015
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 08 Oct 2015 17:14:46 +0000
Subject: [issue25343] Document atomic operations on builtin types
In-Reply-To: <1444318986.11.0.257913016756.issue25343@psf.upfronthosting.co.za>
Message-ID: <1444324486.94.0.999093910412.issue25343@psf.upfronthosting.co.za>


Brett Cannon added the comment:

We actually don't have any guarantees written down because we have never formalized them. It was discussed at the PyCon language summit this past year -- https://lwn.net/Articles/640177/ -- but it didn't lead to anyone writing a proposal to formalize the memory model.

----------
nosy: +brett.cannon

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

From report at bugs.python.org  Thu Oct  8 19:24:15 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 08 Oct 2015 17:24:15 +0000
Subject: [issue25344] Enhancement to Logging - Logging Stack
In-Reply-To: <1444323958.12.0.353720924326.issue25344@psf.upfronthosting.co.za>
Message-ID: <1444325055.1.0.394147608932.issue25344@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'm guessing you could write a custom hander that would do that.  It might be something more suited for a recipe or pypi package.

----------
nosy: +r.david.murray, vinay.sajip

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

From report at bugs.python.org  Thu Oct  8 19:29:21 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 08 Oct 2015 17:29:21 +0000
Subject: [issue25343] Document atomic operations on builtin types
In-Reply-To: <1444318986.11.0.257913016756.issue25343@psf.upfronthosting.co.za>
Message-ID: <1444325361.8.0.782477157949.issue25343@psf.upfronthosting.co.za>


R. David Murray added the comment:

I wonder...personally I prefer to program in asyncio style rather than threading style, where one doesn't have to worry about atomicity.  Maybe Python shouldn't make any atomicity guarantees.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Thu Oct  8 19:34:58 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Oct 2015 17:34:58 +0000
Subject: [issue24848] Warts in UTF-7 error handling
In-Reply-To: <1444319760.22.0.608534188949.issue24848@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbd61cBZRH-EYEMzH-UqtTu2uZSo2Skv7XHMH=seVg_fg@mail.gmail.com>


STINNER Victor added the comment:

The patch looks good to me.

----------

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

From report at bugs.python.org  Thu Oct  8 19:41:09 2015
From: report at bugs.python.org (Gowtham Nm)
Date: Thu, 08 Oct 2015 17:41:09 +0000
Subject: [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: [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  Thu Oct  8 20:42:47 2015
From: report at bugs.python.org (Steve Dower)
Date: Thu, 08 Oct 2015 18:42:47 +0000
Subject: [issue25346] test_regrtest fails because 'sys' is not imported.
Message-ID: <1444329767.85.0.677640686222.issue25346@psf.upfronthosting.co.za>


New submission from Steve Dower:

Fixed in ee1ef5a97e8f

----------
assignee:  -> steve.dower
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Oct  8 21:03:40 2015
From: report at bugs.python.org (eryksun)
Date: Thu, 08 Oct 2015 19:03:40 +0000
Subject: [issue25345] Unable to install Python 3.5 on Windows 10
In-Reply-To: <1444326068.92.0.817766252718.issue25345@psf.upfronthosting.co.za>
Message-ID: <1444331020.29.0.599028567809.issue25345@psf.upfronthosting.co.za>


eryksun added the comment:

Please attach "Python 3.5.0 (32-bit)_*_core_JustForMe.log", if it exists.

According to the log, initially the installer can't create a restore point because, I assume, you have the volume shadow copy (VSS) service disabled, i.e. the error code is ERROR_SERVICE_DISABLED (0x80070422). That shouldn't derail the installation, but it's unusual to disable this service since restore points are critically important in case something goes wrong while modifying the system.

Next, installing core.msi fails with the error code ERROR_INSTALL_ALREADY_RUNNING (0x80070652). This means you had an existing installation in progress. Check for running instances of msiexec.exe. If the existing installation process is hung, try installing Python 3.5 again after rebooting.

----------
nosy: +eryksun

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

From report at bugs.python.org  Thu Oct  8 21:37:31 2015
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 08 Oct 2015 19:37:31 +0000
Subject: [issue24177] Add https?_proxy support to http.client
In-Reply-To: <1431533065.95.0.88567271375.issue24177@psf.upfronthosting.co.za>
Message-ID: <1444333051.45.0.0190425637867.issue24177@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Yeah, agreed that it should be opt-in, at least until a major release.

I've run into a couple cases where higher level libraries use http.client (or httplib) directly, but don't expose the client directly (not that they should anyways). Because of that, there are higher level libraries that simply /can't/ support http_proxy environment variable because they didn't use a higher level abstraction.

Given http.client /does/ implement everything required to support this, I can't see it impacting the architecture in any negative way.

----------

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

From report at bugs.python.org  Thu Oct  8 22:44:53 2015
From: report at bugs.python.org (Mauro S. M. Rodrigues)
Date: Thu, 08 Oct 2015 20:44:53 +0000
Subject: [issue25328] ValueError in smtpd.py __init__() is not raised
In-Reply-To: <1444161567.94.0.721141385253.issue25328@psf.upfronthosting.co.za>
Message-ID: <1444337093.32.0.972963558846.issue25328@psf.upfronthosting.co.za>


Mauro S. M. Rodrigues added the comment:

Hi Barry, I was testing this and it seems to work, am I doing something wrong in order to reproduce it? I've used the same parameters from the unit tests

Python 3.5.0+ (3.5:1e99ba6b7c98, Oct  8 2015, 17:12:06) 
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import smtpd
>>> smtpd.SMTPServer(("127.0.0.1", 0), ('b',0),enable_SMTPUTF8=True,decode_data=True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/maurosr/dev/cpython/Lib/smtpd.py", line 645, in __init__
    raise ValueError("The decode_data and enable_SMTPUTF8"
ValueError: The decode_data and enable_SMTPUTF8 parameters cannot be set to True at the same time.

----------
nosy: +maurosr

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

From report at bugs.python.org  Thu Oct  8 22:48:03 2015
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 08 Oct 2015 20:48:03 +0000
Subject: [issue25328] ValueError in smtpd.py __init__() is not raised
In-Reply-To: <1444337093.32.0.972963558846.issue25328@psf.upfronthosting.co.za>
Message-ID: <20151008164758.291f383d@limelight.wooz.org>


Barry A. Warsaw added the comment:

On Oct 08, 2015, at 08:44 PM, Mauro S. M. Rodrigues wrote:

>Python 3.5.0+ (3.5:1e99ba6b7c98, Oct  8 2015, 17:12:06) 
>[GCC 4.8.4] on linux
>Type "help", "copyright", "credits" or "license" for more information.
>>>> import smtpd
>>>> smtpd.SMTPServer(("127.0.0.1", 0), ('b',0),enable_SMTPUTF8=True,decode_data=True)
>Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
>  File "/home/maurosr/dev/cpython/Lib/smtpd.py", line 645, in __init__
>    raise ValueError("The decode_data and enable_SMTPUTF8"
>ValueError: The decode_data and enable_SMTPUTF8 parameters cannot be set to True at the same time.

That's testing the SMTPServer.__init__() which looks fine.  It's the
SMTPChannel.__init__() that's broken.

----------

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

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: [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 00:59:55 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Oct 2015 22:59:55 +0000
Subject: [issue25318] Add _PyBytesWriter API to optimize Unicode encoders
In-Reply-To: <1444046488.88.0.905297361267.issue25318@psf.upfronthosting.co.za>
Message-ID: <20151008225951.20779.85450@psf.io>


Roundup Robot added the comment:

New changeset 1a2175149c5e by Victor Stinner in branch 'default':
Issue #25318: Add _PyBytesWriter API
https://hg.python.org/cpython/rev/1a2175149c5e

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Oct  9 01:04:15 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Oct 2015 23:04:15 +0000
Subject: [issue25318] Add _PyBytesWriter API to optimize Unicode encoders
In-Reply-To: <1444046488.88.0.905297361267.issue25318@psf.upfronthosting.co.za>
Message-ID: <1444345455.73.0.249241941207.issue25318@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, I was surprised to see same or worse performances for UTF-8/backslashreplace. In fact, I forgot to enable overallocation. With overallocation, it is now faster ;-)

I modified the API to put the "stack buffer" inside _PyBytesWriter API directly. I also reworked _PyBytesWriter_Alloc() to call  _PyBytesWriter_Prepare() so _PyBytesWriter_Alloc() now supports overallocation as well. It was part of _PyBytesWriter design to support overallocation at the first allocation (_PyBytesWriter_Alloc), that's why we have _PyBytesWriter_Alloc() *and* _PyBytesWriter_Init(): it's possible to set overallocate=1 between init and alloc.

I pushed my change since it didn't kill performances. It's only a little bit smaller but on very short encode: less than 500 ns. In other cases, it's the same performances or faster.

----------

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

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: [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 01:46:53 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Oct 2015 23:46:53 +0000
Subject: [issue25318] Add _PyBytesWriter API to optimize Unicode encoders
In-Reply-To: <1444046488.88.0.905297361267.issue25318@psf.upfronthosting.co.za>
Message-ID: <20151008234644.2663.28553@psf.io>


Roundup Robot added the comment:

New changeset 59f4806a5add by Victor Stinner in branch 'default':
Optimize backslashreplace error handler
https://hg.python.org/cpython/rev/59f4806a5add

----------

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

From report at bugs.python.org  Fri Oct  9 02:32:57 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Oct 2015 00:32:57 +0000
Subject: [issue25318] Add _PyBytesWriter API to optimize Unicode encoders
In-Reply-To: <1444046488.88.0.905297361267.issue25318@psf.upfronthosting.co.za>
Message-ID: <20151009003249.3301.26902@psf.io>


Roundup Robot added the comment:

New changeset c134eddcb347 by Victor Stinner in branch 'default':
Issue #25318: Move _PyBytesWriter to bytesobject.c
https://hg.python.org/cpython/rev/c134eddcb347

----------

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

From report at bugs.python.org  Fri Oct  9 02:37:34 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 09 Oct 2015 00:37:34 +0000
Subject: [issue25343] Document atomic operations on builtin types
In-Reply-To: <1444318986.11.0.257913016756.issue25343@psf.upfronthosting.co.za>
Message-ID: <1444351054.9.0.260589730505.issue25343@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> what set() operations are atomic?

The language doesn't make any guarantees about set operation atomicity.  Different implementations such as PyPy, Jython, and IronPython are free to make different choices than CPython.  In general, users should make no assumptions about atomicity unless explicitly documented and tested.  The wise course of action is to use mutexes when there is any doubt.

FWIW, it is difficult to make blanket statements about the methods on sets because the atomicity depends on the objects looked up or stored in the sets rather than the set itself.   Aside from trivial calls to __sizeof__ and __len__, most set methods potentially call __hash__ or __eq__ on the set elements either of which could make a callback into pure python code.  Likewise, any reference count decrement can potentially make a callback as well.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Fri Oct  9 02:44:51 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 09 Oct 2015 00:44:51 +0000
Subject: [issue25344] Enhancement to Logging - Logging Stack
In-Reply-To: <1444323958.12.0.353720924326.issue25344@psf.upfronthosting.co.za>
Message-ID: <1444351491.65.0.201625711847.issue25344@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This seems like a reasonable use case and is worth considering.

Offhand, I don't see how a user could easily implement this on their own without hacking the logging module internals.  What would be needed is some support for begin-logging-transaction, a series of normal logging calls, followed by either a transaction-commit or transaction-rollback.

----------
assignee:  -> vinay.sajip
nosy: +rhettinger

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

From report at bugs.python.org  Fri Oct  9 02:46:08 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 09 Oct 2015 00:46:08 +0000
Subject: [issue17908] Unittest runner needs an option to call gc.collect()
 after each test
In-Reply-To: <1367720444.87.0.21268529715.issue17908@psf.upfronthosting.co.za>
Message-ID: <1444351568.69.0.334903367368.issue17908@psf.upfronthosting.co.za>


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


----------
nosy: +haypo

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

From report at bugs.python.org  Fri Oct  9 02:50:26 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Oct 2015 00:50:26 +0000
Subject: [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 02:51:01 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Oct 2015 00:51:01 +0000
Subject: [issue25349] Use _PyBytesWriter for bytes%args
In-Reply-To: <1444351825.62.0.273684816362.issue25349@psf.upfronthosting.co.za>
Message-ID: <1444351861.44.0.836780508073.issue25349@psf.upfronthosting.co.za>


STINNER Victor added the comment:

See also the PEP 461 "Adding % formatting to bytes and bytearray".

FYI bytes % args is tested by test_format (good to know to test quickly changes).

----------

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

From report at bugs.python.org  Fri Oct  9 02:51:25 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Oct 2015 00:51:25 +0000
Subject: [issue25318] Add _PyBytesWriter API to optimize Unicode encoders
In-Reply-To: <1444046488.88.0.905297361267.issue25318@psf.upfronthosting.co.za>
Message-ID: <1444351885.72.0.0326993455118.issue25318@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I created the issue #25349 "Use _PyBytesWriter for bytes%args".

----------

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

From report at bugs.python.org  Fri Oct  9 02:52:49 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Oct 2015 00:52:49 +0000
Subject: [issue25318] Add _PyBytesWriter API to optimize Unicode encoders
In-Reply-To: <1444046488.88.0.905297361267.issue25318@psf.upfronthosting.co.za>
Message-ID: <20151009005238.70954.28917@psf.io>


Roundup Robot added the comment:

New changeset e9c1404d6bd9 by Victor Stinner in branch 'default':
Issue #25318: Fix compilation error
https://hg.python.org/cpython/rev/e9c1404d6bd9

----------

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

From report at bugs.python.org  Fri Oct  9 03:14:23 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Oct 2015 01:14:23 +0000
Subject: [issue25326] Improve error message for "character buffer objects"
In-Reply-To: <1444149973.59.0.309061962173.issue25326@psf.upfronthosting.co.za>
Message-ID: <20151009011420.7242.9331@psf.io>


Roundup Robot added the comment:

New changeset 4d1bd86d3bbd by Raymond Hettinger in branch '2.7':
Issue #25326:  Improve an obscure error message.
https://hg.python.org/cpython/rev/4d1bd86d3bbd

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Oct  9 03:27:37 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Oct 2015 01:27:37 +0000
Subject: [issue25318] Add _PyBytesWriter API to optimize Unicode encoders
In-Reply-To: <1444046488.88.0.905297361267.issue25318@psf.upfronthosting.co.za>
Message-ID: <1444354057.67.0.618428587183.issue25318@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The FreeBSD 9.x buildbot is grumpy.

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

Assertion failed: (start[writer->allocated] == 0), function _PyBytesWriter_CheckConsistency, file Objects/bytesobject.c, line 3809.
Fatal Python error: Aborted

Current thread 0x0000000801807400 (most recent call first):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/test_pep277.py", line 150 in test_listdir
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/case.py", line 600 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/case.py", line 648 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/runner.py", line 176 in run
...

----------

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

From report at bugs.python.org  Fri Oct  9 03:30:08 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 09 Oct 2015 01:30:08 +0000
Subject: [issue25326] Improve error message for "character buffer objects"
In-Reply-To: <1444149973.59.0.309061962173.issue25326@psf.upfronthosting.co.za>
Message-ID: <1444354208.23.0.822351953547.issue25326@psf.upfronthosting.co.za>


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


----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Oct  9 03:39:01 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Oct 2015 01:39:01 +0000
Subject: [issue25318] Add _PyBytesWriter API to optimize Unicode encoders
In-Reply-To: <1444046488.88.0.905297361267.issue25318@psf.upfronthosting.co.za>
Message-ID: <20151009013850.70956.12407@psf.io>


Roundup Robot added the comment:

New changeset 9cf89366bbcb by Victor Stinner in branch 'default':
Issue #25318: Avoid sprintf() in backslashreplace()
https://hg.python.org/cpython/rev/9cf89366bbcb

New changeset 0a522f68d275 by Victor Stinner in branch 'default':
Issue #25318: Fix backslashreplace()
https://hg.python.org/cpython/rev/0a522f68d275

New changeset c53dcf1d6967 by Victor Stinner in branch 'default':
Issue #25318: cleanup code _PyBytesWriter
https://hg.python.org/cpython/rev/c53dcf1d6967

----------

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

From report at bugs.python.org  Fri Oct  9 04:51:32 2015
From: report at bugs.python.org (Adam)
Date: Fri, 09 Oct 2015 02:51:32 +0000
Subject: [issue25344] Enhancement to Logging - Logging Stack
In-Reply-To: <1444323958.12.0.353720924326.issue25344@psf.upfronthosting.co.za>
Message-ID: <1444359092.13.0.607862538478.issue25344@psf.upfronthosting.co.za>


Changes by Adam <azsorkin at gmail.com>:


----------
nosy: +azsorkin

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

From report at bugs.python.org  Fri Oct  9 05:44:26 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 09 Oct 2015 03:44:26 +0000
Subject: [issue25228] Regression in cookie parsing with brackets and quotes
In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za>
Message-ID: <1444362266.41.0.928878007569.issue25228@psf.upfronthosting.co.za>


Martin Panter added the comment:

The str.find() call was kind of what I had in mind. But I don?t feel qualified to say whether the fix is good in general. I would have to find out about at the Cookie header format, and understand what the security implications are to do with lax parsing.

----------

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

From report at bugs.python.org  Fri Oct  9 06:04:02 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Oct 2015 04:04:02 +0000
Subject: [issue25298] Add lock and rlock weakref tests
In-Reply-To: <1443779607.92.0.0397508107511.issue25298@psf.upfronthosting.co.za>
Message-ID: <20151009040357.97724.32099@psf.io>


Roundup Robot added the comment:

New changeset 45903695e86c by Raymond Hettinger in branch 'default':
Issue #25298:  Add lock and rlock weakref tests (Contributed by Nir Soffer).
https://hg.python.org/cpython/rev/45903695e86c

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Oct  9 06:04:15 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 09 Oct 2015 04:04:15 +0000
Subject: [issue25298] Add lock and rlock weakref tests
In-Reply-To: <1443779607.92.0.0397508107511.issue25298@psf.upfronthosting.co.za>
Message-ID: <1444363455.33.0.443490286062.issue25298@psf.upfronthosting.co.za>


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


----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Oct  9 06:04:46 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 09 Oct 2015 04:04:46 +0000
Subject: [issue25315] Make it clear in the collections Python source code that
 OrderedDict may be overridden
In-Reply-To: <1444010587.49.0.504903152106.issue25315@psf.upfronthosting.co.za>
Message-ID: <1444363486.48.0.633234914533.issue25315@psf.upfronthosting.co.za>


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


----------
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Fri Oct  9 07:07:33 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 09 Oct 2015 05:07:33 +0000
Subject: [issue5380] pty.read raises IOError when slave pty device is closed
In-Reply-To: <1235721814.23.0.522352333065.issue5380@psf.upfronthosting.co.za>
Message-ID: <1444367253.52.0.144884590146.issue5380@psf.upfronthosting.co.za>


Martin Panter added the comment:

My biggest worry about the patch is that it looks like it will mask other EIO errors from normal terminals (e.g. perhaps reading from a slave or a real serial port can also produce an EIO error that does not mean EOF). Another option may be to add a specialized pseudo terminal master wrapper class that does the right thing on Linux. But I?m not a pseudo terminal expert and don?t really have a strong view about this.

I agree that the ?pty? module is rather limited, although the documentation does say pty.openpty() is more portable than os.openpty(). Maybe if Python used posix_openpt(), portability would be less of a problem?

----------

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

From report at bugs.python.org  Fri Oct  9 07:18:33 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 09 Oct 2015 05:18:33 +0000
Subject: [issue5380] pty.read raises IOError when slave pty device is closed
In-Reply-To: <1444367253.52.0.144884590146.issue5380@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJ+jsLt6u80wYz1S+N6Ld4=PXbR6j4KJLdnUJSNgGtGfCw@mail.gmail.com>


Guido van Rossum added the comment:

So maybe we should just close this as won't fix. Whoever wants to use the
master end of a pty had better be prepared for that IOError.

On Thursday, October 8, 2015, Martin Panter <report at bugs.python.org> wrote:

>
> Martin Panter added the comment:
>
> My biggest worry about the patch is that it looks like it will mask other
> EIO errors from normal terminals (e.g. perhaps reading from a slave or a
> real serial port can also produce an EIO error that does not mean EOF).
> Another option may be to add a specialized pseudo terminal master wrapper
> class that does the right thing on Linux. But I?m not a pseudo terminal
> expert and don?t really have a strong view about this.
>
> I agree that the ?pty? module is rather limited, although the
> documentation does say pty.openpty() is more portable than os.openpty().
> Maybe if Python used posix_openpt(), portability would be less of a problem?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org <javascript:;>>
> <http://bugs.python.org/issue5380>
> _______________________________________
>

----------

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

From report at bugs.python.org  Fri Oct  9 07:30:04 2015
From: report at bugs.python.org (=?utf-8?q?M=C3=A1rcio?=)
Date: Fri, 09 Oct 2015 05:30:04 +0000
Subject: [issue5380] pty.read raises IOError when slave pty device is closed
In-Reply-To: <1235721814.23.0.522352333065.issue5380@psf.upfronthosting.co.za>
Message-ID: <1444368604.56.0.206520183348.issue5380@psf.upfronthosting.co.za>


Changes by M?rcio <marciombfaustino at gmail.com>:


----------
nosy:  -marcio

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

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: [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 08:23:19 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 09 Oct 2015 06:23:19 +0000
Subject: [issue25328] ValueError in smtpd.py __init__() is not raised
In-Reply-To: <1444161567.94.0.721141385253.issue25328@psf.upfronthosting.co.za>
Message-ID: <1444371799.01.0.0493610187499.issue25328@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I think this is a typo. The raise is left out.

In test_smtpd.py, it only tests the raise condition in SMTPServer but
not STMPChannel.

I add the raise and a corresponding test in SMTPDChannelTest.

----------
keywords: +patch
nosy: +xiang.zhang
Added file: http://bugs.python.org/file40725/SMTPChannel_raise_ValueError.patch

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

From report at bugs.python.org  Fri Oct  9 09:20:34 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Oct 2015 07:20:34 +0000
Subject: [issue25277] test_sigwaitinfo() of test_eintr hangs on randomly on
 FreeBSD buildbots
In-Reply-To: <1443605568.0.0.865946740877.issue25277@psf.upfronthosting.co.za>
Message-ID: <1444375234.82.0.880636669744.issue25277@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The bug was reproduced with faulthandler:

FAIL: test_all (test.test_eintr.EINTRTests)
Timeout (0:10:00)!
Thread 0x0000000802006400 (most recent call first):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/eintrdata/eintr_tester.py", line 402 in test_sigwaitinfo
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/case.py", line 600 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/case.py", line 648 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/runner.py", line 176 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/support/__init__.py", line 1775 in _run_suite
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/support/__init__.py", line 1809 in run_unittest
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/eintrdata/eintr_tester.py", line 470 in test_main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/eintrdata/eintr_tester.py", line 474 in <module>

The same error occurred multiple times on buildbots FreeBSD 10.0 and 9.x.

----------
title: test_eintr hangs on randomly on "AMD64 FreeBSD 9.x 3.x" -> test_sigwaitinfo() of test_eintr hangs on randomly on FreeBSD buildbots

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

From report at bugs.python.org  Fri Oct  9 09:22:34 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Oct 2015 07:22:34 +0000
Subject: [issue25306] test_huntrleaks_fd_leak() of test_regrtest hangs on
 Windows
In-Reply-To: <1443899963.15.0.405890831726.issue25306@psf.upfronthosting.co.za>
Message-ID: <1444375354.45.0.58064700758.issue25306@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ok, it looks like the issue was fixed.

----------
keywords: +buildbot
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Oct  9 09:23:27 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Oct 2015 07:23:27 +0000
Subject: [issue25287] test_crypt fails on OpenBSD
In-Reply-To: <1443682191.0.0.229033947807.issue25287@psf.upfronthosting.co.za>
Message-ID: <1444375407.69.0.166295377635.issue25287@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hum, the test now fails differently :-(

======================================================================
FAIL: test_methods (test.test_crypt.CryptTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_crypt.py", line 29, in test_methods
    self.assertTrue(len(crypt.methods) >= 1)
AssertionError: False is not true

----------

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

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: [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 09:25:38 2015
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 09 Oct 2015 07:25:38 +0000
Subject: [issue25344] Enhancement to Logging - Logging Stack
In-Reply-To: <1444323958.12.0.353720924326.issue25344@psf.upfronthosting.co.za>
Message-ID: <1444375538.29.0.791472793558.issue25344@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

This is already supported. There is a logging.handlers.MemoryHandler which allows you to buffer logging events and then pass the buffered events to another handler when some condition is met, such as e.g. buffer full or some severity threshold is exceeded. Flushing the buffer to the other handler can be customised by subclassing and overriding shouldFlush() and perhaps flush() methods.

https://docs.python.org/2/library/logging.handlers.html#memoryhandler

I can perhaps add a cookbook recipe to illustrate, so I'll leave this issue open for now, as a reminder.

----------

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

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: [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 12:20:43 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Oct 2015 10:20:43 +0000
Subject: [issue25349] Use _PyBytesWriter for bytes%args
In-Reply-To: <1444351825.62.0.273684816362.issue25349@psf.upfronthosting.co.za>
Message-ID: <1444386043.61.0.46223632869.issue25349@psf.upfronthosting.co.za>


STINNER Victor added the comment:

bench_bytes_format.py: micro-benchmark testing a few formats. Some tests are focused on the implementation of _PyBytesWriter to ensure that the optimization is efficient.

Except of a single test (which is not really revelant, it takes less than 500 nanoseconds), all tests are faster.

The b"xxxxxx %s" % b"y" test confirms that the optimization disabling overallocation for the last write is effective.

Results:

Common platform:
Timer info: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09)
Python unicode implementation: PEP 393
CPU model: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
Platform: Linux-4.1.6-200.fc22.x86_64-x86_64-with-fedora-22-Twenty_Two
CFLAGS: -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
Timer: time.perf_counter
Bits: int=32, long=64, long long=64, size_t=64, void*=64

Platform of campaign orig:
SCM: hg revision=1aae9b6a6929 tag=tip branch=default date="2015-10-09 01:34 -0400"
Timer precision: 64 ns
Python version: 3.6.0a0 (default:1aae9b6a6929, Oct 9 2015, 11:33:56) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)]
Date: 2015-10-09 11:34:11

Platform of campaign writer:
SCM: hg revision=fc2c11a19ae1+ tag=tip branch=default date="2015-10-09 11:48 +0200"
Timer precision: 61 ns
Python version: 3.6.0a0 (default:fc2c11a19ae1+, Oct 9 2015, 12:16:16) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)]
Date: 2015-10-09 12:16:31

---------------------------+------------+--------------
use smaller buffer         |       orig |        writer
---------------------------+------------+--------------
b"hello %s" % b"world"     |  13 ns (*) |   12 ns (-5%)
b"hello %-100s" % b"world" | 158 ns (*) |  98 ns (-38%)
b"x=%d" % 123              |  13 ns (*) |         12 ns
b"x=%f" % 1.2              |  13 ns (*) |         13 ns
b"x=%100d" % 123           | 156 ns (*) |  166 ns (+7%)
---------------------------+------------+--------------
Total                      | 353 ns (*) | 301 ns (-15%)
---------------------------+------------+--------------

-------------------------------------------------+-------------+---------------
"hello %s" % long_string                         |        orig |         writer
-------------------------------------------------+-------------+---------------
fmt = b"hello %s"; arg = b"x" * 10; fmt % arg    |   98 ns (*) |   86 ns (-12%)
fmt = b"hello %s"; arg = b"x" * 100; fmt % arg   |   85 ns (*) |          87 ns
fmt = b"hello %s"; arg = b"x" * 10**3; fmt % arg |  298 ns (*) |  208 ns (-30%)
fmt = b"hello %s"; arg = b"x" * 10**5; fmt % arg |  4.8 us (*) |  4.39 us (-9%)
-------------------------------------------------+-------------+---------------
Total                                            | 5.28 us (*) | 4.77 us (-10%)
-------------------------------------------------+-------------+---------------

---------------------------------------+-------------+---------------
b"xxxxxx %s" % b"y"                    |        orig |         writer
---------------------------------------+-------------+---------------
fmt = b"x" * 10 + b"%s"; fmt % b"y"    |   99 ns (*) |   81 ns (-18%)
fmt = b"x" * 100 + b"%s"; fmt % b"y"   |  189 ns (*) |   87 ns (-54%)
fmt = b"x" * 10**3 + b"%s"; fmt % b"y" | 1.12 us (*) |  209 ns (-81%)
fmt = b"x" * 10**5 + b"%s"; fmt % b"y" | 88.4 us (*) | 8.49 us (-90%)
---------------------------------------+-------------+---------------
Total                                  | 89.8 us (*) | 8.87 us (-90%)
---------------------------------------+-------------+---------------

----------------------------------------------------------+-------------+---------------
%f                                                        |        orig |         writer
----------------------------------------------------------+-------------+---------------
n = 200; fmt = b"%f" * n; arg = tuple([1.2]*n); fmt % arg | 37.2 us (*) | 29.6 us (-21%)
----------------------------------------------------------+-------------+---------------

------------------------------------------------------------+-------------+---------------
%i                                                          |        orig |         writer
------------------------------------------------------------+-------------+---------------
n = 200; fmt = b"%f" * n; arg = tuple([12345]*n); fmt % arg | 49.4 us (*) | 42.8 us (-13%)
------------------------------------------------------------+-------------+---------------

-------------------------+-------------+---------------
Summary                  |        orig |         writer
-------------------------+-------------+---------------
use smaller buffer       |  353 ns (*) |  301 ns (-15%)
"hello %s" % long_string | 5.28 us (*) | 4.77 us (-10%)
b"xxxxxx %s" % b"y"      | 89.8 us (*) | 8.87 us (-90%)
%f                       | 37.2 us (*) | 29.6 us (-21%)
%i                       | 49.4 us (*) | 42.8 us (-13%)
-------------------------+-------------+---------------
Total                    |  182 us (*) | 86.3 us (-53%)
-------------------------+-------------+---------------

----------
Added file: http://bugs.python.org/file40726/bench_bytes_format.py

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

From report at bugs.python.org  Fri Oct  9 12:21:59 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Oct 2015 10:21:59 +0000
Subject: [issue25349] Use _PyBytesWriter for bytes%args
In-Reply-To: <1444351825.62.0.273684816362.issue25349@psf.upfronthosting.co.za>
Message-ID: <20151009102155.3293.82265@psf.io>


Roundup Robot added the comment:

New changeset b2f3cbdc0f2d by Victor Stinner in branch 'default':
Issue #25349: Optimize bytes % args using the new private _PyBytesWriter API
https://hg.python.org/cpython/rev/b2f3cbdc0f2d

----------
nosy: +python-dev

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

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


Emanuel Barry added the comment:

What about the `py' launcher? It will always launch the latest installed version.

----------
nosy: +ebarry

_______________________________________
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: [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 14:15:27 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Oct 2015 12:15:27 +0000
Subject: [issue25353] Use _PyBytesWriter for unicode escape and raw unicode
 escape encoders
In-Reply-To: <1444392822.73.0.0714587534509.issue25353@psf.upfronthosting.co.za>
Message-ID: <1444392927.76.0.386159660475.issue25353@psf.upfronthosting.co.za>


STINNER Victor added the comment:

A few more encoders should be updated to use _PyBytesWriter API:

* Code Page (Windows only)
* Charmap
* UTF-7
* UTF-16
* UTF-32

----------

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

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


STINNER Victor added the comment:

The _PyBytesWriter API was added in the issue #25318. See also the issue #25349 which optimized bytes % args.

----------

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

From report at bugs.python.org  Fri Oct  9 14:18:57 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Oct 2015 12:18:57 +0000
Subject: [issue25318] Add _PyBytesWriter API to optimize Unicode encoders
In-Reply-To: <1444046488.88.0.905297361267.issue25318@psf.upfronthosting.co.za>
Message-ID: <1444393137.42.0.884371841994.issue25318@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Buildbots still like this new API :-) (no test failure recently)

I reworked the API a little bit to make its usage simpler in Unicode encoders. I started to open new issues to using this new API in more functions producing byte strings.

I consider that this issue can now be closed. I'm happy, the API looks good to me and the modified code is faster.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Oct  9 14:43:02 2015
From: report at bugs.python.org (Florin Papa)
Date: Fri, 09 Oct 2015 12:43:02 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1444394582.32.0.357588247973.issue25300@psf.upfronthosting.co.za>


Florin Papa added the comment:

I have modified the small object allocator to set proper bounds  for the pointers it returns. Please see the updated patches.

----------
Added file: http://bugs.python.org/file40728/mpx_enable_3_6_v4.patch

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

From report at bugs.python.org  Fri Oct  9 14:43:13 2015
From: report at bugs.python.org (Florin Papa)
Date: Fri, 09 Oct 2015 12:43:13 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1444394593.03.0.723517187057.issue25300@psf.upfronthosting.co.za>


Changes by Florin Papa <florin.papa at intel.com>:


Added file: http://bugs.python.org/file40729/mpx_enable_2_7_v4.patch

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

From report at bugs.python.org  Fri Oct  9 14:59:11 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Oct 2015 12:59:11 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1444395551.13.0.897999578391.issue25300@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thanks. For the record, the whole test suite still passes? This is good to know :)

----------

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

From report at bugs.python.org  Fri Oct  9 15:02:53 2015
From: report at bugs.python.org (Florin Papa)
Date: Fri, 09 Oct 2015 13:02:53 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1444395773.79.0.599431768011.issue25300@psf.upfronthosting.co.za>


Florin Papa added the comment:

I ran the full Grand Unified Python Benchmarks suite on Python 3.6 and 2.7 before submitting the patches and everything went well. Sorry I did not mention it :)

----------

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

From report at bugs.python.org  Fri Oct  9 15:08:37 2015
From: report at bugs.python.org (Steve Dower)
Date: Fri, 09 Oct 2015 13:08:37 +0000
Subject: [issue25352] Add 'make this my default python' to windows installs
 for Python3.5 and later
In-Reply-To: <1444382005.62.0.6522456142.issue25352@psf.upfronthosting.co.za>
Message-ID: <1444396117.24.0.821881927106.issue25352@psf.upfronthosting.co.za>


Steve Dower added the comment:

The py launcher will prefer 2.7 because that's what was decided when it was added. We're probably getting to a stage where we can revert that.

Unfortunately, there's no way we can reliably fix system configuration without corrupting the users machine. Using the py launcher with -3 is currently the best way to do it.

I don't know where the desktop shortcuts are coming from - they're not ours, so we can't fix them.

----------

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

From report at bugs.python.org  Fri Oct  9 15:17:55 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Oct 2015 13:17:55 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1444396675.0.0.342279450102.issue25300@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I meant the test suite ("python -m test.regrtest"). I presume you did, just checking :-)

----------

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

From report at bugs.python.org  Fri Oct  9 15:23:39 2015
From: report at bugs.python.org (Emanuel Barry)
Date: Fri, 09 Oct 2015 13:23:39 +0000
Subject: [issue25352] Add 'make this my default python' to windows installs
 for Python3.5 and later
In-Reply-To: <1444382005.62.0.6522456142.issue25352@psf.upfronthosting.co.za>
Message-ID: <1444397019.42.0.673817946198.issue25352@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Oh, I didn't know the py launcher preferred 2.7 - I always work with 3.x; my bad.

----------

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

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: [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 15:34:02 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 09 Oct 2015 13:34:02 +0000
Subject: [issue25311] Add f-string support to tokenize.py
In-Reply-To: <1443979407.62.0.707305717475.issue25311@psf.upfronthosting.co.za>
Message-ID: <1444397642.63.0.931325954208.issue25311@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I think the best way to approach this is to generate (in code) all of the places where string prefixes appear. There's StringPrefix, endpats, triple_quotes, and single_quoted.

With the currently valid combinations of f, b, r, and u, I count 24 combinations:
['B', 'BR', 'Br', 'F', 'FR', 'Fr', 'R', 'RB', 'RF', 'Rb', 'Rf', 'U', 'b', 'bR', 'br', 'f', 'fR', 'fr', 'r', 'rB', 'rF', 'rb', 'rf', 'u']

If I add "fb" strings (plus raw), I count 72 combinations:
['B', 'BFR', 'BFr', 'BR', 'BRF', 'BRf', 'BfR', 'Bfr', 'Br', 'BrF', 'Brf', 'F', 'FBR', 'FBr', 'FR', 'FRB', 'FRb', 'FbR', 'Fbr', 'Fr', 'FrB', 'Frb', 'R', 'RB', 'RBF', 'RBf', 'RF', 'RFB', 'RFb', 'Rb', 'RbF', 'Rbf', 'Rf', 'RfB', 'Rfb', 'U', 'b', 'bFR', 'bFr', 'bR', 'bRF', 'bRf', 'bfR', 'bfr', 'br', 'brF', 'brf', 'f', 'fBR', 'fBr', 'fR', 'fRB', 'fRb', 'fbR', 'fbr', 'fr', 'frB', 'frb', 'r', 'rB', 'rBF', 'rBf', 'rF', 'rFB', 'rFb', 'rb', 'rbF', 'rbf', 'rf', 'rfB', 'rfb', 'u']

Coding these combinations by hand seems insane.

----------

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

From report at bugs.python.org  Fri Oct  9 15:34:08 2015
From: report at bugs.python.org (Florin Papa)
Date: Fri, 09 Oct 2015 13:34:08 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1444397648.2.0.612268627185.issue25300@psf.upfronthosting.co.za>


Florin Papa added the comment:

I ran regrtest now and there are a few tests that fail. I will look into the cause of this and provide a solution.

----------

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

From report at bugs.python.org  Fri Oct  9 15:36:50 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 09 Oct 2015 13:36:50 +0000
Subject: [issue25354] test_datetime failing
In-Reply-To: <1444397506.38.0.258649046467.issue25354@psf.upfronthosting.co.za>
Message-ID: <1444397810.86.0.60028782907.issue25354@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +belopolsky

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

From report at bugs.python.org  Fri Oct  9 16:06:32 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Oct 2015 14:06:32 +0000
Subject: [issue25228] Regression in cookie parsing with brackets and quotes
In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za>
Message-ID: <1444399592.7.0.141121478419.issue25228@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, we should get signoff from someone who was involved in the original security fix, since it was a security fix.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Fri Oct  9 16:06:43 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 09 Oct 2015 14:06:43 +0000
Subject: [issue25311] Add f-string support to tokenize.py
In-Reply-To: <1443979407.62.0.707305717475.issue25311@psf.upfronthosting.co.za>
Message-ID: <1444399603.08.0.00865821468559.issue25311@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Oops, make that 80 combinations (I forgot the various 'fb' ones):

['B', 'BF', 'BFR', 'BFr', 'BR', 'BRF', 'BRf', 'Bf', 'BfR', 'Bfr', 'Br', 'BrF', 'Brf', 'F', 'FB', 'FBR', 'FBr', 'FR', 'FRB', 'FRb', 'Fb', 'FbR', 'Fbr', 'Fr', 'FrB', 'Frb', 'R', 'RB', 'RBF', 'RBf', 'RF', 'RFB', 'RFb', 'Rb', 'RbF', 'Rbf', 'Rf', 'RfB', 'Rfb', 'U', 'b', 'bF', 'bFR', 'bFr', 'bR', 'bRF', 'bRf', 'bf', 'bfR', 'bfr', 'br', 'brF', 'brf', 'f', 'fB', 'fBR', 'fBr', 'fR', 'fRB', 'fRb', 'fb', 'fbR', 'fbr', 'fr', 'frB', 'frb', 'r', 'rB', 'rBF', 'rBf', 'rF', 'rFB', 'rFb', 'rb', 'rbF', 'rbf', 'rf', 'rfB', 'rfb', 'u']


import itertools as _itertools

def _all_string_prefixes():
    # The valid string prefixes. Only contain the lower case versions,
    #  and don't contain any permuations (include 'fr', but not
    #  'rf'). The various permutations will be generated.
    _valid_string_prefixes = ['b', 'r', 'u', 'f', 'br', 'fr', 'fb', 'fbr']
    result = set()
    for prefix in _valid_string_prefixes:
        for t in _itertools.permutations(prefix):
            # create a list with upper and lower versions of each
            #  character
            for u in _itertools.product(*[(c, c.upper()) for c in t]):
                result.add(''.join(u))
    return result

----------

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

From report at bugs.python.org  Fri Oct  9 16:08:51 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Oct 2015 14:08:51 +0000
Subject: [issue25350] Stronger type enforcement (feature request)
In-Reply-To: <1444370887.78.0.708610207347.issue25350@psf.upfronthosting.co.za>
Message-ID: <1444399731.16.0.533771954915.issue25350@psf.upfronthosting.co.za>


R. David Murray added the comment:

Check out the types module and PEP 484.

----------
nosy: +r.david.murray
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Oct  9 16:19:24 2015
From: report at bugs.python.org (Gabi Davar)
Date: Fri, 09 Oct 2015 14:19:24 +0000
Subject: [issue6953] readline documenation needs work
In-Reply-To: <1253456012.32.0.661240289209.issue6953@psf.upfronthosting.co.za>
Message-ID: <1444400364.6.0.481861969809.issue6953@psf.upfronthosting.co.za>


Changes by Gabi Davar <grizzly.nyo at gmail.com>:


----------
nosy: +Gabi.Davar

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

From report at bugs.python.org  Fri Oct  9 16:22:58 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Oct 2015 14:22:58 +0000
Subject: [issue25328] ValueError in smtpd.py __init__() is not raised
In-Reply-To: <1444161567.94.0.721141385253.issue25328@psf.upfronthosting.co.za>
Message-ID: <20151009142254.20759.72545@psf.io>


Roundup Robot added the comment:

New changeset d471cf4a73b2 by R David Murray in branch '3.5':
#25328: add missing raise keyword in decode_data+SMTPUTF8 check.
https://hg.python.org/cpython/rev/d471cf4a73b2

New changeset 576128c0d068 by R David Murray in branch 'default':
Merge #25328: add missing raise keyword in decode_data+SMTPUTF8 check.
https://hg.python.org/cpython/rev/576128c0d068

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Oct  9 16:25:36 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Oct 2015 14:25:36 +0000
Subject: [issue25328] ValueError in smtpd.py __init__() is not raised
In-Reply-To: <1444161567.94.0.721141385253.issue25328@psf.upfronthosting.co.za>
Message-ID: <1444400736.46.0.675889433121.issue25328@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Xiang.  Your analysis was correct and your patch is good.

For anyone who is curious, Barry discovered this while writing tests for a new aiosmtpd, which is based on the existing smtpd code.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Fri Oct  9 16:34:02 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Oct 2015 14:34:02 +0000
Subject: [issue25354] test_datetime failing
In-Reply-To: <1444397506.38.0.258649046467.issue25354@psf.upfronthosting.co.za>
Message-ID: <1444401242.91.0.176242372508.issue25354@psf.upfronthosting.co.za>


R. David Murray added the comment:

No, that delta being one hour is the whole point of that test.

I've nosied Alexander.  He'll probably need more information about the environment in which you are seeing this.

----------
nosy: +r.david.murray

_______________________________________
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: [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:27:08 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 09 Oct 2015 15:27:08 +0000
Subject: [issue25311] Add f-string support to tokenize.py
In-Reply-To: <1443979407.62.0.707305717475.issue25311@psf.upfronthosting.co.za>
Message-ID: <1444404428.71.0.0895203019147.issue25311@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

My first attempt. Many more tests are needed.

I'm going to need to spend some time trying to figure out how parts of tokenize.py actually works. I'm not sure, for example, that endpats is initialized correctly. There definitely aren't enough tests, since if I comment out parts of endpats the tests still pass.

----------
Added file: http://bugs.python.org/file40730/issue25311.diff

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

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: [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 17:41:32 2015
From: report at bugs.python.org (CM)
Date: Fri, 09 Oct 2015 15:41:32 +0000
Subject: [issue25336] Segmentation fault on Mavericks consistent crashing of
 software: Please HELP!!!!!
In-Reply-To: <1444263912.5.0.0566907258707.issue25336@psf.upfronthosting.co.za>
Message-ID: <1444405292.74.0.714578897797.issue25336@psf.upfronthosting.co.za>


CM added the comment:

Hi Thanks for your response.
So as you have correctly surmised I am using a software package call oof. I ran the package using gdb and this is the output that I got. I'm having the same issue on i.e. Segmentation fault on three machines, one is a Linux Centos/Redhat server (Python 2.7.8), and two macs (python 2.7.10). The gdb output below is from the Centos Server machine. 

Again not sure if it helps but I'm only posting all the information I have since it wouldn't be entirely easy for me to provide a test case without you actually having the software package installed. Thanks in advance. 


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

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd54c0700 (LWP 22786)]
PyObject_Malloc (nbytes=32) at Objects/obmalloc.c:813
813     Objects/obmalloc.c: No such file or directory.
        in Objects/obmalloc.c
Missing separate debuginfos, use: debuginfo-install expat-2.0.1-11.el6_2.x86_64 fontconfig-2.8.0-3.el6.x86_64 freetype-2.3.11-14.el6_3.1.x86_64 glibc-2.12-1.149.el6_6.5.x86_64 keyutils-libs-1.4-4.el6.x86_64 krb5-libs-1.10.3-10.el6_4.6.x86_64 libICE-1.0.6-1.el6.x86_64 libSM-1.2.1-2.el6.x86_64 libX11-1.6.0-2.2.el6.x86_64 libXau-1.0.6-4.el6.x86_64 libXcursor-1.1.13-6.20130524git8f677eaea.el6.x86_64 libXdamage-1.1.3-4.el6.x86_64 libXext-1.3.1-2.el6.x86_64 libXfixes-5.0-3.el6.x86_64 libXrender-0.9.7-2.el6.x86_64 libXt-1.1.4-6.1.el6.x86_64 libart_lgpl-2.3.20-5.1.el6.x86_64 libcom_err-1.41.12-18.el6.x86_64 libgcc-4.4.7-4.el6.x86_64 libgfortran-4.4.7-4.el6.x86_64 libgnomecanvas-2.26.0-4.el6.x86_64 libgomp-4.4.7-4.el6.x86_64 libjpeg-turbo-1.2.1-3.el6_5.x86_64 libpng-1.2.49-1.el6_2.x86_64 libselinux-2.0.94-5.3.el6_4.1.x86_64 libstdc++-4.4.7-4.el6.x86_64 libtiff-3.9.4-10.el6_5.x86_64 libuuid-2.17.2-12.14.el6.x86_64 libxcb-1.8.1-1.el6.x86_64 openssl-1.0.1e-16.el6_5.15.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) where
#0  PyObject_Malloc (nbytes=32) at Objects/obmalloc.c:813
#1  0x00007ffff7a90c3d in _PyObject_New (tp=0x7ffff7dc3840) at Objects/object.c:244
#2  0x00007ffff7b2cb2d in newlockobject (self=<value optimized out>) at ./Modules/threadmodule.c:164
#3  thread_PyThread_allocate_lock (self=<value optimized out>) at ./Modules/threadmodule.c:746
#4  0x00007ffff7af3741 in call_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4017
#5  PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:2679
#6  0x00007ffff7af54ae in PyEval_EvalCodeEx (co=0x7fffef74bbb0, globals=<value optimized out>, locals=<value optimized out>, 
    args=<value optimized out>, argcount=2, kws=0x7fffa40040c8, kwcount=0, defs=0x7fffef771068, defcount=1, closure=0x0)
    at Python/ceval.c:3265
#7  0x00007ffff7af365a in fast_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4129
#8  call_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4054
#9  PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:2679
#10 0x00007ffff7af54ae in PyEval_EvalCodeEx (co=0x7fffef75b6b0, globals=<value optimized out>, locals=<value optimized out>, 
    args=<value optimized out>, argcount=1, kws=0x7fff5d3de7d8, kwcount=0, defs=0x7fffeecdf068, defcount=1, closure=0x0)
    at Python/ceval.c:3265
#11 0x00007ffff7af365a in fast_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4129
#12 call_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4054
#13 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:2679
#14 0x00007ffff7af54ae in PyEval_EvalCodeEx (co=0x7fffe6669c30, globals=<value optimized out>, locals=<value optimized out>, 
    args=<value optimized out>, argcount=3, kws=0x7fff5d3e1bb0, kwcount=0, defs=0x7fffe6661fe0, defcount=2, closure=0x0)
    at Python/ceval.c:3265
#15 0x00007ffff7af365a in fast_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4129
#16 call_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4054
#17 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:2679
#18 0x00007ffff7af54ae in PyEval_EvalCodeEx (co=0x7ffff7e2ad30, globals=<value optimized out>, locals=<value optimized out>, 
    args=<value optimized out>, argcount=2, kws=0x7ffff7f97068, kwcount=0, defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:3265
#19 0x00007ffff7a73778 in function_call (func=0x7fffeece2938, arg=0x7fff563836c8, kw=0x7fff5642b4b0)
    at Objects/funcobject.c:526
#20 0x00007ffff7a441a3 in PyObject_Call (func=0x7fffeece2938, arg=<value optimized out>, kw=<value optimized out>)
    at Objects/abstract.c:2529
#21 0x00007ffff7af214a in ext_do_call (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4346
#22 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:2718
#23 0x00007ffff7af54ae in PyEval_EvalCodeEx (co=0x7ffff7e342b0, globals=<value optimized out>, locals=<value optimized out>, 
    args=<value optimized out>, argcount=2, kws=0x7ffff7f97068, kwcount=0, defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:3265
#24 0x00007ffff7a73778 in function_call (func=0x7fffeece2cf8, arg=0x7fff563cf638, kw=0x7fff5642b398)
    at Objects/funcobject.c:526
#25 0x00007ffff7a441a3 in PyObject_Call (func=0x7fffeece2cf8, arg=<value optimized out>, kw=<value optimized out>)
    at Objects/abstract.c:2529
#26 0x00007ffff7af214a in ext_do_call (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4346
#27 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:2718
---Type <return> to continue, or q <return> to quit---

----------
status: closed -> open

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

From report at bugs.python.org  Fri Oct  9 17:46:05 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Oct 2015 15:46:05 +0000
Subject: [issue25336] Segmentation fault on Mavericks consistent crashing of
 software: Please HELP!!!!!
In-Reply-To: <1444263912.5.0.0566907258707.issue25336@psf.upfronthosting.co.za>
Message-ID: <1444405565.69.0.701414792126.issue25336@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think Ned meant "it is *not* likely to be in the python interpreter or standard library", and that you should seek help from the third party people trying to track down the problem.  *If* it turns out to be python or the stdlib, which means you've managed to find a reproducer that does *not* involve the third party packages, *then* come back and reopen the issue.

Like Ned said, good luck, but we really can't provide you any more help here until the third party packages are eliminated from the equation.

----------
nosy: +r.david.murray
status: open -> closed

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

From report at bugs.python.org  Fri Oct  9 17:48:48 2015
From: report at bugs.python.org (CM)
Date: Fri, 09 Oct 2015 15:48:48 +0000
Subject: [issue25336] Segmentation fault on Mavericks consistent crashing of
 software: Please HELP!!!!!
In-Reply-To: <1444263912.5.0.0566907258707.issue25336@psf.upfronthosting.co.za>
Message-ID: <1444405728.71.0.456619934777.issue25336@psf.upfronthosting.co.za>


CM added the comment:

I understood what Ned meant, and I did seek advice from the third party software creator, it was the first thing I did because like you stated I thought it was an issue with the third party software and not python. Coming to this bug website was my last resort but I can see that it doesn't make sense

----------

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

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


Laura Creighton added the comment:

checking, these kids are using computers where, at some point, somebody moved the idle shortcut from their 2.7 folder to the desktop.  Which was probably a very bad idea.

But what should I tell them to do to get 3.5 there instead?

(adding IDLE to 'Type')

----------
components: +IDLE

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

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: [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 18:37:47 2015
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Oct 2015 16:37:47 +0000
Subject: [issue25303] py_compile disregards PYTHONDONTWRITEBYTECODE and -B
In-Reply-To: <1443833531.37.0.101836027368.issue25303@psf.upfronthosting.co.za>
Message-ID: <1444408667.14.0.036817786882.issue25303@psf.upfronthosting.co.za>


?ric Araujo added the comment:

I had the same reasoning as RDM when I worked on byte-compilation in distutils2: https://hg.python.org/distutils2/rev/7c0a88497b5c

Using py_compile or compileall means that you want to create pyc or pyo files.
Defining PYTHONDONTWRITEBYTECODE or -B means that you don?t want the Python interpreter to byte-compile module as a side-effect of importing them.
These two things seem orthogonal to me.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Fri Oct  9 18:45:09 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 09 Oct 2015 16:45:09 +0000
Subject: [issue25357] Add an optional newline parameter to
 binascii.b2a_base64() to not add a newline
In-Reply-To: <1444407716.89.0.315561333899.issue25357@psf.upfronthosting.co.za>
Message-ID: <1444409109.42.0.276942309339.issue25357@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

+1. Not sure about the parameter name, but if no one suggests better, it LGTM. Added comments on Rietveld.

What about adding the same parameter to binascii.b2a_uu()?

----------
nosy: +ncoghlan, pitrou, serhiy.storchaka

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

From report at bugs.python.org  Fri Oct  9 18:55:03 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 09 Oct 2015 16:55:03 +0000
Subject: [issue25354] test_datetime failing
In-Reply-To: <1444397506.38.0.258649046467.issue25354@psf.upfronthosting.co.za>
Message-ID: <1444409703.17.0.5337716165.issue25354@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

@shanmbic - did you recompile C modules before running the tests?

----------

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

From report at bugs.python.org  Fri Oct  9 18:57:51 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Oct 2015 16:57:51 +0000
Subject: [issue25349] Use _PyBytesWriter for bytes%args
In-Reply-To: <1444351825.62.0.273684816362.issue25349@psf.upfronthosting.co.za>
Message-ID: <1444409871.7.0.105750572902.issue25349@psf.upfronthosting.co.za>


STINNER Victor added the comment:

bytes_formatlong.patch: Fast-path for b'%d' % int and other integer formatters. It avoids the creation of a temporary bytes object, it writes directly into the writer, as '%d' % int (Unicode).

----------
Added file: http://bugs.python.org/file40732/bytes_formatlong.patch

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

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


STINNER Victor added the comment:

Oh, I forgot to add an unit test.

> What about adding the same parameter to binascii.b2a_uu()?

This function is used in Lib/encodings/uu_codec.py and Lib/uu.py, but the newline is not stripped. So I don't think that it's worth to add an optional parameter.

----------

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

From report at bugs.python.org  Fri Oct  9 19:05:30 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Oct 2015 17:05:30 +0000
Subject: [issue25357] Add an optional newline parameter to
 binascii.b2a_base64() to not add a newline
In-Reply-To: <1444407716.89.0.315561333899.issue25357@psf.upfronthosting.co.za>
Message-ID: <1444410330.05.0.145974865156.issue25357@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Updated patch to take Serhiy's comments in account and now with an unit test!

----------
Added file: http://bugs.python.org/file40733/binascii_b2a_base64_newline-2.patch

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

From report at bugs.python.org  Fri Oct  9 19:07:58 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Oct 2015 17:07:58 +0000
Subject: [issue25357] Add an optional newline parameter to
 binascii.b2a_base64() to not add a newline
In-Reply-To: <1444407716.89.0.315561333899.issue25357@psf.upfronthosting.co.za>
Message-ID: <1444410478.78.0.539027744097.issue25357@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh by the way, the new parameter is a keyword only parameter. It's not possible to write b2a_base64(data, False). Maybe I should also add an unit test for this.

----------

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

From report at bugs.python.org  Fri Oct  9 19:35:40 2015
From: report at bugs.python.org (Steve Dower)
Date: Fri, 09 Oct 2015 17:35:40 +0000
Subject: [issue25352] Add 'make this my default python' to windows installs
 for Python3.5 and later
In-Reply-To: <1444382005.62.0.6522456142.issue25352@psf.upfronthosting.co.za>
Message-ID: <1444412140.86.0.133177999798.issue25352@psf.upfronthosting.co.za>


Steve Dower added the comment:

They can find the 3.5 shortcut in their Start Menu (either by browsing or searching for "IDLE") and then move that to their desktop.

Depending on operating system version, moving it could be:

* drag from the Start Menu to the desktop and drop it
* right-click and choose "Send To -> Desktop (create shortcut)", OR
* right-click, choose "Open File Location" and then right-click again in the new window and choose "Send To -> Desktop (create shortcut)"

----------

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

From report at bugs.python.org  Fri Oct  9 19:38:42 2015
From: report at bugs.python.org (Steve Dower)
Date: Fri, 09 Oct 2015 17:38:42 +0000
Subject: [issue12939] Add new io.FileIO using the native Windows API
In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za>
Message-ID: <1444412322.88.0.459895490897.issue12939@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
nosy: +steve.dower

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

From report at bugs.python.org  Fri Oct  9 20:36:56 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Oct 2015 18:36:56 +0000
Subject: [issue25303] py_compile disregards PYTHONDONTWRITEBYTECODE and -B
In-Reply-To: <1443833531.37.0.101836027368.issue25303@psf.upfronthosting.co.za>
Message-ID: <1444415816.81.0.127378167723.issue25303@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I agree that the proposal as written should be rejected.  I am inclined to think this issue should be closed.

I do not understand the claim about 'python -m py_compile'.  For me, this does nothing, as I would expect from reading the code.  If args = sys.arg[1:] is empty, the else clause for loop immediately quits.

Syntax checking is easily done with compile; that is how IDLE does it.  
  python -c "compile(open(<filename>).read(), '', 'exec').
should do what Pavel tried to do, except for getting a SyntaxError instead of py_compile.PyCompileError.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Fri Oct  9 20:40:15 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Oct 2015 18:40:15 +0000
Subject: [issue25307] Enhancing the argparse help output
In-Reply-To: <1443905883.43.0.512702237453.issue25307@psf.upfronthosting.co.za>
Message-ID: <1444416015.51.0.489349484405.issue25307@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +bethard
versions: +Python 3.6 -Python 3.4

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

From report at bugs.python.org  Fri Oct  9 20:44:01 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Oct 2015 18:44:01 +0000
Subject: [issue25312] Cryptic error message if incorrect spec is set on a
 callable mock
In-Reply-To: <1443982028.68.0.922333733292.issue25312@psf.upfronthosting.co.za>
Message-ID: <1444416241.36.0.409235308324.issue25312@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +michael.foord

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

From report at bugs.python.org  Fri Oct  9 20:47:36 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Oct 2015 18:47:36 +0000
Subject: [issue25320] unittest loader.py TypeError when code directory
 contains a socket
In-Reply-To: <1444063424.79.0.244583020203.issue25320@psf.upfronthosting.co.za>
Message-ID: <1444416456.92.0.765895010351.issue25320@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +ezio.melotti, michael.foord, rbcollins
versions: +Python 3.6

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

From report at bugs.python.org  Fri Oct  9 20:51:57 2015
From: report at bugs.python.org (Alex Warhawk)
Date: Fri, 09 Oct 2015 18:51:57 +0000
Subject: [issue19500] Error when connecting to FTPS servers not supporting SSL
 session resuming
In-Reply-To: <1383624130.64.0.185541289049.issue19500@psf.upfronthosting.co.za>
Message-ID: <1444416717.83.0.336183556581.issue19500@psf.upfronthosting.co.za>


Alex Warhawk added the comment:

Even after enabling client cache one still has to call SSL_set_session. See documentation of SSL_CTX_set_session_cache_mode point SSL_SESS_CACHE_CLIENT.

I started thinking about not exposing a SSL_SESSION object to the user but rather extending wrap_socket to take an already established socket as argument and use that socket's session object. This way I can ensure that both sockets share the same SSL context

I am not really convinced by this idea myself, what do you think about this? Any better ideas?

----------

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

From report at bugs.python.org  Fri Oct  9 20:55:55 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Oct 2015 18:55:55 +0000
Subject: [issue25331] Using Windows doc should list service packs needed to
 install
In-Reply-To: <1444214198.22.0.92198325395.issue25331@psf.upfronthosting.co.za>
Message-ID: <1444416955.42.0.707499595042.issue25331@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> needs patch
title: https://docs.python.org/3.5/using/windows.html should list whcih windows service packs are -> Using Windows doc should list service packs needed to install
type:  -> enhancement
versions: +Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Oct  9 21:07:47 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Oct 2015 19:07:47 +0000
Subject: [issue25334] telnetlib: process_rawq() and binary data
In-Reply-To: <1444223830.96.0.970501650084.issue25334@psf.upfronthosting.co.za>
Message-ID: <1444417667.71.0.848082308095.issue25334@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

A new method is an API change is an enhancement only allowed in a future version. If this is the only change needed to support another RFC also, the idea seems plausible, but I am not an Inet protocol expert.  
https://tools.ietf.org/html/rfc854.html
https://tools.ietf.org/html/rfc856.html
https://tools.ietf.org/html/rfc5198 proposed 854 update for unicode

----------
nosy: +r.david.murray, terry.reedy
stage:  -> patch review
type: behavior -> enhancement
versions:  -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Oct  9 21:19:15 2015
From: report at bugs.python.org (shanmbic)
Date: Fri, 09 Oct 2015 19:19:15 +0000
Subject: [issue25354] test_datetime failing
In-Reply-To: <1444397506.38.0.258649046467.issue25354@psf.upfronthosting.co.za>
Message-ID: <1444418355.91.0.179103362051.issue25354@psf.upfronthosting.co.za>


shanmbic added the comment:

@belopolsky - Yeah, I recompiled all the C modules successfully, still it fails the test. I am running Ubuntu 14.10

----------

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

From report at bugs.python.org  Fri Oct  9 21:23:51 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Oct 2015 19:23:51 +0000
Subject: [issue25303] Add option to py_compile to compile for syntax checking
 without writing bytecode
In-Reply-To: <1443833531.37.0.101836027368.issue25303@psf.upfronthosting.co.za>
Message-ID: <1444418631.34.0.649165554429.issue25303@psf.upfronthosting.co.za>


R. David Murray added the comment:

OK, I'll change the title to reflect the current proposal, and we'll see if anyone is interested in proposing a patch.

The bug with python -m py_compile is when you do:

    python -m py_compile myscript

where myscript is a file containing python code (note there is no .py extension).  In this case you will end up with:

  __pycache__/myscriptcpython-36.pyc

(for example).  This is clearly a bug, but should be reported in a new issue.

----------
title: py_compile disregards PYTHONDONTWRITEBYTECODE and -B -> Add option to py_compile to compile for syntax checking without writing bytecode

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

From report at bugs.python.org  Fri Oct  9 21:35:07 2015
From: report at bugs.python.org (Tim Peters)
Date: Fri, 09 Oct 2015 19:35:07 +0000
Subject: [issue25354] test_datetime failing
In-Reply-To: <1444397506.38.0.258649046467.issue25354@psf.upfronthosting.co.za>
Message-ID: <1444419307.96.0.112067763423.issue25354@psf.upfronthosting.co.za>


Tim Peters added the comment:

This is just hard to believe.  The symptom you describe is exactly what's expected if you got the new test suite but did not compile the new C code, both added by the fix for:

    http://bugs.python.org/issue23600

Since we have numerous buildbots on which the test passes, what's special about your setup?  The changes here were quite straightforward.  Please double-check.

----------
nosy: +tim.peters

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

From report at bugs.python.org  Fri Oct  9 21:46:43 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 09 Oct 2015 19:46:43 +0000
Subject: [issue25099] test_compileall fails when run by unprivileged user on
 installed Python
In-Reply-To: <1442205173.06.0.618332067063.issue25099@psf.upfronthosting.co.za>
Message-ID: <1444420003.38.0.547343480192.issue25099@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Here is a new patch that addresses Serhiy's comments.

----------
Added file: http://bugs.python.org/file40734/issue25099.diff

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

From report at bugs.python.org  Fri Oct  9 21:46:51 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 09 Oct 2015 19:46:51 +0000
Subject: [issue25099] test_compileall fails when run by unprivileged user on
 installed Python
In-Reply-To: <1442205173.06.0.618332067063.issue25099@psf.upfronthosting.co.za>
Message-ID: <1444420011.68.0.873056551155.issue25099@psf.upfronthosting.co.za>


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


----------
stage: patch review -> commit review

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

From report at bugs.python.org  Fri Oct  9 21:52:59 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 09 Oct 2015 19:52:59 +0000
Subject: [issue25303] Add option to py_compile to compile for syntax checking
 without writing bytecode
In-Reply-To: <1443833531.37.0.101836027368.issue25303@psf.upfronthosting.co.za>
Message-ID: <1444420379.9.0.310594448719.issue25303@psf.upfronthosting.co.za>


Brett Cannon added the comment:

You can verify a script is syntactically correct by compiling it to an AST or just calling compile() which is another way of doing essentially what `import` does but without having to worry about import-related side-effects in the code being checked.

But is this really worth adding to the stdlib? You can run your tests to verify the code is syntactically sound, run pylint, etc. I think this is probably straying a bit too much into the tooling arena to make the maintenance burden worth having in the stdlib.

----------
nosy: +brett.cannon

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

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: [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  Fri Oct  9 21:56:53 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Oct 2015 19:56:53 +0000
Subject: [issue25335] ast.literal_eval fails to parse numbers with leading "+"
In-Reply-To: <1444231519.35.0.84058018345.issue25335@psf.upfronthosting.co.za>
Message-ID: <1444420613.44.0.25556512682.issue25335@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I am pretty sure the 2.x anomaly is tied up with having short ints plus the anomaly of having one more negative than positive int.

>>> 2147483648
2147483648L
>>> -(2147483648)
-2147483648L
>>> -2147483648
-2147483648

I believe the last result was once the same as the middle result because I remember reading or even writing the explanation that -2147483648 is (was) parsed as -(2147483648) (or something like this).

Raymond' also made more liberal in other ways: literal_eval('(+1)+(-1)') in now 0 instead of ValueError: malformed string. The 3.x doc was not changed to match, though.

----------
nosy: +terry.reedy
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Oct  9 22:00:46 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Oct 2015 20:00:46 +0000
Subject: [issue25341] File mode wb+ appears as rb+
In-Reply-To: <1444290178.48.0.0607111061258.issue25341@psf.upfronthosting.co.za>
Message-ID: <1444420846.26.0.380394190454.issue25341@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +benjamin.peterson, pitrou, stutzbach

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

From report at bugs.python.org  Fri Oct  9 22:03:31 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Oct 2015 20:03:31 +0000
Subject: [issue25329] test_json crashes with stack overflow on Windows
In-Reply-To: <1444164061.67.0.762118597604.issue25329@psf.upfronthosting.co.za>
Message-ID: <1444421011.75.0.0505721191807.issue25329@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

See also #25342 and its list of related failures.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Fri Oct  9 22:05:41 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Oct 2015 20:05:41 +0000
Subject: [issue25303] Add option to py_compile to compile for syntax checking
 without writing bytecode
In-Reply-To: <1443833531.37.0.101836027368.issue25303@psf.upfronthosting.co.za>
Message-ID: <1444421141.08.0.160603732424.issue25303@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, the thing is that py_compile *already* has all the needed logic, the flag would just allow us to add an if statement before the two lines that write the compiled bytecode out to the file system.  py_compile also has the advantage that it supports the importlib loader logic.  The goal here (from my point of view) is to have a simple command line way of checking the syntax of a script, so that last may not be important.  

The python -c using 'compile(open' *is* reasonably brief, but it is not as elegant as the 'perl -c' mentioned in the linked stackoverflow question.  'python -m py_compile' isn't quite a succinct as 'perl -c', but it is a lot closer than 

  python -c "compile(open(<filename>).read(), '', 'exec')"

and a lot easier to remember.  Now, you can argue that referencing perl in this context is a bit of 'keeping up with the joneses', but I think there is an argument to be made that it is worthwhile in this case.  I won't be heartbroken if the idea gets shot down, though :)

----------

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

From report at bugs.python.org  Fri Oct  9 22:17:01 2015
From: report at bugs.python.org (Ankit Baruah)
Date: Fri, 09 Oct 2015 20:17:01 +0000
Subject: [issue25311] Add f-string support to tokenize.py
In-Reply-To: <1443979407.62.0.707305717475.issue25311@psf.upfronthosting.co.za>
Message-ID: <1444421821.46.0.492915340266.issue25311@psf.upfronthosting.co.za>


Changes by Ankit Baruah <ankit.baruah1 at gmail.com>:


----------
nosy: + at nkit

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

From report at bugs.python.org  Fri Oct  9 22:22:39 2015
From: report at bugs.python.org (Ankit Baruah)
Date: Fri, 09 Oct 2015 20:22:39 +0000
Subject: [issue17908] Unittest runner needs an option to call gc.collect()
 after each test
In-Reply-To: <1367720444.87.0.21268529715.issue17908@psf.upfronthosting.co.za>
Message-ID: <1444422159.63.0.931840422685.issue17908@psf.upfronthosting.co.za>


Changes by Ankit Baruah <ankit.baruah1 at gmail.com>:


----------
nosy: + at nkit

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

From report at bugs.python.org  Fri Oct  9 22:23:19 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Oct 2015 20:23:19 +0000
Subject: [issue25343] Document atomic operations on builtin types
In-Reply-To: <1444318986.11.0.257913016756.issue25343@psf.upfronthosting.co.za>
Message-ID: <1444422199.05.0.874183765023.issue25343@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This question has been asked multiple times before.  I think it should be documented that as far as the language goes, there is no answer.  Raymond's answer is a start.  Dima, where would you expect to find such a disclaimer (other than in the FAQ)?

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Fri Oct  9 22:26:15 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Oct 2015 20:26:15 +0000
Subject: [issue25347] assert_has_calls output is formatted inconsistently
In-Reply-To: <1444342123.9.0.512399656595.issue25347@psf.upfronthosting.co.za>
Message-ID: <1444422375.89.0.233307529129.issue25347@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Oct  9 22:27:21 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 09 Oct 2015 20:27:21 +0000
Subject: [issue25354] test_datetime failing
In-Reply-To: <1444397506.38.0.258649046467.issue25354@psf.upfronthosting.co.za>
Message-ID: <1444422441.09.0.70653681666.issue25354@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Maybe @shanmbic has a clock skew and _datetime.so does not get recompiled?

I would try to do make clean or even make distclean and rebuild everything.

----------

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

From report at bugs.python.org  Fri Oct  9 22:28:54 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Oct 2015 20:28:54 +0000
Subject: [issue25354] test_datetime failing
In-Reply-To: <1444397506.38.0.258649046467.issue25354@psf.upfronthosting.co.za>
Message-ID: <1444422534.46.0.105898805657.issue25354@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, I find that if there's something that might be a compilation problem, doing a make distclean and a build from scratch is a good idea to confirm it.

----------

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

From report at bugs.python.org  Fri Oct  9 22:32:05 2015
From: report at bugs.python.org (Dima Tisnek)
Date: Fri, 09 Oct 2015 20:32:05 +0000
Subject: [issue25343] Document atomic operations on builtin types
In-Reply-To: <1444318986.11.0.257913016756.issue25343@psf.upfronthosting.co.za>
Message-ID: <1444422725.35.0.227913307912.issue25343@psf.upfronthosting.co.za>


Dima Tisnek added the comment:

Ideally I'd like 2 sources:

1. a whole section on atomic operations in language and CPython implementation

2. annotation of standard library methods, e.g.:
set().add(element)  [atomic] or [CPython: atomic(*)]
(*) assuming basic types, note about what custom methods would break this guarantee; the reference could be to 1.

----------

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

From report at bugs.python.org  Fri Oct  9 22:37:41 2015
From: report at bugs.python.org (Ankit Baruah)
Date: Fri, 09 Oct 2015 20:37:41 +0000
Subject: [issue17908] Unittest runner needs an option to call gc.collect()
 after each test
In-Reply-To: <1367720444.87.0.21268529715.issue17908@psf.upfronthosting.co.za>
Message-ID: <1444423061.32.0.910352789264.issue17908@psf.upfronthosting.co.za>


Changes by Ankit Baruah <ankit.baruah1 at gmail.com>:


----------
nosy:  - at nkit

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

From report at bugs.python.org  Fri Oct  9 22:38:16 2015
From: report at bugs.python.org (Ankit Baruah)
Date: Fri, 09 Oct 2015 20:38:16 +0000
Subject: [issue25311] Add f-string support to tokenize.py
In-Reply-To: <1443979407.62.0.707305717475.issue25311@psf.upfronthosting.co.za>
Message-ID: <1444423096.56.0.0954908054418.issue25311@psf.upfronthosting.co.za>


Changes by Ankit Baruah <ankit.baruah1 at gmail.com>:


----------
nosy:  - at nkit

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

From report at bugs.python.org  Fri Oct  9 22:40:32 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Oct 2015 20:40:32 +0000
Subject: [issue25349] Use _PyBytesWriter for bytes%args
In-Reply-To: <1444351825.62.0.273684816362.issue25349@psf.upfronthosting.co.za>
Message-ID: <1444423232.44.0.508772435304.issue25349@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I wrote bench_bytes_int.py micro-benchmark, results are below.

Oh, I did'n expected a real difference even for simple code like b'%d' % 12345 (32% faster). So I consider that it's enough to apply the optimization.

Common platform:
Timer: time.perf_counter
Bits: int=32, long=64, long long=64, size_t=64, void*=64
CPU model: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
Platform: Linux-4.1.6-200.fc22.x86_64-x86_64-with-fedora-22-Twenty_Two
Python unicode implementation: PEP 393
Timer info: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09)
CFLAGS: -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes

Platform of campaign orig:
SCM: hg revision=576128c0d068 tag=tip branch=default date="2015-10-09 10:20 -0400"
Python version: 3.6.0a0 (default:576128c0d068, Oct 9 2015, 22:36:21) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)]
Date: 2015-10-09 22:36:36
Timer precision: 62 ns

Platform of campaign writer:
Python version: 3.6.0a0 (default:576128c0d068+, Oct 9 2015, 22:28:09) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)]
Date: 2015-10-09 22:34:53
SCM: hg revision=576128c0d068+ tag=tip branch=default date="2015-10-09 10:20 -0400"
Timer precision: 65 ns

------------------------------------------------------------+-------------+---------------
%i????????????????????????????????????????????????????????? | ???????orig | ????????writer
------------------------------------------------------------+-------------+---------------
n = 1; fmt = b"%d" * n; arg = tuple([12345]*n); fmt % arg?? | ?155 ns (*) | ?105 ns (-32%)
n = 5; fmt = b"%d" * n; arg = tuple([12345]*n); fmt % arg?? | ?546 ns (*) | ?306 ns (-44%)
n = 10; fmt = b"%d" * n; arg = tuple([12345]*n); fmt % arg? | 1.03 us (*) | ?543 ns (-47%)
n = 25; fmt = b"%d" * n; arg = tuple([12345]*n); fmt % arg? | 2.49 us (*) | 1.27 us (-49%)
n = 100; fmt = b"%d" * n; arg = tuple([12345]*n); fmt % arg | 10.1 us (*) | 5.25 us (-48%)
n = 200; fmt = b"%d" * n; arg = tuple([12345]*n); fmt % arg | 20.5 us (*) | 10.8 us (-47%)
n = 500; fmt = b"%d" * n; arg = tuple([12345]*n); fmt % arg | 48.8 us (*) | 24.6 us (-50%)
------------------------------------------------------------+-------------+---------------
Total?????????????????????????????????????????????????????? | 83.6 us (*) | 42.9 us (-49%)
------------------------------------------------------------+-------------+---------------

---------------------------------------------------------------+-------------+---------------
x=%i?????????????????????????????????????????????????????????? | ???????orig | ????????writer
---------------------------------------------------------------+-------------+---------------
n = 1; fmt = b"x=%d " * n; arg = tuple([12345]*n); fmt % arg?? | ?173 ns (*) | ?123 ns (-29%)
n = 5; fmt = b"x=%d " * n; arg = tuple([12345]*n); fmt % arg?? | ?602 ns (*) | ?372 ns (-38%)
n = 10; fmt = b"x=%d " * n; arg = tuple([12345]*n); fmt % arg? | 1.14 us (*) | ?668 ns (-42%)
n = 25; fmt = b"x=%d " * n; arg = tuple([12345]*n); fmt % arg? | ?2.8 us (*) | 1.56 us (-44%)
n = 100; fmt = b"x=%d " * n; arg = tuple([12345]*n); fmt % arg | 11.1 us (*) | 6.12 us (-45%)
n = 200; fmt = b"x=%d " * n; arg = tuple([12345]*n); fmt % arg | 21.5 us (*) | 12.1 us (-44%)
n = 500; fmt = b"x=%d " * n; arg = tuple([12345]*n); fmt % arg | 53.5 us (*) | 29.8 us (-44%)
---------------------------------------------------------------+-------------+---------------
Total????????????????????????????????????????????????????????? | 90.8 us (*) | 50.7 us (-44%)
---------------------------------------------------------------+-------------+---------------

------------------------------------------------------------+-------------+---------------
%x????????????????????????????????????????????????????????? | ???????orig | ????????writer
------------------------------------------------------------+-------------+---------------
n = 1; fmt = b"%d" * n; arg = tuple([12345]*n); fmt % arg?? | ?155 ns (*) | ?105 ns (-32%)
n = 5; fmt = b"%d" * n; arg = tuple([12345]*n); fmt % arg?? | ?545 ns (*) | ?306 ns (-44%)
n = 10; fmt = b"%d" * n; arg = tuple([12345]*n); fmt % arg? | 1.03 us (*) | ?543 ns (-47%)
n = 25; fmt = b"%d" * n; arg = tuple([12345]*n); fmt % arg? | 2.49 us (*) | 1.26 us (-49%)
n = 100; fmt = b"%d" * n; arg = tuple([12345]*n); fmt % arg | ?9.9 us (*) | 5.07 us (-49%)
n = 200; fmt = b"%d" * n; arg = tuple([12345]*n); fmt % arg | 19.8 us (*) | 10.1 us (-49%)
n = 500; fmt = b"%d" * n; arg = tuple([12345]*n); fmt % arg | 48.9 us (*) | 24.5 us (-50%)
------------------------------------------------------------+-------------+---------------
Total?????????????????????????????????????????????????????? | 82.8 us (*) | 41.9 us (-49%)
------------------------------------------------------------+-------------+---------------

------------------------------------------------------------------+-------------+---------------
x=%x????????????????????????????????????????????????????????????? | ???????orig | ????????writer
------------------------------------------------------------------+-------------+---------------
n = 1; fmt = b"x=%d " * n; arg = tuple([0xabcdef]*n); fmt % arg?? | ?183 ns (*) | ?132 ns (-28%)
n = 5; fmt = b"x=%d " * n; arg = tuple([0xabcdef]*n); fmt % arg?? | ?651 ns (*) | ?419 ns (-36%)
n = 10; fmt = b"x=%d " * n; arg = tuple([0xabcdef]*n); fmt % arg? | 1.23 us (*) | ?761 ns (-38%)
n = 25; fmt = b"x=%d " * n; arg = tuple([0xabcdef]*n); fmt % arg? | 2.96 us (*) | 1.79 us (-40%)
n = 100; fmt = b"x=%d " * n; arg = tuple([0xabcdef]*n); fmt % arg | 11.9 us (*) | 7.13 us (-40%)
n = 200; fmt = b"x=%d " * n; arg = tuple([0xabcdef]*n); fmt % arg | 23.5 us (*) | ??14 us (-41%)
n = 500; fmt = b"x=%d " * n; arg = tuple([0xabcdef]*n); fmt % arg | 58.3 us (*) | 34.3 us (-41%)
------------------------------------------------------------------+-------------+---------------
Total???????????????????????????????????????????????????????????? | 98.6 us (*) | 58.5 us (-41%)
------------------------------------------------------------------+-------------+---------------

--------------------------------------------+-------------+--------------
large int: %i?????????????????????????????? | ???????orig | ???????writer
--------------------------------------------+-------------+--------------
fmt = b"%i"; arg = 10 ** 0 - 1; fmt % arg?? | ?115 ns (*) | ?74 ns (-36%)
fmt = b"%i"; arg = 10 ** 50 - 1; fmt % arg? | ?288 ns (*) | 242 ns (-16%)
fmt = b"%i"; arg = 10 ** 100 - 1; fmt % arg | ?538 ns (*) | ?494 ns (-8%)
fmt = b"%i"; arg = 10 ** 150 - 1; fmt % arg | ?865 ns (*) | ?812 ns (-6%)
fmt = b"%i"; arg = 10 ** 200 - 1; fmt % arg | 1.33 us (*) | ??????1.28 us
--------------------------------------------+-------------+--------------
Total?????????????????????????????????????? | 3.14 us (*) | ?2.9 us (-8%)
--------------------------------------------+-------------+--------------

----------------------------------------------+-------------+---------------
large int: x=%i?????????????????????????????? | ???????orig | ????????writer
----------------------------------------------+-------------+---------------
fmt = b"x=%i"; arg = 10 ** 0 - 1; fmt % arg?? | ?140 ns (*) | ?100 ns (-28%)
fmt = b"x=%i"; arg = 10 ** 50 - 1; fmt % arg? | ?298 ns (*) | ?249 ns (-16%)
fmt = b"x=%i"; arg = 10 ** 100 - 1; fmt % arg | ?548 ns (*) | ??502 ns (-8%)
fmt = b"x=%i"; arg = 10 ** 150 - 1; fmt % arg | ?874 ns (*) | ??822 ns (-6%)
----------------------------------------------+-------------+---------------
Total???????????????????????????????????????? | 1.86 us (*) | 1.67 us (-10%)
----------------------------------------------+-------------+---------------

-------------------+-------------+---------------
Summary??????????? | ???????orig | ????????writer
-------------------+-------------+---------------
%i???????????????? | 83.6 us (*) | 42.9 us (-49%)
x=%i?????????????? | 90.8 us (*) | 50.7 us (-44%)
%x???????????????? | 82.8 us (*) | 41.9 us (-49%)
x=%x?????????????? | 98.6 us (*) | 58.5 us (-41%)
large int: %i????? | 3.14 us (*) | ??2.9 us (-8%)
large int: x=%i??? | 1.86 us (*) | 1.67 us (-10%)
-------------------+-------------+---------------
Total????????????? | ?363 us (*) | ?201 us (-45%)
-------------------+-------------+---------------

----------
Added file: http://bugs.python.org/file40735/bench_bytes_int.py

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

From report at bugs.python.org  Fri Oct  9 22:42:01 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Oct 2015 20:42:01 +0000
Subject: [issue25343] Document atomic operations on builtin types
In-Reply-To: <1444318986.11.0.257913016756.issue25343@psf.upfronthosting.co.za>
Message-ID: <1444423321.72.0.194772992044.issue25343@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think what Terry was asking was, where would you expect to see the disclaimer that *no* operations are guaranteed to be atomic?  That's what we're inclining toward (though we'll probably need a signoff from Guido).

----------

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

From report at bugs.python.org  Fri Oct  9 22:44:05 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Oct 2015 20:44:05 +0000
Subject: [issue25352] Add 'make this my default python' to windows installs
 for Python3.5 and later
In-Reply-To: <1444382005.62.0.6522456142.issue25352@psf.upfronthosting.co.za>
Message-ID: <1444423445.39.0.280459185355.issue25352@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

There used to be such a checkbox, but apparently it had problems.  But there is still something with that effect, at least in part.  When I installed 3.5.0, 'python' was switched from 3.4 to 3.5.  That did not happen with the preliminary releases, because I did somethng different.  Sorry, I don't remember what.

I don't like using the start menu over and over either.  So I pin frequently used programs to the taskbar -- always visible.  The 2.7 IDLE icon just says Python GUI.  In 3.4, it is Python 3.4 GUI.  Ditto for 3.5 and the future.

Steve: when Firefox and some other programs upgrade, the pinned icon remains.  When Python upgrades, the pinned IDLE icon disappears.  When, as is normal, the upgrade is in the same directory, is there any way to leave the icon, since it still points to the right directory and filename?  Or is this icon binary specific?

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Fri Oct  9 22:50:45 2015
From: report at bugs.python.org (eryksun)
Date: Fri, 09 Oct 2015 20:50:45 +0000
Subject: [issue25358] Unexpected behaviour when converting large float to int
In-Reply-To: <1444420460.79.0.0573314564065.issue25358@psf.upfronthosting.co.za>
Message-ID: <1444423845.03.0.144243720546.issue25358@psf.upfronthosting.co.za>


eryksun added the comment:

int(float_version) is returning the actual integer value represented by the float, which is the closest approximation possible using an [IEEE 754 binary64][1], i.e. a C double. Here's one way to compute this value manually:

    from struct import pack
    from fractions import Fraction

    some_number = 1 * 10**44
    float_version = float(some_number)

    n = int.from_bytes(pack('>d', float_version), 'big')
    sign = n >> 63
    exp = ((n >> 52) & (2**11 - 1)) - 1023
    nmantissa = n & (2**52 - 1)
    significand = 1 + sum(Fraction((nmantissa >> (52 - i)) & 1, 2**i)
                          for i in range(52))

    >>> (-1)**sign * significand * 2**exp
    Fraction(100000000000000008821361405306422640701865984, 1)

Or just use the as_integer_ratio method:

    >>> float_version.as_integer_ratio()
    (100000000000000008821361405306422640701865984, 1)

[1]: https://en.wikipedia.org/wiki/Double-precision_floating-point_format

----------
nosy: +eryksun
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Oct  9 22:56:57 2015
From: report at bugs.python.org (Dima Tisnek)
Date: Fri, 09 Oct 2015 20:56:57 +0000
Subject: [issue25343] Document atomic operations on builtin types
In-Reply-To: <1444318986.11.0.257913016756.issue25343@psf.upfronthosting.co.za>
Message-ID: <1444424217.1.0.321121377898.issue25343@psf.upfronthosting.co.za>


Dima Tisnek added the comment:

To clarify, Python language disclaimer can be in the general atomic operations or multithreading section.

What I'd really like to see is documented, practical CPython and stdlib behaviour.

I'm under the impression that there's quite a bit of code out there that relies on what's actually atomic in CPython.

d.

----------

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

From report at bugs.python.org  Fri Oct  9 23:04:48 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Oct 2015 21:04:48 +0000
Subject: [issue25349] Use _PyBytesWriter for bytes%args
In-Reply-To: <1444351825.62.0.273684816362.issue25349@psf.upfronthosting.co.za>
Message-ID: <20151009210441.2685.97886@psf.io>


Roundup Robot added the comment:

New changeset d9a89c9137d2 by Victor Stinner in branch 'default':
Issue #25349: Optimize bytes % int
https://hg.python.org/cpython/rev/d9a89c9137d2

New changeset 4d46d1588629 by Victor Stinner in branch 'default':
Issue #25349: Add fast path for b'%c' % int
https://hg.python.org/cpython/rev/4d46d1588629

----------

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

From report at bugs.python.org  Fri Oct  9 23:06:34 2015
From: report at bugs.python.org (Ankit Baruah)
Date: Fri, 09 Oct 2015 21:06:34 +0000
Subject: [issue25356] Idle (Python 3.4 on Ubuntu) does not allow typing accents
In-Reply-To: <1444404560.14.0.409888700573.issue25356@psf.upfronthosting.co.za>
Message-ID: <1444424794.84.0.120343656344.issue25356@psf.upfronthosting.co.za>


Ankit Baruah added the comment:

Hello, i am totally new.I went through Pythons Developers guide and would like to learn so please tell me what i should learn to resolve this issue.

----------
nosy: + at nkit

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

From report at bugs.python.org  Fri Oct  9 23:06:38 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Oct 2015 21:06:38 +0000
Subject: [issue25349] Use _PyBytesWriter for bytes%args
In-Reply-To: <1444351825.62.0.273684816362.issue25349@psf.upfronthosting.co.za>
Message-ID: <1444424798.76.0.984628485522.issue25349@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ok, I implemented all optimizations which were already implemented in str % args. I close the issue.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Oct  9 23:08:34 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 09 Oct 2015 21:08:34 +0000
Subject: [issue25099] test_compileall fails when run by unprivileged user on
 installed Python
In-Reply-To: <1442205173.06.0.618332067063.issue25099@psf.upfronthosting.co.za>
Message-ID: <1444424914.65.0.133824296748.issue25099@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added new comments.

----------

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

From report at bugs.python.org  Fri Oct  9 23:09:46 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Oct 2015 21:09:46 +0000
Subject: [issue25356] Idle (Python 3.4 on Ubuntu) does not allow typing accents
In-Reply-To: <1444404560.14.0.409888700573.issue25356@psf.upfronthosting.co.za>
Message-ID: <1444424986.53.0.94605387035.issue25356@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

IDLE uses tkinter which wraps the tcl/tk GUI framework.  Tk handles key presses.  So this is almost certainly not an IDLE bug, or even a tkinter bug. Unless you can demonstrate otherwise, I will closing this as a CPython issue.

Since this is the first report I know of reporting a problem with ascii chars, there is almost certainly something peculiar about your system.  You should probably ask for help on python-list (or use the gmane.comp.python.general mirror as news.gmane.org).  Here are some preliminary questions.

Do the keys work in the Ubuntu console?
Do the keys work in interactive python (not IDLE), started with 'python' at the console prompt.
In IDLE, go to Help->About IDLE.  What is the Tk version.
  Best if 8.6.x, if before 8.5.18, upgrade.

Run the following program (IDLE editor is fine).

from tkinter import *
root = Tk()
text = Text(root)
text.pack()
text.focus_set()  # required to work
root.mainloop()

Try typing in the text box, including the problem chars.  What happens?

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Fri Oct  9 23:14:24 2015
From: report at bugs.python.org (Gian Carlo Martinelli)
Date: Fri, 09 Oct 2015 21:14:24 +0000
Subject: [issue25356] Idle (Python 3.4 on Ubuntu) does not allow typing accents
In-Reply-To: <1444404560.14.0.409888700573.issue25356@psf.upfronthosting.co.za>
Message-ID: <1444425264.94.0.214117774841.issue25356@psf.upfronthosting.co.za>


Gian Carlo Martinelli added the comment:

1) Do the keys work in the Ubuntu console?
Yes.

2) Do the keys work in interactive python (not IDLE), started with 'python' at the console prompt.
Yes.

3) In IDLE, go to Help->About IDLE.  What is the Tk version.
  Best if 8.6.x, if before 8.5.18, upgrade.
8.6.1

4) Try typing in the text box, including the problem chars.  What happens?
Ran the program, all characters work perfectly.

----------

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

From report at bugs.python.org  Fri Oct  9 23:15:04 2015
From: report at bugs.python.org (Pavel Roskin)
Date: Fri, 09 Oct 2015 21:15:04 +0000
Subject: [issue25303] Add option to py_compile to compile for syntax checking
 without writing bytecode
In-Reply-To: <1443833531.37.0.101836027368.issue25303@psf.upfronthosting.co.za>
Message-ID: <1444425304.87.0.251623763065.issue25303@psf.upfronthosting.co.za>


Pavel Roskin added the comment:

That's what I have now:

check:
        $(PYTHON) -m py_compile $(SOURCES)
        rm -f $(addsuffix c, $(SOURCES))

make check
python -m py_compile redacted-build redacted-git-diff redacted-git-gc redacted-git-status redacted-init redacted-server
redactedbuilder.py
rm -f redacted-buildc redacted-git-diffc redacted-git-gcc redacted-git-statusc redacted-initc redacted-serverc redactedb
uilder.pyc

That's what David is suggesting:

check:
        for file in $(SOURCES); do \
            python -c "compile(open('$$file').read(), '', 'exec')" || exit 1; \
        done

make check
for file in redacted-build redacted-git-diff redacted-git-gc redacted-git-status redacted-init redacted-server redactedb
uilder.py; do \
            python -c "compile(open('$file').read(), '', 'exec')" || exit 1; \
        done

That's what I could have if I live long enough to see Python 3.6 on my development machine.

check:
        $(PYTHON) -m py_compile --no-output $(SOURCES)

make check
python -m py_compile --no-output redacted-build redacted-git-diff redacted-git-gc redacted-git-status redacted-init redacted-server
redactedbuilder.py

If that does not seem like an important improvement, then I can live with what I have.

----------

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

From report at bugs.python.org  Fri Oct  9 23:15:08 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Oct 2015 21:15:08 +0000
Subject: [issue24870] Optimize ascii and latin1 decoder with surrogateescape
 and surrogatepass error handlers
In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za>
Message-ID: <1444425308.71.0.901186620624.issue24870@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Short summary.

Ok, I optimized ASCII, Latin1 and UTF-8 codecs (encoders and decoders) for the most common error handlers.

* ASCII and Latin1 encoders: surrogateescape, replace, ignore, backslashreplace, xmlcharrefreplace
* ASCII decoder: surrogateescape, replace, ignore
* (Latin1 decoder cannot fail)
* UTF-8 encoder: surrogateescape, surrogatepass, replace, ignore, backslashreplace, xmlcharrefreplace
* UTF-8 decoder: surrogateescape, replace, ignore

The code to handle other error handlers in encoders has also be optimized.

Surrogateescape has now an efficent implementation for ASCII, Latin1 and UTF-8 encoders and decoders.

----------

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

From report at bugs.python.org  Fri Oct  9 23:19:56 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 09 Oct 2015 21:19:56 +0000
Subject: [issue25099] test_compileall fails when run by unprivileged user on
 installed Python
In-Reply-To: <1442205173.06.0.618332067063.issue25099@psf.upfronthosting.co.za>
Message-ID: <1444425596.69.0.809219708868.issue25099@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I have addressed Serhiy's comments again.

----------
Added file: http://bugs.python.org/file40736/issue25099.diff

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

From report at bugs.python.org  Fri Oct  9 23:23:57 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Oct 2015 21:23:57 +0000
Subject: [issue24870] Optimize ascii and latin1 decoder with surrogateescape
 and surrogatepass error handlers
In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za>
Message-ID: <1444425837.37.0.39417843216.issue24870@psf.upfronthosting.co.za>


STINNER Victor added the comment:

INADA Naoki: "I want to Python 3.4 and Python 3.5 solve this issue since it's critical problem for some people."

On microbenchmarks, the optimization that I just implemented in Python 3.6 are impressive. The problem is that the implementation is quite complex. If I understood correctly, you are asking to optimize decoders and encoders for ASCII and UTF-8 (modify 4 functions) for the surrogateescape error handler. Is that right? Would UTF-8 be enough or not?

I don't like backporting optimizations which are not well tested right now. To optimize encoders, I wrote a full new _PyBytesWriter API. We cannot backport this new API, even if it's private. So the backport may be more complex than the code in the default branch.

----------

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

From report at bugs.python.org  Fri Oct  9 23:31:07 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Oct 2015 21:31:07 +0000
Subject: [issue25343] Document atomic operations on builtin types
In-Reply-To: <1444318986.11.0.257913016756.issue25343@psf.upfronthosting.co.za>
Message-ID: <1444426267.48.0.600647018276.issue25343@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think you are correct, and I wouldn't be surprised if there is some in the stdlib as well.

----------

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

From report at bugs.python.org  Fri Oct  9 23:31:27 2015
From: report at bugs.python.org (Ankit Baruah)
Date: Fri, 09 Oct 2015 21:31:27 +0000
Subject: [issue25356] Idle (Python 3.4 on Ubuntu) does not allow typing accents
In-Reply-To: <1444404560.14.0.409888700573.issue25356@psf.upfronthosting.co.za>
Message-ID: <1444426287.81.0.275138544534.issue25356@psf.upfronthosting.co.za>


Ankit Baruah added the comment:

Yes same answers as Gian characters worked perfectly

----------

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

From report at bugs.python.org  Fri Oct  9 23:51:56 2015
From: report at bugs.python.org (shanmbic)
Date: Fri, 09 Oct 2015 21:51:56 +0000
Subject: [issue25354] test_datetime failing
In-Reply-To: <1444397506.38.0.258649046467.issue25354@psf.upfronthosting.co.za>
Message-ID: <1444427516.34.0.103843478433.issue25354@psf.upfronthosting.co.za>


shanmbic added the comment:

make distclean worked. I guess too many reverts in hg caused some issue. :)

----------

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

From report at bugs.python.org  Fri Oct  9 23:53:05 2015
From: report at bugs.python.org (Tim Peters)
Date: Fri, 09 Oct 2015 21:53:05 +0000
Subject: [issue25354] test_datetime failing
In-Reply-To: <1444397506.38.0.258649046467.issue25354@psf.upfronthosting.co.za>
Message-ID: <1444427585.12.0.203076595156.issue25354@psf.upfronthosting.co.za>


Changes by Tim Peters <tim at python.org>:


----------
components: +Library (Lib) -Extension Modules, ctypes
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Oct 10 00:10:18 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Oct 2015 22:10:18 +0000
Subject: [issue25099] test_compileall fails when run by unprivileged user on
 installed Python
In-Reply-To: <1442205173.06.0.618332067063.issue25099@psf.upfronthosting.co.za>
Message-ID: <20151009221015.7262.81222@psf.io>


Roundup Robot added the comment:

New changeset 34bbd537b3e6 by Brett Cannon in branch '3.5':
Issue #25099: Skip relevant tests in test_compileall when an entry on
https://hg.python.org/cpython/rev/34bbd537b3e6

New changeset 21f3a92e0c6d by Brett Cannon in branch 'default':
Merge for issue #25099
https://hg.python.org/cpython/rev/21f3a92e0c6d

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Oct 10 00:10:39 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 09 Oct 2015 22:10:39 +0000
Subject: [issue25099] test_compileall fails when run by unprivileged user on
 installed Python
In-Reply-To: <1442205173.06.0.618332067063.issue25099@psf.upfronthosting.co.za>
Message-ID: <1444428639.84.0.463795783327.issue25099@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks to Serhiy for all of the reviews!

----------
resolution:  -> fixed
stage: commit review -> resolved

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

From report at bugs.python.org  Sat Oct 10 00:11:37 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 09 Oct 2015 22:11:37 +0000
Subject: [issue21264] test_compileall fails to build in the installed location
In-Reply-To: <1397674780.07.0.532661626869.issue21264@psf.upfronthosting.co.za>
Message-ID: <1444428697.72.0.674791857206.issue21264@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I consider this fixed by way of issue #25099. If that's wrong then feel free to open the issue again.

----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> test_compileall fails when run by unprivileged user on installed Python
versions: +Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Oct 10 00:13:57 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Oct 2015 22:13:57 +0000
Subject: [issue25303] Add option to py_compile to compile for syntax checking
 without writing bytecode
In-Reply-To: <1443833531.37.0.101836027368.issue25303@psf.upfronthosting.co.za>
Message-ID: <1444428837.39.0.595078951517.issue25303@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

On the side issue: While the example given, which uses the py_compile.compile defaults via the command line interface, is useless, I disagree that writing a .pyc file for a file without .py is a bug.

Python will run python code with any filename as main module (and not write .pyc).  It will only import the *same code* (and normally write .pyc) if the filename ends with .py (or .pyw on windows).  However, 'import script' will import script.pyc (on the search path) without a script.py file existing.  Using py_compile.compile('script', 'script.pyc') makes that possible.  (I just tried it.)

.

----------

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

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: [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 00:40:32 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Oct 2015 22:40:32 +0000
Subject: [issue25343] Document atomic operations on builtin types
In-Reply-To: <1444318986.11.0.257913016756.issue25343@psf.upfronthosting.co.za>
Message-ID: <1444430432.5.0.336263896176.issue25343@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Yes, I was asking where to put the disclaimer.  The thread docs would be approriate if there is nothing already.

Guido has been very reluctant to put any performance guarantees in the language reference.  I believe he said that O(f(n)) info even for CPython should be in the wiki -- and taken as a guideline, not a iron guarantee.

Further discussion might be better directed to python-ideas, after a search of the pydev and python-ideas archives (most easily done with the gmane mirrors, I believe).

----------

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

From report at bugs.python.org  Sat Oct 10 00:58:24 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Oct 2015 22:58:24 +0000
Subject: [issue25356] Idle (Python 3.4 on Ubuntu) does not allow typing accents
In-Reply-To: <1444404560.14.0.409888700573.issue25356@psf.upfronthosting.co.za>
Message-ID: <1444431504.95.0.243577714684.issue25356@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Ankit: the issue is where do they fail, why, and how to fix.  Are you running Ubuntu also?

G.C. How do you start IDLE? Is the problem with exactly those three chars? Do they fail in the Shell? an editor? search box? other entry box such as you get with Alt-M? Open file dialog (control-O)?

Does this have expected output?

for m in range(32, 128, 16):
    for n in range(16):
        print(chr(m + n), ' ', end='')
    print()
# should print
   !  "  #  $  %  &  '  (  )  *  +  ,  -  .  /  
0  1  2  3  4  5  6  7  8  9  :  ;  <  =  >  ?  
@  A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  
P  Q  R  S  T  U  V  W  X  Y  Z  [  \  ]  ^  _  
`  a  b  c  d  e  f  g  h  i  j  k  l  m  n  o  
p  q  r  s  t  u  v  w  x  y  z  {  |  }  ~    
>>>

----------

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

From report at bugs.python.org  Sat Oct 10 01:40:09 2015
From: report at bugs.python.org (Gian Carlo Martinelli)
Date: Fri, 09 Oct 2015 23:40:09 +0000
Subject: [issue25356] Idle (Python 3.4 on Ubuntu) does not allow typing accents
In-Reply-To: <1444404560.14.0.409888700573.issue25356@psf.upfronthosting.co.za>
Message-ID: <1444434009.35.0.114536293589.issue25356@psf.upfronthosting.co.za>


Gian Carlo Martinelli added the comment:

Terry, first of all thanks for trying to solve this.

I usually start IDLE using Ubuntu's dash.

The problem is with more than just the three characters. Others that I have tested and that don't work include "?", "`", umlauts... There work in others places in my system such as the console for example.

When I try ALT+M or CTRL+O, inside IDLE, these characters work.

This is a copy of my output. Seems OK
!  "  #  $  %  &  '  (  )  *  +  ,  -  .  /  
0  1  2  3  4  5  6  7  8  9  :  ;  <  =  >  ?  
@  A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  
P  Q  R  S  T  U  V  W  X  Y  Z  [  \  ]  ^  _  
`  a  b  c  d  e  f  g  h  i  j  k  l  m  n  o  
p  q  r  s  t  u  v  w  x  y  z  {  |  }  ~  

----------

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

From report at bugs.python.org  Sat Oct 10 01:54:36 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Oct 2015 23:54:36 +0000
Subject: [issue25344] Enhancement to Logging - Logging Stack
In-Reply-To: <1444323958.12.0.353720924326.issue25344@psf.upfronthosting.co.za>
Message-ID: <20151009235432.2692.53466@psf.io>


Roundup Robot added the comment:

New changeset 3ad8a2d34d01 by Vinay Sajip in branch '2.7':
Closes #25344: Added cookbook recipe to show buffering of logging events.
https://hg.python.org/cpython/rev/3ad8a2d34d01

New changeset 7cc3a8141022 by Vinay Sajip in branch '3.4':
Closes #25344: Added cookbook recipe to show buffering of logging events.
https://hg.python.org/cpython/rev/7cc3a8141022

New changeset be13ea160b1a by Vinay Sajip in branch '3.5':
Closes #25344: Merged fix from 3.4.
https://hg.python.org/cpython/rev/be13ea160b1a

New changeset 6c183537b2fb by Vinay Sajip in branch 'default':
Closes #25344: Merged fix from 3.5.
https://hg.python.org/cpython/rev/6c183537b2fb

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Oct 10 03:39:48 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Oct 2015 01:39:48 +0000
Subject: [issue24402] input() uses sys.__stdout__ instead of sys.stdout for
 prompt
In-Reply-To: <1433669452.09.0.930876867216.issue24402@psf.upfronthosting.co.za>
Message-ID: <1444441188.46.0.421765965143.issue24402@psf.upfronthosting.co.za>


Martin Panter added the comment:

Okay I plan to commit a modified version where I moved the input() test methods that use pseudo terminals to a new PtyTests class. The test_input() method stays in the original class, because it shares a helper method with other tests.

I am resisting dropping that decode() step, because it makes any error message from the forked child hard to read:

AssertionError: 256 != 0 : b'quux\r\nTraceback (most recent call last):\r\n  File "/media/disk/home/proj/python/cpython/Lib/test/test_builtin.py", line 1593, in test_input_no_stdout_fileno\r\n    input("prompt")\r\nTypeError: bad argument type for built-in operation\r\n'

----------
nosy: +berker.peksag

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

From report at bugs.python.org  Sat Oct 10 04:10:37 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Oct 2015 02:10:37 +0000
Subject: [issue24402] input() uses sys.__stdout__ instead of sys.stdout for
 prompt
In-Reply-To: <1433669452.09.0.930876867216.issue24402@psf.upfronthosting.co.za>
Message-ID: <20151010021033.97718.93467@psf.io>


Roundup Robot added the comment:

New changeset 425d81d10b13 by Martin Panter in branch '3.4':
Issue #24402: Fix input() when stdout.fileno() fails; diagnosed by Eryksun
https://hg.python.org/cpython/rev/425d81d10b13

New changeset e97d940a6543 by Martin Panter in branch '3.5':
Issue #24402: Merge input() fix from 3.4 into 3.5
https://hg.python.org/cpython/rev/e97d940a6543

New changeset bcc0f8eb6797 by Martin Panter in branch 'default':
Issue #24402: Merge input() fix from 3.5
https://hg.python.org/cpython/rev/bcc0f8eb6797

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Oct 10 04:21:45 2015
From: report at bugs.python.org (Sebastian A. Brachi)
Date: Sat, 10 Oct 2015 02:21:45 +0000
Subject: [issue24978] Contributing to Python 2x and 3x Documentation.
 Translation to Russian.
In-Reply-To: <1441109047.57.0.29993860249.issue24978@psf.upfronthosting.co.za>
Message-ID: <1444443705.12.0.236559630099.issue24978@psf.upfronthosting.co.za>


Sebastian A. Brachi added the comment:

> I wrote a proposal to the board a while ago
I couldn't find that proposal, could you post a link to it? Thanks!

----------
nosy: +Sebastian A. Brachi

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

From report at bugs.python.org  Sat Oct 10 04:39:45 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Oct 2015 02:39:45 +0000
Subject: [issue22413] Bizarre StringIO(newline="\r\n") translation
In-Reply-To: <1410750243.44.0.979805676788.issue22413@psf.upfronthosting.co.za>
Message-ID: <1444444785.29.0.791560051507.issue22413@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the feedback. Yeah, 2.7 is an independent branch, but I will try porting the changes there.

----------
assignee: docs at python -> martin.panter
nosy: +berker.peksag
stage: patch review -> commit review

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

From report at bugs.python.org  Sat Oct 10 04:41:07 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Oct 2015 02:41:07 +0000
Subject: [issue24402] input() uses sys.__stdout__ instead of sys.stdout for
 prompt
In-Reply-To: <1433669452.09.0.930876867216.issue24402@psf.upfronthosting.co.za>
Message-ID: <1444444867.94.0.942032511505.issue24402@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Oct 10 04:59:57 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 10 Oct 2015 02:59:57 +0000
Subject: [issue25356] Idle (Python 3.4 on Ubuntu) does not allow typing accents
In-Reply-To: <1444404560.14.0.409888700573.issue25356@psf.upfronthosting.co.za>
Message-ID: <1444445997.22.0.352534108071.issue25356@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I am not surprised that non-ascii chars fail also. But, all? or just a few (all symbol? or only diacriticals)?

My first thought was that you have a european keyboard that is does not match your Ubuntu configuration.  Or that you had an older tcl/tk that did not work with such.

^O opens a dialog that IDLE is not involved with.  Alt-M open a different tk widget that IDLE in not involved with.

Do shell and editor have exactly the same problems?

Let's try two other things.  Alt-F3 opens Find in Files (grep).  Can you enter any of `'^~ on the first line?

Put anything on the first line and add a *fake* directory on the second (so you have something like zyx/*.py).  Search.  Try typing in the Output Window.  It is slightly different from shell and editor (no colors, for instance).

Ankit: I am trying to narrow possibilities using my knowledge of IDLE internals.  I wish I knew what *I* need to learn for this.

----------

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

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: [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 05:23:04 2015
From: report at bugs.python.org (eryksun)
Date: Sat, 10 Oct 2015 03:23:04 +0000
Subject: [issue25360] pyw should search for pythonw to implement
 #!/usr/bin/env python
In-Reply-To: <1444447306.1.0.629967628506.issue25360@psf.upfronthosting.co.za>
Message-ID: <1444447384.88.0.75408835078.issue25360@psf.upfronthosting.co.za>


Changes by eryksun <eryksun at gmail.com>:


----------
nosy: +vinay.sajip

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

From report at bugs.python.org  Sat Oct 10 05:31:53 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 10 Oct 2015 03:31:53 +0000
Subject: [issue25194] Opt-in motivations & affiliations page for core
 contributors
In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za>
Message-ID: <1444447913.63.0.318503161234.issue25194@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The attached "Final draft" patch is the version I plan to commit tomorrow. Major differences from the previous draft:

* accepted MAL's suggestion of using alphabetical order
* as RDM suggested, explained the rationale for the cases where we encourage people to participate
* after fighting with ReST trying to get it to let me have an indented paragraph following a bulleted list, I eventually hit on the idea of using the "topic" directive to separate entries from each other without introducing an ever expanding list of TOC entries on the main page
* there are now more extensive guidelines inline in the doc as a ReST comment
* three cases of "acceptable links to include" are covered: personal sites, commercial contact details, and crowdfunding
* questions and suggestions (including for new categories of acceptable links) are explicitly directed to the python-committers list

Given the useful feedback from MAL & RDM, I'll hold off on pinging python-committers again until this initial version of the page is live.

Does anyone else want to provide an entry for me to include in the initial commit? It would be good to have a couple more initial entries to help folks generalise from the available examples.

----------
stage: patch review -> commit review
Added file: http://bugs.python.org/file40738/issue25194-motives.diff

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

From report at bugs.python.org  Sat Oct 10 05:41:08 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Oct 2015 03:41:08 +0000
Subject: [issue24402] input() uses sys.__stdout__ instead of sys.stdout for
 prompt
In-Reply-To: <1433669452.09.0.930876867216.issue24402@psf.upfronthosting.co.za>
Message-ID: <1444448468.31.0.372338437128.issue24402@psf.upfronthosting.co.za>


Martin Panter added the comment:

Seems my test hangs the Free BSD 9 buildbot, although Free BSD 10 apparently passed.

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

[390/390] test_builtin
Timeout (1:00:00)!
Thread 0x0000000801407400 (most recent call first):
  File "/usr/home/buildbot/python/3.4.koobs-freebsd9/build/Lib/test/test_builtin.py", line 1585 in test_input_no_stdout_fileno
  File "/usr/home/buildbot/python/3.4.koobs-freebsd9/build/Lib/unittest/case.py", line 580 in run
  File "/usr/home/buildbot/python/3.4.koobs-freebsd9/build/Lib/unittest/case.py", line 628 in __call__

----------
status: closed -> open

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

From report at bugs.python.org  Sat Oct 10 06:01:41 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Oct 2015 04:01:41 +0000
Subject: [issue25357] Add an optional newline parameter to
 binascii.b2a_base64() to not add a newline
In-Reply-To: <1444407716.89.0.315561333899.issue25357@psf.upfronthosting.co.za>
Message-ID: <1444449701.26.0.110707845792.issue25357@psf.upfronthosting.co.za>


Martin Panter added the comment:

The ?newline? name seems as good as any. The patch looks good in general. I left a few comments.

I agree with not bothering for the UU encoder. That encoding has an embedded line length byte at the start of each line, so it makes less sense to omit newlines. Base-64 is used in places such as URLs where multiline output is not relevant, but I don?t know of a similar case for the UU encoding.

If I was doing it, I wouldn?t bother with a test case for keyword-only-ness, but suit yourself.

----------
nosy: +martin.panter

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

From report at bugs.python.org  Sat Oct 10 06:26:23 2015
From: report at bugs.python.org (Ankit Baruah)
Date: Sat, 10 Oct 2015 04:26:23 +0000
Subject: [issue25356] Idle (Python 3.4 on Ubuntu) does not allow typing accents
In-Reply-To: <1444404560.14.0.409888700573.issue25356@psf.upfronthosting.co.za>
Message-ID: <1444451183.97.0.214904693398.issue25356@psf.upfronthosting.co.za>


Ankit Baruah added the comment:

Yes,i am using ubuntu.


Thank you Terry for guiding me really appreciate your help. 
Sorry for not replying fell asleep.

----------

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

From report at bugs.python.org  Sat Oct 10 06:52:10 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 10 Oct 2015 04:52:10 +0000
Subject: [issue24402] input() uses sys.__stdout__ instead of sys.stdout for
 prompt
In-Reply-To: <1433669452.09.0.930876867216.issue24402@psf.upfronthosting.co.za>
Message-ID: <1444452730.33.0.510106962563.issue24402@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

This test also fails on Ubuntu.

[1/1] test_builtin
test test_builtin failed -- Traceback (most recent call last):
  File "/home/angwer/my-cpython/Lib/test/test_builtin.py", line 1588, in test_input_no_stdout_fileno
    self.assertEqual(status, 0, output)
AssertionError: 256 != 0 : quux
Traceback (most recent call last):
  File "/home/angwer/my-cpython/Lib/test/test_builtin.py", line 1593, in test_input_no_stdout_fileno
    input("prompt")
TypeError: bad argument type for built-in operation


1 test failed:
    test_builtin

----------
nosy: +xiang.zhang

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

From report at bugs.python.org  Sat Oct 10 06:53:49 2015
From: report at bugs.python.org (Ankit Baruah)
Date: Sat, 10 Oct 2015 04:53:49 +0000
Subject: [issue25356] Idle (Python 3.4 on Ubuntu) does not allow typing accents
In-Reply-To: <1444404560.14.0.409888700573.issue25356@psf.upfronthosting.co.za>
Message-ID: <1444452829.83.0.657770978226.issue25356@psf.upfronthosting.co.za>


Ankit Baruah added the comment:

Find in Files (grep)
Yes can type `'^~.

Output Window 
Yes seems to work can type `'^~ and other characters.

----------

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

From report at bugs.python.org  Sat Oct 10 07:12:51 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Oct 2015 05:12:51 +0000
Subject: [issue24402] input() uses sys.__stdout__ instead of sys.stdout for
 prompt
In-Reply-To: <1433669452.09.0.930876867216.issue24402@psf.upfronthosting.co.za>
Message-ID: <1444453971.15.0.534655172.issue24402@psf.upfronthosting.co.za>


Martin Panter added the comment:

I wrote this on Arch Linux, so I doubt your Ubuntu failure is valid. The error you see is what I would expect if the bug were not actually fixed. I suspect you need to recompile /Python/bltinmodule.c, which contains the bug fix.

However, the test also hangs OS X buildbots. I can only guess at why it is hanging, either at the waitpid() line or the os.read() line. I am looking at refactoring my test to use the existing check_input_tty() infrastructure. It seems over the top by adding a separate pipe back to the parent process, but presumably will workaround whatever is causing the hang.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24402>
_______________________________________

From report at bugs.python.org  Sat Oct 10 07:28:45 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 10 Oct 2015 05:28:45 +0000
Subject: [issue24402] input() uses sys.__stdout__ instead of sys.stdout for
 prompt
In-Reply-To: <1433669452.09.0.930876867216.issue24402@psf.upfronthosting.co.za>
Message-ID: <1444454925.54.0.645333685045.issue24402@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

It's my fault. I forget to recompile. Now it works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24402>
_______________________________________

From report at bugs.python.org  Sat Oct 10 07:30:25 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Oct 2015 05:30:25 +0000
Subject: [issue24402] input() uses sys.__stdout__ instead of sys.stdout for
 prompt
In-Reply-To: <1433669452.09.0.930876867216.issue24402@psf.upfronthosting.co.za>
Message-ID: <20151010053022.20761.2306@psf.io>


Roundup Robot added the comment:

New changeset d8dd9015b086 by Martin Panter in branch '3.4':
Issue #24402: Factor out PtyTests.run_child() in input() tests
https://hg.python.org/cpython/rev/d8dd9015b086

New changeset 6a8f96b46dce by Martin Panter in branch '3.5':
Issue #24402: Merge potential test fix from 3.4 into 3.5
https://hg.python.org/cpython/rev/6a8f96b46dce

New changeset cb574ee7231e by Martin Panter in branch 'default':
Issue #24402: Merge potential test fix from 3.5
https://hg.python.org/cpython/rev/cb574ee7231e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24402>
_______________________________________

From report at bugs.python.org  Sat Oct 10 08:09:24 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Oct 2015 06:09:24 +0000
Subject: [issue25356] Idle (Python 3.4 on Ubuntu) does not allow typing accents
In-Reply-To: <1444404560.14.0.409888700573.issue25356@psf.upfronthosting.co.za>
Message-ID: <1444457364.69.0.200635025395.issue25356@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Do you have problems with ASCII characters "'", "^", "~", or with combining accents in "a?", "a?", "a?"?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25356>
_______________________________________

From report at bugs.python.org  Sat Oct 10 08:24:04 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Oct 2015 06:24:04 +0000
Subject: [issue25357] Add an optional newline parameter to
 binascii.b2a_base64() to not add a newline
In-Reply-To: <1444407716.89.0.315561333899.issue25357@psf.upfronthosting.co.za>
Message-ID: <1444458244.45.0.856893548269.issue25357@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

With Martin's comments the patch LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25357>
_______________________________________

From report at bugs.python.org  Sat Oct 10 08:29:36 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Oct 2015 06:29:36 +0000
Subject: [issue25359] io.open() fails to open ascii file if LANG env not set
Message-ID: <1444458576.92.0.950124255306.issue25359@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Can't reproduce on Linux.

$ python2.7 io.openBugEx.py
Local pref:  UTF-8
LANG env:  uk_UA.utf8
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
Local pref:  ANSI_X3.4-1968
LANG env has key:  False
ANSI_X3.4-1968
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL

What is your OS?

----------
nosy: +serhiy.storchaka
status: open -> pending
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25359>
_______________________________________

From report at bugs.python.org  Sat Oct 10 08:33:55 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Oct 2015 06:33:55 +0000
Subject: [issue24848] Warts in UTF-7 error handling
In-Reply-To: <1439364965.73.0.526700604341.issue24848@psf.upfronthosting.co.za>
Message-ID: <20151010063352.70990.2337@psf.io>


Roundup Robot added the comment:

New changeset ff1366ff2761 by Serhiy Storchaka in branch '2.7':
Issue #24848: Fixed yet one bug in UTF-7 decoder.  Testing for BASE64 character
https://hg.python.org/cpython/rev/ff1366ff2761

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24848>
_______________________________________

From report at bugs.python.org  Sat Oct 10 09:04:20 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Oct 2015 07:04:20 +0000
Subject: [issue25099] test_compileall fails when run by unprivileged user on
 installed Python
In-Reply-To: <1442205173.06.0.618332067063.issue25099@psf.upfronthosting.co.za>
Message-ID: <1444460660.38.0.362273128478.issue25099@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Do you want to backport the fix to 3.4 (and 2.7?)? Issue21264 was reported for 3.4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25099>
_______________________________________

From report at bugs.python.org  Sat Oct 10 10:27:12 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 10 Oct 2015 08:27:12 +0000
Subject: [issue25341] File mode wb+ appears as rb+
In-Reply-To: <1444290178.48.0.0607111061258.issue25341@psf.upfronthosting.co.za>
Message-ID: <1444465632.89.0.824328673782.issue25341@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I think Mark is right. Since wb+ and rb+ have different behaviours they
should be treat separately.

But this behaviour treating wb+ and rb+ as the same is well tested and
seems to intended to do so.

----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25341>
_______________________________________

From report at bugs.python.org  Sat Oct 10 10:46:11 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Oct 2015 08:46:11 +0000
Subject: [issue25040] xml.sax.make_parser makes bad use of parser_list
 argument default value
In-Reply-To: <1441803251.56.0.483557486647.issue25040@psf.upfronthosting.co.za>
Message-ID: <1444466771.97.0.299727451862.issue25040@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25040>
_______________________________________

From report at bugs.python.org  Sat Oct 10 10:48:25 2015
From: report at bugs.python.org (Mark Williams)
Date: Sat, 10 Oct 2015 08:48:25 +0000
Subject: [issue25341] File mode wb+ appears as rb+
In-Reply-To: <1444465632.89.0.824328673782.issue25341@psf.upfronthosting.co.za>
Message-ID: <CA+TSurB+0CbUZZcc9eU-KKJo1Yf4GKbcYD_o6HZ0kxNPHruKeg@mail.gmail.com>


Mark Williams added the comment:

Python's test suite may test the current behavior but that does not lessen
the problem.

I gave an example of apparently correct code that fails (that was actually
encountered by a Python user) in my original description.  Another such
example: you cannot duplicate a file object -- same path, same mode --- and
be sure that the duplicate is a true duplicate.  Data corruption could
occur in application code if the duplicated file were opened "rb+" instead
of "wb+", as the duplicate would not truncate existing data.

Another way to think about the problem is accuracy of intent.  The mode
attribute on file objects can be incorrect, and by "incorrect" I mean "not
describe the mode under which the file was opened."  Why have a mode
attribute at all, then?  I, for one, would prefer *no* mode attribute to
one that's sometimes incorrect.  But a correct one is even better!

On Sat, Oct 10, 2015 at 1:27 AM, Xiang Zhang <report at bugs.python.org> wrote:

>
> Xiang Zhang added the comment:
>
> I think Mark is right. Since wb+ and rb+ have different behaviours they
> should be treat separately.
>
> But this behaviour treating wb+ and rb+ as the same is well tested and
> seems to intended to do so.
>
> ----------
> nosy: +xiang.zhang
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue25341>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25341>
_______________________________________

From report at bugs.python.org  Sat Oct 10 10:54:45 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 10 Oct 2015 08:54:45 +0000
Subject: [issue25341] File mode wb+ appears as rb+
In-Reply-To: <1444290178.48.0.0607111061258.issue25341@psf.upfronthosting.co.za>
Message-ID: <1444467285.28.0.248688267619.issue25341@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I make a patch which now identifies the difference between wb+ and rb+,
and modifies the corresponding tests. Though I don't know whether this
need to be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25341>
_______________________________________

From report at bugs.python.org  Sat Oct 10 10:54:58 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 10 Oct 2015 08:54:58 +0000
Subject: [issue25341] File mode wb+ appears as rb+
In-Reply-To: <1444290178.48.0.0607111061258.issue25341@psf.upfronthosting.co.za>
Message-ID: <1444467298.81.0.0771979830661.issue25341@psf.upfronthosting.co.za>


Changes by Xiang Zhang <18518281186 at 126.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file40739/file_mode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25341>
_______________________________________

From report at bugs.python.org  Sat Oct 10 12:04:49 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Oct 2015 10:04:49 +0000
Subject: [issue24402] input() uses sys.__stdout__ instead of sys.stdout for
 prompt
In-Reply-To: <1433669452.09.0.930876867216.issue24402@psf.upfronthosting.co.za>
Message-ID: <1444471489.84.0.737670071269.issue24402@psf.upfronthosting.co.za>


Martin Panter added the comment:

My second attempt seems to have avoided the hang.

For the record, the backtrace from 3.4.koobs-freebsd9 did say it was hanging at the os.waitpid() line, but I still don?t understand why.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24402>
_______________________________________

From report at bugs.python.org  Sat Oct 10 12:25:39 2015
From: report at bugs.python.org (Laura Creighton)
Date: Sat, 10 Oct 2015 10:25:39 +0000
Subject: [issue25352] Add 'make this my default python' to windows installs
 for Python3.5 and later
In-Reply-To: <1444382005.62.0.6522456142.issue25352@psf.upfronthosting.co.za>
Message-ID: <1444472739.2.0.24968414012.issue25352@psf.upfronthosting.co.za>


Laura Creighton added the comment:

I think it would be useful if the IDLE icon was overlayed with 
the text of what version of Python you are running.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25352>
_______________________________________

From report at bugs.python.org  Sat Oct 10 12:31:03 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Oct 2015 10:31:03 +0000
Subject: [issue25161] Missing periods at the end of sentences
In-Reply-To: <1442560890.27.0.253223646248.issue25161@psf.upfronthosting.co.za>
Message-ID: <1444473063.45.0.416510597525.issue25161@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
assignee: docs at python -> martin.panter
nosy: +berker.peksag
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25161>
_______________________________________

From report at bugs.python.org  Sat Oct 10 12:31:23 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Oct 2015 10:31:23 +0000
Subject: [issue22413] Bizarre StringIO(newline="\r\n") translation
In-Reply-To: <1410750243.44.0.979805676788.issue22413@psf.upfronthosting.co.za>
Message-ID: <20151010103120.2695.35465@psf.io>


Roundup Robot added the comment:

New changeset 57fc950298bb by Martin Panter in branch '2.7':
Issue #22413: Document newline effect on StringIO initializer and getvalue
https://hg.python.org/cpython/rev/57fc950298bb

New changeset cba4bf2a1721 by Martin Panter in branch '3.4':
Issue #22413: Document newline effect on StringIO initializer and getvalue
https://hg.python.org/cpython/rev/cba4bf2a1721

New changeset 451da3327f68 by Martin Panter in branch '3.5':
Issue #22413: Merge StringIO doc from 3.4 into 3.5
https://hg.python.org/cpython/rev/451da3327f68

New changeset 46df76819b79 by Martin Panter in branch '3.5':
Issue #22413: Remove comment made out of date by Argument Clinic
https://hg.python.org/cpython/rev/46df76819b79

New changeset c12d3f941731 by Martin Panter in branch 'default':
Issue #22413: Merge StringIO doc from 3.5
https://hg.python.org/cpython/rev/c12d3f941731

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22413>
_______________________________________

From report at bugs.python.org  Sat Oct 10 12:33:57 2015
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 10 Oct 2015 10:33:57 +0000
Subject: [issue5380] pty.read raises IOError when slave pty device is closed
In-Reply-To: <1235721814.23.0.522352333065.issue5380@psf.upfronthosting.co.za>
Message-ID: <1444473237.73.0.813171249412.issue5380@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The line discipline [1] of a terminal driver and a pty is controlled by terminal attributes set with tcsetattr() [2][3].

IMHO (as a developer running ptys over asyncio), using a pty implies writing code at the low level such as configuring the line discipline, or possibly dealing with the notions of controlling terminal, process group and so on. So it seems right that Python io would not support ptys as Python io sits at a higher level.

[1] http://en.wikipedia.org/wiki/Line_discipline
[2] http://www.gnu.org/software/libc/manual/html_node/Terminal-Modes.html
[3] http://docs.python.org/3/library/termios.html?highlight=termios#module-termios

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5380>
_______________________________________

From report at bugs.python.org  Sat Oct 10 12:37:49 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Oct 2015 10:37:49 +0000
Subject: [issue22413] Bizarre StringIO(newline="\r\n") translation
In-Reply-To: <1410750243.44.0.979805676788.issue22413@psf.upfronthosting.co.za>
Message-ID: <1444473469.63.0.453347675554.issue22413@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution: wont fix -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22413>
_______________________________________

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: [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 12:43:38 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Oct 2015 10:43:38 +0000
Subject: [issue25322] contextlib.suppress not tested for nested usage
In-Reply-To: <1444123306.69.0.0149294325224.issue25322@psf.upfronthosting.co.za>
Message-ID: <1444473818.45.0.669319418433.issue25322@psf.upfronthosting.co.za>


Martin Panter added the comment:

Okay maybe ?ignored? wasn?t the best choice of variable name. Perhaps I will write ?outer_continued = True? instead.

----------
assignee:  -> martin.panter
nosy: +berker.peksag
stage:  -> commit review
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25322>
_______________________________________

From report at bugs.python.org  Sat Oct 10 12:53:42 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Oct 2015 10:53:42 +0000
Subject: [issue25161] Missing periods at the end of sentences
In-Reply-To: <1442560890.27.0.253223646248.issue25161@psf.upfronthosting.co.za>
Message-ID: <20151010105339.471.42988@psf.io>


Roundup Robot added the comment:

New changeset 4dfead9635e5 by Martin Panter in branch '3.4':
Issue #25161: Add full stops in documentation; patch by Takase Arihiro
https://hg.python.org/cpython/rev/4dfead9635e5

New changeset be34d96e2184 by Martin Panter in branch '3.5':
Issue #25161: Merge full stops from 3.4 into 3.5
https://hg.python.org/cpython/rev/be34d96e2184

New changeset fe87a6f9caa7 by Martin Panter in branch 'default':
Issue #25161: Merge full stops from 3.5
https://hg.python.org/cpython/rev/fe87a6f9caa7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25161>
_______________________________________

From report at bugs.python.org  Sat Oct 10 12:57:17 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 10 Oct 2015 10:57:17 +0000
Subject: [issue25352] Add 'make this my default python' to windows installs
 for Python3.5 and later
In-Reply-To: <1444382005.62.0.6522456142.issue25352@psf.upfronthosting.co.za>
Message-ID: <1444474637.25.0.813204577394.issue25352@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Desktop shortcuts all have a label.  The 3.4 and 3.5 labels have the python version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25352>
_______________________________________

From report at bugs.python.org  Sat Oct 10 12:57:54 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Oct 2015 10:57:54 +0000
Subject: [issue25161] Missing periods at the end of sentences
In-Reply-To: <1442560890.27.0.253223646248.issue25161@psf.upfronthosting.co.za>
Message-ID: <20151010105751.477.39453@psf.io>


Roundup Robot added the comment:

New changeset b9a0ecae02cb by Martin Panter in branch '2.7':
Issue #25161: Add full stops in documentation; patch by Takase Arihiro
https://hg.python.org/cpython/rev/b9a0ecae02cb

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25161>
_______________________________________

From report at bugs.python.org  Sat Oct 10 13:10:39 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Oct 2015 11:10:39 +0000
Subject: [issue25322] contextlib.suppress not tested for nested usage
In-Reply-To: <1444123306.69.0.0149294325224.issue25322@psf.upfronthosting.co.za>
Message-ID: <20151010111036.70986.45753@psf.io>


Roundup Robot added the comment:

New changeset 452f76cbebdd by Martin Panter in branch '3.4':
Issue #25322: Fix test for nested contextlib.suppress
https://hg.python.org/cpython/rev/452f76cbebdd

New changeset 836ac579e179 by Martin Panter in branch '3.5':
Issue #25322: Merge contextlib.suppress test fix from 3.4 into 3.5
https://hg.python.org/cpython/rev/836ac579e179

New changeset c601496c2829 by Martin Panter in branch 'default':
Issue #25322: Merge contextlib.suppress test fix from 3.5
https://hg.python.org/cpython/rev/c601496c2829

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25322>
_______________________________________

From report at bugs.python.org  Sat Oct 10 13:41:53 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Oct 2015 11:41:53 +0000
Subject: [issue25161] Missing periods at the end of sentences
In-Reply-To: <1442560890.27.0.253223646248.issue25161@psf.upfronthosting.co.za>
Message-ID: <1444477313.61.0.177654429538.issue25161@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks very much for the patches.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25161>
_______________________________________

From report at bugs.python.org  Sat Oct 10 13:43:20 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Oct 2015 11:43:20 +0000
Subject: [issue25322] contextlib.suppress not tested for nested usage
In-Reply-To: <1444123306.69.0.0149294325224.issue25322@psf.upfronthosting.co.za>
Message-ID: <1444477400.73.0.822122743717.issue25322@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25322>
_______________________________________

From report at bugs.python.org  Sat Oct 10 14:10:17 2015
From: report at bugs.python.org (eryksun)
Date: Sat, 10 Oct 2015 12:10:17 +0000
Subject: [issue25361] Is python-3-5-0.exe compiled with SSE2 instrutions? If
 so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1444479017.05.0.0332061077722.issue25361@psf.upfronthosting.co.za>


eryksun added the comment:

With Visual Studio 2010 and earlier, SSE support had to be explicitly enabled. Starting with VS2012 it's on by default [1]:

    Because the x86 compiler generates code that uses SSE2 
    instructions by default, you must specify /arch:IA32 to 
    disable generation of SSE and SSE2 instructions for x86 
    processors.

For 3.5, the 32-bit build does use SSE2 instructions. For example, float_add uses the addsd instruction (opcode F2 0F 58):

    0:000> s python35!float_add l100 f2 0f 58
    71f6c5d8  f2 0f 58 44 24 08 8b 0d-84 11 18 72 f2 0f 11 44  ..XD$......r...D
    0:000> u 71f6c5d8 l3
    python35!float_add+0x98:
    71f6c5d8 f20f58442408    addsd   xmm0,mmword ptr [esp+8]
    71f6c5de 8b0d84111872    mov     ecx,dword ptr [python35!free_list (72181184)]
    71f6c5e4 f20f11442410    movsd   mmword ptr [esp+10h],xmm0

Thus 3.5 doesn't support older CPUs that lack SSE2, such as the AMD Athlon XP. I didn't check the installer itself, but that would be a pointless exercise.

[1]: https://msdn.microsoft.com/en-us/library/7t5yh4fd

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25361>
_______________________________________

From report at bugs.python.org  Sat Oct 10 14:33:38 2015
From: report at bugs.python.org (Laura Creighton)
Date: Sat, 10 Oct 2015 12:33:38 +0000
Subject: [issue25352] Add 'make this my default python' to windows installs
 for Python3.5 and later
In-Reply-To: <1444382005.62.0.6522456142.issue25352@psf.upfronthosting.co.za>
Message-ID: <1444480418.72.0.266556954916.issue25352@psf.upfronthosting.co.za>


Laura Creighton added the comment:

Okay, sorry for the noise then.  The problems of not having a windows system to check.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25352>
_______________________________________

From report at bugs.python.org  Sat Oct 10 14:42:34 2015
From: report at bugs.python.org (Laura Creighton)
Date: Sat, 10 Oct 2015 12:42:34 +0000
Subject: [issue25361] Is python-3-5-0.exe compiled with SSE2 instrutions? If
 so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1444480954.61.0.59283288583.issue25361@psf.upfronthosting.co.za>


Laura Creighton added the comment:

Okay then, wherever we put the -- Beginning with 3.5 we are not
supporting 3.5 we need to also tell people whose CPUs lack SSE2
that they are out of luck, as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25361>
_______________________________________

From report at bugs.python.org  Sat Oct 10 15:32:30 2015
From: report at bugs.python.org (Gian Carlo Martinelli)
Date: Sat, 10 Oct 2015 13:32:30 +0000
Subject: [issue25356] Idle (Python 3.4 on Ubuntu) does not allow typing accents
In-Reply-To: <1444404560.14.0.409888700573.issue25356@psf.upfronthosting.co.za>
Message-ID: <1444483950.71.0.479819907249.issue25356@psf.upfronthosting.co.za>


Gian Carlo Martinelli added the comment:

@Terry
Using 'Find in Files' (Alt+F3) works fine. I can type everything normally. Also in the Output everything is fine.

Apparently the problem is only with diacriticals (I mentioned '?', but it is working (I have a particular key for that in my keyboard... it is a Brazilian keyboard)).

@Serhiy
The problem is both with standalone keys ('`~^) and accented characters (????? etc)



Today I found a very strange behaviour.

IF I start IDLE with a clean file, everything works fine. 

If then I open a .py file, or save the new file as .py, after 3-5 seconds these keys stop working. Very strange...

I hope I was clear in describing this.

@Ankit: check if this behavior is the same for you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25356>
_______________________________________

From report at bugs.python.org  Sat Oct 10 16:03:45 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 10 Oct 2015 14:03:45 +0000
Subject: [issue25361] Is python-3-5-0.exe compiled with SSE2 instrutions? If
 so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1444485825.09.0.727204336268.issue25361@psf.upfronthosting.co.za>


Steve Dower added the comment:

Did that report come with any reason for SSE to be relevant, such as an error message or log file?

Windows requires SSE these days, since Vista IIRC, so the problem is probably someone on XP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25361>
_______________________________________

From report at bugs.python.org  Sat Oct 10 16:30:34 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 10 Oct 2015 14:30:34 +0000
Subject: [issue25322] contextlib.suppress not tested for nested usage
In-Reply-To: <1444123306.69.0.0149294325224.issue25322@psf.upfronthosting.co.za>
Message-ID: <1444487434.58.0.189228930988.issue25322@psf.upfronthosting.co.za>


R. David Murray added the comment:

I had no problem understanding that ignored meant the exception had been ignored, but making it clearer certainly doesn't hurt.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25322>
_______________________________________

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: [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 16:49:29 2015
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 10 Oct 2015 14:49:29 +0000
Subject: [issue24940] RotatingFileHandler uses tell in non-binary mode to
 determine size of the file in bytes
In-Reply-To: <1440559082.45.0.784571189082.issue24940@psf.upfronthosting.co.za>
Message-ID: <1444488569.76.0.378646913981.issue24940@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

But this is a change in behaviour which might cause people a problem. The way it is now, the size may be approximate rather than exact, which is reasonable for the use case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24940>
_______________________________________

From report at bugs.python.org  Sat Oct 10 16:53:25 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 10 Oct 2015 14:53:25 +0000
Subject: [issue25362] In threading module, use with instead of try finally
In-Reply-To: <1444487860.53.0.808291026774.issue25362@psf.upfronthosting.co.za>
Message-ID: <1444488805.35.0.989266432889.issue25362@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
title: Use with instead of try finally -> In threading module, use with instead of try finally

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25362>
_______________________________________

From report at bugs.python.org  Sat Oct 10 17:08:38 2015
From: report at bugs.python.org (Nir Soffer)
Date: Sat, 10 Oct 2015 15:08:38 +0000
Subject: [issue25362] In threading module, use with instead of try finally
In-Reply-To: <1444487860.53.0.808291026774.issue25362@psf.upfronthosting.co.za>
Message-ID: <1444489718.67.0.704884060058.issue25362@psf.upfronthosting.co.za>


Changes by Nir Soffer <nirsof at gmail.com>:


Added file: http://bugs.python.org/file40741/0001-In-threading-module-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: [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:38:22 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 10 Oct 2015 15:38:22 +0000
Subject: [issue5380] pty.read raises IOError when slave pty device is closed
In-Reply-To: <1235721814.23.0.522352333065.issue5380@psf.upfronthosting.co.za>
Message-ID: <1444491502.95.0.440240305669.issue5380@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

OK, I'm closing this as won't fix. If someone disagrees please explain.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5380>
_______________________________________

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: [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 17:51:58 2015
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 10 Oct 2015 15:51:58 +0000
Subject: [issue25342] test_json segfault on OpenBSD
In-Reply-To: <0E4C8DEA-DAE2-4EF7-9976-BD099157F9F8@wirtel.be>
Message-ID: <1444492318.16.0.021270392717.issue25342@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Adjusting the estimate at runtime sounds good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25342>
_______________________________________

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: [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:08:46 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 10 Oct 2015 16:08:46 +0000
Subject: [issue25099] test_compileall fails when run by unprivileged user on
 installed Python
In-Reply-To: <1442205173.06.0.618332067063.issue25099@psf.upfronthosting.co.za>
Message-ID: <1444493326.33.0.880357837867.issue25099@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I feel I have already spent way too much time on this issue, but if you want to backport even further then feel free to.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25099>
_______________________________________

From report at bugs.python.org  Sat Oct 10 18:12:27 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Oct 2015 16:12:27 +0000
Subject: [issue25365] test_pickle fails with --without-threads
In-Reply-To: <1444492895.03.0.158264675245.issue25365@psf.upfronthosting.co.za>
Message-ID: <1444493547.11.0.255099879585.issue25365@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25365>
_______________________________________

From report at bugs.python.org  Sat Oct 10 18:12:55 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Oct 2015 16:12:55 +0000
Subject: [issue25364] zipfile broken with --without-threads
In-Reply-To: <1444491902.09.0.108690377093.issue25364@psf.upfronthosting.co.za>
Message-ID: <1444493575.12.0.605260041477.issue25364@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25364>
_______________________________________

From report at bugs.python.org  Sat Oct 10 18:15:33 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 10 Oct 2015 16:15:33 +0000
Subject: [issue25363] x=[1,2,3].append([1,2,3]) bug
In-Reply-To: <1444491475.67.0.0313628985758.issue25363@psf.upfronthosting.co.za>
Message-ID: <1444493733.9.0.215031219194.issue25363@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

This is the right behaviour.

x=[1, 2, 3].append([1, 2, 3]) acts as:

    x=([1, 2, 3].append([1, 2, 3])

Since append is a in-place operation it return None. Then x is None.

----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25363>
_______________________________________

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: [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 18:28:22 2015
From: report at bugs.python.org (Bar Harel)
Date: Sat, 10 Oct 2015 16:28:22 +0000
Subject: [issue25177] OverflowError in statistics.mean when summing large
 floats
In-Reply-To: <1442662840.23.0.781753910755.issue25177@psf.upfronthosting.co.za>
Message-ID: <1444494502.17.0.976011910225.issue25177@psf.upfronthosting.co.za>


Bar Harel added the comment:

Any comments on the patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25177>
_______________________________________

From report at bugs.python.org  Sat Oct 10 18:39:47 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 10 Oct 2015 16:39:47 +0000
Subject: [issue25363] x=[1,2,3].append([1,2,3]) bug
In-Reply-To: <1444491475.67.0.0313628985758.issue25363@psf.upfronthosting.co.za>
Message-ID: <1444495187.18.0.630610393387.issue25363@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25363>
_______________________________________

From report at bugs.python.org  Sat Oct 10 18:45:04 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Oct 2015 16:45:04 +0000
Subject: [issue25364] zipfile broken with --without-threads
In-Reply-To: <1444491902.09.0.108690377093.issue25364@psf.upfronthosting.co.za>
Message-ID: <20151010164501.70956.40159@psf.io>


Roundup Robot added the comment:

New changeset 15740b3ad148 by Serhiy Storchaka in branch '3.5':
Issue #25364: zipfile now works in threads disabled builds.
https://hg.python.org/cpython/rev/15740b3ad148

New changeset 44b37c3ee76c by Serhiy Storchaka in branch 'default':
Issue #25364: zipfile now works in threads disabled builds.
https://hg.python.org/cpython/rev/44b37c3ee76c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25364>
_______________________________________

From report at bugs.python.org  Sat Oct 10 18:46:23 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Oct 2015 16:46:23 +0000
Subject: [issue25364] zipfile broken with --without-threads
In-Reply-To: <1444491902.09.0.108690377093.issue25364@psf.upfronthosting.co.za>
Message-ID: <1444495583.56.0.718414737907.issue25364@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your report Arfrever.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25364>
_______________________________________

From report at bugs.python.org  Sat Oct 10 18:58:11 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 10 Oct 2015 16:58:11 +0000
Subject: [issue24784] Build fails with --with-pydebug and --without-threads
In-Reply-To: <1438592818.36.0.612740760113.issue24784@psf.upfronthosting.co.za>
Message-ID: <1444496291.65.0.64811574199.issue24784@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
keywords: +3.5regression
nosy: +Arfrever
title: Build fails --without-threads -> Build fails with --with-pydebug and --without-threads
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24784>
_______________________________________

From report at bugs.python.org  Sat Oct 10 19:06:30 2015
From: report at bugs.python.org (Laura Creighton)
Date: Sat, 10 Oct 2015 17:06:30 +0000
Subject: [issue25361] Is python-3-5-0.exe compiled with SSE2 instrutions? If
 so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1444496790.06.0.76910603436.issue25361@psf.upfronthosting.co.za>


Laura Creighton added the comment:

Further conversation has confirmed that the person is on XP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25361>
_______________________________________

From report at bugs.python.org  Sat Oct 10 19:07:42 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 10 Oct 2015 17:07:42 +0000
Subject: [issue25341] File mode wb+ appears as rb+
In-Reply-To: <1444290178.48.0.0607111061258.issue25341@psf.upfronthosting.co.za>
Message-ID: <1444496862.31.0.433899458717.issue25341@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25341>
_______________________________________

From report at bugs.python.org  Sat Oct 10 19:08:55 2015
From: report at bugs.python.org (Laura Creighton)
Date: Sat, 10 Oct 2015 17:08:55 +0000
Subject: [issue25361] Is python-3-5-0.exe compiled with SSE2 instrutions? If
 so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1444496935.76.0.0399261128747.issue25361@psf.upfronthosting.co.za>


Laura Creighton added the comment:

He says that he got an error saying something was compiled SSE2 and needed to be SSE, but if we are going to detect XP then that will be
a better error message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25361>
_______________________________________

From report at bugs.python.org  Sat Oct 10 19:12:43 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Oct 2015 17:12:43 +0000
Subject: [issue25365] test_pickle fails with --without-threads
In-Reply-To: <1444492895.03.0.158264675245.issue25365@psf.upfronthosting.co.za>
Message-ID: <20151010171238.7252.71482@psf.io>


Roundup Robot added the comment:

New changeset 1cb9ce2d83d8 by Serhiy Storchaka in branch '3.4':
Issue #25365: test_pickle now works in threads disabled builds.
https://hg.python.org/cpython/rev/1cb9ce2d83d8

New changeset 48cb00431ce6 by Serhiy Storchaka in branch '3.5':
Issue #25365: test_pickle now works in threads disabled builds.
https://hg.python.org/cpython/rev/48cb00431ce6

New changeset 655fd1e9b444 by Serhiy Storchaka in branch 'default':
Issue #25365: test_pickle now works in threads disabled builds.
https://hg.python.org/cpython/rev/655fd1e9b444

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25365>
_______________________________________

From report at bugs.python.org  Sat Oct 10 19:28:45 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Oct 2015 17:28:45 +0000
Subject: [issue25099] test_compileall fails when run by unprivileged user on
 installed Python
In-Reply-To: <1442205173.06.0.618332067063.issue25099@psf.upfronthosting.co.za>
Message-ID: <20151010172842.2687.3346@psf.io>


Roundup Robot added the comment:

New changeset fc0a7aa7ae61 by Brett Cannon in branch '3.4':
Issue #25099: Skip relevant tests in test_compileall when an entry on
https://hg.python.org/cpython/rev/fc0a7aa7ae61

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25099>
_______________________________________

From report at bugs.python.org  Sat Oct 10 19:29:38 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Oct 2015 17:29:38 +0000
Subject: [issue25365] test_pickle fails with --without-threads
In-Reply-To: <1444492895.03.0.158264675245.issue25365@psf.upfronthosting.co.za>
Message-ID: <1444498178.58.0.584997025385.issue25365@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your report Arfrever.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25365>
_______________________________________

From report at bugs.python.org  Sat Oct 10 19:51:39 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Oct 2015 17:51:39 +0000
Subject: [issue25194] Opt-in motivations & affiliations page for core
 contributors
In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za>
Message-ID: <1444499499.64.0.578464608718.issue25194@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

A few comments:

1) In the "Restrictions on scope" section, you could turn "Contributor Licensing Agreement" into a link.
2) You call this a "program" in a couple of place, and I'm not sure that's the right term (to me "program" sounds like an organized effort brought forward by the PSF rather than just a self-compiled list of names).
3) I would have kept the 2 disclosure-related cases separate from the availability for paid work, but I guess practicality beats purity and the paragraph you added to clarifies the difference does a good-enough job.
4) In the "commercial contacts" bullet point, you could clarify what kind of contacts are allowed (e.g. link, email address, phone numbers, company address, etc.).
5) Several devs already have a bio page on the wiki.  Instead of repeating it here, it might be easier to just add a link to that.  This makes the list shorter and easier to read, and allows people to write as much as they want on their wiki page.
6) If the bio is moved to the wiki, a more concise table-based approach might work better.  The table can include columns for names, affiliations, availability for paid work (just a check mark), link to bio, and possibly other links.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25194>
_______________________________________

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: [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: [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 20:41:30 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 10 Oct 2015 18:41:30 +0000
Subject: [issue25368] test_eintr fails with --without-threads
In-Reply-To: <1444502478.57.0.122084998013.issue25368@psf.upfronthosting.co.za>
Message-ID: <1444502490.2.0.670898030303.issue25368@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
title: test_eintr -> test_eintr fails with --without-threads

_______________________________________
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: [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 21:12:41 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 10 Oct 2015 19:12:41 +0000
Subject: [issue25369] test_regrtest fails with --without-threads
In-Reply-To: <1444504132.12.0.946058661737.issue25369@psf.upfronthosting.co.za>
Message-ID: <1444504361.7.0.240556593844.issue25369@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file40743/test_regrtest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25369>
_______________________________________

From report at bugs.python.org  Sat Oct 10 21:15:54 2015
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 10 Oct 2015 19:15:54 +0000
Subject: [issue24870] Optimize ascii and latin1 decoder with surrogateescape
 and surrogatepass error handlers
In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za>
Message-ID: <1444504554.0.0.646010145038.issue24870@psf.upfronthosting.co.za>


INADA Naoki added the comment:

UTF-8 and Latin1 are typical encoding for MySQL query.
When inserting BLOB:

# Decode binary data
x = data.decode('ascii', 'surrogateescape')
# %-format query
psql = sql % (escape(x),)  # sql is unicode
# Encode sql to connection encoding (latin1 or utf8)
query_bytes = psql.encode('utf-8', 'surrogateescape')

So decoder speedup is required only for ascii, but encoder speedup is required for utf-8 and latin1.

I'll consider other ways including creating speedup module and register it on PyPI.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24870>
_______________________________________

From report at bugs.python.org  Sat Oct 10 21:24:36 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 10 Oct 2015 19:24:36 +0000
Subject: [issue24784] Build fails with --with-pydebug and --without-threads
In-Reply-To: <1438592818.36.0.612740760113.issue24784@psf.upfronthosting.co.za>
Message-ID: <1444505076.92.0.567547270147.issue24784@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

Calls to PyGILState_Check() in Python/fileutils.c were introduced in revisions 0b99d7043a99 and cfe541c694f3.
Call to PyGILState_Check() in Modules/socketmodule.c was introduced in revision 75fcc7a3738a.

----------
assignee:  -> haypo
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24784>
_______________________________________

From report at bugs.python.org  Sat Oct 10 21:27:44 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 10 Oct 2015 19:27:44 +0000
Subject: [issue24784] Build fails with --with-pydebug and --without-threads
In-Reply-To: <1438592818.36.0.612740760113.issue24784@psf.upfronthosting.co.za>
Message-ID: <1444505264.51.0.470046687102.issue24784@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

> Call to PyGILState_Check() in Modules/socketmodule.c was introduced in revision 75fcc7a3738a.

Actually that call was moved from another place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24784>
_______________________________________

From report at bugs.python.org  Sat Oct 10 21:29:43 2015
From: report at bugs.python.org (eryksun)
Date: Sat, 10 Oct 2015 19:29:43 +0000
Subject: [issue25361] Is python-3-5-0.exe compiled with SSE2 instrutions? If
 so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1444505383.8.0.295992074886.issue25361@psf.upfronthosting.co.za>


eryksun added the comment:

> Windows requires SSE these days, since Vista IIRC, so the problem 
> is probably someone on XP.

Windows 8 is the first to require SSE2 [1][2]. I'm sure it's no coincidence that this became the default in VS 2012. 

There is probably a small minority of users that upgraded to 32-bit Windows 7 on old hardware. Python 3.5 excludes them, but I don't think the build should switch to using /arch:IA32 just to support them. If a user on such a system really needs 3.5, it's possible to create a private build without SSE2. Most packages that have extension modules will also have to be built from source instead of using prebuilt wheels.

[1]: http://windows.microsoft.com/en-us/windows7/products/system-requirements
[2]: http://windows.microsoft.com/en-US/windows-8/system-requirements

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25361>
_______________________________________

From report at bugs.python.org  Sat Oct 10 21:41:39 2015
From: report at bugs.python.org (Laura Creighton)
Date: Sat, 10 Oct 2015 19:41:39 +0000
Subject: [issue25361] Is python-3-5-0.exe compiled with SSE2 instrutions? If
 so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1444506099.01.0.629729670885.issue25361@psf.upfronthosting.co.za>


Laura Creighton added the comment:

Ok, where do we put the info about how to create a private build?  And
who will write it?  (I lack the understanding.) Does it belong in:
https://docs.python.org/3/using/windows.html

or some place else?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25361>
_______________________________________

From report at bugs.python.org  Sat Oct 10 21:43:02 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Oct 2015 19:43:02 +0000
Subject: [issue24164] Support pickling objects with __new__ with keyword
 arguments with protocol 2+
In-Reply-To: <1431341390.51.0.0928642680419.issue24164@psf.upfronthosting.co.za>
Message-ID: <20151010194259.128836.8888@psf.io>


Roundup Robot added the comment:

New changeset bc5894a3a0e6 by Serhiy Storchaka in branch 'default':
Issue #24164: Objects that need calling ``__new__`` with keyword arguments,
https://hg.python.org/cpython/rev/bc5894a3a0e6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24164>
_______________________________________

From report at bugs.python.org  Sat Oct 10 21:44:08 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Oct 2015 19:44:08 +0000
Subject: [issue24164] Support pickling objects with __new__ with keyword
 arguments with protocol 2+
In-Reply-To: <1431341390.51.0.0928642680419.issue24164@psf.upfronthosting.co.za>
Message-ID: <1444506248.82.0.201225445612.issue24164@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your review Victor.

----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24164>
_______________________________________

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: [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  Sat Oct 10 22:06:33 2015
From: report at bugs.python.org (eryksun)
Date: Sat, 10 Oct 2015 20:06:33 +0000
Subject: [issue25361] Is python-3-5-0.exe compiled with SSE2 instrutions? If
 so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1444507593.14.0.343695432563.issue25361@psf.upfronthosting.co.za>


eryksun added the comment:

Building Python 3.5 requires Visual Studio 2015 and Windows 8.1, so this would be a vanishingly small audience that's building to deploy on old 32-bit Windows 7 machines. I don't think the PSF needs to worry about this. Anyway, the "/arch (x86)" docs [1] explain how to configure a project to use IA32, and PCBuild/readme.txt [2] explains how to build Python using Visual Studio 2015. I know this doesn't really help a novice user; just tell them to install Python 3.4!

[1]: https://msdn.microsoft.com/en-us/library/7t5yh4fd

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25361>
_______________________________________

From report at bugs.python.org  Sat Oct 10 22:08:47 2015
From: report at bugs.python.org (eryksun)
Date: Sat, 10 Oct 2015 20:08:47 +0000
Subject: [issue25361] Is python-3-5-0.exe compiled with SSE2 instrutions? If
 so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1444507727.65.0.355380098708.issue25361@psf.upfronthosting.co.za>


eryksun added the comment:

Sorry, I forgot to include the link to readme.txt:

[2]: https://hg.python.org/cpython/file/v3.5.0/PCbuild/readme.txt

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25361>
_______________________________________

From report at bugs.python.org  Sun Oct 11 00:05:02 2015
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 10 Oct 2015 22:05:02 +0000
Subject: [issue25177] OverflowError in statistics.mean when summing large
 floats
In-Reply-To: <1444494502.17.0.976011910225.issue25177@psf.upfronthosting.co.za>
Message-ID: <20151010220455.GJ28222@ando.pearwood.info>


Steven D'Aprano added the comment:

On Sat, Oct 10, 2015 at 04:28:22PM +0000, Bar Harel wrote:
> Any comments on the patch?

Not yet, I've been unable to look at it, but thank you. If I haven't 
responded by the 17th of this month, please ping me again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25177>
_______________________________________

From report at bugs.python.org  Sun Oct 11 00:47:33 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 10 Oct 2015 22:47:33 +0000
Subject: [issue25367] test_coroutines fails with --without-threads
In-Reply-To: <1444501201.87.0.229985434953.issue25367@psf.upfronthosting.co.za>
Message-ID: <1444517253.16.0.425497385916.issue25367@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Can you test with this patch?

----------
keywords: +patch
Added file: http://bugs.python.org/file40744/coro-skip.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25367>
_______________________________________

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: [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:32:51 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Oct 2015 02:32:51 +0000
Subject: [issue25371] select.select docstring needs comma
In-Reply-To: <1444521219.18.0.906188853689.issue25371@psf.upfronthosting.co.za>
Message-ID: <20151011023246.128826.30464@psf.io>


Roundup Robot added the comment:

New changeset 99c82576bb70 by Benjamin Peterson in branch '3.4':
add a missing comma (closes #25371)
https://hg.python.org/cpython/rev/99c82576bb70

New changeset ae98209ff69a by Benjamin Peterson in branch '3.5':
merge 3.4 (#25371)
https://hg.python.org/cpython/rev/ae98209ff69a

New changeset d2d8c1c8c258 by Benjamin Peterson in branch 'default':
merge 3.5 (#25371)
https://hg.python.org/cpython/rev/d2d8c1c8c258

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25371>
_______________________________________

From report at bugs.python.org  Sun Oct 11 04:37:07 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Oct 2015 02:37:07 +0000
Subject: [issue25362] In threading module, use with instead of try finally
In-Reply-To: <1444487860.53.0.808291026774.issue25362@psf.upfronthosting.co.za>
Message-ID: <20151011023704.2683.27229@psf.io>


Roundup Robot added the comment:

New changeset 9049134eecae by Benjamin Peterson in branch '2.7':
use the with statement for locking the internal condition (closes #25362)
https://hg.python.org/cpython/rev/9049134eecae

New changeset 62e87422a1a9 by Benjamin Peterson in branch '3.4':
use the with statement for locking the internal condition (closes #25362)
https://hg.python.org/cpython/rev/62e87422a1a9

New changeset 794101c6e560 by Benjamin Peterson in branch '3.5':
merge 3.4 (#25362)
https://hg.python.org/cpython/rev/794101c6e560

New changeset 555ab69f071a by Benjamin Peterson in branch 'default':
merge 3.5 (#25362)
https://hg.python.org/cpython/rev/555ab69f071a

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25362>
_______________________________________

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: [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 05:28:37 2015
From: report at bugs.python.org (Pathangi Jatinshravan)
Date: Sun, 11 Oct 2015 03:28:37 +0000
Subject: [issue25372] load_module() does not link submodule to parent package
In-Reply-To: <1444531632.83.0.513711320874.issue25372@psf.upfronthosting.co.za>
Message-ID: <1444534117.28.0.20322734722.issue25372@psf.upfronthosting.co.za>


Pathangi Jatinshravan added the comment:

Hi, if this is not too critical of a bug, can I be assigned to this issue?

----------
nosy: +Pathangi Jatinshravan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25372>
_______________________________________

From report at bugs.python.org  Sun Oct 11 05:36:49 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 11 Oct 2015 03:36:49 +0000
Subject: [issue25372] load_module() does not link submodule to parent package
In-Reply-To: <1444531632.83.0.513711320874.issue25372@psf.upfronthosting.co.za>
Message-ID: <1444534609.02.0.79338542461.issue25372@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'm no expert on pep 302 either, but I'm guessing this is an intentional part of the design.  You'll note that updating the namespace is *not* mentioned as one of the things load_module has to do.  The update of the namespace is something the import system as a whole implements, and I'm not sure where it happens (probably __import__/import_module).

Unless you are saying that this is a regression, it doesn't really matter if it was intentional or not, since if it is not a regression then it's been that way for a long time.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25372>
_______________________________________

From report at bugs.python.org  Sun Oct 11 06:25:43 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 11 Oct 2015 04:25:43 +0000
Subject: [issue25367] test_coroutines fails with --without-threads
In-Reply-To: <1444501201.87.0.229985434953.issue25367@psf.upfronthosting.co.za>
Message-ID: <1444537543.62.0.461621461681.issue25367@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

It works.
A more standard way would be 'self.skipTest(...)' instead of 'raise unittest.SkipTest(...)'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25367>
_______________________________________

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: [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:36:35 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 11 Oct 2015 04:36:35 +0000
Subject: [issue25373] test.regrtest: -jN (with N != 1) + --slow + child error
 or interruption = TypeError
In-Reply-To: <1444538091.0.0.0447780927267.issue25373@psf.upfronthosting.co.za>
Message-ID: <1444538195.29.0.049187065841.issue25373@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file40746/regrtest-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25373>
_______________________________________

From report at bugs.python.org  Sun Oct 11 06:36:58 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 11 Oct 2015 04:36:58 +0000
Subject: [issue25373] test.regrtest: -jN (with N != 1) + --slow + child error
 or interruption = TypeError
In-Reply-To: <1444538091.0.0.0447780927267.issue25373@psf.upfronthosting.co.za>
Message-ID: <1444538218.54.0.295645858707.issue25373@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


Added file: http://bugs.python.org/file40747/regrtest-3.4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25373>
_______________________________________

From report at bugs.python.org  Sun Oct 11 06:37:15 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 11 Oct 2015 04:37:15 +0000
Subject: [issue25373] test.regrtest: -jN (with N != 1) + --slow + child error
 or interruption = TypeError
In-Reply-To: <1444538091.0.0.0447780927267.issue25373@psf.upfronthosting.co.za>
Message-ID: <1444538235.02.0.126215510691.issue25373@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


Added file: http://bugs.python.org/file40748/regrtest-3.5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25373>
_______________________________________

From report at bugs.python.org  Sun Oct 11 06:37:30 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 11 Oct 2015 04:37:30 +0000
Subject: [issue25373] test.regrtest: -jN (with N != 1) + --slow + child error
 or interruption = TypeError
In-Reply-To: <1444538091.0.0.0447780927267.issue25373@psf.upfronthosting.co.za>
Message-ID: <1444538250.86.0.31757103702.issue25373@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


Added file: http://bugs.python.org/file40749/regrtest-3.6.patch

_______________________________________
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: [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 06:49:17 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Oct 2015 04:49:17 +0000
Subject: [issue25367] test_coroutines fails with --without-threads
In-Reply-To: <1444501201.87.0.229985434953.issue25367@psf.upfronthosting.co.za>
Message-ID: <1444538957.09.0.733831772681.issue25367@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

You also can use special helper: test.support.import_module().

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25367>
_______________________________________

From report at bugs.python.org  Sun Oct 11 06:51:07 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Oct 2015 04:51:07 +0000
Subject: [issue25372] load_module() does not link submodule to parent package
In-Reply-To: <1444531632.83.0.513711320874.issue25372@psf.upfronthosting.co.za>
Message-ID: <1444539067.33.0.316132025255.issue25372@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +brett.cannon, eric.snow, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25372>
_______________________________________

From report at bugs.python.org  Sun Oct 11 06:55:01 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 11 Oct 2015 04:55:01 +0000
Subject: [issue25367] test_coroutines fails with --without-threads
In-Reply-To: <1444501201.87.0.229985434953.issue25367@psf.upfronthosting.co.za>
Message-ID: <1444539301.0.0.150635682255.issue25367@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Can one of you produce a proper patch? Then the other can review. Serhiy can commit it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25367>
_______________________________________

From report at bugs.python.org  Sun Oct 11 06:57:52 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 11 Oct 2015 04:57:52 +0000
Subject: [issue25372] load_module() does not link submodule to parent package
In-Reply-To: <1444531632.83.0.513711320874.issue25372@psf.upfronthosting.co.za>
Message-ID: <1444539472.23.0.806100813722.issue25372@psf.upfronthosting.co.za>


Martin Panter added the comment:

I don?t think it is a regression. But it is annoying, because my code that works fine for top-level modules and packages happens to screw up the import system for deeper-level module names.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25372>
_______________________________________

From report at bugs.python.org  Sun Oct 11 06:58:45 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 11 Oct 2015 04:58:45 +0000
Subject: [issue25372] load_module() does not link submodule to parent package
In-Reply-To: <1444531632.83.0.513711320874.issue25372@psf.upfronthosting.co.za>
Message-ID: <1444539525.95.0.531378765017.issue25372@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25372>
_______________________________________

From report at bugs.python.org  Sun Oct 11 07:23:06 2015
From: report at bugs.python.org (Pavel Roskin)
Date: Sun, 11 Oct 2015 05:23:06 +0000
Subject: [issue25303] Add option to py_compile to compile for syntax checking
 without writing bytecode
In-Reply-To: <1443833531.37.0.101836027368.issue25303@psf.upfronthosting.co.za>
Message-ID: <1444540986.17.0.331160251825.issue25303@psf.upfronthosting.co.za>


Pavel Roskin added the comment:

Thank you for the comments. I was annoyed by py_compile making files with names very similar to the original scripts, names that could not even be recognized by shell patterns in .gitignore unless scripts ending with "c" are banned. But that problem is addressed in Python 3. I don't really care what files are in __pycache__, I won't have that urge to remove them. And then I simply was annoyed by the fact that py_compile was ignoring my attempts to suppress its output. Now I understand the reason for that. Migrating to Python 3 would address my original problem with strange looking cache files. I'm going to close this issue.

----------
nosy: +Pavel Roskin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25303>
_______________________________________

From report at bugs.python.org  Sun Oct 11 07:27:40 2015
From: report at bugs.python.org (Ilya Kulakov)
Date: Sun, 11 Oct 2015 05:27:40 +0000
Subject: [issue24575] timemodule build fail - missing definitions for
 _Py_BEGIN_SUPPRESS_IPH and _Py_END_SUPPRESS_IPH
In-Reply-To: <1436188396.48.0.089424009249.issue24575@psf.upfronthosting.co.za>
Message-ID: <1444541260.54.0.419137813259.issue24575@psf.upfronthosting.co.za>


Ilya Kulakov added the comment:

Why is it important to hide these 2 macroses behind Py_BUILD_CORE?

Certain tools for embedding python may try to compile modules independently. I realize that it's not a problem of Python to take care of that, but in that particular case if hiding these 2 macroses behind Py_BUILD_CORE is not required, it may help to retain compatibility with such tools.

----------
nosy: +Ilya.Kulakov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24575>
_______________________________________

From report at bugs.python.org  Sun Oct 11 07:36:19 2015
From: report at bugs.python.org (Chris Angelico)
Date: Sun, 11 Oct 2015 05:36:19 +0000
Subject: [issue12813] uuid4 is not tested if a uuid4 system routine isn't
 present
In-Reply-To: <1313995301.93.0.316946106703.issue12813@psf.upfronthosting.co.za>
Message-ID: <1444541779.29.0.823696210226.issue12813@psf.upfronthosting.co.za>


Chris Angelico added the comment:

3.6 doesn't have this check, so I would say that yes, this has indeed been fixed. Issue can be closed fixed.

----------
nosy: +Rosuav

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12813>
_______________________________________

From report at bugs.python.org  Sun Oct 11 07:38:44 2015
From: report at bugs.python.org (Chris Angelico)
Date: Sun, 11 Oct 2015 05:38:44 +0000
Subject: [issue15999] Using new 'bool' format character
In-Reply-To: <1348242429.94.0.662282558141.issue15999@psf.upfronthosting.co.za>
Message-ID: <1444541924.0.0.618121822859.issue15999@psf.upfronthosting.co.za>


Chris Angelico added the comment:

Has this been entirely superseded by Argument Clinic?

----------
nosy: +Rosuav

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15999>
_______________________________________

From report at bugs.python.org  Sun Oct 11 07:49:51 2015
From: report at bugs.python.org (Chris Angelico)
Date: Sun, 11 Oct 2015 05:49:51 +0000
Subject: [issue20216] Misleading docs for sha1, sha256, sha512, md5 modules
In-Reply-To: <1389320490.58.0.128009418019.issue20216@psf.upfronthosting.co.za>
Message-ID: <1444542591.67.0.663778856011.issue20216@psf.upfronthosting.co.za>


Chris Angelico added the comment:

"bytes of binary data" seems redundant - how about just "byte string"? Otherwise, sure.

----------
nosy: +Rosuav

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20216>
_______________________________________

From report at bugs.python.org  Sun Oct 11 07:50:47 2015
From: report at bugs.python.org (Chris Angelico)
Date: Sun, 11 Oct 2015 05:50:47 +0000
Subject: [issue18769] argparse remove subparser
In-Reply-To: <1376757040.66.0.700111900917.issue18769@psf.upfronthosting.co.za>
Message-ID: <1444542647.47.0.193922867476.issue18769@psf.upfronthosting.co.za>


Chris Angelico added the comment:

Patch applies cleanly to 3.6 and doesn't appear to add any new test failures (3.6 currently has a couple). Needs its own test, though.

----------
nosy: +Rosuav
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18769>
_______________________________________

From report at bugs.python.org  Sun Oct 11 07:59:29 2015
From: report at bugs.python.org (Chris Angelico)
Date: Sun, 11 Oct 2015 05:59:29 +0000
Subject: [issue22228] Adapt bash readline operate-and-get-next function
In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za>
Message-ID: <1444543169.52.0.610856042357.issue22228@psf.upfronthosting.co.za>


Chris Angelico added the comment:

Any other interest in this? It'd be nice to get this in trunk and start being able to recommend it to people.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22228>
_______________________________________

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: [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 08:25:04 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Oct 2015 06:25:04 +0000
Subject: [issue25375] Don't mention 2.2 in the 3.x docs
In-Reply-To: <1444544103.53.0.168517351377.issue25375@psf.upfronthosting.co.za>
Message-ID: <20151011062501.18376.75897@psf.io>


Roundup Robot added the comment:

New changeset a81b47fb5848 by Benjamin Peterson in branch '2.7':
don't mention Python 2.2 (closes #25375)
https://hg.python.org/cpython/rev/a81b47fb5848

New changeset 275d388ca1fc by Benjamin Peterson in branch '3.4':
don't mention Python 2.2 (closes #25375)
https://hg.python.org/cpython/rev/275d388ca1fc

New changeset 0017245ff5ce by Benjamin Peterson in branch 'default':
merge 3.5 (#25375)
https://hg.python.org/cpython/rev/0017245ff5ce

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25375>
_______________________________________

From report at bugs.python.org  Sun Oct 11 08:41:52 2015
From: report at bugs.python.org (Chris Angelico)
Date: Sun, 11 Oct 2015 06:41:52 +0000
Subject: [issue6259] ctypes pointer arithmetic
In-Reply-To: <1244662680.17.0.41540856406.issue6259@psf.upfronthosting.co.za>
Message-ID: <1444545712.76.0.696169566896.issue6259@psf.upfronthosting.co.za>


Chris Angelico added the comment:

Nudging this as a forgotten patch. Is anyone at all interested in this, or should it be closed as not worth the hassle? The patch is ancient and doesn't apply to 3.6.

Propose closing, to clean up the tracker. It can always be reopened if the patch is updated to current.

----------
nosy: +Rosuav

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6259>
_______________________________________

From report at bugs.python.org  Sun Oct 11 09:48:13 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Oct 2015 07:48:13 +0000
Subject: [issue25368] test_eintr fails with --without-threads
In-Reply-To: <1444502478.57.0.122084998013.issue25368@psf.upfronthosting.co.za>
Message-ID: <20151011074810.20757.79072@psf.io>


Roundup Robot added the comment:

New changeset 42101b8f777c by Victor Stinner in branch 'default':
Close #25368: Fix test_eintr when Python is compiled without thread support
https://hg.python.org/cpython/rev/42101b8f777c

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25368>
_______________________________________

From report at bugs.python.org  Sun Oct 11 09:50:16 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 11 Oct 2015 07:50:16 +0000
Subject: [issue24164] Support pickling objects with __new__ with keyword
 arguments with protocol 2+
In-Reply-To: <1431341390.51.0.0928642680419.issue24164@psf.upfronthosting.co.za>
Message-ID: <1444549816.76.0.912378893973.issue24164@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Buildbots failed.

http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.x/builds/2807/steps/test/logs/stdio

======================================================================
FAIL: test_reduce (test.test_descr.PicklingTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_descr.py", line 4745, in test_reduce
    obj.__reduce_ex__(proto)
AssertionError: ValueError not raised

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24164>
_______________________________________

From report at bugs.python.org  Sun Oct 11 09:54:00 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 11 Oct 2015 07:54:00 +0000
Subject: [issue24164] Support pickling objects with __new__ with keyword
 arguments with protocol 2+
In-Reply-To: <1431341390.51.0.0928642680419.issue24164@psf.upfronthosting.co.za>
Message-ID: <1444550040.72.0.934601924455.issue24164@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24164>
_______________________________________

From report at bugs.python.org  Sun Oct 11 09:55:00 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Oct 2015 07:55:00 +0000
Subject: [issue24784] Build fails with --with-pydebug and --without-threads
In-Reply-To: <1438592818.36.0.612740760113.issue24784@psf.upfronthosting.co.za>
Message-ID: <20151011075457.128828.88039@psf.io>


Roundup Robot added the comment:

New changeset 3ab4f23ab983 by Victor Stinner in branch 'default':
Close #24784: Fix compilation without thread support
https://hg.python.org/cpython/rev/3ab4f23ab983

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24784>
_______________________________________

From report at bugs.python.org  Sun Oct 11 10:04:41 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Oct 2015 08:04:41 +0000
Subject: [issue25369] test_regrtest fails with --without-threads
In-Reply-To: <1444504132.12.0.946058661737.issue25369@psf.upfronthosting.co.za>
Message-ID: <20151011080437.97700.47448@psf.io>


Roundup Robot added the comment:

New changeset 0d0d83b1c078 by Victor Stinner in branch 'default':
Close #25369: Fix test_regrtest without thread support
https://hg.python.org/cpython/rev/0d0d83b1c078

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25369>
_______________________________________

From report at bugs.python.org  Sun Oct 11 10:12:52 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Oct 2015 08:12:52 +0000
Subject: [issue24784] Build fails with --with-pydebug and --without-threads
In-Reply-To: <1438592818.36.0.612740760113.issue24784@psf.upfronthosting.co.za>
Message-ID: <20151011081246.70990.52258@psf.io>


Roundup Robot added the comment:

New changeset 20ef719b1cb9 by Victor Stinner in branch '3.5':
Close #24784: Fix compilation without thread support
https://hg.python.org/cpython/rev/20ef719b1cb9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24784>
_______________________________________

From report at bugs.python.org  Sun Oct 11 10:12:52 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Oct 2015 08:12:52 +0000
Subject: [issue25367] test_coroutines fails with --without-threads
In-Reply-To: <1444501201.87.0.229985434953.issue25367@psf.upfronthosting.co.za>
Message-ID: <20151011081246.70990.25518@psf.io>


Roundup Robot added the comment:

New changeset d8737b841fcf by Victor Stinner in branch '3.5':
Close #25367: Fix test_coroutines with no thread support
https://hg.python.org/cpython/rev/d8737b841fcf

New changeset d8002372e5df by Victor Stinner in branch 'default':
Merge 3.5 (test_coroutines, issue #25367)
https://hg.python.org/cpython/rev/d8002372e5df

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25367>
_______________________________________

From report at bugs.python.org  Sun Oct 11 10:13:25 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 11 Oct 2015 08:13:25 +0000
Subject: [issue25367] test_coroutines fails with --without-threads
In-Reply-To: <1444501201.87.0.229985434953.issue25367@psf.upfronthosting.co.za>
Message-ID: <1444551205.64.0.803360724771.issue25367@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I fixed the issue based on Guido's patch and Serhiy's suggestion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25367>
_______________________________________

From report at bugs.python.org  Sun Oct 11 10:20:14 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 11 Oct 2015 08:20:14 +0000
Subject: [issue25367] test_coroutines fails with --without-threads
In-Reply-To: <1444501201.87.0.229985434953.issue25367@psf.upfronthosting.co.za>
Message-ID: <1444551614.15.0.652111614641.issue25367@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

======================================================================
ERROR: test_asyncio_1 (test.test_coroutines.CoroAsyncIOCompatTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/cpython/Lib/test/test_coroutines.py", line 1351, in test_asyncio_1
    loop = asyncio.new_event_loop()
NameError: name 'asyncio' is not defined

----------------------------------------------------------------------

----------
resolution: fixed -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25367>
_______________________________________

From report at bugs.python.org  Sun Oct 11 10:41:10 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 11 Oct 2015 08:41:10 +0000
Subject: [issue6259] ctypes pointer arithmetic
In-Reply-To: <1244662680.17.0.41540856406.issue6259@psf.upfronthosting.co.za>
Message-ID: <1444552869.99.0.387740329234.issue6259@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for triaging work, but an outdated patch is not an enough reason to close an issue. Also, the default value of "status" field is "open" at http://bugs.python.org/issue?@template=search&status=1 so closing an unresolved issue will make it harder to find for potential interested contributors. See https://docs.python.org/devguide/triaging.html for more information.

----------
nosy: +berker.peksag
stage:  -> needs patch
versions: +Python 3.6 -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6259>
_______________________________________

From report at bugs.python.org  Sun Oct 11 10:41:14 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Oct 2015 08:41:14 +0000
Subject: [issue25373] test.regrtest: -jN (with N != 1) + --slow + child error
 or interruption = TypeError
In-Reply-To: <1444538091.0.0.0447780927267.issue25373@psf.upfronthosting.co.za>
Message-ID: <20151011084111.18388.94904@psf.io>


Roundup Robot added the comment:

New changeset 746b98342943 by Victor Stinner in branch 'default':
Close #25373: Fix regrtest --slow with interrupted test
https://hg.python.org/cpython/rev/746b98342943

New changeset ef70e5373131 by Victor Stinner in branch '3.5':
lose #25373: Fix regrtest --slow with interrupted test
https://hg.python.org/cpython/rev/ef70e5373131

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25373>
_______________________________________

From report at bugs.python.org  Sun Oct 11 10:44:32 2015
From: report at bugs.python.org (Chris Angelico)
Date: Sun, 11 Oct 2015 08:44:32 +0000
Subject: [issue6259] ctypes pointer arithmetic
In-Reply-To: <1244662680.17.0.41540856406.issue6259@psf.upfronthosting.co.za>
Message-ID: <1444553072.54.0.481232930874.issue6259@psf.upfronthosting.co.za>


Chris Angelico added the comment:

Fair enough. Still needs someone to update the patch though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6259>
_______________________________________

From report at bugs.python.org  Sun Oct 11 10:44:40 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 11 Oct 2015 08:44:40 +0000
Subject: [issue25373] test.regrtest: -jN (with N != 1) + --slow + child error
 or interruption = TypeError
In-Reply-To: <1444538091.0.0.0447780927267.issue25373@psf.upfronthosting.co.za>
Message-ID: <1444553080.28.0.885269595533.issue25373@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Python 2.7 is not affected by the bug (I'm unable to reproduce it on Python 2.7).

Python 3.4 is near end-of-life and this bug looks like a corner case, I don't think that it's worth to fix it.

I fixed the bug in Python 3.5 and 3.6. I added an unit test for Python 3.6 (test_regrtest). Thanks for the report Arfrever.

----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25373>
_______________________________________

From report at bugs.python.org  Sun Oct 11 10:46:13 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 11 Oct 2015 08:46:13 +0000
Subject: [issue25373] test.regrtest: -jN (with N != 1) + --slow + child error
 or interruption = TypeError
In-Reply-To: <1444538091.0.0.0447780927267.issue25373@psf.upfronthosting.co.za>
Message-ID: <1444553173.13.0.348547794957.issue25373@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh! I didn't see that you proposed a fix, sorry. I fixed the bug differently. IMHO it's easier to not add the test to test_times.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25373>
_______________________________________

From report at bugs.python.org  Sun Oct 11 10:51:44 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 11 Oct 2015 08:51:44 +0000
Subject: [issue24575] timemodule build fail - missing definitions for
 _Py_BEGIN_SUPPRESS_IPH and _Py_END_SUPPRESS_IPH
In-Reply-To: <1436188396.48.0.089424009249.issue24575@psf.upfronthosting.co.za>
Message-ID: <1444553504.79.0.909527560001.issue24575@psf.upfronthosting.co.za>


STINNER Victor added the comment:

setup.py gets C flags from Makefile using the sysconfig module. You must have -DBUILD_CORE in Makefile. When I compiled Python using "./configure; make" the time module is build.

How do you compile Python?

"#define _Py_BEGIN_SUPPRESS_IPH" is already declared in pyport.h which is included by Python.h, and timemodule.c includes Python.h.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24575>
_______________________________________

From report at bugs.python.org  Sun Oct 11 10:54:06 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Oct 2015 08:54:06 +0000
Subject: [issue25367] test_coroutines fails with --without-threads
In-Reply-To: <1444501201.87.0.229985434953.issue25367@psf.upfronthosting.co.za>
Message-ID: <20151011085403.18364.40066@psf.io>


Roundup Robot added the comment:

New changeset 493845d905c5 by Victor Stinner in branch '3.5':
Close #25367: Fix test_coroutines()
https://hg.python.org/cpython/rev/493845d905c5

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25367>
_______________________________________

From report at bugs.python.org  Sun Oct 11 10:54:33 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 11 Oct 2015 08:54:33 +0000
Subject: [issue25367] test_coroutines fails with --without-threads
In-Reply-To: <1444501201.87.0.229985434953.issue25367@psf.upfronthosting.co.za>
Message-ID: <1444553673.03.0.0209256041893.issue25367@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> NameError: name 'asyncio' is not defined

Oops :-( I also fixed this one, sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25367>
_______________________________________

From report at bugs.python.org  Sun Oct 11 10:57:14 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 11 Oct 2015 08:57:14 +0000
Subject: [issue25368] test_eintr fails with --without-threads
In-Reply-To: <20151011074810.20757.79072@psf.io>
Message-ID: <CAMpsgwbUct_42XkZD1==G0Mgo2C5jMdCg3T9h1M2vS+WrfhDtg@mail.gmail.com>


STINNER Victor added the comment:

It's now fixed, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25368>
_______________________________________

From report at bugs.python.org  Sun Oct 11 10:57:34 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 11 Oct 2015 08:57:34 +0000
Subject: [issue25369] test_regrtest fails with --without-threads
In-Reply-To: <20151011080437.97700.47448@psf.io>
Message-ID: <CAMpsgwaxLRELqh2UFufUbfh2v7oro6CAJ5xWf-uP4Sfsr1x3ng@mail.gmail.com>


STINNER Victor added the comment:

It's now fixed, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25369>
_______________________________________

From report at bugs.python.org  Sun Oct 11 10:58:01 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 11 Oct 2015 08:58:01 +0000
Subject: [issue24784] Build fails with --with-pydebug and --without-threads
In-Reply-To: <20151011081246.70990.52258@psf.io>
Message-ID: <CAMpsgwZTizmV-OEr3JkyRAoA+n5+N6kOy1JZhakqWxM815FSnw@mail.gmail.com>


STINNER Victor added the comment:

It's now fixed, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24784>
_______________________________________

From report at bugs.python.org  Sun Oct 11 11:01:35 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Oct 2015 09:01:35 +0000
Subject: [issue25357] Add an optional newline parameter to
 binascii.b2a_base64() to not add a newline
In-Reply-To: <1444407716.89.0.315561333899.issue25357@psf.upfronthosting.co.za>
Message-ID: <20151011090132.483.10139@psf.io>


Roundup Robot added the comment:

New changeset 463a09a3bfff by Victor Stinner in branch 'default':
Issue #25357: Add an optional newline paramer to binascii.b2a_base64().
https://hg.python.org/cpython/rev/463a09a3bfff

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25357>
_______________________________________

From report at bugs.python.org  Sun Oct 11 11:02:38 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 11 Oct 2015 09:02:38 +0000
Subject: [issue25357] Add an optional newline parameter to
 binascii.b2a_base64() to not add a newline
In-Reply-To: <1444407716.89.0.315561333899.issue25357@psf.upfronthosting.co.za>
Message-ID: <1444554158.13.0.31810626058.issue25357@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Thanks for reviews Serhiy & Martin.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25357>
_______________________________________

From report at bugs.python.org  Sun Oct 11 11:10:00 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 11 Oct 2015 09:10:00 +0000
Subject: [issue25373] test.regrtest: -jN (with N != 1) + --slow + child error
 or interruption = TypeError
In-Reply-To: <1444538091.0.0.0447780927267.issue25373@psf.upfronthosting.co.za>
Message-ID: <1444554600.4.0.603649449742.issue25373@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

Apparently problem was only reproducible in Python 3, because in Python 3, in "while finished < use_mp" loop, accumulate_result() is called early before checking if result[0] is INTERRUPTED or CHILD_ERROR, while in Python 2, accumulate_result() is called after check for result[0].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25373>
_______________________________________

From report at bugs.python.org  Sun Oct 11 11:10:48 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 11 Oct 2015 09:10:48 +0000
Subject: [issue22228] Adapt bash readline operate-and-get-next function
In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za>
Message-ID: <1444554648.52.0.0859319694701.issue22228@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I left a comment on Rietveld. If I remember correctly, Modules/readline.c is basically a wrapper around libreadline and libedit. I'm not sure if we can add custom behaviors likes this. Perhaps we can expose some of the libreadline functions in Modules/readline.c and let users implement(I don't know if it's possible) it in their pythonrc?

----------
components: +Extension Modules
nosy: +berker.peksag, twouters
stage:  -> patch review
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22228>
_______________________________________

From report at bugs.python.org  Sun Oct 11 11:28:36 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 11 Oct 2015 09:28:36 +0000
Subject: [issue25373] test.regrtest: -jN (with N != 1) + --slow + child error
 or interruption = TypeError
In-Reply-To: <1444538091.0.0.0447780927267.issue25373@psf.upfronthosting.co.za>
Message-ID: <1444555716.67.0.871856727737.issue25373@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

By the way, should "10 slowest tests:\n" (not followed by anything) be printed if all tests failed with CHILD_ERROR or INTERRUPTED?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25373>
_______________________________________

From report at bugs.python.org  Sun Oct 11 12:11:50 2015
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 11 Oct 2015 10:11:50 +0000
Subject: [issue24931] _asdict breaks when inheriting from a namedtuple
In-Reply-To: <1440460188.11.0.136200791288.issue24931@psf.upfronthosting.co.za>
Message-ID: <1444558310.76.0.566349645395.issue24931@psf.upfronthosting.co.za>


Matthias Klose added the comment:

reopening. the incompatible behavior is report in a Debian report as well.

"""
collections.namedtuple appears to not to create namedtuples which have the
__dict__ attribute any more. Given that the stdlib docs stated that using
vars() (and hence the existence of __dict__) was preferred, it seems odd that
it has disappeared.
""" 

https://bugs.debian.org/800370

----------
nosy: +doko, larry
priority: high -> release blocker
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24931>
_______________________________________

From report at bugs.python.org  Sun Oct 11 12:38:10 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 11 Oct 2015 10:38:10 +0000
Subject: [issue25122] test_eintr randomly fails on FreeBSD
In-Reply-To: <1442311779.01.0.43728096223.issue25122@psf.upfronthosting.co.za>
Message-ID: <1444559890.38.0.897875575813.issue25122@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

> New changeset e48ec5f5b82b by Victor Stinner in branch 'default':
> Issue #25122: Remove verbose mode of test_eintr
> https://hg.python.org/cpython/rev/e48ec5f5b82b

This could be backported to 3.5 branch. (Verbose mode was added there just 10 days earlier.)

----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25122>
_______________________________________

From report at bugs.python.org  Sun Oct 11 14:00:08 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 11 Oct 2015 12:00:08 +0000
Subject: [issue25194] Opt-in motivations & affiliations page for core
 contributors
In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za>
Message-ID: <1444564808.31.0.297101710338.issue25194@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

For the version I'm committing:

- I've accepted Ezio's first 3 suggestions, and modified the text accordingly
- for the 4th point, I've changed the guideline there to be about marking the entries "Available for <activity>" rather than using the generic "Commercial contact", and given more details on why I think a link to a separate info page is a better idea than including contact details directly.

I'm not entirely sold on that being the best structure, so I hope folks that actually want to use it to link out to their consulting will suggest alternatives on python-committers if they'd like to do it differently.

For the last two points, I don't want using the wiki to be a requirement (editing the dev guide directly is a much nicer user experience), but I did suggest "Extended bio" as another optional link type. I also expect the layout to be something we revisit as additional entries are added - while OpenHub shows 52 active core contributors in the past 12 months, we don't know how many are going to choose to add entries here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25194>
_______________________________________

From report at bugs.python.org  Sun Oct 11 14:15:35 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Oct 2015 12:15:35 +0000
Subject: [issue25194] Opt-in motivations & affiliations page for core
 contributors
In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za>
Message-ID: <20151011121531.7252.13137@psf.io>


Roundup Robot added the comment:

New changeset 0f0ff7d19cfc by Nick Coghlan in branch 'default':
Issue #25194: Add motivations & affiliations page
https://hg.python.org/devguide/rev/0f0ff7d19cfc

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25194>
_______________________________________

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: [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 14:40:36 2015
From: report at bugs.python.org (Miikka Salminen)
Date: Sun, 11 Oct 2015 12:40:36 +0000
Subject: [issue25376] KeyboardInterrupt handling and traceback broken on
 Windows 10
In-Reply-To: <1444566744.92.0.693006452936.issue25376@psf.upfronthosting.co.za>
Message-ID: <1444567236.08.0.958032385807.issue25376@psf.upfronthosting.co.za>


Miikka Salminen added the comment:

Just tried the same in an IDLE session, but it seems to display the KeyboardInterrupt correctly:

Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:27:37) [MSC v.1900 64 bit (AMD64)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> input("Question: ")
Question: 
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    input("Question: ")
  File "C:\y\Python\Python35\lib\idlelib\PyShell.py", line 1385, in readline
    line = self._line_buffer or self.shell.readline()
KeyboardInterrupt
>>> 

Running the file input_test.py I meantioned in my original report doesn't seem to diplay anything when Ctrl+C is pressed:

============= RESTART: C:\x\input_test.py =============
Question: 
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25376>
_______________________________________

From report at bugs.python.org  Sun Oct 11 14:41:14 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 11 Oct 2015 12:41:14 +0000
Subject: [issue24931] _asdict breaks when inheriting from a namedtuple
In-Reply-To: <1440460188.11.0.136200791288.issue24931@psf.upfronthosting.co.za>
Message-ID: <1444567274.52.0.729504108897.issue24931@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Why is this marked as a release blocker?  It doesn't strike me as all that major.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24931>
_______________________________________

From report at bugs.python.org  Sun Oct 11 14:42:11 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 11 Oct 2015 12:42:11 +0000
Subject: [issue25188] regrtest.py improvement for Profile Guided Optimization
 builds
In-Reply-To: <1442726782.64.0.586742420801.issue25188@psf.upfronthosting.co.za>
Message-ID: <1444567331.49.0.621529280618.issue25188@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

> New changeset 136ad559fa4f by Brett Cannon in branch '2.7':
> Issue #25188: Add -P/--pgo to test.regrtest for PGO building.
> https://hg.python.org/cpython/rev/136ad559fa4f
> 
> +                    # required to permit running tests with PGO flag on/off
> +                    if pgo:
> +                        args_tuple[1]['pgo']=pgo

This looks ugly.
The following change should work and would be consistent with handling of huntrleaks and use_resources:

--- Lib/test/regrtest.py
+++ Lib/test/regrtest.py
@@ -508,7 +508,8 @@
             for test in tests:
                 args_tuple = (
                     (test, verbose, quiet),
-                    dict(huntrleaks=huntrleaks, use_resources=use_resources)
+                    dict(huntrleaks=huntrleaks, use_resources=use_resources,
+                         pgo=pgo)
                 )
                 yield (test, args_tuple)
         pending = tests_and_args()
@@ -526,9 +527,6 @@
                     except StopIteration:
                         output.put((None, None, None, None))
                         return
-                    # required to permit running tests with PGO flag on/off
-                    if pgo:
-                        args_tuple[1]['pgo']=pgo
                     # -E is needed by some tests, e.g. test_import
                     popen = Popen(base_cmd + ['--slaveargs', json.dumps(args_tuple)],
                                    stdout=PIPE, stderr=PIPE,

----------
nosy: +Arfrever
resolution: fixed -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25188>
_______________________________________

From report at bugs.python.org  Sun Oct 11 14:45:29 2015
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 11 Oct 2015 12:45:29 +0000
Subject: [issue24931] _asdict breaks when inheriting from a namedtuple
In-Reply-To: <1440460188.11.0.136200791288.issue24931@psf.upfronthosting.co.za>
Message-ID: <1444567529.81.0.505829567639.issue24931@psf.upfronthosting.co.za>


Matthias Klose added the comment:

now marked as regression, and lowered the priority.

but how should regressions on release branches be marked else?

----------
keywords: +3.4regression, 3.5regression -patch
priority: release blocker -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24931>
_______________________________________

From report at bugs.python.org  Sun Oct 11 16:14:49 2015
From: report at bugs.python.org (Miikka Salminen)
Date: Sun, 11 Oct 2015 14:14:49 +0000
Subject: [issue25376] KeyboardInterrupt handling and traceback broken on
 Windows 10
In-Reply-To: <1444566744.92.0.693006452936.issue25376@psf.upfronthosting.co.za>
Message-ID: <1444572889.07.0.045030112201.issue25376@psf.upfronthosting.co.za>


Miikka Salminen added the comment:

Did some more testing. KeyboardInterrupt traceback displays properly when pressing Ctrl+C during an infinite loop:

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.
>>> while True:
...     pass
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
KeyboardInterrupt
>>>

Also when running a file in a similar way as I did in the original bug report:

C:\x>python infinite_loop.py
Traceback (most recent call last):
  File "infinite_loop.py", line 2, in <module>
    pass
KeyboardInterrupt

C:\x>

Could this mean that the problem is more related to reading stdin than the actual KeyboardInterrupt?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25376>
_______________________________________

From report at bugs.python.org  Sun Oct 11 16:20:47 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 11 Oct 2015 14:20:47 +0000
Subject: [issue25361] Is python-3-5-0.exe compiled with SSE2 instrutions? If
 so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1444573247.39.0.803847698017.issue25361@psf.upfronthosting.co.za>


Steve Dower added the comment:

Since we officially support platforms that don't require SSE, I'll disable those instructions for 3.5.1.

As eryksun points out, this doesn't affect 64-bit builds, which are the standard for most performance critical uses anyway.

----------
assignee: docs at python -> steve.dower
components: +Build, Distutils -Documentation, Installation
keywords: +3.5regression
nosy: +dstufft, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25361>
_______________________________________

From report at bugs.python.org  Sun Oct 11 16:39:39 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 11 Oct 2015 14:39:39 +0000
Subject: [issue25374] Deficiencies in type hint usage in Python standard
 libraries
In-Reply-To: <1444538776.34.0.720036996405.issue25374@psf.upfronthosting.co.za>
Message-ID: <1444574379.55.0.93033162922.issue25374@psf.upfronthosting.co.za>


R. David Murray added the comment:

You need to install the (currently externally maintained) type hints files from https://github.com/python/typeshed.  I don't think a decision has been made about if/when these files will be incorporated into the distribution.

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25374>
_______________________________________

From report at bugs.python.org  Sun Oct 11 16:55:15 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Oct 2015 14:55:15 +0000
Subject: [issue20289] Make cgi.FieldStorage a context manager
In-Reply-To: <1389970045.35.0.547540590752.issue20289@psf.upfronthosting.co.za>
Message-ID: <20151011145512.7256.18350@psf.io>


Roundup Robot added the comment:

New changeset 80501740ab84 by Serhiy Storchaka in branch '3.5':
No longer skip tests for classes with __getnewargs_ex__.  The copy module
https://hg.python.org/cpython/rev/80501740ab84

New changeset 6f4dd9bc1f20 by Serhiy Storchaka in branch 'default':
No longer skip tests for classes with __getnewargs_ex__.  The copy module
https://hg.python.org/cpython/rev/6f4dd9bc1f20

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20289>
_______________________________________

From report at bugs.python.org  Sun Oct 11 16:55:16 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Oct 2015 14:55:16 +0000
Subject: [issue24164] Support pickling objects with __new__ with keyword
 arguments with protocol 2+
In-Reply-To: <1431341390.51.0.0928642680419.issue24164@psf.upfronthosting.co.za>
Message-ID: <20151011145512.7256.34552@psf.io>


Roundup Robot added the comment:

New changeset df33dbbef7bb by Serhiy Storchaka in branch 'default':
Issue #24164: Fixed test_descr: __getnewargs_ex__ now is supported in protocols 2 and 3.
https://hg.python.org/cpython/rev/df33dbbef7bb

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24164>
_______________________________________

From report at bugs.python.org  Sun Oct 11 16:58:10 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 11 Oct 2015 14:58:10 +0000
Subject: [issue25372] load_module() does not link submodule to parent package
In-Reply-To: <1444531632.83.0.513711320874.issue25372@psf.upfronthosting.co.za>
Message-ID: <1444575490.97.0.0360445156372.issue25372@psf.upfronthosting.co.za>


Brett Cannon added the comment:

This is entirely on purpose as you're not meant to call load_module() if you want to import code programmatically; that's what importlib.import_module() is for. The load_module() method -- which is kind of deprecated thanks to exec_module() -- is there purely to initialize the module being imported, with everything else the responsibility of other parts of import. You should only be calling load_module/execx_module tonload a specific set of bytes and to bypass the import machinery entirely, in which case you have to manage any "extras" you want, like setting a submodule on a parent package.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25372>
_______________________________________

From report at bugs.python.org  Sun Oct 11 17:01:36 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Oct 2015 15:01:36 +0000
Subject: [issue24164] Support pickling objects with __new__ with keyword
 arguments with protocol 2+
In-Reply-To: <1431341390.51.0.0928642680419.issue24164@psf.upfronthosting.co.za>
Message-ID: <1444575696.73.0.0724800129297.issue24164@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Victor. Tests are fixed.

I think the documentation needs to be updated. Here is a patch for pickle documentation.

----------
stage: resolved -> patch review
Added file: http://bugs.python.org/file40751/pickle_new_ex_protocol_2_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24164>
_______________________________________

From report at bugs.python.org  Sun Oct 11 17:09:00 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 11 Oct 2015 15:09:00 +0000
Subject: [issue25372] load_module() does not link submodule to parent package
In-Reply-To: <1444531632.83.0.513711320874.issue25372@psf.upfronthosting.co.za>
Message-ID: <1444576140.35.0.598385562564.issue25372@psf.upfronthosting.co.za>


R. David Murray added the comment:

Brett: Martin is calling pkgutil.find_loader, which is not marked as deprecated, and then calling load_module on the returned loader, which apparently does *almost* what he wants but not quite.

Martin: maybe you should explain your use case in more detail.  Probably there is a better way to accomplish it using importlib directly.  Unless one of your issues is needing to write 2/3 compatible code...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25372>
_______________________________________

From report at bugs.python.org  Sun Oct 11 17:17:21 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 11 Oct 2015 15:17:21 +0000
Subject: [issue12813] uuid4 is not tested if a uuid4 system routine isn't
 present
In-Reply-To: <1313995301.93.0.316946106703.issue12813@psf.upfronthosting.co.za>
Message-ID: <1444576641.64.0.529152134247.issue12813@psf.upfronthosting.co.za>


R. David Murray added the comment:

I doesn't look that way to me.  test_uuid4 is still skipped if there is no cytpes in 3.6, and I don't see the new test methods from the patch.  I'd say this was still valid.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12813>
_______________________________________

From report at bugs.python.org  Sun Oct 11 17:19:30 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 11 Oct 2015 15:19:30 +0000
Subject: [issue25372] load_module() does not link submodule to parent package
In-Reply-To: <1444531632.83.0.513711320874.issue25372@psf.upfronthosting.co.za>
Message-ID: <1444576770.09.0.510597675344.issue25372@psf.upfronthosting.co.za>


Brett Cannon added the comment:

1) I would use https://docs.python.org/3/library/importlib.html#importlib.find_loader instead of pkgutil

2) there are a bunch of ways to get a hold of a loader and its hard to document how to use a loader properly since it's low level like __path__ while being crucial for stuff like reloading and loaders predate __spec__

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25372>
_______________________________________

From report at bugs.python.org  Sun Oct 11 17:27:04 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 11 Oct 2015 15:27:04 +0000
Subject: [issue20216] Misleading docs for sha1, sha256, sha512, md5 modules
In-Reply-To: <1389320490.58.0.128009418019.issue20216@psf.upfronthosting.co.za>
Message-ID: <1444577224.05.0.194058698343.issue20216@psf.upfronthosting.co.za>


R. David Murray added the comment:

'bytes of binary data' should be 'bytes object', which is what is used in the ReST documentation.  Otherwise the patch looks good to me.

----------
nosy: +r.david.murray
versions: +Python 3.5, Python 3.6 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20216>
_______________________________________

From report at bugs.python.org  Sun Oct 11 17:36:06 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 11 Oct 2015 15:36:06 +0000
Subject: [issue25376] KeyboardInterrupt handling and traceback broken on
 Windows 10
In-Reply-To: <1444566744.92.0.693006452936.issue25376@psf.upfronthosting.co.za>
Message-ID: <1444577766.73.0.242245842962.issue25376@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, this is probably a duplicate of issue 18597.

----------
nosy: +r.david.murray

_______________________________________
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: [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  Sun Oct 11 17:46:55 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 11 Oct 2015 15:46:55 +0000
Subject: [issue25377] Mention octal format of mode argument of os.chmod
In-Reply-To: <1444577786.91.0.966567920628.issue25377@psf.upfronthosting.co.za>
Message-ID: <1444578415.69.0.983788091857.issue25377@psf.upfronthosting.co.za>


R. David Murray added the comment:

The main docs do not mention octal, but instead point to the constants in the stat module.  The help text currently says "Operating-system mode bitfield", which is in fact accurate.  A decimal number is *not* a bitfield (although it can be interpreted as one, giving the unexpected results).  

However, the help doc could be enhanced to say "Operating-system mode bitfield, see stat module for symbolic constants.".

Basically, the fact that octal works is an historical accident due to it working that way on unix, but ideally should not be relied upon by python code (though of course it will be :).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25377>
_______________________________________

From report at bugs.python.org  Sun Oct 11 18:34:26 2015
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 11 Oct 2015 16:34:26 +0000
Subject: [issue25377] Mention octal format of mode argument of os.chmod
In-Reply-To: <1444577786.91.0.966567920628.issue25377@psf.upfronthosting.co.za>
Message-ID: <1444581266.12.0.464865917425.issue25377@psf.upfronthosting.co.za>


Georg Brandl added the comment:

A short sentence like 

Be careful when using number literals for *mode*. The conventional UNIX notation for numeric modes uses an octal base, which needs to be indicated with a ``0o`` prefix in Python.

should be a good addition here.  (I wonder why it isn't there, I seem to recall an earlier issue about this.)

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25377>
_______________________________________

From report at bugs.python.org  Sun Oct 11 18:48:18 2015
From: report at bugs.python.org (Adam)
Date: Sun, 11 Oct 2015 16:48:18 +0000
Subject: [issue25344] Enhancement to Logging - Logging Stack
In-Reply-To: <1444323958.12.0.353720924326.issue25344@psf.upfronthosting.co.za>
Message-ID: <1444582098.1.0.0971024205399.issue25344@psf.upfronthosting.co.za>


Changes by Adam <azsorkin at gmail.com>:


----------
nosy:  -azsorkin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25344>
_______________________________________

From report at bugs.python.org  Sun Oct 11 19:03:46 2015
From: report at bugs.python.org (Davin Potts)
Date: Sun, 11 Oct 2015 17:03:46 +0000
Subject: [issue25340] libraries variable in setup.py ignore for
 multiprocessing module
In-Reply-To: <1444289556.93.0.862916307871.issue25340@psf.upfronthosting.co.za>
Message-ID: <1444583026.85.0.388273299494.issue25340@psf.upfronthosting.co.za>


Davin Potts added the comment:

Can you provide more relevant information to help others reproduce this?  What operating system, did you install Python yourself or did it come with the operating system, what Python package you are trying to install (the package supplying the setup.py you're trying to run)?

Without more information, there's nothing for us to go on.

----------
nosy: +davin
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25340>
_______________________________________

From report at bugs.python.org  Sun Oct 11 19:20:05 2015
From: report at bugs.python.org (Davin Potts)
Date: Sun, 11 Oct 2015 17:20:05 +0000
Subject: [issue12939] Add new io.FileIO using the native Windows API
In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za>
Message-ID: <1444584005.88.0.307082797051.issue12939@psf.upfronthosting.co.za>


Changes by Davin Potts <python at discontinuity.net>:


----------
nosy: +davin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12939>
_______________________________________

From report at bugs.python.org  Sun Oct 11 19:21:58 2015
From: report at bugs.python.org (Davin Potts)
Date: Sun, 11 Oct 2015 17:21:58 +0000
Subject: [issue22393] multiprocessing.Pool shouldn't hang forever if a worker
 process dies unexpectedly
In-Reply-To: <1410474786.78.0.264797717105.issue22393@psf.upfronthosting.co.za>
Message-ID: <1444584118.49.0.634455185986.issue22393@psf.upfronthosting.co.za>


Changes by Davin Potts <python at discontinuity.net>:


----------
nosy: +davin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22393>
_______________________________________

From report at bugs.python.org  Sun Oct 11 19:40:06 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 11 Oct 2015 17:40:06 +0000
Subject: [issue25194] Opt-in motivations & affiliations page for core
 contributors
In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za>
Message-ID: <1444585206.83.0.90366754473.issue25194@psf.upfronthosting.co.za>


R. David Murray added the comment:

Since this is new, rather than just updating the devguide I'm posting my proposed entry here first in case there is feedback.

One think I noticed in writing this is that the page is called "motivations", but because the instructions are to write the entry in the third person, it does not seem natural to actually talk about *why* I am motivated to contribute.  This may or may not be a bug :)

----------
Added file: http://bugs.python.org/file40752/rdm_motivations.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25194>
_______________________________________

From report at bugs.python.org  Sun Oct 11 20:39:02 2015
From: report at bugs.python.org (Laura Creighton)
Date: Sun, 11 Oct 2015 18:39:02 +0000
Subject: [issue25361] Is python-3-5-0.exe compiled with SSE2 instrutions? If
 so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1444588742.31.0.80924778937.issue25361@psf.upfronthosting.co.za>


Laura Creighton added the comment:

Another 2 bits of data:

I now know of 2 separate users from a Swedish teenager mailing list, whose machines (in each case 'my father's old laptop') didn't have SSE2.  One youth was running XP but spent today successfully migrating to windows 7 with help from her father.  The other was already running windows 7.

Neither of them had ever used Python before.  They are now running 
3.4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25361>
_______________________________________

From report at bugs.python.org  Sun Oct 11 22:09:20 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 11 Oct 2015 20:09:20 +0000
Subject: [issue25373] test.regrtest: -jN (with N != 1) + --slow + child error
 or interruption = TypeError
In-Reply-To: <1444555716.67.0.871856727737.issue25373@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwajyVf5oKAuciHm7Yu2fB46k61Ayz8OhB+XYbg8OgEPzQ@mail.gmail.com>


STINNER Victor added the comment:

No idea. I don't think that --slow is heavily used in the wild. The current
behaiour looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25373>
_______________________________________

From report at bugs.python.org  Sun Oct 11 22:10:41 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 11 Oct 2015 20:10:41 +0000
Subject: [issue25122] test_eintr randomly fails on FreeBSD
In-Reply-To: <1444559890.38.0.897875575813.issue25122@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaeLhqvgY6N1bG+hP83tziLzhKKQ8+o9+MZOjLmhXyq5A@mail.gmail.com>


STINNER Victor added the comment:

We should remove it, but test_eintr still hangs randomly on freebsd.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25122>
_______________________________________

From report at bugs.python.org  Mon Oct 12 00:04:54 2015
From: report at bugs.python.org (Robert Collins)
Date: Sun, 11 Oct 2015 22:04:54 +0000
Subject: [issue25320] unittest loader.py TypeError when code directory
 contains a socket
In-Reply-To: <1444063424.79.0.244583020203.issue25320@psf.upfronthosting.co.za>
Message-ID: <1444601094.68.0.220988414795.issue25320@psf.upfronthosting.co.za>


Robert Collins added the comment:

The fix is appropriate (we might want to think about symlinks in the future). I'd very much like a test for it (in Lib/unittest/test/test_discovery.py) and it should be applied to 3.5, master - older versions had this wrapped up in simpler code and won't fail like this.

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25320>
_______________________________________

From report at bugs.python.org  Mon Oct 12 00:16:38 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Oct 2015 22:16:38 +0000
Subject: [issue25361] Is python-3-5-0.exe compiled with SSE2 instrutions? If
 so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <20151011221635.128836.40158@psf.io>


Roundup Robot added the comment:

New changeset 15f6bbe944fa by Steve Dower in branch '3.5':
Issue #25361: Disables use of SSE2 instructions in Windows 32-bit build
https://hg.python.org/cpython/rev/15f6bbe944fa

New changeset 3cf8c2930373 by Steve Dower in branch 'default':
Issue #25361: Disables use of SSE2 instructions in Windows 32-bit build
https://hg.python.org/cpython/rev/3cf8c2930373

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25361>
_______________________________________

From report at bugs.python.org  Mon Oct 12 00:17:40 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 11 Oct 2015 22:17:40 +0000
Subject: [issue25361] Is python-3-5-0.exe compiled with SSE2 instrutions? If
 so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1444601860.6.0.448899824312.issue25361@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25361>
_______________________________________

From report at bugs.python.org  Mon Oct 12 00:38:03 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Oct 2015 22:38:03 +0000
Subject: [issue25163] Windows installer in AllUsers mode presents wrong
 installation path
In-Reply-To: <1442564000.23.0.122739262623.issue25163@psf.upfronthosting.co.za>
Message-ID: <20151011223800.20755.18622@psf.io>


Roundup Robot added the comment:

New changeset 919b1dffa741 by Steve Dower in branch '3.5':
Issue #25163: Display correct directory in installer when using non-default settings.
https://hg.python.org/cpython/rev/919b1dffa741

New changeset 6f97c51b6dc5 by Steve Dower in branch 'default':
Issue #25163: Display correct directory in installer when using non-default settings.
https://hg.python.org/cpython/rev/6f97c51b6dc5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25163>
_______________________________________

From report at bugs.python.org  Mon Oct 12 00:38:15 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 11 Oct 2015 22:38:15 +0000
Subject: [issue25163] Windows installer in AllUsers mode presents wrong
 installation path
In-Reply-To: <1442564000.23.0.122739262623.issue25163@psf.upfronthosting.co.za>
Message-ID: <1444603095.13.0.877860706158.issue25163@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25163>
_______________________________________

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: [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 00:41:15 2015
From: report at bugs.python.org (paul j3)
Date: Sun, 11 Oct 2015 22:41:15 +0000
Subject: [issue18769] argparse remove subparser
In-Reply-To: <1376757040.66.0.700111900917.issue18769@psf.upfronthosting.co.za>
Message-ID: <1444603275.71.0.39282231248.issue18769@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18769>
_______________________________________

From report at bugs.python.org  Mon Oct 12 00:41:22 2015
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Jan_Warecki?=)
Date: Sun, 11 Oct 2015 22:41:22 +0000
Subject: [issue25378] Roundoff error on OS X
In-Reply-To: <1444603260.51.0.439677989725.issue25378@psf.upfronthosting.co.za>
Message-ID: <1444603282.36.0.487908180716.issue25378@psf.upfronthosting.co.za>


Changes by Micha? Jan Warecki <mwarecki1 at gmail.com>:


----------
components: +Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25378>
_______________________________________

From report at bugs.python.org  Mon Oct 12 00:42:30 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 11 Oct 2015 22:42:30 +0000
Subject: [issue25378] Roundoff error on OS X
In-Reply-To: <1444603260.51.0.439677989725.issue25378@psf.upfronthosting.co.za>
Message-ID: <1444603350.02.0.313087262683.issue25378@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

See https://docs.python.org/3/tutorial/floatingpoint.html

----------
nosy: +ezio.melotti
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25378>
_______________________________________

From report at bugs.python.org  Mon Oct 12 01:41:09 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Oct 2015 23:41:09 +0000
Subject: [issue25143] 3.5 install fails poorly on Windows XP
In-Reply-To: <1442420286.68.0.457975935538.issue25143@psf.upfronthosting.co.za>
Message-ID: <20151011234107.18378.69187@psf.io>


Roundup Robot added the comment:

New changeset 2316bc881eea by Steve Dower in branch '3.5':
Issue #25143: Improves installer error messages for unsupported platforms.
https://hg.python.org/cpython/rev/2316bc881eea

New changeset 2c384ba13fdd by Steve Dower in branch 'default':
Issue #25143: Improves installer error messages for unsupported platforms.
https://hg.python.org/cpython/rev/2c384ba13fdd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25143>
_______________________________________

From report at bugs.python.org  Mon Oct 12 01:43:12 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 11 Oct 2015 23:43:12 +0000
Subject: [issue25143] 3.5 install fails poorly on Windows XP
In-Reply-To: <1442420286.68.0.457975935538.issue25143@psf.upfronthosting.co.za>
Message-ID: <1444606992.87.0.604455795582.issue25143@psf.upfronthosting.co.za>


Steve Dower added the comment:

Still need to validate the fix on WinXP, as I'm not 100% certain that enough UI will appear to show the user the error, but we will now bail right at the start and link to either help pages for installing updates (for Vista/7) or Python 3.4 (for pre-Vista).

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25143>
_______________________________________

From report at bugs.python.org  Mon Oct 12 01:52:41 2015
From: report at bugs.python.org (paul j3)
Date: Sun, 11 Oct 2015 23:52:41 +0000
Subject: [issue18769] argparse remove subparser
In-Reply-To: <1376757040.66.0.700111900917.issue18769@psf.upfronthosting.co.za>
Message-ID: <1444607561.68.0.492454117595.issue18769@psf.upfronthosting.co.za>


paul j3 added the comment:

Under what circumstances would this be useful?

http://bugs.python.org/issue19462 asks for a 'remove_argument' method.  That seems to be most useful if the argument is inherited from a parent parser.

A subparsers argument could be inherited from a parent (I think), but the parenting mechanism does not provide a reference to the corresponding  _SubParsersAction object.  We'd have to look it up in the main parser._actions.

Also parenting does not make copies of the Actions.  It just copies references.  That means any change to the main parser  _SubParsersAction object is also a change to the parent's object.

http://bugs.python.org/issue22401 discusses the problems involved changing an inherited argument.

The method seems simple enough, but I'd like to see a better case for its value.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18769>
_______________________________________

From report at bugs.python.org  Mon Oct 12 03:11:44 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 12 Oct 2015 01:11:44 +0000
Subject: [issue25125] "Edit with IDLE" does not work for shortcuts
In-Reply-To: <1442318370.13.0.116980940121.issue25125@psf.upfronthosting.co.za>
Message-ID: <1444612304.77.0.453981988115.issue25125@psf.upfronthosting.co.za>


Steve Dower added the comment:

Because of the way Open With works, we can't do this unless we start building an EXE to launch IDLE (Windows automatically picks up most of the details from the target executable, so it will show as "pythonw" if we do it without the launcher).

Unassigning myself, as there doesn't seem to be anything to "do" right now. If consensus on moving all the versioned menus to the top level context menu is reached (possibly on the IDLE mailing list), it can be re-raised here. I personally don't consider a limitation of Windows 7 wrt shortcuts to be a compelling enough reason to change away from the submenu.

----------
assignee: steve.dower -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25125>
_______________________________________

From report at bugs.python.org  Mon Oct 12 04:01:21 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 12 Oct 2015 02:01:21 +0000
Subject: [issue25254] Idle: debugger source line highlighting fails again
In-Reply-To: <1443410161.14.0.45288371975.issue25254@psf.upfronthosting.co.za>
Message-ID: <1444615281.59.0.0663308776188.issue25254@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

No.  Turning it on, I discovered why off is default. When it on, it sometimes does surprising things on IDLE.  For instance, print('x') is (usually) a builtin and can not be stepped into.  However, it calls sys.stdout.write('x'+'\n').  Under Idle, user process sys.stdout is PyShell.Pseudofile, so when source is checked, 'step' on a line with print opens the file and highlights lines in the write method.

Step should ask before opening a file, and/or a 'smart step' is needed.

----------
resolution:  -> not a bug
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25254>
_______________________________________

From report at bugs.python.org  Mon Oct 12 04:05:05 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 12 Oct 2015 02:05:05 +0000
Subject: [issue24782] Merge 'configure extensions' into main IDLE config dialog
In-Reply-To: <1438549617.46.0.760286591646.issue24782@psf.upfronthosting.co.za>
Message-ID: <1444615505.8.0.532630226672.issue24782@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Do you have a patch to move the untabbed pane, as is, to preferences?  If not, I will write one.

----------
versions: +Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24782>
_______________________________________

From report at bugs.python.org  Mon Oct 12 04:08:22 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Oct 2015 02:08:22 +0000
Subject: [issue22726] Idle: add help to config dialogs
In-Reply-To: <1414212383.94.0.847086482603.issue22726@psf.upfronthosting.co.za>
Message-ID: <20151012020818.7264.3932@psf.io>


Roundup Robot added the comment:

New changeset fd41b05b8227 by Terry Jan Reedy in branch '2.7':
Issue #22726: Re-activate config dialog help button with some content about
https://hg.python.org/cpython/rev/fd41b05b8227

New changeset 01f83efcc44b by Terry Jan Reedy in branch '3.4':
Issue #22726: Re-activate config dialog help button with some content about
https://hg.python.org/cpython/rev/01f83efcc44b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22726>
_______________________________________

From report at bugs.python.org  Mon Oct 12 04:13:10 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 12 Oct 2015 02:13:10 +0000
Subject: [issue22726] Idle: add help to config dialogs
In-Reply-To: <1414212383.94.0.847086482603.issue22726@psf.upfronthosting.co.za>
Message-ID: <1444615990.15.0.26386545689.issue22726@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I rewrote the common section to explain what the button do. I did not modify the extensions dialog because I want to finish #24782.  #22707 may add more.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22726>
_______________________________________

From report at bugs.python.org  Mon Oct 12 04:31:30 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 12 Oct 2015 02:31:30 +0000
Subject: [issue22179] Idle. Search dialog found text not highlited on Windows
In-Reply-To: <1407672062.65.0.813743837574.issue22179@psf.upfronthosting.co.za>
Message-ID: <1444617090.6.0.132089569723.issue22179@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I am closing this because #24972 fixes the immediate issue.

----------
dependencies:  -Found text not always highlighted by Replace dialog on Windows
resolution:  -> out of date
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22179>
_______________________________________

From report at bugs.python.org  Mon Oct 12 04:36:45 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 12 Oct 2015 02:36:45 +0000
Subject: [issue18590] Found text not always highlighted by Replace dialog on
 Windows
In-Reply-To: <1375128565.7.0.113615028691.issue18590@psf.upfronthosting.co.za>
Message-ID: <1444617405.14.0.818706337562.issue18590@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

#24972 fixes the immediate issue but the Find and Replace code are needlessly different in doing the same thing and redundant in double tagging found text, and there are some other glitches.  I think a better fix will be to only use the found tag, but this needs discussion, perhaps on idle-dev. #22179 also has some discussion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18590>
_______________________________________

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: [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 07:18:51 2015
From: report at bugs.python.org (Bert JW Regeer)
Date: Mon, 12 Oct 2015 05:18:51 +0000
Subject: [issue25379] Changes in traceback broke existing code (Python 3.5)
In-Reply-To: <1444624940.12.0.845916385151.issue25379@psf.upfronthosting.co.za>
Message-ID: <1444627131.82.0.323022626032.issue25379@psf.upfronthosting.co.za>


Bert JW Regeer added the comment:

Looks like this is a dup of: https://bugs.python.org/issue25108

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25379>
_______________________________________

From report at bugs.python.org  Mon Oct 12 07:37:13 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 12 Oct 2015 05:37:13 +0000
Subject: [issue25379] Changes in traceback broke existing code (Python 3.5)
In-Reply-To: <1444624940.12.0.845916385151.issue25379@psf.upfronthosting.co.za>
Message-ID: <1444628233.86.0.333613455175.issue25379@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report! Yes, this is a duplicate of issue 25108. It would be great if you have time to test it with the current 3.5 branch.

----------
components: +Library (Lib)
nosy: +berker.peksag
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> traceback.extract_stack() compatibility break in 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25379>
_______________________________________

From report at bugs.python.org  Mon Oct 12 07:50:14 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 12 Oct 2015 05:50:14 +0000
Subject: [issue25194] Opt-in motivations & affiliations page for core
 contributors
In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za>
Message-ID: <1444629014.34.0.0608176042682.issue25194@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

That's a good point about the current "3rd party bio" instructions being counterproductive - my goal is to capture "Why do we consider core development a good use of our time?" moreso than "What have we done in the past?".

So perhaps switching back to the first person model I used in the second draft would be a better idea?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25194>
_______________________________________

From report at bugs.python.org  Mon Oct 12 07:55:29 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 12 Oct 2015 05:55:29 +0000
Subject: [issue25194] Opt-in motivations & affiliations page for core
 contributors
In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za>
Message-ID: <1444629329.41.0.627952974125.issue25194@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Additional feedback received off-list in response to the python-committers thread:

* the current preamble is still overly legalistic and could stand to be toned down (e.g. finding a friendlier word than "disclose" in a couple of places)

* the page doesn't really explain why it exists. There's hints of that in the "Limitations on Scope" section, but it would likely be better to have a more explicit "Goals of this page" section.

I'll draft an updated version of that and post it here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25194>
_______________________________________

From report at bugs.python.org  Mon Oct 12 08:33:34 2015
From: report at bugs.python.org (nikitakit)
Date: Mon, 12 Oct 2015 06:33:34 +0000
Subject: [issue12920] inspect.getsource only works for objects loaded from
 files, not interactive session
In-Reply-To: <1315334278.72.0.69534403863.issue12920@psf.upfronthosting.co.za>
Message-ID: <1444631614.11.0.946176474156.issue12920@psf.upfronthosting.co.za>


nikitakit added the comment:

I just ran into this issue trying to introspect an IPython session, in which case the __main__ module doesn't have a file associated with it.

But it turns out that methods defined in a class do have source code associated with them, so it's possible to add a workaround for the common case where a class actually has methods.

Code: https://gist.github.com/nikitakit/642cb96febdf2f812d0b

----------
nosy: +nikitakit

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12920>
_______________________________________

From report at bugs.python.org  Mon Oct 12 09:50:14 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Oct 2015 07:50:14 +0000
Subject: [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: [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 10:18:55 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Oct 2015 08:18:55 +0000
Subject: [issue25381] Doc: Use old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1444637935.62.0.277789764985.issue25381@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: Use old description of raise in Python3 -> Doc: Use old description of raise in Python3

_______________________________________
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: [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 11:57:40 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Oct 2015 09:57:40 +0000
Subject: [issue25380] Incorrect protocol for the STACK_GLOBAL opcode
In-Reply-To: <1444636213.99.0.44021196254.issue25380@psf.upfronthosting.co.za>
Message-ID: <1444643860.82.0.537162607846.issue25380@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +alexandre.vassalotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25380>
_______________________________________

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: [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 12:42:22 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 12 Oct 2015 10:42:22 +0000
Subject: [issue25383] Docs: Broken link
In-Reply-To: <1444644244.01.0.0650490218044.issue25383@psf.upfronthosting.co.za>
Message-ID: <1444646542.86.0.862897208747.issue25383@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report, but I think this should be reported to PyPA since even https://packaging.python.org doesn't work. Can you open an issue at https://github.com/pypa/python-packaging-user-guide/issues

----------
nosy: +berker.peksag
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25383>
_______________________________________

From report at bugs.python.org  Mon Oct 12 13:29:57 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 12 Oct 2015 11:29:57 +0000
Subject: [issue25170] 3.5.0 documentation archives missing
In-Reply-To: <1442601694.39.0.291720811899.issue25170@psf.upfronthosting.co.za>
Message-ID: <1444649397.73.0.545543535633.issue25170@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
priority: normal -> high
resolution: not a bug -> 
stage: resolved -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25170>
_______________________________________

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: [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 13:40:59 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Oct 2015 11:40:59 +0000
Subject: [issue25384] Use _PyBytesWriter in the binascii module
In-Reply-To: <1444650015.66.0.169778133218.issue25384@psf.upfronthosting.co.za>
Message-ID: <1444650059.18.0.101100043022.issue25384@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I implemented the "use empty string singleton" optimization in _PyBytesWriter_Finish(): see changeset f33433d9c163.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25384>
_______________________________________

From report at bugs.python.org  Mon Oct 12 14:00:31 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Oct 2015 12:00:31 +0000
Subject: [issue24164] Support pickling objects with __new__ with keyword
 arguments with protocol 2+
In-Reply-To: <1431341390.51.0.0928642680419.issue24164@psf.upfronthosting.co.za>
Message-ID: <1444651231.41.0.673077421284.issue24164@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"Thank you Victor. Tests are fixed."

Not all of them. Failure on FreeBSD:

(I don't know what is test_pyclbr!?)

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x/builds/3866/


======================================================================
FAIL: test_others (test.test_pyclbr.PyclbrTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_pyclbr.py", line 159, in test_others
    cm('pickle')
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_pyclbr.py", line 86, in checkModule
    self.assertIsInstance(py_item, (FunctionType, BuiltinFunctionType))
AssertionError: <class 'functools.partial'> is not an instance of (<class 'function'>, <class 'builtin_function_or_method'>)

----------------------------------------------------------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24164>
_______________________________________

From report at bugs.python.org  Mon Oct 12 14:21:48 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 12 Oct 2015 12:21:48 +0000
Subject: [issue25285] regrtest: run tests in subprocesses with -j1 on buildbots
In-Reply-To: <1443645362.81.0.234212686686.issue25285@psf.upfronthosting.co.za>
Message-ID: <1444652508.28.0.483583516856.issue25285@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25285>
_______________________________________

From report at bugs.python.org  Mon Oct 12 14:38:35 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Oct 2015 12:38:35 +0000
Subject: [issue24164] Support pickling objects with __new__ with keyword
 arguments with protocol 2+
In-Reply-To: <1431341390.51.0.0928642680419.issue24164@psf.upfronthosting.co.za>
Message-ID: <20151012123832.483.15417@psf.io>


Roundup Robot added the comment:

New changeset 288953a787ce by Victor Stinner in branch 'default':
Issue #24164: Fix test_pyclbr
https://hg.python.org/cpython/rev/288953a787ce

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24164>
_______________________________________

From report at bugs.python.org  Mon Oct 12 14:40:08 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Oct 2015 12:40:08 +0000
Subject: [issue24164] Support pickling objects with __new__ with keyword
 arguments with protocol 2+
In-Reply-To: <1431341390.51.0.0928642680419.issue24164@psf.upfronthosting.co.za>
Message-ID: <1444653608.39.0.170873687087.issue24164@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> New changeset 288953a787ce by Victor Stinner in branch 'default':
> Issue #24164: Fix test_pyclbr

Another fix would be to accept functools.partial type, but it looks like the test wants to exclude symbols which comes from other modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24164>
_______________________________________

From report at bugs.python.org  Mon Oct 12 16:32:10 2015
From: report at bugs.python.org (Christian Tanzer)
Date: Mon, 12 Oct 2015 14:32:10 +0000
Subject: [issue22005] datetime.__setstate__ fails decoding python2 pickle
In-Reply-To: <1405687792.76.0.689943587668.issue22005@psf.upfronthosting.co.za>
Message-ID: <1444660330.27.0.342577452812.issue22005@psf.upfronthosting.co.za>


Christian Tanzer added the comment:

> The code works when using encoding='bytes'. Thanks Tim for the suggestion.

> So this is not a bug, but is there any sense in having encoding='ASCII' by default in pickle ?

It is most definitely a bug. And it adds another road block to moving python applications from 2.7 to 3.x!

encoding='bytes' has serious side effects and isn't useful in the general case. For instance, it will result in dict-keys being unpickled as bytes instead of as str after which hilarity ensues.

I got the exception

  UnicodeDecodeError: 'ascii' codec can't decode byte 0xdf in position 1: ordinal not in range(128)

when testing an application for compatibility in Python 3.5 on a pickle created by Python 2.7. The pickled data is a nested data structure and it took me quite a while to determine that the single datetime instance was the culprit.

Here is a small test case that reproduces the problem::

# -*- coding: utf-8 -*-
# pickle_dump.py 
import datetime, pickle, uuid
dti = datetime.datetime(2015, 10, 12, 13, 17, 42, 123456)
data = { "ascii" : "abc", "text" : u"?bc", "int" :  42, "date-time" : dti }
with open("/tmp/pickle.test", "wb") as file :
    pickle.dump(data, file, protocol=2)

# pickle_load.py
# -*- coding: utf-8 -*-
import pickle
with open("/tmp/pickle.test", "rb") as file :
    data = pickle.load(file)
print(data)

$ python2.7 pickle_dump.py
$ python2.7 pickle_load.py 
{'ascii': 'abc', 'text': u'\xe4bc', 'int': 42, 'date-time': datetime.datetime(2015, 10, 12, 13, 17, 42, 123456)}
$ python3.5 pickle_load.py 
Traceback (most recent call last):
  File "pickle_load.py", line 6, in <module>
    data = pickle.load(file)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xdf in position 1: ordinal not in range(128)

That error message is spectacularly useless.

----------
nosy: +tanzer at swing.co.at

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22005>
_______________________________________

From report at bugs.python.org  Mon Oct 12 17:17:04 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Oct 2015 15:17:04 +0000
Subject: [issue25381] Doc: Use of old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1444663024.62.0.523311920732.issue25381@psf.upfronthosting.co.za>


R. David Murray added the comment:

Looks good to me.

----------
nosy: +r.david.murray
stage:  -> commit review
title: Doc: Use old description of raise in Python3 -> Doc: Use of old description of raise in Python3
versions: +Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25381>
_______________________________________

From report at bugs.python.org  Mon Oct 12 17:20:17 2015
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 12 Oct 2015 15:20:17 +0000
Subject: [issue21159] configparser.InterpolationMissingOptionError is not very
 intuitive
In-Reply-To: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za>
Message-ID: <1444663217.22.0.766134347837.issue21159@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21159>
_______________________________________

From report at bugs.python.org  Mon Oct 12 17:21:20 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Oct 2015 15:21:20 +0000
Subject: [issue25381] Doc: Use of old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1444663280.55.0.631498792935.issue25381@psf.upfronthosting.co.za>


R. David Murray added the comment:

Actually, I take that back.  Shouldn't it be "the object passed *as* the exception object to raise?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25381>
_______________________________________

From report at bugs.python.org  Mon Oct 12 17:22:58 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Oct 2015 15:22:58 +0000
Subject: [issue25381] Doc: Use of old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1444663378.29.0.491356440644.issue25381@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25381>
_______________________________________

From report at bugs.python.org  Mon Oct 12 17:23:50 2015
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 12 Oct 2015 15:23:50 +0000
Subject: [issue21159] configparser.InterpolationMissingOptionError is not very
 intuitive
In-Reply-To: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za>
Message-ID: <1444663430.42.0.672625817042.issue21159@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Reopening because we're starting to see regressions caused by the fix for this bug, e.g.: https://bugs.launchpad.net/configglue/+bug/1504288

----------
keywords: +3.4regression, 3.5regression -patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21159>
_______________________________________

From report at bugs.python.org  Mon Oct 12 17:29:14 2015
From: report at bugs.python.org (L)
Date: Mon, 12 Oct 2015 15:29:14 +0000
Subject: [issue25359] io.open() fails to open ascii file if LANG env not set
In-Reply-To: <1444458576.92.0.950124255306.issue25359@psf.upfronthosting.co.za>
Message-ID: <1444663754.05.0.253301267318.issue25359@psf.upfronthosting.co.za>


L added the comment:

Mac OSX 10.8.5
Python 2.7.10 installed via macports

$ python2.7 io.openBugEx.py
Local pref:  UTF-8
LANG env:  en_US.UTF-8
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
Local pref:
LANG env has key:  False

Traceback (most recent call last):
  File "io.openBugEx.py", line 21, in <module>
    print io.open(tmpfile).read()
LookupError: unknown encoding:

----------
status: pending -> open
type: behavior -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25359>
_______________________________________

From report at bugs.python.org  Mon Oct 12 17:29:30 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Oct 2015 15:29:30 +0000
Subject: [issue21159] configparser.InterpolationMissingOptionError is not very
 intuitive
In-Reply-To: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za>
Message-ID: <1444663770.19.0.446823653648.issue21159@psf.upfronthosting.co.za>


R. David Murray added the comment:

The linked bug doesn't include any information as to what the observed failure mode(s) are.  Can you provide details, please?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21159>
_______________________________________

From report at bugs.python.org  Mon Oct 12 17:43:07 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 12 Oct 2015 15:43:07 +0000
Subject: [issue24575] timemodule build fail - missing definitions for
 _Py_BEGIN_SUPPRESS_IPH and _Py_END_SUPPRESS_IPH
In-Reply-To: <1436188396.48.0.089424009249.issue24575@psf.upfronthosting.co.za>
Message-ID: <1444664587.31.0.475609305751.issue24575@psf.upfronthosting.co.za>


Steve Dower added the comment:

If they are compiled independently, they should have Py_BUILD_CORE set. 

That flag is meant for the headers, which serve dual purposes, not the module itself. *Any* C file that is part of core should expect that option to be set for when it includes its headers.

All that said, it seems that _datetimemodule.c forces Py_BUILD_CORE on to get access to some extra definitions, which presumably means that somebody at some point wanted to compile it into an extension module. I don't see the use case here though - is there something about its public API that is not stable?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24575>
_______________________________________

From report at bugs.python.org  Mon Oct 12 17:45:52 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 12 Oct 2015 15:45:52 +0000
Subject: [issue25001] Make --nowindows argument to regrtest propagate when
 running with -j
In-Reply-To: <1441399617.05.0.891415993838.issue25001@psf.upfronthosting.co.za>
Message-ID: <1444664752.34.0.76748919753.issue25001@psf.upfronthosting.co.za>


Steve Dower added the comment:

Between Victor's fix and #23919, is there anything left to do for this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25001>
_______________________________________

From report at bugs.python.org  Mon Oct 12 17:48:43 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Oct 2015 15:48:43 +0000
Subject: [issue25359] io.open() fails to open ascii file if LANG env not set
In-Reply-To: <1444458576.92.0.950124255306.issue25359@psf.upfronthosting.co.za>
Message-ID: <1444664923.32.0.815270055544.issue25359@psf.upfronthosting.co.za>


R. David Murray added the comment:

I cannot reproduce this on 10.10.3:

rdmurray at intel-vm-buildbot:~>sw_vers
ProductName:    Mac OS X
ProductVersion: 10.10.3
BuildVersion:   14D136

rdmurray at intel-vm-buildbot:~>LANG=en_us.UTF-8 python temp
Local pref:  UTF-8
LANG env:  en_us.UTF-8
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
Local pref:  UTF-8
LANG env has key:  False
UTF-8
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL

This is using the installed Apple python, but I get the same result using a recent local 2.7 build.

----------
components: +Macintosh
nosy: +ned.deily, r.david.murray, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25359>
_______________________________________

From report at bugs.python.org  Mon Oct 12 17:48:52 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Oct 2015 15:48:52 +0000
Subject: [issue25359] io.open() fails to open ascii file if LANG env not set
In-Reply-To: <1444458576.92.0.950124255306.issue25359@psf.upfronthosting.co.za>
Message-ID: <1444664932.36.0.255169267311.issue25359@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25359>
_______________________________________

From report at bugs.python.org  Mon Oct 12 17:49:50 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 12 Oct 2015 15:49:50 +0000
Subject: [issue25381] Doc: Use of old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1444664990.57.0.849596125895.issue25381@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

With this sentence

A second global variable stores the ?associated value? of the exception (the second argument to raise).

I think the phrase inside the parentheses is to explain the "associated value", which is usually a string passed to the exception object, not the exception object itself.

Do I misunderstand anything?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25381>
_______________________________________

From report at bugs.python.org  Mon Oct 12 17:57:28 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Oct 2015 15:57:28 +0000
Subject: [issue25381] Doc: Use of old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1444665448.77.0.076000369867.issue25381@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes.  The second element of the sys.exc_info result is the exception instance, not the argument to the exception constructor.  The old raise syntax allowed you to specify the exception instance as the second argument to raise, but if you specified a string it converted it to an exception instance using the first argument as the constructor to call.  So, the 2.7 docs aren't entirely accurate, since it isn't the second argument to raise that is stored, but the object that results from raise *processing* its second argument.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25381>
_______________________________________

From report at bugs.python.org  Mon Oct 12 18:16:19 2015
From: report at bugs.python.org (L)
Date: Mon, 12 Oct 2015 16:16:19 +0000
Subject: [issue25359] io.open() fails to open ascii file if LANG env not set
In-Reply-To: <1444458576.92.0.950124255306.issue25359@psf.upfronthosting.co.za>
Message-ID: <1444666579.89.0.441987357949.issue25359@psf.upfronthosting.co.za>


L added the comment:

The difference, and I believe the crux of the issue is that locale.getprefferedencoding() is still returning and encoding for you, mine returns and emtpy str.

Do you have any other envs set that getprefferedencoding my be using:
 'LANGUAGE', 'LC_ALL', 'LC_CTYPE', and 'LANG'
Perhaps if you wipe all of these?

----------
components:  -Macintosh
type: behavior -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25359>
_______________________________________

From report at bugs.python.org  Mon Oct 12 18:18:22 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Oct 2015 16:18:22 +0000
Subject: [issue24931] _asdict breaks when inheriting from a namedtuple
In-Reply-To: <1440460188.11.0.136200791288.issue24931@psf.upfronthosting.co.za>
Message-ID: <1444666702.79.0.700727595499.issue24931@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> it seems odd that it has disappeared.

It disappeared because it was fundamentally broken in Python 3, so it had to be removed.  Providing __dict__ broke subclassing and produced odd behaviors.

----------
keywords:  -3.5regression
priority: high -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24931>
_______________________________________

From report at bugs.python.org  Mon Oct 12 18:26:01 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Oct 2015 16:26:01 +0000
Subject: [issue25001] Make --nowindows argument to regrtest propagate when
 running with -j
In-Reply-To: <1441399617.05.0.891415993838.issue25001@psf.upfronthosting.co.za>
Message-ID: <1444667161.49.0.493894600521.issue25001@psf.upfronthosting.co.za>


STINNER Victor added the comment:

We are good, I close the issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25001>
_______________________________________

From report at bugs.python.org  Mon Oct 12 18:30:54 2015
From: report at bugs.python.org (Shubham Dash)
Date: Mon, 12 Oct 2015 16:30:54 +0000
Subject: [issue18156] Add an 'attr' attribute to AttributeError
In-Reply-To: <1370619110.26.0.980030189702.issue18156@psf.upfronthosting.co.za>
Message-ID: <1444667454.62.0.1587222985.issue18156@psf.upfronthosting.co.za>


Changes by Shubham Dash <shubham.ddash at gmail.com>:


Added file: http://bugs.python.org/file40757/client.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18156>
_______________________________________

From report at bugs.python.org  Mon Oct 12 18:34:17 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 12 Oct 2015 16:34:17 +0000
Subject: [issue25381] Doc: Use of old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1444667657.77.0.336196194985.issue25381@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Oops, I misunderstand sys.exc_info all the time, sad :(

Now, both versions of doc are not correct. Please make them fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25381>
_______________________________________

From report at bugs.python.org  Mon Oct 12 18:45:10 2015
From: report at bugs.python.org (Mark Roseman)
Date: Mon, 12 Oct 2015 16:45:10 +0000
Subject: [issue25254] Idle: debugger source line highlighting fails again
In-Reply-To: <1443410161.14.0.45288371975.issue25254@psf.upfronthosting.co.za>
Message-ID: <1444668310.19.0.76390904113.issue25254@psf.upfronthosting.co.za>


Mark Roseman added the comment:

FYI, the new debugger UI has an option to only show highlights in already open files (i.e. don't open new ones)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25254>
_______________________________________

From report at bugs.python.org  Mon Oct 12 18:59:23 2015
From: report at bugs.python.org (Ned Deily)
Date: Mon, 12 Oct 2015 16:59:23 +0000
Subject: [issue25359] io.open() fails to open ascii file if LANG env not set
In-Reply-To: <1444458576.92.0.950124255306.issue25359@psf.upfronthosting.co.za>
Message-ID: <1444669163.07.0.295782999.issue25359@psf.upfronthosting.co.za>


Ned Deily added the comment:

I can reproduce the problem using the MacPorts python2.7 but not the Apple-supplied Python 2.7 or the python.org one.  The difference seems to be that the MacPorts Python is built with the MacPorts-supplied GNU gettext and its libintl, whereas the others aren't (since Apple does not ship libintl).  I don't have time at the moment to dig into why the libintl version of setlocale retunes '' instead of 'US-ASCII'.  Perhaps locale.py or io could handle that case better?

----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25359>
_______________________________________

From report at bugs.python.org  Mon Oct 12 19:31:37 2015
From: report at bugs.python.org (L)
Date: Mon, 12 Oct 2015 17:31:37 +0000
Subject: [issue25359] io.open() fails to open ascii file if LANG env not set
In-Reply-To: <1444458576.92.0.950124255306.issue25359@psf.upfronthosting.co.za>
Message-ID: <1444671097.46.0.275870613442.issue25359@psf.upfronthosting.co.za>


L added the comment:

Should I submit elsewhere?

----------
type: behavior -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25359>
_______________________________________

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: [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  Mon Oct 12 19:59:40 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Oct 2015 17:59:40 +0000
Subject: [issue25359] io.open() fails to open ascii file if LANG env not set
In-Reply-To: <1444458576.92.0.950124255306.issue25359@psf.upfronthosting.co.za>
Message-ID: <1444672780.68.0.573403471605.issue25359@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, it might be a bug in libintl, but it would be a good idea to investigate further before reporting it upstream to them.  And we may want to deal with the possibility of a blank return regardless.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25359>
_______________________________________

From report at bugs.python.org  Mon Oct 12 20:07:57 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Oct 2015 18:07:57 +0000
Subject: [issue22005] datetime.__setstate__ fails decoding python2 pickle
In-Reply-To: <1405687792.76.0.689943587668.issue22005@psf.upfronthosting.co.za>
Message-ID: <1444673276.99.0.248226167349.issue22005@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There are two issues here.

1. datetime.datetime accepts only bytes, not str.
2. Unpickling non-ASCII str pickled in Python 2 raises an error by default.

The second issue usually hides the first one. The demonstration of the first issue:

>>> pickle.loads(b'cdatetime\ndatetime\n(U\n\x07l\x01\x01\x00\x00\x00\x00\x00\x00tR.')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: an integer is required (got type str)

The first issue can be solved by accepting str argument and encoding it to bytes. The second issue can be solved by changing an encoding or an error handler. Following patch uses the "surrogateescape" error handler.

>>> pickle.loads(b'cdatetime\ndatetime\n(U\n\x07l\x01\x01\x00\x00\x00\x00\xc3\xa4tR.')
datetime.datetime(1900, 1, 1, 0, 0, 0, 50084)

Unfortunately setting the "surrogateescape" error handler by default has a side effect. It can hide string decoding errors. In addition, unpickling datetime will not always work with different encodings.

>>> pickle.loads(b'cdatetime\ndatetime\n(U\n\x07l\x01\x01\x00\x00\x00\x00\xc3\xa4tR.', encoding='latin1')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode characters in position 8-9: ordinal not in range(128)
>>> pickle.loads(b'cdatetime\ndatetime\n(U\n\x07l\x01\x01\x00\x00\x00\x00\xc3\xa4tR.', encoding='utf-8')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: an integer is required (got type str)

----------
keywords: +patch
nosy: +serhiy.storchaka
versions: +Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40758/unpickle_datetime_surrogateescape.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22005>
_______________________________________

From report at bugs.python.org  Mon Oct 12 20:12:56 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Oct 2015 18:12:56 +0000
Subject: [issue25359] io.open() fails to open ascii file if LANG env not set
In-Reply-To: <1444458576.92.0.950124255306.issue25359@psf.upfronthosting.co.za>
Message-ID: <1444673576.37.0.796696462497.issue25359@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Please don't change the type of the issue to "crash". This is different type of issues. See classification in https://docs.python.org/devguide/triaging.html#type.

----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25359>
_______________________________________

From report at bugs.python.org  Mon Oct 12 20:19:05 2015
From: report at bugs.python.org (L)
Date: Mon, 12 Oct 2015 18:19:05 +0000
Subject: [issue25359] io.open() fails to open ascii file if LANG env not set
In-Reply-To: <1444458576.92.0.950124255306.issue25359@psf.upfronthosting.co.za>
Message-ID: <1444673945.8.0.403555270782.issue25359@psf.upfronthosting.co.za>


L added the comment:

Type changed from cash to behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25359>
_______________________________________

From report at bugs.python.org  Mon Oct 12 20:19:12 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 12 Oct 2015 18:19:12 +0000
Subject: [issue22005] datetime.__setstate__ fails decoding python2 pickle
In-Reply-To: <1405687792.76.0.689943587668.issue22005@psf.upfronthosting.co.za>
Message-ID: <1444673952.29.0.210553472394.issue22005@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> The first issue can be solved by accepting str argument and encoding it to bytes.

A strong -1 from me.  Accepting bytes objects for year in 3.x (and str in 2.x) is a gross hack.  In the long run, I would like to see a public named constructor, e.g. datetime.datetime.load to be used in datetime pickles.

Can someone explain succinctly what the problem is?  Does it only affect pickles transferred between 2.x and 3.x Pythons?  If not, how can I reproduce the problem in 3.5?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22005>
_______________________________________

From report at bugs.python.org  Mon Oct 12 20:55:03 2015
From: report at bugs.python.org (Mark Roseman)
Date: Mon, 12 Oct 2015 18:55:03 +0000
Subject: [issue24782] Merge 'configure extensions' into main IDLE config dialog
In-Reply-To: <1438549617.46.0.760286591646.issue24782@psf.upfronthosting.co.za>
Message-ID: <1444676103.41.0.12366057815.issue24782@psf.upfronthosting.co.za>


Mark Roseman added the comment:

No, I don't, sorry.  If it will be quick for you to do, no problem, otherwise I'd be happy to put it together.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24782>
_______________________________________

From report at bugs.python.org  Mon Oct 12 20:59:02 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Oct 2015 18:59:02 +0000
Subject: [issue22005] datetime.__setstate__ fails decoding python2 pickle
In-Reply-To: <1444673952.29.0.210553472394.issue22005@psf.upfronthosting.co.za>
Message-ID: <1554999.fs9U5IjYUQ@raxxla>


Serhiy Storchaka added the comment:

The problem is that you can't unpickle a data that contains both datetime 
classes (datetime, date, time) instances and strings (including attribute 
names, so actually this affects instances of any Python classes). Yes, it only 
affects pickles transferred between 2.x and 3.x Pythons.

Yet one possible solution is to change datetime classes in 2.x to produce more 
portable pickles. But new pickles will be larger, and pickling and unpickling 
will be slower, and this doesn't solve a problem with existing pickled data. 
We still are receiving bug reports for 2.7.3 and like.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22005>
_______________________________________

From report at bugs.python.org  Mon Oct 12 21:13:33 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 12 Oct 2015 19:13:33 +0000
Subject: [issue22005] datetime.__setstate__ fails decoding python2 pickle
In-Reply-To: <1405687792.76.0.689943587668.issue22005@psf.upfronthosting.co.za>
Message-ID: <1444677213.14.0.686017572585.issue22005@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I wonder if this can be fixed using a fix_imports hook.  I agree, it would be nice to fix this issue by modifying 3.x versions only.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22005>
_______________________________________

From report at bugs.python.org  Mon Oct 12 21:18:17 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 12 Oct 2015 19:18:17 +0000
Subject: [issue22005] datetime.__setstate__ fails decoding python2 pickle
In-Reply-To: <1405687792.76.0.689943587668.issue22005@psf.upfronthosting.co.za>
Message-ID: <1444677497.64.0.479848661582.issue22005@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> .. pickling and unpickling will be slower

If we are concerned about performance, we should definitely avoid the decode-encode roundtrip.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22005>
_______________________________________

From report at bugs.python.org  Mon Oct 12 21:34:09 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 12 Oct 2015 19:34:09 +0000
Subject: [issue24782] Merge 'configure extensions' into main IDLE config dialog
In-Reply-To: <1438549617.46.0.760286591646.issue24782@psf.upfronthosting.co.za>
Message-ID: <1444678449.37.0.861907304978.issue24782@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Go ahead then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24782>
_______________________________________

From report at bugs.python.org  Mon Oct 12 21:47:35 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Oct 2015 19:47:35 +0000
Subject: [issue22005] datetime.__setstate__ fails decoding python2 pickle
In-Reply-To: <1405687792.76.0.689943587668.issue22005@psf.upfronthosting.co.za>
Message-ID: <1444679255.1.0.926959836287.issue22005@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch against 2.7 that makes datetime pickling portable.

It doesn't solve problem with existing pickled data, but at least it allows to convert existing pickled data with 2.7 to portable format.

----------
Added file: http://bugs.python.org/file40759/datetime_portable_pickle-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22005>
_______________________________________

From report at bugs.python.org  Mon Oct 12 22:39:08 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Oct 2015 20:39:08 +0000
Subject: [issue22005] datetime.__setstate__ fails decoding python2 pickle
In-Reply-To: <1405687792.76.0.689943587668.issue22005@psf.upfronthosting.co.za>
Message-ID: <1444682348.3.0.61828255163.issue22005@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is alternative patch for 2.7. It makes datetime pickling produce the same data as in 3.x.

The side effect of this approach: it makes datetime pickling incompatible with Unicode disabled builds of 2.x.

----------
stage:  -> patch review
versions: +Python 2.7
Added file: http://bugs.python.org/file40760/datetime_pickle_bytes-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22005>
_______________________________________

From report at bugs.python.org  Mon Oct 12 22:39:28 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Oct 2015 20:39:28 +0000
Subject: [issue25353] Use _PyBytesWriter for unicode escape and raw unicode
 escape encoders
In-Reply-To: <1444392822.73.0.0714587534509.issue25353@psf.upfronthosting.co.za>
Message-ID: <20151012203922.97712.38890@psf.io>


Roundup Robot added the comment:

New changeset 8e27f8398a4f by Victor Stinner in branch 'default':
Issue #25353: Optimize unicode escape and raw unicode escape encoders to use
https://hg.python.org/cpython/rev/8e27f8398a4f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25353>
_______________________________________

From report at bugs.python.org  Mon Oct 12 22:41:38 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Oct 2015 20:41:38 +0000
Subject: [issue25353] Use _PyBytesWriter for unicode escape and raw unicode
 escape encoders
In-Reply-To: <1444392822.73.0.0714587534509.issue25353@psf.upfronthosting.co.za>
Message-ID: <1444682498.64.0.342646251822.issue25353@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25353>
_______________________________________

From report at bugs.python.org  Mon Oct 12 23:02:58 2015
From: report at bugs.python.org (Mark Roseman)
Date: Mon, 12 Oct 2015 21:02:58 +0000
Subject: [issue24782] Merge 'configure extensions' into main IDLE config dialog
In-Reply-To: <1438549617.46.0.760286591646.issue24782@psf.upfronthosting.co.za>
Message-ID: <1444683778.81.0.781430335808.issue24782@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Patch against head to change extensions dialog to a pane of main config dialog.

----------
Added file: http://bugs.python.org/file40761/mergeext.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24782>
_______________________________________

From report at bugs.python.org  Mon Oct 12 23:03:30 2015
From: report at bugs.python.org (Mark Roseman)
Date: Mon, 12 Oct 2015 21:03:30 +0000
Subject: [issue24782] Merge 'configure extensions' into main IDLE config dialog
In-Reply-To: <1438549617.46.0.760286591646.issue24782@psf.upfronthosting.co.za>
Message-ID: <1444683810.86.0.807326233773.issue24782@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Same patch against 2.7

----------
Added file: http://bugs.python.org/file40762/mergeext27.cfg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24782>
_______________________________________

From report at bugs.python.org  Mon Oct 12 23:33:01 2015
From: report at bugs.python.org (paul j3)
Date: Mon, 12 Oct 2015 21:33:01 +0000
Subject: [issue18769] argparse remove subparser
In-Reply-To: <1376757040.66.0.700111900917.issue18769@psf.upfronthosting.co.za>
Message-ID: <1444685581.89.0.851148522116.issue18769@psf.upfronthosting.co.za>


paul j3 added the comment:

There's a partial overlap with this issue

http://bugs.python.org/issue22848

which seeks to hide a subparser - both in the help lines and the choices lists.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18769>
_______________________________________

From report at bugs.python.org  Mon Oct 12 23:37:42 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Oct 2015 21:37:42 +0000
Subject: [issue25277] test_sigwaitinfo() of test_eintr hangs on randomly on
 FreeBSD buildbots
In-Reply-To: <1443605568.0.0.865946740877.issue25277@psf.upfronthosting.co.za>
Message-ID: <20151012213740.455.54018@psf.io>


Roundup Robot added the comment:

New changeset 605eda657884 by Victor Stinner in branch '3.5':
Issue #25277: Use a longer sleep in test_eintr to reduce the risk of race
https://hg.python.org/cpython/rev/605eda657884

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25277>
_______________________________________

From report at bugs.python.org  Mon Oct 12 23:55:36 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Oct 2015 21:55:36 +0000
Subject: [issue25277] test_sigwaitinfo() of test_eintr hangs on randomly on
 FreeBSD buildbots
In-Reply-To: <1443605568.0.0.865946740877.issue25277@psf.upfronthosting.co.za>
Message-ID: <1444686936.13.0.222949704025.issue25277@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I hope that 2 seconds should be enough to workaround the lack of real synchronization between the parent and the child process.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25277>
_______________________________________

From report at bugs.python.org  Tue Oct 13 00:16:33 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Oct 2015 22:16:33 +0000
Subject: [issue25274] sys.setrecursionlimit() must fail if the current
 recursion depth is higher than the new low-water mark
In-Reply-To: <1443570348.5.0.971307491137.issue25274@psf.upfronthosting.co.za>
Message-ID: <20151012221630.18372.67954@psf.io>


Roundup Robot added the comment:

New changeset eb0c76442cee by Victor Stinner in branch '3.5':
sys.setrecursionlimit() now raises RecursionError
https://hg.python.org/cpython/rev/eb0c76442cee

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25274>
_______________________________________

From report at bugs.python.org  Tue Oct 13 00:19:15 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Oct 2015 22:19:15 +0000
Subject: [issue25274] sys.setrecursionlimit() must fail if the current
 recursion depth is higher than the new low-water mark
In-Reply-To: <1443570348.5.0.971307491137.issue25274@psf.upfronthosting.co.za>
Message-ID: <1444688355.68.0.970634576058.issue25274@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I pushed sys_setrecursionlimit-4.patch.

Thanks a lot Serhiy for your review and your help on this issue!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25274>
_______________________________________

From report at bugs.python.org  Tue Oct 13 00:21:13 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Oct 2015 22:21:13 +0000
Subject: [issue25207] ICC compiler warnings
In-Reply-To: <1442867798.75.0.456459463931.issue25207@psf.upfronthosting.co.za>
Message-ID: <1444688473.41.0.628418191053.issue25207@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I fixed some warnings.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25207>
_______________________________________

From report at bugs.python.org  Tue Oct 13 00:23:26 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Oct 2015 22:23:26 +0000
Subject: [issue24164] Support pickling objects with __new__ with keyword
 arguments with protocol 2+
In-Reply-To: <1431341390.51.0.0928642680419.issue24164@psf.upfronthosting.co.za>
Message-ID: <1444688606.7.0.212926171818.issue24164@psf.upfronthosting.co.za>


STINNER Victor added the comment:

At least, test_pyclbr was fixed by my change. Most 3.x buildbots are green again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24164>
_______________________________________

From report at bugs.python.org  Tue Oct 13 00:25:55 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Oct 2015 22:25:55 +0000
Subject: [issue25230] asyncio/Windows: Unix datagram sockets not supported
In-Reply-To: <1443132861.89.0.286854164453.issue25230@psf.upfronthosting.co.za>
Message-ID: <1444688755.95.0.656831430878.issue25230@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: Unix datagram sockets not supported -> asyncio/Windows: Unix datagram sockets not supported

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25230>
_______________________________________

From report at bugs.python.org  Tue Oct 13 00:33:57 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Oct 2015 22:33:57 +0000
Subject: [issue25210] Special-case NoneType() in do_richcompare()
In-Reply-To: <1442900927.33.0.98928488186.issue25210@psf.upfronthosting.co.za>
Message-ID: <1444689237.09.0.0671950355008.issue25210@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> TypeError: '<' not supported between instances of 'int' and 'NoneType'

Here is a patch for Python 3.6.

----------
keywords: +patch
Added file: http://bugs.python.org/file40763/richcompare.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25210>
_______________________________________

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: [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 01:53:44 2015
From: report at bugs.python.org (Alexander Riccio)
Date: Mon, 12 Oct 2015 23:53:44 +0000
Subject: [issue25386] msvcrt_putch/msvcrt_putwch don't check the return value
 of _putch/_putwch
In-Reply-To: <1444693845.85.0.133666844386.issue25386@psf.upfronthosting.co.za>
Message-ID: <1444694024.65.0.729816377292.issue25386@psf.upfronthosting.co.za>


Alexander Riccio added the comment:

For your convenience, the MSDN docs for the _putch/_putwch functions: https://msdn.microsoft.com/en-us/library/azb6c04e.aspx

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25386>
_______________________________________

From report at bugs.python.org  Tue Oct 13 02:23:21 2015
From: report at bugs.python.org (Alexander Riccio)
Date: Tue, 13 Oct 2015 00:23:21 +0000
Subject: [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 02:30:51 2015
From: report at bugs.python.org (Alexander Riccio)
Date: Tue, 13 Oct 2015 00:30:51 +0000
Subject: [issue25387] sound_msgbeep doesn't check the return value of
 MessageBeep
Message-ID: <1444696251.21.0.518539201505.issue25387@psf.upfronthosting.co.za>


New submission from Alexander Riccio:

A really minor issue (probably qualifies for the "easy" keyword):

sound_msgbeep (in http://svn.python.org/projects/python/trunk/PC/winsound.c) doesn't check the return value of MessageBeep (https://msdn.microsoft.com/en-us/library/windows/desktop/ms680356.aspx). This is a very minor issue, but the possibility of failure is not mentioned in the winsound documentation. Invisible failures are quite surprising.


A message in the Gnome archives (https://mail.gnome.org/archives/commits-list/2010-November/msg01938.html) has an example "fix".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25387>
_______________________________________

From report at bugs.python.org  Tue Oct 13 03:46:36 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 13 Oct 2015 01:46:36 +0000
Subject: [issue25210] Special-case NoneType() in do_richcompare()
In-Reply-To: <1442900927.33.0.98928488186.issue25210@psf.upfronthosting.co.za>
Message-ID: <1444700796.96.0.760821595509.issue25210@psf.upfronthosting.co.za>


Martin Panter added the comment:

I like the patch.

It looks like some of the example sessions in the documentation will become out of date. Not sure if that is a problem.

----------
nosy: +martin.panter
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25210>
_______________________________________

From report at bugs.python.org  Tue Oct 13 04:29:32 2015
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 13 Oct 2015 02:29:32 +0000
Subject: [issue25386] msvcrt_putch/msvcrt_putwch don't check the return value
 of _putch/_putwch
In-Reply-To: <1444693845.85.0.133666844386.issue25386@psf.upfronthosting.co.za>
Message-ID: <1444703372.62.0.884935061563.issue25386@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Feel free to create a patch yourself, we'll be happy to review it.  Note though that the python project on svn.python.org is old and abandoned; we moved to Mercurial several years ago (see https://hg.python.org/cpython/).  I haven't checked to see whether the issue you report has already been fixed in the years since moving away from svn.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25386>
_______________________________________

From report at bugs.python.org  Tue Oct 13 04:46:16 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 13 Oct 2015 02:46:16 +0000
Subject: [issue25210] Special-case NoneType() in do_richcompare()
In-Reply-To: <1442900927.33.0.98928488186.issue25210@psf.upfronthosting.co.za>
Message-ID: <1444704376.43.0.470345374285.issue25210@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

LGTM.
Updating examples is low-priority but I think it should be done.
I think it would be good to also add a couple of tests to make sure that the correct operator and types are included in the message.
Both make good bite-sized tasks for new contributors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25210>
_______________________________________

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: [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 05:16:00 2015
From: report at bugs.python.org (Brian Cain)
Date: Tue, 13 Oct 2015 03:16:00 +0000
Subject: [issue25388] tokenizer crash/misbehavior
In-Reply-To: <1444706115.92.0.283351483962.issue25388@psf.upfronthosting.co.za>
Message-ID: <1444706160.42.0.407544814077.issue25388@psf.upfronthosting.co.za>


Brian Cain added the comment:

asan output

----------
Added file: http://bugs.python.org/file40765/asan.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25388>
_______________________________________

From report at bugs.python.org  Tue Oct 13 05:16:44 2015
From: report at bugs.python.org (Brian Cain)
Date: Tue, 13 Oct 2015 03:16:44 +0000
Subject: [issue25388] tokenizer crash/misbehavior -- heap use-after-free
In-Reply-To: <1444706115.92.0.283351483962.issue25388@psf.upfronthosting.co.za>
Message-ID: <1444706204.3.0.431301791757.issue25388@psf.upfronthosting.co.za>


Changes by Brian Cain <brian.cain at gmail.com>:


----------
title: tokenizer crash/misbehavior -> tokenizer crash/misbehavior -- heap use-after-free

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25388>
_______________________________________

From report at bugs.python.org  Tue Oct 13 05:18:14 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 13 Oct 2015 03:18:14 +0000
Subject: [issue25381] Doc: Use of old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1444706294.93.0.104170764692.issue25381@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I fix my patch with David's comment.

----------
Added file: http://bugs.python.org/file40766/doc_extending2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25381>
_______________________________________

From report at bugs.python.org  Tue Oct 13 05:29:42 2015
From: report at bugs.python.org (Brian Cain)
Date: Tue, 13 Oct 2015 03:29:42 +0000
Subject: [issue25388] tokenizer crash/misbehavior -- heap use-after-free
In-Reply-To: <1444706115.92.0.283351483962.issue25388@psf.upfronthosting.co.za>
Message-ID: <1444706982.15.0.343396030791.issue25388@psf.upfronthosting.co.za>


Changes by Brian Cain <brian.cain at gmail.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25388>
_______________________________________

From report at bugs.python.org  Tue Oct 13 05:58:04 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 13 Oct 2015 03:58:04 +0000
Subject: [issue16151] Deferred KeyboardInterrupt in interactive mode
In-Reply-To: <1349551962.43.0.949416732292.issue16151@psf.upfronthosting.co.za>
Message-ID: <1444708684.76.0.307492817757.issue16151@psf.upfronthosting.co.za>


Martin Panter added the comment:

I can?t reproduce this on 2.7.10 nor 3.4.3, on Arch Linux with Gnu Readline 6.3.008-1. Instead, when I press <Tab><Tab>, I see the y or n query printed, but it is immediately followed by all the possibilities (as if I said Y) without any chance to actually enter Y or N or hit Ctrl+C.

----------
nosy: +martin.panter
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16151>
_______________________________________

From report at bugs.python.org  Tue Oct 13 06:01:36 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 13 Oct 2015 04:01:36 +0000
Subject: [issue16151] Deferred KeyboardInterrupt in interactive mode
In-Reply-To: <1349551962.43.0.949416732292.issue16151@psf.upfronthosting.co.za>
Message-ID: <1444708896.14.0.666419614905.issue16151@psf.upfronthosting.co.za>


Martin Panter added the comment:

FWIW the ?Display all possibilities? prompt works properly in Bash, so maybe I have a separate bug somewhere which is masking Serhiy?s bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16151>
_______________________________________

From report at bugs.python.org  Tue Oct 13 06:26:28 2015
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 13 Oct 2015 04:26:28 +0000
Subject: [issue25093] New 3.5.0 failure in test_tcl on win7
In-Reply-To: <1442200639.15.0.127298727385.issue25093@psf.upfronthosting.co.za>
Message-ID: <1444710388.94.0.0775821621713.issue25093@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
versions: +Python 3.4, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25093>
_______________________________________

From report at bugs.python.org  Tue Oct 13 06:27:03 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 13 Oct 2015 04:27:03 +0000
Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT
Message-ID: <1444710423.83.0.277808853337.issue1054041@psf.upfronthosting.co.za>


Martin Panter added the comment:

This covers the same ground as Issue 14229, which was rejected with the argument that re-raising the signal is ?ugly? and bypasses some things that are done by the standard OS exit() function.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054041>
_______________________________________

From report at bugs.python.org  Tue Oct 13 06:32:04 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 13 Oct 2015 04:32:04 +0000
Subject: [issue25093] New 3.5.0 failure in test_tcl on win7
In-Reply-To: <1442200639.15.0.127298727385.issue25093@psf.upfronthosting.co.za>
Message-ID: <20151013043200.485.70375@psf.io>


Roundup Robot added the comment:

New changeset 6eb49f521336 by Zachary Ware in branch '3.4':
Issue #25093: Fix test_tcl's testloadWithUNC for paths with spaces
https://hg.python.org/cpython/rev/6eb49f521336

New changeset a557ec9c8b12 by Zachary Ware in branch '3.5':
Issue #25093: Merge with 3.4
https://hg.python.org/cpython/rev/a557ec9c8b12

New changeset a345d1c70d95 by Zachary Ware in branch 'default':
Closes #25093: Merge with 3.5
https://hg.python.org/cpython/rev/a345d1c70d95

----------
nosy: +python-dev
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25093>
_______________________________________

From report at bugs.python.org  Tue Oct 13 06:38:37 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 13 Oct 2015 04:38:37 +0000
Subject: [issue13673] PyTraceBack_Print() fails if signal received but
 PyErr_CheckSignals() not called
In-Reply-To: <1325108100.49.0.901203078622.issue13673@psf.upfronthosting.co.za>
Message-ID: <1444711117.03.0.682132426056.issue13673@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
Removed message: http://bugs.python.org/msg185910

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13673>
_______________________________________

From report at bugs.python.org  Tue Oct 13 06:38:39 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 13 Oct 2015 04:38:39 +0000
Subject: [issue13673] PyTraceBack_Print() fails if signal received but
 PyErr_CheckSignals() not called
In-Reply-To: <1325108100.49.0.901203078622.issue13673@psf.upfronthosting.co.za>
Message-ID: <1444711119.2.0.998886129029.issue13673@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
Removed message: http://bugs.python.org/msg185911

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13673>
_______________________________________

From report at bugs.python.org  Tue Oct 13 06:40:06 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 13 Oct 2015 04:40:06 +0000
Subject: [issue25376] KeyboardInterrupt handling and traceback broken on
 Windows 10
In-Reply-To: <1444566744.92.0.693006452936.issue25376@psf.upfronthosting.co.za>
Message-ID: <1444711206.52.0.34532967708.issue25376@psf.upfronthosting.co.za>


Martin Panter added the comment:

I am no Windows expert, but I read in Issue 18597 that Ctrl+C is treated as EOF, except that a SIGINT is also sent in the background. This would explain why you see an EOFError. The partial traceback may also be from the same EOFError. Or both cases could be truncated reports of KeyboardInterrupt chained onto EOFError.

I understand the code path for input() may bypass the usual stdin.read() and readline() methods. Issue 18597 is about readline(), so it may not be an exact duplicate.

See also Issue 17619, which hints that KeyboardInterrupt handling for input() was worked on and fixed in 3.3. So why is it broken again in 3.4? A regression test would be nice, if at all possible. Does Windows have an equivalent of pseudo terminals?

Possibly also related is Issue 13673, about functions (like input) raising an exception (like EOFError), when SIGINT has been received. It mentions the interpreter completely failing to report the entire traceback, or truncating the traceback. It might be worth trying out the patch there. It might also be interesting to check sys.last_value in the interactive case.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25376>
_______________________________________

From report at bugs.python.org  Tue Oct 13 07:07:24 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 13 Oct 2015 05:07:24 +0000
Subject: [issue25381] Doc: Use of old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1444712844.69.0.815914782156.issue25381@psf.upfronthosting.co.za>


Martin Panter added the comment:

?Associated value? still seems a bit weird. I wonder if it would be clearer to say

The exception type is stored in a static global variable .?.?. A second global variable stores the exception instance passed to :keyword:`raise` .?.?.

Also further down that section it looks like there are other problems. ?Exception object? is perhaps actually a C object referencing the exception class (type). ?Python string object .?.?. stored as the "associated value"?? should perhaps be the exception instance (object). I think a long time ago Python may have actually worked this way, but not any more, and the whole section probably needs updating.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25381>
_______________________________________

From report at bugs.python.org  Tue Oct 13 07:11:36 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Oct 2015 05:11:36 +0000
Subject: [issue25093] New 3.5.0 failure in test_tcl on win7
In-Reply-To: <1442200639.15.0.127298727385.issue25093@psf.upfronthosting.co.za>
Message-ID: <1444713096.87.0.707115035466.issue25093@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks Zachary. I couldn't test the patch myself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25093>
_______________________________________

From report at bugs.python.org  Tue Oct 13 07:27:07 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Oct 2015 05:27:07 +0000
Subject: [issue16151] Deferred KeyboardInterrupt in interactive mode
In-Reply-To: <1349551962.43.0.949416732292.issue16151@psf.upfronthosting.co.za>
Message-ID: <1444714027.33.0.847184430823.issue16151@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I can't reproduce original behavior anymore. In 3.4+ <Tab> at the begin of the line inserts the tabulation character. In 2.7 and 3.3- double <Tab> causes the behavior described by Martin.

Yes, please open new issue about the ?Display all possibilities? prompt Martin.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16151>
_______________________________________

From report at bugs.python.org  Tue Oct 13 07:33:48 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Oct 2015 05:33:48 +0000
Subject: [issue24164] Support pickling objects with __new__ with keyword
 arguments with protocol 2+
In-Reply-To: <1431341390.51.0.0928642680419.issue24164@psf.upfronthosting.co.za>
Message-ID: <1444714428.13.0.488454226608.issue24164@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Victor for fixing test_pyclbr. test_pyclbr looks fragile and may be there are bugs in pyclbr itself. But this is different issue.

Could you please look at proposed documentation changes?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24164>
_______________________________________

From report at bugs.python.org  Tue Oct 13 07:38:44 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 13 Oct 2015 05:38:44 +0000
Subject: [issue25381] Doc: Use of old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1444714724.26.0.370077841537.issue25381@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Yes, you are right martin. It seems the whole chapter needs more updates, not only the bits I mentioned. I won't provide a new patch since I am not an English native and I am not sure I can provide an accurate and right description. Hope someone else may help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25381>
_______________________________________

From report at bugs.python.org  Tue Oct 13 08:31:59 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 13 Oct 2015 06:31:59 +0000
Subject: [issue25194] Opt-in motivations & affiliations page for core
 contributors
In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za>
Message-ID: <1444717919.12.0.973573657245.issue25194@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I'm about to hop on a plane to PyCon Poland, so David, how about you just go ahead and add your entry? After some reflection, I've realised we probably don't want to be too prescriptive regarding the personal bios, and can instead let patterns & themes emerge as folks add their own entries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25194>
_______________________________________

From report at bugs.python.org  Tue Oct 13 10:46:17 2015
From: report at bugs.python.org (Jan Malte)
Date: Tue, 13 Oct 2015 08:46:17 +0000
Subject: [issue22684] message.as_bytes() produces recursion depth exceeded
In-Reply-To: <1413894566.0.0.84714989702.issue22684@psf.upfronthosting.co.za>
Message-ID: <1444725977.3.0.819712611582.issue22684@psf.upfronthosting.co.za>


Jan Malte added the comment:

Are there any news about this bug report?

----------
nosy: +janmalte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22684>
_______________________________________

From report at bugs.python.org  Tue Oct 13 10:52:53 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 13 Oct 2015 08:52:53 +0000
Subject: [issue25384] Use _PyBytesWriter in the binascii module
In-Reply-To: <1444650015.66.0.169778133218.issue25384@psf.upfronthosting.co.za>
Message-ID: <20151013085249.20779.88082@psf.io>


Roundup Robot added the comment:

New changeset d6fcda2b9b5e by Victor Stinner in branch 'default':
Issue #25384: Use _PyBytesWriter API in binascii
https://hg.python.org/cpython/rev/d6fcda2b9b5e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25384>
_______________________________________

From report at bugs.python.org  Tue Oct 13 10:53:05 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Oct 2015 08:53:05 +0000
Subject: [issue25384] Use _PyBytesWriter in the binascii module
In-Reply-To: <1444650015.66.0.169778133218.issue25384@psf.upfronthosting.co.za>
Message-ID: <1444726385.87.0.580768125615.issue25384@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25384>
_______________________________________

From report at bugs.python.org  Tue Oct 13 11:02:29 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 13 Oct 2015 09:02:29 +0000
Subject: [issue25386] msvcrt_putch/msvcrt_putwch don't check the return value
 of _putch/_putwch
In-Reply-To: <1444693845.85.0.133666844386.issue25386@psf.upfronthosting.co.za>
Message-ID: <1444726949.32.0.19973178822.issue25386@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Although the function names have changed (I think due to Argument Clinic), the reported issue still applies to the current code:

https://hg.python.org/cpython/file/tip/PC/msvcrtmodule.c#l309

I'll let other decide if the change is actually desirable. It would be interesting to know under what circumstances these functions can fail.

----------
keywords: +easy
nosy: +eric.smith
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25386>
_______________________________________

From report at bugs.python.org  Tue Oct 13 11:22:41 2015
From: report at bugs.python.org (IvenDong)
Date: Tue, 13 Oct 2015 09:22:41 +0000
Subject: [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: [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 11:49:42 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Oct 2015 09:49:42 +0000
Subject: [issue24164] Support pickling objects with __new__ with keyword
 arguments with protocol 2+
In-Reply-To: <1444714428.13.0.488454226608.issue24164@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwb3pQ_e8jyYjQ+mzeFKVgc1LTfMt0ygp+Ycstf6xKwefQ@mail.gmail.com>


STINNER Victor added the comment:

Serhiy Storchaka added the comment:
> Could you please look at proposed documentation changes?

Sure, done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24164>
_______________________________________

From report at bugs.python.org  Tue Oct 13 12:13:54 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 13 Oct 2015 10:13:54 +0000
Subject: [issue25390] Can't define a typing.Union containing a
 typing.re.Pattern
In-Reply-To: <1444728467.55.0.552197008785.issue25390@psf.upfronthosting.co.za>
Message-ID: <1444731234.45.0.893466679881.issue25390@psf.upfronthosting.co.za>


Changes by Xiang Zhang <18518281186 at 126.com>:


----------
nosy: +xiang.zhang

_______________________________________
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: [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:09:06 2015
From: report at bugs.python.org (Lewis Haley)
Date: Tue, 13 Oct 2015 11:09:06 +0000
Subject: [issue25391] difflib.SequenceMatcher(...).ratio gives
 bad/wrong/unexpected low value with repetitious strings
In-Reply-To: <1444734460.53.0.30170524569.issue25391@psf.upfronthosting.co.za>
Message-ID: <1444734546.0.0.871572597729.issue25391@psf.upfronthosting.co.za>


Changes by Lewis Haley <lewismhaley at gmail.com>:


----------
title: difflib.SequenceMatcher(...).ratio gives bad/wrong/unexpected low value with repetitous strings -> difflib.SequenceMatcher(...).ratio gives bad/wrong/unexpected low value with repetitious strings

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25391>
_______________________________________

From report at bugs.python.org  Tue Oct 13 13:38:20 2015
From: report at bugs.python.org (Ned Deily)
Date: Tue, 13 Oct 2015 11:38:20 +0000
Subject: [issue25389] It crashes as long as I press "(parenthese)
In-Reply-To: <1444728159.88.0.185583668011.issue25389@psf.upfronthosting.co.za>
Message-ID: <1444736300.59.0.8498655494.issue25389@psf.upfronthosting.co.za>


Ned Deily added the comment:

Unfortunately, the version of Tcl/Tk shipped by Apple in OS X is old and buggy.  Please install an updated version of Tcl/Tk 8.5, for example from ActiveState, as explained here:

https://www.python.org/download/mac/tcltk/

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25389>
_______________________________________

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: [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 15:05:52 2015
From: report at bugs.python.org (=?utf-8?q?Mart=C3=AD_Congost_Tapias?=)
Date: Tue, 13 Oct 2015 13:05:52 +0000
Subject: [issue25390] Can't define a typing.Union containing a
 typing.re.Pattern
In-Reply-To: <1444728467.55.0.552197008785.issue25390@psf.upfronthosting.co.za>
Message-ID: <1444741552.25.0.539959356917.issue25390@psf.upfronthosting.co.za>


Changes by Mart? Congost Tapias <marti.congost at whads.com>:


----------
components: +Library (Lib) -Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25390>
_______________________________________

From report at bugs.python.org  Tue Oct 13 15:09:10 2015
From: report at bugs.python.org (simon04)
Date: Tue, 13 Oct 2015 13:09:10 +0000
Subject: [issue9208] SMTPHandler in the logging module does not handle unicode
 strings
In-Reply-To: <1278627371.74.0.0567748809415.issue9208@psf.upfronthosting.co.za>
Message-ID: <1444741750.52.0.579933593501.issue9208@psf.upfronthosting.co.za>


simon04 added the comment:

I don't see why/how this should be fixed in Python 3.

Using the example from msg109621 and Python 3.5.0, I get:
--- 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: ()

The problem is that an SMTP message is constructed and non-ASCII characters are not escaped in SMTPHandler.emit. A robust fix would be to use email.mime.text.MIMEText instead:

msg = MIMEText(msg)
msg['Subject'] = self.getSubject(record)
msg['From'] = self.fromaddr
msg['To'] = ",".join(self.toaddrs)

----------
nosy: +simon04

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9208>
_______________________________________

From report at bugs.python.org  Tue Oct 13 15:13:47 2015
From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=)
Date: Tue, 13 Oct 2015 13:13:47 +0000
Subject: [issue25392] setup.py --quiet doesn't silence "no previously-included
 directories" warnings from MANIFEST.in
In-Reply-To: <1444736729.8.0.451337139853.issue25392@psf.upfronthosting.co.za>
Message-ID: <1444742027.47.0.162578352351.issue25392@psf.upfronthosting.co.za>


Ionel Cristian M?rie? added the comment:

I think those warning are about the fact that stuff that ain't in the packages list are added on PYTHONPATH. Not 100% sure tho.

Nothing to do with MANIFEST.in (not used for develop). Plus it's more specific to setuptools (where develop is implemented) than distutils.

----------
nosy: +ionelmc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25392>
_______________________________________

From report at bugs.python.org  Tue Oct 13 15:20:22 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 13 Oct 2015 13:20:22 +0000
Subject: [issue25381] Doc: Use of old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1444742422.77.0.980349516824.issue25381@psf.upfronthosting.co.za>


R. David Murray added the comment:

There's also the fact that the argument to raise can be an exception class, but the second element of sys.exc_info is still an instance of that class, which only occurred to me while reading your revised patch.

----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25381>
_______________________________________

From report at bugs.python.org  Tue Oct 13 15:36:24 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 13 Oct 2015 13:36:24 +0000
Subject: [issue9208] SMTPHandler in the logging module does not handle unicode
 strings
In-Reply-To: <1278627371.74.0.0567748809415.issue9208@psf.upfronthosting.co.za>
Message-ID: <1444743384.13.0.338761664594.issue9208@psf.upfronthosting.co.za>


R. David Murray added the comment:

In 3.4/3.5 a better fix would be to use EmailMessage instead of Message, and smtp.send_message instead of smtp.sendmail.  That will do the right thing, where "the right thing" is defined as defaulting to utf-8 for both headers and body.  A specific application might want other defaults, in which case one should proceed as Vinay suggests.

You could open a new issue requesting the use of EmailMessage/send_message in python3 logging if you want to pursue this.  Note that this would also allow unicode in the display name part of the addresses.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9208>
_______________________________________

From report at bugs.python.org  Tue Oct 13 15:38:30 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 13 Oct 2015 13:38:30 +0000
Subject: [issue9208] SMTPHandler in the logging module does not handle unicode
 strings
In-Reply-To: <1278627371.74.0.0567748809415.issue9208@psf.upfronthosting.co.za>
Message-ID: <1444743510.13.0.178995909422.issue9208@psf.upfronthosting.co.za>


R. David Murray added the comment:

To clarify: it will default to utf-8 encoded for email transport.  (Since email now supports SMTPUTF8, what I said could have meant defaulting to that, which it does *not* do.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9208>
_______________________________________

From report at bugs.python.org  Tue Oct 13 16:00:20 2015
From: report at bugs.python.org (Allan Lewis)
Date: Tue, 13 Oct 2015 14:00:20 +0000
Subject: [issue25391] difflib.SequenceMatcher(...).ratio gives
 bad/wrong/unexpected low value with repetitious strings
In-Reply-To: <1444734460.53.0.30170524569.issue25391@psf.upfronthosting.co.za>
Message-ID: <1444744820.1.0.678680720191.issue25391@psf.upfronthosting.co.za>


Changes by Allan Lewis <allanlewis99 at gmail.com>:


----------
nosy: +Allan Lewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25391>
_______________________________________

From report at bugs.python.org  Tue Oct 13 16:03:08 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 13 Oct 2015 14:03:08 +0000
Subject: [issue25381] Doc: Use of old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1444744988.95.0.337906406969.issue25381@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Actually what I intend is that the exception object passed to raise is the exception instance raise finally throws (what is stored in the second variable). So it seems wise not to do any more for me. A single sentence has lead to confusion, not to mention more.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25381>
_______________________________________

From report at bugs.python.org  Tue Oct 13 16:05:25 2015
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 13 Oct 2015 14:05:25 +0000
Subject: [issue25392] setup.py --quiet doesn't silence "no previously-included
 directories" warnings from MANIFEST.in
In-Reply-To: <1444736729.8.0.451337139853.issue25392@psf.upfronthosting.co.za>
Message-ID: <1444745125.23.0.683237102641.issue25392@psf.upfronthosting.co.za>


Ned Batchelder added the comment:

You are right that "develop" is from setuptools.  The same messages appear with "sdist":

    $ python setup.py --quiet sdist
    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'

----------

_______________________________________
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: [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 16:50:11 2015
From: report at bugs.python.org (Shubham Dash)
Date: Tue, 13 Oct 2015 14:50:11 +0000
Subject: [issue1353344] python.desktop
Message-ID: <1444747811.21.0.235218296153.issue1353344@psf.upfronthosting.co.za>


Changes by Shubham Dash <shubham.ddash at gmail.com>:


Added file: http://bugs.python.org/file40768/python.desktop

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1353344>
_______________________________________

From report at bugs.python.org  Tue Oct 13 17:40:37 2015
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 13 Oct 2015 15:40:37 +0000
Subject: [issue21159] configparser.InterpolationMissingOptionError is not very
 intuitive
In-Reply-To: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za>
Message-ID: <1444750837.27.0.370876758645.issue21159@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

The failure is in the configglue test suite, but apparently also kazan and qutebrowser are also affected by this change.  In the Launchpad bug there's a link to a librarian build log result.

The problem is that doing the .get() requires that subclasses implement a compatible API, which wasn't required previous to this change.  But apparently adding the fallback argument to the subclass's .get() doesn't entirely fix the problem, it leads to other failures.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21159>
_______________________________________

From report at bugs.python.org  Tue Oct 13 17:42:47 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 13 Oct 2015 15:42:47 +0000
Subject: [issue25391] difflib.SequenceMatcher(...).ratio gives
 bad/wrong/unexpected low value with repetitious strings
In-Reply-To: <1444734460.53.0.30170524569.issue25391@psf.upfronthosting.co.za>
Message-ID: <1444750967.03.0.813674095696.issue25391@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25391>
_______________________________________

From report at bugs.python.org  Tue Oct 13 17:54:36 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 13 Oct 2015 15:54:36 +0000
Subject: [issue25390] Can't define a typing.Union containing a
 typing.re.Pattern
In-Reply-To: <1444728467.55.0.552197008785.issue25390@psf.upfronthosting.co.za>
Message-ID: <1444751676.87.0.766747617334.issue25390@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Confirmed. The failure is because Pattern is _TypeAlias, which is not a type. But it should be allowed. I'll think of something. (Does mypy accept this?)

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25390>
_______________________________________

From report at bugs.python.org  Tue Oct 13 17:54:58 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 13 Oct 2015 15:54:58 +0000
Subject: [issue25390] Can't define a typing.Union containing a
 typing.re.Pattern
In-Reply-To: <1444728467.55.0.552197008785.issue25390@psf.upfronthosting.co.za>
Message-ID: <1444751698.12.0.302861366849.issue25390@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
assignee:  -> gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25390>
_______________________________________

From report at bugs.python.org  Tue Oct 13 18:14:01 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 13 Oct 2015 16:14:01 +0000
Subject: [issue21159] configparser.InterpolationMissingOptionError is not very
 intuitive
In-Reply-To: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za>
Message-ID: <1444752841.67.0.548755827985.issue21159@psf.upfronthosting.co.za>


R. David Murray added the comment:

OK, so I guess it should be backed out in 3.4.  But the since the patch does not change the signature of get, it seems like it is a legitimate change for 3.5.  It is using the public API, after all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21159>
_______________________________________

From report at bugs.python.org  Tue Oct 13 18:16:33 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 13 Oct 2015 16:16:33 +0000
Subject: [issue21159] configparser.InterpolationMissingOptionError is not very
 intuitive
In-Reply-To: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za>
Message-ID: <1444752993.14.0.775684667292.issue21159@psf.upfronthosting.co.za>


R. David Murray added the comment:

Or are you saying the existing code is actually depending on the old value of rawval, which is what ?ukasz was worried about?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21159>
_______________________________________

From report at bugs.python.org  Tue Oct 13 18:18:38 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 13 Oct 2015 16:18:38 +0000
Subject: [issue21159] configparser.InterpolationMissingOptionError is not very
 intuitive
In-Reply-To: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za>
Message-ID: <1444753118.29.0.0706726654596.issue21159@psf.upfronthosting.co.za>


R. David Murray added the comment:

By the way, I won't argue a lot if you say we should go for the strict backward compatibility view even in 3.5, I'm more raising the question.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21159>
_______________________________________

From report at bugs.python.org  Tue Oct 13 19:07:31 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 13 Oct 2015 17:07:31 +0000
Subject: [issue25385] Spurious warning when compiling extension module
In-Reply-To: <1444671317.42.0.28476348382.issue25385@psf.upfronthosting.co.za>
Message-ID: <1444756051.62.0.720052897914.issue25385@psf.upfronthosting.co.za>


Steve Dower added the comment:

This should be fixed in numpy.distutils. The warning exists in distutils.msvccompiler, which is deprecated and only remains in case people were importing it directly (the only reference in the stdlib is the test suite).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25385>
_______________________________________

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: [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 19:37:28 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Oct 2015 17:37:28 +0000
Subject: [issue25385] Spurious warning when compiling extension module
In-Reply-To: <1444671317.42.0.28476348382.issue25385@psf.upfronthosting.co.za>
Message-ID: <1444757848.26.0.0108052578759.issue25385@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Do you have a reference or changeset to point to, so that the Numpy developers can understand easily what the issue is?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25385>
_______________________________________

From report at bugs.python.org  Tue Oct 13 19:40:14 2015
From: report at bugs.python.org (Chris Seto)
Date: Tue, 13 Oct 2015 17:40:14 +0000
Subject: [issue25394] CoroWrapper breaks gen.throw
In-Reply-To: <1444757549.53.0.051433336619.issue25394@psf.upfronthosting.co.za>
Message-ID: <1444758014.45.0.867996984889.issue25394@psf.upfronthosting.co.za>


Changes by Chris Seto <chriskseto at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file40770/corowrapper.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25394>
_______________________________________

From report at bugs.python.org  Tue Oct 13 20:01:47 2015
From: report at bugs.python.org (Tim Peters)
Date: Tue, 13 Oct 2015 18:01:47 +0000
Subject: [issue25391] difflib.SequenceMatcher(...).ratio gives
 bad/wrong/unexpected low value with repetitious strings
In-Reply-To: <1444734460.53.0.30170524569.issue25391@psf.upfronthosting.co.za>
Message-ID: <1444759307.74.0.61011312541.issue25391@psf.upfronthosting.co.za>


Tim Peters added the comment:

Do note that this is not an "edit distance" (like Levenshtein) algorithm.  It works as documented instead ;-) , searching (in effect recursively) for the leftmost longest contiguous matching blocks.  Both "leftmost" and "contiguous" are crucial to understanding what it does.

I expect you're most surprised by the 2nd example, comparing:

location,location,location
location.location,location

The longest contiguous matching block is "location,location", in the first string at slice 0:17 (leftmost!) and in the second string at slice 9:26.  That leaves a wholly unmatched ",location" at the end of the first string and a wholly unmatched "location." at the start of the second string.  That's why the ratio is so low.  We have a total of 17*2 = 34 matching characters (in the single matching block) out of 2*26 = 52 characters total, so the ratio is 34/52 ~= 0.65.

Had it searched for the _rightmost_ longest matching blocks instead, then the trailing "location,location" pieces of both strings would have matched first, and then the leading "location" pieces of both strings, giving a ratio of about 0.96 instead.  Indeed, that's essentially what happens in your 3rd example.

.quick_ratio() and .real_quick_ratio() use entirely different algorithms, and - again as documented - their only purpose is to give an upper bound on what .ratio() returns (but do so faster).

Anyway, a couple things to take from this:

1. Some apps really want an "edit distance" kind of algorithm instead.  I would welcome one, but nobody so far has volunteered to implement one.  "A problem" is that there are many such algorithms (e.g., computational biology has driven many developments in this area).

2. It's far too late to change what current difflib functions implement.  The primary use case for the "leftmost longest contiguous matches" design was to improve the quality (as perceived by human eyes) of diffs generated for text files containing code (like C or Python source code), and it works very well for that purpose most times.  It doesn't work well for all purposes at all times.  Note that "works well (as perceived by human eyes)" is largely subjective, so arguing about that won't get far ;-)

Since it's functioning as designed & documented, I'm closing this as "not a bug".  It may make sense to open a different "enhancement" issue instead asking for a different algorithm(s).

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25391>
_______________________________________

From report at bugs.python.org  Tue Oct 13 20:04:31 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Oct 2015 18:04:31 +0000
Subject: [issue24164] Support pickling objects with __new__ with keyword
 arguments with protocol 2+
In-Reply-To: <1431341390.51.0.0928642680419.issue24164@psf.upfronthosting.co.za>
Message-ID: <1444759471.53.0.75927116218.issue24164@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Documentation patch updated.

----------
Added file: http://bugs.python.org/file40771/pickle_new_ex_protocol_2_doc_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24164>
_______________________________________

From report at bugs.python.org  Tue Oct 13 20:11:44 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Oct 2015 18:11:44 +0000
Subject: [issue24164] Support pickling objects with __new__ with keyword
 arguments with protocol 2+
In-Reply-To: <1444759471.53.0.75927116218.issue24164@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYGg9bXPkm9NJ5E5FZXFi2shnQ7m_pLCCzd2TGmTDzjaA@mail.gmail.com>


STINNER Victor added the comment:

pickle_new_ex_protocol_2_doc_2.patch looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24164>
_______________________________________

From report at bugs.python.org  Tue Oct 13 20:14:58 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 13 Oct 2015 18:14:58 +0000
Subject: [issue25380] Incorrect protocol for the STACK_GLOBAL opcode
In-Reply-To: <1444636213.99.0.44021196254.issue25380@psf.upfronthosting.co.za>
Message-ID: <20151013181455.20777.28212@psf.io>


Roundup Robot added the comment:

New changeset e52f1fa2d10e by Serhiy Storchaka in branch '3.4':
Issue #25380: Fixed protocol for the STACK_GLOBAL opcode in
https://hg.python.org/cpython/rev/e52f1fa2d10e

New changeset 4115eabc3a6d by Serhiy Storchaka in branch '3.5':
Issue #25380: Fixed protocol for the STACK_GLOBAL opcode in
https://hg.python.org/cpython/rev/4115eabc3a6d

New changeset f584dadc640f by Serhiy Storchaka in branch 'default':
Issue #25380: Fixed protocol for the STACK_GLOBAL opcode in
https://hg.python.org/cpython/rev/f584dadc640f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25380>
_______________________________________

From report at bugs.python.org  Tue Oct 13 20:19:45 2015
From: report at bugs.python.org (Tim Peters)
Date: Tue, 13 Oct 2015 18:19:45 +0000
Subject: [issue25391] difflib.SequenceMatcher(...).ratio gives
 bad/wrong/unexpected low value with repetitious strings
In-Reply-To: <1444734460.53.0.30170524569.issue25391@psf.upfronthosting.co.za>
Message-ID: <1444760385.31.0.878056117427.issue25391@psf.upfronthosting.co.za>


Tim Peters added the comment:

BTW, the "leftmost longest contiguous" bit is messy to explain, so the main part of the docs don't explain it all (it's of no interest to 99.9% of users).  Instead it's formally defined in the .find_longest_match() docs:

"""
If isjunk was omitted or None, find_longest_match() returns (i, j, k) such that a[i:i+k] is equal to b[j:j+k], where alo <= i <= i+k <= ahi and blo <= j <= j+k <= bhi. For all (i', j', k') meeting those conditions, the additional conditions k >= k', i <= i', and if i == i', j <= j' are also met. In other words, of all maximal matching blocks, return one that starts earliest in a, and of all those maximal matching blocks that start earliest in a, return the one that starts earliest in b.
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25391>
_______________________________________

From report at bugs.python.org  Tue Oct 13 20:20:54 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 13 Oct 2015 18:20:54 +0000
Subject: [issue25382] pickletools.dis(): output memo id for MEMOIZE
In-Reply-To: <1444643828.19.0.0921700569142.issue25382@psf.upfronthosting.co.za>
Message-ID: <20151013182050.18370.85622@psf.io>


Roundup Robot added the comment:

New changeset d88526aa1b29 by Serhiy Storchaka in branch 'default':
Issue #25382: pickletools.dis() now outputs implicit memo index for the
https://hg.python.org/cpython/rev/d88526aa1b29

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25382>
_______________________________________

From report at bugs.python.org  Tue Oct 13 20:21:36 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Oct 2015 18:21:36 +0000
Subject: [issue25380] Incorrect protocol for the STACK_GLOBAL opcode
In-Reply-To: <1444636213.99.0.44021196254.issue25380@psf.upfronthosting.co.za>
Message-ID: <1444760496.28.0.702941608971.issue25380@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25380>
_______________________________________

From report at bugs.python.org  Tue Oct 13 20:24:15 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Oct 2015 18:24:15 +0000
Subject: [issue25382] pickletools.dis(): output memo id for MEMOIZE
In-Reply-To: <1444643828.19.0.0921700569142.issue25382@psf.upfronthosting.co.za>
Message-ID: <1444760655.98.0.0588263954009.issue25382@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25382>
_______________________________________

From report at bugs.python.org  Tue Oct 13 20:27:20 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 13 Oct 2015 18:27:20 +0000
Subject: [issue24164] Support pickling objects with __new__ with keyword
 arguments with protocol 2+
In-Reply-To: <1431341390.51.0.0928642680419.issue24164@psf.upfronthosting.co.za>
Message-ID: <20151013182717.3295.68307@psf.io>


Roundup Robot added the comment:

New changeset de982d8b7b15 by Serhiy Storchaka in branch 'default':
Issue #24164: Document changes to __getnewargs__ and __getnewargs_ex__.
https://hg.python.org/cpython/rev/de982d8b7b15

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24164>
_______________________________________

From report at bugs.python.org  Tue Oct 13 20:29:17 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Oct 2015 18:29:17 +0000
Subject: [issue24164] Support pickling objects with __new__ with keyword
 arguments with protocol 2+
In-Reply-To: <1431341390.51.0.0928642680419.issue24164@psf.upfronthosting.co.za>
Message-ID: <1444760957.17.0.293519879948.issue24164@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24164>
_______________________________________

From report at bugs.python.org  Tue Oct 13 20:44:08 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 13 Oct 2015 18:44:08 +0000
Subject: [issue25385] Spurious warning when compiling extension module
In-Reply-To: <1444671317.42.0.28476348382.issue25385@psf.upfronthosting.co.za>
Message-ID: <1444761848.03.0.911529440717.issue25385@psf.upfronthosting.co.za>


Steve Dower added the comment:

Issue #23970 added the new compiler class, but all that really changed is that the module name is now distutils._msvccompiler. You *still* shouldn't access it except through distutils.ccompiler.new_compiler(compiler='msvc'), which is how it always was.

I can't point to exactly where in numpy the issue is, but I'd guess it looks a lot like "import distutils.msvccompiler"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25385>
_______________________________________

From report at bugs.python.org  Tue Oct 13 20:56:46 2015
From: report at bugs.python.org (Jason Morawski)
Date: Tue, 13 Oct 2015 18:56:46 +0000
Subject: [issue14574] SocketServer doesn't handle client disconnects properly
In-Reply-To: <1334358462.67.0.980544384901.issue14574@psf.upfronthosting.co.za>
Message-ID: <1444762606.14.0.335134394463.issue14574@psf.upfronthosting.co.za>


Jason Morawski added the comment:

Found another issue with this in 2.7

If the socket.error gets raised from the call to self.wfile.flush(), then when self.wfile.close() is called, self.wfile.flush() is called a second time if self.wfile._wbuf is not empty. This will raise the socket.error again. Attaching a patch that explicitly clears the buffer when the socket.error occurs.

----------
nosy: +Jason Morawski
Added file: http://bugs.python.org/file40772/clear_buffer_on_error.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14574>
_______________________________________

From report at bugs.python.org  Tue Oct 13 21:35:43 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Oct 2015 19:35:43 +0000
Subject: [issue24980] Allow for providing 'on_new_thread' callback to
 'concurrent.futures.ThreadPoolExecutor'
In-Reply-To: <1441134792.06.0.689087897304.issue24980@psf.upfronthosting.co.za>
Message-ID: <1444764943.81.0.891085323294.issue24980@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24980>
_______________________________________

From report at bugs.python.org  Tue Oct 13 21:38:09 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Oct 2015 19:38:09 +0000
Subject: [issue24980] Allow for providing 'on_new_thread' callback to
 'concurrent.futures.ThreadPoolExecutor'
In-Reply-To: <1441134792.06.0.689087897304.issue24980@psf.upfronthosting.co.za>
Message-ID: <1444765089.36.0.48385244088.issue24980@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +bquinlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24980>
_______________________________________

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: [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:40:01 2015
From: report at bugs.python.org (Ben Finney)
Date: Tue, 13 Oct 2015 19:40:01 +0000
Subject: [issue25392] setup.py --quiet doesn't silence "no previously-included
 directories" warnings from MANIFEST.in
In-Reply-To: <1444736729.8.0.451337139853.issue25392@psf.upfronthosting.co.za>
Message-ID: <1444765201.79.0.0102635537154.issue25392@psf.upfronthosting.co.za>


Changes by Ben Finney <ben+python at benfinney.id.au>:


----------
nosy: +bignose

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25392>
_______________________________________

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: [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  Tue Oct 13 21:44:06 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Oct 2015 19:44:06 +0000
Subject: [issue25370] Add support of pickling very large bytes and str objects
 with protocol < 4
In-Reply-To: <1444507390.05.0.862514167793.issue25370@psf.upfronthosting.co.za>
Message-ID: <1444765446.86.0.973314387969.issue25370@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is preliminary patch. It doesn't include changes to tests. Some bigmem tests need to be changed.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file40774/pickle_large_strings.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25370>
_______________________________________

From report at bugs.python.org  Tue Oct 13 21:45:08 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 13 Oct 2015 19:45:08 +0000
Subject: [issue25395] SIGSEGV using json.tool
In-Reply-To: <1444765181.78.0.70980847428.issue25395@psf.upfronthosting.co.za>
Message-ID: <1444765508.83.0.24819423577.issue25395@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +serhiy.storchaka
stage:  -> needs patch
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25395>
_______________________________________

From report at bugs.python.org  Tue Oct 13 21:51:14 2015
From: report at bugs.python.org (Adam)
Date: Tue, 13 Oct 2015 19:51:14 +0000
Subject: [issue17908] Unittest runner needs an option to call gc.collect()
 after each test
In-Reply-To: <1367720444.87.0.21268529715.issue17908@psf.upfronthosting.co.za>
Message-ID: <1444765874.79.0.861660379856.issue17908@psf.upfronthosting.co.za>


Adam added the comment:

Any comments about this proposed patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17908>
_______________________________________

From report at bugs.python.org  Tue Oct 13 22:03:52 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Oct 2015 20:03:52 +0000
Subject: [issue17908] Unittest runner needs an option to call gc.collect()
 after each test
In-Reply-To: <1367720444.87.0.21268529715.issue17908@psf.upfronthosting.co.za>
Message-ID: <1444766632.6.0.290827976796.issue17908@psf.upfronthosting.co.za>


STINNER Victor added the comment:

While I like the idea of adding an option to force a garbage collection after running each time, I don't like how unittest is growing :-( It looks more and more like regrtest and I hate regrtest (I reworked its code recently to create a less ugly "libregrtes").

Once Antoine Pitrou proposed to add "plugins" to unittest. I agree that we need a gate between unittest and all other test frameworks: nose, py.test, testtools/testrepository/testr, etc.

Seriously, don't you think that something is wrong with such API?

def __init__(self, module='__main__', defaultTest=None, argv=None,
             testRunner=None, testLoader=loader.defaultTestLoader,
             exit=True, verbosity=1, failfast=None, catchbreak=None,
             buffer=None, warnings=None, *, tb_locals=False,
             gc_enabled=False):

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17908>
_______________________________________

From report at bugs.python.org  Tue Oct 13 22:14:57 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Oct 2015 20:14:57 +0000
Subject: [issue25395] SIGSEGV using json.tool
In-Reply-To: <1444765181.78.0.70980847428.issue25395@psf.upfronthosting.co.za>
Message-ID: <1444767297.03.0.0170985658345.issue25395@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Doesn't crash on 3.4.3. Crashes on 3.5.0. The crash is reproduced with Python-only implementation of json, therefore it is not related to json.

----------
nosy: +haypo
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25395>
_______________________________________

From report at bugs.python.org  Tue Oct 13 22:18:13 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Oct 2015 20:18:13 +0000
Subject: [issue25395] SIGSEGV using json.tool
In-Reply-To: <1444765181.78.0.70980847428.issue25395@psf.upfronthosting.co.za>
Message-ID: <1444767493.69.0.875600232072.issue25395@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Can you post a GDB traceback?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25395>
_______________________________________

From report at bugs.python.org  Tue Oct 13 22:23:32 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Oct 2015 20:23:32 +0000
Subject: [issue25395] SIGSEGV using json.tool
In-Reply-To: <1444765181.78.0.70980847428.issue25395@psf.upfronthosting.co.za>
Message-ID: <1444767812.29.0.0374579918876.issue25395@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

3.6.0a0 (de982d8b7b15)

#0  0x080e62a1 in _PyTrash_thread_destroy_chain () at Objects/object.c:2010
#1  0x080bf8b3 in frame_dealloc (f=f at entry=0x83f06e4) at Objects/frameobject.c:462
#2  0x080e3eef in _Py_Dealloc (op=op at entry=0x83f06e4) at Objects/object.c:1786
#3  0x081909c1 in fast_function (func=func at entry=0xb77f4154, pp_stack=pp_stack at entry=0xbfffe6ac, n=n at entry=0, na=na at entry=0, nk=nk at entry=0) at Python/ceval.c:4752
#4  0x0819102a in call_function (pp_stack=pp_stack at entry=0xbfffe6ac, oparg=oparg at entry=0) at Python/ceval.c:4677
#5  0x0818e1f7 in PyEval_EvalFrameEx (f=f at entry=0xb795f034, throwflag=throwflag at entry=0) at Python/ceval.c:3181
#6  0x081906e7 in _PyEval_EvalCodeWithName (_co=_co at entry=0xb77f00f8, globals=globals at entry=0xb798f734, locals=locals at entry=0xb798f734, args=args at entry=0x0, 
    argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, kwdefs=kwdefs at entry=0x0, 
    closure=closure at entry=0x0, name=name at entry=0x0, qualname=qualname at entry=0x0) at Python/ceval.c:3962
#7  0x0819080a in PyEval_EvalCodeEx (_co=_co at entry=0xb77f00f8, globals=globals at entry=0xb798f734, locals=locals at entry=0xb798f734, args=args at entry=0x0, 
    argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, kwdefs=kwdefs at entry=0x0, 
    closure=closure at entry=0x0) at Python/ceval.c:3983
#8  0x0819086d in PyEval_EvalCode (co=co at entry=0xb77f00f8, globals=globals at entry=0xb798f734, locals=locals at entry=0xb798f734) at Python/ceval.c:777
#9  0x08180503 in builtin_exec_impl (module=module at entry=0xb7a1e534, source=0xb77f00f8, globals=0xb798f734, locals=0xb798f734) at Python/bltinmodule.c:942
#10 0x08180688 in builtin_exec (module=module at entry=0xb7a1e534, args=args at entry=0xb78b784c) at Python/clinic/bltinmodule.c.h:275
#11 0x080e025c in PyCFunction_Call (func=func at entry=0xb7a1ecb4, args=args at entry=0xb78b784c, kwds=kwds at entry=0x0) at Objects/methodobject.c:109
#12 0x08190f18 in call_function (pp_stack=pp_stack at entry=0xbfffe97c, oparg=oparg at entry=2) at Python/ceval.c:4651
#13 0x0818e1f7 in PyEval_EvalFrameEx (f=f at entry=0xb79d4cac, throwflag=throwflag at entry=0) at Python/ceval.c:3181
#14 0x081906e7 in _PyEval_EvalCodeWithName (_co=0xb78b9028, globals=<optimized out>, locals=locals at entry=0x0, args=args at entry=0xb7a00e84, argcount=argcount at entry=5, 
    kws=kws at entry=0xb7a00e98, kwcount=kwcount at entry=0, defs=defs at entry=0xb78ba288, defcount=5, kwdefs=kwdefs at entry=0x0, closure=closure at entry=0x0, 
    name=name at entry=0xb78b83e8, qualname=qualname at entry=0xb78b83e8) at Python/ceval.c:3962
#15 0x08190a52 in fast_function (func=func at entry=0xb7925994, pp_stack=pp_stack at entry=0xbfffeb3c, n=n at entry=5, na=na at entry=5, nk=nk at entry=0) at Python/ceval.c:4760
#16 0x0819102a in call_function (pp_stack=pp_stack at entry=0xbfffeb3c, oparg=oparg at entry=5) at Python/ceval.c:4677
#17 0x0818e1f7 in PyEval_EvalFrameEx (f=f at entry=0xb7a00d1c, throwflag=throwflag at entry=0) at Python/ceval.c:3181
#18 0x081906e7 in _PyEval_EvalCodeWithName (_co=_co at entry=0xb78b9298, globals=globals at entry=0xb78b17dc, locals=locals at entry=0x0, args=args at entry=0xb79b83c8, 
    argcount=argcount at entry=2, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0xb78b7eb8, defcount=defcount at entry=1, kwdefs=kwdefs at entry=0x0, 
    closure=closure at entry=0x0, name=name at entry=0x0, qualname=qualname at entry=0x0) at Python/ceval.c:3962
#19 0x0819080a in PyEval_EvalCodeEx (_co=0xb78b9298, globals=globals at entry=0xb78b17dc, locals=locals at entry=0x0, args=args at entry=0xb79b83c8, argcount=2, 
    kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0xb78b7eb8, defcount=defcount at entry=1, kwdefs=0x0, closure=0x0) at Python/ceval.c:3983
#20 0x0820be82 in function_call (func=0xb7841454, arg=0xb79b83b4, kw=0x0) at Objects/funcobject.c:632
#21 0x080939ce in PyObject_Call (func=func at entry=0xb7841454, arg=arg at entry=0xb79b83b4, kw=kw at entry=0x0) at Objects/abstract.c:2147
#22 0x0807614a in RunModule (modname=modname at entry=0x8330308 L"json.tool", set_argv0=set_argv0 at entry=1) at Modules/main.c:208
#23 0x08076f56 in Py_Main (argc=argc at entry=5, argv=argv at entry=0x832f010) at Modules/main.c:709
#24 0x0805edb4 in main (argc=5, argv=0xbfffee84) at ./Programs/python.c:69

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25395>
_______________________________________

From report at bugs.python.org  Tue Oct 13 22:59:59 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Oct 2015 20:59:59 +0000
Subject: [issue17908] Unittest runner needs an option to call gc.collect()
 after each test
In-Reply-To: <1444766632.6.0.290827976796.issue17908@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZn9UewVKoCLMJ9nR=uqCi=GcdLjmYL4zHc+S3fRhFc0A@mail.gmail.com>


STINNER Victor added the comment:

Well, maybe we can add yet another parameter to all unittest classes
(push this change), but IMHO someone must rework the unittest API to
make it more extensible instead of adding more and more stuff in the
base API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17908>
_______________________________________

From report at bugs.python.org  Tue Oct 13 23:31:50 2015
From: report at bugs.python.org (eryksun)
Date: Tue, 13 Oct 2015 21:31:50 +0000
Subject: [issue25386] msvcrt_putch/msvcrt_putwch don't check the return value
 of _putch/_putwch
In-Reply-To: <1444693845.85.0.133666844386.issue25386@psf.upfronthosting.co.za>
Message-ID: <1444771910.57.0.063270926983.issue25386@psf.upfronthosting.co.za>


eryksun added the comment:

> It would be interesting to know under what circumstances these 
> functions can fail.

The CRT _put[w]ch and _get[w]ch[e] functions will fail when called in a process that doesn't have a console. (Except get[w]ch may succeed if it follows unget[w]ch.) This is the case when running under pythonw.exe if the process hasn't first attached to a console via AllocConsole() or AttachConsole(). It also applies to python.exe when run as a detached process (i.e. the creation flag DETACHED_PROCESS) or after having detached the console via FreeConsole(). 

Note that even though the docs for get[w]ch [1] and get[w]che [2] state that "[t]here is no error return", these functions actually do return an error value of [W]EOF. This has been the case since at least back to Windows NT. Maybe Steve Dower can shed light on why this is undocumented.

Here's an example, tested on 64-bit Windows 10 in Python 3.5. This example calls the console I/O functions using both msvcrt and ctypes. Since there's no attached console, an error is expected, except when calling ungetwch followed by getwch.

    import os
    import sys
    import subprocess

    cmds_msvcrt = [
        "import msvcrt; msvcrt.ungetwch('a'); msvcrt.getwch()",
        "import msvcrt; msvcrt.ungetwch('a'); msvcrt.ungetwch('a')",
        "import msvcrt; msvcrt.getwch()",
        "import msvcrt; msvcrt.putwch('a')",
    ]

    csetup = "import sys,ctypes; ucrt = ctypes.cdll.ucrtbase; "

    cmds_ctypes = [
        csetup + "ucrt._ungetwch(ord('a')); sys.exit(ucrt._getwch())",
        csetup + "ucrt._ungetwch(ord('a')); sys.exit(ucrt._ungetwch(ord('a')))",
        csetup + "sys.exit(ucrt._getwch())",
        csetup + "sys.exit(ucrt._putwch(ord('a')))",
    ]

    def test(cmds):
        pythonw = os.path.join(sys.prefix, 'pythonw.exe')
        return [subprocess.call([pythonw, '-c', cmd]) for cmd in cmds]
    
    
    >>> test(cmds_msvcrt)
    [0, 1, 0, 0]

    >>> test(cmds_ctypes)
    [97, 65535, 65535, 65535]

65535 is WEOF. 

[1]: https://msdn.microsoft.com/en-us/library/078sfkak
[2]: https://msdn.microsoft.com/en-us/library/kswce429

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25386>
_______________________________________

From report at bugs.python.org  Tue Oct 13 23:41:30 2015
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 13 Oct 2015 21:41:30 +0000
Subject: [issue25396] A Python runtime not could be located.
In-Reply-To: <1444765309.47.0.487032440124.issue25396@psf.upfronthosting.co.za>
Message-ID: <1444772490.06.0.374478580539.issue25396@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Sorry, this is not the appropriate place to look for help with this issue; it's not a bug with Python itself.  I'd suggest asking on a Mac help forum.  There was a similar question on python-list a few months ago, you might find some pointers in that thread: https://mail.python.org/pipermail/python-list/2015-May/691527.html

Good luck!

----------
nosy: +zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25396>
_______________________________________

From report at bugs.python.org  Tue Oct 13 23:42:26 2015
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 13 Oct 2015 21:42:26 +0000
Subject: [issue25093] New 3.5.0 failure in test_tcl on win7
In-Reply-To: <1442200639.15.0.127298727385.issue25093@psf.upfronthosting.co.za>
Message-ID: <1444772546.06.0.0199910889836.issue25093@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thank you for the patch, Serhiy.  I'm just sorry it took me so long to get it committed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25093>
_______________________________________

From report at bugs.python.org  Wed Oct 14 00:27:48 2015
From: report at bugs.python.org (Mike Frysinger)
Date: Tue, 13 Oct 2015 22:27:48 +0000
Subject: [issue19372] configure and compile problems with older CentOS releases
In-Reply-To: <1382585649.75.0.66347191102.issue19372@psf.upfronthosting.co.za>
Message-ID: <1444775268.37.0.695588449368.issue19372@psf.upfronthosting.co.za>


Mike Frysinger added the comment:

time to close then ?

----------
nosy: +vapier

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19372>
_______________________________________

From report at bugs.python.org  Wed Oct 14 00:28:54 2015
From: report at bugs.python.org (Mike Frysinger)
Date: Tue, 13 Oct 2015 22:28:54 +0000
Subject: [issue18148] Make of Python 3.2.2 fails on Solaris SPARC
In-Reply-To: <1370522977.23.0.850120192524.issue18148@psf.upfronthosting.co.za>
Message-ID: <1444775334.86.0.270776502063.issue18148@psf.upfronthosting.co.za>


Mike Frysinger added the comment:

if the current builds fail, please make sure to include the config.log file as that includes a cross-compile test for this setting

----------
nosy: +vapier

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18148>
_______________________________________

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: [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: [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: [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 03:25:01 2015
From: report at bugs.python.org (Peter Wirtz)
Date: Wed, 14 Oct 2015 01:25:01 +0000
Subject: [issue25400] robotparser doesn't return crawl delay for default entry
In-Reply-To: <1444785702.73.0.849541373226.issue25400@psf.upfronthosting.co.za>
Message-ID: <1444785901.06.0.565991567706.issue25400@psf.upfronthosting.co.za>


Peter Wirtz added the comment:

This fix breaks the unit tests though. I am not sure how to go about checking those as this would be my first contribution to python and an open source project in general.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25400>
_______________________________________

From report at bugs.python.org  Wed Oct 14 04:09:59 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Oct 2015 02:09:59 +0000
Subject: [issue24782] Merge 'configure extensions' into main IDLE config dialog
In-Reply-To: <1438549617.46.0.760286591646.issue24782@psf.upfronthosting.co.za>
Message-ID: <20151014020954.128836.48917@psf.io>


Roundup Robot added the comment:

New changeset 334dc1abc8af by Terry Jan Reedy in branch '2.7':
Issue #24782: Finish converting the Configure Extension dialog into a new
https://hg.python.org/cpython/rev/334dc1abc8af

New changeset 5647c61fb593 by Terry Jan Reedy in branch '3.4':
Issue #24782: Finish converting the Configure Extension dialog into a new
https://hg.python.org/cpython/rev/5647c61fb593

New changeset 6bce28fec911 by Terry Jan Reedy in branch '2.7':
Issue #24782: whitespace
https://hg.python.org/cpython/rev/6bce28fec911

New changeset 4ed0cc2b7c7c by Terry Jan Reedy in branch '3.4':
Issue #24782: whitespace
https://hg.python.org/cpython/rev/4ed0cc2b7c7c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24782>
_______________________________________

From report at bugs.python.org  Wed Oct 14 04:36:44 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 14 Oct 2015 02:36:44 +0000
Subject: [issue24782] Merge 'configure extensions' into main IDLE config dialog
In-Reply-To: <1438549617.46.0.760286591646.issue24782@psf.upfronthosting.co.za>
Message-ID: <1444790204.06.0.523488607233.issue24782@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Nice. The only changes I had to make other than a doc change are 'Settings tab' to 'Extensions tab' and deletion of an line-ending space that got added in editing the extension doc string.  We both need to remember to strip trailing whitespace, as it causes changesets to be rejected when pushed. Pl

----------
assignee:  -> terry.reedy
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24782>
_______________________________________

From report at bugs.python.org  Wed Oct 14 07:59:02 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 14 Oct 2015 05:59:02 +0000
Subject: [issue25372] load_module() does not link submodule to parent package
In-Reply-To: <1444531632.83.0.513711320874.issue25372@psf.upfronthosting.co.za>
Message-ID: <1444802342.28.0.583121347024.issue25372@psf.upfronthosting.co.za>


Martin Panter added the comment:

My use case is for Readline auto-completion, to list submodules of a package given by the user, without importing anything unnecessary. The original code is compatible with Python 2, but I am also writing a patch for 3.6 that wouldn't need that. The original implementation is like this pseudocode:

def list_submodules(package):
    # Ensure it is a package before loading or importing it
    for name in parent_packages:
        loader = pkgutil.find_loader(name)
        assert loader.is_package()
    # Could call importlib.import_module(), but this seemed easier because I already have the loader:
    package = loader.load_module(name)
    # The only reason I want to load the module:
    search_path = package.__path__
    return pkgutil.iter_modules(search_path)

Thanks for your feedback Brett. I have changed over to importlib.import_module(), and will accept that this is just a quirk of the low level import stuff.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25372>
_______________________________________

From report at bugs.python.org  Wed Oct 14 09:07:49 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 14 Oct 2015 07:07:49 +0000
Subject: [issue24782] Merge 'configure extensions' into main IDLE config dialog
In-Reply-To: <1438549617.46.0.760286591646.issue24782@psf.upfronthosting.co.za>
Message-ID: <1444806469.65.0.717456207388.issue24782@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

There is one issue.  The window is wider now, I suspect because of the extension frame, which is wider than it need to be, at least for now.  I will try adjusting it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24782>
_______________________________________

From report at bugs.python.org  Wed Oct 14 10:01:45 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Oct 2015 08:01:45 +0000
Subject: [issue25399] Optimize bytearray % args
In-Reply-To: <1444783348.44.0.280990123345.issue25399@psf.upfronthosting.co.za>
Message-ID: <1444809705.98.0.405215855205.issue25399@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Microbenchmark result below.

Most operations are now between 2.5 and 5 times faster. %f is as-fast, probably because formatting a float is more expensive than copying bytes (raw estimation: 150 ns to format a single floating pointer number).

Common platform:
Timer: time.perf_counter
CPU model: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
Bits: int=32, long=64, long long=64, size_t=64, void*=64
CFLAGS: -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
Platform: Linux-4.1.6-200.fc22.x86_64-x86_64-with-fedora-22-Twenty_Two
Timer info: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09)
Python unicode implementation: PEP 393

Platform of campaign orig:
Python version: 3.6.0a0 (default:af34d0626fb4, Oct 14 2015, 09:51:04) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)]
Timer precision: 64 ns
Date: 2015-10-14 09:51:20
SCM: hg revision=af34d0626fb4 branch=default date="2015-10-14 09:47 +0200"

Platform of campaign no_copy:
Timer precision: 59 ns
Python version: 3.6.0a0 (default:2e9d9873d2be, Oct 14 2015, 09:49:28) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)]
Date: 2015-10-14 09:49:44
SCM: hg revision=2e9d9873d2be tag=tip branch=default date="2015-10-14 09:41 +0200"

-------------------------------------------------+-------------+--------------
use smaller buffer                               |        orig |       no_copy
-------------------------------------------------+-------------+--------------
fmt = bytearray(b"hello %s"); fmt % b"world"     |  656 ns (*) |  93 ns (-86%)
fmt = bytearray(b"hello %-100s"); fmt % b"world" |  686 ns (*) | 105 ns (-85%)
fmt = bytearray(b"x=%d"); fmt % 123              |  689 ns (*) | 112 ns (-84%)
fmt = bytearray(b"x=%f"); fmt % 1.2              |  976 ns (*) | 216 ns (-78%)
fmt = bytearray(b"x=%100d"); fmt % 123           |  870 ns (*) | 172 ns (-80%)
-------------------------------------------------+-------------+--------------
Total                                            | 3.88 us (*) | 698 ns (-82%)
-------------------------------------------------+-------------+--------------

------------------------------------------------------------+-------------+---------------
"hello %s" % long_string                                    |        orig |        no_copy
------------------------------------------------------------+-------------+---------------
fmt = bytearray(b"hello %s"); arg = b"x" * 10; fmt % arg    |  661 ns (*) |   93 ns (-86%)
fmt = bytearray(b"hello %s"); arg = b"x" * 100; fmt % arg   |  667 ns (*) |   93 ns (-86%)
fmt = bytearray(b"hello %s"); arg = b"x" * 10**3; fmt % arg |  982 ns (*) |  186 ns (-81%)
fmt = bytearray(b"hello %s"); arg = b"x" * 10**5; fmt % arg | 10.2 us (*) | 4.42 us (-57%)
------------------------------------------------------------+-------------+---------------
Total                                                       | 12.5 us (*) |  4.8 us (-62%)
------------------------------------------------------------+-------------+---------------

--------------------------------------------------+-------------+---------------
b"xxxxxx %s" % b"y"                               |        orig |        no_copy
--------------------------------------------------+-------------+---------------
fmt = bytearray(b"x" * 10 + b"%s"); fmt % b"y"    |  653 ns (*) |   88 ns (-86%)
fmt = bytearray(b"x" * 100 + b"%s"); fmt % b"y"   |  674 ns (*) |   94 ns (-86%)
fmt = bytearray(b"x" * 10**3 + b"%s"); fmt % b"y" | 1.09 us (*) |  213 ns (-80%)
fmt = bytearray(b"x" * 10**5 + b"%s"); fmt % b"y" | 21.4 us (*) | 8.47 us (-60%)
--------------------------------------------------+-------------+---------------
Total                                             | 23.8 us (*) | 8.87 us (-63%)
--------------------------------------------------+-------------+---------------

---------------------------------------------------------------------+-------------+--------
%f                                                                   |        orig | no_copy
---------------------------------------------------------------------+-------------+--------
n = 200; fmt = bytearray(b"%f" * n); arg = tuple([1.2]*n); fmt % arg | 32.2 us (*) | 32.3 us
---------------------------------------------------------------------+-------------+--------

-----------------------------------------------------------------------+-------------+---------------
%i                                                                     |        orig |        no_copy
-----------------------------------------------------------------------+-------------+---------------
n = 1; fmt = bytearray(b"%d" * n); arg = tuple([12345]*n); fmt % arg   |  678 ns (*) |  105 ns (-85%)
n = 5; fmt = bytearray(b"%d" * n); arg = tuple([12345]*n); fmt % arg   |  884 ns (*) |  296 ns (-66%)
n = 10; fmt = bytearray(b"%d" * n); arg = tuple([12345]*n); fmt % arg  | 1.13 us (*) |  531 ns (-53%)
n = 25; fmt = bytearray(b"%d" * n); arg = tuple([12345]*n); fmt % arg  | 1.85 us (*) | 1.24 us (-33%)
n = 100; fmt = bytearray(b"%d" * n); arg = tuple([12345]*n); fmt % arg | 5.62 us (*) |  4.8 us (-15%)
n = 200; fmt = bytearray(b"%d" * n); arg = tuple([12345]*n); fmt % arg | 10.6 us (*) |        10.8 us
n = 500; fmt = bytearray(b"%d" * n); arg = tuple([12345]*n); fmt % arg | 25.1 us (*) |  26.8 us (+7%)
-----------------------------------------------------------------------+-------------+---------------
Total                                                                  | 45.9 us (*) |        44.6 us
-----------------------------------------------------------------------+-------------+---------------

--------------------------------------------------------------------------+-------------+---------------
x=%i                                                                      |        orig |        no_copy
--------------------------------------------------------------------------+-------------+---------------
n = 1; fmt = bytearray(b"x=%d " * n); arg = tuple([12345]*n); fmt % arg   |  699 ns (*) |  123 ns (-82%)
n = 5; fmt = bytearray(b"x=%d " * n); arg = tuple([12345]*n); fmt % arg   |  943 ns (*) |  364 ns (-61%)
n = 10; fmt = bytearray(b"x=%d " * n); arg = tuple([12345]*n); fmt % arg  | 1.22 us (*) |  655 ns (-47%)
n = 25; fmt = bytearray(b"x=%d " * n); arg = tuple([12345]*n); fmt % arg  | 2.08 us (*) | 1.52 us (-27%)
n = 100; fmt = bytearray(b"x=%d " * n); arg = tuple([12345]*n); fmt % arg | 6.86 us (*) |        6.79 us
n = 200; fmt = bytearray(b"x=%d " * n); arg = tuple([12345]*n); fmt % arg | 12.6 us (*) |  13.3 us (+6%)
n = 500; fmt = bytearray(b"x=%d " * n); arg = tuple([12345]*n); fmt % arg | 29.7 us (*) |  32.4 us (+9%)
--------------------------------------------------------------------------+-------------+---------------
Total                                                                     | 54.1 us (*) |        55.2 us
--------------------------------------------------------------------------+-------------+---------------

-----------------------------------------------------------------------+-------------+---------------
%x                                                                     |        orig |        no_copy
-----------------------------------------------------------------------+-------------+---------------
n = 1; fmt = bytearray(b"%d" * n); arg = tuple([12345]*n); fmt % arg   |  677 ns (*) |  105 ns (-85%)
n = 5; fmt = bytearray(b"%d" * n); arg = tuple([12345]*n); fmt % arg   |  886 ns (*) |  297 ns (-67%)
n = 10; fmt = bytearray(b"%d" * n); arg = tuple([12345]*n); fmt % arg  | 1.13 us (*) |  530 ns (-53%)
n = 25; fmt = bytearray(b"%d" * n); arg = tuple([12345]*n); fmt % arg  | 1.85 us (*) | 1.24 us (-33%)
n = 100; fmt = bytearray(b"%d" * n); arg = tuple([12345]*n); fmt % arg | 5.64 us (*) | 4.82 us (-15%)
n = 200; fmt = bytearray(b"%d" * n); arg = tuple([12345]*n); fmt % arg | 10.7 us (*) |        10.8 us
n = 500; fmt = bytearray(b"%d" * n); arg = tuple([12345]*n); fmt % arg | 25.2 us (*) |  26.8 us (+7%)
-----------------------------------------------------------------------+-------------+---------------
Total                                                                  | 46.1 us (*) |        44.6 us
-----------------------------------------------------------------------+-------------+---------------

-----------------------------------------------------------------------------+-------------+---------------
x=%x                                                                         |        orig |        no_copy
-----------------------------------------------------------------------------+-------------+---------------
n = 1; fmt = bytearray(b"x=%x " * n); arg = tuple([0xabcdef]*n); fmt % arg   |  685 ns (*) |  120 ns (-82%)
n = 5; fmt = bytearray(b"x=%x " * n); arg = tuple([0xabcdef]*n); fmt % arg   |  916 ns (*) |  342 ns (-63%)
n = 10; fmt = bytearray(b"x=%x " * n); arg = tuple([0xabcdef]*n); fmt % arg  | 1.19 us (*) |  609 ns (-49%)
n = 25; fmt = bytearray(b"x=%x " * n); arg = tuple([0xabcdef]*n); fmt % arg  | 1.99 us (*) | 1.41 us (-29%)
n = 100; fmt = bytearray(b"x=%x " * n); arg = tuple([0xabcdef]*n); fmt % arg | 6.64 us (*) |        6.43 us
n = 200; fmt = bytearray(b"x=%x " * n); arg = tuple([0xabcdef]*n); fmt % arg | 11.9 us (*) |  12.7 us (+7%)
n = 500; fmt = bytearray(b"x=%x " * n); arg = tuple([0xabcdef]*n); fmt % arg | 28.2 us (*) |  30.5 us (+8%)
-----------------------------------------------------------------------------+-------------+---------------
Total                                                                        | 51.5 us (*) |        52.1 us
-----------------------------------------------------------------------------+-------------+---------------

-------------------------------------------------------+-------------+---------------
large int: %i                                          |        orig |        no_copy
-------------------------------------------------------+-------------+---------------
fmt = bytearray(b"%i"); arg = 10 ** 0 - 1; fmt % arg   |  651 ns (*) |   75 ns (-89%)
fmt = bytearray(b"%i"); arg = 10 ** 50 - 1; fmt % arg  |  810 ns (*) |  245 ns (-70%)
fmt = bytearray(b"%i"); arg = 10 ** 100 - 1; fmt % arg | 1.06 us (*) |  496 ns (-53%)
fmt = bytearray(b"%i"); arg = 10 ** 150 - 1; fmt % arg | 1.38 us (*) |  819 ns (-41%)
fmt = bytearray(b"%i"); arg = 10 ** 200 - 1; fmt % arg | 1.87 us (*) | 1.28 us (-32%)
-------------------------------------------------------+-------------+---------------
Total                                                  | 5.78 us (*) | 2.91 us (-50%)
-------------------------------------------------------+-------------+---------------

---------------------------------------------------------+-------------+---------------
large int: x=%i                                          |        orig |        no_copy
---------------------------------------------------------+-------------+---------------
fmt = bytearray(b"x=%i"); arg = 10 ** 0 - 1; fmt % arg   |  674 ns (*) |  103 ns (-85%)
fmt = bytearray(b"x=%i"); arg = 10 ** 50 - 1; fmt % arg  |  820 ns (*) |  254 ns (-69%)
fmt = bytearray(b"x=%i"); arg = 10 ** 100 - 1; fmt % arg | 1.07 us (*) |  503 ns (-53%)
fmt = bytearray(b"x=%i"); arg = 10 ** 150 - 1; fmt % arg |  1.4 us (*) |  824 ns (-41%)
---------------------------------------------------------+-------------+---------------
Total                                                    | 3.96 us (*) | 1.68 us (-58%)
---------------------------------------------------------+-------------+---------------

-------------------------+-------------+---------------
Summary                  |        orig |        no_copy
-------------------------+-------------+---------------
use smaller buffer       | 3.88 us (*) |  698 ns (-82%)
"hello %s" % long_string | 12.5 us (*) |  4.8 us (-62%)
b"xxxxxx %s" % b"y"      | 23.8 us (*) | 8.87 us (-63%)
%f                       | 32.2 us (*) |        32.3 us
%i                       | 45.9 us (*) |        44.6 us
x=%i                     | 54.1 us (*) |        55.2 us
%x                       | 46.1 us (*) |        44.6 us
x=%x                     | 51.5 us (*) |        52.1 us
large int: %i            | 5.78 us (*) | 2.91 us (-50%)
large int: x=%i          | 3.96 us (*) | 1.68 us (-58%)
-------------------------+-------------+---------------
Total                    |  280 us (*) |  248 us (-11%)
-------------------------+-------------+---------------

----------
Added file: http://bugs.python.org/file40778/bench_bytes_format.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25399>
_______________________________________

From report at bugs.python.org  Wed Oct 14 10:02:11 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Oct 2015 08:02:11 +0000
Subject: [issue25399] Optimize bytearray % args
In-Reply-To: <1444783348.44.0.280990123345.issue25399@psf.upfronthosting.co.za>
Message-ID: <20151014080207.55474.94259@psf.io>


Roundup Robot added the comment:

New changeset 03646293f1b3 by Victor Stinner in branch 'default':
Fix long_format_binary()
https://hg.python.org/cpython/rev/03646293f1b3

New changeset 6fe0050a2f52 by Victor Stinner in branch 'default':
Add use_bytearray attribute to _PyBytesWriter
https://hg.python.org/cpython/rev/6fe0050a2f52

New changeset f369b79c0153 by Victor Stinner in branch 'default':
Optimize bytearray % args
https://hg.python.org/cpython/rev/f369b79c0153

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25399>
_______________________________________

From report at bugs.python.org  Wed Oct 14 11:05:21 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Oct 2015 09:05:21 +0000
Subject: [issue25399] Optimize bytearray % args
In-Reply-To: <1444783348.44.0.280990123345.issue25399@psf.upfronthosting.co.za>
Message-ID: <1444813521.83.0.810757574262.issue25399@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25399>
_______________________________________

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: [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 11:10:17 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 14 Oct 2015 09:10:17 +0000
Subject: [issue25400] robotparser doesn't return crawl delay for default entry
In-Reply-To: <1444785702.73.0.849541373226.issue25400@psf.upfronthosting.co.za>
Message-ID: <1444813817.45.0.288185133312.issue25400@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25400>
_______________________________________

From report at bugs.python.org  Wed Oct 14 11:32:14 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Oct 2015 09:32:14 +0000
Subject: [issue25401] Optimize bytes.fromhex() and bytearray.fromhex()
In-Reply-To: <1444813760.4.0.225046078014.issue25401@psf.upfronthosting.co.za>
Message-ID: <1444815134.8.0.274992601919.issue25401@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It's between 2 and 3.5x faster.

It's 9% slower on short string (10 bytes for the output), but I consider that the speedup is more interesting than the slowdown on short strings.

RMicrobenchmark:

Common platform:
Platform: Linux-4.1.6-200.fc22.x86_64-x86_64-with-fedora-22-Twenty_Two
Timer: time.perf_counter
CFLAGS: -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
Python unicode implementation: PEP 393
Timer info: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09)
CPU model: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
Bits: int=32, long=64, long long=64, size_t=64, void*=64

Platform of campaign orig:
SCM: hg revision=90e41d965228 tag=tip branch=default date="2015-10-14 10:10 +0200"
Python version: 3.6.0a0 (default:90e41d965228, Oct 14 2015, 10:46:50) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)]
Date: 2015-10-14 10:47:05
Timer precision: 54 ns

Platform of campaign optim:
SCM: hg revision=90e41d965228+ tag=tip branch=default date="2015-10-14 10:10 +0200"
Python version: 3.6.0a0 (default:90e41d965228+, Oct 14 2015, 11:07:24) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)]
Date: 2015-10-14 11:09:53
Timer precision: 62 ns

-----------------------------------------+-------------+---------------
without spaces                           |        orig |          optim
-----------------------------------------+-------------+---------------
data = "AB" * 10; bytes.fromhex(data)    |  167 ns (*) |   181 ns (+9%)
data = "AB" * 100; bytes.fromhex(data)   |  621 ns (*) |  295 ns (-52%)
data = "AB" * 10**3; bytes.fromhex(data) | 5.15 us (*) | 1.65 us (-68%)
data = "AB" * 10**5; bytes.fromhex(data) |  500 us (*) |  147 us (-71%)
-----------------------------------------+-------------+---------------
Total                                    |  506 us (*) |  149 us (-70%)
-----------------------------------------+-------------+---------------

---------------------------------------------------+-------------+---------------
with 0.5 space                                     |        orig |          optim
---------------------------------------------------+-------------+---------------
data = "ABAB " * (10 // 2); bytes.fromhex(data)    |  179 ns (*) |         186 ns
data = "ABAB " * (100 // 2); bytes.fromhex(data)   |  659 ns (*) |  340 ns (-48%)
data = "ABAB " * (10**3 // 2); bytes.fromhex(data) | 5.48 us (*) | 2.19 us (-60%)
data = "ABAB " * (10**5 // 2); bytes.fromhex(data) |  529 us (*) |  194 us (-63%)
---------------------------------------------------+-------------+---------------
Total                                              |  536 us (*) |  196 us (-63%)
---------------------------------------------------+-------------+---------------

------------------------------------------+-------------+---------------
with 1 space                              |        orig |          optim
------------------------------------------+-------------+---------------
data = "AB " * 10; bytes.fromhex(data)    |  180 ns (*) |   191 ns (+6%)
data = "AB " * 100; bytes.fromhex(data)   |  710 ns (*) |  330 ns (-54%)
data = "AB " * 10**3; bytes.fromhex(data) | 5.77 us (*) | 1.99 us (-66%)
data = "AB " * 10**5; bytes.fromhex(data) |  559 us (*) |  177 us (-68%)
------------------------------------------+-------------+---------------
Total                                     |  565 us (*) |  179 us (-68%)
------------------------------------------+-------------+---------------

---------------+-------------+--------------
Summary        |        orig |         optim
---------------+-------------+--------------
without spaces |  506 us (*) | 149 us (-70%)
with 0.5 space |  536 us (*) | 196 us (-63%)
with 1 space   |  565 us (*) | 179 us (-68%)
---------------+-------------+--------------
Total          | 1.61 ms (*) | 525 us (-67%)
---------------+-------------+--------------

----------
Added file: http://bugs.python.org/file40780/bench_fromhex.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25401>
_______________________________________

From report at bugs.python.org  Wed Oct 14 11:32:43 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Oct 2015 09:32:43 +0000
Subject: [issue25401] Optimize bytes.fromhex() and bytearray.fromhex()
In-Reply-To: <1444813760.4.0.225046078014.issue25401@psf.upfronthosting.co.za>
Message-ID: <20151014093240.3285.75020@psf.io>


Roundup Robot added the comment:

New changeset 55d207a637ff by Victor Stinner in branch 'default':
Optimize bytes.fromhex() and bytearray.fromhex()
https://hg.python.org/cpython/rev/55d207a637ff

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25401>
_______________________________________

From report at bugs.python.org  Wed Oct 14 11:33:09 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Oct 2015 09:33:09 +0000
Subject: [issue25401] Optimize bytes.fromhex() and bytearray.fromhex()
In-Reply-To: <1444813760.4.0.225046078014.issue25401@psf.upfronthosting.co.za>
Message-ID: <1444815189.44.0.0635083497004.issue25401@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25401>
_______________________________________

From report at bugs.python.org  Wed Oct 14 12:05:53 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Oct 2015 10:05:53 +0000
Subject: [issue25401] Optimize bytes.fromhex() and bytearray.fromhex()
In-Reply-To: <1444813760.4.0.225046078014.issue25401@psf.upfronthosting.co.za>
Message-ID: <20151014100550.70994.38879@psf.io>


Roundup Robot added the comment:

New changeset 09e0533f3694 by Victor Stinner in branch 'default':
Issue #25401: Remove now unused hex_digit_to_int() function
https://hg.python.org/cpython/rev/09e0533f3694

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25401>
_______________________________________

From report at bugs.python.org  Wed Oct 14 12:14:13 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Oct 2015 10:14:13 +0000
Subject: [issue25370] Add support of pickling very large bytes and str objects
 with protocol < 4
In-Reply-To: <1444507390.05.0.862514167793.issue25370@psf.upfronthosting.co.za>
Message-ID: <1444817653.09.0.861375937484.issue25370@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Changed tests and fixed bugs.

Could anyone please test the patch with bigmem pickle tests? Tests need at least 32GB of memory, I have no such much memory.

----------
Added file: http://bugs.python.org/file40781/pickle_large_strings_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25370>
_______________________________________

From report at bugs.python.org  Wed Oct 14 12:14:25 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Oct 2015 10:14:25 +0000
Subject: [issue25370] Add support of pickling very large bytes and str objects
 with protocol < 4
In-Reply-To: <1444507390.05.0.862514167793.issue25370@psf.upfronthosting.co.za>
Message-ID: <1444817665.35.0.481859125688.issue25370@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file40774/pickle_large_strings.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25370>
_______________________________________

From report at bugs.python.org  Wed Oct 14 13:39:02 2015
From: report at bugs.python.org (Jung-chih Wei)
Date: Wed, 14 Oct 2015 11:39:02 +0000
Subject: [issue25338] urllib bypasses all hosts if proxyoverride includes an
 empty element
In-Reply-To: <1444280721.33.0.78593437261.issue25338@psf.upfronthosting.co.za>
Message-ID: <1444822742.5.0.620803693861.issue25338@psf.upfronthosting.co.za>


Jung-chih Wei added the comment:

I believe IE ignores the empty element because I must access the internet through proxy.
And please refer to http://mxr.mozilla.org/mozilla-central/source/toolkit/system/windowsproxy/nsWindowsSystemProxySettings.cpp#177, Firefox also ignores the empty element.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25338>
_______________________________________

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: [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: [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: [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 14:37:39 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Oct 2015 12:37:39 +0000
Subject: [issue25404] ssl.SSLcontext.load_dh_params() does not handle unicode
 filenames properly
In-Reply-To: <1444826187.38.0.734586543163.issue25404@psf.upfronthosting.co.za>
Message-ID: <1444826259.9.0.100028041364.issue25404@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
components: +Unicode, Windows
nosy: +ezio.melotti, haypo, paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25404>
_______________________________________

From report at bugs.python.org  Wed Oct 14 14:38:27 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Oct 2015 12:38:27 +0000
Subject: [issue25404] ssl.SSLcontext.load_dh_params() does not handle unicode
 filenames properly
In-Reply-To: <1444826187.38.0.734586543163.issue25404@psf.upfronthosting.co.za>
Message-ID: <1444826307.39.0.1830511593.issue25404@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Right. The workaround is to encode manually the filename:

filename = filename.encode(sys.getfilesystemencoding())

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25404>
_______________________________________

From report at bugs.python.org  Wed Oct 14 14:56:05 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 14 Oct 2015 12:56:05 +0000
Subject: [issue25372] load_module() does not link submodule to parent package
In-Reply-To: <1444531632.83.0.513711320874.issue25372@psf.upfronthosting.co.za>
Message-ID: <1444827365.57.0.223745847161.issue25372@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, once you've loaded the module and added it to the namespace of the parent package, you've imported it.  Since import_module is available in 2.7, it sounds like that satisfies your use case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25372>
_______________________________________

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: [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: [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 15:29:13 2015
From: report at bugs.python.org (Michael Schlenker)
Date: Wed, 14 Oct 2015 13:29:13 +0000
Subject: [issue25404] ssl.SSLcontext.load_dh_params() does not handle unicode
 filenames properly
In-Reply-To: <1444826187.38.0.734586543163.issue25404@psf.upfronthosting.co.za>
Message-ID: <1444829353.96.0.851584368158.issue25404@psf.upfronthosting.co.za>


Michael Schlenker added the comment:

Yes, the workaround works.

Would be nice if this could be fixed in a 2.7.11...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25404>
_______________________________________

From report at bugs.python.org  Wed Oct 14 15:31:50 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Oct 2015 13:31:50 +0000
Subject: [issue25384] Use _PyBytesWriter in the binascii module
In-Reply-To: <1444650015.66.0.169778133218.issue25384@psf.upfronthosting.co.za>
Message-ID: <20151014133144.2689.8422@psf.io>


Roundup Robot added the comment:

New changeset 32b17c3b3cf3 by Victor Stinner in branch 'default':
Issue #25384: Fix binascii.rledecode_hqx()
https://hg.python.org/cpython/rev/32b17c3b3cf3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25384>
_______________________________________

From report at bugs.python.org  Wed Oct 14 15:46:36 2015
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 14 Oct 2015 13:46:36 +0000
Subject: [issue23857] Make default HTTPS certificate verification setting
 configurable
In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za>
Message-ID: <1444830396.53.0.0250927992106.issue23857@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Re: platform_default - I'm not sure that's a good idea.  It hides what's actually happening in some hard to discover place (the code).  Probably EIBTI and just go with 'enable' and 'disable'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23857>
_______________________________________

From report at bugs.python.org  Wed Oct 14 16:20:17 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Oct 2015 14:20:17 +0000
Subject: [issue25406] OrderedDict.move_to_end may cause crash in python 3.5
In-Reply-To: <1444828803.02.0.823696555455.issue25406@psf.upfronthosting.co.za>
Message-ID: <1444832417.7.0.611789339543.issue25406@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +rhettinger, serhiy.storchaka
priority: normal -> critical
stage:  -> needs patch
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25406>
_______________________________________

From report at bugs.python.org  Wed Oct 14 16:27:14 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Oct 2015 14:27:14 +0000
Subject: [issue25406] OrderedDict.move_to_end may cause crash in python 3.5
In-Reply-To: <1444828803.02.0.823696555455.issue25406@psf.upfronthosting.co.za>
Message-ID: <1444832834.22.0.95944660201.issue25406@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25406>
_______________________________________

From report at bugs.python.org  Wed Oct 14 16:32:28 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 14 Oct 2015 14:32:28 +0000
Subject: [issue25405] User install of 3.5 removes py.exe from C:\Windows
In-Reply-To: <1444828075.41.0.296808473589.issue25405@psf.upfronthosting.co.za>
Message-ID: <1444833148.47.0.17629659667.issue25405@psf.upfronthosting.co.za>


Steve Dower added the comment:

Part of this will be the upgrade from RC, which will behave differently from the next upgrade to 3.5.1. But I have just made some fixes in how upgrading the launcher is handled, so there's a chance this is already fixed. But I'll test this scenario too.

Do you remember whether the launcher was originally installed for all users? At some point I made that the default to better deal with people who have 2.7/3.4 installed (that version of the launcher won't detect 3.5-32).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25405>
_______________________________________

From report at bugs.python.org  Wed Oct 14 16:40:36 2015
From: report at bugs.python.org (Snivy Pang)
Date: Wed, 14 Oct 2015 14:40:36 +0000
Subject: [issue25406] OrderedDict.move_to_end may cause crash in python 3.5
In-Reply-To: <1444828803.02.0.823696555455.issue25406@psf.upfronthosting.co.za>
Message-ID: <1444833636.21.0.0531019527818.issue25406@psf.upfronthosting.co.za>


Changes by Snivy Pang <slapaper.pku at gmail.com>:


----------
nosy: +Snivy Pang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25406>
_______________________________________

From report at bugs.python.org  Wed Oct 14 17:15:15 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Oct 2015 15:15:15 +0000
Subject: [issue25406] OrderedDict.move_to_end may cause crash in python 3.5
In-Reply-To: <1444828803.02.0.823696555455.issue25406@psf.upfronthosting.co.za>
Message-ID: <1444835715.92.0.828372117203.issue25406@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch that fixes the issue.

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25406>
_______________________________________

From report at bugs.python.org  Wed Oct 14 17:15:42 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Oct 2015 15:15:42 +0000
Subject: [issue25406] OrderedDict.move_to_end may cause crash in python 3.5
In-Reply-To: <1444828803.02.0.823696555455.issue25406@psf.upfronthosting.co.za>
Message-ID: <1444835742.91.0.81944940294.issue25406@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file40783/move_to_end_issue25406.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25406>
_______________________________________

From report at bugs.python.org  Wed Oct 14 17:20:20 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 14 Oct 2015 15:20:20 +0000
Subject: [issue23857] Make default HTTPS certificate verification setting
 configurable
In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za>
Message-ID: <1444836020.03.0.525206366561.issue23857@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The rationale behind "platform_default" relates to what we put in the default config file in the RPM. If enable/disable are the only options, then as soon as the first version ships with "disable" as the default, affected systems will *never* switch to being enabled by default unless the system administrator changes it.

By contrast, if we put "platform_default" in the default configuration, then inattentive sysadmins could theoretically eventually have their defaults switched to "enable" at some point.

We don't know yet if we'd ever upgrade the "platform_default" setting, but I think it's worthwhile to retain the option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23857>
_______________________________________

From report at bugs.python.org  Wed Oct 14 17:31:25 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Oct 2015 15:31:25 +0000
Subject: [issue25395] SIGSEGV using json.tool
In-Reply-To: <1444765181.78.0.70980847428.issue25395@psf.upfronthosting.co.za>
Message-ID: <1444836685.33.0.574501255298.issue25395@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Likely this issue is related to C implementation of OrderedDict. json.tool doesn't crash with --sort-keys and doesn't crash with Python implementation of OrderedDict.

The patch for similar issue25406 doesn't fix this issue.

----------
nosy: +eric.snow, rhettinger
priority: high -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25395>
_______________________________________

From report at bugs.python.org  Wed Oct 14 17:34:01 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 14 Oct 2015 15:34:01 +0000
Subject: [issue25406] OrderedDict.move_to_end may cause crash in python 3.5
In-Reply-To: <1444828803.02.0.823696555455.issue25406@psf.upfronthosting.co.za>
Message-ID: <1444836841.34.0.449414846095.issue25406@psf.upfronthosting.co.za>


Eric Snow added the comment:

@Serhiy, patch LGTM.  Thanks for taking care of it.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25406>
_______________________________________

From report at bugs.python.org  Wed Oct 14 17:34:19 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 14 Oct 2015 15:34:19 +0000
Subject: [issue25406] OrderedDict.move_to_end may cause crash in python 3.5
In-Reply-To: <1444828803.02.0.823696555455.issue25406@psf.upfronthosting.co.za>
Message-ID: <1444836859.75.0.130499744655.issue25406@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25406>
_______________________________________

From report at bugs.python.org  Wed Oct 14 17:38:03 2015
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 14 Oct 2015 15:38:03 +0000
Subject: [issue23857] Make default HTTPS certificate verification setting
 configurable
In-Reply-To: <1444836020.03.0.525206366561.issue23857@psf.upfronthosting.co.za>
Message-ID: <20151014113754.3b7882f0@limelight.wooz.org>


Barry A. Warsaw added the comment:

On Oct 14, 2015, at 03:20 PM, Nick Coghlan wrote:

>The rationale behind "platform_default" relates to what we put in the default
>config file in the RPM. If enable/disable are the only options, then as soon
>as the first version ships with "disable" as the default, affected systems
>will *never* switch to being enabled by default unless the system
>administrator changes it.
>
>By contrast, if we put "platform_default" in the default configuration, then
>inattentive sysadmins could theoretically eventually have their defaults
>switched to "enable" at some point.
>
>We don't know yet if we'd ever upgrade the "platform_default" setting, but I
>think it's worthwhile to retain the option.

We've consulted with the Ubuntu security team and have decided not to enable
it for Ubuntu 14.04 LTS.  For upgrades from there to newer releases, we won't
include the patch and will just enable it by default.  So for us,
platform_default doesn't make sense.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23857>
_______________________________________

From report at bugs.python.org  Wed Oct 14 17:57:50 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 14 Oct 2015 15:57:50 +0000
Subject: [issue25099] test_compileall fails when run by unprivileged user on
 installed Python
In-Reply-To: <1442205173.06.0.618332067063.issue25099@psf.upfronthosting.co.za>
Message-ID: <1444838270.91.0.0724792541933.issue25099@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25099>
_______________________________________

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: [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 18:20:20 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Oct 2015 16:20:20 +0000
Subject: [issue21165] Optimize str.translate() for replacement with substrings
 and non-ASCII strings
In-Reply-To: <1396861844.88.0.0543379452839.issue21165@psf.upfronthosting.co.za>
Message-ID: <1444839620.6.0.658543670815.issue21165@psf.upfronthosting.co.za>


STINNER Victor added the comment:

This issue was more a reminder for myself, and I'm not more interested to implement this optimization. The method is already fast enough.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21165>
_______________________________________

From report at bugs.python.org  Wed Oct 14 18:21:52 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Oct 2015 16:21:52 +0000
Subject: [issue8952] Doc/c-api/arg.rst: fix documentation of number formats
In-Reply-To: <1276079688.25.0.118377953399.issue8952@psf.upfronthosting.co.za>
Message-ID: <1444839712.81.0.22166557142.issue8952@psf.upfronthosting.co.za>


STINNER Victor added the comment:

This issue is now 5 years old and it doesn't contain much information. It's more a TODO item, and I'm not more interested to work on it. So I close the issue. If you want to work on the doc, please write a patch ;-)

----------
nosy: +haypo
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8952>
_______________________________________

From report at bugs.python.org  Wed Oct 14 18:26:58 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Oct 2015 16:26:58 +0000
Subject: [issue25406] OrderedDict.move_to_end may cause crash in python 3.5
In-Reply-To: <1444828803.02.0.823696555455.issue25406@psf.upfronthosting.co.za>
Message-ID: <1444840018.83.0.953267848012.issue25406@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your review Eric.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25406>
_______________________________________

From report at bugs.python.org  Wed Oct 14 18:27:21 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Oct 2015 16:27:21 +0000
Subject: [issue25406] OrderedDict.move_to_end may cause crash in python 3.5
In-Reply-To: <1444828803.02.0.823696555455.issue25406@psf.upfronthosting.co.za>
Message-ID: <20151014162353.20759.89141@psf.io>


Roundup Robot added the comment:

New changeset 88e6641c3dd3 by Serhiy Storchaka in branch '3.5':
Issue #25406: Fixed a bug in C implementation of OrderedDict.move_to_end()
https://hg.python.org/cpython/rev/88e6641c3dd3

New changeset 33d53a41daeb by Serhiy Storchaka in branch 'default':
Issue #25406: Fixed a bug in C implementation of OrderedDict.move_to_end()
https://hg.python.org/cpython/rev/33d53a41daeb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25406>
_______________________________________

From report at bugs.python.org  Wed Oct 14 18:29:07 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Oct 2015 16:29:07 +0000
Subject: [issue25210] Special-case NoneType() in do_richcompare()
In-Reply-To: <1442900927.33.0.98928488186.issue25210@psf.upfronthosting.co.za>
Message-ID: <20151014162905.97714.30596@psf.io>


Roundup Robot added the comment:

New changeset 0238eafb68da by Victor Stinner in branch 'default':
Issue #25210: Change error message of do_richcompare()
https://hg.python.org/cpython/rev/0238eafb68da

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25210>
_______________________________________

From report at bugs.python.org  Wed Oct 14 18:29:26 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Oct 2015 16:29:26 +0000
Subject: [issue25210] Special-case NoneType() in do_richcompare()
In-Reply-To: <1442900927.33.0.98928488186.issue25210@psf.upfronthosting.co.za>
Message-ID: <1444840166.82.0.565646622061.issue25210@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> It looks like some of the example sessions in the documentation will become out of date. Not sure if that is a problem.

Ah yes, I updated them. Thanks for the review.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25210>
_______________________________________

From report at bugs.python.org  Wed Oct 14 18:33:57 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Oct 2015 16:33:57 +0000
Subject: [issue19058] test_sys.test_ioencoding_nonascii() fails with ASCII
 locale encoding
In-Reply-To: <1379712575.68.0.606220974648.issue19058@psf.upfronthosting.co.za>
Message-ID: <1444840437.31.0.636361172714.issue19058@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> What could you say about the recent patch Victor?

I'm not sure that it works in all cases. io.TextIOWrapper doesn't care to normalize the encoding name. You should use something like:

   encoding = codecs.lookup(encoding).name

Otherwise, the test can fail if you care one of the various aliases of each encoding. Example: "UTF-8" vs "utf8" vs "utf-8".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19058>
_______________________________________

From report at bugs.python.org  Wed Oct 14 18:35:15 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Oct 2015 16:35:15 +0000
Subject: [issue25339] sys.stdout.errors is set to "surrogateescape"
In-Reply-To: <1444287088.0.0.588605250096.issue25339@psf.upfronthosting.co.za>
Message-ID: <1444840515.76.0.20987001941.issue25339@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Sorry, I don't understand the issue. Do you consider that using surrogateescape is a bug?

Which behaviour do you expect?

Python 3.5 now uses surrogateescape by default for stdout and stderr when the locale is POSIX. I guess that you got the POSIX locale using "LANG=".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25339>
_______________________________________

From report at bugs.python.org  Wed Oct 14 18:50:04 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 14 Oct 2015 16:50:04 +0000
Subject: [issue23857] Make default HTTPS certificate verification setting
 configurable
In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za>
Message-ID: <1444841404.43.0.85708064187.issue23857@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Yeah, it's the extra 5 years on RHEL 7 that makes me wary. For anything with a shorter life cycle, letting the legacy setting age out likely makes more sense.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23857>
_______________________________________

From report at bugs.python.org  Wed Oct 14 19:02:57 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Oct 2015 17:02:57 +0000
Subject: [issue25339] sys.stdout.errors is set to "surrogateescape"
In-Reply-To: <1444287088.0.0.588605250096.issue25339@psf.upfronthosting.co.za>
Message-ID: <1444842177.55.0.684759503015.issue25339@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm not sure this is a bug, but it looks at least unexpected, that surrogateescape is used with non-ASCII encoding. For example my last test for issue19058 fails on POSIX locale in 3.5+, and it is not so easy to make it working.

May be change error handler to surrogateescape only if PYTHONIOENCODING is not specified?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25339>
_______________________________________

From report at bugs.python.org  Wed Oct 14 19:42:12 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Oct 2015 17:42:12 +0000
Subject: [issue25164] Windows default installation path is inconsistent
 between per-user and system-wide installation
In-Reply-To: <1442564482.39.0.225945260969.issue25164@psf.upfronthosting.co.za>
Message-ID: <20151014174208.70965.38277@psf.io>


Roundup Robot added the comment:

New changeset be92f6ce1e80 by Steve Dower in branch '3.5':
Issue #25164: Changes default all-users install directory to match per-user directory.
https://hg.python.org/cpython/rev/be92f6ce1e80

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25164>
_______________________________________

From report at bugs.python.org  Wed Oct 14 19:46:40 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 14 Oct 2015 17:46:40 +0000
Subject: [issue25164] Windows default installation path is inconsistent
 between per-user and system-wide installation
In-Reply-To: <1442564482.39.0.225945260969.issue25164@psf.upfronthosting.co.za>
Message-ID: <1444844800.86.0.13075186792.issue25164@psf.upfronthosting.co.za>


Steve Dower added the comment:

I don't think it will be a significant breaking change at this stage to update the default all-user install directory, since everyone *should* be resolving it through the registry keys or overriding it on installation. Upgrading from 3.5.0 will not change to the new directory, so it only affects new installs.

The change is that the directory is named "Python35" or "Python35-32" under either %ProgramFiles% or %LocalAppData%\Programs\Python. (This is not a change in the latter case.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25164>
_______________________________________

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: [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  Wed Oct 14 20:16:25 2015
From: report at bugs.python.org (Peter Wirtz)
Date: Wed, 14 Oct 2015 18:16:25 +0000
Subject: [issue25400] robotparser doesn't return crawl delay for default entry
In-Reply-To: <1444785702.73.0.849541373226.issue25400@psf.upfronthosting.co.za>
Message-ID: <1444846585.47.0.949644588261.issue25400@psf.upfronthosting.co.za>


Peter Wirtz added the comment:

On further inspection of the tests, it appears that the way in which the tests are written, a test case can only be tested for one useragent at a time. I will attempt to work on the tests so work correctly. Any advice would be much appreciated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25400>
_______________________________________

From report at bugs.python.org  Wed Oct 14 20:22:35 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 14 Oct 2015 18:22:35 +0000
Subject: [issue25400] robotparser doesn't return crawl delay for default entry
In-Reply-To: <1444785702.73.0.849541373226.issue25400@psf.upfronthosting.co.za>
Message-ID: <1444846955.45.0.270525752427.issue25400@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch Peter(and welcome to Python and open source development). I have a WIP patch to rewrite test_robotparser in a less magic way. So we can ignore test failures for now. I'll take a closer look to your patch.

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25400>
_______________________________________

From report at bugs.python.org  Wed Oct 14 20:35:14 2015
From: report at bugs.python.org (Peter Wirtz)
Date: Wed, 14 Oct 2015 18:35:14 +0000
Subject: [issue25400] robotparser doesn't return crawl delay for default entry
In-Reply-To: <1444785702.73.0.849541373226.issue25400@psf.upfronthosting.co.za>
Message-ID: <1444847714.71.0.723535846745.issue25400@psf.upfronthosting.co.za>


Peter Wirtz added the comment:

Ok, for the mean time, I reworked the test so it appears to test correctly and tests passes. There does seem to be some magic, so I do hope I did not overlook anything. Here is the new patch.

----------
Added file: http://bugs.python.org/file40784/robotparser_crawl_delay_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25400>
_______________________________________

From report at bugs.python.org  Wed Oct 14 22:12:38 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Oct 2015 20:12:38 +0000
Subject: [issue25339] sys.stdout.errors is set to "surrogateescape"
In-Reply-To: <1444287088.0.0.588605250096.issue25339@psf.upfronthosting.co.za>
Message-ID: <1444853558.17.0.847346836565.issue25339@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"it looks at least unexpected, that surrogateescape is used with non-ASCII encoding"

What do you mean by non-ASCII encoding? surrogateescape is used by all encodings for all OS operations on Python 3, like os.listdir(), even for UTF-8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25339>
_______________________________________

From report at bugs.python.org  Wed Oct 14 22:28:11 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Oct 2015 20:28:11 +0000
Subject: [issue25408] Consider dropping html5lib and spambayes from the
 default benchmark set
In-Reply-To: <1444845307.71.0.511849152884.issue25408@psf.upfronthosting.co.za>
Message-ID: <1444854491.64.0.435815491246.issue25408@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This all sounds good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25408>
_______________________________________

From report at bugs.python.org  Wed Oct 14 22:31:26 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 14 Oct 2015 20:31:26 +0000
Subject: [issue25408] Consider dropping html5lib and spambayes from the
 default benchmark set
In-Reply-To: <1444845307.71.0.511849152884.issue25408@psf.upfronthosting.co.za>
Message-ID: <1444854686.87.0.321248314278.issue25408@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25408>
_______________________________________

From report at bugs.python.org  Wed Oct 14 23:29:07 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 14 Oct 2015 21:29:07 +0000
Subject: [issue25023] time.strftime('%a'), ValueError: embedded null byte,
 in ko locale
In-Reply-To: <1441690327.52.0.627876952587.issue25023@psf.upfronthosting.co.za>
Message-ID: <1444858147.93.0.309054494373.issue25023@psf.upfronthosting.co.za>


Steve Dower added the comment:

I can confirm that this is fixed in an upcoming Windows update:

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.
>>> import locale, time
>>> locale.setlocale(locale.LC_ALL, 'ko')
'ko'
>>> time.strftime('%a')
'\uc218'
>>>

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25023>
_______________________________________

From report at bugs.python.org  Thu Oct 15 00:17:32 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 14 Oct 2015 22:17:32 +0000
Subject: [issue25164] Windows default installation path is inconsistent
 between per-user and system-wide installation
In-Reply-To: <1442564482.39.0.225945260969.issue25164@psf.upfronthosting.co.za>
Message-ID: <1444861052.38.0.718570137505.issue25164@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25164>
_______________________________________

From report at bugs.python.org  Thu Oct 15 01:14:24 2015
From: report at bugs.python.org (Nathaniel Manista)
Date: Wed, 14 Oct 2015 23:14:24 +0000
Subject: [issue18886] BytesGenerator does not handle 'binary' CTE correctly
In-Reply-To: <1377895050.78.0.441930672492.issue18886@psf.upfronthosting.co.za>
Message-ID: <1444864464.69.0.287595516084.issue18886@psf.upfronthosting.co.za>


Nathaniel Manista added the comment:

This is status:open but versions:3.3,3.4. Should 3.5 and 3.6 also be listed as being affected by this issue?

----------
nosy: +Nathaniel Manista

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18886>
_______________________________________

From report at bugs.python.org  Thu Oct 15 01:59:39 2015
From: report at bugs.python.org (Nathaniel Manista)
Date: Wed, 14 Oct 2015 23:59:39 +0000
Subject: [issue18886] BytesGenerator does not handle 'binary' CTE correctly
In-Reply-To: <1377895050.78.0.441930672492.issue18886@psf.upfronthosting.co.za>
Message-ID: <1444867179.55.0.811474048881.issue18886@psf.upfronthosting.co.za>


Nathaniel Manista added the comment:

Also what's this bug's relationship to 19003?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18886>
_______________________________________

From report at bugs.python.org  Thu Oct 15 02:57:00 2015
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 15 Oct 2015 00:57:00 +0000
Subject: [issue16113] SHA-3 (Keccak) support may need to be removed before 3.4
In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za>
Message-ID: <1444870620.17.0.659315138441.issue16113@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

SHA-3 is released.

http://www.nist.gov/manuscript-publication-search.cfm?pub_id=919061

Should we add it to Python 2.7.11, 3.4.4, 3.5.1 or just for 18 months away Python 3.6?. Since this is a security sensitive issue, I would vote for adding it to the maintained releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16113>
_______________________________________

From report at bugs.python.org  Thu Oct 15 03:01:03 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Oct 2015 01:01:03 +0000
Subject: [issue18886] BytesGenerator does not handle 'binary' CTE correctly
In-Reply-To: <1377895050.78.0.441930672492.issue18886@psf.upfronthosting.co.za>
Message-ID: <1444870863.15.0.14564651951.issue18886@psf.upfronthosting.co.za>


R. David Murray added the comment:

Just 3.6 at this point, since really support for CTE binary is a new feature (there may even be a separate issue saying that, in which case this one should be closed as a duplicate).  We don't auto-update the issue versions when a new release comes out.

Issue 19003 is a bug involving the handling of bytes payloads (but not binary CTE) and so is different.

----------
type: behavior -> enhancement
versions: +Python 3.6 -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18886>
_______________________________________

From report at bugs.python.org  Thu Oct 15 03:16:42 2015
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 15 Oct 2015 01:16:42 +0000
Subject: [issue16113] SHA-3 (Keccak) support may need to be removed before 3.4
In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za>
Message-ID: <1444871802.76.0.293599356921.issue16113@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Describing this as a "security sensitive issue" is being facile.  It's more appropriate to describe this as a "new feature", aka, something that does not go in after x.y.0 final.

Please only check this in to "default", aka 3.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16113>
_______________________________________

From report at bugs.python.org  Thu Oct 15 04:06:04 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 15 Oct 2015 02:06:04 +0000
Subject: [issue21165] Optimize str.translate() for replacement with substrings
 and non-ASCII strings
In-Reply-To: <1396861844.88.0.0543379452839.issue21165@psf.upfronthosting.co.za>
Message-ID: <1444874764.17.0.265663055298.issue21165@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

I actually have a patch (still requires a little cleanup) that makes translations for non-ASCII and 1-n translations substantially faster. I've been delaying posting it largely because it makes significant changes to str.maketrans so it returns a special mapping that can be used far more efficiently than Python dicts. The effects of this are:

1. str.maketrans takes a little longer to run (when mappings are defined outside the latin-1 range, it takes about 6x as much time), and technically, the runtime is unbounded. I'm using "Perfect Hashing" to make a chaining free lookup table, but this involves randomly generating the parameters until they produce a collision free set of mappings; the number of rounds of generation is probabilistically very small (IIRC, for pathological cases, you'd still have a >50% chance of success for any random set of parameters, so the odds of failing to map after more than a dozen or so attempts is infinitesimal)
2. The resulting object, while it obeys the contract for collections.abc.Mapping, is not a dict, nor is it mutable, which would be a backwards incompatible change.

Under the current design, the mapping uses ~2x the space as the old dict (largely because it actually stores the dict internally to preserve references and simplify basic lookups).

In exchange for the longer time to do str.maketrans and the slightly higher memory, it provides:

1. Improved runtime for ASCII->Unicode (and vice-versa) of roughly 15-20x
2. Similar improvements for 1-n translations (regardless of whether non-ASCII is involved)
3. In general, much more consistent translation performance; the variance based on the contents of the mapping and the contents of the string is much lower, making it behave more like the old Py2 str.translate (and Py3 bytes.translate); translation is almost always faster than any other approach, instead of being a pessimization.

I don't know how to float changes that would make fairly substantial changes to existing APIs though, so I'm not sure how to proceed. I'd like translation to be beneficial (the optimization made in #21118 didn't actually improve my use case of stripping diacritics to convert to ASCII equivalent characters from latin-1 and related characters), but I have no good solutions that don't mess around with the API (I'd considered trying to internally cache "compiled" translation tables like the re module does, but the tables are mutable dicts, so caching can't be based on identity, and can't use the dicts as keys, which makes it difficult).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21165>
_______________________________________

From report at bugs.python.org  Thu Oct 15 05:10:23 2015
From: report at bugs.python.org (Peter Wirtz)
Date: Thu, 15 Oct 2015 03:10:23 +0000
Subject: [issue21475] Support the Sitemap extension in robotparser
In-Reply-To: <1399858557.27.0.633505879036.issue21475@psf.upfronthosting.co.za>
Message-ID: <1444878623.74.0.159390576991.issue21475@psf.upfronthosting.co.za>


Peter Wirtz added the comment:

I would like to tackle this issue. Should I wait for issue25400 to be resolved first?

----------
nosy: +pwirtz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21475>
_______________________________________

From report at bugs.python.org  Thu Oct 15 07:48:01 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Oct 2015 05:48:01 +0000
Subject: [issue16113] SHA-3 (Keccak) support may need to be removed before 3.4
In-Reply-To: <1444871802.76.0.293599356921.issue16113@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbuMqUS8uNG7NyWgDmEXmQF+QNtHi=T0GhMkEn7ffBvrQ@mail.gmail.com>


STINNER Victor added the comment:

I agree with Larry. If this feature is super useful, we can consider adding
it to stable versions later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16113>
_______________________________________

From report at bugs.python.org  Thu Oct 15 07:50:57 2015
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 15 Oct 2015 05:50:57 +0000
Subject: [issue16113] SHA-3 (Keccak) support may need to be removed before 3.4
In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za>
Message-ID: <1444888257.45.0.254345257636.issue16113@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I should clarify, I don't speak for 2.7.  The rules there are a little different and it's up to Benjamin to decide.  But please don't add new features to 3.4 and 3.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16113>
_______________________________________

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: [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 08:27:36 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 15 Oct 2015 06:27:36 +0000
Subject: [issue16113] Add SHA-3 (Keccak) support
In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za>
Message-ID: <1444890456.5.0.421635315221.issue16113@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
priority: release blocker -> normal
resolution: fixed -> 
stage: commit review -> 
status: closed -> open
title: SHA-3 (Keccak) support may need to be removed before 3.4 -> Add SHA-3 (Keccak) support
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16113>
_______________________________________

From report at bugs.python.org  Thu Oct 15 09:00:23 2015
From: report at bugs.python.org (Wei Wu)
Date: Thu, 15 Oct 2015 07:00:23 +0000
Subject: [issue25403] urllib.parse.urljoin is broken in python 3.5
In-Reply-To: <1444823340.35.0.0533245258476.issue25403@psf.upfronthosting.co.za>
Message-ID: <1444892423.32.0.784818934579.issue25403@psf.upfronthosting.co.za>


Wei Wu added the comment:

It's a change made in 3.5 that resolution of relative URLs confirms to the RFC 3986. See https://bugs.python.org/issue22118 for details.

----------
nosy: +kilowu

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25403>
_______________________________________

From report at bugs.python.org  Thu Oct 15 09:05:48 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Oct 2015 07:05:48 +0000
Subject: [issue25403] urllib.parse.urljoin is broken in python 3.5
In-Reply-To: <1444823340.35.0.0533245258476.issue25403@psf.upfronthosting.co.za>
Message-ID: <1444892748.93.0.692245189822.issue25403@psf.upfronthosting.co.za>


STINNER Victor added the comment:

See also this change:

changeset:   95683:fc0e79387a3a
user:        Berker Peksag <berker.peksag at gmail.com>
date:        Thu Apr 16 02:31:14 2015 +0300
files:       Lib/test/test_urlparse.py Lib/urllib/parse.py Misc/NEWS
description:
Issue #23703: Fix a regression in urljoin() introduced in 901e4e52b20a.

Patch by Demian Brecht.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25403>
_______________________________________

From report at bugs.python.org  Thu Oct 15 09:06:42 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Oct 2015 07:06:42 +0000
Subject: [issue25403] urllib.parse.urljoin is broken in python 3.5
In-Reply-To: <1444823340.35.0.0533245258476.issue25403@psf.upfronthosting.co.za>
Message-ID: <1444892802.25.0.344700687747.issue25403@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +berker.peksag, martin.panter, orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25403>
_______________________________________

From report at bugs.python.org  Thu Oct 15 09:29:38 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Oct 2015 07:29:38 +0000
Subject: [issue25402] Accurater estimation of the number of digits in int to
 decimal string conversion
In-Reply-To: <1444822963.9.0.112952407665.issue25402@psf.upfronthosting.co.za>
Message-ID: <1444894178.01.0.0376546366855.issue25402@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25402>
_______________________________________

From report at bugs.python.org  Thu Oct 15 09:37:17 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 15 Oct 2015 07:37:17 +0000
Subject: [issue25403] urllib.parse.urljoin is broken in python 3.5
In-Reply-To: <1444823340.35.0.0533245258476.issue25403@psf.upfronthosting.co.za>
Message-ID: <1444894637.91.0.764985737133.issue25403@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +3.5regression

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25403>
_______________________________________

From report at bugs.python.org  Thu Oct 15 10:05:09 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Oct 2015 08:05:09 +0000
Subject: [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 10:23:39 2015
From: report at bugs.python.org (Wenzel Jakob)
Date: Thu, 15 Oct 2015 08:23:39 +0000
Subject: [issue25006] List pybind11 binding generator
In-Reply-To: <1441409694.33.0.221981890825.issue25006@psf.upfronthosting.co.za>
Message-ID: <1444897419.19.0.437888055324.issue25006@psf.upfronthosting.co.za>


Wenzel Jakob added the comment:

Hi,

just another ping regarding this ticket. Since the last message, pybind11 now has:

- Documentation on readthedocs: http://pybind11.readthedocs.org/en/latest/
- Continuous integration tests: https://travis-ci.org/wjakob/pybind11
- A first stable release: https://github.com/wjakob/pybind11/releases

It would be fantastic if the Python documentation referenced it as an option for binding C++ code to Python.

Thanks,
Wenzel

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25006>
_______________________________________

From report at bugs.python.org  Thu Oct 15 10:23:49 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 15 Oct 2015 08:23:49 +0000
Subject: [issue21475] Support the Sitemap extension in robotparser
In-Reply-To: <1399858557.27.0.633505879036.issue21475@psf.upfronthosting.co.za>
Message-ID: <1444897429.36.0.378947811515.issue21475@psf.upfronthosting.co.za>


Berker Peksag added the comment:

issue 25400 is not a blocker of this, so feel free to write a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21475>
_______________________________________

From report at bugs.python.org  Thu Oct 15 10:34:15 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Oct 2015 08:34:15 +0000
Subject: [issue25402] Accurater estimation of the number of digits in int to
 decimal string conversion
In-Reply-To: <1444822963.9.0.112952407665.issue25402@psf.upfronthosting.co.za>
Message-ID: <1444898055.42.0.417015131896.issue25402@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Currently, the code uses Py_ABS(Py_SIZE(x))*PyLong_SHIFT to estimate the upper-bound of the number of bits of the number x. It's a raw estimation, the difference can be up to 29 bits. We may try to compute the exact number of bits, x.bit_length().

Python 3.5 estimate the number of "decimalbase" (10**9) digits using:

def decimalbase_digits1(x):
    bits = size(x) * PyLong_SHIFT
    return 1 + bits // (3 * _PyLong_DECIMAL_SHIFT)

I wrote a test to compute how many digits are overallocated (and unused): 552961 for this function. I'm not sure that "1+" is needed, since 3.0 is already lower than log2(10) (3.32...). If we compute the exact number of bits using the Python 3.5 function, it's a little bit better:

def decimalbase_digits2(x):
    bits = x.bit_length()
    return 1 + bits // (3 * _PyLong_DECIMAL_SHIFT)

=> 546250 digits (1% less). You propose a better estimation:

def decimalbase_digits3(x):
    digits = size(x)
    d = (33 * _PyLong_DECIMAL_SHIFT) // (10 * PyLong_SHIFT - 33 * _PyLong_DECIMAL_SHIFT)
    return 1 + digits + digits // d

With your estimation, only 504243 are overallocated (9% less than Python 3.5 function). But why only using 2 digits for log2(10) estimation? We can more digits:

def decimalbase_digits4(x):
    bits = size(x) * PyLong_SHIFT
    return bits * 10000 // (33219 * _PyLong_DECIMAL_SHIFT)

=> 491908 digits (11% less)

According to my tests, the best function uses the number of bits and the better estimation of log2(10):

def new_decimalbase_digits5(x):
    bits = x.bit_length()
    return bits * 10000 // (33219 * _PyLong_DECIMAL_SHIFT)

=> 483424 digits (13% less)


See attached for my tests.

----------
Added file: http://bugs.python.org/file40786/estimate_decimalbase_digits.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25402>
_______________________________________

From report at bugs.python.org  Thu Oct 15 11:40:01 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Oct 2015 09:40:01 +0000
Subject: [issue25402] Accurater estimation of the number of digits in int to
 decimal string conversion
In-Reply-To: <1444822963.9.0.112952407665.issue25402@psf.upfronthosting.co.za>
Message-ID: <1444902001.43.0.929390391806.issue25402@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> But why only using 2 digits for log2(10) estimation?

Because the difference between 3 and 3.3 is 10%, and the difference between 3.3 and exact log2(10) is only 1%. Yes, we can use more digits, but the effect of any additional digit is decreased in geometric progression.

If use simple and fast formula that avoids integer multiplication overflow "digits + digits // d", the effect of additional precision is virtually vanished.

>>> PyLong_SHIFT, _PyLong_DECIMAL_SHIFT = 15, 4
>>> (3 * _PyLong_DECIMAL_SHIFT) // (1 * PyLong_SHIFT - 3 * _PyLong_DECIMAL_SHIFT)
4
>>> (33 * _PyLong_DECIMAL_SHIFT) // (10 * PyLong_SHIFT - 33 * _PyLong_DECIMAL_SHIFT)
7
>>> (33219 * _PyLong_DECIMAL_SHIFT) // (10000 * PyLong_SHIFT - 33219 * _PyLong_DECIMAL_SHIFT)
7

>>> PyLong_SHIFT, _PyLong_DECIMAL_SHIFT = 30, 9
>>> (3 * _PyLong_DECIMAL_SHIFT) // (1 * PyLong_SHIFT - 3 * _PyLong_DECIMAL_SHIFT)
9
>>> (33 * _PyLong_DECIMAL_SHIFT) // (10 * PyLong_SHIFT - 33 * _PyLong_DECIMAL_SHIFT)
99
>>> (332 * _PyLong_DECIMAL_SHIFT) // (100 * PyLong_SHIFT - 332 * _PyLong_DECIMAL_SHIFT)
249
>>> (3321 * _PyLong_DECIMAL_SHIFT) // (1000 * PyLong_SHIFT - 3321 * _PyLong_DECIMAL_SHIFT)
269
>>> (33219 * _PyLong_DECIMAL_SHIFT) // (10000 * PyLong_SHIFT - 33219 * _PyLong_DECIMAL_SHIFT)
290
>>> (332192 * _PyLong_DECIMAL_SHIFT) // (100000 * PyLong_SHIFT - 332192 * _PyLong_DECIMAL_SHIFT)
291
>>> (332192809 * _PyLong_DECIMAL_SHIFT) // (100000000 * PyLong_SHIFT - 332192809 * _PyLong_DECIMAL_SHIFT)
291

The best approximation with minimal denominator is 485/146.

>>> PyLong_SHIFT, _PyLong_DECIMAL_SHIFT = 15, 4
>>> (485 * _PyLong_DECIMAL_SHIFT) // (146 * PyLong_SHIFT - 485 * _PyLong_DECIMAL_SHIFT)
7
>>> PyLong_SHIFT, _PyLong_DECIMAL_SHIFT = 30, 9
>>> (485 * _PyLong_DECIMAL_SHIFT) // (146 * PyLong_SHIFT - 485 * _PyLong_DECIMAL_SHIFT)
291

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25402>
_______________________________________

From report at bugs.python.org  Thu Oct 15 12:21:27 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 15 Oct 2015 10:21:27 +0000
Subject: [issue25194] Opt-in motivations & affiliations page for core
 contributors
In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za>
Message-ID: <1444904487.96.0.16200630531.issue25194@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Additional notes for a revised preamble:

* it may be worth linking to the OpenHub contributor page to highlight the automatically generated list of active core contributors, and the fact that this page is designed to add the Motivations & Affiliations information that can't be readily extracted from existing public data sources

* a cross-link to the Experts Index for technical interests may be useful

* given the current scope limitations, it may be worth changing to "core developers" as the terminology, since we're not capturing other forms of contribution (e.g. issue triagers and user representatives in mailing list design discussions)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25194>
_______________________________________

From report at bugs.python.org  Thu Oct 15 12:49:20 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 15 Oct 2015 10:49:20 +0000
Subject: [issue25194] Opt-in motivations & affiliations page for core
 contributors
In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za>
Message-ID: <1444906160.18.0.929726338943.issue25194@psf.upfronthosting.co.za>


Berker Peksag added the comment:

> * it may be worth linking to the OpenHub contributor page to highlight the automatically generated list of active core contributors

+1 but that data is a bit outdated. Perhaps the GitHub mirror can be used as a more up-to-date data source: https://github.com/python/cpython/graphs/contributors?from=2015-01-01&to=2016-01-01&type=c

> * given the current scope limitations, it may be worth changing to "core developers" as the terminology, since we're not capturing other forms of contribution

+1

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25194>
_______________________________________

From report at bugs.python.org  Thu Oct 15 12:56:21 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Oct 2015 10:56:21 +0000
Subject: [issue25409] fnmatch.fnmatch normalizes slashes/backslashes on Windows
In-Reply-To: <1444889091.12.0.272630391848.issue25409@psf.upfronthosting.co.za>
Message-ID: <1444906581.59.0.405251861962.issue25409@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think the existing behavior is the desirable behavior, but in any case as you say it is too late to change it.  The docs should indeed be clarified by changing the wording to indicate that fnmatch calls normcase but fnmatchcase does not, with a link to normcase (which in turn documents the windows behavior).

----------
nosy: +r.david.murray
stage:  -> needs patch
versions: +Python 3.4, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25409>
_______________________________________

From report at bugs.python.org  Thu Oct 15 13:00:37 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 15 Oct 2015 11:00:37 +0000
Subject: [issue25210] Special-case NoneType() in do_richcompare()
In-Reply-To: <1442900927.33.0.98928488186.issue25210@psf.upfronthosting.co.za>
Message-ID: <1444906837.28.0.856302098089.issue25210@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Thanks!

----------
stage: patch review -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25210>
_______________________________________

From report at bugs.python.org  Thu Oct 15 13:04:24 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Oct 2015 11:04:24 +0000
Subject: [issue25402] More accurate estimation of the number of digits in int
 to decimal string conversion
In-Reply-To: <1444822963.9.0.112952407665.issue25402@psf.upfronthosting.co.za>
Message-ID: <1444907064.37.0.712810921962.issue25402@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
title: Accurater estimation of the number of digits in int to decimal string conversion -> More accurate estimation of the number of digits in int to decimal string conversion

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25402>
_______________________________________

From report at bugs.python.org  Thu Oct 15 13:55:44 2015
From: report at bugs.python.org (Christian Tanzer)
Date: Thu, 15 Oct 2015 11:55:44 +0000
Subject: [issue22005] datetime.__setstate__ fails decoding python2 pickle
In-Reply-To: <1405687792.76.0.689943587668.issue22005@psf.upfronthosting.co.za>
Message-ID: <1444910144.17.0.311597298326.issue22005@psf.upfronthosting.co.za>


Christian Tanzer added the comment:

IMNSHO, the problem lies in the Python 3 pickle.py and it is **not** restricted to datetime instances 
(for a detailed rambling see http://c-tanzer.at/en/breaking_py2_pickles_in_py3.html) .

In Python 2, 8-bit strings are used for text and for binary data. Well designed applications will use unicode for all text, but Python 2 itself forces some text to be 8-bit string, e.g., names of attributes, classes, and functions. In other words, **any 8-bit strings explicitly created by such an application will contain binary data.**

In Python 2, pickle.dump uses BINSTRING (and SHORT_BINSTRING) for 8-bit strings; Python 3 uses BINBYTES (and SHORT_BINBYTES) instead.

In Python 3, pickle.load should handle BINSTRING (and SHORT_BINSTRING) like this:

* convert ASCII values to `str`

* convert non-ASCII values to `bytes`

`bytes` is Python 3's equivalent to Python 2's 8-bit string! 

It is only because of the use of 8-bit strings for Python 2 names that the mapping to `str` is necessary but all such names are guaranteed to be ASCII!

I would propose to change `load_binstring` and `load_short_binstring` to call a function like::

    def _decode_binstring(self, value):
        # Used to allow strings from Python 2 to be decoded either as
        # bytes or Unicode strings.  This should be used only with the
        # BINSTRING and SHORT_BINSTRING opcodes.
        if self.encoding != "bytes":
            try :
                return value.decode("ASCII")
            except UnicodeDecodeError:
                pass
        return value

instead of the currently called `_decode_string`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22005>
_______________________________________

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: [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 15:04:47 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 15 Oct 2015 13:04:47 +0000
Subject: [issue25386] msvcrt_putch/msvcrt_putwch don't check the return value
 of _putch/_putwch
In-Reply-To: <1444693845.85.0.133666844386.issue25386@psf.upfronthosting.co.za>
Message-ID: <1444914287.12.0.0322535344653.issue25386@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

That's a great test, thanks.

If we were designing this from scratch, I agree that raising an exception is the right thing to do. But the questions is: can we change the behavior now?

I think it's unlikely that anyone is relying on these functions returning [W]EOF, and that raising an exception is unlikely to cause problems.

I'm curious: did you [Alexander] have some code where you're actually expecting an exception, or did you just stumble across this case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25386>
_______________________________________

From report at bugs.python.org  Thu Oct 15 15:21:54 2015
From: report at bugs.python.org (simon04)
Date: Thu, 15 Oct 2015 13:21:54 +0000
Subject: [issue25411] SMTPHandler in the logging module fails with unicode
 strings
In-Reply-To: <1444914126.08.0.971116617077.issue25411@psf.upfronthosting.co.za>
Message-ID: <1444915314.43.0.312153211169.issue25411@psf.upfronthosting.co.za>


Changes by simon04 <Simon.Legner at gmail.com>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25411>
_______________________________________

From report at bugs.python.org  Thu Oct 15 15:51:45 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Oct 2015 13:51:45 +0000
Subject: [issue25411] SMTPHandler in the logging module fails with unicode
 strings
In-Reply-To: <1444914126.08.0.971116617077.issue25411@psf.upfronthosting.co.za>
Message-ID: <1444917105.08.0.915796382743.issue25411@psf.upfronthosting.co.za>


R. David Murray added the comment:

This mostly looks good to me, Vinay.

Simon: did you intentionally omit the date header, and if so why?  (The smtp server normally adds one, but you can't really depend on that).  Adding it would look like:

  msg['Date'] = email.utils.localtime()

(Hmm.  I wonder if send_message should add Date header if there isn't one...)

----------
nosy: +vinay.sajip

_______________________________________
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: [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:12:59 2015
From: report at bugs.python.org (Sergey Shashkov)
Date: Thu, 15 Oct 2015 14:12:59 +0000
Subject: [issue25412] __floordiv__ in module fraction fails with TypeError
 instead of returning NotImplemented
In-Reply-To: <1444918194.04.0.71189202918.issue25412@psf.upfronthosting.co.za>
Message-ID: <1444918379.47.0.792770019605.issue25412@psf.upfronthosting.co.za>


Sergey Shashkov added the comment:

def __floordiv__(a, b):
        """a // b"""
        if isinstance(b, numbers.Complex):
            return math.floor(a / b)
        else:
            return NotImplemented

And the same for __mod__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25412>
_______________________________________

From report at bugs.python.org  Thu Oct 15 16:22:52 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Oct 2015 14:22:52 +0000
Subject: [issue25412] __floordiv__ in module fraction fails with TypeError
 instead of returning NotImplemented
In-Reply-To: <1444918194.04.0.71189202918.issue25412@psf.upfronthosting.co.za>
Message-ID: <1444918972.16.0.101114101072.issue25412@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +mark.dickinson

_______________________________________
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: [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 16:38:32 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Oct 2015 14:38:32 +0000
Subject: [issue25006] List pybind11 binding generator
In-Reply-To: <1441409694.33.0.221981890825.issue25006@psf.upfronthosting.co.za>
Message-ID: <1444919912.12.0.525254028644.issue25006@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

You could perhaps start by creating a PyPI entry for your package:
https://pypi.python.org/pypi?%3Aaction=search&term=pybind11&submit=search

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25006>
_______________________________________

From report at bugs.python.org  Thu Oct 15 16:55:24 2015
From: report at bugs.python.org (Wenzel Jakob)
Date: Thu, 15 Oct 2015 14:55:24 +0000
Subject: [issue25006] List pybind11 binding generator
In-Reply-To: <1441409694.33.0.221981890825.issue25006@psf.upfronthosting.co.za>
Message-ID: <1444920924.3.0.778227819323.issue25006@psf.upfronthosting.co.za>


Wenzel Jakob added the comment:

Dear Antoine,

I wonder if this makes sense, as pybind11 is a collection of C++ header files using the Python C API.

The library is meant to be used by other projects but does not generate any installable code by itself. (i.e. it isn't clear what pip install pybind11 should even do) I haven't seen any PyPI packages of this type, though I'm happy to be told otherwise.

Best,
Wenzel

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25006>
_______________________________________

From report at bugs.python.org  Thu Oct 15 16:59:11 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 15 Oct 2015 14:59:11 +0000
Subject: [issue25410] Clean up and fix OrderedDict
In-Reply-To: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za>
Message-ID: <1444921151.05.0.975716688216.issue25410@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

These all look good except for perhaps #5 which I need to look at a bit more for its effect on OD subclasses.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25410>
_______________________________________

From report at bugs.python.org  Thu Oct 15 17:27:16 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Oct 2015 15:27:16 +0000
Subject: [issue25412] __floordiv__ in module fraction fails with TypeError
 instead of returning NotImplemented
In-Reply-To: <1444918194.04.0.71189202918.issue25412@psf.upfronthosting.co.za>
Message-ID: <1444922836.01.0.525346452081.issue25412@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Can you please write a patch? See https://docs.python.org/devguide/

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25412>
_______________________________________

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: [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 18:01:53 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 15 Oct 2015 16:01:53 +0000
Subject: [issue25414] Bypass unnecessary size limit test from deques on builds
 with 64-bit numbers
In-Reply-To: <1444923376.04.0.306426728101.issue25414@psf.upfronthosting.co.za>
Message-ID: <1444924913.55.0.360688265066.issue25414@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
components: +Extension Modules
keywords: +patch
stage:  -> patch review
title: Drop unnecessary size limit test from deques on builds with 64-bit numbers -> Bypass unnecessary size limit test from deques on builds with 64-bit numbers
type:  -> performance
Added file: http://bugs.python.org/file40789/deque_limit_test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25414>
_______________________________________

From report at bugs.python.org  Thu Oct 15 18:04:14 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 15 Oct 2015 16:04:14 +0000
Subject: [issue25414] Bypass unnecessary size limit test from deques on builds
 with 64-bit numbers
In-Reply-To: <1444923376.04.0.306426728101.issue25414@psf.upfronthosting.co.za>
Message-ID: <1444925054.52.0.210254357371.issue25414@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


Added file: http://bugs.python.org/file40790/deque_limit_test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25414>
_______________________________________

From report at bugs.python.org  Thu Oct 15 18:04:26 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 15 Oct 2015 16:04:26 +0000
Subject: [issue25414] Bypass unnecessary size limit test from deques on builds
 with 64-bit numbers
In-Reply-To: <1444923376.04.0.306426728101.issue25414@psf.upfronthosting.co.za>
Message-ID: <1444925066.31.0.850334988941.issue25414@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


Removed file: http://bugs.python.org/file40789/deque_limit_test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25414>
_______________________________________

From report at bugs.python.org  Thu Oct 15 18:15:30 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Oct 2015 16:15:30 +0000
Subject: [issue25159] Regression in time to import a module
In-Reply-To: <1442556606.15.0.522584302018.issue25159@psf.upfronthosting.co.za>
Message-ID: <1444925730.55.0.462313688522.issue25159@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Importing a module looks slow to me. Importing a module which is a an *empty* .py file takes ~160 us.

$ python3 -I -m timeit -s "open('slow.py', 'wb').close(); import sys; import slow" "del sys.modules['slow']; import slow"
10000 loops, best of 3: 156 usec per loop

The difference betwen Python 3.4 and 3.5 is that enum.py imports indirectly more modules. The following two imports were added to types.py in Python 3.5:

import functools as _functools         
import collections.abc as _collections_abc

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25159>
_______________________________________

From report at bugs.python.org  Thu Oct 15 18:16:25 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Oct 2015 16:16:25 +0000
Subject: [issue25159] Regression in time to import a module
In-Reply-To: <1442556606.15.0.522584302018.issue25159@psf.upfronthosting.co.za>
Message-ID: <1444925785.88.0.480497114182.issue25159@psf.upfronthosting.co.za>


STINNER Victor added the comment:

$ 3.4/python -c "import sys; sys.modules.clear(); import enum; print(len(sys.modules))"
18

$ 3.5/python -c "import sys; sys.modules.clear(); import enum; print(len(sys.modules))"
22

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25159>
_______________________________________

From report at bugs.python.org  Thu Oct 15 18:30:54 2015
From: report at bugs.python.org (Wenzel Jakob)
Date: Thu, 15 Oct 2015 16:30:54 +0000
Subject: [issue25006] List pybind11 binding generator
In-Reply-To: <1441409694.33.0.221981890825.issue25006@psf.upfronthosting.co.za>
Message-ID: <1444926654.43.0.333073183591.issue25006@psf.upfronthosting.co.za>


Wenzel Jakob added the comment:

Never mind -- I made an entry for it.

See https://pypi.python.org/pypi/pybind11/1.0

Thanks,
Wenzel

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25006>
_______________________________________

From report at bugs.python.org  Thu Oct 15 18:40:17 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Oct 2015 16:40:17 +0000
Subject: [issue25006] List pybind11 binding generator
In-Reply-To: <1441409694.33.0.221981890825.issue25006@psf.upfronthosting.co.za>
Message-ID: <1444927217.53.0.148979836623.issue25006@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Yes, I think it doesn't hurt to advertise your project there.
As for the official Python docs, I can't answer -- someone who maintains them would have to chime in.

Perhaps you can also submit an addition to the packaging guide:
https://packaging.python.org/en/latest/extensions/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25006>
_______________________________________

From report at bugs.python.org  Thu Oct 15 19:56:42 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 15 Oct 2015 17:56:42 +0000
Subject: [issue22005] datetime.__setstate__ fails decoding python2 pickle
In-Reply-To: <1405687792.76.0.689943587668.issue22005@psf.upfronthosting.co.za>
Message-ID: <1444931802.01.0.646162206486.issue22005@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Christian,

I don't think your solution will work for date/time/datetime pickles.  There are many values for which pickle payload consists of bytes within 0-127 range.  IIUC, you propose to decode those to Python 3 strings using ASCII encoding.  This will in turn require accepting str type in date/time/datetime constructors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22005>
_______________________________________

From report at bugs.python.org  Thu Oct 15 19:58:55 2015
From: report at bugs.python.org (Gerrit Holl)
Date: Thu, 15 Oct 2015 17:58:55 +0000
Subject: [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:07:35 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Oct 2015 18:07:35 +0000
Subject: [issue25414] Bypass unnecessary size limit test from deques on builds
 with 64-bit numbers
In-Reply-To: <1444923376.04.0.306426728101.issue25414@psf.upfronthosting.co.za>
Message-ID: <1444932455.88.0.11245504619.issue25414@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

We can remove this test at all, it can never succeed on 32-bit platform. deque takes at least 4 bytes (PyObject*) per element. In 32-bit address space the maximal deque size is less than 2**32/4 = 2**30 that is much less than MAX_DEQUE_LEN = 2**31-1-3*64.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25414>
_______________________________________

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: [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  Thu Oct 15 20:36:14 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Oct 2015 18:36:14 +0000
Subject: [issue25159] Regression in time to import a module
In-Reply-To: <1442556606.15.0.522584302018.issue25159@psf.upfronthosting.co.za>
Message-ID: <1444934174.3.0.331008072139.issue25159@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, importing 4 additional modules can be a cause of the slowdown. Thanks Victor.

----------
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25159>
_______________________________________

From report at bugs.python.org  Thu Oct 15 20:37:56 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Oct 2015 18:37:56 +0000
Subject: [issue25416] Add encoding aliases from the (HTML5) Encoding Standard
In-Reply-To: <1444932787.73.0.313042926579.issue25416@psf.upfronthosting.co.za>
Message-ID: <1444934276.1.0.780768520174.issue25416@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
components: +Unicode
nosy: +ezio.melotti, haypo, lemburg, loewis
stage:  -> needs patch
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25416>
_______________________________________

From report at bugs.python.org  Thu Oct 15 21:51:18 2015
From: report at bugs.python.org (Peter Wirtz)
Date: Thu, 15 Oct 2015 19:51:18 +0000
Subject: [issue21475] Support the Sitemap extension in robotparser
In-Reply-To: <1399858557.27.0.633505879036.issue21475@psf.upfronthosting.co.za>
Message-ID: <1444938678.55.0.900060283166.issue21475@psf.upfronthosting.co.za>


Peter Wirtz added the comment:

Here is a patch that provides support for the Sitemap extension.

----------
keywords: +patch
Added file: http://bugs.python.org/file40791/robotparser_site_maps_v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21475>
_______________________________________

From report at bugs.python.org  Fri Oct 16 00:16:41 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 15 Oct 2015 22:16:41 +0000
Subject: [issue25415] I can create instances of io.IOBase
In-Reply-To: <1444931934.97.0.280840323098.issue25415@psf.upfronthosting.co.za>
Message-ID: <1444947401.87.0.0691246000567.issue25415@psf.upfronthosting.co.za>


Martin Panter added the comment:

?No public constructor? to me means that it is not defined how or if you can construct instances other than by the public subclasses. What do you expect to happen? How do you expect the public subclasses such as FileIO and BufferedReader to work if the base constructor does not work?

The other three base classes (RawIOBase, BufferedIOBase, TextIOBase) also say ?there is no public constructor?. However allowing custom subclasses of these is very useful, so I would actually be for removing these restrictions from the documentation, and instead saying that each constructor accepts no arguments.

----------
assignee:  -> docs at python
components: +Documentation, IO -Library (Lib)
nosy: +docs at python, martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25415>
_______________________________________

From report at bugs.python.org  Fri Oct 16 01:05:33 2015
From: report at bugs.python.org (Gerrit Holl)
Date: Thu, 15 Oct 2015 23:05:33 +0000
Subject: [issue25415] I can create instances of io.IOBase
In-Reply-To: <1444931934.97.0.280840323098.issue25415@psf.upfronthosting.co.za>
Message-ID: <1444950333.36.0.620009592675.issue25415@psf.upfronthosting.co.za>


Gerrit Holl added the comment:

When the documentation says there is no public constructor, I expected it would be impossible to create instances, as in:

TypeError: cannot create 'builtin_function_or_method' instances

Perhaps I misunderstand the documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25415>
_______________________________________

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: [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 02:21:04 2015
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 16 Oct 2015 00:21:04 +0000
Subject: [issue25417] Minor typo in Path.samefile docstring
In-Reply-To: <1444954626.12.0.126658123546.issue25417@psf.upfronthosting.co.za>
Message-ID: <1444954864.96.0.630468075959.issue25417@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25417>
_______________________________________

From report at bugs.python.org  Fri Oct 16 02:21:38 2015
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 16 Oct 2015 00:21:38 +0000
Subject: [issue25417] Minor typo in Path.samefile docstring
In-Reply-To: <1444954626.12.0.126658123546.issue25417@psf.upfronthosting.co.za>
Message-ID: <1444954898.4.0.308088183941.issue25417@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy:  -ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25417>
_______________________________________

From report at bugs.python.org  Fri Oct 16 04:19:30 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 16 Oct 2015 02:19:30 +0000
Subject: [issue25403] urllib.parse.urljoin is broken in python 3.5
In-Reply-To: <1444823340.35.0.0533245258476.issue25403@psf.upfronthosting.co.za>
Message-ID: <1444961970.86.0.0770764900897.issue25403@psf.upfronthosting.co.za>


Martin Panter added the comment:

It is true that 3.5 is meant to follow RFC 3986, which obsoletes RFC 1808 and specifies slightly different behaviour for abnormal cases. This change is documented under urljoin(), and also in ?What?s New in 3.5?. Pavel?s first case is one of these differences in the RFCs, and I don?t think it is a bug. According to <https://tools.ietf.org/html/rfc3986.html#section-5.2.4>,

?The remove_dot_segments algorithm respects [the base?s] hierarchy by removing extra dot-segments rather than treating them as an error or leaving them to be misinterpreted by dereference implementations.?

For Pavel?s second and third cases, RFC 3986 doesn?t cover them directly because the base URL is relative. The RFC only covers absolute base URLs, which start with a scheme like ?http:?. The documentation doesn?t really bless these cases either: ?Construct a full (?absolute?) URL?. However there is explicit support in the source code ("" in urllib.parse.uses_relative).

It looks like 3.5 is strict in following the RFC?s Remove Dot Segments algorithm. Step 2C says that for ?/../? or ?/..?, the parent segment is removed, but the input is always replaced with ?/?:

?a/..? ? ?/?
?a/../..? ? ?/..? ? ?/?

I would prefer a less strict interpretation of the spirit of the algorithm. Do not introduce a slash in the input if you did not remove one from the output buffer:

?a/..? ? empty URL
?a/../..? ? ?..? ? empty URL

Python 3.4 and earlier did not behave sensibly if you extend the relative URL:

>>> urljoin("a/", "..")
''
>>> urljoin("a/", "../..")
'..'
>>> urljoin("a/", "../../..")
''
>>> urljoin("a/", "../../../..")
'../'

Pavel, what behaviour would you expect in these cases? My empty URL interpretation, or perhaps a more sensible version of the Python 3.4 behaviour? What is your use case?

One related more serious (IMO) regression I noticed compared to 3.4, where the path becomes a host name:

>>> urljoin("file:///base", "/dummy/..//host/oops")
'file://host/oops'

----------
components:  -Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25403>
_______________________________________

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: [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 08:21:11 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 16 Oct 2015 06:21:11 +0000
Subject: [issue25414] Bypass unnecessary size limit test from deques on builds
 with 64-bit numbers
In-Reply-To: <1444923376.04.0.306426728101.issue25414@psf.upfronthosting.co.za>
Message-ID: <1444976471.99.0.906404983897.issue25414@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


Added file: http://bugs.python.org/file40793/deque_limit_remove.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25414>
_______________________________________

From report at bugs.python.org  Fri Oct 16 10:22:58 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Oct 2015 08:22:58 +0000
Subject: [issue25418] Minor markup issue in reference/datamodel docs
In-Reply-To: <1444976202.25.0.459794059719.issue25418@psf.upfronthosting.co.za>
Message-ID: <20151016082255.471.28484@psf.io>


Roundup Robot added the comment:

New changeset 389c78c2c031 by Berker Peksag in branch '3.4':
Issue #25418: Fix markup in object.__hash__ documentation
https://hg.python.org/cpython/rev/389c78c2c031

New changeset f56006107a4b by Berker Peksag in branch '3.5':
Issue #25418: Fix markup in object.__hash__ documentation
https://hg.python.org/cpython/rev/f56006107a4b

New changeset 0aaadc1c60fd by Berker Peksag in branch 'default':
Issue #25418: Fix markup in object.__hash__ documentation
https://hg.python.org/cpython/rev/0aaadc1c60fd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25418>
_______________________________________

From report at bugs.python.org  Fri Oct 16 10:24:01 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 16 Oct 2015 08:24:01 +0000
Subject: [issue25418] Minor markup issue in reference/datamodel docs
In-Reply-To: <1444976202.25.0.459794059719.issue25418@psf.upfronthosting.co.za>
Message-ID: <1444983841.91.0.380648153063.issue25418@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Good catch, thanks!

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25418>
_______________________________________

From report at bugs.python.org  Fri Oct 16 10:34:58 2015
From: report at bugs.python.org (Christian Tanzer)
Date: Fri, 16 Oct 2015 08:34:58 +0000
Subject: [issue22005] datetime.__setstate__ fails decoding python2 pickle
In-Reply-To: Your message of "Thu, 15 Oct 2015 17:56:42 +0000"
 <1444931802.01.0.646162206486.issue22005@psf.upfronthosting.co.za>
Message-ID: <E1Zn0TX-0008L0-E6@swing.co.at>


Christian Tanzer added the comment:

Alexander Belopolsky wrote at Thu, 15 Oct 2015 17:56:42 +0000:

> I don't think your solution will work for date/time/datetime pickles.
> There are many values for which pickle payload consists of bytes
> within 0-127 range.

Hmmmm.

> IIUC, you propose to decode those to Python 3
> strings using ASCII encoding.

Yes. There are too many BINSTRING instances that need to be Python 3
strings.

> This will in turn require accepting str
> type in date/time/datetime constructors.

These datetime... constructors are strange beasts already.

The documentation says that three integer arguments are required for
datetime.datetime but it accepts a single bytes argument anyway. I
agree that it would be much nicer if there was a
datetime.datetime.load method instead. Unfortunately, that would
require Guido's time machine to go back all the way to 2003 (at least).

So yes, the only practical solution is to accept a single str typed
argument (as long as it is ASCII only). An alternative would be to add
a dispatch table for loading functions to Python 3's pickle that would
be used by load_global. That would add indirection for the datetime
constructors but would allow support for other types requiring
arguments of type bytes.

The change I proposed in http://bugs.python.org/issue22005#msg253042
to fix the handling of binary 8-bit strings is still necessary.

To summarize:

IMHO the solution needs to be implemented in Python 3 ? otherwise
pickles with binary strings created by Python 2.x cannot be loaded in
Python 3. Changing the pickle implementation of Python 2 doesn't fix
existing pickles and couldn't fix the general problem of binary
strings, anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22005>
_______________________________________

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: [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: [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:01 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Oct 2015 16:42:01 +0000
Subject: [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: [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 18:42:41 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 16 Oct 2015 16:42:41 +0000
Subject: [issue25422] tokenize: add tests for multi-line strings
In-Reply-To: <1445013749.49.0.456758504402.issue25422@psf.upfronthosting.co.za>
Message-ID: <1445013761.49.0.35145993782.issue25422@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
title: tokenize: add test for multi-line strings -> tokenize: add tests for multi-line strings

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25422>
_______________________________________

From report at bugs.python.org  Fri Oct 16 19:13:16 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 Oct 2015 17:13:16 +0000
Subject: [issue25408] Consider dropping html5lib and spambayes from the
 default benchmark set
In-Reply-To: <1444845307.71.0.511849152884.issue25408@psf.upfronthosting.co.za>
Message-ID: <1445015596.21.0.162686557562.issue25408@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Fixed in changeset 22a5da25fa4e .

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25408>
_______________________________________

From report at bugs.python.org  Fri Oct 16 19:16:27 2015
From: report at bugs.python.org (Oscar Benjamin)
Date: Fri, 16 Oct 2015 17:16:27 +0000
Subject: [issue25412] __floordiv__ in module fraction fails with TypeError
 instead of returning NotImplemented
In-Reply-To: <1444918194.04.0.71189202918.issue25412@psf.upfronthosting.co.za>
Message-ID: <1445015787.79.0.809358928823.issue25412@psf.upfronthosting.co.za>


Oscar Benjamin added the comment:

You should test the change with number types that don't use the number tower e.g. Decimal, sympy, gmpy2, mpf, numpy arrays etc. Few non stdlib types use the number ABCs so testing against numbers.Complex may cause a change in behaviour.

----------
nosy: +oscarbenjamin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25412>
_______________________________________

From report at bugs.python.org  Fri Oct 16 19:29:25 2015
From: report at bugs.python.org (John Morrissey)
Date: Fri, 16 Oct 2015 17:29:25 +0000
Subject: [issue23735] Readline not adjusting width after resize with 6.3
In-Reply-To: <1426984974.32.0.405944458303.issue23735@psf.upfronthosting.co.za>
Message-ID: <1445016565.91.0.668729795225.issue23735@psf.upfronthosting.co.za>


Changes by John Morrissey <jwm at horde.net>:


----------
nosy: +johnmorr

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23735>
_______________________________________

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: [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: [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 19:35:47 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Oct 2015 17:35:47 +0000
Subject: [issue25423] Deprecate benchmarks that execute too quickly
In-Reply-To: <1445016719.35.0.429724365495.issue25423@psf.upfronthosting.co.za>
Message-ID: <1445016947.87.0.181154668914.issue25423@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I haven't seen that:

$ ./perf.py -f -b silent_logging `which python2.7` `which python3.4`
INFO:root:Automatically selected timer: time
Running silent_logging...
INFO:root:Running `/home/antoine/.local/bin/python3.4 ./performance/bm_logging.py -n 5 --timer time no_output`
INFO:root:Running `/usr/bin/python2.7 ./performance/bm_logging.py -n 5 --timer time no_output`

Report on Linux fsol 3.19.0-30-generic #34-Ubuntu SMP Fri Oct 2 22:08:41 UTC 2015 x86_64 x86_64
Total CPU cores: 4

### silent_logging ###
Min: 0.056003 -> 0.075588: 1.35x slower
Avg: 0.056043 -> 0.076493: 1.36x slower
Significant (t=-38.61)
Stddev: 0.00003 -> 0.00118: 47.2238x larger


In any case, if it runs too fast, we should simply increase the number of iterations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25423>
_______________________________________

From report at bugs.python.org  Fri Oct 16 20:14:07 2015
From: report at bugs.python.org (Sergey Shashkov)
Date: Fri, 16 Oct 2015 18:14:07 +0000
Subject: [issue25412] __floordiv__ in module fraction fails with TypeError
 instead of returning NotImplemented
In-Reply-To: <1444918194.04.0.71189202918.issue25412@psf.upfronthosting.co.za>
Message-ID: <1445019247.72.0.114955348979.issue25412@psf.upfronthosting.co.za>


Sergey Shashkov added the comment:

OK,

then we should not change numbers.py.

And in fractions.py:

def __floordiv__(a, b):
        """a // b"""
        if isinstance(b, numbers.Complex) or hasattr(b, '__rtruediv__'):
            fr = a / b
            if fr != NotImplemented:
                return math.floor(a / b)
            else:
                return NotImplemented
        else:
            return NotImplemented

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25412>
_______________________________________

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: [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 20:18:34 2015
From: report at bugs.python.org (Sergey Shashkov)
Date: Fri, 16 Oct 2015 18:18:34 +0000
Subject: [issue25412] __floordiv__ in module fraction fails with TypeError
 instead of returning NotImplemented
In-Reply-To: <1444918194.04.0.71189202918.issue25412@psf.upfronthosting.co.za>
Message-ID: <1445019514.98.0.929892360752.issue25412@psf.upfronthosting.co.za>


Sergey Shashkov added the comment:

Bad idea, just


def __floordiv__(a, b):
        """a // b"""
        if isinstance(b, numbers.Complex):
            return math.floor(a / b)
        else:
            return NotImplemented

If b is inherited from number, real, complex, Fraction and etc, then a of type Fraction knows, how do make a division.
Otherwise may be b has __rfloordiv__, that khows how to be divided by Fraction.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25412>
_______________________________________

From report at bugs.python.org  Fri Oct 16 20:22:27 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 Oct 2015 18:22:27 +0000
Subject: [issue25234] test_eintr.test_os_open hangs under Xcode 7
In-Reply-To: <1443210079.4.0.780575467942.issue25234@psf.upfronthosting.co.za>
Message-ID: <1445019747.8.0.0574475623189.issue25234@psf.upfronthosting.co.za>


Brett Cannon added the comment:

This is still an intermittent problem for me. Maybe it's related to issue #25122 ?

----------
nosy: +haypo
resolution: not a bug -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25234>
_______________________________________

From report at bugs.python.org  Fri Oct 16 20:24:46 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 Oct 2015 18:24:46 +0000
Subject: [issue25424] Deprecate older versions of benchmarks
In-Reply-To: <1445016798.76.0.0686859610456.issue25424@psf.upfronthosting.co.za>
Message-ID: <1445019886.45.0.0979432081217.issue25424@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Another option is to make it so that we add an "old" group of tests and make negation by group work, e.g., `-b 2n3,-old`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25424>
_______________________________________

From report at bugs.python.org  Fri Oct 16 20:36:57 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Oct 2015 18:36:57 +0000
Subject: [issue25424] Deprecate older versions of benchmarks
In-Reply-To: <1445016798.76.0.0686859610456.issue25424@psf.upfronthosting.co.za>
Message-ID: <1445020617.72.0.591921183952.issue25424@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

As you prefer. The modern equivalents should be good replacements anyway, so there's not much need in keeping the old ones.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25424>
_______________________________________

From report at bugs.python.org  Fri Oct 16 20:39:31 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Oct 2015 18:39:31 +0000
Subject: [issue25425] white-spaces encountered in 3.4
In-Reply-To: <1445019439.47.0.233830038143.issue25425@psf.upfronthosting.co.za>
Message-ID: <1445020771.6.0.202366080072.issue25425@psf.upfronthosting.co.za>


R. David Murray added the comment:

You are going to have to explain more about what your issue is, there isn't enough information here to even start to guess.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25425>
_______________________________________

From report at bugs.python.org  Fri Oct 16 20:53:11 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Oct 2015 18:53:11 +0000
Subject: [issue25424] Deprecate older versions of benchmarks
In-Reply-To: <1445016798.76.0.0686859610456.issue25424@psf.upfronthosting.co.za>
Message-ID: <20151016185307.117258.88929@psf.io>


Roundup Robot added the comment:

New changeset 2dfb8e568d93 by Brett Cannon in branch 'default':
Issue #25424: Deprecate benchmarks with newer versions
https://hg.python.org/benchmarks/rev/2dfb8e568d93

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25424>
_______________________________________

From report at bugs.python.org  Fri Oct 16 20:53:38 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 Oct 2015 18:53:38 +0000
Subject: [issue25424] Deprecate older versions of benchmarks
In-Reply-To: <1445016798.76.0.0686859610456.issue25424@psf.upfronthosting.co.za>
Message-ID: <1445021618.44.0.939061156216.issue25424@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks for the input, Antoine!

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25424>
_______________________________________

From report at bugs.python.org  Fri Oct 16 21:10:03 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Oct 2015 19:10:03 +0000
Subject: [issue25407] Update PEP 4 to keep modules in Python 3
In-Reply-To: <1444838356.16.0.900937210643.issue25407@psf.upfronthosting.co.za>
Message-ID: <20151016191000.75273.2782@psf.io>


Roundup Robot added the comment:

New changeset bcee1364e2dc by Brett Cannon in branch '3.5':
Issue #25407: Drop the mention of the formatter module being removed
https://hg.python.org/cpython/rev/bcee1364e2dc

New changeset 9a0d367b8dd3 by Brett Cannon in branch 'default':
Merge for issue #25407
https://hg.python.org/cpython/rev/9a0d367b8dd3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25407>
_______________________________________

From report at bugs.python.org  Fri Oct 16 21:12:42 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 Oct 2015 19:12:42 +0000
Subject: [issue25407] Update PEP 4 to keep modules in Python 3
In-Reply-To: <1444838356.16.0.900937210643.issue25407@psf.upfronthosting.co.za>
Message-ID: <1445022762.03.0.440077676291.issue25407@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25407>
_______________________________________

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: [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  Fri Oct 16 21:30:28 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Oct 2015 19:30:28 +0000
Subject: [issue25188] regrtest.py improvement for Profile Guided Optimization
 builds
In-Reply-To: <1442726782.64.0.586742420801.issue25188@psf.upfronthosting.co.za>
Message-ID: <20151016193025.7244.63121@psf.io>


Roundup Robot added the comment:

New changeset cc42700abb8e by Brett Cannon in branch '2.7':
Issue #25188: Clean up code to pass the --pgo flag to subprocesses
https://hg.python.org/cpython/rev/cc42700abb8e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25188>
_______________________________________

From report at bugs.python.org  Fri Oct 16 21:31:36 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 Oct 2015 19:31:36 +0000
Subject: [issue25188] regrtest.py improvement for Profile Guided Optimization
 builds
In-Reply-To: <1442726782.64.0.586742420801.issue25188@psf.upfronthosting.co.za>
Message-ID: <1445023896.27.0.00577822902291.issue25188@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks for the patch, Arfrever. Although next time you don't need to unset every field of the issue since the issue was still fixed, just in a suboptimal fashion that didn't impact performance.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25188>
_______________________________________

From report at bugs.python.org  Fri Oct 16 22:05:58 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Oct 2015 20:05:58 +0000
Subject: [issue25426] Deprecate the regex_compile benchmark
In-Reply-To: <1445023706.21.0.465528553225.issue25426@psf.upfronthosting.co.za>
Message-ID: <1445025958.82.0.747565181483.issue25426@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

That sounds reasonable to me. It's a pity there isn't an official way to compile without caching.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25426>
_______________________________________

From report at bugs.python.org  Fri Oct 16 22:27:53 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Oct 2015 20:27:53 +0000
Subject: [issue25419] Readline completion of module names in import statements
In-Reply-To: <1444994208.15.0.362897114106.issue25419@psf.upfronthosting.co.za>
Message-ID: <1445027273.21.0.500939831801.issue25419@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm reviewing the patch, but it will take a time.

Wouldn't be simpler to use regular expressions instead of tokenizer?

For now Completer doesn't depends on the readline module, nor other global state. It can be used for completing in other environment, for example to complete words in IDE. Patched Completer retrieves additional information from the readline module. This can break existing code. It would be nice to decouple Completer from readline. In contrary to user .pythonrc.py file, we are free to invent new interfaces. May be add methods to the Completer class that provides needed additional information (nothing by default), and add Completer's subclass ReadlineCompleter that implements these methods using readline?

Found presumable bugs:

"import sy" doesn't suggest completion "sys".

"import os.p" doesn't suggest completion "os.path".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25419>
_______________________________________

From report at bugs.python.org  Fri Oct 16 22:44:21 2015
From: report at bugs.python.org (Sergey Shashkov)
Date: Fri, 16 Oct 2015 20:44:21 +0000
Subject: [issue25412] __floordiv__ in module fraction fails with TypeError
 instead of returning NotImplemented
In-Reply-To: <1444918194.04.0.71189202918.issue25412@psf.upfronthosting.co.za>
Message-ID: <1445028261.63.0.295951081114.issue25412@psf.upfronthosting.co.za>


Sergey Shashkov added the comment:

...
        def forward(a, b):
            if isinstance(b, (int, Fraction)):
                return monomorphic_operator(a, b)
            elif isinstance(b, float):
                return fallback_operator(float(a), b)
            elif isinstance(b, complex):
                return fallback_operator(complex(a), b)
            else:
                return NotImplemented
        forward.__name__ = '__' + fallback_operator.__name__ + '__'
        forward.__doc__ = monomorphic_operator.__doc__

        def reverse(b, a):
            if isinstance(a, numbers.Rational):
                # Includes ints.
                return monomorphic_operator(a, b)
            elif isinstance(a, numbers.Real):
                return fallback_operator(float(a), float(b))
            elif isinstance(a, numbers.Complex):
                return fallback_operator(complex(a), complex(b))
            else:
                return NotImplemented
...
so division is possible only with int, Fraction, float, complex, numbers.Rational, numbers.Real, numbers.Complex.
For all of them "isinstance(b, numbers.Complex)" is true

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25412>
_______________________________________

From report at bugs.python.org  Fri Oct 16 22:48:13 2015
From: report at bugs.python.org (Sergey Shashkov)
Date: Fri, 16 Oct 2015 20:48:13 +0000
Subject: [issue25412] __floordiv__ in module fraction fails with TypeError
 instead of returning NotImplemented
In-Reply-To: <1444918194.04.0.71189202918.issue25412@psf.upfronthosting.co.za>
Message-ID: <1445028493.12.0.679138322821.issue25412@psf.upfronthosting.co.za>


Changes by Sergey Shashkov <sh57 at yandex.ru>:


----------
hgrepos: +320

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25412>
_______________________________________

From report at bugs.python.org  Fri Oct 16 22:49:59 2015
From: report at bugs.python.org (Sergey Shashkov)
Date: Fri, 16 Oct 2015 20:49:59 +0000
Subject: [issue25412] __floordiv__ in module fraction fails with TypeError
 instead of returning NotImplemented
In-Reply-To: <1444918194.04.0.71189202918.issue25412@psf.upfronthosting.co.za>
Message-ID: <1445028599.01.0.75023866961.issue25412@psf.upfronthosting.co.za>


Changes by Sergey Shashkov <sh57 at yandex.ru>:


----------
hgrepos:  -320

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25412>
_______________________________________

From report at bugs.python.org  Fri Oct 16 22:51:21 2015
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 16 Oct 2015 20:51:21 +0000
Subject: [issue25008] Deprecate smtpd (based on deprecated asyncore/asynchat):
 write a new smtp server with asyncio
In-Reply-To: <1441472893.95.0.412611892234.issue25008@psf.upfronthosting.co.za>
Message-ID: <1445028681.35.0.280695088764.issue25008@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

This has come along pretty well.  The project is managed here:

https://gitlab.com/python-smtpd-hackers/aiosmtpd

and documentation here:

http://aiosmtpd.readthedocs.org/en/latest/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25008>
_______________________________________

From report at bugs.python.org  Fri Oct 16 22:52:11 2015
From: report at bugs.python.org (Nan Wu)
Date: Fri, 16 Oct 2015 20:52:11 +0000
Subject: [issue25017] htmllib deprecated: Which library to use? Missing sane
 default in docs
In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za>
Message-ID: <1445028731.75.0.964986876288.issue25017@psf.upfronthosting.co.za>


Nan Wu added the comment:

Added a small patched for this change.

----------
keywords: +patch
nosy: +Nan Wu
Added file: http://bugs.python.org/file40796/htmllib_deprecation_warning.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25017>
_______________________________________

From report at bugs.python.org  Fri Oct 16 22:59:31 2015
From: report at bugs.python.org (Sergey Shashkov)
Date: Fri, 16 Oct 2015 20:59:31 +0000
Subject: [issue25412] __floordiv__ in module fraction fails with TypeError
 instead of returning NotImplemented
In-Reply-To: <1444918194.04.0.71189202918.issue25412@psf.upfronthosting.co.za>
Message-ID: <1445029171.4.0.605175195746.issue25412@psf.upfronthosting.co.za>


Changes by Sergey Shashkov <sh57 at yandex.ru>:


----------
hgrepos: +321
keywords: +patch
Added file: http://bugs.python.org/file40797/fractions_truediv_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25412>
_______________________________________

From report at bugs.python.org  Fri Oct 16 23:06:28 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Oct 2015 21:06:28 +0000
Subject: [issue25234] test_eintr.test_os_open hangs under Xcode 7
In-Reply-To: <1443210079.4.0.780575467942.issue25234@psf.upfronthosting.co.za>
Message-ID: <1445029588.4.0.631590782014.issue25234@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hi Brett, if you are motivated, you can try the C program that I wrote to reproduce the bug on FreeBSD. It's attached to #25122. If the C program hangs too, it would mean that Darwin has also a bug (same bug??) in its code to handle signals in the code handling FIFO devices.

Or you can just add a skip mentioning this issue.

On my FreeBSD VM, it took a few minutes and multiples instances of the C program to reproduce the bug. On physical machines, other reported that a seconds and a single instance is enough. Well, see the FreeBSD bug report for more information ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25234>
_______________________________________

From report at bugs.python.org  Fri Oct 16 23:29:58 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Oct 2015 21:29:58 +0000
Subject: [issue25426] Deprecate the regex_compile benchmark
In-Reply-To: <1445023706.21.0.465528553225.issue25426@psf.upfronthosting.co.za>
Message-ID: <1445030998.58.0.669827407047.issue25426@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The public API for cache clearing is re.purge().

> It's a pity there isn't an official way to compile without caching.

See issue17441.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25426>
_______________________________________

From report at bugs.python.org  Fri Oct 16 23:59:10 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 Oct 2015 21:59:10 +0000
Subject: [issue25234] test_eintr.test_os_open hangs under Xcode 7
In-Reply-To: <1443210079.4.0.780575467942.issue25234@psf.upfronthosting.co.za>
Message-ID: <1445032750.82.0.421796122868.issue25234@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I can't get your testing program to compile, Victor, so if I run into it again I will add a skip to the test (harder to detect that it's the same test since test_eintr runs another test suite as if it's a single test).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25234>
_______________________________________

From report at bugs.python.org  Sat Oct 17 00:01:02 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 Oct 2015 22:01:02 +0000
Subject: [issue25426] Deprecate the regex_compile benchmark
In-Reply-To: <1445023706.21.0.465528553225.issue25426@psf.upfronthosting.co.za>
Message-ID: <1445032862.33.0.612714374818.issue25426@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25426>
_______________________________________

From report at bugs.python.org  Sat Oct 17 00:14:34 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Oct 2015 22:14:34 +0000
Subject: [issue25154] Drop the pyvenv script
In-Reply-To: <1442514921.37.0.255858283829.issue25154@psf.upfronthosting.co.za>
Message-ID: <20151016221431.18380.2654@psf.io>


Roundup Robot added the comment:

New changeset 6ab285820db2 by Brett Cannon in branch 'default':
Issue #25154: Deprecate the pyvenv script.
https://hg.python.org/cpython/rev/6ab285820db2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25154>
_______________________________________

From report at bugs.python.org  Sat Oct 17 00:15:01 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 Oct 2015 22:15:01 +0000
Subject: [issue25154] Drop the pyvenv script
In-Reply-To: <1442514921.37.0.255858283829.issue25154@psf.upfronthosting.co.za>
Message-ID: <1445033701.28.0.82910074375.issue25154@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25154>
_______________________________________

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: [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 00:15:54 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 Oct 2015 22:15:54 +0000
Subject: [issue25427] Remove the pyvenv script in Python 3.8
In-Reply-To: <1445033746.77.0.533143282748.issue25427@psf.upfronthosting.co.za>
Message-ID: <1445033754.34.0.414229308405.issue25427@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
dependencies: +Drop the pyvenv script

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25427>
_______________________________________

From report at bugs.python.org  Sat Oct 17 00:44:16 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Fri, 16 Oct 2015 22:44:16 +0000
Subject: [issue25419] Readline completion of module names in import statements
In-Reply-To: <1444994208.15.0.362897114106.issue25419@psf.upfronthosting.co.za>
Message-ID: <1445035456.45.0.721963106898.issue25419@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Is there a reason ipython's import completer couldn't be borrowed in its entirety? At work, I use a lightly adapted version of the code from ipython to do completion when I'm using the plain interactive interpreter (for whatever reason), and it works just fine.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25419>
_______________________________________

From report at bugs.python.org  Sat Oct 17 01:04:25 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 16 Oct 2015 23:04:25 +0000
Subject: [issue25422] tokenize: add tests for multi-line strings
In-Reply-To: <1445013749.49.0.456758504402.issue25422@psf.upfronthosting.co.za>
Message-ID: <1445036665.62.0.960176950284.issue25422@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file40798/issue-25422.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25422>
_______________________________________

From report at bugs.python.org  Sat Oct 17 01:19:53 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 16 Oct 2015 23:19:53 +0000
Subject: [issue23735] Readline not adjusting width after resize with 6.3
In-Reply-To: <1426984974.32.0.405944458303.issue23735@psf.upfronthosting.co.za>
Message-ID: <1445037593.86.0.560705017205.issue23735@psf.upfronthosting.co.za>


Martin Panter added the comment:

One idea might be to synchronously poll the screen size each time before Readline is invoked. Would doing this be such a burden? The polling could be limited to once every 0.1 s or so if it was a big burden. These ways would avoid interfering with signal handlers entirely.

----------
components: +Extension Modules
nosy: +martin.panter
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23735>
_______________________________________

From report at bugs.python.org  Sat Oct 17 01:43:14 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 16 Oct 2015 23:43:14 +0000
Subject: [issue25422] tokenize: add tests for multi-line strings
In-Reply-To: <1445013749.49.0.456758504402.issue25422@psf.upfronthosting.co.za>
Message-ID: <1445038994.71.0.877045976366.issue25422@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Avoid truncating the expected results when the tokens are long.

----------
Added file: http://bugs.python.org/file40799/issue-25422-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25422>
_______________________________________

From report at bugs.python.org  Sat Oct 17 02:39:30 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 17 Oct 2015 00:39:30 +0000
Subject: [issue25422] tokenize: add tests for multi-line strings
In-Reply-To: <1445013749.49.0.456758504402.issue25422@psf.upfronthosting.co.za>
Message-ID: <1445042370.14.0.592387002588.issue25422@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Removed the truncation of tokens. There's really no point to it, and it could be hiding bugs.

Also removed the truncation of token names, although none were ever truncated.

----------
Added file: http://bugs.python.org/file40800/issue-25422-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25422>
_______________________________________

From report at bugs.python.org  Sat Oct 17 02:45:58 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Oct 2015 00:45:58 +0000
Subject: [issue25422] tokenize: add tests for multi-line strings
In-Reply-To: <1445013749.49.0.456758504402.issue25422@psf.upfronthosting.co.za>
Message-ID: <20151017004550.34027.18776@psf.io>


Roundup Robot added the comment:

New changeset 91c44dc35dfd by Eric V. Smith in branch 'default':
Issue 25422: Add tests for multi-line string tokenization. Also remove truncated tokens.
https://hg.python.org/cpython/rev/91c44dc35dfd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25422>
_______________________________________

From report at bugs.python.org  Sat Oct 17 02:46:20 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 17 Oct 2015 00:46:20 +0000
Subject: [issue25422] tokenize: add tests for multi-line strings
In-Reply-To: <1445013749.49.0.456758504402.issue25422@psf.upfronthosting.co.za>
Message-ID: <1445042780.8.0.76640016376.issue25422@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25422>
_______________________________________

From report at bugs.python.org  Sat Oct 17 02:47:53 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 17 Oct 2015 00:47:53 +0000
Subject: [issue25311] Add f-string support to tokenize.py
In-Reply-To: <1443979407.62.0.707305717475.issue25311@psf.upfronthosting.co.za>
Message-ID: <1445042873.28.0.973608908437.issue25311@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Multi-line string tests were added in changeset 91c44dc35dfd. That will make changes for this issue safer. Updated patch to come.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25311>
_______________________________________

From report at bugs.python.org  Sat Oct 17 03:07:00 2015
From: report at bugs.python.org (Eric Snow)
Date: Sat, 17 Oct 2015 01:07:00 +0000
Subject: [issue25410] Clean up and fix OrderedDict
In-Reply-To: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za>
Message-ID: <1445044020.01.0.661185482172.issue25410@psf.upfronthosting.co.za>


Eric Snow added the comment:

Thanks for working on this, Serhiy.  I've left a review.

As to the points you outlined, I have concerns with the impact of #3 and #5 on subclasses.  Notably od.__class__ is not necessarily the same as type(od).  Also #7 may introduce an unhandled re-entrancy, causing potentially incorrect outcomes.

Also note that I was extremely careful to (almost) exactly match the pure Python implementation.  Not only did this guarantee equivalent behavior, but it simplified the porting effort.  I'm not opposed to deviating from the pure Python implementation as long as the behavior remains exactly the same.  So if you want to change the behavior of OrderedDict you must be sure to make the equivalent change in the pure Python implementation (with the associated backward-compatibility constraints).  Thanks again for working on this though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25410>
_______________________________________

From report at bugs.python.org  Sat Oct 17 03:23:08 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Oct 2015 01:23:08 +0000
Subject: [issue25381] Doc: Use of old description of raise in Python3
In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za>
Message-ID: <1445044988.0.0.379577487164.issue25381@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25381>
_______________________________________

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: [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 03:48:17 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Oct 2015 01:48:17 +0000
Subject: [issue25428] Have `datetime` understand integer arguments for
 timezones
In-Reply-To: <1445045654.46.0.202441860249.issue25428@psf.upfronthosting.co.za>
Message-ID: <1445046497.96.0.117421221211.issue25428@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +belopolsky, lemburg
versions:  -Python 3.5

_______________________________________
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: [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 04:15:12 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Oct 2015 02:15:12 +0000
Subject: [issue25428] Have `datetime` understand integer arguments for
 timezones
In-Reply-To: <1445045654.46.0.202441860249.issue25428@psf.upfronthosting.co.za>
Message-ID: <1445048112.15.0.137937767622.issue25428@psf.upfronthosting.co.za>


R. David Murray added the comment:

timezone is relatively new.  Work is in progress to add better timezone support to datetime, but it is a complicated subject and may or may not make it into 3.6.  In any case I think it is too soon to talk about this kind of API change, before the other work gets farther along.  That's probably also true for changes to the docs, although a concrete proposal there might have some chance.

There's a mailing list for talking specifically about datetime issues, you might want to post there (see mail.python.org, datetime-sig).

----------
nosy: +r.david.murray
resolution:  -> later
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25428>
_______________________________________

From report at bugs.python.org  Sat Oct 17 04:36:08 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Oct 2015 02:36:08 +0000
Subject: [issue25388] tokenizer crash/misbehavior -- heap use-after-free
In-Reply-To: <1444706115.92.0.283351483962.issue25388@psf.upfronthosting.co.za>
Message-ID: <1445049368.55.0.412810876019.issue25388@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

According to https://docs.python.org/3/reference/lexical_analysis.html#lexical-analysis, the encoding of a sourcefile (in Python 3) defaults to utf-8* and a decoding error is (should be) reported as a SyntaxError. Since b"\x7f\x00\x00\n''s\x01\xfd\n'S" is not invalid as utf-8, I expect a UnicodeDecodeError converted to SyntaxError.

* compile(bytes, filename, mode) defaults to latin1 instead.  It has no decoding problem, but quits with "ValueError: source code string cannot contain null bytes".  On 2.7, I might expect that as the error.

I expect '''self.assertIn(b"Non-UTF-8", res.err)''' to always fail because error messages are strings, not bytes.  That aside, have you ever seen that particular text (as a string) in a SyntaxError message?).

Why do you think the crash is during the tokenizing phase?  I could not see anything in the AS report.

----------
nosy: +terry.reedy
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25388>
_______________________________________

From report at bugs.python.org  Sat Oct 17 04:56:15 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 17 Oct 2015 02:56:15 +0000
Subject: [issue25419] Readline completion of module names in import statements
In-Reply-To: <1444994208.15.0.362897114106.issue25419@psf.upfronthosting.co.za>
Message-ID: <1445050575.25.0.973912404161.issue25419@psf.upfronthosting.co.za>


Martin Panter added the comment:

Josh: Thanks for pointing out I Python. I haven?t used it much myself, but it does seem to do a similar thing to my proposal. Looks like the relevant code may be around module_completion() at <https://github.com/ipython/ipython/blob/ab929fe/IPython/core/completerlib.py#L209>.

The ?sys? module is one of the builtin modules that I mentioned above. I plan to discuss changing pkgutil.iter_modules() to include it, in a separate bug report.

The ?os.path? case is more awkward. The ?os? module is not actually a package. I believe ?import os.path? only works because executing the ?os? module modifies sys.modules. My code currently avoids importing non-packages, because I thought it would be annoying to accidentally run a script via tab completion (anything not protected by ?if __name__ == "__main__" ?). On the other hand, I Python happily completes ?os.path? (and many more non-submodule names). It also can be tricked into running scripts, e.g. if you do ?import idlelib.__main__.? and press Tab. But maybe this is not a real problem, and I should stop being paranoid.

I tend to avoid regular expressions if practical. But Serhiy you may be right that some simple string matching rules would reduce the need for tokenizing. It looks like I Python only has a few simple rules for the entire input line being ?import x? and ?from x import y?. The disadvantage is less accurate understanding of more complicated syntax, like ?from x import y; from z import (a, bb as b, . . .?. It is a tradeoff between simpler code that only supports basic functionality versus complex code that supports more complete functionality.

I hear your points about decoupling from Readline and backwards compatibility. I will consider the overall architecture more in a future update. It would be good to allow this stuff to be used in e.g. Idle (though I wouldn?t know where to wire it in myself).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25419>
_______________________________________

From report at bugs.python.org  Sat Oct 17 05:00:15 2015
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 17 Oct 2015 03:00:15 +0000
Subject: [issue25429] Can segfault Python with itertools.chain.from_iterable
In-Reply-To: <1445047913.08.0.75860781244.issue25429@psf.upfronthosting.co.za>
Message-ID: <1445050815.37.0.487033808263.issue25429@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
assignee:  -> rhettinger
components: +Extension Modules
nosy: +rhettinger
versions: +Python 3.5, Python 3.6 -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25429>
_______________________________________

From report at bugs.python.org  Sat Oct 17 05:05:35 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Oct 2015 03:05:35 +0000
Subject: [issue25405] User install of 3.5 removes py.exe from C:\Windows
In-Reply-To: <1444828075.41.0.296808473589.issue25405@psf.upfronthosting.co.za>
Message-ID: <1445051135.04.0.0454555285512.issue25405@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

In my view, py.exe is a mess.  Steve, I know this is something you just inherited.  I have multiple all-user installs.  The first problem I have with py.exe is its defaulting to 2.7 instead of latest 3.5, and the impossibility of changing this.  The second, given that it does have a default, is its being given all the file associations, so one can only 'open with' 2.7 on the context menu.  (I know, pydev discussion is needed.)

I have twice changed the default by the cumbersome method given in the Using Python  manual, which requires admin privileges, which some people do not have.  Yet once again, the default is 2.7.  I am not sure whether this reset behavior started with 3.5 or not. I believe not.

In any case, the installer does not say whether one should or should not check (or leave checked) "[x] install launcher" when it is already installed.  Has it been upgraded ever? Or is the same buggy version just being reinstalled.  Paul, it sounds like for your, it did the only the 'delete the old' part of a re-install.

Bottom line: it should not be deleted unless re-installed; it should only be re-installed if there is an upgrade; and if it is re-installed, the changed default should not be disturbed.  If the latter is not possible with the user change in /Windows, then the method of changing the default should be changed.  For instance, "py -default x.y", which would be a good idea anyway.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25405>
_______________________________________

From report at bugs.python.org  Sat Oct 17 05:20:04 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 17 Oct 2015 03:20:04 +0000
Subject: [issue25421] Make __sizeof__ for builtin types more subclass friendly
In-Reply-To: <1445013720.79.0.218203938843.issue25421@psf.upfronthosting.co.za>
Message-ID: <1445052004.55.0.861472410799.issue25421@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25421>
_______________________________________

From report at bugs.python.org  Sat Oct 17 05:37:21 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Oct 2015 03:37:21 +0000
Subject: [issue25415] I can create instances of io.IOBase
In-Reply-To: <1444931934.97.0.280840323098.issue25415@psf.upfronthosting.co.za>
Message-ID: <1445053041.13.0.828117082873.issue25415@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Martin, I agree with changing the doc. Gerrit misunderstood because 'no public constructors' is either meaningless or wrong.  We do not usually talk about public versus private constructors.  This sounds more like C++ than Python.

For Python namespaces, names that start with '_' are private by convention unless documented otherwise.  Special names (__x__) are private in the sense that they are not usually used except by methods of the class; special methods are usually accessed by syntax or public names.  For class C, the default constructor is C.__new__, accessed by calling C.  (Let us not worry about other methods here.)  If C is a public name, with no '_', as is 'IOBase', then to me it has/is a public constructor.  Like other classes, IOBase has .__new__ and calling it produces an instance, as Gerrit discovered.  In that sense, it is not truly abstract.

I believe 'has no public constructor' is intended to mean 'has no documented signature and should not be *directly* called."  (If subclasses do call the base, then the signature should be documented.)

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25415>
_______________________________________

From report at bugs.python.org  Sat Oct 17 06:00:34 2015
From: report at bugs.python.org (eryksun)
Date: Sat, 17 Oct 2015 04:00:34 +0000
Subject: [issue25405] User install of 3.5 removes py.exe from C:\Windows
In-Reply-To: <1444828075.41.0.296808473589.issue25405@psf.upfronthosting.co.za>
Message-ID: <1445054434.35.0.432978114841.issue25405@psf.upfronthosting.co.za>


eryksun added the comment:

Setting a new default for py.exe doesn't require admin privileges. You can use the PY_PYTHON environment variable:

    C:\>py --version
    Python 2.7.10

    C:\>set PY_PYTHON=3

    C:\>py --version
    Python 3.5.0

which you can easily persist in the registry using setx.exe:

    C:\>setx PY_PYTHON 3

    SUCCESS: Specified value was saved.

Check that it was saved:

    C:\>reg query HKCU\Environment /v PY_PYTHON

    HKEY_CURRENT_USER\Environment
        PY_PYTHON    REG_SZ    3

You can also use %LOCALAPPDATA%\py.ini to set the default:

    C:\>py --version
    Python 2.7.10

    C:\>copy con "%localappdata%\py.ini"
    [defaults]
    python=3
    ^Z
            1 file(s) copied.

    C:\>py --version
    Python 3.5.0

Note that the environment variable is preferred:

    C:\Temp>set PY_PYTHON=2
    
    C:\Temp>py --version
    Python 2.7.10

and an active virtual environment is most preferred:

    C:\Temp>py -3.5 -m venv testenv

    C:\Temp>testenv\Scripts\activate.bat

    (testenv) C:\Temp>py --version
    Python 3.5.0
    (testenv) C:\Temp>py -c "import sys; print(sys.prefix)"
    C:\Temp\testenv

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25405>
_______________________________________

From report at bugs.python.org  Sat Oct 17 06:46:43 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Sat, 17 Oct 2015 04:46:43 +0000
Subject: [issue25429] Can segfault Python with itertools.chain.from_iterable
In-Reply-To: <1445047913.08.0.75860781244.issue25429@psf.upfronthosting.co.za>
Message-ID: <1445057203.55.0.306936381996.issue25429@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Also crashes in 3.5.0 (on Windows 7, with 64 bit build).

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25429>
_______________________________________

From report at bugs.python.org  Sat Oct 17 07:11:29 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 17 Oct 2015 05:11:29 +0000
Subject: [issue25429] Can segfault Python with itertools.chain.from_iterable
In-Reply-To: <1445047913.08.0.75860781244.issue25429@psf.upfronthosting.co.za>
Message-ID: <1445058689.75.0.284679060168.issue25429@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This is a duplicate of Issue #14010.  This issue runs deep and isn't itertools specific.  Running infinite chains of iterators pushes a number of CPython internals past their limits.  The best solutions are hard (monitoring the C-stack or fixing every possible fault at the fracture point).  The simplest solution (adding recursion count tracking to every possible iteration)is very heavy-handed and would slow-down all of Python in order to spare exotic cases that don't seem to arise in practice.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25429>
_______________________________________

From report at bugs.python.org  Sat Oct 17 07:47:37 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Oct 2015 05:47:37 +0000
Subject: [issue25414] Bypass unnecessary size limit test from deques on builds
 with 64-bit numbers
In-Reply-To: <1444923376.04.0.306426728101.issue25414@psf.upfronthosting.co.za>
Message-ID: <20151017054734.117256.47706@psf.io>


Roundup Robot added the comment:

New changeset 1733b3bd46db by Raymond Hettinger in branch 'default':
Issue #25414: Remove unnecessary tests that can never succeed.
https://hg.python.org/cpython/rev/1733b3bd46db

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25414>
_______________________________________

From report at bugs.python.org  Sat Oct 17 08:00:58 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Oct 2015 06:00:58 +0000
Subject: [issue25410] Clean up and fix OrderedDict
In-Reply-To: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za>
Message-ID: <1445061658.91.0.232631738559.issue25410@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your review Eric.

As for using Py_TYPE(self) instead of the __class__ attribute in #3, this is consistent with the rest of Python core and stdlib. All C implementations use Py_TYPE(self) for repr and pickling, even if Python implementations can use __class__.

>>> class S(set): __class__ = str
... 
>>> s = S()
>>> s.__class__
<class 'str'>
>>> s
S()
>>> s.__reduce_ex__(2)
(<class '__main__.S'>, ([],), {})
>>> s+''
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'S' and 'str'

Note that you can't just set s.__class__ = str, this is forbidden (issue24912). You should set __class__ in class definition or make it a property, and this doesn't have affect object's behavior, the only visible effect is the value of the __class__ attribute itself.

One possible argument for Py_TYPE(self) (besides simplicity and historical reasons) is that it is more reliable. It doesn't cause executing arbitrary Python code and therefore is thread-safe and reentrant. It returns the true type of the object, that can be important for debugging.

We should not care about exactly matching Python implementation, but rather about consistency with the rest of Python. If such type of mismatching is considered a bug, Python is full of such bugs.

About #5, be sure that the new code is exact semantic equivalence to the old code besides copying the dict that is not needed now. I just dropped an iteration on always empty dict and related code.

I don't see re-entrancy problem in #7. Could you please provide an example?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25410>
_______________________________________

From report at bugs.python.org  Sat Oct 17 08:57:29 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Oct 2015 06:57:29 +0000
Subject: [issue25429] Can segfault Python with itertools.chain.from_iterable
In-Reply-To: <1445047913.08.0.75860781244.issue25429@psf.upfronthosting.co.za>
Message-ID: <1445065049.75.0.22060961402.issue25429@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Actually this issue an exact duplicate of issue22911 that is a duplicate of issue14010.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25429>
_______________________________________

From report at bugs.python.org  Sat Oct 17 08:57:44 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 17 Oct 2015 06:57:44 +0000
Subject: [issue25414] Bypass unnecessary size limit test from deques on builds
 with 64-bit numbers
In-Reply-To: <1444923376.04.0.306426728101.issue25414@psf.upfronthosting.co.za>
Message-ID: <1445065064.16.0.234735279641.issue25414@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25414>
_______________________________________

From report at bugs.python.org  Sat Oct 17 08:58:28 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Oct 2015 06:58:28 +0000
Subject: [issue25429] Can segfault Python with itertools.chain.from_iterable
In-Reply-To: <1445047913.08.0.75860781244.issue25429@psf.upfronthosting.co.za>
Message-ID: <1445065108.73.0.440268839259.issue25429@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
superseder:  -> deeply nested filter segfaults

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25429>
_______________________________________

From report at bugs.python.org  Sat Oct 17 09:46:49 2015
From: report at bugs.python.org (Denis Jacquerye)
Date: Sat, 17 Oct 2015 07:46:49 +0000
Subject: [issue6331] Add unicode script info to the unicode database
In-Reply-To: <1245790259.44.0.08771310344.issue6331@psf.upfronthosting.co.za>
Message-ID: <1445068009.46.0.715377887609.issue6331@psf.upfronthosting.co.za>


Changes by Denis Jacquerye <moyogo at gmail.com>:


----------
nosy: +Denis Jacquerye

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6331>
_______________________________________

From report at bugs.python.org  Sat Oct 17 09:47:47 2015
From: report at bugs.python.org (Denis Jacquerye)
Date: Sat, 17 Oct 2015 07:47:47 +0000
Subject: [issue22612] Add block info to unicodedata
In-Reply-To: <1413050325.25.0.295627364762.issue22612@psf.upfronthosting.co.za>
Message-ID: <1445068067.97.0.300890215302.issue22612@psf.upfronthosting.co.za>


Changes by Denis Jacquerye <moyogo at gmail.com>:


----------
nosy: +Denis Jacquerye

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22612>
_______________________________________

From report at bugs.python.org  Sat Oct 17 10:58:07 2015
From: report at bugs.python.org (Torsten Bronger)
Date: Sat, 17 Oct 2015 08:58:07 +0000
Subject: [issue22570] Better stdlib support for Path objects
In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za>
Message-ID: <1445072287.74.0.410046878712.issue22570@psf.upfronthosting.co.za>


Changes by Torsten Bronger <bronger at physik.rwth-aachen.de>:


----------
nosy: +bronger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22570>
_______________________________________

From report at bugs.python.org  Sat Oct 17 12:13:34 2015
From: report at bugs.python.org (Torsten Bronger)
Date: Sat, 17 Oct 2015 10:13:34 +0000
Subject: [issue22570] Better stdlib support for Path objects
In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za>
Message-ID: <1445076814.05.0.321317436481.issue22570@psf.upfronthosting.co.za>


Torsten Bronger added the comment:

Please be conservative with adding methods to Path.

FWIW, my own experiences with pathlib have shown that utility methods have the disadvantage of duplicating well-established Python idioms.  This reduces code readability in my opinion.  While it is desirable that the rather inconvenient os.path may be superseded by pathlib in the long run,  utility methods like Path.glob, Path.open, Path.mkdir, and Path.readtext have convenient stdlib counterparts with long tradition, and using the methods seems disruptive and confusing to me.

This is a further argument for having a path protocol instead IMO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22570>
_______________________________________

From report at bugs.python.org  Sat Oct 17 13:32:01 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 17 Oct 2015 11:32:01 +0000
Subject: [issue25335] ast.literal_eval fails to parse numbers with leading "+"
In-Reply-To: <1444231519.35.0.84058018345.issue25335@psf.upfronthosting.co.za>
Message-ID: <1445081521.7.0.0425819188622.issue25335@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> I am pretty sure the 2.x anomaly is tied up with having short ints plus the anomaly of having one more negative than positive int.

Yes, that was the rationale for folding in the minus operation. It had some odd side-effects, though:

>>> -1j
-1j
>>> -(1j)
(-0-1j)

See issue 9011 for more discussion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25335>
_______________________________________

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: [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:06:25 2015
From: report at bugs.python.org (simon04)
Date: Sat, 17 Oct 2015 13:06:25 +0000
Subject: [issue25411] SMTPHandler in the logging module fails with unicode
 strings
In-Reply-To: <1444914126.08.0.971116617077.issue25411@psf.upfronthosting.co.za>
Message-ID: <1445087185.84.0.120588221961.issue25411@psf.upfronthosting.co.za>


simon04 added the comment:

I omitted the date header w/o intent. Basically because I couldn't quickly figure out how to set it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25411>
_______________________________________

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: [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:33:28 2015
From: report at bugs.python.org (Jos de Kloe)
Date: Sat, 17 Oct 2015 14:33:28 +0000
Subject: [issue12873] 2to3 incorrectly handles multi-line imports from
 __future__
In-Reply-To: <1314827841.27.0.752701109449.issue12873@psf.upfronthosting.co.za>
Message-ID: <1445092408.72.0.228621324726.issue12873@psf.upfronthosting.co.za>


Jos de Kloe added the comment:

still having this issue with 2to3 from python-tools-2.7.8-11 as packaged by Fedora 21.
Any progress since 2011?

----------
nosy: +jdekloe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12873>
_______________________________________

From report at bugs.python.org  Sat Oct 17 16:44:55 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Oct 2015 14:44:55 +0000
Subject: [issue16182] readline: Wrong tab completion scope indices in Unicode
 terminals
In-Reply-To: <1349813384.06.0.615857426211.issue16182@psf.upfronthosting.co.za>
Message-ID: <1445093095.43.0.439832350366.issue16182@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16182>
_______________________________________

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: [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  Sat Oct 17 17:24:37 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Oct 2015 15:24:37 +0000
Subject: [issue25411] SMTPHandler in the logging module fails with unicode
 strings
In-Reply-To: <1444914126.08.0.971116617077.issue25411@psf.upfronthosting.co.za>
Message-ID: <20151017152433.7252.11636@psf.io>


Roundup Robot added the comment:

New changeset eb843115e052 by Vinay Sajip in branch '3.4':
Closes #25411: Improved Unicode support in SMTPHandler.
https://hg.python.org/cpython/rev/eb843115e052

New changeset b99b3ddd0ac4 by Vinay Sajip in branch '3.5':
Closes #25411: Merged fix from 3.4.
https://hg.python.org/cpython/rev/b99b3ddd0ac4

New changeset 522b5cdffd42 by Vinay Sajip in branch 'default':
Closes #25411: Merged fix from 3.5.
https://hg.python.org/cpython/rev/522b5cdffd42

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25411>
_______________________________________

From report at bugs.python.org  Sat Oct 17 17:33:26 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Oct 2015 15:33:26 +0000
Subject: [issue25419] Readline completion of module names in import statements
In-Reply-To: <1444994208.15.0.362897114106.issue25419@psf.upfronthosting.co.za>
Message-ID: <1445096006.87.0.456998172325.issue25419@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added few cursory comments on Rietveld.

"sys" and "os.path" cases are not critical and we can ignore them if it complicates the code. But preserving Completer independence from readline looks more important to me. We can just add methods get_line_buffer(), get_begidx(), get_endidx() and get_completion_type() to Completer, but may be better to add more high level methods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25419>
_______________________________________

From report at bugs.python.org  Sat Oct 17 18:01:20 2015
From: report at bugs.python.org (Eric Snow)
Date: Sat, 17 Oct 2015 16:01:20 +0000
Subject: [issue25410] Clean up and fix OrderedDict
In-Reply-To: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za>
Message-ID: <1445097680.66.0.821868605697.issue25410@psf.upfronthosting.co.za>


Eric Snow added the comment:

Regarding Py_TYPE(od) vs. od.__class__, there is a difference for subclasses, as you demonstrated in your example. [1]  Thanks for explaining your rationale.  I now understand your argument about using PyTYPE() for repr and pickle in C types.  I still have concerns, though, regarding parity between the two OrderedDict implementations.

The key difference is that we're talking about an after-the-fact C port of an existing pure Python implementation.  The two implementations should behave identically in nearly every case.  The only place I would expect a deviation to not matter is for anything where Python-as-a-whole does not guarantee behavior.  However there are *very* few of those when all is said and done.  Any other variation should not be made casually and only if we are willing to accept that there may be code out there that relies on the pure Python behavior which the C implementation will break.

So like I said before, as a rule I'm absolutely okay with changing the behavior as long as the pure Python implementation is changed to match and OrderedDict remains backward-compatible (and the change is meaningful, e.g. efficiency, consistency).  Otherwise my concerns remain and we have to have sufficient justification for the change.

It may be worth taking this to python-dev to get a clearer consensus on both "Py_TYPE(obj) vs. obj.__class__", as well as about parity between dual pure-Python/C implementations in the stdlib, regardless of the outcome of this issue.  Both are points about which we should be consistent throughout Python.  The type() vs. __class__ question may deserve an entry in the language reference and both may deserve a PEP.  

-----

For this particular case, I think we should still aim for compatibility with the pure Python implementation.  To that effect, we could use Py_TYPE(od) only if PyODict_CheckExact() returns true (as a fast path) and use od.__class__ otherwise.  That fast path would be safe for the C implementation since code can't change OrderedDict().__class__ (due to #24912).

That particular difference in the implementations (i.e. you *can* change od.__class__ for the pure Python one) is an acceptable compatibility break since it's unlikely anyone is changing od.__class__ *and* if they are then they can just switch to a simple subclass that wraps OrderedDict:

    # before:
    from collections import OrderedDict
    od = OrderedDict()
    od.__class__ = SomethingElse

    # after:
    import collections
    class OrderedDict(collections.OrderedDict):
        pass
    od = OrderedDict()
    od.__class__ = SomethingElse

If we *do* continue supporting "type(od) != od.__class__" in repr then I'd say why bother with a fast path for PyOdict_CheckExact().  That sort of efficiency isn't necessary for repr.  If we stop supporting a differing od.__class__ then I'm fine simply using Py_TYPE() throughout.
    
Likewise, if this is not a case we want to support then we must accept that we may break some code out there, however unlikely that is.  In that case perhaps we could be more clear in the documentation that OrderedDict().__class__ should not be changed, though such an addition to the OrderedDict docs might just be clutter.  A general FAQ or other broader doc entry about not assigning to obj.__class__ for stdlib types might be more appropriate.  But that is where clarification from python-dev would help.


[1] There is also a difference between type(obj) and obj.__class__ in the case of proxies (e.g. see #16251), but that is less of an issue here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25410>
_______________________________________

From report at bugs.python.org  Sat Oct 17 18:19:10 2015
From: report at bugs.python.org (Eric Snow)
Date: Sat, 17 Oct 2015 16:19:10 +0000
Subject: [issue25410] Clean up and fix OrderedDict
In-Reply-To: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za>
Message-ID: <1445098750.29.0.805789002075.issue25410@psf.upfronthosting.co.za>


Eric Snow added the comment:

Regarding #5, you're right about OrderedDict().__dict__ being empty for the C implementation.  (Nice observation!)  So I'm okay with ripping all that code out of odict_reduce().  Since we're still accessing od.__dict__ through _PyObject_GetAttrId() that should not impact subclassing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25410>
_______________________________________

From report at bugs.python.org  Sat Oct 17 18:37:56 2015
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 17 Oct 2015 16:37:56 +0000
Subject: [issue25405] User install of 3.5 removes py.exe from C:\Windows
In-Reply-To: <1444828075.41.0.296808473589.issue25405@psf.upfronthosting.co.za>
Message-ID: <1445099876.55.0.202265162801.issue25405@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25405>
_______________________________________

From report at bugs.python.org  Sat Oct 17 18:44:35 2015
From: report at bugs.python.org (Aleksandr Balezin)
Date: Sat, 17 Oct 2015 16:44:35 +0000
Subject: [issue25430] speed up ipaddress __contain__ method
In-Reply-To: <1445083038.14.0.911555841878.issue25430@psf.upfronthosting.co.za>
Message-ID: <1445100275.69.0.180925084471.issue25430@psf.upfronthosting.co.za>


Changes by Aleksandr Balezin <gescheit12 at gmail.com>:


----------
versions: +Python 3.4, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25430>
_______________________________________

From report at bugs.python.org  Sat Oct 17 18:44:58 2015
From: report at bugs.python.org (Aleksandr Balezin)
Date: Sat, 17 Oct 2015 16:44:58 +0000
Subject: [issue25431] implement address in network in ipaddress module
In-Reply-To: <1445089092.67.0.311861464579.issue25431@psf.upfronthosting.co.za>
Message-ID: <1445100298.31.0.585905665415.issue25431@psf.upfronthosting.co.za>


Changes by Aleksandr Balezin <gescheit12 at gmail.com>:


----------
versions: +Python 3.4, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25431>
_______________________________________

From report at bugs.python.org  Sat Oct 17 18:45:09 2015
From: report at bugs.python.org (Eric Snow)
Date: Sat, 17 Oct 2015 16:45:09 +0000
Subject: [issue25410] Clean up and fix OrderedDict
In-Reply-To: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za>
Message-ID: <1445100309.92.0.837523271012.issue25410@psf.upfronthosting.co.za>


Eric Snow added the comment:

Regarding #7, I see what you did now.  That looks fine to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25410>
_______________________________________

From report at bugs.python.org  Sat Oct 17 19:06:21 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Oct 2015 17:06:21 +0000
Subject: [issue25432] isinstance documentation doesn't explain what happens
 when type is tuple
In-Reply-To: <1445093164.36.0.718439234598.issue25432@psf.upfronthosting.co.za>
Message-ID: <1445101581.52.0.712167579249.issue25432@psf.upfronthosting.co.za>


R. David Murray added the comment:

I don't see any ambiguity here.  There are other Python APIs with the same behavior, and all we say is that it can be a tuple (eg: str.startswith).  That is, I don't see any other way a tuple could be interpreted that would make any sense.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25432>
_______________________________________

From report at bugs.python.org  Sat Oct 17 19:17:52 2015
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 17 Oct 2015 17:17:52 +0000
Subject: [issue25429] Can segfault Python with itertools.chain.from_iterable
In-Reply-To: <1445047913.08.0.75860781244.issue25429@psf.upfronthosting.co.za>
Message-ID: <1445102272.64.0.625878798571.issue25429@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25429>
_______________________________________

From report at bugs.python.org  Sat Oct 17 19:21:35 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Oct 2015 17:21:35 +0000
Subject: [issue25410] Clean up and fix OrderedDict
In-Reply-To: <1445097680.66.0.821868605697.issue25410@psf.upfronthosting.co.za>
Message-ID: <4304260.CpbrLUAp50@raxxla>


Serhiy Storchaka added the comment:

> Regarding Py_TYPE(od) vs. od.__class__, there is a difference for
> subclasses, as you demonstrated in your example. [1]  Thanks for explaining
> your rationale.  I now understand your argument about using PyTYPE() for
> repr and pickle in C types.  I still have concerns, though, regarding
> parity between the two OrderedDict implementations.
> 
> The key difference is that we're talking about an after-the-fact C port of
> an existing pure Python implementation.

There is no a difference. io, pickle, ElementTree, bz2, virtually all 
accelerator classes was created as replacements of pure Python 
implementations. All C implementations use Py_TYPE(self) for repr() and 
pickling. I think this deviation is common and acceptable.

Backward compatibility related to __class__ assignment was already broken in C 
implementation. In 3.4 following code works:

>>> from collections import *
>>> class foo(OrderedDict):
...     def bark(self): return "spam"
... 
>>> class bar(OrderedDict):
...     pass
... 
>>> od = bar()
>>> od.__class__ = foo
>>> od.bark()
'spam'

In 3.5 it doesn't.

> That particular difference in the implementations (i.e. you *can* change
> od.__class__ for the pure Python one) is an acceptable compatibility break
> since it's unlikely anyone is changing od.__class__ *and* if they are then
> they can just switch to a simple subclass that wraps OrderedDict:
> 
>     # before:
>     from collections import OrderedDict
>     od = OrderedDict()
>     od.__class__ = SomethingElse
> 
>     # after:
>     import collections
>     class OrderedDict(collections.OrderedDict):
>         pass
>     od = OrderedDict()
>     od.__class__ = SomethingElse

No, this assignment is forbidden (due to #24912). You can't set __class_ for 
an instance of a subclass of non-heap type.

> It may be worth taking this to python-dev to get a clearer consensus on both
> "Py_TYPE(obj) vs. obj.__class__", as well as about parity between dual
> pure-Python/C implementations in the stdlib, regardless of the outcome of
> this issue.  Both are points about which we should be consistent throughout
> Python.  The type() vs. __class__ question may deserve an entry in the
> language reference and both may deserve a PEP.

Could you please raise a discussion on Python-Dev? You will formulate the 
problem better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25410>
_______________________________________

From report at bugs.python.org  Sat Oct 17 19:25:21 2015
From: report at bugs.python.org (eryksun)
Date: Sat, 17 Oct 2015 17:25:21 +0000
Subject: [issue25432] isinstance documentation doesn't explain what happens
 when type is tuple
In-Reply-To: <1445093164.36.0.718439234598.issue25432@psf.upfronthosting.co.za>
Message-ID: <1445102721.74.0.669873112683.issue25432@psf.upfronthosting.co.za>


eryksun added the comment:

Since Python has multiple inheritance, it could be misconstrued as a conjunctive test. For example, if c is an instance of C, which subclasses both A and B, then someone might think isinstance(c, (A, B)) requires c to be an instance of both A and B. The description could clarify that it's a disjunctive test with short circuiting.

    class MetaA(type):
        def __instancecheck__(self, other):
            print('MetaA.__instancecheck__')
            return False

    class A(metaclass=MetaA): pass

    >>> isinstance(1, (A, int))
    MetaA.__instancecheck__
    True
    >>> isinstance(1, (int, A))
    True

----------
keywords: +easy
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25432>
_______________________________________

From report at bugs.python.org  Sat Oct 17 20:00:13 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Oct 2015 18:00:13 +0000
Subject: [issue25431] implement address in network in ipaddress module
In-Reply-To: <1445089092.67.0.311861464579.issue25431@psf.upfronthosting.co.za>
Message-ID: <1445104813.89.0.405918443489.issue25431@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
dependencies: +speed up ipaddress __contain__ method
nosy: +ncoghlan, pmoody
stage:  -> patch review
type:  -> enhancement
versions:  -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25431>
_______________________________________

From report at bugs.python.org  Sat Oct 17 20:00:45 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Oct 2015 18:00:45 +0000
Subject: [issue25430] speed up ipaddress __contain__ method
In-Reply-To: <1445083038.14.0.911555841878.issue25430@psf.upfronthosting.co.za>
Message-ID: <1445104845.36.0.529002467768.issue25430@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +ncoghlan, pmoody
stage:  -> patch review
versions:  -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25430>
_______________________________________

From report at bugs.python.org  Sat Oct 17 21:22:54 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Oct 2015 19:22:54 +0000
Subject: [issue25410] Clean up and fix OrderedDict
In-Reply-To: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za>
Message-ID: <1445109774.11.0.411651603493.issue25410@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch addresses Eric's comments. Changes related to #3 are reverted. We will return to this after discussing on Python-Dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25410>
_______________________________________

From report at bugs.python.org  Sat Oct 17 21:23:19 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Oct 2015 19:23:19 +0000
Subject: [issue25410] Clean up and fix OrderedDict
In-Reply-To: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za>
Message-ID: <1445109799.73.0.992218100573.issue25410@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file40803/odict_cleanup_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25410>
_______________________________________

From report at bugs.python.org  Sat Oct 17 23:06:30 2015
From: report at bugs.python.org (Eric Snow)
Date: Sat, 17 Oct 2015 21:06:30 +0000
Subject: [issue25410] Clean up and fix OrderedDict
In-Reply-To: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za>
Message-ID: <1445115990.83.0.555262369493.issue25410@psf.upfronthosting.co.za>


Eric Snow added the comment:

new patch LGTM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25410>
_______________________________________

From report at bugs.python.org  Sat Oct 17 23:10:07 2015
From: report at bugs.python.org (Eric Snow)
Date: Sat, 17 Oct 2015 21:10:07 +0000
Subject: [issue25410] Clean up and fix OrderedDict
In-Reply-To: <4304260.CpbrLUAp50@raxxla>
Message-ID: <CALFfu7DDr9iyzxAQFKxWXA6ni=rO5YSTDDB5Ggi-hwgxpct+LA@mail.gmail.com>


Eric Snow added the comment:

> Backward compatibility related to __class__ assignment was already broken in C
> implementation. In 3.4 following code works:
[snip]
> In 3.5 it doesn't.

Depending on what feedback we get from python-dev, that may need to be
fixed.  I'd be inclined to not worry about it. :)

> No, this assignment is forbidden (due to #24912). You can't set __class_ for
> an instance of a subclass of non-heap type.

Ah, I see.  So the solution to that issue has *forced* a compatibility break.

> Could you please raise a discussion on Python-Dev? You will formulate the
> problem better.

I will.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25410>
_______________________________________

From report at bugs.python.org  Sun Oct 18 00:21:32 2015
From: report at bugs.python.org (Eric Snow)
Date: Sat, 17 Oct 2015 22:21:32 +0000
Subject: [issue25410] Clean up and fix OrderedDict
In-Reply-To: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za>
Message-ID: <1445120492.78.0.621165742785.issue25410@psf.upfronthosting.co.za>


Eric Snow added the comment:

Posted to python-dev:

https://mail.python.org/pipermail/python-dev/2015-October/141953.html

https://mail.python.org/pipermail/python-dev/2015-October/141954.html

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25410>
_______________________________________

From report at bugs.python.org  Sun Oct 18 08:16:34 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 18 Oct 2015 06:16:34 +0000
Subject: [issue25395] SIGSEGV using json.tool: highly nested OrderedDict
In-Reply-To: <1444765181.78.0.70980847428.issue25395@psf.upfronthosting.co.za>
Message-ID: <1445148994.75.0.507286069108.issue25395@psf.upfronthosting.co.za>


Martin Panter added the comment:

The following simplified code produces the crash:

from collections import OrderedDict
obj = []
for _ in range(33):
    obj = OrderedDict(((None, obj),))
for _ in range(17):
    obj = [obj]
print("Still alive, crash happens at interpreter finalization")

This crashes at the same line as in Serhiy?s backtrace. In _PyTrash_thread_destroy_chain(), Py_TYPE(op) is a bad pointer (0xdbdbdbdbdbdbdbdb); I have enabled --with-pydebug.

----------
components: +Interpreter Core -Library (Lib)
nosy: +martin.panter
title: SIGSEGV using json.tool -> SIGSEGV using json.tool: highly nested OrderedDict

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25395>
_______________________________________

From report at bugs.python.org  Sun Oct 18 08:55:32 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Oct 2015 06:55:32 +0000
Subject: [issue25410] Clean up and fix OrderedDict
In-Reply-To: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za>
Message-ID: <20151018065528.18368.59069@psf.io>


Roundup Robot added the comment:

New changeset b6e33798f82a by Serhiy Storchaka in branch '3.5':
Issue #25410: Cleaned up and fixed minor bugs in C implementation of OrderedDict.
https://hg.python.org/cpython/rev/b6e33798f82a

New changeset 741ef17e9b86 by Serhiy Storchaka in branch 'default':
Issue #25410: Cleaned up and fixed minor bugs in C implementation of OrderedDict.
https://hg.python.org/cpython/rev/741ef17e9b86

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25410>
_______________________________________

From report at bugs.python.org  Sun Oct 18 09:05:40 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 18 Oct 2015 07:05:40 +0000
Subject: [issue25395] SIGSEGV using json.tool: highly nested OrderedDict
In-Reply-To: <1444765181.78.0.70980847428.issue25395@psf.upfronthosting.co.za>
Message-ID: <1445151940.77.0.764905994741.issue25395@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a patch that seems to fix the problem for me. Can someone who knows more about tp_dealloc() methods and the Py_TRASHCAN_SAFE stuff have a look? All I know is that the body of the trashcan stuff can be deferred until an outer nested body is finished, so I though it might be best to defer that PyDict_Type.tp_dealloc() call as well.

Is it worth packaging up my simplified code in a test case, perhaps in an assert_python_ok() child process?

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file40804/odict-trashcan.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25395>
_______________________________________

From report at bugs.python.org  Sun Oct 18 09:19:51 2015
From: report at bugs.python.org (koobs)
Date: Sun, 18 Oct 2015 07:19:51 +0000
Subject: [issue7352] pythonx.y-config --ldflags out of /usr and missing
 -L<install_lib_dir>
In-Reply-To: <1258578467.08.0.137292547946.issue7352@psf.upfronthosting.co.za>
Message-ID: <1445152791.15.0.247294691404.issue7352@psf.upfronthosting.co.za>


koobs added the comment:

The attached patch courtesy of Jan Beich @ FreeBSD minimally mimics (in the python version), the --ldflags output of the shell version of python-config(.sh).

The ideal scenario of course would be to use the shell script across all versions, as per revision c0370730b364 from #16235, so that two different versions of python-config no longer need to be maintained (as doko suggested in msg173710) and a whole bunch of now divergent code can be relegated to the depths.

@doko - can we please get this in for at least 2.7 and 3.4 please, downstreams can at least then manage backports themselves for 3.3 and below if necessary. This *is* a bug.

----------
Added file: http://bugs.python.org/file40805/patch-issue7352.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7352>
_______________________________________

From report at bugs.python.org  Sun Oct 18 09:34:15 2015
From: report at bugs.python.org (koobs)
Date: Sun, 18 Oct 2015 07:34:15 +0000
Subject: [issue7352] pythonx.y-config --ldflags out of /usr and missing
 -L<install_lib_dir>
In-Reply-To: <1258578467.08.0.137292547946.issue7352@psf.upfronthosting.co.za>
Message-ID: <1445153655.83.0.850525962352.issue7352@psf.upfronthosting.co.za>


koobs added the comment:

To clarify, the bug remains in all branches including default, but only 3.4+ use the .sh script, leaving 3.3, 3.2, 2.7 using the python implementation.

----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7352>
_______________________________________

From report at bugs.python.org  Sun Oct 18 10:04:27 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Oct 2015 08:04:27 +0000
Subject: [issue25395] SIGSEGV using json.tool: highly nested OrderedDict
In-Reply-To: <1444765181.78.0.70980847428.issue25395@psf.upfronthosting.co.za>
Message-ID: <1445155467.88.0.753761224374.issue25395@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think there is no need to run the test in a subprocess. You can trigger the crash by "del obj".

from collections import OrderedDict
obj = None
for _ in range(1000):
    obj = OrderedDict([(None, obj)])

del obj
support.gc_collect()

Unfortunately this test is crashed with the patch.

Fatal Python error: Objects/odictobject.c:1443 object at 0xb749ddfc has negative ref count -1

Current thread 0xb7580700 (most recent call first):
  File "<stdin>", line 1 in <module>
Aborted (core dumped)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25395>
_______________________________________

From report at bugs.python.org  Sun Oct 18 10:24:04 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Oct 2015 08:24:04 +0000
Subject: [issue25410] Clean up and fix OrderedDict
In-Reply-To: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za>
Message-ID: <1445156644.09.0.859579864928.issue25410@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch that makes both implementations to use type(self) instead of self.__class__ in __repr__(), __reduce__() and copy().

There is a difference between current implementations. Python implementation uses self.__class__ in copy(), C implementation uses type(self).

----------
Added file: http://bugs.python.org/file40806/odict_type.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25410>
_______________________________________

From report at bugs.python.org  Sun Oct 18 11:05:39 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 18 Oct 2015 09:05:39 +0000
Subject: [issue25395] SIGSEGV using json.tool: highly nested OrderedDict
In-Reply-To: <1444765181.78.0.70980847428.issue25395@psf.upfronthosting.co.za>
Message-ID: <1445159139.93.0.959224579677.issue25395@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a new patch which uses Py_CLEAR() rather than Py_XDECREF(), which seems to cure the negative reference count problem. This change was only a guess based on looking at namespaceobject.c and the Py_CLEAR() documentation, so it would be good for someone else to carefully review it.

----------
Added file: http://bugs.python.org/file40807/odict-trashcan.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25395>
_______________________________________

From report at bugs.python.org  Sun Oct 18 12:39:35 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Oct 2015 10:39:35 +0000
Subject: [issue25395] SIGSEGV using json.tool: highly nested OrderedDict
In-Reply-To: <1445159139.93.0.959224579677.issue25395@psf.upfronthosting.co.za>
Message-ID: <43796231.G6sVO9q5QZ@raxxla>


Serhiy Storchaka added the comment:

Using Py_CLEAR() fixes symptoms in this test, but the real issue is that 
deallocating code is executed twice for some objects (for every 25th 
OrderedDict).

PyDict_Type.tp_dealloc() can deposit an object in the _PyTrash_delete_later 
list if trash_delete_nesting exceeds PyTrash_UNWIND_LEVEL. Later Py_TYPE(op)-
>tp_dealloc is called for objects in the _PyTrash_delete_later list. But this 
is odict_dealloc that already was called.

One of ways to avoid repeated deallocation is to change the type of the object 
before calling PyDict_Type.tp_dealloc(). This looks as a hack, but correct 
hack. May be there is more straightforward solution.

----------
Added file: http://bugs.python.org/file40808/odict-trashcan.v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25395>
_______________________________________
-------------- next part --------------
diff -r 741ef17e9b86 Lib/test/test_collections.py
--- a/Lib/test/test_collections.py	Sun Oct 18 09:54:42 2015 +0300
+++ b/Lib/test/test_collections.py	Sun Oct 18 13:28:41 2015 +0300
@@ -2033,6 +2033,14 @@ class OrderedDictTests:
         items = [('a', 1), ('c', 3), ('b', 2)]
         self.assertEqual(list(MyOD(items).items()), items)
 
+    def test_highly_nested(self):
+        # Issue 25395: crashes during garbage collection
+        obj = None
+        for _ in range(1000):
+            obj = self.module.OrderedDict([(None, obj)])
+        del obj
+        support.gc_collect()
+
 
 class PurePythonOrderedDictTests(OrderedDictTests, unittest.TestCase):
 
diff -r 741ef17e9b86 Misc/NEWS
--- a/Misc/NEWS	Sun Oct 18 09:54:42 2015 +0300
+++ b/Misc/NEWS	Sun Oct 18 13:28:41 2015 +0300
@@ -10,6 +10,9 @@ Release date: XXXX-XX-XX
 Core and Builtins
 -----------------
 
+- Issue #25395: Fix crash when highly nested OrderedDict structures were
+  garbage collected.
+
 - Issue #25401: Optimize bytes.fromhex() and bytearray.fromhex(): they are now
   between 2x and 3.5x faster.
 
diff -r 741ef17e9b86 Objects/odictobject.c
--- a/Objects/odictobject.c	Sun Oct 18 09:54:42 2015 +0300
+++ b/Objects/odictobject.c	Sun Oct 18 13:28:41 2015 +0300
@@ -1438,16 +1438,19 @@ static void
 odict_dealloc(PyODictObject *self)
 {
     PyObject_GC_UnTrack(self);
-    Py_TRASHCAN_SAFE_BEGIN(self);
+    Py_TRASHCAN_SAFE_BEGIN(self)
+
     Py_XDECREF(self->od_inst_dict);
     if (self->od_weakreflist != NULL)
         PyObject_ClearWeakRefs((PyObject *)self);
 
     _odict_clear_nodes(self);
-    Py_TRASHCAN_SAFE_END(self);
 
     /* must be last */
+    Py_TYPE(self) = &PyDict_Type;
     PyDict_Type.tp_dealloc((PyObject *)self);
+
+    Py_TRASHCAN_SAFE_END(self)
 };
 
 /* tp_repr */

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: [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 14:27:57 2015
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 18 Oct 2015 12:27:57 +0000
Subject: [issue25432] isinstance documentation doesn't explain what happens
 when type is tuple
In-Reply-To: <1445093164.36.0.718439234598.issue25432@psf.upfronthosting.co.za>
Message-ID: <1445171277.98.0.0832500969103.issue25432@psf.upfronthosting.co.za>


Georg Brandl added the comment:

But without using the word "disjunctive".

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25432>
_______________________________________

From report at bugs.python.org  Sun Oct 18 18:22:14 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Oct 2015 16:22:14 +0000
Subject: [issue15999] Using new 'bool' format character
In-Reply-To: <1348242429.94.0.662282558141.issue15999@psf.upfronthosting.co.za>
Message-ID: <1445185334.52.0.93185349175.issue15999@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

No, it is orthogonal to Argument Clinic. Usually converting to Argument Clinic didn't change semantic. However these changes conflicted with proposed patch.

Rebased patch is splitted on two patches.

bool_cleanup.patch. It almost doesn't change the behavior. It uses the "p" format unit instead of manually called PyObject_IsTrue(), passes boolean value instead 0/1 integers to functions that needs boolean, and made some arguments ("flush" in print(), "strict", "sort_keys" and "skipkeys" in json module) to be converted to boolean only once.

accept_bool.patch. It makes a number of functions to accept arbitrary objects in boolean context, not just False/True and ints representable as C int. But I prefer first to commit the patch for issue24037.

----------
Added file: http://bugs.python.org/file40809/bool_cleanup.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15999>
_______________________________________

From report at bugs.python.org  Sun Oct 18 18:22:33 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Oct 2015 16:22:33 +0000
Subject: [issue15999] Using new 'bool' format character
In-Reply-To: <1348242429.94.0.662282558141.issue15999@psf.upfronthosting.co.za>
Message-ID: <1445185353.95.0.711043409203.issue15999@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file40810/accept_bool.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15999>
_______________________________________

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: [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 19:22:44 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Oct 2015 17:22:44 +0000
Subject: [issue25434] Fix typo in whatsnew/3.5
In-Reply-To: <1445188273.65.0.786710324106.issue25434@psf.upfronthosting.co.za>
Message-ID: <20151018172239.18366.43207@psf.io>


Roundup Robot added the comment:

New changeset 04ce28b11467 by Berker Peksag in branch '3.5':
Issue #25434: Fix typo in whatsnew/3.5rst
https://hg.python.org/cpython/rev/04ce28b11467

New changeset 93a1b79d0b19 by Berker Peksag in branch 'default':
Issue #25434: Fix typo in whatsnew/3.5rst
https://hg.python.org/cpython/rev/93a1b79d0b19

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25434>
_______________________________________

From report at bugs.python.org  Sun Oct 18 19:23:53 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 18 Oct 2015 17:23:53 +0000
Subject: [issue25434] Fix typo in whatsnew/3.5
In-Reply-To: <1445188273.65.0.786710324106.issue25434@psf.upfronthosting.co.za>
Message-ID: <1445189033.52.0.422843054267.issue25434@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Louis.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25434>
_______________________________________

From report at bugs.python.org  Sun Oct 18 19:27:05 2015
From: report at bugs.python.org (SilentGhost)
Date: Sun, 18 Oct 2015 17:27:05 +0000
Subject: [issue25434] Fix typo in whatsnew/3.5
In-Reply-To: <1445188273.65.0.786710324106.issue25434@psf.upfronthosting.co.za>
Message-ID: <1445189225.43.0.607502436095.issue25434@psf.upfronthosting.co.za>


SilentGhost added the comment:

Shouldn't the line above read "now accepts" rather than "how accepts"?

----------
nosy: +SilentGhost

_______________________________________
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: [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 20:54:57 2015
From: report at bugs.python.org (SilentGhost)
Date: Sun, 18 Oct 2015 18:54:57 +0000
Subject: [issue25435] Wrong function calls and referring to not removed
 concepts in descriptor HowTo (documentation)
In-Reply-To: <1445194189.09.0.0973348556564.issue25435@psf.upfronthosting.co.za>
Message-ID: <1445194497.7.0.505988021702.issue25435@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
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: [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: [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  Sun Oct 18 21:46:26 2015
From: report at bugs.python.org (Daniel Waites)
Date: Sun, 18 Oct 2015 19:46:26 +0000
Subject: [issue25437] Issue with ftplib.FTP_TLS and server forcing SSL
 connection reuse
In-Reply-To: <1445197458.2.0.693285034257.issue25437@psf.upfronthosting.co.za>
Message-ID: <1445197586.0.0.655182702909.issue25437@psf.upfronthosting.co.za>


Daniel Waites added the comment:

Incidentally, there appears to be an old bug report with a similar error message, although the error is encountered in a different context. http://bugs.python.org/issue10808 . Evidently, errors encountered in libssl aren't necessarily being propagated up to python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25437>
_______________________________________

From report at bugs.python.org  Sun Oct 18 21:49:24 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 18 Oct 2015 19:49:24 +0000
Subject: [issue25436] argparse.ArgumentError missing error message in __repr__
In-Reply-To: <1445196585.11.0.0454648926496.issue25436@psf.upfronthosting.co.za>
Message-ID: <1445197764.72.0.764836411833.issue25436@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
stage:  -> patch review
type:  -> behavior
versions: +Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25436>
_______________________________________

From report at bugs.python.org  Sun Oct 18 23:09:13 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Oct 2015 21:09:13 +0000
Subject: [issue25420] "import random" blocks on entropy collection on Linux
 with low entropy
In-Reply-To: <1445003396.34.0.246344104115.issue25420@psf.upfronthosting.co.za>
Message-ID: <1445202553.12.0.050681981834.issue25420@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"The RNG is seeded from os.urandom, which as of python 3.5 uses the potentially blocking getrandom() call."

Hum ok, so your issue is specific to Linux.

"This causes problems e.g. on our build VMs that don't have true entropy, so getrandom() blocks forever"

Hum, the problem was already fixed some months/years ago: you must attach a RNG virtio device to your VM. Python is just one example, a lot of applications need entropy.

"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)"

An unsafe *workaround* is to install haveged, a daemon generating entropy using the CPU.

----------
nosy: +haypo
title: "import random" blocks on entropy collection -> "import random" blocks on entropy collection on Linux with low entropy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25420>
_______________________________________

From report at bugs.python.org  Sun Oct 18 23:58:28 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 18 Oct 2015 21:58:28 +0000
Subject: [issue25434] Fix typo in whatsnew/3.5
In-Reply-To: <1445188273.65.0.786710324106.issue25434@psf.upfronthosting.co.za>
Message-ID: <1445205508.93.0.635291572257.issue25434@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Good catch, fixed in 530846c3ebb4 and f020a27b5391. Thanks SilentGhost.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25434>
_______________________________________

From report at bugs.python.org  Mon Oct 19 02:40:46 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 19 Oct 2015 00:40:46 +0000
Subject: [issue25435] Wrong function calls and referring to not removed
 concepts in descriptor HowTo (documentation)
In-Reply-To: <1445194189.09.0.0973348556564.issue25435@psf.upfronthosting.co.za>
Message-ID: <1445215246.73.0.49963561092.issue25435@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the patch. I left a few comments on the code review. I think the class is meant to represent a real function object, not a wrapper. And it would be good to update the following paragraphs about unbound methods.

Also, it looks like the rest of that page could do with some other updates. E.g. no need for explicit Function(object) base class, no need to mention that a method exists in Python 2.3, code could use @classmethod decorator syntax. But these are a slightly separate issues.

----------
nosy: +martin.panter
stage:  -> patch review
versions: +Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25435>
_______________________________________

From report at bugs.python.org  Mon Oct 19 03:21:59 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 19 Oct 2015 01:21:59 +0000
Subject: [issue13195] subprocess: args with shell=True is not documented on
 Windows
In-Reply-To: <1318850493.84.0.375275631996.issue13195@psf.upfronthosting.co.za>
Message-ID: <1445217719.57.0.113241956515.issue13195@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think the documentation changes made for Issue 16115 should address your first question (shell=False). For shell=True, see the discussion at Issue 20344. Perhaps you can review my patch.

----------
dependencies: +test the executable arg to Popen() and improve related docs
nosy: +martin.panter
resolution:  -> duplicate
status: open -> closed
superseder:  -> subprocess.check_output() docs misrepresent what shell=True does

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13195>
_______________________________________

From report at bugs.python.org  Mon Oct 19 05:26:18 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 19 Oct 2015 03:26:18 +0000
Subject: [issue23702] docs.python.org/3/howto/descriptor.html still refers to
 "unbound methods"
In-Reply-To: <1426708114.47.0.635748134131.issue23702@psf.upfronthosting.co.za>
Message-ID: <1445225178.93.0.83318896289.issue23702@psf.upfronthosting.co.za>


Martin Panter added the comment:

Current patch for Issue 25435 addresses the code example. Changes to the text are also needed though.

----------
dependencies: +Wrong function calls and referring to not removed concepts in descriptor HowTo (documentation)
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23702>
_______________________________________

From report at bugs.python.org  Mon Oct 19 05:29:04 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 19 Oct 2015 03:29:04 +0000
Subject: [issue25435] Wrong function calls and referring to not removed
 concepts in descriptor HowTo (documentation)
In-Reply-To: <1445194189.09.0.0973348556564.issue25435@psf.upfronthosting.co.za>
Message-ID: <1445225344.05.0.331480606267.issue25435@psf.upfronthosting.co.za>


Martin Panter added the comment:

Also further up the page, ?unbound methods . . . are . . . based on the descriptor protocol? is probably not really correct or useful. Issue 23702 is already open about mentioning unbound methods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25435>
_______________________________________

From report at bugs.python.org  Mon Oct 19 06:09:06 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 19 Oct 2015 04:09:06 +0000
Subject: [issue16785] Document the fact that constructing OSError with erron
 returns subclass if possible
In-Reply-To: <1356521712.57.0.0819210166931.issue16785@psf.upfronthosting.co.za>
Message-ID: <1445227746.62.0.6649329681.issue16785@psf.upfronthosting.co.za>


Martin Panter added the comment:

My proposed patch at Issue 23391 addresses this

----------
dependencies: +Documentation of EnvironmentError (OSError) arguments disappeared
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16785>
_______________________________________

From report at bugs.python.org  Mon Oct 19 07:40:18 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Oct 2015 05:40:18 +0000
Subject: [issue23391] Documentation of EnvironmentError (OSError) arguments
 disappeared
In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za>
Message-ID: <1445233218.35.0.881893943202.issue23391@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Perhaps you missed my comments to previous patch on Rietveld. Besides this the patch LGTM.

May be we should change weird behavior for 6+ arguments. But this is different issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23391>
_______________________________________

From report at bugs.python.org  Mon Oct 19 07:42:04 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Oct 2015 05:42:04 +0000
Subject: [issue23391] Documentation of EnvironmentError (OSError) arguments
 disappeared
In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za>
Message-ID: <1445233324.32.0.00168519234804.issue23391@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
Removed message: http://bugs.python.org/msg253170

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23391>
_______________________________________

From report at bugs.python.org  Mon Oct 19 07:43:09 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Oct 2015 05:43:09 +0000
Subject: [issue23391] Documentation of EnvironmentError (OSError) arguments
 disappeared
In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za>
Message-ID: <1445233389.08.0.958426725049.issue23391@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch LGTM. We should handle the problem with extra arguments in separate issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23391>
_______________________________________

From report at bugs.python.org  Mon Oct 19 07:43:41 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Oct 2015 05:43:41 +0000
Subject: [issue23391] Documentation of EnvironmentError (OSError) arguments
 disappeared
In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za>
Message-ID: <1445233421.5.0.170182761674.issue23391@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee: docs at python -> martin.panter
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23391>
_______________________________________

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: [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: [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 11:47:04 2015
From: report at bugs.python.org (=?utf-8?b?QmrDtnJuIEVkc3Ryw7Zt?=)
Date: Mon, 19 Oct 2015 09:47:04 +0000
Subject: [issue16113] Add SHA-3 (Keccak) support
In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za>
Message-ID: <1445248024.67.0.072941630418.issue16113@psf.upfronthosting.co.za>


Bj?rn Edstr?m added the comment:

Remember that FIPS202 slightly change some parts of the Keccak that won the competition, so test results are different. I updated my stand alone SHA3 module, for anyone who is interested in using this now in Python 2 and 3.

https://github.com/bjornedstrom/python-sha3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16113>
_______________________________________

From report at bugs.python.org  Mon Oct 19 12:34:15 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 19 Oct 2015 10:34:15 +0000
Subject: [issue25439] Add type checks to urllib.request.Request
In-Reply-To: <1445247083.91.0.927080887762.issue25439@psf.upfronthosting.co.za>
Message-ID: <1445250855.66.0.611879820907.issue25439@psf.upfronthosting.co.za>


Martin Panter added the comment:

Type checking on the URL should be reasonably straightforward.

For the request data, the question is what types do we currently support? This may be a can of worms. We would have to be careful not to break existing use cases, even undocumented ones.

Looking at Issue 23740, the underlying ?http.client? accepts a variety of data types (bytes, Latin-1 str, iterables, files), and this support varies depending if the Content-Length header is supplied. I don?t think all combinations work with urlopen(), but judging by Issue 5038, there is at least partial support for bytes-like, iterables, and file objects.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25439>
_______________________________________

From report at bugs.python.org  Mon Oct 19 12:44:49 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 19 Oct 2015 10:44:49 +0000
Subject: [issue25439] Add type checks to urllib.request.Request
In-Reply-To: <1445247083.91.0.927080887762.issue25439@psf.upfronthosting.co.za>
Message-ID: <1445251489.21.0.752311110824.issue25439@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> For the request data, the question is what types do we currently support?

This is what I was wondering as well.  The doc says "data must be a bytes object specifying additional data to send to the server, or None if no such data is needed."[0]
However one of the error messages says "POST data should be bytes or an iterable of bytes." and "Content-Length should be specified for iterable data" so iterables of bytes also seem to be supported.
One option is to simply reject str and dict (or mappings in general), since these seem to me the two most likely errors (the first in case the user forgot to encode the output of urlencode(), the second in case the user forgot urlencode() altogether and passed a dict).

[0]: https://docs.python.org/3/library/urllib.request.html#urllib.request.Request

----------

_______________________________________
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: [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 14:06:33 2015
From: report at bugs.python.org (jan matejek)
Date: Mon, 19 Oct 2015 12:06:33 +0000
Subject: [issue25420] "import random" blocks on entropy collection on Linux
 with low entropy
In-Reply-To: <1445202553.12.0.050681981834.issue25420@psf.upfronthosting.co.za>
Message-ID: <5624DCCD.8040505@suse.cz>


jan matejek added the comment:

On 18.10.2015 23:09, STINNER Victor wrote:
> Hum ok, so your issue is specific to Linux.

yes, should have specified that, sorry

> Hum, the problem was already fixed some months/years ago: you must attach a RNG virtio device to your VM. Python is just one example, a lot of applications need entropy.

i disagree that this is a good solution; similar to your haveged 
suggestion, this is a workaround.

Unless a program specifically uses randomness, it should not need to 
read any entropy. For the python runtime itself, this is preventable by 
setting fixed PYTHONHASHSEED. For `random` module, there is no clean way 
to prevent it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25420>
_______________________________________

From report at bugs.python.org  Mon Oct 19 14:15:47 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Oct 2015 12:15:47 +0000
Subject: [issue25440] python3.4-config --extension-suffix not expanded
In-Reply-To: <1445256286.32.0.301975796809.issue25440@psf.upfronthosting.co.za>
Message-ID: <20151019121539.75261.14445@psf.io>


Roundup Robot added the comment:

New changeset 74b6b19e52b4 by doko in branch '3.4':
- Issue #25440: Fix output of python-config --extension-suffix.
https://hg.python.org/cpython/rev/74b6b19e52b4

New changeset 40aba0cda7b6 by doko in branch '3.5':
- Issue #25440: Fix output of python-config --extension-suffix.
https://hg.python.org/cpython/rev/40aba0cda7b6

New changeset dd1abadb1325 by doko in branch 'default':
- Issue #25440: Fix output of python-config --extension-suffix.
https://hg.python.org/cpython/rev/dd1abadb1325

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25440>
_______________________________________

From report at bugs.python.org  Mon Oct 19 14:17:18 2015
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 19 Oct 2015 12:17:18 +0000
Subject: [issue25440] python3.4-config --extension-suffix not expanded
In-Reply-To: <1445256286.32.0.301975796809.issue25440@psf.upfronthosting.co.za>
Message-ID: <1445257038.31.0.230578534609.issue25440@psf.upfronthosting.co.za>


Changes by Matthias Klose <doko at debian.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25440>
_______________________________________

From report at bugs.python.org  Mon Oct 19 15:15:29 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Oct 2015 13:15:29 +0000
Subject: [issue25420] "import random" blocks on entropy collection on Linux
 with low entropy
In-Reply-To: <5624DCCD.8040505@suse.cz>
Message-ID: <CAMpsgwYSxx8QcePC=a=scGAEXNnBZ7UQJ8K_DpJap4z9pZn4Uw@mail.gmail.com>


STINNER Victor added the comment:

If your OS has no entropy at all, you will have much more severe
issue. For example, don't try to generate a SSH key or established a
SSL/TLS session.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25420>
_______________________________________

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: [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 16:46:57 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 19 Oct 2015 14:46:57 +0000
Subject: [issue25441] StreamWriter.drain() unreliably reports closed sockets
In-Reply-To: <1445263930.02.0.0288344927045.issue25441@psf.upfronthosting.co.za>
Message-ID: <1445266017.29.0.904114817253.issue25441@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

See also this upstream git issue: https://github.com/python/asyncio/issues/263. Let me know whether the patch suggested there works for you, and I'll prioritize getting it checked in. (Help would also be appreciated, e.g. in the form of a unittest.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25441>
_______________________________________

From report at bugs.python.org  Mon Oct 19 16:47:14 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 19 Oct 2015 14:47:14 +0000
Subject: [issue25441] StreamWriter.drain() unreliably reports closed sockets
In-Reply-To: <1445263930.02.0.0288344927045.issue25441@psf.upfronthosting.co.za>
Message-ID: <1445266034.24.0.279524273056.issue25441@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
versions: +Python 3.4, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25441>
_______________________________________

From report at bugs.python.org  Mon Oct 19 17:23:10 2015
From: report at bugs.python.org (Daniel Waites)
Date: Mon, 19 Oct 2015 15:23:10 +0000
Subject: [issue25437] Issue with ftplib.FTP_TLS and server forcing SSL
 connection reuse
In-Reply-To: <1445197458.2.0.693285034257.issue25437@psf.upfronthosting.co.za>
Message-ID: <1445268190.88.0.332863101059.issue25437@psf.upfronthosting.co.za>


Changes by Daniel Waites <bigdwaites at gmail.com>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25437>
_______________________________________

From report at bugs.python.org  Mon Oct 19 17:31:56 2015
From: report at bugs.python.org (Jan Malte)
Date: Mon, 19 Oct 2015 15:31:56 +0000
Subject: [issue22684] message.as_bytes() produces recursion depth exceeded
In-Reply-To: <1413894566.0.0.84714989702.issue22684@psf.upfronthosting.co.za>
Message-ID: <1445268716.45.0.59907285642.issue22684@psf.upfronthosting.co.za>


Jan Malte added the comment:

for the same objects as_string() is working correctly

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22684>
_______________________________________

From report at bugs.python.org  Mon Oct 19 18:19:53 2015
From: report at bugs.python.org (Sebastien Bourdeauducq)
Date: Mon, 19 Oct 2015 16:19:53 +0000
Subject: [issue25441] StreamWriter.drain() unreliably reports closed sockets
In-Reply-To: <1445263930.02.0.0288344927045.issue25441@psf.upfronthosting.co.za>
Message-ID: <1445271593.32.0.6996962192.issue25441@psf.upfronthosting.co.za>


Sebastien Bourdeauducq added the comment:

Yes, this patch fixes the problem (in both this example and my real application). Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25441>
_______________________________________

From report at bugs.python.org  Mon Oct 19 18:38:04 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 19 Oct 2015 16:38:04 +0000
Subject: [issue25154] Drop the pyvenv script
In-Reply-To: <1442514921.37.0.255858283829.issue25154@psf.upfronthosting.co.za>
Message-ID: <1445272684.11.0.760020163543.issue25154@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I have a typo in my commit where I accidentally placed the file argument in str.format() instead of for print() (pointed out on GitHub).

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25154>
_______________________________________

From report at bugs.python.org  Mon Oct 19 21:02:16 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 19 Oct 2015 19:02:16 +0000
Subject: [issue25441] StreamWriter.drain() unreliably reports closed sockets
In-Reply-To: <1445263930.02.0.0288344927045.issue25441@psf.upfronthosting.co.za>
Message-ID: <1445281336.86.0.677279414232.issue25441@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Fixed by 17f76258d11d, d30fbc55194d and 08adb4056b5f.

----------
assignee:  -> gvanrossum
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25441>
_______________________________________

From report at bugs.python.org  Mon Oct 19 21:10:21 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Oct 2015 19:10:21 +0000
Subject: [issue25441] StreamWriter.drain() unreliably reports closed sockets
In-Reply-To: <1445263930.02.0.0288344927045.issue25441@psf.upfronthosting.co.za>
Message-ID: <20151019190113.20761.35746@psf.io>


Roundup Robot added the comment:

New changeset 17f76258d11d by Guido van Rossum in branch '3.4':
Issue #25441: asyncio: Raise error from drain() when socket is closed.
https://hg.python.org/cpython/rev/17f76258d11d

New changeset d30fbc55194d by Guido van Rossum in branch '3.5':
Issue #25441: asyncio: Raise error from drain() when socket is closed. (Merge 3.4->3.5)
https://hg.python.org/cpython/rev/d30fbc55194d

New changeset 08adb4056b5f by Guido van Rossum in branch 'default':
Issue #25441: asyncio: Raise error from drain() when socket is closed. (Merge 3.5->3.6)
https://hg.python.org/cpython/rev/08adb4056b5f

----------
nosy: +python-dev

_______________________________________
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: [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  Mon Oct 19 22:04:23 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Oct 2015 20:04:23 +0000
Subject: [issue22684] message.as_bytes() produces recursion depth exceeded
In-Reply-To: <1413894566.0.0.84714989702.issue22684@psf.upfronthosting.co.za>
Message-ID: <1445285063.92.0.173522978952.issue22684@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is minimized example.

from email._header_value_parser import *
al = AddressList([Address([Mailbox([NameAddr([DisplayName([Atom([ValueTerminal('example', 'atext'), CFWSList([WhiteSpaceTerminal('\t', 'fws')])])]), AngleAddr([ValueTerminal('<', 'angle-addr-start'), AddrSpec([LocalPart([DotAtom([DotAtomText([ValueTerminal('very-very-very-very-very-very-very-very-very-very-very-very-long', 'atext')])])]), ValueTerminal('@', 'address-at-symbol'), Domain([DotAtom([DotAtomText([ValueTerminal('example', 'atext'), ValueTerminal('.', 'dot'), ValueTerminal('org', 'atext')])])])]), ValueTerminal('>', 'angle-addr-end')])])])]), ValueTerminal(',', 'list-separator'), Address([Mailbox([NameAddr([AngleAddr([CFWSList([WhiteSpaceTerminal('\t', 'fws')]), ValueTerminal('<', 'angle-addr-start'), AddrSpec([LocalPart([DotAtom([DotAtomText([ValueTerminal('very-very-very-very-very-very-very-very-very-very-very-very-long', 'atext')])])]), ValueTerminal('@', 'address-at-symbol'), Domain([DotAtom([DotAtomText([ValueTerminal('example', 'atext'), ValueTerminal('.', 'dot'), ValueTerminal('org', 'atext')])])])]), ValueTerminal('>', 'angle-addr-end')])])])])])
import email.policy
al.fold(policy=email.policy.default)

----------
nosy: +serhiy.storchaka
Added file: http://bugs.python.org/file40814/msg.mbox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22684>
_______________________________________

From report at bugs.python.org  Mon Oct 19 22:12:06 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 19 Oct 2015 20:12:06 +0000
Subject: [issue24885] StreamReaderProtocol docs recommend using private API
In-Reply-To: <1439891310.64.0.826592232629.issue24885@psf.upfronthosting.co.za>
Message-ID: <1445285526.77.0.723745264893.issue24885@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I just re-read the docs here (which came straight from the open_connection() docstring). The parenthetical remark is confusing -- I meant something more like

"""
If you want to use different classes than StreamReader, StreamReaderProtocol and StreamWriter, just copy the code of open_connection() and substitute your own classes.
"""

That is, the customization it is trying to refer to is open_connection(), not the classes.

FWIW I think subclassing implementation classes is a dangerous practice and shouldn't be encouraged.

Because the same reasoning applies to all the top-level functions here (but not to the classes), I think I'll delete the offending paragraph and replace it with something like the following at the top of the docs for this module:

"""
The top-level functions in this module are meant convenience wrappers only; there's really nothing special there, and if they don't do what you want feel free to copy their code.
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24885>
_______________________________________

From report at bugs.python.org  Mon Oct 19 22:20:05 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Oct 2015 20:20:05 +0000
Subject: [issue24885] StreamReaderProtocol docs recommend using private API
In-Reply-To: <1439891310.64.0.826592232629.issue24885@psf.upfronthosting.co.za>
Message-ID: <20151019202000.7246.77758@psf.io>


Roundup Robot added the comment:

New changeset d91208957e4e by Guido van Rossum in branch '3.4':
Issue #24885: Update note in docs about stream convenience functions.
https://hg.python.org/cpython/rev/d91208957e4e

New changeset 43c63dd2f383 by Guido van Rossum in branch '3.5':
Issue #24885: Update note in docs about stream convenience functions. (Merge 3.4->3.5)
https://hg.python.org/cpython/rev/43c63dd2f383

New changeset 7947f43a1a87 by Guido van Rossum in branch 'default':
Issue #24885: Update note in docs about stream convenience functions. (Merge 3.5->3.6)
https://hg.python.org/cpython/rev/7947f43a1a87

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24885>
_______________________________________

From report at bugs.python.org  Mon Oct 19 22:22:21 2015
From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=)
Date: Mon, 19 Oct 2015 20:22:21 +0000
Subject: [issue16500] Add an 'atfork' module
In-Reply-To: <1353252005.31.0.454056781872.issue16500@psf.upfronthosting.co.za>
Message-ID: <1445286141.19.0.400219615058.issue16500@psf.upfronthosting.co.za>


Changes by Ionel Cristian M?rie? <contact at ionelmc.ro>:


----------
nosy: +ionelmc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16500>
_______________________________________

From report at bugs.python.org  Mon Oct 19 22:54:03 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 19 Oct 2015 20:54:03 +0000
Subject: [issue24885] StreamReaderProtocol docs recommend using private API
In-Reply-To: <1439891310.64.0.826592232629.issue24885@psf.upfronthosting.co.za>
Message-ID: <1445288043.83.0.456149660061.issue24885@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
assignee:  -> gvanrossum
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24885>
_______________________________________

From report at bugs.python.org  Mon Oct 19 23:05:22 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Oct 2015 21:05:22 +0000
Subject: [issue22684] message.as_bytes() produces recursion depth exceeded
In-Reply-To: <1413894566.0.0.84714989702.issue22684@psf.upfronthosting.co.za>
Message-ID: <1445288722.11.0.864857144296.issue22684@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Even more minimized artificial example:

from email._header_value_parser import *
import email.policy
tl = TokenList([
    TokenList([
        ValueTerminal('x', 'atext'),
        WhiteSpaceTerminal(' ', 'fws'),
        ValueTerminal('x'*76, 'atext'),
    ]),
    ValueTerminal(',', 'list-separator')
])
tl.fold(policy=email.policy.default)

list(tl.parts)[0] == tl and tl.has_fws is True, so TokenList._fold() is called recursively with the same argument.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22684>
_______________________________________

From report at bugs.python.org  Mon Oct 19 23:17:15 2015
From: report at bugs.python.org (paul j3)
Date: Mon, 19 Oct 2015 21:17:15 +0000
Subject: [issue25436] argparse.ArgumentError missing error message in __repr__
In-Reply-To: <1445196585.11.0.0454648926496.issue25436@psf.upfronthosting.co.za>
Message-ID: <1445289435.45.0.735396812338.issue25436@psf.upfronthosting.co.za>


paul j3 added the comment:

The short `repr` is produced in Python2.7, but not 3.5.

Your test case:

    action = argparse._StoreAction(['--file], dest='file_path')
    error = argparse.ArgumentError(action, 'File not found.')
    print(str(error))
    print(repr(error))

With Python3.5 this displays:

    argument --file: File not found.

    ArgumentError(_StoreAction(option_strings=['--file'],
       dest='file_path', nargs=None, const=None, default=None,
       type=None, choices=None, help=None, metavar=None), 
       'File not found.')

In Python2.7 the `repr()` produces:

    ArgumentError()

Your patch changes the `repr` to:

    ArgumentError('File not found.', '--file')

I think you could achieve the same effect by defining a `__repr__` method for `ArgumentError`.  

By the way, to produce such an Action, you would normally use:

    parser.add_argument('--file')

'--file=/foo/bar' is not a good argument option flag.  The code may accept it, but it will confuse your users.


--------------

Normally an `ArgumentError` is raised during parsing, and is caught at the end of `parse_known_args` with:

        except ArgumentError:
            err = _sys.exc_info()[1]
            self.error(str(err))

So its `str()` is passed on the the `parser.error` method (and on to `parser.exit`).  Normally a user, or developer's code will not see this error class.

The purpose of `ArgumentError` is to clearly identify a class of error, and to add the `Action` identity to the error message.  It's part of the API so custom Action classes can use it to pass errors through the normal parsing error system.

Can you make a better case for needing an improved `repr`?  How would it be logged or otherwise be made visible to users and/or developers?

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25436>
_______________________________________

From report at bugs.python.org  Mon Oct 19 23:18:28 2015
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 19 Oct 2015 21:18:28 +0000
Subject: [issue18673] Add O_TMPFILE to os module
In-Reply-To: <1375818220.16.0.883591943761.issue18673@psf.upfronthosting.co.za>
Message-ID: <1445289508.01.0.61861317198.issue18673@psf.upfronthosting.co.za>


???? ????????? added the comment:

Just for link. Issue #21515 ? tempfile use this functionality now.

----------
nosy: +mmarkk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18673>
_______________________________________

From report at bugs.python.org  Mon Oct 19 23:21:30 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 19 Oct 2015 21:21:30 +0000
Subject: [issue25442] Shelve consistency issues
In-Reply-To: <1445284348.45.0.829357698435.issue25442@psf.upfronthosting.co.za>
Message-ID: <1445289690.56.0.105073880535.issue25442@psf.upfronthosting.co.za>


R. David Murray added the comment:

Shelve does not itself implement any database, but it does *use* a database[*].  Any aspects of this must be directed toward the underlying database library used.  In particular, it is not part of the shelve API to know anything about any possible underlying file or files, nor is it *necessarily* the case that there is pending data to be flushed on close.

So, if you want to suggest a documentation enhancement, it should to make reference to the issue and point the user at the documentation for the underlying database they choose to use for more information.

[*] There is an open issue proposing an sqlite backend for shelve, but no one so far has had the motivation to finish it.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25442>
_______________________________________

From report at bugs.python.org  Mon Oct 19 23:28:35 2015
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 19 Oct 2015 21:28:35 +0000
Subject: [issue21515] Use Linux O_TMPFILE flag in tempfile.TemporaryFile?
In-Reply-To: <1400231841.29.0.337128735098.issue21515@psf.upfronthosting.co.za>
Message-ID: <1445290115.25.0.699822324918.issue21515@psf.upfronthosting.co.za>


???? ????????? added the comment:

Suppose conditions:
- Old linux kernel ignoring flag
- malicious hacker force use of PLAIN FILE instead of directory

On new kernel it will fail
On old kernel it will just open that file!

So, we can make a HACK! Just add last slash to directory name. This will not hurt on new kernels, but protect on old kernels.

tests should also test a case when directory is symlink really.

----------
nosy: +mmarkk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21515>
_______________________________________

From report at bugs.python.org  Mon Oct 19 23:33:22 2015
From: report at bugs.python.org (paul j3)
Date: Mon, 19 Oct 2015 21:33:22 +0000
Subject: [issue11174] add argparse formatting option to display type names for
 metavar
In-Reply-To: <1297352753.29.0.422535680818.issue11174@psf.upfronthosting.co.za>
Message-ID: <1445290402.69.0.494136055053.issue11174@psf.upfronthosting.co.za>


paul j3 added the comment:

This formatter produces an error if one or more of the arguments uses the default `None` type (a string).   This is because `None` does not have a `.__name__`.

This HelpFormatter probably has been rarely, if ever, used.  The metavar parameter works just as well.

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11174>
_______________________________________

From report at bugs.python.org  Mon Oct 19 23:56:46 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Oct 2015 21:56:46 +0000
Subject: [issue25390] Can't define a typing.Union containing a
 typing.re.Pattern
In-Reply-To: <1444728467.55.0.552197008785.issue25390@psf.upfronthosting.co.za>
Message-ID: <20151019215643.117274.79547@psf.io>


Roundup Robot added the comment:

New changeset 955d3faf727a by Guido van Rossum in branch '3.5':
Issue #25390: typing: Don't crash on Union[str, Pattern].
https://hg.python.org/cpython/rev/955d3faf727a

New changeset 04314479af0b by Guido van Rossum in branch 'default':
Issue #25390: typing: Don't crash on Union[str, Pattern]. (Merge 3.5->3.6)
https://hg.python.org/cpython/rev/04314479af0b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25390>
_______________________________________

From report at bugs.python.org  Mon Oct 19 23:57:04 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 19 Oct 2015 21:57:04 +0000
Subject: [issue25390] Can't define a typing.Union containing a
 typing.re.Pattern
In-Reply-To: <1444728467.55.0.552197008785.issue25390@psf.upfronthosting.co.za>
Message-ID: <1445291824.19.0.436383125494.issue25390@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25390>
_______________________________________

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: [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 02:58:07 2015
From: report at bugs.python.org (Yanyan Jiang)
Date: Tue, 20 Oct 2015 00:58:07 +0000
Subject: [issue25442] Shelve consistency issues
In-Reply-To: <1445284348.45.0.829357698435.issue25442@psf.upfronthosting.co.za>
Message-ID: <1445302687.68.0.160711308631.issue25442@psf.upfronthosting.co.za>


Yanyan Jiang added the comment:

Thanks for reminding. It is originally reported with the default setting. We conducted further tests with other options of anydbm (dbhash, dbm, gdbm), none of them survived crash testing. For the detailed reasoning please refer to an OSDI'14 research paper: https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-pillai.pdf
 This paper discussed vulnerabilities of GDBM implementation in that paper, and these lightweight db implementations have similar problems. We also have tests SQLite, and it is much more robust that we have not found ACID violation yet.

Personally I think it is reasonable to have an SQLite backend, as it is much safer (plus providing thread safety). Just to see what I can do for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25442>
_______________________________________

From report at bugs.python.org  Tue Oct 20 04:07:47 2015
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 20 Oct 2015 02:07:47 +0000
Subject: [issue25177] OverflowError in statistics.mean when summing large
 floats
In-Reply-To: <1442662840.23.0.781753910755.issue25177@psf.upfronthosting.co.za>
Message-ID: <1445306867.29.0.649483224256.issue25177@psf.upfronthosting.co.za>


Changes by Steven D'Aprano <steve+python at pearwood.info>:


----------
assignee:  -> steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25177>
_______________________________________

From report at bugs.python.org  Tue Oct 20 04:09:39 2015
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 20 Oct 2015 02:09:39 +0000
Subject: [issue20499] Rounding errors with statistics.variance
In-Reply-To: <1391431579.33.0.244887922603.issue20499@psf.upfronthosting.co.za>
Message-ID: <1445306979.22.0.190182634058.issue20499@psf.upfronthosting.co.za>


Changes by Steven D'Aprano <steve+python at pearwood.info>:


----------
assignee:  -> steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20499>
_______________________________________

From report at bugs.python.org  Tue Oct 20 04:18:41 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 20 Oct 2015 02:18:41 +0000
Subject: [issue25177] OverflowError in statistics.mean when summing large
 floats
In-Reply-To: <1442662840.23.0.781753910755.issue25177@psf.upfronthosting.co.za>
Message-ID: <1445307521.46.0.757584771512.issue25177@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Do you have any benchmarks on the before and after? I strongly suspect that moving from float to Fraction-based ratios is going to kill performance in the common case, particularly for longer input sequences, but that's a hunch only.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25177>
_______________________________________

From report at bugs.python.org  Tue Oct 20 04:54:39 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 20 Oct 2015 02:54:39 +0000
Subject: [issue25435] Wrong function calls and referring to not removed
 concepts in descriptor HowTo (documentation)
In-Reply-To: <1445194189.09.0.0973348556564.issue25435@psf.upfronthosting.co.za>
Message-ID: <1445309679.51.0.496533201944.issue25435@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25435>
_______________________________________

From report at bugs.python.org  Tue Oct 20 04:55:22 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 20 Oct 2015 02:55:22 +0000
Subject: [issue25435] Wrong function calls and referring to not removed
 concepts in descriptor HowTo (documentation)
In-Reply-To: <1445194189.09.0.0973348556564.issue25435@psf.upfronthosting.co.za>
Message-ID: <1445309722.27.0.11629147255.issue25435@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I'll update this document to reflect the current state of the world.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25435>
_______________________________________

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: [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 06:58:19 2015
From: report at bugs.python.org (Nils Lindemann)
Date: Tue, 20 Oct 2015 04:58:19 +0000
Subject: [issue25444] Py Launch Icon
In-Reply-To: <1445315488.63.0.0387362218843.issue25444@psf.upfronthosting.co.za>
Message-ID: <1445317099.74.0.627160849334.issue25444@psf.upfronthosting.co.za>


Nils Lindemann added the comment:

Hm actually an alternative icon for idle can be useful to separate it from command lines in the task bar. But a special launcher symbol is not necessary in my opinion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25444>
_______________________________________

From report at bugs.python.org  Tue Oct 20 07:56:20 2015
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 20 Oct 2015 05:56:20 +0000
Subject: [issue25420] "import random" blocks on entropy collection on Linux
 with low entropy
In-Reply-To: <1445003396.34.0.246344104115.issue25420@psf.upfronthosting.co.za>
Message-ID: <1445320580.63.0.781857456755.issue25420@psf.upfronthosting.co.za>


???? ????????? added the comment:

Just install rngd and setup it to user /dev/urandom as entropy source. I think thread is closed :)

----------
nosy: +mmarkk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25420>
_______________________________________

From report at bugs.python.org  Tue Oct 20 08:08:40 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Oct 2015 06:08:40 +0000
Subject: [issue25420] "import random" blocks on entropy collection on Linux
 with low entropy
In-Reply-To: <1445320580.63.0.781857456755.issue25420@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZ-QB4qMZwN-yFgyudxhOvK93Ry5-Jv=uRDv63NfphFBA@mail.gmail.com>


STINNER Victor added the comment:

I knew the subtle difference between reading from /dev/urandom and
getrandom() syscall: the syscall hangs until /dev/urandom is feeded with
enough entropy. It should be documented in Whats New, os.urandom and maybe
also random doc. Not only python 3.5 was affected by the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25420>
_______________________________________

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: [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 08:16:25 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 20 Oct 2015 06:16:25 +0000
Subject: [issue24782] Merge 'configure extensions' into main IDLE config dialog
In-Reply-To: <1438549617.46.0.760286591646.issue24782@psf.upfronthosting.co.za>
Message-ID: <20151020061621.117262.23021@psf.io>


Roundup Robot added the comment:

New changeset 8953a42c2ac4 by Terry Jan Reedy in branch '2.7':
Issue #24782: Don't try to run now-removed extension dialog test.
https://hg.python.org/cpython/rev/8953a42c2ac4

New changeset 4bf862fc10a5 by Terry Jan Reedy in branch '3.4':
Issue #24782: Don't try to run now-removed extension dialog test.
https://hg.python.org/cpython/rev/4bf862fc10a5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24782>
_______________________________________

From report at bugs.python.org  Tue Oct 20 08:16:32 2015
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 20 Oct 2015 06:16:32 +0000
Subject: [issue25420] "import random" blocks on entropy collection on Linux
 with low entropy
In-Reply-To: <1445003396.34.0.246344104115.issue25420@psf.upfronthosting.co.za>
Message-ID: <1445321792.33.0.31258617461.issue25420@psf.upfronthosting.co.za>


???? ????????? added the comment:

Man getrandom()     

As of Linux 3.19, the following bug exists:

       *  Depending on CPU load, getrandom() does not react to interrupts
          before reading all bytes requested.


So, is it goot to use this syscall now?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25420>
_______________________________________

From report at bugs.python.org  Tue Oct 20 08:17:55 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 20 Oct 2015 06:17:55 +0000
Subject: [issue24782] Merge 'configure extensions' into main IDLE config dialog
In-Reply-To: <1438549617.46.0.760286591646.issue24782@psf.upfronthosting.co.za>
Message-ID: <1445321875.12.0.179374160492.issue24782@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

There are two 'width=250' settings, which I tried changing to 150, with no effect, so there is something else making the dialog wider than before.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24782>
_______________________________________

From report at bugs.python.org  Tue Oct 20 08:44:40 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Oct 2015 06:44:40 +0000
Subject: [issue25177] OverflowError in statistics.mean when summing large
 floats
In-Reply-To: <1442662840.23.0.781753910755.issue25177@psf.upfronthosting.co.za>
Message-ID: <1445323480.63.0.859260712266.issue25177@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> I strongly suspect that moving from float to Fraction-based ratios is going to kill performance in the common case

The existing code already converts each of the input items to Fraction; the only difference is that the old code converts the sum of those Fractions to float (or whatever the target type is) *before* dividing by the count, while the new code performs the sum/count division in Fraction-land, and only *then* converts to float.  That is, it's the difference between "float(exact_sum) / count" and "float(exact_sum / count)".

IOW, the performance is already dead.  Or rather, it's just resting: IIUC, the module design prioritises correctness over speed.  I'm sure Steven would be open to suggestions for faster algorithms that maintain the current accuracy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25177>
_______________________________________

From report at bugs.python.org  Tue Oct 20 08:48:53 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 20 Oct 2015 06:48:53 +0000
Subject: [issue25420] "import random" blocks on entropy collection on Linux
 with low entropy
In-Reply-To: <1445003396.34.0.246344104115.issue25420@psf.upfronthosting.co.za>
Message-ID: <1445323733.77.0.165459873026.issue25420@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25420>
_______________________________________

From report at bugs.python.org  Tue Oct 20 09:47:25 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Oct 2015 07:47:25 +0000
Subject: [issue25420] "import random" blocks on entropy collection on Linux
 with low entropy
In-Reply-To: <1445321792.33.0.31258617461.issue25420@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbEzZupakZjqGU2vZ5_nx9awNrHeVLWQEfL2BGYOrFa1Q@mail.gmail.com>


STINNER Victor added the comment:

Hi,

???? ????????? added the comment:
> Man getrandom()
>
> As of Linux 3.19, the following bug exists:
>
>        *  Depending on CPU load, getrandom() does not react to interrupts
>           before reading all bytes requested.
>
> So, is it goot to use this syscall now?

I saw a fix proposed on the LKML but it looks like it was not merged.
I don't know what to think about this bug.

getrandom(n, GRND_NONBLOCK) behaviour depends if /dev/urandom was
feeded with enough entropy and the value of n. It should not be
interrupted by signal for n <= 256.

Can you reproduce the bug? Which kind of applications can hang because
of this bug?

I would prefer to continue to use getrandom() syscall on Linux, avoid
using a file descriptor is really useful.

Maybe we can try to document the behaviour of os.urandom() for signal
handling? Or at least redirect users to getrandom() manual page.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25420>
_______________________________________

From report at bugs.python.org  Tue Oct 20 09:54:21 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Oct 2015 07:54:21 +0000
Subject: [issue21515] Use Linux O_TMPFILE flag in tempfile.TemporaryFile?
In-Reply-To: <1400231841.29.0.337128735098.issue21515@psf.upfronthosting.co.za>
Message-ID: <1445327661.53.0.0719362186468.issue21515@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Suppose conditions:
> - Old linux kernel ignoring flag
> - malicious hacker force use of PLAIN FILE instead of directory

Is it a theorical bug, or are you able to reproduce it?

Old Linux kernel ignores the 0o20000000 bit but O_TMPFILE is 0o20000000 | os.O_DIRECTORY. So the kernel still ensures that the path is a directory. tempfile.TemporaryFile() tries to open the path with:

   os.open(path, os.O_RDWR |os.O_EXCL | os.O_TMPFILE)

if the 0o20000000 bit is ignored by old kernel, it becomes:

   os.open(path, os.O_RDWR |os.O_EXCL | os.O_DIRECTORY)

You cannot open a regular file with these flags:

>>> open('x', 'w').close()
>>> os.open('x', os.O_RDWR |os.O_EXCL | os.O_DIRECTORY)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NotADirectoryError: [Errno 20] Not a directory: 'x'

You cannot open a directory with these flags:

>>> os.open('.', os.O_RDWR |os.O_EXCL | os.O_DIRECTORY)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IsADirectoryError: [Errno 21] Is a directory: '.'

Same behaviour for symbolic link to a regular file or to a directory.

Please open a new issue if you consider that you found a bug, but please write a short script reproducing the bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21515>
_______________________________________

From report at bugs.python.org  Tue Oct 20 10:02:32 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Oct 2015 08:02:32 +0000
Subject: [issue25420] "import random" blocks on entropy collection on Linux
 with low entropy
In-Reply-To: <1445003396.34.0.246344104115.issue25420@psf.upfronthosting.co.za>
Message-ID: <1445328152.82.0.320673928166.issue25420@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The RNG is seeded from os.urandom, which as of python 3.5 uses the potentially blocking getrandom() call.

Here is a patch for os.urandom() documentation. What do you think?

----------
keywords: +patch
Added file: http://bugs.python.org/file40816/urandom.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25420>
_______________________________________

From report at bugs.python.org  Tue Oct 20 13:56:04 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 20 Oct 2015 11:56:04 +0000
Subject: [issue25442] Shelve consistency issues
In-Reply-To: <1445284348.45.0.829357698435.issue25442@psf.upfronthosting.co.za>
Message-ID: <1445342164.2.0.547882006044.issue25442@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yeah, if we had an sqlite backend I think we'd make it the default if sqlite was available.  There's a proof of concept implementation in the open issue 3783.  I'm not sure what remains to be done (other than docs)...I didn't read through the issue and there's a fair bit of discussion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25442>
_______________________________________

From report at bugs.python.org  Tue Oct 20 13:59:41 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 20 Oct 2015 11:59:41 +0000
Subject: [issue25445] type xterm in python
In-Reply-To: <1445321729.67.0.92223592464.issue25445@psf.upfronthosting.co.za>
Message-ID: <1445342381.34.0.958508042287.issue25445@psf.upfronthosting.co.za>


R. David Murray added the comment:

For programming help you should post to the python-tutor or python-list mailing lists.  This issue tracker is for reporting bugs.

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25445>
_______________________________________

From report at bugs.python.org  Tue Oct 20 15:41:52 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 20 Oct 2015 13:41:52 +0000
Subject: [issue25410] Clean up and fix OrderedDict
In-Reply-To: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za>
Message-ID: <1445348512.66.0.474268775614.issue25410@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Seems there is a leak in _odict_add_new_node() when PyObject_Hash(key) fails. Here is a fix.

----------
stage: commit review -> patch review
Added file: http://bugs.python.org/file40817/odict_add_new_node_leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25410>
_______________________________________

From report at bugs.python.org  Tue Oct 20 16:48:33 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 20 Oct 2015 14:48:33 +0000
Subject: [issue25410] Clean up and fix OrderedDict
In-Reply-To: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za>
Message-ID: <1445352513.87.0.70694927411.issue25410@psf.upfronthosting.co.za>


Eric Snow added the comment:

both patches* LGTM

* odict_type.patch and odict_add_new_node_leak.patch

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25410>
_______________________________________

From report at bugs.python.org  Tue Oct 20 16:50:46 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 20 Oct 2015 14:50:46 +0000
Subject: [issue25410] Clean up and fix OrderedDict
In-Reply-To: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za>
Message-ID: <1445352646.92.0.867664720022.issue25410@psf.upfronthosting.co.za>


Eric Snow added the comment:

And thanks again, Serhiy, for taking the time on this. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25410>
_______________________________________

From report at bugs.python.org  Tue Oct 20 17:00:16 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 20 Oct 2015 15:00:16 +0000
Subject: [issue25395] SIGSEGV using json.tool: highly nested OrderedDict
In-Reply-To: <1444765181.78.0.70980847428.issue25395@psf.upfronthosting.co.za>
Message-ID: <1445353216.53.0.80605030981.issue25395@psf.upfronthosting.co.za>


Eric Snow added the comment:

Thanks for solving this!

odict-trashcan.v3.patch LGTM

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25395>
_______________________________________

From report at bugs.python.org  Tue Oct 20 17:24:07 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 20 Oct 2015 15:24:07 +0000
Subject: [issue25410] Clean up and fix OrderedDict
In-Reply-To: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za>
Message-ID: <20151020152343.75263.33378@psf.io>


Roundup Robot added the comment:

New changeset 93f948120773 by Serhiy Storchaka in branch '3.5':
Issue #25410: Fixed a memory leak in OrderedDict in the case when key's hash
https://hg.python.org/cpython/rev/93f948120773

New changeset c3cec0f77eff by Serhiy Storchaka in branch 'default':
Issue #25410: Fixed a memory leak in OrderedDict in the case when key's hash
https://hg.python.org/cpython/rev/c3cec0f77eff

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25410>
_______________________________________

From report at bugs.python.org  Tue Oct 20 17:25:14 2015
From: report at bugs.python.org (jan matejek)
Date: Tue, 20 Oct 2015 15:25:14 +0000
Subject: [issue25420] "import random" blocks on entropy collection on Linux
 with low entropy
In-Reply-To: <1445003396.34.0.246344104115.issue25420@psf.upfronthosting.co.za>
Message-ID: <1445354714.39.0.593447430467.issue25420@psf.upfronthosting.co.za>


jan matejek added the comment:

let me reiterate that what I consider a bug is the fact that "import random" statement calls os.urandom (which per the proposed documentation may sometimes block)

IOW, "import random" may sometimes block, even though it is not actually used at any point (could be pulled in through some dependencies)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25420>
_______________________________________

From report at bugs.python.org  Tue Oct 20 17:29:26 2015
From: report at bugs.python.org (Stefano Taschini)
Date: Tue, 20 Oct 2015 15:29:26 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1445354966.13.0.281365672959.issue4709@psf.upfronthosting.co.za>


Changes by Stefano Taschini <taschini at ieee.org>:


----------
nosy: +taschini

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4709>
_______________________________________

From report at bugs.python.org  Tue Oct 20 17:35:22 2015
From: report at bugs.python.org (Nils Lindemann)
Date: Tue, 20 Oct 2015 15:35:22 +0000
Subject: [issue25444] Py Launch Icon
In-Reply-To: <1445315488.63.0.0387362218843.issue25444@psf.upfronthosting.co.za>
Message-ID: <1445355322.96.0.0467268261923.issue25444@psf.upfronthosting.co.za>


Nils Lindemann added the comment:

Here is also a zip containing the icons.

----------
Added file: http://bugs.python.org/file40818/icons.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25444>
_______________________________________

From report at bugs.python.org  Tue Oct 20 17:38:20 2015
From: report at bugs.python.org (Paul Moore)
Date: Tue, 20 Oct 2015 15:38:20 +0000
Subject: [issue25444] Py Launch Icon
In-Reply-To: <1445315488.63.0.0387362218843.issue25444@psf.upfronthosting.co.za>
Message-ID: <1445355500.61.0.368489174179.issue25444@psf.upfronthosting.co.za>


Paul Moore added the comment:

It's a very personal choice, but I prefer the current icons. I'm -1 on this change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25444>
_______________________________________

From report at bugs.python.org  Tue Oct 20 17:41:20 2015
From: report at bugs.python.org (Tim Golden)
Date: Tue, 20 Oct 2015 15:41:20 +0000
Subject: [issue25444] Py Launch Icon
In-Reply-To: <1445315488.63.0.0387362218843.issue25444@psf.upfronthosting.co.za>
Message-ID: <1445355680.95.0.612732443842.issue25444@psf.upfronthosting.co.za>


Changes by Tim Golden <mail at timgolden.me.uk>:


----------
nosy:  -tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25444>
_______________________________________

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: [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 17:44:18 2015
From: report at bugs.python.org (Paul Moore)
Date: Tue, 20 Oct 2015 15:44:18 +0000
Subject: [issue25444] Py Launch Icon
In-Reply-To: <1445315488.63.0.0387362218843.issue25444@psf.upfronthosting.co.za>
Message-ID: <1445355858.34.0.810224414538.issue25444@psf.upfronthosting.co.za>


Changes by Paul Moore <p.f.moore at gmail.com>:


----------
nosy:  -paul.moore

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25444>
_______________________________________

From report at bugs.python.org  Tue Oct 20 17:52:11 2015
From: report at bugs.python.org (Joe Jevnik)
Date: Tue, 20 Oct 2015 15:52:11 +0000
Subject: [issue23926] skipitem() in getargs.c still supports 'w' and 'w#',
 and shouldn't
In-Reply-To: <1428893040.89.0.319300847517.issue23926@psf.upfronthosting.co.za>
Message-ID: <1445356331.19.0.418628153953.issue23926@psf.upfronthosting.co.za>


Joe Jevnik added the comment:

bumping this issue

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23926>
_______________________________________

From report at bugs.python.org  Tue Oct 20 18:02:47 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 20 Oct 2015 16:02:47 +0000
Subject: [issue23926] skipitem() in getargs.c still supports 'w' and 'w#',
 and shouldn't
In-Reply-To: <1428893040.89.0.319300847517.issue23926@psf.upfronthosting.co.za>
Message-ID: <1445356967.18.0.768072502285.issue23926@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage: test needed -> patch review
type: crash -> behavior
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23926>
_______________________________________

From report at bugs.python.org  Tue Oct 20 18:03:47 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 20 Oct 2015 16:03:47 +0000
Subject: [issue25410] Clean up and fix OrderedDict
In-Reply-To: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za>
Message-ID: <1445357027.71.0.347642519592.issue25410@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your reviews and discussions (and for your appreciated C acceleration of OrderedDict of course) Eric. I just want to make the code a little cleaner and reliable.

As for odict_type.patch, I would prefer to commit only C part of the patch and left Python implementation unchanged. There few not very strong arguments for __class__ against type() in Python code.

1. Calling type() needs to make globals and builtins lookup. This is more than 2 times slower than access the __class__ attribute. Not critical for __repr__(), __reduce__() and copy().

2. If the code is invoked at shutdown after destroying the builtins module, type can be None. We already had issues with this in the past. In current Python such situation is almost impossible nevertheless, due to different defensive techniques.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25410>
_______________________________________

From report at bugs.python.org  Tue Oct 20 18:08:48 2015
From: report at bugs.python.org (Nils Lindemann)
Date: Tue, 20 Oct 2015 16:08:48 +0000
Subject: [issue25444] Py Launch Icon
In-Reply-To: <1445315488.63.0.0387362218843.issue25444@psf.upfronthosting.co.za>
Message-ID: <1445357328.04.0.113592281132.issue25444@psf.upfronthosting.co.za>


Nils Lindemann added the comment:

The icons are not intended to be used instead of the three default icons, please dont, these are just great.

I am just targeting the current launcher symbol:

* It contains a symbol of an instrument which can be used to kill people.
* in the 16x16 icon it is not clear at all what this is. it just looks like a smudge on the icon. When i first saw it i touched it to see if the smudge is on my screen.
* the symbol indicates that one is running the launcher. But thats not true, he is running the process that was launched by the launcher. So if this symbol is used for the exe which is the launcher, ok, but using it for all processes started with it is wrong in my opinion.

The icons for idle are just suggestions, using an alternative icon for idele, as i said, may be helpful to separate idle from command lines.

The alternative icons for the launcher are just thought as source of inspiration. Actually i think launched processes (except maybe idle) should use the standard py exe icon!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25444>
_______________________________________

From report at bugs.python.org  Tue Oct 20 18:14:51 2015
From: report at bugs.python.org (Nils Lindemann)
Date: Tue, 20 Oct 2015 16:14:51 +0000
Subject: [issue25444] Py Launch Icon
In-Reply-To: <1445315488.63.0.0387362218843.issue25444@psf.upfronthosting.co.za>
Message-ID: <1445357691.64.0.283012166088.issue25444@psf.upfronthosting.co.za>


Nils Lindemann added the comment:

let me reformulate it: my main intention is to get rid of the launcher symbol, or at least have a nicer looking symbol, i dont care for the idle symbol.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25444>
_______________________________________

From report at bugs.python.org  Tue Oct 20 18:26:20 2015
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 20 Oct 2015 16:26:20 +0000
Subject: [issue25420] "import random" blocks on entropy collection on Linux
 with low entropy
In-Reply-To: <1445003396.34.0.246344104115.issue25420@psf.upfronthosting.co.za>
Message-ID: <1445358380.05.0.625085839576.issue25420@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

I think Jan has a point there. An import should not cause the whole interpreter to hang.

Wouldn't it be possible to have the getrandom() call be done lazily to avoid this and only have it block when the RNG from the random is actually being used ?

Or alternatively, make things more robust by avoiding to call the API on systems which are known to have blocking problems and then reverting to using /dev/urandom directly instead ?

Note that the RNG does already use a fallback solution for systems which don't provide os.urandom. Also note that os.urandom() is documented (indirectly via man 4 urandom) to not be blocking. If it blocks on some systems, we should add a work-around for those, just like Python/random.c does for Solaris.

BTW: Is there a way to determine whether enough entropy has been gathered without doing a blocking call ? This could be used to find out whether getrandom() will potentially block.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25420>
_______________________________________

From report at bugs.python.org  Tue Oct 20 18:27:39 2015
From: report at bugs.python.org (Nan Wu)
Date: Tue, 20 Oct 2015 16:27:39 +0000
Subject: [issue25439] Add type checks to urllib.request.Request
In-Reply-To: <1445247083.91.0.927080887762.issue25439@psf.upfronthosting.co.za>
Message-ID: <1445358459.12.0.164541705118.issue25439@psf.upfronthosting.co.za>


Nan Wu added the comment:

Uploaded a patch. Also update the test. Seems there are at least two old test cases using empty dict as data param. has dict been supported before?

----------
keywords: +patch
nosy: +Nan Wu
Added file: http://bugs.python.org/file40819/urllib_request_param_type_check.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25439>
_______________________________________

From report at bugs.python.org  Tue Oct 20 18:30:50 2015
From: report at bugs.python.org (jan matejek)
Date: Tue, 20 Oct 2015 16:30:50 +0000
Subject: [issue25420] "import random" blocks on entropy collection on Linux
 with low entropy
In-Reply-To: <1445003396.34.0.246344104115.issue25420@psf.upfronthosting.co.za>
Message-ID: <1445358650.25.0.951583129615.issue25420@psf.upfronthosting.co.za>


jan matejek added the comment:

attaching a first draft of what i'd consider a solution? not sure if this is the right way to go, and i don't know how to write a test for an import statement

----------
Added file: http://bugs.python.org/file40820/random.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25420>
_______________________________________

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: [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 18:35:15 2015
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 20 Oct 2015 16:35:15 +0000
Subject: [issue25447] TypeError invoking deepcopy on lru_cache
In-Reply-To: <1445358729.12.0.473819832569.issue25447@psf.upfronthosting.co.za>
Message-ID: <1445358915.69.0.367078254873.issue25447@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

For some context into the error:

$ python3.5 -m pdb cachecopy.py 
> /home/jaraco/cachecopy.py(1)<module>()
-> import copy
(Pdb) c
Traceback (most recent call last):
  File "/usr/lib/python3.5/pdb.py", line 1661, in main
    pdb._runscript(mainpyfile)
  File "/usr/lib/python3.5/pdb.py", line 1542, in _runscript
    self.run(statement)
  File "/usr/lib/python3.5/bdb.py", line 431, in run
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "/home/jaraco/cachecopy.py", line 1, in <module>
    import copy
  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
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> /usr/lib/python3.5/copyreg.py(88)__newobj__()
-> return cls.__new__(cls, *args)
(Pdb) cls
<class 'functools._lru_cache_wrapper'>
(Pdb) args
cls = <class 'functools._lru_cache_wrapper'>
args = ()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25447>
_______________________________________

From report at bugs.python.org  Tue Oct 20 18:41:34 2015
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 20 Oct 2015 16:41:34 +0000
Subject: [issue14373] C implementation of functools.lru_cache
In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za>
Message-ID: <1445359294.18.0.0740212900516.issue14373@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I suspect this change is implicated in issue25447.

----------
nosy: +jason.coombs
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14373>
_______________________________________

From report at bugs.python.org  Tue Oct 20 19:22:24 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 20 Oct 2015 17:22:24 +0000
Subject: [issue25311] Add f-string support to tokenize.py
In-Reply-To: <1443979407.62.0.707305717475.issue25311@psf.upfronthosting.co.za>
Message-ID: <1445361744.86.0.913839505922.issue25311@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

This patch cleans up string matching in tokenize.py, and adds f-string support.

----------
Added file: http://bugs.python.org/file40821/issue25311-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25311>
_______________________________________

From report at bugs.python.org  Tue Oct 20 19:42:18 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 20 Oct 2015 17:42:18 +0000
Subject: [issue25395] SIGSEGV using json.tool: highly nested OrderedDict
In-Reply-To: <1444765181.78.0.70980847428.issue25395@psf.upfronthosting.co.za>
Message-ID: <1445362938.63.0.277727194707.issue25395@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is a problem with odict-trashcan.v3.patch. PyDict_Type.tp_dealloc() can put the object to the freelist if it's type is dict. Since odict_dealloc() fakes object's type, it alows deallocated OrderedDict to be later used as dict. But the size of OrderedDict object is larger than the size of plain dict, this creates a leak.

odict-trashcan.v2.patch is not good too. I found new test that crashes with it.

Here is a patch that solves all known issues with OrderedDict deallocation. Please correct my wording in the comment if needed. Similar bad scenario is described in the comment at the end of subtype_dealloc() in Objects/typeobject.c, but the patch uses different method to solve this.

----------
stage: commit review -> patch review
Added file: http://bugs.python.org/file40822/odict-trashcan.v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25395>
_______________________________________

From report at bugs.python.org  Tue Oct 20 20:02:27 2015
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 20 Oct 2015 18:02:27 +0000
Subject: [issue21515] Use Linux O_TMPFILE flag in tempfile.TemporaryFile?
In-Reply-To: <1400231841.29.0.337128735098.issue21515@psf.upfronthosting.co.za>
Message-ID: <1445364147.3.0.285571330843.issue21515@psf.upfronthosting.co.za>


???? ????????? added the comment:

Okay, seemes it is not documented that

os.open('.', os.O_RDWR |os.O_EXCL | os.O_DIRECTORY)

Should return EISDIR  

I did not found that in Linux manpages. Using undocumented features is bad. Maybe I should report this to Michael Kerrisk to update manpage ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21515>
_______________________________________

From report at bugs.python.org  Tue Oct 20 20:08:26 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 20 Oct 2015 18:08:26 +0000
Subject: [issue25447] TypeError invoking deepcopy on lru_cache
In-Reply-To: <1445358729.12.0.473819832569.issue25447@psf.upfronthosting.co.za>
Message-ID: <1445364506.83.0.089959689495.issue25447@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm not sure that we can say that deepcopying was not supported for lru_cache. copy.deepcopy() returned the same object, as for immutable objects, but can we consider decorated with lru_cache() function immutable?
 
The question is: if made functools._lru_cache_wrapper to support deepcopy protocol, should the result of copy.deepcopy() share the cache with original?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25447>
_______________________________________

From report at bugs.python.org  Tue Oct 20 20:11:00 2015
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 20 Oct 2015 18:11:00 +0000
Subject: [issue21515] Use Linux O_TMPFILE flag in tempfile.TemporaryFile?
In-Reply-To: <1400231841.29.0.337128735098.issue21515@psf.upfronthosting.co.za>
Message-ID: <1445364660.52.0.458268174099.issue21515@psf.upfronthosting.co.za>


???? ????????? added the comment:

Well, it's not said explicit, that O_DIRECTORY cannot be combined with O_RDWR.

So, everything is valid now, very hacky, but works without bugs.

It will be nice, if someone comment that hacks in source code

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21515>
_______________________________________

From report at bugs.python.org  Tue Oct 20 21:13:16 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 20 Oct 2015 19:13:16 +0000
Subject: [issue25446] smtplib.py AUTH LOGIN code messed up sending login and
 password data since 3.5
In-Reply-To: <1445355692.4.0.944252984253.issue25446@psf.upfronthosting.co.za>
Message-ID: <1445368396.53.0.456889271474.issue25446@psf.upfronthosting.co.za>


R. David Murray added the comment:

Does the fix at the end of issue 15014 address your concern?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25446>
_______________________________________

From report at bugs.python.org  Tue Oct 20 21:21:04 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 20 Oct 2015 19:21:04 +0000
Subject: [issue25446] smtplib.py AUTH LOGIN code messed up sending login and
 password data since 3.5
In-Reply-To: <1445355692.4.0.944252984253.issue25446@psf.upfronthosting.co.za>
Message-ID: <1445368864.02.0.71979214036.issue25446@psf.upfronthosting.co.za>


R. David Murray added the comment:

Sorry, I misremenbered and thought that fix didn't make it in to 3.5, but in fact you are talking about the behavior of that fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25446>
_______________________________________

From report at bugs.python.org  Tue Oct 20 21:23:03 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 20 Oct 2015 19:23:03 +0000
Subject: [issue25446] smtplib.py AUTH LOGIN code messed up sending login and
 password data since 3.5
In-Reply-To: <1445355692.4.0.944252984253.issue25446@psf.upfronthosting.co.za>
Message-ID: <1445368983.22.0.225314550383.issue25446@psf.upfronthosting.co.za>


R. David Murray added the comment:

Can you explain more about the failure you are seeing?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25446>
_______________________________________

From report at bugs.python.org  Tue Oct 20 21:25:13 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 20 Oct 2015 19:25:13 +0000
Subject: [issue25410] Clean up and fix OrderedDict
In-Reply-To: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za>
Message-ID: <1445369113.96.0.490775236604.issue25410@psf.upfronthosting.co.za>


Eric Snow added the comment:

Since the python-dev discussion about __class__, leaving the Python implementation alone is fine with me.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25410>
_______________________________________

From report at bugs.python.org  Tue Oct 20 21:30:01 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Oct 2015 19:30:01 +0000
Subject: [issue21515] Use Linux O_TMPFILE flag in tempfile.TemporaryFile?
In-Reply-To: <1445364147.3.0.285571330843.issue21515@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbswoTvC4nrhsk1C3uLqbNn5YxzqF0ddYrc6kDqrXBcmA@mail.gmail.com>


STINNER Victor added the comment:

2015-10-20 20:02 GMT+02:00 ???? ????????? <report at bugs.python.org>:
> Okay, seemes it is not documented that
>
> os.open('.', os.O_RDWR |os.O_EXCL | os.O_DIRECTORY)
>
> Should return EISDIR

You cannot open a directory to write, only to read.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21515>
_______________________________________

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: [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 21:39:50 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Oct 2015 19:39:50 +0000
Subject: [issue21515] Use Linux O_TMPFILE flag in tempfile.TemporaryFile?
In-Reply-To: <1400231841.29.0.337128735098.issue21515@psf.upfronthosting.co.za>
Message-ID: <1445369990.52.0.181711076719.issue21515@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> It will be nice, if someone comment that hacks in source code

I don't understand why you keep calling this a hack. It's part of open() contract, and I'm quite sure that it was a deliberate choice to declare O_TMPFILE as O_DIRECTY|new_bit. See for example this comment:
https://lwn.net/Articles/560834/

I wrote a patch to explain that it's fine to call open() with O_TMPFILE on old kernels to check if the flag is supported: see attached patch.

----------
resolution: fixed -> 
status: closed -> open
Added file: http://bugs.python.org/file40824/tempfile_comment.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21515>
_______________________________________

From report at bugs.python.org  Tue Oct 20 21:56:00 2015
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 20 Oct 2015 19:56:00 +0000
Subject: [issue21515] Use Linux O_TMPFILE flag in tempfile.TemporaryFile?
In-Reply-To: <1400231841.29.0.337128735098.issue21515@psf.upfronthosting.co.za>
Message-ID: <1445370960.28.0.990158592705.issue21515@psf.upfronthosting.co.za>


???? ????????? added the comment:

Huge thanks for that patch. Now things are much cleaner.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21515>
_______________________________________

From report at bugs.python.org  Tue Oct 20 22:17:31 2015
From: report at bugs.python.org (Victor van den Elzen)
Date: Tue, 20 Oct 2015 20:17:31 +0000
Subject: [issue25320] unittest loader.py TypeError when code directory
 contains a socket
In-Reply-To: <1444063424.79.0.244583020203.issue25320@psf.upfronthosting.co.za>
Message-ID: <1445372251.57.0.332922313042.issue25320@psf.upfronthosting.co.za>


Victor van den Elzen added the comment:

patch-with-test.patch is a patch against current tip (c3cec0f77eff+). It applies cleanly to 3.5.

It seemed simplest to include the socket in test_find_tests.

----------
Added file: http://bugs.python.org/file40825/patch-with-test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25320>
_______________________________________

From report at bugs.python.org  Tue Oct 20 22:18:40 2015
From: report at bugs.python.org (Victor van den Elzen)
Date: Tue, 20 Oct 2015 20:18:40 +0000
Subject: [issue25320] unittest loader.py TypeError when code directory
 contains a socket
In-Reply-To: <1444063424.79.0.244583020203.issue25320@psf.upfronthosting.co.za>
Message-ID: <1445372320.04.0.0289925975522.issue25320@psf.upfronthosting.co.za>


Victor van den Elzen added the comment:

Alternatively, patch-with-seperate-test.patch creates a seperate function to test for this issue.

----------
Added file: http://bugs.python.org/file40826/patch-with-seperate-test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25320>
_______________________________________

From report at bugs.python.org  Tue Oct 20 22:18:49 2015
From: report at bugs.python.org (Victor van den Elzen)
Date: Tue, 20 Oct 2015 20:18:49 +0000
Subject: [issue25320] unittest loader.py TypeError when code directory
 contains a socket
In-Reply-To: <1444063424.79.0.244583020203.issue25320@psf.upfronthosting.co.za>
Message-ID: <1445372329.07.0.386649857554.issue25320@psf.upfronthosting.co.za>


Changes by Victor van den Elzen <victor.vde at gmail.com>:


Removed 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 20 22:19:07 2015
From: report at bugs.python.org (Aaron Meurer)
Date: Tue, 20 Oct 2015 20:19:07 +0000
Subject: [issue22515] Implement partial order on Counter
In-Reply-To: <1412019201.2.0.639073460867.issue22515@psf.upfronthosting.co.za>
Message-ID: <1445372347.93.0.44665075153.issue22515@psf.upfronthosting.co.za>


Aaron Meurer added the comment:

I can't believe this issue was closed. Why can't Counter.__lt__(self, other) just be all(self[i] < other[i] for i in self)? 

Just because Counter supports weird stuff shouldn't bill it out. To follow that logic, we should also remove Counter.subtract

>>> Counter(a='b') - Counter(a='c')
Traceback (most recent call last):
  File "<ipython-input-5-31b2df7f8ff1>", line 1, in <module>
    Counter(a='b') - Counter(a='c')
  File "/Users/aaronmeurer/anaconda/lib/python3.5/collections/__init__.py", line 709, in __sub__
    newcount = count - other[elem]
TypeError: unsupported operand type(s) for -: 'str' and 'str'

It's super annoying that Counter supports all the basic set operations *except* subset. A reminder that this *does* work:

>>> Counter(a=2) | Counter(a=1)
Counter({'a': 2})

And also fails on weird values:

>>> Counter(a='b') | Counter(a='c')
Traceback (most recent call last):
  File "<ipython-input-8-f9768ad92117>", line 1, in <module>
    Counter(a='b') | Counter(a='c')
  File "/Users/aaronmeurer/anaconda/lib/python3.5/collections/__init__.py", line 730, in __or__
    if newcount > 0:
TypeError: unorderable types: str() > int()

----------
nosy: +Aaron.Meurer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22515>
_______________________________________

From report at bugs.python.org  Tue Oct 20 23:04:58 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 20 Oct 2015 21:04:58 +0000
Subject: [issue25439] Add type checks to urllib.request.Request
In-Reply-To: <1445247083.91.0.927080887762.issue25439@psf.upfronthosting.co.za>
Message-ID: <1445375098.36.0.0909854341878.issue25439@psf.upfronthosting.co.za>


Martin Panter added the comment:

The iterable option is documented under the urlopen(data=...) parameter, albeit not under the Request.data attribute. IMO this isn?t right, because you need to use Request to add Content-Length, but that is a separate documentation issue.

Technically, an empty dict() and a dictionary of bytes keys are both iterables of bytes. I admit it is a strange case though; this is one of those canned worms I mentioned. Example:

headers = {"Content-Length": 6}
data = OrderedDict(((b"abc", 1), (b"def", 2))))
urlopen(Request("http://localhost/", headers=headers, data=data))
# Sends request data b"abcdef"

Using the annotate function <https://hg.python.org/cpython/annotate/0a0aafaa9bf5/Lib/test/test_urllib.py#l1167> reveals that your empty dict() tests were added by revision 0a0aafaa9bf5. I suspect it was an accident that happened to work, which is really an argument for diagnosing passing in a dict, although as I mentioned this is technically breaking compatibility.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25439>
_______________________________________

From report at bugs.python.org  Tue Oct 20 23:10:16 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 20 Oct 2015 21:10:16 +0000
Subject: [issue25448] Exception ABC doesn't work in Python 3 (but does in
 Python 2.7)
In-Reply-To: <1445369551.19.0.243396138359.issue25448@psf.upfronthosting.co.za>
Message-ID: <1445375416.4.0.0409967073439.issue25448@psf.upfronthosting.co.za>


R. David Murray added the comment:

What are you trying to accomplish that needs an abstract base class?

APIError is not an Exception class, it is a meta-class, and thus it does not match the exception because it is not a *base* class of DriverError (it is DiverError's *meta* class).

Now, it is an interesting question whether we want the try/except statement's behavior to match issubclass, since intuitively we think the except in try except is doing the equivalent of issubclass (it isn't).

I don't know why this works in python2, but the class/meta-class machinery did undergo some significant changes.  So, it is possible that this is in fact a bug (ie: an unintentional change in semantics).  If so, it is also a doc bug, since the try statement docs clear say the expression must evaluate to a base class, and the virtual class (abc) docs *only* mention issubclass and isinstance.

----------
nosy: +ncoghlan, r.david.murray, rhettinger

_______________________________________
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: [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:14:41 2015
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 20 Oct 2015 21:14:41 +0000
Subject: [issue25447] TypeError invoking deepcopy on lru_cache
In-Reply-To: <1445358729.12.0.473819832569.issue25447@psf.upfronthosting.co.za>
Message-ID: <1445375681.43.0.626667548608.issue25447@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

Indeed. I guess my point about "supported" related to not having tests capturing this requirement or docs stipulating it.

My instinct on the latter question is this - an lru_cache-decorated function is a stateful function. It is mutable, much like a dict or list. If simply copied, the resulting function should have references to the same state. If _deep_ copied, the state (cache) should be similarly deep copied.

Focusing on the deep copy operation, if a cached function is copied, the copy could have additional operations invoked on it and its cache would hit or miss on those calls independently from the original function, and likewise subsequent calls on the original function should not hit on calls unique to the copied function.

I don't have a heavy investment in this expectation. It's also reasonable to me that a deepcopy operation could reuse the same cache or result in an uninitialized one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25447>
_______________________________________

From report at bugs.python.org  Tue Oct 20 23:16:44 2015
From: report at bugs.python.org (Oliver Merkel)
Date: Tue, 20 Oct 2015 21:16:44 +0000
Subject: [issue25446] smtplib.py AUTH LOGIN code messed up sending login and
 password data since 3.5
In-Reply-To: <1445355692.4.0.944252984253.issue25446@psf.upfronthosting.co.za>
Message-ID: <1445375804.68.0.808666638714.issue25446@psf.upfronthosting.co.za>


Oliver Merkel added the comment:

Let us assume you want to establish a smtp session with AUTH LOGIN as the supported authentication type. Sample code to send mail: Typical preparation steps like

    with SMTP( mailserver, 587 ) as smtp:
      # smtp.set_debuglevel(1)
      smtp.ehlo()
      smtp.starttls()
      smtp.ehlo()
      smtp.login( account, password )

If you try to login (last line in sample code above) at the smtp server then the smtp server will expect a command to be send like

AUTH LOGIN <base64encodedaccountdata>

Now switching from sample code to our smtplib.py:

Since the "AUTH LOGIN" is missing in original Python35/Lib/smtplib.py in line...

660c663
<         (code, resp) = self.docmd(
---
>         (code, resp) = self.docmd("AUTH", "LOGIN " +

... the smtp server will answer that the library is sending an unknown command here. That is why I added... "AUTH", "LOGIN " + ...at this line.

Line 660 in class SMTP: def auth_login is called before it reaches line 630 in class SMTP: def auth

In case of authentication type AUTH LOGIN in line 630 you must not call with "AUTH", mechanism + " " +

So the following changes have to be applied at least for AUTH LOGIN mechanism

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)

The first change affecting line 660 described above will will imply that the you remove the AUTH mechanism in line 630. For mechanism LOGIN the base64 encoded password will be needed to be sent in 660...

See possible fix in the diff above.

To ease understanding the fix I will apply a running version of my local Lib/smtplib.py (instead of just providing the diff lines). Feel free to directly use the file.

----------
Added file: http://bugs.python.org/file40828/smtplib.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25446>
_______________________________________

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: [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  Tue Oct 20 23:41:38 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 20 Oct 2015 21:41:38 +0000
Subject: [issue25448] Exception ABC doesn't work in Python 3 (but does in
 Python 2.7)
In-Reply-To: <1445369551.19.0.243396138359.issue25448@psf.upfronthosting.co.za>
Message-ID: <1445377298.05.0.214930765916.issue25448@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thinking about this some more my explanation isn't quite clear (because my thinking wasn't quite clear): the problem isn't that APIError isn't *capable* of being a base class; I was wrong when I said it is itself a metaclass.  It is a class that has ABCMeta *as* its metaclass.  The problem is what I said in the second part: that APIError isn't a base class *of DriverError*.  The operant issue is that 'except' isn't doing issubclass, it is looking at the base class list of DriverError, and APIError isn't in it.

I'd have to see your 2.7 code to figure out why that version "works" :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25448>
_______________________________________

From report at bugs.python.org  Tue Oct 20 23:46:14 2015
From: report at bugs.python.org (Oliver Merkel)
Date: Tue, 20 Oct 2015 21:46:14 +0000
Subject: [issue25446] smtplib.py AUTH LOGIN code messed up sending login and
 password data since 3.5
In-Reply-To: <1445355692.4.0.944252984253.issue25446@psf.upfronthosting.co.za>
Message-ID: <1445377574.83.0.308125830236.issue25446@psf.upfronthosting.co.za>


Oliver Merkel added the comment:

Sample session log output showing the error with smtp.set_debuglevel(1):

send: 'ehlo <mysmtpserver>\r\n'
reply: b'250-<mysmtpserver> Hello [myIP4address]\r\n'
reply: b'250-SIZE 53248000\r\n'
reply: b'250-PIPELINING\r\n'
reply: b'250-DSN\r\n'
reply: b'250-ENHANCEDSTATUSCODES\r\n'
reply: b'250-STARTTLS\r\n'
reply: b'250-AUTH GSSAPI NTLM\r\n'
reply: b'250-8BITMIME\r\n'
reply: b'250-BINARYMIME\r\n'
reply: b'250 CHUNKING\r\n'
reply: retcode (250); Msg: b'<mysmtpserver> Hello [myIP4address]\
nSIZE 53248000\nPIPELINING\nDSN\nENHANCEDSTATUSCODES\nSTARTTLS\nAUTH GSSAPI NTLM
\n8BITMIME\nBINARYMIME\nCHUNKING'
send: 'STARTTLS\r\n'
reply: b'220 2.0.0 SMTP server ready\r\n'
reply: retcode (220); Msg: b'2.0.0 SMTP server ready'
send: 'ehlo [mymachinename]\r\n'
reply: b'250-<mysmtpserver> Hello [myIP4address]\r\n'
reply: b'250-SIZE 53248000\r\n'
reply: b'250-PIPELINING\r\n'
reply: b'250-DSN\r\n'
reply: b'250-ENHANCEDSTATUSCODES\r\n'
reply: b'250-AUTH GSSAPI NTLM LOGIN\r\n'
reply: b'250-8BITMIME\r\n'
reply: b'250-BINARYMIME\r\n'
reply: b'250 CHUNKING\r\n'
reply: retcode (250); Msg: b'<mysmtpserver> Hello [myIP4address]\
nSIZE 53248000\nPIPELINING\nDSN\nENHANCEDSTATUSCODES\nAUTH GSSAPI NTLM LOGIN\n8B
ITMIME\nBINARYMIME\nCHUNKING'
send: '<base64encodedaccountnamedata>==\r\n'
reply: b'500 5.3.3 Unrecognized command\r\n'
reply: retcode (500); Msg: b'5.3.3 Unrecognized command'
send: 'QUIT\r\n'
reply: b'221 2.0.0 Service closing transmission channel\r\n'
reply: retcode (221); Msg: b'2.0.0 Service closing transmission channel'
Traceback (most recent call last):
  File "sendtestmail.py", line 172, in <module>
    announcement.sendMail(password)
  File "sendtestmail.py", line 97, in sendMail
    smtp.login( self.getShortAddressList()[0], password )
  File "c:\Python35\lib\smtplib.py", line 730, in login
    raise last_exception
  File "c:\Python35\lib\smtplib.py", line 721, in login
    initial_response_ok=initial_response_ok)
  File "c:\Python35\lib\smtplib.py", line 627, in auth
    initial_response = (authobject() if initial_response_ok else None)
  File "c:\Python35\lib\smtplib.py", line 664, in auth_login
    raise SMTPAuthenticationError(code, resp)
smtplib.SMTPAuthenticationError: (500, b'5.3.3 Unrecognized command')

due to missing AUTH LOGIN here as previously described...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25446>
_______________________________________

From report at bugs.python.org  Tue Oct 20 23:47:49 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 20 Oct 2015 21:47:49 +0000
Subject: [issue25449] Test OrderedDict subclass
In-Reply-To: <1445375538.53.0.781433530973.issue25449@psf.upfronthosting.co.za>
Message-ID: <1445377669.69.0.503183787886.issue25449@psf.upfronthosting.co.za>


Eric Snow added the comment:

LGTM as long as you also add PurePythonOrderedDictSubclassTests to match CPythonOrderedDictSubclassTests (per PEP 399).

----------
nosy: +eric.snow
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25449>
_______________________________________

From report at bugs.python.org  Tue Oct 20 23:54:26 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 20 Oct 2015 21:54:26 +0000
Subject: [issue25446] smtplib.py AUTH LOGIN code messed up sending login and
 password data since 3.5
In-Reply-To: <1445355692.4.0.944252984253.issue25446@psf.upfronthosting.co.za>
Message-ID: <1445378066.12.0.582194612221.issue25446@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, now I see what you are saying.  How in the world did we miss that?  Our unit tests must be broken too.

----------
keywords: +3.5regression
priority: normal -> release blocker
stage:  -> needs patch
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25446>
_______________________________________

From report at bugs.python.org  Wed Oct 21 00:01:22 2015
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 20 Oct 2015 22:01:22 +0000
Subject: [issue25450] IDLE: Save path automatically choses C:\Windows\system32
In-Reply-To: <1445376716.84.0.123418793499.issue25450@psf.upfronthosting.co.za>
Message-ID: <1445378482.52.0.983883612676.issue25450@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
components: +IDLE, Windows -Installation
nosy: +kbk, paul.moore, roger.serwy, steve.dower, terry.reedy, tim.golden, zach.ware
title: Save path automatically choses C:\Windows\system32 -> IDLE: Save path automatically choses C:\Windows\system32

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25450>
_______________________________________

From report at bugs.python.org  Wed Oct 21 00:06:51 2015
From: report at bugs.python.org (Oliver Merkel)
Date: Tue, 20 Oct 2015 22:06:51 +0000
Subject: [issue25446] smtplib.py AUTH LOGIN code messed up sending login and
 password data since 3.5
In-Reply-To: <1445355692.4.0.944252984253.issue25446@psf.upfronthosting.co.za>
Message-ID: <1445378811.69.0.578450756606.issue25446@psf.upfronthosting.co.za>


Oliver Merkel added the comment:

Change proposal attached as a unified diff / patch file.

----------
keywords: +patch
Added file: http://bugs.python.org/file40829/smtplib-patch.issue25446.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25446>
_______________________________________

From report at bugs.python.org  Wed Oct 21 00:10:04 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Oct 2015 22:10:04 +0000
Subject: [issue25413] ctypes (libffi) fails to compile on Solaris X86
In-Reply-To: <1444919626.01.0.242398686702.issue25413@psf.upfronthosting.co.za>
Message-ID: <1445379004.2.0.610882456076.issue25413@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +amaury.forgeotdarc, belopolsky, meador.inge
versions: +Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25413>
_______________________________________

From report at bugs.python.org  Wed Oct 21 00:12:23 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Oct 2015 22:12:23 +0000
Subject: [issue25154] Drop the pyvenv script
In-Reply-To: <1442514921.37.0.255858283829.issue25154@psf.upfronthosting.co.za>
Message-ID: <1445379143.91.0.832197090413.issue25154@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Did you fix the "exeutable" typo?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25154>
_______________________________________

From report at bugs.python.org  Wed Oct 21 00:14:27 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 20 Oct 2015 22:14:27 +0000
Subject: [issue25154] Drop the pyvenv script
In-Reply-To: <1442514921.37.0.255858283829.issue25154@psf.upfronthosting.co.za>
Message-ID: <1445379267.63.0.269314996986.issue25154@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Not yet. I will get to it no later than Friday (just a matter of either remembering to quickly fix it when I get home from work, bother setting up SSH keys at work, or simply doing it on Friday when I typically do all of my Python work).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25154>
_______________________________________

From report at bugs.python.org  Wed Oct 21 00:15:36 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 20 Oct 2015 22:15:36 +0000
Subject: [issue21515] Use Linux O_TMPFILE flag in tempfile.TemporaryFile?
In-Reply-To: <1400231841.29.0.337128735098.issue21515@psf.upfronthosting.co.za>
Message-ID: <20151020221525.117256.44347@psf.io>


Roundup Robot added the comment:

New changeset dc2deecb2346 by Victor Stinner in branch '3.5':
Issue #21515: Elaborate tempfile.TemporaryFile() comment
https://hg.python.org/cpython/rev/dc2deecb2346

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21515>
_______________________________________

From report at bugs.python.org  Wed Oct 21 00:20:25 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Oct 2015 22:20:25 +0000
Subject: [issue21515] Use Linux O_TMPFILE flag in tempfile.TemporaryFile?
In-Reply-To: <1400231841.29.0.337128735098.issue21515@psf.upfronthosting.co.za>
Message-ID: <1445379625.36.0.963448028294.issue21515@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Huge thanks for that patch. Now things are much cleaner.

I understand that the patch looks good to you, so I pushed it to Python 3.5 & 3.6. I close again the issue. Thanks for your analasys of tempfile.TemporaryFile() :-)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21515>
_______________________________________

From report at bugs.python.org  Wed Oct 21 00:44:18 2015
From: report at bugs.python.org (Nan Wu)
Date: Tue, 20 Oct 2015 22:44:18 +0000
Subject: [issue25439] Add type checks to urllib.request.Request
In-Reply-To: <1445247083.91.0.927080887762.issue25439@psf.upfronthosting.co.za>
Message-ID: <1445381058.57.0.625715654821.issue25439@psf.upfronthosting.co.za>


Nan Wu added the comment:

I see. Empty dict is considered as iterable of bytes makes good sense. I just left the old tests there. And explicitly give warnings when data field is of type str or type dict with non-bytes key.

----------
Added file: http://bugs.python.org/file40830/urllib_request_param_type_check_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25439>
_______________________________________

From report at bugs.python.org  Wed Oct 21 01:27:31 2015
From: report at bugs.python.org (eryksun)
Date: Tue, 20 Oct 2015 23:27:31 +0000
Subject: [issue25448] Exception ABC doesn't work in Python 3 (but does in
 Python 2.7)
In-Reply-To: <1445369551.19.0.243396138359.issue25448@psf.upfronthosting.co.za>
Message-ID: <1445383651.71.0.569955155759.issue25448@psf.upfronthosting.co.za>


eryksun added the comment:

In Python 2, PyErr_GivenExceptionMatches [1] calls PyObject_IsSubclass. To handle calling __subclasscheck__ in this case, 2.7 (but not 2.6) temporarily increases the recursion limit by 5. For example:

    class CMeta(type):
        def __subclasscheck__(self, other):
            import sys
            print 'recursion limit: %d' % sys.getrecursionlimit()
            frame = sys._getframe(1)
            n = 0
            while frame:
                n += 1
                frame = frame.f_back
            print 'frame: %d' % n
            return True

    class C(Exception):
        __metaclass__ = CMeta

    def f():
        try:
            f()
        except C:
            pass

    >>> sys.getrecursionlimit()
    1000
    >>> f()
    recursion limit: 1005
    frame: 1000
    >>> sys.getrecursionlimit()
    1000

If the recursion limit weren't temporarily increased, then trying to call __subclasscheck__ in the above case would raise another RuntimeError.

In Python 3, PyErr_GivenExceptionMatches [2] instead calls PyType_IsSubtype. See issue 2534. In that issue Antoine's reason for the change is that "otherwise there are some nasty issues with recursion checking". 

[1]: https://hg.python.org/cpython/file/v2.7.10/Python/errors.c#l84
[2]: https://hg.python.org/cpython/file/v3.5.0/Python/errors.c#l166

----------
components: +Interpreter Core
nosy: +eryksun
versions: +Python 3.5, Python 3.6 -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25448>
_______________________________________

From report at bugs.python.org  Wed Oct 21 02:19:40 2015
From: report at bugs.python.org (Medardo Rodriguez)
Date: Wed, 21 Oct 2015 00:19:40 +0000
Subject: [issue25448] Exception ABC doesn't work in Python 3 (but does in
 Python 2.7)
In-Reply-To: <1445369551.19.0.243396138359.issue25448@psf.upfronthosting.co.za>
Message-ID: <1445386780.61.0.848833830625.issue25448@psf.upfronthosting.co.za>


Medardo Rodriguez added the comment:

Thanks ~eryksun, you clarified me in where the error is located and possible patches for it.

We are programming a framework where is very important to do mappings between (1) the API and (2) the drivers layers.

We try to make our code available to both branches of Python (2 and 3).  This case is complex because a logical exception type definition (like "resource not found") is implemented different by disparate API consumer applications (these implementing the drivers), for example `httplib`, `couchdb` or any specific database management system.

So, the API layer have to find a way to uniform disparate exception "fauna" in its definitions at a logical level.

ABCs are the nice solution, only have to work as its conceptual definition said, including exceptions, in all Python versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25448>
_______________________________________

From report at bugs.python.org  Wed Oct 21 03:47:47 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 21 Oct 2015 01:47:47 +0000
Subject: [issue12029] Catching virtual subclasses in except clauses
In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>
Message-ID: <1445392067.96.0.827921815162.issue12029@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Does this introduce a slowdown when the type doesn't match? That is, clearly George's example:

try:
    {}["a"]                       
except KeyError:
    pass

won't be slowed because the fast path will get an immediate hit. But what about:


try:
    {}["a"]
except TypeError:
    pass
except ValueError:
    pass
except KeyError:
    pass

(or with the KeyError handler higher up the call stack). The fast path speeds up the handled case, but it doesn't seem like it would help the unhandled case (where it would need to check the slow path for each unhandled exception type one at a time).

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12029>
_______________________________________

From report at bugs.python.org  Wed Oct 21 03:48:33 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 21 Oct 2015 01:48:33 +0000
Subject: [issue25448] Exception ABC doesn't work in Python 3 (but does in
 Python 2.7)
In-Reply-To: <1445369551.19.0.243396138359.issue25448@psf.upfronthosting.co.za>
Message-ID: <1445392113.78.0.540965104926.issue25448@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

This looks like a duplicate of #12029. The delays on addressing that bug seem to indicate that initially there was a fairly substantial performance cost for all exception handling paths when ABC friendly checking was performed, but that was at least partially due to a bug in those code paths that didn't bypass the ABC machinery in the simple subclass case.

That said, I'm not sure it wouldn't cause other performance regressions (I made a comment to that effect on the original bug).

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25448>
_______________________________________

From report at bugs.python.org  Wed Oct 21 03:52:09 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 21 Oct 2015 01:52:09 +0000
Subject: [issue12029] Catching virtual subclasses in except clauses
In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>
Message-ID: <1445392329.11.0.847768882146.issue12029@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

On rereading #22540, maybe that won't be an issue (in the common case where no custom metaclasses are used for the exceptions to be caught, it looks like maybe there is no slow path to traverse?). Still worth double checking.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12029>
_______________________________________

From report at bugs.python.org  Wed Oct 21 04:26:42 2015
From: report at bugs.python.org (Medardo Rodriguez)
Date: Wed, 21 Oct 2015 02:26:42 +0000
Subject: [issue25448] Exception ABC doesn't work in Python 3 (but does in
 Python 2.7)
In-Reply-To: <1445369551.19.0.243396138359.issue25448@psf.upfronthosting.co.za>
Message-ID: <1445394402.02.0.437772145963.issue25448@psf.upfronthosting.co.za>


Medardo Rodriguez added the comment:

Josh Rosenberg, you are right, it's a duplication. Sorry I didn't find the issue #12029 before.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25448>
_______________________________________

From report at bugs.python.org  Wed Oct 21 04:32:09 2015
From: report at bugs.python.org (eryksun)
Date: Wed, 21 Oct 2015 02:32:09 +0000
Subject: [issue25448] Exception ABC doesn't work in Python 3 (but does in
 Python 2.7)
In-Reply-To: <1445369551.19.0.243396138359.issue25448@psf.upfronthosting.co.za>
Message-ID: <1445394729.85.0.305648945713.issue25448@psf.upfronthosting.co.za>


Changes by eryksun <eryksun at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Catching virtual subclasses in except clauses

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25448>
_______________________________________

From report at bugs.python.org  Wed Oct 21 05:17:45 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 21 Oct 2015 03:17:45 +0000
Subject: [issue25017] htmllib deprecated: Which library to use? Missing sane
 default in docs
In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za>
Message-ID: <1445397465.25.0.0613366410162.issue25017@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch.

I think we can move the Python 3 part of the patch to a new note directive (similar to the example in httplib documentation: https://docs.python.org/2/library/httplib.html)

For example:

.. deprecated:: 2.6
   Use :mode:`HTMLParser` instead.

.. note::
   The :mod:`htmllib` module has been removed in Python 3.  Use :mod:`html.parser` (equivalent of :mode:`HTMLParser`) instead.

----------
nosy: +berker.peksag
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25017>
_______________________________________

From report at bugs.python.org  Wed Oct 21 05:22:07 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 21 Oct 2015 03:22:07 +0000
Subject: [issue25438] document what codec PyMemberDef T_STRING decodes the
 char * as
In-Reply-To: <1445236924.11.0.92849861938.issue25438@psf.upfronthosting.co.za>
Message-ID: <1445397727.49.0.837717038173.issue25438@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Checking the source ( https://hg.python.org/cpython/file/tip/Python/structmember.c#l51 ), it calls PyUnicodeFromString ( https://docs.python.org/3/c-api/unicode.html?highlight=pyunicode_fromstring#c.PyUnicode_FromString ), so it's always interpreted as UTF-8.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25438>
_______________________________________

From report at bugs.python.org  Wed Oct 21 06:27:46 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 21 Oct 2015 04:27:46 +0000
Subject: [issue25450] IDLE: Save path automatically choses C:\Windows\system32
In-Reply-To: <1445376716.84.0.123418793499.issue25450@psf.upfronthosting.co.za>
Message-ID: <1445401666.86.0.857548734057.issue25450@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

On my win 10 machine, upgraded from win 7 a week ago, I have C:/programs/Python27, ...34, and ...35.  C:/Windows/system32 contains python27.dll and ...34.dll, but not ...35.dll.  For Idle 2.7 and 3.4, default 'Save As' directory is Python27 and ...34.  (Saving to install directory is not best but works.) For 3.5, it is indeed ...system32.  This is wrong and bad.  The startup directory becomes '.', at the head of sys.path, the module search path.

This is not an IDLE issue.  Start console Python from the icon.
>>> import os; os.getcwd()
'C:\\Programs\\Python34'  # 3.4
'C:\\WINDOWS\\System32'  # 3.5
The following test of Python installed on Windows (preferably before release) would have caught this regression/bug.
  os.getcwd() == os.path.split(sys.executable)[0]

As for IDLE: in IOBinding.py, save_as (l.350) calls asksavefile (l.512).  That calls tkinter.filedialog.SaveAs().show with initialdir = self.defaultfilename("save")[0].  defaultfilename (l.500) defaults to os.getcwd(), which, as above, returns ...system32.

I believe this is an installation bug of not specifying the startup directory for the 3.5 Python and IDLE icons (others should be checked also).

The 3.4 IDLE Icon Properties dialog has 'Target: Python 3.4.3 (64bit)', the latter in grayed-out read-only unselectable text and Start in: C:\Programs\Python34\, the latter rather dangerously pre-selecteed (and hence too easy to inadvertently alter or delete).  

The 3.5 dialog has '''Target: C:\Programs\Python35\pythonw.exe "C:\Programs\Python35\Lib\idlelib\idle.pyw"''', with the target preselected.  This change is useful since users can add IDLE startup arguments at the end, such as '-s' to execute PYTHONSTARTUP.

However, 'Start in:' is blank and for what ever reason, the default is ...system32.  Putting C:\Programs\Python35\ there fixes the problem, and that or something should be there on installation.  When I start IDLE on a command line with "python -m idlelib", the start 'directory' is "Desktop /n Terry", which is an alias for c:\Users\Terry. For most people, that is a better default directory than the install directory.

Larry, Maja is the 2nd or 3rd teacher to report this problem.  See python-list thread "teacher need help!" 
https://mail.python.org/pipermail/python-list/2015-October/698054.html
for one who had problems on 3 of 13 machines and in desperation "formatted the machines, reinstalling everything, including Python."

Maja, the recurring problem may have been due to the bad startup directory being the first directory searched for imports. Or it it may be due to 'C:\Windows\system34\turtle.py' being recorded in <home directory>/.idlerc/recent-files.lst, which is used for File -> Recent Files.  Although IDLE deletes at least some bad entries, the ultimate solution to problems with that file is for a user to edit and delete bad names or delete the file entirely.

----------
components: +Installation -IDLE
priority: normal -> release blocker
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25450>
_______________________________________

From report at bugs.python.org  Wed Oct 21 08:32:00 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Oct 2015 06:32:00 +0000
Subject: [issue25449] Test OrderedDict subclass
In-Reply-To: <1445375538.53.0.781433530973.issue25449@psf.upfronthosting.co.za>
Message-ID: <1445409120.81.0.47490278596.issue25449@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch was not ready for commit. The problem is that test_issue24347 fails in CPythonOrderedDictSubclassTests. The failure is random, you need to run test several times to encounter it.

Experimenting with this test I found other bug probably related to issue24347.

>>> from collections import OrderedDict
>>> od = OrderedDict()
>>> dict.__setitem__(od, 1, 2)
>>> od
OrderedDict([<NULL>])

I expected rather raising an exception or showing an empty OrderedDict, that exposing NULL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25449>
_______________________________________

From report at bugs.python.org  Wed Oct 21 09:26:05 2015
From: report at bugs.python.org (Matt Joiner)
Date: Wed, 21 Oct 2015 07:26:05 +0000
Subject: [issue14373] C implementation of functools.lru_cache
In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za>
Message-ID: <1445412365.39.0.491053528954.issue14373@psf.upfronthosting.co.za>


Changes by Matt Joiner <anacrolix at gmail.com>:


----------
nosy:  -anacrolix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14373>
_______________________________________

From report at bugs.python.org  Wed Oct 21 09:44:48 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 21 Oct 2015 07:44:48 +0000
Subject: [issue25450] Python 3.5 starts in C:\Windows\system32 as current
 directory
In-Reply-To: <1445376716.84.0.123418793499.issue25450@psf.upfronthosting.co.za>
Message-ID: <1445413488.28.0.712259125405.issue25450@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: IDLE: Save path automatically choses C:\Windows\system32 -> Python 3.5 starts in C:\Windows\system32 as current directory
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25450>
_______________________________________

From report at bugs.python.org  Wed Oct 21 09:57:20 2015
From: report at bugs.python.org (eryksun)
Date: Wed, 21 Oct 2015 07:57:20 +0000
Subject: [issue25450] Python 3.5 starts in C:\Windows\system32 as current
 directory
In-Reply-To: <1445376716.84.0.123418793499.issue25450@psf.upfronthosting.co.za>
Message-ID: <1445414240.56.0.271474827174.issue25450@psf.upfronthosting.co.za>


eryksun added the comment:

> 'Start in:' is blank and for what ever reason, the default is ...system32. 

When the "Start in" field of a .lnk shortcut is blank, the child process inherits the working directory of the parent process (i.e. the process that runs the shortcut), unless the parent passes some other directory to ShellExecute. 

If you copy the shortcut to the desktop, for example, Explorer sets the working directory to the desktop. If it's run from the command prompt, cmd uses its own working directory. When run from the Start menu, the child inherits Explorer's working directory, %SystemRoot%\System32.

The old installer (pre-3.5) sets "Start in" to the installation directory. IMO, a better choice would be "%USERPROFILE%". The Windows shell expands the environment variable to the current user's profile directory when it runs the shortcut. 

I'm not keen on using a profile subdirectory such as "Documents" or "Desktop", since a user can relocate most of the special folders in his or her profile. Unfortunately the "Start in" field won't accept shell: locations such as "shell:Personal" or "shell:Desktop". It would be nice if it did, since those take into account relocated folders.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25450>
_______________________________________

From report at bugs.python.org  Wed Oct 21 10:02:37 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 21 Oct 2015 08:02:37 +0000
Subject: [issue25017] htmllib deprecated: Which library to use? Missing sane
 default in docs
In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za>
Message-ID: <1445414557.63.0.240517922396.issue25017@psf.upfronthosting.co.za>


Martin Panter added the comment:

Also beware it should be :mod: not :mode: :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25017>
_______________________________________

From report at bugs.python.org  Wed Oct 21 10:15:07 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 21 Oct 2015 08:15:07 +0000
Subject: [issue25450] Python 3.5 starts in C:\Windows\system32 as current
 directory
In-Reply-To: <1445376716.84.0.123418793499.issue25450@psf.upfronthosting.co.za>
Message-ID: <1445415307.4.0.583635408012.issue25450@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Thanks for the explanation.  When I did the test with Command Prompt, I happened to be in /Users/Terry, which is where C.P. starts.  %USERPROFILE% is what I was thinking of but could not precisely remember.  It worked when put in that box.

I think adding /Documents would be a mistake because many users (including me) put Python stuff in other subdirectories.

A minor mystery.  Changing Start in: for the Python icon requires admin permission; for the IDLE icon, not.

----------

_______________________________________
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: [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: [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: [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 14:28:24 2015
From: report at bugs.python.org (Saksham Agrawal)
Date: Wed, 21 Oct 2015 12:28:24 +0000
Subject: [issue25453] Arithmetics with complex infinities is inconsistent with
 C/C++
In-Reply-To: <1445430043.57.0.625714416149.issue25453@psf.upfronthosting.co.za>
Message-ID: <1445430504.36.0.372953619483.issue25453@psf.upfronthosting.co.za>


Saksham Agrawal added the comment:

Hi

Would like to work on this bug...but I am new, would like some guidance

Please help me

----------
nosy: +Saksham Agrawal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25453>
_______________________________________

From report at bugs.python.org  Wed Oct 21 14:56:55 2015
From: report at bugs.python.org (Nan Wu)
Date: Wed, 21 Oct 2015 12:56:55 +0000
Subject: [issue25017] htmllib deprecated: Which library to use? Missing sane
 default in docs
In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za>
Message-ID: <1445432215.32.0.678106372467.issue25017@psf.upfronthosting.co.za>


Nan Wu added the comment:

Updated the patch. The typo was fixed too. Thanks for the catching.

----------
Added file: http://bugs.python.org/file40831/htmllib_deprecation_warning_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25017>
_______________________________________

From report at bugs.python.org  Wed Oct 21 15:03:50 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 21 Oct 2015 13:03:50 +0000
Subject: [issue25453] Arithmetics with complex infinities is inconsistent with
 C/C++
In-Reply-To: <1445430043.57.0.625714416149.issue25453@psf.upfronthosting.co.za>
Message-ID: <1445432630.3.0.854254272213.issue25453@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Saksham, if you would like to work on this issue you can check the devguide for more information.

----------
components: +Interpreter Core
nosy: +eric.smith, ezio.melotti, lemburg, mark.dickinson, stutzbach
versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25453>
_______________________________________

From report at bugs.python.org  Wed Oct 21 15:24:39 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Oct 2015 13:24:39 +0000
Subject: [issue25446] smtplib.py AUTH LOGIN code messed up sending login and
 password data since 3.5
In-Reply-To: <1445355692.4.0.944252984253.issue25446@psf.upfronthosting.co.za>
Message-ID: <1445433879.55.0.936074435237.issue25446@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, but special-casing login in the 'auth' method means that the auth method isn't working right, since special-casing defeats the whole purpose of the auth mechanism.

I think we need to change the logic in auth so that it is checking for a 334 even if it has been provided an initial response.  That is, outdent the block that starts with the '# Server replies...' comment.  Once that is done, auth_login becomes:

  def auth_login(self, challenge=None)
      if challenge is None:
          return encode_base64(self.user.encode('ascii'))
      else:
          return self.password

We may also need to add a try/except around the base64.decodebytes in auth.

And we need a unit test that demonstrates the current failure.

I'm also wondering now about the ascii encoding on the challenge and response.  Someone should check the RFC to see if those are limited to ascii or if they can contain other bytes.  If they are limited to ascii we should stick in a comment to that effect with a pointer to the relevant RFC section.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25446>
_______________________________________

From report at bugs.python.org  Wed Oct 21 16:15:19 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Oct 2015 14:15:19 +0000
Subject: [issue12029] Catching virtual subclasses in except clauses
In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>
Message-ID: <1445436919.78.0.0421036232418.issue12029@psf.upfronthosting.co.za>


R. David Murray added the comment:

Note from discussion on duplicate issue 25448: when this is fixed, the try/except documentation should be updated to indicate that the except clause test is equivalent to 'issubclass', so that the handling of virtual subclasses are implied by the doc.  (The current proposed patch contains no doc changes.)

Apparently this also affects pypy.

----------
nosy: +alex, fijal, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12029>
_______________________________________

From report at bugs.python.org  Wed Oct 21 16:40:40 2015
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 21 Oct 2015 14:40:40 +0000
Subject: [issue25453] Arithmetics with complex infinities is inconsistent with
 C/C++
In-Reply-To: <1445430043.57.0.625714416149.issue25453@psf.upfronthosting.co.za>
Message-ID: <1445438440.56.0.349048940794.issue25453@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

I'm not entirely satisfied that the way it is calculated by C++11/C99 is correct. (Although I can see the appeal of the C version.) Mathematically, complex multiplication (a+bj)*x should be identical to (a+bj)*(x+0j), but obviously in the presence of NANs that is no longer the case. So it isn't clear to me that Python is wrong to allow NANs to "infect" the real part after multiplication.

Before changing the behaviour, I'd like to hear from someone who might be able to comment on what the IEEE-754 standard may have to say about this.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25453>
_______________________________________

From report at bugs.python.org  Wed Oct 21 17:19:15 2015
From: report at bugs.python.org (Francesco Biscani)
Date: Wed, 21 Oct 2015 15:19:15 +0000
Subject: [issue25453] Arithmetics with complex infinities is inconsistent with
 C/C++
In-Reply-To: <1445430043.57.0.625714416149.issue25453@psf.upfronthosting.co.za>
Message-ID: <1445440755.15.0.812236011886.issue25453@psf.upfronthosting.co.za>


Francesco Biscani added the comment:

The best reference I could find so far is in the C99 standard:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

Annex G is titled "IEC 60559-compatible complex arithmetic". In G.3.1 it is written:

"""
A complex or imaginary value with at least one infinite part is regarded as an infinity (even if its other part is a NaN).
"""

Later on, in G.5.1.4, it is stated:

"""
The * and / operators satisfy the following infinity properties for all real, imaginary, and complex operands:

- if one operand is an infinity and the other operand is a nonzero finite number or an infinity, then the result of the * operator is an infinity;
- if the first operand is an infinity and the second operand is a finite number, then the result of the / operator is an infinity;
- if the first operand is a finite number and the second operand is an infinity, then the result of the / operator is a zero;
"""

So to recap, according to these definitions:

- inf + nanj is a complex infinity,
- (inf + nanj) * (2 + 0j) should give a complex infinity (i.e., a complex number in which at least one component is inf).

I am not saying that these rules are necessarily "mathematically correct". I am aware that floating point is always a quagmire to get into, and the situation here is even more complex (eh!) than usual.

But it seems to me that Python, or CPython at least, follows a pattern of copying (or relying on) the behaviour of C for floating-point operations, and it seems like in the case of complex numbers this "rule" is broken. It certainly caught me by surprise anyway :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25453>
_______________________________________

From report at bugs.python.org  Wed Oct 21 17:28:46 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 21 Oct 2015 15:28:46 +0000
Subject: [issue24379] operator.subscript
In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za>
Message-ID: <1445441326.8.0.966602423398.issue24379@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This is causing a reference leak problem:  https://mail.python.org/pipermail/python-dev/2015-October/141993.html

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24379>
_______________________________________

From report at bugs.python.org  Wed Oct 21 17:28:54 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 21 Oct 2015 15:28:54 +0000
Subject: [issue24379] operator.subscript
In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za>
Message-ID: <1445441334.86.0.0134489492798.issue24379@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24379>
_______________________________________

From report at bugs.python.org  Wed Oct 21 17:29:37 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 21 Oct 2015 15:29:37 +0000
Subject: [issue25449] Test OrderedDict subclass
In-Reply-To: <1445375538.53.0.781433530973.issue25449@psf.upfronthosting.co.za>
Message-ID: <1445441377.26.0.954346455236.issue25449@psf.upfronthosting.co.za>


Eric Snow added the comment:

Regarding dict.__setitem__, see issue #24726.  Raymond outlined what needs to be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25449>
_______________________________________

From report at bugs.python.org  Wed Oct 21 17:29:44 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 21 Oct 2015 15:29:44 +0000
Subject: [issue25449] Test OrderedDict subclass
In-Reply-To: <1445375538.53.0.781433530973.issue25449@psf.upfronthosting.co.za>
Message-ID: <1445441384.6.0.250974245501.issue25449@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25449>
_______________________________________

From report at bugs.python.org  Wed Oct 21 17:29:52 2015
From: report at bugs.python.org (Saksham Agrawal)
Date: Wed, 21 Oct 2015 15:29:52 +0000
Subject: [issue25453] Arithmetics with complex infinities is inconsistent with
 C/C++
In-Reply-To: <1445430043.57.0.625714416149.issue25453@psf.upfronthosting.co.za>
Message-ID: <1445441392.44.0.990498301975.issue25453@psf.upfronthosting.co.za>


Saksham Agrawal added the comment:

I read the first 6 chapters of the devguide.

Now how should I proceed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25453>
_______________________________________

From report at bugs.python.org  Wed Oct 21 17:33:24 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 21 Oct 2015 15:33:24 +0000
Subject: [issue24726] OrderedDict has strange behaviour when dict.__setitem__
 is used.
In-Reply-To: <1437906052.21.0.35165181866.issue24726@psf.upfronthosting.co.za>
Message-ID: <1445441604.02.0.136624803526.issue24726@psf.upfronthosting.co.za>


Eric Snow added the comment:

FTR, this will likely involve more than just fixing odict_repr().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24726>
_______________________________________

From report at bugs.python.org  Wed Oct 21 17:45:43 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 21 Oct 2015 15:45:43 +0000
Subject: [issue25453] Arithmetics with complex infinities is inconsistent with
 C/C++
In-Reply-To: <1445430043.57.0.625714416149.issue25453@psf.upfronthosting.co.za>
Message-ID: <1445442343.85.0.87901860213.issue25453@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Saksham: First we need our "experts" to decide what, if any, change is needed. If we decide that a change is needed, at that point we'd look at a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25453>
_______________________________________

From report at bugs.python.org  Wed Oct 21 17:50:03 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 21 Oct 2015 15:50:03 +0000
Subject: [issue25453] Arithmetics with complex infinities is inconsistent with
 C/C++
In-Reply-To: <1445430043.57.0.625714416149.issue25453@psf.upfronthosting.co.za>
Message-ID: <1445442603.52.0.787186775813.issue25453@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Saksham: Also, it would be best to take this discussion of how to produce a patch to the python-committers mailing list: https://mail.python.org/mailman/listinfo/python-committers

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25453>
_______________________________________

From report at bugs.python.org  Wed Oct 21 18:04:53 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Oct 2015 16:04:53 +0000
Subject: [issue24726] OrderedDict has strange behaviour when dict.__setitem__
 is used.
In-Reply-To: <1437906052.21.0.35165181866.issue24726@psf.upfronthosting.co.za>
Message-ID: <1445443493.65.0.4398194147.issue24726@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24726>
_______________________________________

From report at bugs.python.org  Wed Oct 21 19:06:37 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 21 Oct 2015 17:06:37 +0000
Subject: [issue25453] Arithmetics with complex infinities is inconsistent with
 C/C++
In-Reply-To: <1445430043.57.0.625714416149.issue25453@psf.upfronthosting.co.za>
Message-ID: <1445447197.76.0.0189624046489.issue25453@psf.upfronthosting.co.za>


Berker Peksag added the comment:

> Also, it would be best to take this discussion of how to produce a patch to the python-committers mailing list:

or the core-mentorship list: https://mail.python.org/mailman/listinfo/core-mentorship :)

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25453>
_______________________________________

From report at bugs.python.org  Wed Oct 21 19:10:35 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Oct 2015 17:10:35 +0000
Subject: [issue25417] Minor typo in Path.samefile docstring
In-Reply-To: <1444954626.12.0.126658123546.issue25417@psf.upfronthosting.co.za>
Message-ID: <20151021171028.27534.30235@psf.io>


Roundup Robot added the comment:

New changeset 7d65be20e0d8 by Berker Peksag in branch '3.5':
Issue #25417: Fix typo in Path.samefile() docstring
https://hg.python.org/cpython/rev/7d65be20e0d8

New changeset 0b09a866da77 by Berker Peksag in branch 'default':
Issue #25417: Fix typo in Path.samefile() docstring
https://hg.python.org/cpython/rev/0b09a866da77

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25417>
_______________________________________

From report at bugs.python.org  Wed Oct 21 19:11:24 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 21 Oct 2015 17:11:24 +0000
Subject: [issue25417] Minor typo in Path.samefile docstring
In-Reply-To: <1444954626.12.0.126658123546.issue25417@psf.upfronthosting.co.za>
Message-ID: <1445447484.6.0.052484411269.issue25417@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Fixed, thank you Antony.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25417>
_______________________________________

From report at bugs.python.org  Wed Oct 21 19:20:04 2015
From: report at bugs.python.org (Antony Lee)
Date: Wed, 21 Oct 2015 17:20:04 +0000
Subject: [issue25417] Minor typo in Path.samefile docstring
In-Reply-To: <1444954626.12.0.126658123546.issue25417@psf.upfronthosting.co.za>
Message-ID: <1445448004.18.0.359787856267.issue25417@psf.upfronthosting.co.za>


Antony Lee added the comment:

Actually there's also an extra dot at the end of the first line of the docstring (redundant with the one on the second line).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25417>
_______________________________________

From report at bugs.python.org  Wed Oct 21 19:23:14 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 21 Oct 2015 17:23:14 +0000
Subject: [issue25453] Arithmetics with complex infinities is inconsistent with
 C/C++
In-Reply-To: <1445447197.76.0.0189624046489.issue25453@psf.upfronthosting.co.za>
Message-ID: <2AB2D14C-C790-4C19-80F4-251A9B1BD78B@trueblade.com>


Eric V. Smith added the comment:

> Berker Peksag added the comment:
> 
>> Also, it would be best to take this discussion of how to produce a patch to the python-committers mailing list:
> 
> or the core-mentorship list: https://mail.python.org/mailman/listinfo/core-mentorship :)

Argh! That's of course what I meant. Apologies all around.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25453>
_______________________________________

From report at bugs.python.org  Wed Oct 21 19:29:44 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Oct 2015 17:29:44 +0000
Subject: [issue25449] Test OrderedDict subclass
In-Reply-To: <1445375538.53.0.781433530973.issue25449@psf.upfronthosting.co.za>
Message-ID: <1445448584.78.0.0417250074673.issue25449@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

New patch adds PurePythonOrderedDictSubclassTests, moves all tests except test_key_change_during_iteration from CPythonOrderedDictTests to OrderedDictTests to test Python implementation too, fixes a bug in values and items iteration that caused test_issue24347 to fail, and adds additional explicit checks for values() and items() to test_issue24347.

----------
type: enhancement -> behavior
Added file: http://bugs.python.org/file40832/odict_subclass_test_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25449>
_______________________________________

From report at bugs.python.org  Wed Oct 21 19:43:28 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 21 Oct 2015 17:43:28 +0000
Subject: [issue20504] cgi.FieldStorage, multipart, missing Content-Length
In-Reply-To: <1391463199.17.0.394387661768.issue20504@psf.upfronthosting.co.za>
Message-ID: <1445449408.95.0.951426375552.issue20504@psf.upfronthosting.co.za>


Berker Peksag added the comment:

The attached patch(cgi.patch) doesn't fix the problem for me: cgi-bug.py still fails with a TypeError. Here is a patch with a test to fix the problem.

With issue20504.diff applied:

$ ./python t.py 
5

(Only changed the "assert len(fields["my-arg"].file.read()) == 5" line with "print(len(fields["my-arg"].file.read()))")

----------
nosy: +berker.peksag
stage:  -> patch review
versions: +Python 3.6 -Python 3.3
Added file: http://bugs.python.org/file40833/issue20504.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20504>
_______________________________________

From report at bugs.python.org  Wed Oct 21 20:04:53 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 21 Oct 2015 18:04:53 +0000
Subject: [issue25453] Arithmetics with complex infinities is inconsistent with
 C/C++
In-Reply-To: <1445430043.57.0.625714416149.issue25453@psf.upfronthosting.co.za>
Message-ID: <1445450693.68.0.697958161152.issue25453@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

If the proposal is to add C99 Appendix G-style handling of nan+nanj results for complex multiplication, that doesn't seem unreasonable to me, though I'm not particularly convinced that the gain in complexity is worth it.  So -0 from me. Whatever happens, I'd hope that the complex multiplication operation 
remains simple and easily explainable, not degenerating into a mass of special cases.

I'd be opposed to adding special-case handing for float-by-complex multiplication (i.e., doing anything other than promoting the float to a complex by introducing a zero imaginary part, and then doing normal complex multiplication).  But I don't think that's what Francesco is proposing.

FWIW, NumPy semantics follow those of Python, though that's hardly an independent data point.

In answer to Steven, IEEE 754 has precisely nothing to say on this subject: it simply doesn't cover complex arithmetic.

Francesco: by the way, I'd be interested to see the C source that gave you `inf + nan*j` for this.  How did you initialise the arguments to the multiplication? C99 has a significant issue here (fixed in C2011), namely that there's no standard way to create a complex value with given real and imaginary parts.  (Using real_part + I*imaginary_part doesn't count, because in the absence of the Imaginary type, which few compilers seem to implement, the real part of the "I" constant mucks up the arithmetic w.r.t. infinities, NaNs and signed zeros.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25453>
_______________________________________

From report at bugs.python.org  Wed Oct 21 20:06:46 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 21 Oct 2015 18:06:46 +0000
Subject: [issue25453] Arithmetics with complex infinities is inconsistent with
 C/C++
In-Reply-To: <1445430043.57.0.625714416149.issue25453@psf.upfronthosting.co.za>
Message-ID: <1445450806.67.0.559647636649.issue25453@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Changing Python versions and issue type: the current behaviour is certainly deliberate, so a proposal to change it would be a feature request, which could only land in Python 3.6 or later.

----------
type: behavior -> enhancement
versions:  -Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25453>
_______________________________________

From report at bugs.python.org  Wed Oct 21 20:22:46 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 21 Oct 2015 18:22:46 +0000
Subject: [issue25453] Arithmetics with complex infinities is inconsistent with
 C/C++
In-Reply-To: <1445430043.57.0.625714416149.issue25453@psf.upfronthosting.co.za>
Message-ID: <1445451766.48.0.0315208341547.issue25453@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25453>
_______________________________________

From report at bugs.python.org  Wed Oct 21 20:46:03 2015
From: report at bugs.python.org (Francesco Biscani)
Date: Wed, 21 Oct 2015 18:46:03 +0000
Subject: [issue25453] Arithmetics with complex infinities is inconsistent with
 C/C++
In-Reply-To: <1445430043.57.0.625714416149.issue25453@psf.upfronthosting.co.za>
Message-ID: <1445453163.17.0.87817016353.issue25453@psf.upfronthosting.co.za>


Francesco Biscani added the comment:

Hi Mark,

the original code is C++, and the inf + nanj result can be reproduced by the following snippet:

"""
#include <complex>
#include <iostream>

int main(int argc, char * argv[]) {
  std::cout << std::complex<double>(3,0) / 0. << '\n';
  return 0;
}
"""

Here is the C99 version:

"""
#include <complex.h>
#include <math.h>
#include <stdio.h>

int main(int argc, char * argv[]) {
  double complex a = 3.0 + 0.0*I;
  printf("%f + i%f\n", creal(a/0.), cimag(a/0.));
  return 0;
}
"""

This is on Linux x86_64 with GCC 4.9. Clang gives the same result. Adding the "-ffast-math" compilation flag changes the result for the C version but apparently not for the C++ one.

The original code came from an implementation of a special function f(z) which has a pole near the origin. When computing f(0), the C++ code returns inf+nan*j, which is fine (in the sense that it is a complex infinity of some kind). I then need to use this result in a larger piece of code which at one point needs to compute 1/f(0), with the expected result being 0 mathematically. This works if I implement the calculation all within C/C++, but if I switch to Python when computing 1/f(0) I get nan + nan*j as a result.

Of course I could do all sorts of stuff to improve this specific calculation and avoid the problems (possibly improving the numerical behaviour near the pole via a Taylor expansion, etc. etc. etc.).

Beware that implementing C99 behaviour will result in a noticeable overhead for complex operations. In compiled C/C++ code one usually has the option to switch on/off the -ffast-math flag to improve performance at the expense of standard-conformance, but I imagine this is not feasible in Python.

----------

_______________________________________
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: [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:02:17 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 21 Oct 2015 19:02:17 +0000
Subject: [issue25453] Arithmetics with complex infinities is inconsistent with
 C/C++
In-Reply-To: <1445430043.57.0.625714416149.issue25453@psf.upfronthosting.co.za>
Message-ID: <1445454137.05.0.796654977271.issue25453@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Thanks for the update.

I'm not too worried about performance: I suspect that any additional overhead would be lost in the overhead of the Python machinery. It would be worth profiling to check, of course, before any change went in. I'd expect that most performance critical code of this type would be using NumPy/SciPy anyway.

I'm still unsure about whether the code is worth changing: I do agree that the behaviour suggested by C99 Annex G is (in the abstract) an improvement on Python's current behaviour, and compatibility with C would be a plus. On the other side, introducing an incompatibility with other versions of Python and with NumPy isn't ideal. For me, the potential benefits don't really overcome the drawbacks here, but I'd like to hear other opinions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25453>
_______________________________________

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: [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  Wed Oct 21 21:18:33 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Oct 2015 19:18:33 +0000
Subject: [issue24726] OrderedDict has strange behaviour when dict.__setitem__
 is used.
In-Reply-To: <1437906052.21.0.35165181866.issue24726@psf.upfronthosting.co.za>
Message-ID: <1445455113.08.0.0636653904961.issue24726@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

__repr__() allocates a list with the size len(od) and fills it iterating linked list. If the size of linked list is less then the size of the dict, the rest of the list is not initialized.

Even worse things happened when the size of linked list is greater then the size of the dict. Following example causes a crash:

from collections import OrderedDict
od = OrderedDict()
class K(str):
    def __hash__(self):
        return 1

od[K('a')] = 1
od[K('b')] = 2
print(len(od), len(list(od)))
K.__eq__ = lambda self, other: True
dict.__delitem__(od, K('a'))
print(len(od), len(list(od)))
print(repr(od))

Proposed patch fixes both issues.

----------
components: +Extension Modules -Library (Lib)
keywords: +patch
stage: test needed -> patch review
type: behavior -> crash
versions:  -Python 2.7, Python 3.4
Added file: http://bugs.python.org/file40834/odict_repr_after_dict_setitem_delitem.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24726>
_______________________________________

From report at bugs.python.org  Wed Oct 21 21:51:42 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 21 Oct 2015 19:51:42 +0000
Subject: [issue25450] Python 3.5 starts in C:\Windows\system32 as current
 directory
In-Reply-To: <1445376716.84.0.123418793499.issue25450@psf.upfronthosting.co.za>
Message-ID: <1445457102.23.0.286097527291.issue25450@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
assignee:  -> steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25450>
_______________________________________

From report at bugs.python.org  Thu Oct 22 00:53:22 2015
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 21 Oct 2015 22:53:22 +0000
Subject: [issue24782] Merge 'configure extensions' into main IDLE config dialog
In-Reply-To: <1438549617.46.0.760286591646.issue24782@psf.upfronthosting.co.za>
Message-ID: <1445468002.44.0.282313875136.issue24782@psf.upfronthosting.co.za>


Mark Roseman added the comment:

The extra width appears to be coming from the canvas inside VerticalScrolledFrame; the canvas gets the default size and the frame adjusts to fit its contents (the canvas and the scrollbar). If you really want to reduce the size, add a "-width" option where that canvas is being created.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24782>
_______________________________________

From report at bugs.python.org  Thu Oct 22 02:29:20 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 22 Oct 2015 00:29:20 +0000
Subject: [issue23981] Update test_unicodedata.py to use script_helpers
In-Reply-To: <1429228835.0.0.167852596687.issue23981@psf.upfronthosting.co.za>
Message-ID: <20151022002915.20753.4755@psf.io>


Roundup Robot added the comment:

New changeset fbd83224e132 by Berker Peksag in branch '3.5':
Issue #23981: Update test_unicodedata to use script_helpers
https://hg.python.org/cpython/rev/fbd83224e132

New changeset 6315abbf5f71 by Berker Peksag in branch 'default':
Issue #23981: Update test_unicodedata to use script_helpers
https://hg.python.org/cpython/rev/6315abbf5f71

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23981>
_______________________________________

From report at bugs.python.org  Thu Oct 22 02:30:48 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 22 Oct 2015 00:30:48 +0000
Subject: [issue23981] Update test_unicodedata.py to use script_helpers
In-Reply-To: <1429228835.0.0.167852596687.issue23981@psf.upfronthosting.co.za>
Message-ID: <1445473848.6.0.168727444915.issue23981@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Christie.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23981>
_______________________________________

From report at bugs.python.org  Thu Oct 22 02:34:19 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 22 Oct 2015 00:34:19 +0000
Subject: [issue25417] Minor typo in Path.samefile docstring
In-Reply-To: <1444954626.12.0.126658123546.issue25417@psf.upfronthosting.co.za>
Message-ID: <20151022003416.18366.43290@psf.io>


Roundup Robot added the comment:

New changeset 642a7be9f384 by Berker Peksag in branch '3.5':
Issue #25417: Remove the extra dot from docstring
https://hg.python.org/cpython/rev/642a7be9f384

New changeset 4cd2ae001d30 by Berker Peksag in branch 'default':
Issue #25417: Remove the extra dot from docstring
https://hg.python.org/cpython/rev/4cd2ae001d30

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25417>
_______________________________________

From report at bugs.python.org  Thu Oct 22 06:49:18 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 22 Oct 2015 04:49:18 +0000
Subject: [issue25210] Special-case NoneType() in do_richcompare()
In-Reply-To: <1442900927.33.0.98928488186.issue25210@psf.upfronthosting.co.za>
Message-ID: <20151022044915.75690.20775@psf.io>


Roundup Robot added the comment:

New changeset 5c7dd88cd0c5 by Berker Peksag in branch 'default':
Issue #25210: Add some basic tests for the new exception message
https://hg.python.org/cpython/rev/5c7dd88cd0c5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25210>
_______________________________________

From report at bugs.python.org  Thu Oct 22 08:27:52 2015
From: report at bugs.python.org (Alexander Riccio)
Date: Thu, 22 Oct 2015 06:27:52 +0000
Subject: [issue25386] msvcrt_putch/msvcrt_putwch don't check the return value
 of _putch/_putwch
In-Reply-To: <1444693845.85.0.133666844386.issue25386@psf.upfronthosting.co.za>
Message-ID: <1445495272.52.0.0250355401595.issue25386@psf.upfronthosting.co.za>


Alexander Riccio added the comment:

Sorry for the delay: Gmail actually directed the update emails to my spam folder! Gmail said (something like): "It is in violation of Google's recommended email sender guidelines."

...and it's apparently not the first time this has happened with the python bugtracker: https://mail.python.org/pipermail/tracker-discuss/2015-January/003989.html


Anyways:

> That's a great test, thanks.

That IS a great test :)

> I'm curious: did you [Alexander] have some code where you're actually expecting an exception, or did you just stumble across this case?

Nope, I was just poking around the sources. I was curious to see what CPython's C implementation looked like, and decided to poke around some of the dustier, and the less used corners.

That, and I'm really OCD about checking return values.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25386>
_______________________________________

From report at bugs.python.org  Thu Oct 22 09:00:36 2015
From: report at bugs.python.org (Jurjen N.E. Bos)
Date: Thu, 22 Oct 2015 07:00:36 +0000
Subject: [issue24925] Allow doctest to find line number of __test__ strings if
 formatted as a triple quoted string.
In-Reply-To: <1440433204.72.0.951879790885.issue24925@psf.upfronthosting.co.za>
Message-ID: <1445497236.14.0.00506761697272.issue24925@psf.upfronthosting.co.za>


Jurjen N.E. Bos added the comment:

I am not as good in making nice patches, but that code can be improved upon a bit as follows:
<insert patch intro blurb here, same as original>

+        if isinstance(obj, str) and source_lines is not None:
+            # This will find __test__ string doctests if and only if the string
+            # contains any unique line.
+            for offset,line in enumerate(obj.splitlines(keepends=True):
+                if source_lines.count(line)==1:
+                    lineno = source_lines.index(line)-offset
+                    break

         # We couldn't find the line number.
         return None


I thing this will improve legibility and probably also speed under most circumstances.

----------
nosy: +jneb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24925>
_______________________________________

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: [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 09:14:47 2015
From: report at bugs.python.org (Jurjen N.E. Bos)
Date: Thu, 22 Oct 2015 07:14:47 +0000
Subject: [issue24925] Allow doctest to find line number of __test__ strings if
 formatted as a triple quoted string.
In-Reply-To: <1440433204.72.0.951879790885.issue24925@psf.upfronthosting.co.za>
Message-ID: <1445498087.75.0.555088069786.issue24925@psf.upfronthosting.co.za>


Jurjen N.E. Bos added the comment:

Oops. Lousy editing, I should have used return instead of break.

These 6 lines can be inserted in lib/doctest at line 1100:
+        if isinstance(obj, str) and source_lines is not None:
+            # This will find __test__ string doctests if and only if the string
+            # contains any unique line.
+            for offset,line in enumerate(obj.splitlines(keepends=True):
+                if source_lines.count(line)==1:
+                    return source_lines.index(line)-offset

And it works fine for me; the code is quite general and has predictable behaviour: any test string with a unique line in it will work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24925>
_______________________________________

From report at bugs.python.org  Thu Oct 22 09:28:25 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 22 Oct 2015 07:28:25 +0000
Subject: [issue24782] Merge 'configure extensions' into main IDLE config dialog
In-Reply-To: <1438549617.46.0.760286591646.issue24782@psf.upfronthosting.co.za>
Message-ID: <20151022072822.7244.76442@psf.io>


Roundup Robot added the comment:

New changeset a96e39e20490 by Terry Jan Reedy in branch '2.7':
Issue #24782: Limit width of canvas and hence IDLE settings dialog.
https://hg.python.org/cpython/rev/a96e39e20490

New changeset 0847398f9b00 by Terry Jan Reedy in branch '3.4':
Issue #24782: Limit width of canvas and hence IDLE settings dialog.
https://hg.python.org/cpython/rev/0847398f9b00

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24782>
_______________________________________

From report at bugs.python.org  Thu Oct 22 09:30:58 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 22 Oct 2015 07:30:58 +0000
Subject: [issue24782] Merge 'configure extensions' into main IDLE config dialog
In-Reply-To: <1438549617.46.0.760286591646.issue24782@psf.upfronthosting.co.za>
Message-ID: <1445499058.92.0.0633897739244.issue24782@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Thanks, that was it.  I actually want to not use the scroll bar unless needed for an extension with more than 15 or so settings, but that is another patch.  Ditto for the list of extensions.  This looks OK for now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24782>
_______________________________________

From report at bugs.python.org  Thu Oct 22 09:45:44 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Oct 2015 07:45:44 +0000
Subject: [issue20504] cgi.FieldStorage, multipart, missing Content-Length
In-Reply-To: <1391463199.17.0.394387661768.issue20504@psf.upfronthosting.co.za>
Message-ID: <1445499944.22.0.443629337459.issue20504@psf.upfronthosting.co.za>


STINNER Victor added the comment:

See also issue #24764: "cgi.FieldStorage.read_multi ignores Content-Length" (changeset 11e9f34169d1).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20504>
_______________________________________

From report at bugs.python.org  Thu Oct 22 09:59:37 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Oct 2015 07:59:37 +0000
Subject: [issue20504] cgi.FieldStorage, multipart, missing Content-Length
In-Reply-To: <1391463199.17.0.394387661768.issue20504@psf.upfronthosting.co.za>
Message-ID: <1445500777.91.0.861839821654.issue20504@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I reviewed issue20504.diff on Rietveld.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20504>
_______________________________________

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: [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:28:58 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 22 Oct 2015 10:28:58 +0000
Subject: [issue25323] Bus error: 10 when executing recursive program
In-Reply-To: <1444128171.82.0.123240917074.issue25323@psf.upfronthosting.co.za>
Message-ID: <1445509738.23.0.134353411738.issue25323@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

W.r.t. the bus error on OSX: see issue #18049, the default stack size on OSX is too small to reach the default recursion limit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25323>
_______________________________________

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: [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 13:59:25 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Oct 2015 11:59:25 +0000
Subject: [issue25452] Add __bool__() method to subprocess.CompletedProcess
In-Reply-To: <1445424658.54.0.134413313052.issue25452@psf.upfronthosting.co.za>
Message-ID: <1445515165.16.0.89170230243.issue25452@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Can you please give examples of use cases? (code)

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25452>
_______________________________________

From report at bugs.python.org  Thu Oct 22 14:00:03 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Oct 2015 12:00:03 +0000
Subject: [issue25451] tkinter: PhotoImage transparency methods
In-Reply-To: <1445417795.5.0.279905447074.issue25451@psf.upfronthosting.co.za>
Message-ID: <1445515203.23.0.242975380402.issue25451@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: PhotoImage transparency methods -> tkinter: PhotoImage transparency methods

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25451>
_______________________________________

From report at bugs.python.org  Thu Oct 22 15:12:32 2015
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 22 Oct 2015 13:12:32 +0000
Subject: [issue25456] 3.4 _tkinter build fails, Windows 10, no tcl.h
In-Reply-To: <1445497790.14.0.147176888356.issue25456@psf.upfronthosting.co.za>
Message-ID: <1445519552.1.0.690718377081.issue25456@psf.upfronthosting.co.za>


Zachary Ware added the comment:

3.4 still requires Tcl/Tk to be built outside of VS, and its too late in the 3.4 release cycle to think about changing it. PCbuild\build.bat has been updated to do the Tcl/Tk build, though; run "PCbuild\build.bat -e -d" (remove '-d' for a Release build) once, and you shouldn't need to worry about Tcl/Tk again for the remaining life of 3.4.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25456>
_______________________________________

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: [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 16:01:30 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Oct 2015 14:01:30 +0000
Subject: [issue25459] EAGAIN errors in Python logging module
In-Reply-To: <1445522395.9.0.458727890682.issue25459@psf.upfronthosting.co.za>
Message-ID: <1445522490.01.0.701567180376.issue25459@psf.upfronthosting.co.za>


STINNER Victor added the comment:

What is the type of the stream? Is is a pipe or a regular file? Or a socket?

Can you please format the patch as an unified patch please?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25459>
_______________________________________

From report at bugs.python.org  Thu Oct 22 16:18:14 2015
From: report at bugs.python.org (Vikas)
Date: Thu, 22 Oct 2015 14:18:14 +0000
Subject: [issue17468] Generator memory leak
In-Reply-To: <1363638865.27.0.0312549957802.issue17468@psf.upfronthosting.co.za>
Message-ID: <1445523494.87.0.915127442366.issue17468@psf.upfronthosting.co.za>


Vikas added the comment:

I see this comment :
>> When iteration over a queryset raised an exception, the result cache remained initialized with an empty list, so subsequent iterations returned an empty list instead of raising an exception>>

What if we catch the exceptions? Will that cause not to leak memory?

----------
nosy: +Vikas

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17468>
_______________________________________

From report at bugs.python.org  Thu Oct 22 17:03:13 2015
From: report at bugs.python.org (Henrique Andrade)
Date: Thu, 22 Oct 2015 15:03:13 +0000
Subject: [issue25459] EAGAIN errors in Python logging module
In-Reply-To: <1445522490.01.0.701567180376.issue25459@psf.upfronthosting.co.za>
Message-ID: <CALAFW=BAHL3nDdHTd0hwh8zMNdZiCdKrTXHFgB8V2gvB8NSHiA@mail.gmail.com>


Henrique Andrade added the comment:

The stream in this case (where I hit the bug) is just the console, but I
suspect the same issue will affect other streams too.

A key piece of information is that this is probably triggered by having a
custom SIGPIPE handler, which my particular application has.

When a SIGPIPE handler is in place, errors such as EAGAIN and EWOULDBLOCK
might be generated and the logging module wasn't resilient to it.

Here is the unified patch output:

11:00:38|sequoia|/opt/continuum/anaconda> diff -u
/opt/continuum/anaconda/pkgs/python-2.7.8-0/lib/python2.7/logging/__init__.py
/opt/continuum/anaconda/pkgs/python-2.7.8-1/lib/python2.7/logging/__init__.py
---
/opt/continuum/anaconda/pkgs/python-2.7.8-0/lib/python2.7/logging/__init__.py
2014-07-02
19:08:57.000000000 -0400
+++
/opt/continuum/anaconda/pkgs/python-2.7.8-1/lib/python2.7/logging/__init__.py
2015-09-22
13:57:39.196032267 -0400
@@ -23,7 +23,7 @@
 To use, simply 'import logging' and log away!
 """

-import sys, os, time, cStringIO, traceback, warnings, weakref, collections
+import sys, os, time, cStringIO, traceback, warnings, weakref,
collections, errno

 __all__ = ['BASIC_FORMAT', 'BufferingFormatter', 'CRITICAL', 'DEBUG',
'ERROR',
            'FATAL', 'FileHandler', 'Filter', 'Formatter', 'Handler',
'INFO',
@@ -877,7 +877,13 @@
                             #An extra encoding step seems to be needed.
                             stream.write((ufs %
msg).encode(stream.encoding))
                     else:
-                        stream.write(fs % msg)
+                        while True:
+                            try:
+                                stream.write(fs % msg)
+                                break
+                            except IOError as e:
+                                if e.errno != errno.EAGAIN:
+                                    raise
                 except UnicodeError:
                     stream.write(fs % msg.encode("UTF-8"))
             self.flush()

On Thu, Oct 22, 2015 at 10:01 AM, STINNER Victor <report at bugs.python.org>
wrote:

>
> STINNER Victor added the comment:
>
> What is the type of the stream? Is is a pipe or a regular file? Or a
> socket?
>
> Can you please format the patch as an unified patch please?
>
> ----------
> nosy: +haypo
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue25459>
> _______________________________________
>

----------

_______________________________________
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: [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 17:15:04 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Oct 2015 15:15:04 +0000
Subject: [issue25460] Misc/.gdbinit uses preprocessor macro
In-Reply-To: <1445526835.22.0.109540938613.issue25460@psf.upfronthosting.co.za>
Message-ID: <1445526904.16.0.644058563265.issue25460@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> GNU gdb (GDB) 7.9.50.20150218-cvs

Since you have using a recent version of gdb supporting python scripting, you must test python-gdb.py which is more reliable and has more features.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25460>
_______________________________________

From report at bugs.python.org  Thu Oct 22 18:14:33 2015
From: report at bugs.python.org (Mark Roseman)
Date: Thu, 22 Oct 2015 16:14:33 +0000
Subject: [issue25244] Idle: refine right-click behavior
In-Reply-To: <1443309139.01.0.264782757887.issue25244@psf.upfronthosting.co.za>
Message-ID: <1445530473.1.0.729868746525.issue25244@psf.upfronthosting.co.za>


Changes by Mark Roseman <mark at markroseman.com>:


----------
nosy: +markroseman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25244>
_______________________________________

From report at bugs.python.org  Thu Oct 22 18:15:24 2015
From: report at bugs.python.org (Richard Neumann)
Date: Thu, 22 Oct 2015 16:15:24 +0000
Subject: [issue25452] Add __bool__() method to subprocess.CompletedProcess
In-Reply-To: <1445424658.54.0.134413313052.issue25452@psf.upfronthosting.co.za>
Message-ID: <1445530524.9.0.564632266909.issue25452@psf.upfronthosting.co.za>


Richard Neumann added the comment:

A useless use case is attached.
Basically it boils down to having the ability to evaluate the CompletedProcess directly by if/else rather than comparing its returncode attribute to zero each time or handling the exception raised by check_returncode().
I use this quite frequently in programs which run system commands.
Before the new subprocess.run() method and subprocess.CompletedProcess were introduced with python 3.5 I already wrote my own library for that, wich now nearly became obsoleted by the new subprocess library of python 3.5 with the expection that it does not have this feature.
See the class ProcessResult here: https://github.com/HOMEINFO/homeinfo-lib/blob/master/homeinfo/lib/system.py

----------
Added file: http://bugs.python.org/file40836/usecase.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25452>
_______________________________________

From report at bugs.python.org  Thu Oct 22 18:25:52 2015
From: report at bugs.python.org (Eric Price)
Date: Thu, 22 Oct 2015 16:25:52 +0000
Subject: [issue23735] Readline not adjusting width after resize with 6.3
In-Reply-To: <1426984974.32.0.405944458303.issue23735@psf.upfronthosting.co.za>
Message-ID: <1445531152.18.0.910958158192.issue23735@psf.upfronthosting.co.za>


Eric Price added the comment:

This patch seems to fix the issue for me, by installing a signal handler for SIGWINCH that sets a flag which is checked while waiting for input.

One could make a simpler patch that just calls rl_resize_terminal() from the signal handler.  That would essentially replicate the pre-readline 6.2 behavior, which worked fine, but supposedly it's `dangerous'.

----------
keywords: +patch
nosy: +Eric Price
Added file: http://bugs.python.org/file40837/rl_sigwinch_update.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23735>
_______________________________________

From report at bugs.python.org  Thu Oct 22 18:29:32 2015
From: report at bugs.python.org (Francesco Biscani)
Date: Thu, 22 Oct 2015 16:29:32 +0000
Subject: [issue25453] Arithmetics with complex infinities is inconsistent with
 C/C++
In-Reply-To: <1445430043.57.0.625714416149.issue25453@psf.upfronthosting.co.za>
Message-ID: <1445531372.07.0.368286557228.issue25453@psf.upfronthosting.co.za>


Francesco Biscani added the comment:

@Mark

Yes I understand that this is a thorny issue. I was kinda hoping NumPy would just forward complex arithmetic to the underlying C implementation, but apparently that's not the case (which OTOH makes sense as the use of C99 complex numbers is not that widespread).

FWIW, the quoted section in the C standard (Annex G) contains the pseudocode for standard-conforming implementations of complex multiplication and division, in case the decision is taken to change the behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25453>
_______________________________________

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: [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  Thu Oct 22 19:10:02 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 22 Oct 2015 17:10:02 +0000
Subject: [issue25461] Unclear language (the word ineffective) in the
 documentation for os.walk
In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za>
Message-ID: <1445533802.01.0.795112537095.issue25461@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Thanks for the report.
This sounds like a reasonable request to me.
Would you like to make a patch?
(If so, you can check the devguide.)

----------
keywords: +easy
nosy: +ezio.melotti
stage:  -> needs patch
versions: +Python 3.4, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25461>
_______________________________________

From report at bugs.python.org  Thu Oct 22 19:15:39 2015
From: report at bugs.python.org (=?utf-8?q?Bernt_R=C3=B8skar_Brenna?=)
Date: Thu, 22 Oct 2015 17:15:39 +0000
Subject: [issue25461] Unclear language (the word ineffective) in the
 documentation for os.walk
In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za>
Message-ID: <1445534139.75.0.0950249807918.issue25461@psf.upfronthosting.co.za>


Bernt R?skar Brenna added the comment:

OK, I'll submit a patch

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25461>
_______________________________________

From report at bugs.python.org  Thu Oct 22 19:20:04 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 22 Oct 2015 17:20:04 +0000
Subject: [issue25410] Clean up and fix OrderedDict
In-Reply-To: <1444896308.75.0.718152743923.issue25410@psf.upfronthosting.co.za>
Message-ID: <20151022171952.27514.90139@psf.io>


Roundup Robot added the comment:

New changeset a42c0c1c5133 by Serhiy Storchaka in branch '3.5':
Issue #25410: C implementation of OrderedDict now uses type(self) instead of
https://hg.python.org/cpython/rev/a42c0c1c5133

New changeset 10b965d59b49 by Serhiy Storchaka in branch 'default':
Issue #25410: C implementation of OrderedDict now uses type(self) instead of
https://hg.python.org/cpython/rev/10b965d59b49

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25410>
_______________________________________

From report at bugs.python.org  Thu Oct 22 19:31:03 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 22 Oct 2015 17:31:03 +0000
Subject: [issue25461] Unclear language (the word ineffective) in the
 documentation for os.walk
In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za>
Message-ID: <1445535063.78.0.914665721406.issue25461@psf.upfronthosting.co.za>


R. David Murray added the comment:

As an English speaker, I prefer ineffective.  Modifying dirnames does have an effect, it modifies dirnames.  What it doesn't do (is ineffective at) is thereby altering the behavior of walk.

If you want to avoid ineffective because its meaning is subtle (a reasonable request), the correct replacement would be "modifying dirnames has no effect on the behavior of the walk", which is wordier but clearer.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25461>
_______________________________________

From report at bugs.python.org  Thu Oct 22 19:42:44 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 22 Oct 2015 17:42:44 +0000
Subject: [issue18820] json.dump() ignores its 'default' option when
 serializing dictionary keys
In-Reply-To: <1377253830.03.0.463497944995.issue18820@psf.upfronthosting.co.za>
Message-ID: <1445535764.06.0.630800886206.issue18820@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
stage: test needed -> patch review
type: enhancement -> behavior
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18820>
_______________________________________

From report at bugs.python.org  Thu Oct 22 20:15:07 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Oct 2015 18:15:07 +0000
Subject: [issue25462] Avoid repeated hash calculation in C implementation of
 OrderedDict
Message-ID: <1445537707.4.0.965290035462.issue25462@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There are private _PyDict_*_KnownHash functions that allow to avoid repeated hash calculation in complex operations with a dict. Proposed patch makes C implementation of OrderedDict to use these functions. It is not just an optimization, it makes some OrderedDict methods atomic (or almost atomic), that decreases a chance to desynchronize the linked list with the dict. That is why I suggest to commit the patch in 3.5.

----------
components: Regular Expressions
files: odict_knownhash.patch
keywords: patch
messages: 253343
nosy: eric.snow, ezio.melotti, mrabarnett, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Avoid repeated hash calculation in C implementation of OrderedDict
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40838/odict_knownhash.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25462>
_______________________________________

From report at bugs.python.org  Thu Oct 22 20:20:06 2015
From: report at bugs.python.org (Laszlo Nagy)
Date: Thu, 22 Oct 2015 18:20:06 +0000
Subject: [issue20120] Percent-signs (%) in .pypirc should not be interpolated
In-Reply-To: <1388825675.42.0.435893533792.issue20120@psf.upfronthosting.co.za>
Message-ID: <1445538006.56.0.563789141528.issue20120@psf.upfronthosting.co.za>


Laszlo Nagy added the comment:

When I uploaded via "setup.py register" and created a new user, then distutils saved the password in the wrong format! So maybe the password read part is a wontfix, but then the save part must be fixed.

----------
nosy: +nagylzs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20120>
_______________________________________

From report at bugs.python.org  Sun Oct 25 11:50:44 2015
From: report at bugs.python.org (Vilnis Termanis)
Date: Sun, 25 Oct 2015 15:50:44 +0000
Subject: [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
In-Reply-To: <1445681395.35.0.393874869917.issue25469@psf.upfronthosting.co.za>
Message-ID: <1445788244.52.0.473500791521.issue25469@psf.upfronthosting.co.za>


Vilnis Termanis added the comment:

A few additional notes:

1) On an AMD E-450 under Ubuntu 14.04 x64 with a current in-development build, when running condition_test.py, Condition.notify_all() takes (measure using time.clock) 0.0003 with the patch and 0.3219 without it. Additionally the in-script timeit calls seem to suggest that the patch does not adversely affect Condition.wait().

2) Unit tests have also been run against test_multiprocessing_forkserver (typo in original message).

3) A scenario where this might become apparent would be to have many worker processes which have a loop along the lines of:

while not event.is_set():
  do_more_work()
  # Pause because the task is only supposed to happen every X seconds
  # or a wait is in effect due to an error. Do not want to use
  # time.sleep so loop is exited promptly rather than blindly sleeping.
  event.wait(some_amount)
other_work_or_shutdown()

If many processes call event.wait() with a timeout and the event is not set often (e.g. since it's a shutdown flag), a long-running program with many worker processes can end up having event.set() take a considerable amount of time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25469>
_______________________________________

From report at bugs.python.org  Sat Oct 24 10:56:35 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Oct 2015 14:56:35 +0000
Subject: [issue18010] pydoc search chokes on import errors
In-Reply-To: <1368896719.35.0.915741072389.issue18010@psf.upfronthosting.co.za>
Message-ID: <1445698595.95.0.490818571258.issue18010@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage: needs patch -> test needed
versions: +Python 3.5, Python 3.6 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18010>
_______________________________________

From report at bugs.python.org  Sun Oct 25 15:46:21 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Oct 2015 19:46:21 +0000
Subject: [issue892902] problem with pickling newstyle class instances
Message-ID: <1445802381.33.0.971006514783.issue892902@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch that backports recursive objects handling to 2.7.

----------
keywords: +patch
nosy: +serhiy.storchaka
stage: needs patch -> patch review
Added file: http://bugs.python.org/file40859/pickle_recursive-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue892902>
_______________________________________

From report at bugs.python.org  Fri Oct 23 11:56:13 2015
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 23 Oct 2015 15:56:13 +0000
Subject: [issue25154] Drop the pyvenv script
In-Reply-To: <1442514921.37.0.255858283829.issue25154@psf.upfronthosting.co.za>
Message-ID: <1445615773.71.0.335381812152.issue25154@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

May I ask how difficult it is for any of the core developers to fix a known typo in a Python source file?

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25154>
_______________________________________

From report at bugs.python.org  Sat Oct 24 10:45:52 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Oct 2015 14:45:52 +0000
Subject: [issue21160] incorrect comments in nturl2path.py
In-Reply-To: <1396694736.78.0.949476383561.issue21160@psf.upfronthosting.co.za>
Message-ID: <1445697952.13.0.165031500451.issue21160@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your patch Jurko.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21160>
_______________________________________

From report at bugs.python.org  Fri Oct 23 07:22:42 2015
From: report at bugs.python.org (Herbert)
Date: Fri, 23 Oct 2015 11:22:42 +0000
Subject: [issue25465] Pickle uses O(n) memory overhead
In-Reply-To: <1445593043.5.0.334623277706.issue25465@psf.upfronthosting.co.za>
Message-ID: <1445599362.29.0.438798202807.issue25465@psf.upfronthosting.co.za>


Herbert added the comment:

That sound reasonable regarding why O(n), but it does not explain why linux crashes (I've seen this on two ubuntu systems)if pickle runs out of memory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25465>
_______________________________________

From report at bugs.python.org  Sat Oct 24 04:25:07 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 24 Oct 2015 08:25:07 +0000
Subject: [issue25465] Pickle uses O(n) memory overhead
In-Reply-To: <1445593043.5.0.334623277706.issue25465@psf.upfronthosting.co.za>
Message-ID: <1445675107.14.0.68097220598.issue25465@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

In what way does the OS crash? Are there any kernel messages? Or is this the python executable crashing? Again, if so, what messages are printed?

In any event, if this really is an OS crash, then it's a Linux bug and should be reported to them.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25465>
_______________________________________

From report at bugs.python.org  Fri Oct 23 06:15:21 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Oct 2015 10:15:21 +0000
Subject: [issue25461] Unclear language (the word ineffective) in the
 documentation for os.walk
In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za>
Message-ID: <1445595321.64.0.628392265498.issue25461@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25461>
_______________________________________

From report at bugs.python.org  Fri Oct 23 12:09:03 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 23 Oct 2015 16:09:03 +0000
Subject: [issue25466] offer "from __future__ import" option for "raise... from"
In-Reply-To: <1445613687.79.0.0523081768685.issue25466@psf.upfronthosting.co.za>
Message-ID: <1445616543.05.0.612816219974.issue25466@psf.upfronthosting.co.za>


R. David Murray added the comment:

I doubt we are going to add such a feature to python2 at this point, since people have worked out various workarounds (see the six module). We do not at this point add features to python2 unless there's a really compelling reason (eg: security).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25466>
_______________________________________

From report at bugs.python.org  Fri Oct 23 06:51:12 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Oct 2015 10:51:12 +0000
Subject: [issue25461] Unclear language (the word ineffective) in the
 documentation for os.walk
In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za>
Message-ID: <1445597472.92.0.320948061076.issue25461@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> If you want to avoid ineffective because its meaning is subtle (a reasonable request), the correct replacement would be "modifying dirnames has no effect on the behavior of the walk", which is wordier but clearer.

I prefer the new sentence, it's more explicit. Maybe I pushed the change too fast.

@David: are you ok with the change?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25461>
_______________________________________

From report at bugs.python.org  Sat Oct 24 23:07:43 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 25 Oct 2015 03:07:43 +0000
Subject: [issue25471] socket.recv() blocks while it's gettimeout() returns 0.0
In-Reply-To: <1445727809.94.0.696138695468.issue25471@psf.upfronthosting.co.za>
Message-ID: <20151025030739.34043.87799@psf.io>


Roundup Robot added the comment:

New changeset 10e044a734f3 by Benjamin Peterson in branch '3.4':
accepted sockets shouldn't inherit the SOCK_NONBLOCK flag (closes #25471)
https://hg.python.org/cpython/rev/10e044a734f3

New changeset 7577960ea17b by Benjamin Peterson in branch '3.5':
merge 3.4 (#25471)
https://hg.python.org/cpython/rev/7577960ea17b

New changeset 347221cfa224 by Benjamin Peterson in branch 'default':
merge 3.5 (#25471)
https://hg.python.org/cpython/rev/347221cfa224

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25471>
_______________________________________

From report at bugs.python.org  Sat Oct 24 13:31:41 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Oct 2015 17:31:41 +0000
Subject: [issue8231] Unable to run IDLE without write-access to home directory
In-Reply-To: <1269531569.44.0.352644957859.issue8231@psf.upfronthosting.co.za>
Message-ID: <1445707901.55.0.0849067249507.issue8231@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Idle is not unique.  Several other apps ported from unix also put .xyx files in the home directory on Windows. What is unusual, if not unique, about IDLE is the need to run multiple versions. If .idlerc is moved, already released versions will not be able to access it.  I am not ready to make a break yet.  In any case, moving it to a subdirectory of $HOME will not solve this issue, which is not being able to write to $HOME, and it therefore a different issue.

----------
versions: +Python 3.5, Python 3.6 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8231>
_______________________________________

From report at bugs.python.org  Sat Oct 24 10:17:47 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Oct 2015 14:17:47 +0000
Subject: [issue21160] incorrect comments in nturl2path.py
In-Reply-To: <1396694736.78.0.949476383561.issue21160@psf.upfronthosting.co.za>
Message-ID: <1445696267.88.0.322112028668.issue21160@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka
stage:  -> commit review
type:  -> enhancement
versions: +Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21160>
_______________________________________

From report at bugs.python.org  Fri Oct 23 09:10:57 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Oct 2015 13:10:57 +0000
Subject: [issue25461] Unclear language (the word ineffective) in the
 documentation for os.walk
In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za>
Message-ID: <1445605857.97.0.46756907162.issue25461@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Usually docstrings are short and to the point, and serve more as a remainder, whereas the online docs explain everything in detail.
Also rst markup in docstrings would be distractings, so we keep docstrings and online docs separated, even though there is often some overlapping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25461>
_______________________________________

From report at bugs.python.org  Sat Oct 24 06:10:49 2015
From: report at bugs.python.org (Vilnis Termanis)
Date: Sat, 24 Oct 2015 10:10:49 +0000
Subject: [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
In-Reply-To: <1445681395.35.0.393874869917.issue25469@psf.upfronthosting.co.za>
Message-ID: <1445681449.69.0.219216163845.issue25469@psf.upfronthosting.co.za>


Changes by Vilnis Termanis <vilnis.termanis at googlemail.com>:


Added file: http://bugs.python.org/file40854/condition_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25469>
_______________________________________

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: [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  Sat Oct 24 16:08:57 2015
From: report at bugs.python.org (Ent)
Date: Sat, 24 Oct 2015 20:08:57 +0000
Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible
 usage.
In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za>
Message-ID: <1445717337.01.0.376547735173.issue23255@psf.upfronthosting.co.za>


Ent added the comment:

Hi,

Is it possible for this patch to be reviewed now?

Regards,
Ent

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23255>
_______________________________________

From report at bugs.python.org  Sat Oct 24 02:46:48 2015
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 24 Oct 2015 06:46:48 +0000
Subject: [issue25456] 3.4 _tkinter build requires undocumented manual steps to
 be usable
In-Reply-To: <1445497790.14.0.147176888356.issue25456@psf.upfronthosting.co.za>
Message-ID: <1445669208.51.0.680515916458.issue25456@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Should be fixed now, please test?  I think everything is now covered in readme.txt as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25456>
_______________________________________

From report at bugs.python.org  Fri Oct 23 13:23:25 2015
From: report at bugs.python.org (Tony R.)
Date: Fri, 23 Oct 2015 17:23:25 +0000
Subject: =?utf-8?q?=5Bissue25467=5D_Put_=E2=80=9Cdeprecated=E2=80=9D_warnings_firs?=
 =?utf-8?q?t?=
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  Sat Oct 24 03:25:31 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 24 Oct 2015 07:25:31 +0000
Subject: [issue25455] Some repr implementations don't check for
 self-referential structures
In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za>
Message-ID: <1445671531.0.0.141507906208.issue25455@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
priority: normal -> high
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25455>
_______________________________________

From report at bugs.python.org  Fri Oct 23 16:41:42 2015
From: report at bugs.python.org (Steve Dower)
Date: Fri, 23 Oct 2015 20:41:42 +0000
Subject: [issue25450] Python 3.5 starts in C:\Windows\system32 as current
 directory
In-Reply-To: <1445376716.84.0.123418793499.issue25450@psf.upfronthosting.co.za>
Message-ID: <1445632902.25.0.855175352004.issue25450@psf.upfronthosting.co.za>


Steve Dower added the comment:

Unfortunately it looks like MSI won't let you put an environment variable into the shortcut, as it has to resolve it on install (see WkDir at https://msdn.microsoft.com/en-us/library/aa371847(VS.85).aspx)

Trying some other ideas, but it looks like the most robust solution will be for IDLE to change the current directory on startup (maybe via a command line option?), or specify the initial directory in its open/save dialogs.

Otherwise, the best I can realistically promise is to set it to the Python install directory, which is not particularly useful either...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25450>
_______________________________________

From report at bugs.python.org  Sun Oct 25 15:44:15 2015
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 25 Oct 2015 19:44:15 +0000
Subject: [issue20438] inspect: Deprecate getfullargspec?
In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za>
Message-ID: <1445802255.36.0.0162671527739.issue20438@psf.upfronthosting.co.za>


Ned Batchelder added the comment:

I'm confused: the discussion here is mostly about updating docs to note deprecation.  Then at the very end, is an off-hand remark about removing getargspec.

The docs for getargspec currently read, "This function will be removed in Python 3.6."  Why?  We keep all sorts of old APIs for the sake of backward compatibility, why is this one different?

----------
nosy: +nedbat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20438>
_______________________________________

From report at bugs.python.org  Sat Oct 24 05:58:03 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Oct 2015 09:58:03 +0000
Subject: [issue9051] Improve pickle format for timezone aware datetime
 instances
In-Reply-To: <1277151308.95.0.331220838487.issue9051@psf.upfronthosting.co.za>
Message-ID: <1445680683.19.0.571494561262.issue9051@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Following patch adds tests for timezone pickling and copying. Note, that timezone.utc identity is preserved.

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file40852/timezone_test_pickle.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9051>
_______________________________________

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: [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  Sun Oct 25 00:27:31 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 25 Oct 2015 04:27:31 +0000
Subject: [issue25456] 3.4 _tkinter build requires undocumented manual steps to
 be usable
In-Reply-To: <1445497790.14.0.147176888356.issue25456@psf.upfronthosting.co.za>
Message-ID: <20151025042728.20723.20949@psf.io>


Roundup Robot added the comment:

New changeset 168569414215 by Zachary Ware in branch '3.4':
Issue #25456: Fix test_idle when Tcl/Tk DLLs are loaded from python.exe's home
https://hg.python.org/cpython/rev/168569414215

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25456>
_______________________________________

From report at bugs.python.org  Sun Oct 25 13:29:30 2015
From: report at bugs.python.org (SilentGhost)
Date: Sun, 25 Oct 2015 17:29:30 +0000
Subject: [issue25475] use argparse instead of getopt
In-Reply-To: <1445793389.31.0.201223450113.issue25475@psf.upfronthosting.co.za>
Message-ID: <1445794170.06.0.169352905314.issue25475@psf.upfronthosting.co.za>


SilentGhost added the comment:

This seems like a change for the sake of change. I think any module that requires argparse features can be moved in its own time.

----------
nosy: +SilentGhost
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25475>
_______________________________________

From report at bugs.python.org  Sun Oct 25 06:30:23 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Oct 2015 10:30:23 +0000
Subject: [issue892902] problem with pickling newstyle class instances
Message-ID: <1445769023.06.0.722055145994.issue892902@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage: test needed -> needs patch
versions:  -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue892902>
_______________________________________

From report at bugs.python.org  Fri Oct 23 06:39:32 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Oct 2015 10:39:32 +0000
Subject: [issue25461] Unclear language (the word ineffective) in the
 documentation for os.walk
In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za>
Message-ID: <20151023103929.416.97988@psf.io>


Roundup Robot added the comment:

New changeset 0286bb18a351 by Victor Stinner in branch '3.4':
Issue #25461: Rephrase os.walk() doc
https://hg.python.org/cpython/rev/0286bb18a351

New changeset 9f68e41fb4a7 by Victor Stinner in branch '3.5':
Merge 3.4 (Issue #25461)
https://hg.python.org/cpython/rev/9f68e41fb4a7

New changeset db07937b3e49 by Victor Stinner in branch 'default':
Merge 3.4 (Issue #25461)
https://hg.python.org/cpython/rev/db07937b3e49

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25461>
_______________________________________

From report at bugs.python.org  Sat Oct 24 12:47:29 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 24 Oct 2015 16:47:29 +0000
Subject: [issue18010] pydoc search chokes on import errors
In-Reply-To: <1368896719.35.0.915741072389.issue18010@psf.upfronthosting.co.za>
Message-ID: <1445705249.28.0.130966635979.issue18010@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The patch looks good.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18010>
_______________________________________

From report at bugs.python.org  Fri Oct 23 12:29:15 2015
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 23 Oct 2015 16:29:15 +0000
Subject: [issue25447] TypeError invoking deepcopy on lru_cache
In-Reply-To: <1445358729.12.0.473819832569.issue25447@psf.upfronthosting.co.za>
Message-ID: <1445617755.84.0.246084117629.issue25447@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

Simple and elegant. I like it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25447>
_______________________________________

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: [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 10:44:27 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Oct 2015 14:44:27 +0000
Subject: [issue21160] incorrect comments in nturl2path.py
In-Reply-To: <1396694736.78.0.949476383561.issue21160@psf.upfronthosting.co.za>
Message-ID: <20151024144423.75245.35684@psf.io>


Roundup Robot added the comment:

New changeset 6a15845142ec by Serhiy Storchaka in branch '3.4':
Issue21160: Correct comments in nturl2path.  Patch by Jurko Gospodneti?.
https://hg.python.org/cpython/rev/6a15845142ec

New changeset acc453391c5b by Serhiy Storchaka in branch '2.7':
Issue21160: Correct comments in nturl2path.  Patch by Jurko Gospodneti?.
https://hg.python.org/cpython/rev/acc453391c5b

New changeset 67dfa5cf38c2 by Serhiy Storchaka in branch '3.5':
Issue21160: Correct comments in nturl2path.  Patch by Jurko Gospodneti?.
https://hg.python.org/cpython/rev/67dfa5cf38c2

New changeset 1216494acffe by Serhiy Storchaka in branch 'default':
Issue21160: Correct comments in nturl2path.  Patch by Jurko Gospodneti?.
https://hg.python.org/cpython/rev/1216494acffe

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21160>
_______________________________________

From report at bugs.python.org  Fri Oct 23 09:04:33 2015
From: report at bugs.python.org (=?utf-8?q?Bernt_R=C3=B8skar_Brenna?=)
Date: Fri, 23 Oct 2015 13:04:33 +0000
Subject: [issue25461] Unclear language (the word ineffective) in the
 documentation for os.walk
In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za>
Message-ID: <1445605473.94.0.865181371832.issue25461@psf.upfronthosting.co.za>


Bernt R?skar Brenna added the comment:

A question/comment:

In this case (and there are probably other cases like it) - it seems to me that the docstring (in os.py) and the docs (in os.rst) are similar enough that the docstring from the code could be included in the docs (using Sphinx's autodoc).

What is the preferred way? Is there a reason to have it the way it is? I notice the .rst docs have some formatting applied, is it considered not OK to put formatting in docstrings?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25461>
_______________________________________

From report at bugs.python.org  Fri Oct 23 23:35:44 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Oct 2015 03:35:44 +0000
Subject: [issue25450] Python 3.5 starts in C:\Windows\system32 as current
 directory
In-Reply-To: <1445376716.84.0.123418793499.issue25450@psf.upfronthosting.co.za>
Message-ID: <1445657744.81.0.36260650239.issue25450@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I see the problem: there is only one IDLE icon for all users, so you need the env var to customize for each user, which you cannot use. Staying with the python install directory, as before, should be better.  We never got any complaints about that.  But the new install locations are more problematical.

I have also thought of adding an new startup option, but it should only apply if IDLE is started with the ICON.  When started at the command line, it should start at the current directory of the console, as it does now, so '.' refers to that directory.  Ironically, a current directory of .../system32 would be a good indicator.  I need to see what is in sys.argv after the different start methods.

This issue is currently only for Windows. I don't know what happens on other systems or whether they could stand improvement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25450>
_______________________________________

From report at bugs.python.org  Fri Oct 23 07:52:38 2015
From: report at bugs.python.org (Marcin Szewczyk)
Date: Fri, 23 Oct 2015 11:52:38 +0000
Subject: [issue4963] mimetypes.guess_extension result changes after
 mimetypes.init()
In-Reply-To: <1232107494.83.0.0570958889295.issue4963@psf.upfronthosting.co.za>
Message-ID: <1445601158.42.0.71147725014.issue4963@psf.upfronthosting.co.za>


Changes by Marcin Szewczyk <wodny1 at gmail.com>:


----------
nosy: +wodny

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4963>
_______________________________________

From report at bugs.python.org  Fri Oct 23 12:34:25 2015
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 23 Oct 2015 16:34:25 +0000
Subject: [issue25447] TypeError invoking deepcopy on lru_cache
In-Reply-To: <1445358729.12.0.473819832569.issue25447@psf.upfronthosting.co.za>
Message-ID: <1445618065.62.0.464990341887.issue25447@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

Can you speak to why 'update_wrapper' should be removed? Is that indicative of a deeper issue with update_wrapper also not supporting pickle/deepcopy?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25447>
_______________________________________

From report at bugs.python.org  Fri Oct 23 06:42:55 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Oct 2015 10:42:55 +0000
Subject: [issue25461] Unclear language (the word ineffective) in the
 documentation for os.walk
In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za>
Message-ID: <20151023104252.27532.13647@psf.io>


Roundup Robot added the comment:

New changeset 8247dff49113 by Victor Stinner in branch '2.7':
Issue #25461: Rephrase os.walk() doc
https://hg.python.org/cpython/rev/8247dff49113

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25461>
_______________________________________

From report at bugs.python.org  Fri Oct 23 06:12:14 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Oct 2015 10:12:14 +0000
Subject: [issue25465] Pickle uses O(n) memory overhead
In-Reply-To: <1445593043.5.0.334623277706.issue25465@psf.upfronthosting.co.za>
Message-ID: <1445595134.39.0.414765557068.issue25465@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

That is because a pickler keeps track of all pickled objects. This is needed to preserve identity and support recursive objects.

You can disable memoizing by setting the "fast" attribute of the Pickler object.

def fastdump(obj, file):
    p = pickle.Pickler(file)
    p.fast = True
    p.dump(obj)

But you can't pickle recursive objects in the "fast" mode.

----------
nosy: +alexandre.vassalotti, pitrou, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25465>
_______________________________________

From report at bugs.python.org  Sun Oct 25 12:55:42 2015
From: report at bugs.python.org (Evgeny Kapun)
Date: Sun, 25 Oct 2015 16:55:42 +0000
Subject: [issue25454] operator.methodcaller should accept additional arguments
 during the call
In-Reply-To: <1445453619.22.0.222588930326.issue25454@psf.upfronthosting.co.za>
Message-ID: <1445792142.26.0.767319041021.issue25454@psf.upfronthosting.co.za>


Evgeny Kapun added the comment:

There are methods that accept a single argument and behave like a binary operation or a predicate. It would be useful to be able to turn them into binary functions for use with higher-order functions like map and reduce:

    reduce(methodcaller("combine"), objs) # reduce a sequence using "combine" method
    map(methodcaller("combine"), alist, blist) # combine pairs of elements
    all(map(methodcaller("compatible_with"), alist, blist)) # check that pairs of elements are compatible

This functionality is already available for overloaded operators, because operator module provides them as functions. Some methods behave similarly to operators, so I think that a similar functionality should be available for them as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25454>
_______________________________________

From report at bugs.python.org  Sun Oct 25 17:13:47 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 25 Oct 2015 21:13:47 +0000
Subject: [issue20438] inspect: Deprecate getfullargspec?
In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za>
Message-ID: <1445807627.63.0.765621770532.issue20438@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> The docs for getargspec currently read, "This function will be removed in Python 3.6."  Why?  We keep all sorts of old APIs for the sake of backward compatibility, why is this one different?

getargspec was deprecated since 3.0.  Besides that, it returns incomplete information about function parameters: keyword-only parameters won't be introspected at all for instance.

Migration path is very simple and clear -- just use getfullargspec (almost 100% backwards compatible), which won't be removed probably till Python 4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20438>
_______________________________________

From report at bugs.python.org  Sat Oct 24 11:59:47 2015
From: report at bugs.python.org (Michael)
Date: Sat, 24 Oct 2015 15:59:47 +0000
Subject: [issue17214] http.client.HTTPConnection.putrequest encode  error
In-Reply-To: <1361011959.8.0.221376430084.issue17214@psf.upfronthosting.co.za>
Message-ID: <1445702387.54.0.766793822783.issue17214@psf.upfronthosting.co.za>


Michael added the comment:

The patch issue17214 did fix this issue in my 3.4.2 install on Ubuntu LTS.

It triggered however another bug:

  File "/usr/local/lib/python3.4/urllib/request.py", line 646, in http_error_302
    path = urlparts.path if urlpaths.path else "/"
NameError: name 'urlpaths' is not defined

This is obviously a typo. 

I'm not sure if that one has been reported yet (a short google search didn't find anything) and I don't know how to provoke it independently.

----------
nosy: +Strecke
versions:  -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17214>
_______________________________________

From report at bugs.python.org  Fri Oct 23 09:07:45 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Oct 2015 13:07:45 +0000
Subject: [issue25461] Unclear language (the word ineffective) in the
 documentation for os.walk
In-Reply-To: <1445605473.94.0.865181371832.issue25461@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaBMxOVBfYifnbXEn-qhx2GE9zFRqRf780Rz6iATX+gHA@mail.gmail.com>


STINNER Victor added the comment:

We don't use autodoc. It would be "nice" to have a tool to update .rst
files from .py and .c files, but it's not the case right now :-/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25461>
_______________________________________

From report at bugs.python.org  Fri Oct 23 08:30:33 2015
From: report at bugs.python.org (=?utf-8?q?Bernt_R=C3=B8skar_Brenna?=)
Date: Fri, 23 Oct 2015 12:30:33 +0000
Subject: [issue25461] Unclear language (the word ineffective) in the
 documentation for os.walk
In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za>
Message-ID: <1445603433.26.0.359176310193.issue25461@psf.upfronthosting.co.za>


Bernt R?skar Brenna added the comment:

Yet another patch, this time including changes to os.walk()'s docstring as well.

Ignore the two other files.

----------
Added file: http://bugs.python.org/file40849/os_walk_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25461>
_______________________________________

From report at bugs.python.org  Sun Oct 25 13:39:26 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 25 Oct 2015 17:39:26 +0000
Subject: [issue25475] use argparse instead of getopt
In-Reply-To: <1445793389.31.0.201223450113.issue25475@psf.upfronthosting.co.za>
Message-ID: <1445794766.39.0.187864135405.issue25475@psf.upfronthosting.co.za>


St?phane Wirtel added the comment:

and optparse.

In fact, we have getopt, optparse and argparse. 3 API for the command line.

optparse is marked as deprecated.
maybe we can add getopt in this list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25475>
_______________________________________

From report at bugs.python.org  Sat Oct 24 13:09:30 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Oct 2015 17:09:30 +0000
Subject: [issue18010] pydoc search chokes on import errors
In-Reply-To: <1368896719.35.0.915741072389.issue18010@psf.upfronthosting.co.za>
Message-ID: <1445706570.8.0.0463820195031.issue18010@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Would be nice to have a test.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18010>
_______________________________________

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: [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  Fri Oct 23 12:02:27 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Oct 2015 16:02:27 +0000
Subject: [issue25154] Drop the pyvenv script
In-Reply-To: <1442514921.37.0.255858283829.issue25154@psf.upfronthosting.co.za>
Message-ID: <1445616147.44.0.25823149164.issue25154@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixing a typo is trivial.  If the typo affects several version the changeset needs to be merged on all the applicable branches before being pushed.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25154>
_______________________________________

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: [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: [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  Fri Oct 23 09:15:30 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Oct 2015 13:15:30 +0000
Subject: [issue25461] Unclear language (the word ineffective) in the
 documentation for os.walk
In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za>
Message-ID: <1445606130.63.0.681872236662.issue25461@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"Also rst markup in docstrings would be distractings, so we keep docstrings and online docs separated, even though there is often some overlapping."

Ah yes, and the doc in Doc/ directory contains more information like ".. versionchanged:: (...)", ".. versionadded:: (...)", links to other doc using reST markups, etc.

In general, the doc in Doc/ is higher quality than docstrings ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25461>
_______________________________________

From report at bugs.python.org  Sat Oct 24 13:51:54 2015
From: report at bugs.python.org (Keith Teal)
Date: Sat, 24 Oct 2015 17:51:54 +0000
Subject: [issue8231] Unable to run IDLE without write-access to home directory
In-Reply-To: <1269531569.44.0.352644957859.issue8231@psf.upfronthosting.co.za>
Message-ID: <1445709114.88.0.649866008662.issue8231@psf.upfronthosting.co.za>


Keith Teal added the comment:

Hi Terry,

I did not just make that stuff up on my last post, that is actually the standard for Windows applications. Yes, many Linux ports get it wrong but is that any reason to ever perpetuate a bad practice?

To see the standards you can download the Windows SDK but to make things easier for you here is a link that talks about this: http://blogs.msdn.com/b/patricka/archive/2010/03/18/where-should-i-store-my-data-and-configuration-files-if-i-target-multiple-os-versions.aspx

By using non-standard conventions the application is just asking for trouble like what is being manifested with this issue. Users will be able to write to their %APPDATA% area, no administrator would lock that down as it would cause too many applications to fail (Kiosk type installations not included).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8231>
_______________________________________

From report at bugs.python.org  Sat Oct 24 15:01:53 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 24 Oct 2015 19:01:53 +0000
Subject: [issue17214] http.client.HTTPConnection.putrequest encode  error
In-Reply-To: <1361011959.8.0.221376430084.issue17214@psf.upfronthosting.co.za>
Message-ID: <1445713313.35.0.958614253288.issue17214@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17214>
_______________________________________

From report at bugs.python.org  Sat Oct 24 10:58:26 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Oct 2015 14:58:26 +0000
Subject: [issue1749512] imaplib cannot handle mailboxes with ACL: lrs
Message-ID: <1445698706.75.0.800633665287.issue1749512@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1749512>
_______________________________________

From report at bugs.python.org  Sat Oct 24 05:52:01 2015
From: report at bugs.python.org (eryksun)
Date: Sat, 24 Oct 2015 09:52:01 +0000
Subject: [issue25450] Python 3.5 starts in C:\Windows\system32 as current
 directory
In-Reply-To: <1445376716.84.0.123418793499.issue25450@psf.upfronthosting.co.za>
Message-ID: <1445680321.74.0.747812773007.issue25450@psf.upfronthosting.co.za>


eryksun added the comment:

Steve, I think you're right that it's simpler and more reliable to add a command-line option that sets IDLE's working directory to the current user's home directory. 

Terry, the default behavior in Linux, at least in Ubuntu, is to start IDLE with the working directory set to the user's home directory. 

The Linux equivalent of a Windows .lnk shortcut is an XDG .desktop file [1]. A desktop application entry sets the working directory using the "Path" key, such as Path=/absolute/path (or also, and maybe only in Ubuntu Unity, Path=relative/path) in the main "Desktop Entry" or in a "Desktop Action" (i.e. right-click menu action). Environment variables are not supported. 

If "Path" isn't defined, I can only say from experience what Ubuntu's Unity shell does, since the spec doesn't define a default behavior. In this case, the child process inherits Unity's working directory. Since it's a plugin for the Compiz window manager, the child inherits the working directory of Compiz. This is the current user's $HOME directory, which Compiz inherits indirectly from the user-mode init process. I confirmed the behavior by attaching gdb to compiz and executing `call chdir("/home")`, and then continued compiz and opened IDLE to verify that the working directory was inherited as "/home". 

[1]: http://standards.freedesktop.org/desktop-entry-spec/latest

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25450>
_______________________________________

From report at bugs.python.org  Sun Oct 25 03:52:19 2015
From: report at bugs.python.org (Michiel de Hoon)
Date: Sun, 25 Oct 2015 07:52:19 +0000
Subject: [issue23237] Interrupts are lost during readline PyOS_InputHook
 processing (reopening)
In-Reply-To: <1421201583.23.0.507661432161.issue23237@psf.upfronthosting.co.za>
Message-ID: <1445759539.35.0.990114444637.issue23237@psf.upfronthosting.co.za>


Michiel de Hoon added the comment:

Anything I can do to help this patch move forward?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23237>
_______________________________________

From report at bugs.python.org  Fri Oct 23 12:50:39 2015
From: report at bugs.python.org (Nan Wu)
Date: Fri, 23 Oct 2015 16:50:39 +0000
Subject: [issue25439] Add type checks to urllib.request.Request
In-Reply-To: <1445247083.91.0.927080887762.issue25439@psf.upfronthosting.co.za>
Message-ID: <1445619039.48.0.899345453084.issue25439@psf.upfronthosting.co.za>


Changes by Nan Wu <nanbytesflow at gmail.com>:


Added file: http://bugs.python.org/file40850/urllib_request_param_type_check_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25439>
_______________________________________

From report at bugs.python.org  Sat Oct 24 17:21:38 2015
From: report at bugs.python.org (Ivan Pozdeev)
Date: Sat, 24 Oct 2015 21:21:38 +0000
Subject: [issue24747] ctypes silently truncates ints larger than C int
In-Reply-To: <1438171886.06.0.632497745661.issue24747@psf.upfronthosting.co.za>
Message-ID: <1445721698.72.0.0142372177536.issue24747@psf.upfronthosting.co.za>


Ivan Pozdeev added the comment:

I wouldn't call it so carved in stone:

1) The note at `ctypes.c_int' (https://docs.python.org/2/library/ctypes.html?highlight=c_int#ctypes.c_int) is meant for explicit conversion - since the entry is about using `c_int' is Python code, not converting something to `int' anywhere in Python's codebase. (thus, eryksun's statement is but a liberal interpretation)

2) 15.17.1.3. (https://docs.python.org/2/library/ctypes.html?highlight=c_int#calling-functions) is a tutorial, rather than reference, section, and as such, is not an authoritative source. And the corresponding reference section, 15.17.2.3. (https://docs.python.org/2/library/ctypes.html?highlight=c_int#foreign-functions) has nothing of the kind.
Basically, when seen in a non-normative text, such a piece of information is interpreted as a "taking into a secret": "this is what happens behind the scenes - so you better understand it - but don't rely on this too much".

Anyway, to produce convincing evidence to change anything, one probably needs to dig up the rationale for the current behaviour and see what adheres to it / if it still stands.

Sure, this violates Python Zen (koans 2 and 12), yet we probably need something better that this to convince core devs that this is a _bug_.

----------
nosy: +Ivan.Pozdeev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24747>
_______________________________________

From report at bugs.python.org  Sat Oct 24 19:10:41 2015
From: report at bugs.python.org (Alexey Gorshkov)
Date: Sat, 24 Oct 2015 23:10:41 +0000
Subject: [issue25471] socket.recv() blocks while it's gettimeout() returns 0.0
In-Reply-To: <1445727809.94.0.696138695468.issue25471@psf.upfronthosting.co.za>
Message-ID: <1445728241.39.0.311164451067.issue25471@psf.upfronthosting.co.za>


Alexey Gorshkov added the comment:

telnet 127.0.0.1 9000 can be used as testing client

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25471>
_______________________________________

From report at bugs.python.org  Fri Oct 23 09:18:16 2015
From: report at bugs.python.org (Joshua Landau)
Date: Fri, 23 Oct 2015 13:18:16 +0000
Subject: [issue21593] Clarify re.search documentation first match
In-Reply-To: <1401287966.38.0.860641123785.issue21593@psf.upfronthosting.co.za>
Message-ID: <1445606296.98.0.184121891411.issue21593@psf.upfronthosting.co.za>


Changes by Joshua Landau <joshua.landau.ws at gmail.com>:


----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21593>
_______________________________________

From report at bugs.python.org  Sat Oct 24 10:59:22 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Oct 2015 14:59:22 +0000
Subject: [issue1749512] imaplib cannot handle mailboxes with ACL: lrs
Message-ID: <1445698762.63.0.162084653584.issue1749512@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
components: +email
nosy: +barry, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1749512>
_______________________________________

From report at bugs.python.org  Sat Oct 24 12:08:30 2015
From: report at bugs.python.org (Michael)
Date: Sat, 24 Oct 2015 16:08:30 +0000
Subject: [issue17214] http.client.HTTPConnection.putrequest encode  error
In-Reply-To: <1361011959.8.0.221376430084.issue17214@psf.upfronthosting.co.za>
Message-ID: <1445702910.43.0.75995495179.issue17214@psf.upfronthosting.co.za>


Michael added the comment:

I should have looked more closely. 

The typo is part of the patch. It should be corrected there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17214>
_______________________________________

From report at bugs.python.org  Sun Oct 25 17:28:19 2015
From: report at bugs.python.org (David Beazley)
Date: Sun, 25 Oct 2015 21:28:19 +0000
Subject: [issue7322] Socket timeout can cause file-like readline() method to
 lose data
In-Reply-To: <1258218993.08.0.764402701678.issue7322@psf.upfronthosting.co.za>
Message-ID: <1445808499.92.0.891528697345.issue7322@psf.upfronthosting.co.za>


David Beazley added the comment:

This bug is still present in Python 3.5, but it occurs if you attempt to do a readline() on a socket that's in non-blocking mode.  In that case, you probably DO want to retry at a later time (unlike the timeout case).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Sat Oct 24 19:14:30 2015
From: report at bugs.python.org (Alexey Gorshkov)
Date: Sat, 24 Oct 2015 23:14:30 +0000
Subject: [issue25471] socket.recv() blocks while it's gettimeout() returns 0.0
In-Reply-To: <1445727809.94.0.696138695468.issue25471@psf.upfronthosting.co.za>
Message-ID: <1445728470.95.0.545444299197.issue25471@psf.upfronthosting.co.za>


Changes by Alexey Gorshkov <animus at wayround.org>:


Removed 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  Sat Oct 24 23:53:30 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 25 Oct 2015 03:53:30 +0000
Subject: [issue25454] operator.methodcaller should accept additional arguments
 during the call
In-Reply-To: <1445453619.22.0.222588930326.issue25454@psf.upfronthosting.co.za>
Message-ID: <1445745210.19.0.408097023451.issue25454@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This would be easier to evaluate propertly if you supplied some meaningful use cases.  Otherwise, it is looks like hypergeneralizing.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25454>
_______________________________________

From report at bugs.python.org  Sat Oct 24 02:55:08 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Oct 2015 06:55:08 +0000
Subject: [issue25447] TypeError invoking deepcopy on lru_cache
In-Reply-To: <1445358729.12.0.473819832569.issue25447@psf.upfronthosting.co.za>
Message-ID: <1445669708.2.0.1214093483.issue25447@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your report and review Jason.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25447>
_______________________________________

From report at bugs.python.org  Sat Oct 24 08:44:29 2015
From: report at bugs.python.org (Keith Teal)
Date: Sat, 24 Oct 2015 12:44:29 +0000
Subject: [issue8231] Unable to run IDLE without write-access to home directory
In-Reply-To: <1269531569.44.0.352644957859.issue8231@psf.upfronthosting.co.za>
Message-ID: <1445690669.5.0.203082805251.issue8231@psf.upfronthosting.co.za>


Keith Teal added the comment:

I would also like to add that the location of this directory is not correct for Windows software. This directory should be created in %APPDATA% where users by default do have write permissions.

If there are plans to ever make this application portable then it should support a command line option to specify the location of the configuration as well.

----------
nosy: +tealduck

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8231>
_______________________________________

From report at bugs.python.org  Sat Oct 24 19:14:47 2015
From: report at bugs.python.org (Alexey Gorshkov)
Date: Sat, 24 Oct 2015 23:14:47 +0000
Subject: [issue25471] socket.recv() blocks while it's gettimeout() returns 0.0
In-Reply-To: <1445727809.94.0.696138695468.issue25471@psf.upfronthosting.co.za>
Message-ID: <1445728487.19.0.999474506518.issue25471@psf.upfronthosting.co.za>


Changes by Alexey Gorshkov <animus at wayround.org>:


Added file: http://bugs.python.org/file40856/s1.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25471>
_______________________________________

From report at bugs.python.org  Fri Oct 23 16:24:22 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Oct 2015 20:24:22 +0000
Subject: [issue24633] README file installed into site-packages conflicts with
 package named "readme"
In-Reply-To: <1436861246.12.0.158910992978.issue24633@psf.upfronthosting.co.za>
Message-ID: <20151023202419.400.92547@psf.io>


Roundup Robot added the comment:

New changeset 742aefb5ca46 by Steve Dower in branch 'default':
Issue #24633: Removes automatic rename of site-packages/README since README.txt is now committed.
https://hg.python.org/cpython/rev/742aefb5ca46

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24633>
_______________________________________

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: [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 02:52:53 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Oct 2015 06:52:53 +0000
Subject: [issue25447] TypeError invoking deepcopy on lru_cache
In-Reply-To: <1445358729.12.0.473819832569.issue25447@psf.upfronthosting.co.za>
Message-ID: <20151024065250.17795.74668@psf.io>


Roundup Robot added the comment:

New changeset 73226f0d0f89 by Serhiy Storchaka in branch '3.5':
Issue #25447: The lru_cache() wrapper objects now can be copied and pickled
https://hg.python.org/cpython/rev/73226f0d0f89

New changeset d3e048c7b65a by Serhiy Storchaka in branch 'default':
Issue #25447: The lru_cache() wrapper objects now can be copied and pickled
https://hg.python.org/cpython/rev/d3e048c7b65a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25447>
_______________________________________

From report at bugs.python.org  Sat Oct 24 11:04:09 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Oct 2015 15:04:09 +0000
Subject: [issue23235] run_tests.py doesn't set test.support.verbose correctly
In-Reply-To: <1421193875.73.0.411637461646.issue23235@psf.upfronthosting.co.za>
Message-ID: <1445699049.3.0.0808130299301.issue23235@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
components: +Tests
nosy: +ezio.melotti, michael.foord, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23235>
_______________________________________

From report at bugs.python.org  Sat Oct 24 11:02:13 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Oct 2015 15:02:13 +0000
Subject: [issue22968] Lib/types.py nit: isinstance != PyType_IsSubtype
In-Reply-To: <1417293514.02.0.452977288528.issue22968@psf.upfronthosting.co.za>
Message-ID: <1445698933.31.0.518568973746.issue22968@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +yselivanov
stage:  -> patch review
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22968>
_______________________________________

From report at bugs.python.org  Sun Oct 25 01:08:42 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Oct 2015 05:08:42 +0000
Subject: [issue25472] Typing: Specialized subclasses of generics cannot be
 unpickled
In-Reply-To: <1445742573.23.0.0225018159767.issue25472@psf.upfronthosting.co.za>
Message-ID: <1445749722.52.0.228186835763.issue25472@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
components: +Library (Lib)
nosy: +alexandre.vassalotti, gvanrossum, pitrou, serhiy.storchaka
type:  -> behavior
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25472>
_______________________________________

From report at bugs.python.org  Sat Oct 24 17:00:02 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Oct 2015 21:00:02 +0000
Subject: [issue17864] IDLE won't run
In-Reply-To: <1367173337.57.0.3678200637.issue17864@psf.upfronthosting.co.za>
Message-ID: <1445720402.24.0.373343751701.issue17864@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
superseder:  -> Unable to run IDLE without write-access to home directory

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17864>
_______________________________________

From report at bugs.python.org  Sun Oct 25 15:10:56 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 25 Oct 2015 19:10:56 +0000
Subject: [issue25475] use argparse instead of getopt
In-Reply-To: <1445793389.31.0.201223450113.issue25475@psf.upfronthosting.co.za>
Message-ID: <1445800256.83.0.0640127719746.issue25475@psf.upfronthosting.co.za>


R. David Murray added the comment:

This was discussed when argparse was included in the standard library, and the conclusion was that getopt serves a different purpose than argparse and should not be deprecated.  argparse is mentioned as an alternative since in many cases it is to be preferred, but there are cases where getopt is the better choice.  (I myself have a command line parsing library (not yet published) that uses getopt as its base.)

As far as using argparse in the standard library, yes, we convert modules on a case by case basis when someone has the interest and the time to write tests for the existing command line behavior before doing the conversion.  And in every case we have still introduced bugs when the conversion was released, so this should not be done lightly (ie: we usually only do it when introducing new functionality or fixing a bug).

----------
nosy: +r.david.murray
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25475>
_______________________________________

From report at bugs.python.org  Sat Oct 24 15:47:46 2015
From: report at bugs.python.org (George Jenkins)
Date: Sat, 24 Oct 2015 19:47:46 +0000
Subject: [issue1182143] making builtin exceptions more informative
Message-ID: <1445716066.45.0.620619985951.issue1182143@psf.upfronthosting.co.za>


George Jenkins added the comment:

Bump on this one please

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1182143>
_______________________________________

From report at bugs.python.org  Sat Oct 24 02:36:40 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Oct 2015 06:36:40 +0000
Subject: [issue25456] 3.4 _tkinter build requires undocumented manual steps to
 be usable
In-Reply-To: <1445497790.14.0.147176888356.issue25456@psf.upfronthosting.co.za>
Message-ID: <20151024063636.20725.42507@psf.io>


Roundup Robot added the comment:

New changeset b5889dbbc382 by Zachary Ware in branch '3.4':
Closes #25456: Copy Tcl/Tk DLLs to build directory on Windows
https://hg.python.org/cpython/rev/b5889dbbc382

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25456>
_______________________________________

From report at bugs.python.org  Sun Oct 25 12:50:54 2015
From: report at bugs.python.org (SilentGhost)
Date: Sun, 25 Oct 2015 16:50:54 +0000
Subject: [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
In-Reply-To: <1445681395.35.0.393874869917.issue25469@psf.upfronthosting.co.za>
Message-ID: <1445791854.45.0.938409019593.issue25469@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy: +jnoller, sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25469>
_______________________________________

From report at bugs.python.org  Sun Oct 25 12:55:10 2015
From: report at bugs.python.org (SilentGhost)
Date: Sun, 25 Oct 2015 16:55:10 +0000
Subject: [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
In-Reply-To: <1445681395.35.0.393874869917.issue25469@psf.upfronthosting.co.za>
Message-ID: <1445792110.41.0.615306282917.issue25469@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
versions:  -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25469>
_______________________________________

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: [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: [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 13:37:16 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 25 Oct 2015 17:37:16 +0000
Subject: [issue25475] use argparse instead of getopt
In-Reply-To: <1445793389.31.0.201223450113.issue25475@psf.upfronthosting.co.za>
Message-ID: <1445794636.84.0.959629389418.issue25475@psf.upfronthosting.co.za>


St?phane Wirtel added the comment:

it's not for the pleasure, but there are two api for the command line. getopt and argparse. so in this case, what's the reason to keep both ? in particular if the documentation of getopt has a note with an alternative.

maybe to keep the backward compatibility, but in this case, maybe we can start to deprecate getopt in favour of argparse.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25475>
_______________________________________

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: [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  Fri Oct 23 13:01:43 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Oct 2015 17:01:43 +0000
Subject: [issue25447] TypeError invoking deepcopy on lru_cache
In-Reply-To: <1445358729.12.0.473819832569.issue25447@psf.upfronthosting.co.za>
Message-ID: <1445619703.49.0.861647179442.issue25447@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It is redundant. update_wrapper() is called just after calling _lru_cache_wrapper() in decorating_function().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25447>
_______________________________________

From report at bugs.python.org  Sun Oct 25 18:13:49 2015
From: report at bugs.python.org (augustin rieunier)
Date: Sun, 25 Oct 2015 22:13:49 +0000
Subject: [issue25470] Random Malloc error raised
In-Reply-To: <1445695572.21.0.810479855368.issue25470@psf.upfronthosting.co.za>
Message-ID: <1445811229.56.0.802653811389.issue25470@psf.upfronthosting.co.za>


Changes by augustin rieunier <augustin.rieunier at gmail.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25470>
_______________________________________

From report at bugs.python.org  Sun Oct 25 18:42:58 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 25 Oct 2015 22:42:58 +0000
Subject: [issue25193] itertools.accumulate should have an optional initializer
 argument
In-Reply-To: <1442738800.12.0.18115193144.issue25193@psf.upfronthosting.co.za>
Message-ID: <1445812978.03.0.652114911064.issue25193@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> OTOH, none of those projects is natural fit for itertools,
> so changing itertools wouldn't help them directly.

Indeed, this may not be a natural fit for itertools problems.

As a side note, the itertools were designed to form the elements of "an iterator algebra" with itertools.chain() as the intended compose-operation, so the OPs original solution was the right way to do it.  

The main question is whether the current solution is common enough to warrant being made a little more convenient (saving 9 characters), and whether the resulting code reads well:

current:  accumulate(chain([10]), range(1,4), operator.mul)
proposed: accumulate(range(1,4), operator.mul, 10) 

The latter spelling saves 9 characters; however, to my eyes, the "10" isn't obvious about what it doing and its placement is odd (the order of execution is 10, 1, 2, 3 eventhough the argument order has the range(1,4) as the first argument and the "10" as the third-argument).  I don't think the proposed spelling is doing us any favors in terms of code clarity -- the current spelling with chain() is more versatile and makes it perfectly clear that the 10 happens before the 1,2,3.

The OP made reference to functools.reduce() for comparison but we should keep in mind that reduce() was banished to functools because Guido found it to be relatively unintelligible and thought most code would be clearer without it.

As an additional data point, I did a GitHub code search.  In the first 20 pages of the search results, I found only three examples.  The first example seems reasonable.  The second example was a toy demonstration of "generator and iterator towers".  And the third example was a olympiad toy puzzle problem.

Github Code Search
------------------
https://github.com/search?p=1&q=itertools.accumulate&ref=searchresults&type=Code&utf8=%E2%9C%93


Ex1:
----
def collect(seed, iterable):
    return it.accumulate(it.chain([seed], iterable))

Ex2:
----
for number, op, fac in itertools.chain(
     zip(itertools.accumulate(itertools.chain((nr,), range(2, 10)),
     operator.mul), itertools.repeat(" * "), range(2, 10)),

Ex3:
----
if sum(loop) % 2015 == 0 and not list(filter(test,
      itertools.accumulate(itertools.chain(start, loop)))):
          print(0)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25193>
_______________________________________

From report at bugs.python.org  Sun Oct 25 19:16:29 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 25 Oct 2015 23:16:29 +0000
Subject: [issue25450] Python 3.5 starts in C:\Windows\system32 as current
 directory
In-Reply-To: <1445376716.84.0.123418793499.issue25450@psf.upfronthosting.co.za>
Message-ID: <1445814989.12.0.112589528825.issue25450@psf.upfronthosting.co.za>


Steve Dower added the comment:

We can add more options to the start menu icon, even something like "--start-in %userprofile%" should work there, as it really is just a blob of text (though I need to test that). Accepting "--start-in ~" and os.path.expanduser() would also be fine, I believe.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25450>
_______________________________________

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: [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 20:36:58 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 26 Oct 2015 00:36:58 +0000
Subject: [issue25425] white-spaces encountered in 3.4
In-Reply-To: <1445019439.47.0.233830038143.issue25425@psf.upfronthosting.co.za>
Message-ID: <1445819818.08.0.0578990178406.issue25425@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Pavan, if you want to followup, please post to python-list where you can get help explaining whatever you see as a problem.  If you get agreement there that a patch to CPython is needed, we can reopen this.

----------
nosy: +terry.reedy
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: performance -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25425>
_______________________________________

From report at bugs.python.org  Sun Oct 25 20:40:26 2015
From: report at bugs.python.org (Gian Carlo Martinelli)
Date: Mon, 26 Oct 2015 00:40:26 +0000
Subject: [issue25356] Idle (Python 3.4 on Ubuntu) does not allow typing accents
In-Reply-To: <1444404560.14.0.409888700573.issue25356@psf.upfronthosting.co.za>
Message-ID: <1445820026.03.0.415712620612.issue25356@psf.upfronthosting.co.za>


Gian Carlo Martinelli added the comment:

Any additional input on this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25356>
_______________________________________

From report at bugs.python.org  Sun Oct 25 20:40:40 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 26 Oct 2015 00:40:40 +0000
Subject: [issue25154] Drop the pyvenv script
In-Reply-To: <1442514921.37.0.255858283829.issue25154@psf.upfronthosting.co.za>
Message-ID: <20151026004037.75261.19285@psf.io>


Roundup Robot added the comment:

New changeset 7a5f8418b4ab by Brett Cannon in branch 'default':
Issue #25154: Make the file argument apply to the print function and
https://hg.python.org/cpython/rev/7a5f8418b4ab

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25154>
_______________________________________

From report at bugs.python.org  Sun Oct 25 20:41:13 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 26 Oct 2015 00:41:13 +0000
Subject: [issue25154] Drop the pyvenv script
In-Reply-To: <1442514921.37.0.255858283829.issue25154@psf.upfronthosting.co.za>
Message-ID: <1445820073.13.0.373086883146.issue25154@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Sorry for the delay on this; fell ill Friday and then had guests all weekend.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25154>
_______________________________________

From report at bugs.python.org  Sun Oct 25 20:52:31 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 26 Oct 2015 00:52:31 +0000
Subject: [issue25432] isinstance documentation: explain behavior when type is
 a tuple
In-Reply-To: <1445093164.36.0.718439234598.issue25432@psf.upfronthosting.co.za>
Message-ID: <1445820751.91.0.358306247853.issue25432@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Perhaps add after third sentence (ending with "not accepted)."), "If classinfo is a tuple, isinstance(x, classinfo) is the same as any(isinstance(x, C) for C in flatten(classinfo))".

----------
nosy: +terry.reedy
stage:  -> needs patch
title: isinstance documentation doesn't explain what happens when type is tuple -> isinstance documentation: explain behavior when type is a tuple
type:  -> enhancement
versions: +Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25432>
_______________________________________

From report at bugs.python.org  Sun Oct 25 20:57:53 2015
From: report at bugs.python.org (Alun Champion)
Date: Mon, 26 Oct 2015 00:57:53 +0000
Subject: [issue25193] itertools.accumulate should have an optional initializer
 argument
In-Reply-To: <1442738800.12.0.18115193144.issue25193@psf.upfronthosting.co.za>
Message-ID: <1445821073.75.0.823800454224.issue25193@psf.upfronthosting.co.za>


Alun Champion added the comment:

If you are looking for other examples.
Here's a wheel factorization of an indefinite sieve (primes) that was peer reviewed on codereview.stackexchange.com, see the final result in the last post by Will Ness: http://codereview.stackexchange.com/questions/92365/wheel-based-unbounded-sieve-of-eratosthenes-in-python which included two uses of accumulate(chain(...), ...).

Constructing and unpacking the list in a chain seems like an unnecessary overhead when all you are looking for is an initial value. The reason I suggested it as the 3rd argument is it is the "most" optional argument and mirrors reduce (though iterable, function is the reverse of reduce).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25193>
_______________________________________

From report at bugs.python.org  Sun Oct 25 21:35:50 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 26 Oct 2015 01:35:50 +0000
Subject: [issue25444] Py Launch Icon
In-Reply-To: <1445315488.63.0.0387362218843.issue25444@psf.upfronthosting.co.za>
Message-ID: <1445823350.16.0.140884057561.issue25444@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Rockets are also used to launch communication satellites and scientific research missions.

On Windows, the IDLE icon has the double snake on a white page, while the python icon is the snakes on a dark console window.  They are already well differentiated.

However, the blue and yellow colors of the 16-bit version get darkened when placed in the top title bar of windows, and the snake shape a bit distorted. (idlelib/icons contains icons for both Windows and *nix.) They are even worse on Win10, so I have been thinking about redoing it. I might use your IDLE version to help with a redesign.

If you want the .exe icon changed, try to get support on python-list or python-ideas lists.

----------
nosy: +terry.reedy
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25444>
_______________________________________

From report at bugs.python.org  Sun Oct 25 21:37:26 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 26 Oct 2015 01:37:26 +0000
Subject: [issue25451] tkinter: PhotoImage transparency methods
In-Reply-To: <1445417795.5.0.279905447074.issue25451@psf.upfronthosting.co.za>
Message-ID: <1445823446.73.0.531828019789.issue25451@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +serhiy.storchaka, terry.reedy
stage:  -> needs patch
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25451>
_______________________________________

From report at bugs.python.org  Sun Oct 25 21:53:08 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 26 Oct 2015 01:53:08 +0000
Subject: [issue25473] socket.recv() raises correct code with the misleading
 description 'BlockingIOError: [Errno 11] Resource temporarily unavailable'
In-Reply-To: <1445773075.06.0.853655440523.issue25473@psf.upfronthosting.co.za>
Message-ID: <1445824388.06.0.801109575053.issue25473@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

This is simply the way glibc defines the error messages.

% python3
Python 3.4.3 (default, Sep 27 2015, 15:15:25) 
[GCC 4.8.5] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import errno, os
>>> errno.EAGAIN, errno.EWOULDBLOCK
(11, 11)
>>> os.strerror(errno.EAGAIN)
'Resource temporarily unavailable'

----------
nosy: +benjamin.peterson
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25473>
_______________________________________

From report at bugs.python.org  Sun Oct 25 22:06:57 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 26 Oct 2015 02:06:57 +0000
Subject: [issue25356] Idle (Python 3.4 on Ubuntu) does not allow typing accents
In-Reply-To: <1444404560.14.0.409888700573.issue25356@psf.upfronthosting.co.za>
Message-ID: <1445825217.93.0.546061851834.issue25356@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I am out of ideas.  You might ask on python-list (accessible as newsgroup mirror on news.gmane.org) whether any other Ubunto users have the problem or have heard of it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25356>
_______________________________________

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: [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 22:02:50 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 26 Oct 2015 02:02:50 +0000
Subject: [issue25466] offer "from __future__ import" option for "raise... from"
In-Reply-To: <1445613687.79.0.0523081768685.issue25466@psf.upfronthosting.co.za>
Message-ID: <1445824970.51.0.78112261989.issue25466@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Except for *very* carefully considered security features for 2.7, we do not add new features to python x.y after initial release.  The 2.7 security exception required a PEP, and I believe the PEP was limited to features specified in the PEP.

I would expect porting guides (or 2 & 3 guides) to cover this issue.

Features added in 3.0 were considered for backporting to 2.7, which came out 18 months later.  This one did not make the cut.

----------
nosy: +terry.reedy
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25466>
_______________________________________

From report at bugs.python.org  Sun Oct 25 22:29:05 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 26 Oct 2015 02:29:05 +0000
Subject: [issue25478] Consider adding a normalize() method to
 collections.Counter()
In-Reply-To: <1445826280.05.0.307309053044.issue25478@psf.upfronthosting.co.za>
Message-ID: <1445826545.22.0.535720052701.issue25478@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
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: [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  Sun Oct 25 23:44:08 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 26 Oct 2015 03:44:08 +0000
Subject: [issue25193] itertools.accumulate should have an optional initializer
 argument
In-Reply-To: <1442738800.12.0.18115193144.issue25193@psf.upfronthosting.co.za>
Message-ID: <1445831048.07.0.180764305132.issue25193@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

To me prime sieve demos and puzzle problems aren't motivating use cases.  Also, the two examples in the single stack-exchange answer become awkward because they would also need a middle argument for the accumulation function:

Current:
  cs = accumulate(chain([11], cycle(wh11)))
  wheel = accumulate(chain([psq+x[i]], cycle(x[i+1:] + x[:i+1])))

Proposed:
  cs = accumulate(cycle(wh11), operator.add, 11)
  wheel = accumulate(cycle(x[i+1:] + x[:i+1]), operator.add, psq+x[i])

IMO both of the newer ones are wordier, don't read well, and are slower.  

After more thought, I've decided to stick with the original decision and decline the feature request.  There are other major languages that seem to do fine without the feature, the current approach works fine, my search for possible use cases shows that they are uncommon or contrived, and looking at the revised examples I just don't think that the newer code reads well.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25193>
_______________________________________

From report at bugs.python.org  Mon Oct 26 03:29:05 2015
From: report at bugs.python.org (Nils Lindemann)
Date: Mon, 26 Oct 2015 07:29:05 +0000
Subject: [issue25444] Py Launch Icon
In-Reply-To: <1445315488.63.0.0387362218843.issue25444@psf.upfronthosting.co.za>
Message-ID: <1445844545.43.0.950470260535.issue25444@psf.upfronthosting.co.za>


Nils Lindemann added the comment:

it seems i have still not explained my issue in an understandable way: the three first icons in the file list in the screenshot, aka the icons which are used in eg py 3.2, these icons are cool.

the icon i do not like, is the launcher icon which is used in eg py 3.5 and which shows up in the windows task bar when i run python scripts which open a commandline. This is the last icon in the file list in the screenshot.

Im fine with everything else, i always liked the original icons, just the new launcher icon is terrible in my opinion :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25444>
_______________________________________

From report at bugs.python.org  Mon Oct 26 03:46:54 2015
From: report at bugs.python.org (eryksun)
Date: Mon, 26 Oct 2015 07:46:54 +0000
Subject: [issue25476] close() behavior on non-blocking BufferedIO objects with
 sockets
In-Reply-To: <1445809592.17.0.674825265911.issue25476@psf.upfronthosting.co.za>
Message-ID: <1445845614.43.0.402121818942.issue25476@psf.upfronthosting.co.za>


eryksun added the comment:

Per issue 16597, when an exception occurs in flush(), the file is closed anyway. You'd have to check the exception and only skip to the end for EWOULDBLOCK or EAGAIN. That way you're not introducing a regression for ENOSPC and other exceptions for which retrying will just repeatedly fail. 

I'm adding 2.7 to keep the io module consistent; however, socket.makefile in 2.7 doesn't use the io module.

----------
nosy: +eryksun
versions: +Python 2.7, Python 3.4, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25476>
_______________________________________

From report at bugs.python.org  Mon Oct 26 03:49:03 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 26 Oct 2015 07:49:03 +0000
Subject: [issue25154] Drop the pyvenv script
In-Reply-To: <1442514921.37.0.255858283829.issue25154@psf.upfronthosting.co.za>
Message-ID: <1445845743.92.0.58032599569.issue25154@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

There's a typo here in 'executable':

+          '`{} -m venv`'.format(exeutable), file=sys.stderr)

And this could now be:
    print('WARNING: the pyenv script is deprecated in favour of '
          f'`{executable} -m venv`', file=sys.stderr)

!

And since there is no .format() call, you can't accidentally pass it file=.

----------
nosy: +eric.smith
Added file: http://bugs.python.org/file40861/issue25154-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25154>
_______________________________________

From report at bugs.python.org  Mon Oct 26 04:08:32 2015
From: report at bugs.python.org (Florin Papa)
Date: Mon, 26 Oct 2015 08:08:32 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1445846912.09.0.255403178478.issue25300@psf.upfronthosting.co.za>


Florin Papa added the comment:

Hi all,

I updated the patch after fixing crashes that occurred at compile and run time on Ubuntu 15.10, with kernel version 4.2.0-16-generic, LD version 2.25.1 and GCC version 5.2.1. The Python MPX binary will be built with ?O0 because other optimization levels will change instruction order and cause crashes, making it useful for debugging purposes. The minimum GCC version was upgraded to 5.2 for the MPX build in order to make sure there is full support for this feature.

All tests from regrtest pass, except pest_pyclbr which also fails on a non-MPX build and two other tests, test_capi and test_faulthandler, which fail because the output expected after a segmentation fault is generated is modified by MPX (which reacts to a memory violation).

The built MPX Python binary was evaluated (?./python -m test.regrtest?) on two older Intel generation processors, Haswell and Broadwell, and no functional issue was observed.  However, we don?t know its impact on third-party extensions.

Thank you,
Florin

----------
Added file: http://bugs.python.org/file40862/mpx_enable_3_6_v5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25300>
_______________________________________

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: [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:33:13 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 26 Oct 2015 08:33:13 +0000
Subject: [issue25480] string format in large number
In-Reply-To: <1445847262.11.0.792420097545.issue25480@psf.upfronthosting.co.za>
Message-ID: <1445848393.25.0.90027140568.issue25480@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

You should read: https://docs.python.org/3/tutorial/floatingpoint.html

----------
components:  -Build
nosy: +eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25480>
_______________________________________

From report at bugs.python.org  Mon Oct 26 04:38:11 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 26 Oct 2015 08:38:11 +0000
Subject: [issue25311] Add f-string support to tokenize.py
In-Reply-To: <1443979407.62.0.707305717475.issue25311@psf.upfronthosting.co.za>
Message-ID: <20151026083808.75245.58890@psf.io>


Roundup Robot added the comment:

New changeset 21f6c4378846 by Eric V. Smith in branch 'default':
Issue 25311: Add support for f-strings to tokenize.py. Also added some comments to explain what's happening, since it's not so obvious.
https://hg.python.org/cpython/rev/21f6c4378846

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25311>
_______________________________________

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: [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 04:44:04 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 26 Oct 2015 08:44:04 +0000
Subject: [issue25311] Add f-string support to tokenize.py
In-Reply-To: <1443979407.62.0.707305717475.issue25311@psf.upfronthosting.co.za>
Message-ID: <1445849044.13.0.580831900384.issue25311@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I've fixed this particular problem, but the tokenize module definitely has some other issues. It recompiles regexes very often when it doesn't need to, it treats single- and triple-quoted strings differently (leading to some code bloat), etc. I may open another issue to address some of these problems.

And I'll be adding more tests. tokenize is still woefully under-tested.

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25311>
_______________________________________

From report at bugs.python.org  Mon Oct 26 04:44:45 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 26 Oct 2015 08:44:45 +0000
Subject: [issue25311] Add f-string support to tokenize.py
In-Reply-To: <1443979407.62.0.707305717475.issue25311@psf.upfronthosting.co.za>
Message-ID: <1445849085.26.0.295677050936.issue25311@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
keywords:  -patch
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25311>
_______________________________________

From report at bugs.python.org  Mon Oct 26 04:48:20 2015
From: report at bugs.python.org (David Beazley)
Date: Mon, 26 Oct 2015 08:48:20 +0000
Subject: [issue25476] close() behavior on non-blocking BufferedIO objects with
 sockets
In-Reply-To: <1445809592.17.0.674825265911.issue25476@psf.upfronthosting.co.za>
Message-ID: <1445849300.87.0.518006131027.issue25476@psf.upfronthosting.co.za>


David Beazley added the comment:

Please don't make flush() close the file on a BlockingIOError.   That would be an unfortunate mistake and make it impossible to implement non-blocking I/O correctly with buffered I/O.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25476>
_______________________________________

From report at bugs.python.org  Mon Oct 26 06:04:59 2015
From: report at bugs.python.org (eryksun)
Date: Mon, 26 Oct 2015 10:04:59 +0000
Subject: [issue25476] close() behavior on non-blocking BufferedIO objects with
 sockets
In-Reply-To: <1445809592.17.0.674825265911.issue25476@psf.upfronthosting.co.za>
Message-ID: <1445853899.22.0.0560920311577.issue25476@psf.upfronthosting.co.za>


eryksun added the comment:

I meant that you need a check in buffered_close such as the following:

    if (res == NULL) {
        if (PyErr_ExceptionMatches(PyExc_BlockingIOError))
            goto end;
        PyErr_Fetch(&exc, &val, &tb);
    } else
        Py_DECREF(res);

For 2.7 you could create a function similar to _PyIO_trap_eintr, but trap the errors that Python 3 maps to BlockingIOError: EAGAIN/EWOULDBLOCK, EALREADY, and EINPROGRESS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25476>
_______________________________________

From report at bugs.python.org  Mon Oct 26 07:24:20 2015
From: report at bugs.python.org (pavan kumar Dharmavarapu)
Date: Mon, 26 Oct 2015 11:24:20 +0000
Subject: [issue25425] white-spaces encountered in 3.4
In-Reply-To: <1445819818.08.0.0578990178406.issue25425@psf.upfronthosting.co.za>
Message-ID: <CAJ_G_WpzYqXGhKnfASB-8GBOFMdfe5pn0Dw1RE8P-NQEwtrrUg@mail.gmail.com>


pavan kumar Dharmavarapu added the comment:

Terry:

Thanks for you comments and  your help we will keep your mail as reference
, I will be posting regarding this in near future since we are developing
some of our applications.

On Mon, Oct 26, 2015 at 6:06 AM, Terry J. Reedy <report at bugs.python.org>
wrote:

>
> Terry J. Reedy added the comment:
>
> Pavan, if you want to followup, please post to python-list where you can
> get help explaining whatever you see as a problem.  If you get agreement
> there that a patch to CPython is needed, we can reopen this.
>
> ----------
> nosy: +terry.reedy
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
> type: performance ->
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue25425>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25425>
_______________________________________

From report at bugs.python.org  Mon Oct 26 07:31:07 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 26 Oct 2015 11:31:07 +0000
Subject: =?utf-8?q?=5Bissue25467=5D_Put_=E2=80=9Cdeprecated=E2=80=9D_warnings_firs?=
 =?utf-8?q?t?=
In-Reply-To: <1445621003.26.0.876373693451.issue25467@psf.upfronthosting.co.za>
Message-ID: <1445859067.16.0.232994760849.issue25467@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Thanks for the report and the patch.

I think a better way to handle this would be to add a "tag" next to the function name for both deprecations and "new in", and leave the actual deprecation/new-in notes at the bottom, something like:

funcname(args)  [new in 3.2] [deprecated in 3.5]
  Func description here.

  New in 3.2: the funcname() function was added.
  Deprecated in 3.5: funcname() has been deprecated.  Use anotherfunc() instead.

I've seen other docs doing it, however I'm not sure how easy it would be to implement something similar for Sphinx (maybe it's necessary to redefine the func/meth/class roles).

----------
nosy: +eric.araujo, ezio.melotti, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25467>
_______________________________________

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: [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 08:18:05 2015
From: report at bugs.python.org (Herbert)
Date: Mon, 26 Oct 2015 12:18:05 +0000
Subject: [issue25465] Pickle uses O(n) memory overhead
In-Reply-To: <1445593043.5.0.334623277706.issue25465@psf.upfronthosting.co.za>
Message-ID: <1445861885.36.0.585982177261.issue25465@psf.upfronthosting.co.za>


Herbert added the comment:

Hi Eric,

I would assume that for the right range-parameter (in my case 30 * 1000 ** 2), which just fits in memory, your system would also crash after a pickle.dump. That is, I had this behavior on two of my machine both running a Ubuntu setup though.

Nevertheless, if you give me some time I'm happy to check my dmesg and any log you wish. I find it strange that sometimes I get a MemoryError when I run out of memory (in particular when using numpy), and sometimes the system crashes (in particular when using other python-stuff). Therefore I don't think this is pickle-specific, or even if this is a bug instead of a 'feature'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25465>
_______________________________________

From report at bugs.python.org  Mon Oct 26 08:40:28 2015
From: report at bugs.python.org (Tony R.)
Date: Mon, 26 Oct 2015 12:40:28 +0000
Subject: =?utf-8?q?=5Bissue25467=5D_Put_=E2=80=9Cdeprecated=E2=80=9D_warnings_firs?=
 =?utf-8?q?t?=
In-Reply-To: <1445859067.16.0.232994760849.issue25467@psf.upfronthosting.co.za>
Message-ID: <563E2139-7033-4C9C-A4F3-F98B86EE4825@gmail.com>


Tony R. added the comment:

> Thanks for the report and the patch.

Thank you for the review!

> I think a better way to handle this would be to add a "tag" next to the function name for both deprecations and "new in", and leave the actual deprecation/new-in notes at the bottom, something like:
> 
> funcname(args)  [new in 3.2] [deprecated in 3.5]
>  Func description here.
> 
>  New in 3.2: the funcname() function was added.
>  Deprecated in 3.5: funcname() has been deprecated.  Use anotherfunc() instead.

I?m not sure I understand what you mean by ?tag?.

(ASIDE: I?m only marginally familiar with Sphinx, so I don?t know if ?tag? has a specific meaning here.  I dabble across lots of markup-to-full-docs generation tools; Sphinx is just one that I happen to know the least.)

Are you saying that the source documentation would remain as-is, but something during the Sphinx _transformation_ would generate the new/deprecated tags?  

As long as those tags are clearly visible at-or-near the start, then I?m all for it.  If that is what you propose, then I can think of several possible ways to structure the generated HTML & CSS?and from there I would just need to dive into the Sphinx transformations and figure out where to sprinkle the ?tags?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25467>
_______________________________________

From report at bugs.python.org  Mon Oct 26 08:57:42 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 26 Oct 2015 12:57:42 +0000
Subject: [issue25444] Py Launch Icon
In-Reply-To: <1445315488.63.0.0387362218843.issue25444@psf.upfronthosting.co.za>
Message-ID: <1445864262.34.0.523192137649.issue25444@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I am the current IDLE maintainer, so that is my interest.  I am not responsible for the launcher icon and don't care about it either way.  The second one is the one used for IDLE, but Windows has a different format for icons and the little one on the title bar does not look as in the screenshot.  It looks terrible, worse than the launcher icon.  I do not really know why but I want to fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25444>
_______________________________________

From report at bugs.python.org  Mon Oct 26 09:11:00 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 26 Oct 2015 13:11:00 +0000
Subject: =?utf-8?q?=5Bissue25467=5D_Put_=E2=80=9Cdeprecated=E2=80=9D_warnings_firs?=
 =?utf-8?q?t?=
In-Reply-To: <1445621003.26.0.876373693451.issue25467@psf.upfronthosting.co.za>
Message-ID: <1445865060.5.0.385670324933.issue25467@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> I?m not sure I understand what you mean by ?tag?.

>> funcname(args)  [new in 3.2] [deprecated in 3.5]
>>   Func description here.

I mean some kind of tag/label next to the name of the function in the documentation (red/orange for deprecations, green for new-in)  -- it's not a Sphinx-specific term.
I saw it in some other documentation but I can't find it anymore, however if you look at the [task] and [assigned] tags/labels at the top of https://twistedmatrix.com/trac/ticket/5000 you can get a pretty close idea of what I'm thinking about.

> Are you saying that the source documentation would remain as-is,
> but something during the Sphinx _transformation_ would generate
> the new/deprecated tags?  

That's the idea.  Ideally the func/meth/class directives [0] would add the tags/labels if they contain version-added/version-changed/deprecated/deprecated-remove directives.

[0]: directives look like ".. function:: foo(args)", whereas roles look like :func:`foo`.  Functions are defined using directives.  In the previous message I mistakenly said "roles".  See also https://docs.python.org/devguide/documenting.html#directives

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25467>
_______________________________________

From report at bugs.python.org  Mon Oct 26 09:38:53 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Oct 2015 13:38:53 +0000
Subject: [issue20438] inspect: Deprecate getfullargspec?
In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za>
Message-ID: <1445866733.02.0.0765107032078.issue20438@psf.upfronthosting.co.za>


R. David Murray added the comment:

The thing is, we've adopted a policy that if something exists in python2.7 we shouldn't delete it in python3 until after 2.7 is officially out of maintenance (at the earliest), in order to facilitate single-source porting to python3.  That policy was adopted relatively recently, after the deprecation warning mentioning 3.6 was added in this issue, as I recall it.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20438>
_______________________________________

From report at bugs.python.org  Mon Oct 26 09:55:22 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Oct 2015 13:55:22 +0000
Subject: [issue25481] PermissionError in subprocess.check_output() when
 running as a different user (not login shell)
In-Reply-To: <1445848797.06.0.600636578696.issue25481@psf.upfronthosting.co.za>
Message-ID: <1445867722.7.0.414981367029.issue25481@psf.upfronthosting.co.za>


R. David Murray added the comment:

It is almost certainly the case that the error message is correct.  The most likely explanation given your pasted session is that user2 does not have permission in the CWD.  When you use --login, the CWD changes to user2's home, which it of course has permission in.

----------
nosy: +r.david.murray
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25481>
_______________________________________

From report at bugs.python.org  Mon Oct 26 10:39:07 2015
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 26 Oct 2015 14:39:07 +0000
Subject: [issue20438] inspect: Deprecate getfullargspec?
In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za>
Message-ID: <1445870347.16.0.0894251539222.issue20438@psf.upfronthosting.co.za>


Ned Batchelder added the comment:

This is the situation I am in: coverage.py uses getargspec in a very simple way in its tooling.  I support 2.7 and 3.5, so I have to do this:

    try:
        getargspec = inspect.getfullargspec
    except AttributeError:
        getargspec = inspect.getargspec
    argspec = getargspec(function)

It seems like needless churn.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20438>
_______________________________________

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: [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 11:53:02 2015
From: report at bugs.python.org (Jose M. Alcaide)
Date: Mon, 26 Oct 2015 15:53:02 +0000
Subject: [issue24570] IDLE Autocomplete and Call Tips Do Not Pop Up on OS X
 with ActiveTcl 8.5.18
In-Reply-To: <1436129307.64.0.192936457067.issue24570@psf.upfronthosting.co.za>
Message-ID: <1445874782.66.0.494962932139.issue24570@psf.upfronthosting.co.za>


Jose M. Alcaide added the comment:

My previous comment was incorrect, sorry.

I thought that this issue was fixed in time for the release of Python 3.5, but it wasn't (fix was committed on Sep 26, two weeks after 3.5's release).

My apologies.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24570>
_______________________________________

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: [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 12:14:02 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 26 Oct 2015 16:14:02 +0000
Subject: =?utf-8?q?=5Bissue25467=5D_Put_=E2=80=9Cdeprecated=E2=80=9D_warnings_firs?=
 =?utf-8?q?t?=
In-Reply-To: <1445621003.26.0.876373693451.issue25467@psf.upfronthosting.co.za>
Message-ID: <1445876042.82.0.0744043816233.issue25467@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25467>
_______________________________________

From report at bugs.python.org  Mon Oct 26 12:39:44 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 26 Oct 2015 16:39:44 +0000
Subject: [issue25154] Drop the pyvenv script
In-Reply-To: <1442514921.37.0.255858283829.issue25154@psf.upfronthosting.co.za>
Message-ID: <1445877584.45.0.767130794985.issue25154@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25154>
_______________________________________

From report at bugs.python.org  Mon Oct 26 12:39:47 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 26 Oct 2015 16:39:47 +0000
Subject: [issue25484] Operator issue with "in" on same level and preceding ==
In-Reply-To: <1445875738.33.0.0502599312232.issue25484@psf.upfronthosting.co.za>
Message-ID: <1445877587.04.0.908937838086.issue25484@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25484>
_______________________________________

From report at bugs.python.org  Mon Oct 26 12:50:28 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 26 Oct 2015 16:50:28 +0000
Subject: [issue25484] Operator issue with "in" on same level and preceding ==
In-Reply-To: <1445875738.33.0.0502599312232.issue25484@psf.upfronthosting.co.za>
Message-ID: <1445878228.37.0.168175154614.issue25484@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

As far as I understand, this is treated as "x < y < z" or "x == y == z":

>>> import ast
>>> ast.dump(ast.parse("1 < 2 < 3"))
'Module(body=[Expr(value=Compare(left=Num(n=1), ops=[Lt(), Lt()], comparators=[Num(n=2), Num(n=3)]))])
>>> ast.dump(ast.parse("1 == 2 == 3"))
'Module(body=[Expr(value=Compare(left=Num(n=1), ops=[Eq(), Eq()], comparators=[Num(n=2), Num(n=3)]))])'
>>> ast.dump(ast.parse("1 in 2 == 3"))
'Module(body=[Expr(value=Compare(left=Num(n=1), ops=[In(), Eq()], comparators=[Num(n=2), Num(n=3)]))])'

The following code is also valid and works as expected:
>>> 1 in [1] in [[1]]
True
>>> 2 not in [1] in [[1]]
True

Your example yields an unexpected result, but I'm not sure if and how it can be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25484>
_______________________________________

From report at bugs.python.org  Mon Oct 26 13:01:58 2015
From: report at bugs.python.org (jaystrict)
Date: Mon, 26 Oct 2015 17:01:58 +0000
Subject: [issue25481] PermissionError in subprocess.check_output() when
 running as a different user (not login shell)
In-Reply-To: <1445848797.06.0.600636578696.issue25481@psf.upfronthosting.co.za>
Message-ID: <1445878918.09.0.330516209125.issue25481@psf.upfronthosting.co.za>


jaystrict added the comment:

user2 in fact has permissions in the CWD.
The CWD has been set to /tmp intentionally, exactly for that reason that every user has "rwx" access there.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25481>
_______________________________________

From report at bugs.python.org  Mon Oct 26 13:08:50 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Oct 2015 17:08:50 +0000
Subject: [issue25481] PermissionError in subprocess.check_output() when
 running as a different user (not login shell)
In-Reply-To: <1445848797.06.0.600636578696.issue25481@psf.upfronthosting.co.za>
Message-ID: <1445879330.48.0.838545661954.issue25481@psf.upfronthosting.co.za>


R. David Murray added the comment:

On some unix systems you cannot execute files in /tmp, even if x is set.  Is that true for yours?  Bascially, subprocess is just reporting the error that the OS is reporting to it, which is why I say the messages is almost certainly correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25481>
_______________________________________

From report at bugs.python.org  Mon Oct 26 13:15:31 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 26 Oct 2015 17:15:31 +0000
Subject: [issue25484] Operator issue with "in" on same level and preceding ==
In-Reply-To: <1445875738.33.0.0502599312232.issue25484@psf.upfronthosting.co.za>
Message-ID: <1445879731.97.0.59699481746.issue25484@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

https://docs.python.org/3/reference/expressions.html#comparisons says that "a op1 b op2 c ... y opN z is equivalent to a op1 b and b op2 c and ... y opN z" and this explains the "unexpected" result:

>>> 1 in [1] == True
False
>>> 1 in [1] and [1] == True
False

"in" and "not in" are also listed among the comparison operators, so I think this behavior is expected and by design.  I don't think there's anything that needs to be fixed here.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25484>
_______________________________________

From report at bugs.python.org  Mon Oct 26 13:33:45 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Oct 2015 17:33:45 +0000
Subject: =?utf-8?q?=5Bissue25467=5D_Put_=E2=80=9Cdeprecated=E2=80=9D_warnings_firs?=
 =?utf-8?q?t?=
In-Reply-To: <1445621003.26.0.876373693451.issue25467@psf.upfronthosting.co.za>
Message-ID: <1445880825.33.0.945225763091.issue25467@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think Ezio's idea is great.  I would not want to see the notices at the top, but a label would make things clear (and the label could be hyperlinked to the note, since sometimes they are a bit of a distance away).

Someone has to figure out the Sphinx programming, though.

Note that the 'new' label should only appear for stuff that is new in that release.  It's not clear to me if it should appear at all in the docs for maintenance releases...that should be discussed.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25467>
_______________________________________

From report at bugs.python.org  Mon Oct 26 13:35:21 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 26 Oct 2015 17:35:21 +0000
Subject: [issue25483] Improve f-string implementation: FORMAT_VALUE opcode
In-Reply-To: <1445874299.22.0.773155754186.issue25483@psf.upfronthosting.co.za>
Message-ID: <1445880921.47.0.887128554429.issue25483@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Small cleanups. Fixed a bug in PyCompile_OpcodeStackEffect.

----------
Added file: http://bugs.python.org/file40864/format-opcode-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25483>
_______________________________________

From report at bugs.python.org  Mon Oct 26 13:42:29 2015
From: report at bugs.python.org (jaystrict)
Date: Mon, 26 Oct 2015 17:42:29 +0000
Subject: [issue25481] PermissionError in subprocess.check_output() when
 running as a different user (not login shell)
In-Reply-To: <1445848797.06.0.600636578696.issue25481@psf.upfronthosting.co.za>
Message-ID: <1445881349.94.0.663190357176.issue25481@psf.upfronthosting.co.za>


jaystrict added the comment:

I just tried the same thing in /home/user2 which is the home of user2 and in /.
In both directories the result is the PermissionError. So the cause is not the CWD.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25481>
_______________________________________

From report at bugs.python.org  Mon Oct 26 13:49:46 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 26 Oct 2015 17:49:46 +0000
Subject: =?utf-8?q?=5Bissue25467=5D_Put_=E2=80=9Cdeprecated=E2=80=9D_warnings_firs?=
 =?utf-8?q?t?=
In-Reply-To: <1445621003.26.0.876373693451.issue25467@psf.upfronthosting.co.za>
Message-ID: <1445881786.52.0.901717620528.issue25467@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> Note that the 'new' label should only appear for stuff that is new
> in that release.

This is not a problem if it says [new in x.y] explicitly.  This way for each version-added/version-changed/deprecated/deprecated-remove directive we will also have a label.

As for the implementation, I'm pretty sure it can be done by changing/redefining all the function/method/class directives.  The directives should then be able to inspect the nodes they contain and see if there are any of the aforementioned directives and turn them into labels.  Not sure if there's a clever way to do it though (maybe a CSS class can be added to the directives and the labels can be added with CSS :after).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25467>
_______________________________________

From report at bugs.python.org  Mon Oct 26 13:52:51 2015
From: report at bugs.python.org (Tony R.)
Date: Mon, 26 Oct 2015 17:52:51 +0000
Subject: =?utf-8?q?=5Bissue25467=5D_Put_=E2=80=9Cdeprecated=E2=80=9D_warnings_firs?=
 =?utf-8?q?t?=
In-Reply-To: <1445881786.52.0.901717620528.issue25467@psf.upfronthosting.co.za>
Message-ID: <091205E7-7CD2-4875-A0C7-E283D745F1A6@gmail.com>


Tony R. added the comment:

> On Oct 26, 2015, at 1:49 PM, Ezio Melotti <report at bugs.python.org> wrote:
> 
> Not sure if there's a clever way to do it though (maybe a CSS class can be added to the directives and the labels can be added with CSS :after).

I was thinking something along these lines.  Other possibilities come to mind, also.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25467>
_______________________________________

From report at bugs.python.org  Mon Oct 26 14:13:11 2015
From: report at bugs.python.org (jaystrict)
Date: Mon, 26 Oct 2015 18:13:11 +0000
Subject: [issue25481] PermissionError in subprocess.check_output() when
 running as a different user (not login shell)
In-Reply-To: <1445848797.06.0.600636578696.issue25481@psf.upfronthosting.co.za>
Message-ID: <1445883190.98.0.862389642522.issue25481@psf.upfronthosting.co.za>


jaystrict added the comment:

I just found that a "chmod o+x /home/user1" fixes the problem in the sense that now a FileNotFoundError is thrown.
So I am very certain that you can reproduce this by making your home directory non-executable.

Could it be that python tries to access the "original" home directory somehow? For example to write to a pipe?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25481>
_______________________________________

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: [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 14:22:28 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Oct 2015 18:22:28 +0000
Subject: =?utf-8?q?=5Bissue25467=5D_Put_=E2=80=9Cdeprecated=E2=80=9D_warnings_firs?=
 =?utf-8?q?t?=
In-Reply-To: <1445621003.26.0.876373693451.issue25467@psf.upfronthosting.co.za>
Message-ID: <1445883748.06.0.532190146286.issue25467@psf.upfronthosting.co.za>


R. David Murray added the comment:

Insert "in my opinion" into that sentence.  I don't want to be distracted by "new in 3.1" tags when reading the 3.6 documentation.  It isn't new from my POV :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25467>
_______________________________________

From report at bugs.python.org  Mon Oct 26 14:43:52 2015
From: report at bugs.python.org (jaystrict)
Date: Mon, 26 Oct 2015 18:43:52 +0000
Subject: [issue25481] PermissionError in subprocess.check_output() when
 running as a different user (not login shell)
In-Reply-To: <1445848797.06.0.600636578696.issue25481@psf.upfronthosting.co.za>
Message-ID: <1445885032.61.0.0368966544091.issue25481@psf.upfronthosting.co.za>


jaystrict added the comment:

Narrowing it down further:

In $PATH there is a subdirectory of /home/user1.
PATH="/home/user1/bin:/usr/local/sbin:/usr/local/bin:/usr/bin"

Doing an strace on the example above shows the line
stat("/home/user1/bin/python", 0x7fff9d365bb0) = -1 EACCES (Permission denied)
AFAICT this line is generated when the shell looks for the correct python executable, but it should not interfere with the (later) call to subprocess.check_output().

If I delete "/home/user1/bin" from $PATH, then the correct FileNotFoundError is thrown.

So it seems (just guessing) that subprocess.check_output() somehow throws the older, obsolete error code. Would this be possible?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25481>
_______________________________________

From report at bugs.python.org  Mon Oct 26 14:54:43 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Oct 2015 18:54:43 +0000
Subject: [issue25481] PermissionError in subprocess.check_output() when
 running as a different user (not login shell)
In-Reply-To: <1445848797.06.0.600636578696.issue25481@psf.upfronthosting.co.za>
Message-ID: <1445885683.21.0.592338856666.issue25481@psf.upfronthosting.co.za>


R. David Murray added the comment:

What do you mean by older obsolete error code?  It sounds like the problem is that user2 doesn't have read (or execute?) permission for that directory in the path.  I'd think it would just skip it in that case, though.  I don't have time to run tests myself right now...maybe you can take a look at what subprocess is actually doing when that error is generated?  (It might be in the C code, though, I don't remember).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25481>
_______________________________________

From report at bugs.python.org  Mon Oct 26 15:14:38 2015
From: report at bugs.python.org (Gustavo J. A. M. Carneiro)
Date: Mon, 26 Oct 2015 19:14:38 +0000
Subject: [issue20519] Replace uuid ctypes usage with an extension module.
In-Reply-To: <1391601143.27.0.910101155735.issue20519@psf.upfronthosting.co.za>
Message-ID: <1445886878.61.0.88555331221.issue20519@psf.upfronthosting.co.za>


Gustavo J. A. M. Carneiro added the comment:

This patch fixes the Mac OS X issue @haypo pointed out.

----------
Added file: http://bugs.python.org/file40865/issue20519_10941v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20519>
_______________________________________

From report at bugs.python.org  Mon Oct 26 15:25:11 2015
From: report at bugs.python.org (Gustavo J. A. M. Carneiro)
Date: Mon, 26 Oct 2015 19:25:11 +0000
Subject: [issue20519] Replace uuid ctypes usage with an extension module.
In-Reply-To: <1391601143.27.0.910101155735.issue20519@psf.upfronthosting.co.za>
Message-ID: <1445887511.92.0.527475872686.issue20519@psf.upfronthosting.co.za>


Gustavo J. A. M. Carneiro added the comment:

One issue of note is regarding generate_time().  Originally I found ctypes bindings for this function, so I wrapped it as well in the extension module.  However, it doesn't appear to be used...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20519>
_______________________________________

From report at bugs.python.org  Mon Oct 26 16:27:29 2015
From: report at bugs.python.org (feliep)
Date: Mon, 26 Oct 2015 20:27:29 +0000
Subject: [issue25432] isinstance documentation: explain behavior when type is
 a tuple
In-Reply-To: <1445093164.36.0.718439234598.issue25432@psf.upfronthosting.co.za>
Message-ID: <1445891249.38.0.838751261361.issue25432@psf.upfronthosting.co.za>


feliep added the comment:

I think that the following part could replace the part of the other text that's between ###. It's more objective and easier to understand. 

classinfo may could be a tuple of type objects, or may contains others tuples that contains type objects (other sequence types are not accepted).

Return true if the object argument is an instance of the classinfo argument, or of a (direct, indirect or virtual) subclass thereof. If object is not an object of the given type, the function always returns false. ### If classinfo is not a class (type object), it may be a tuple of type objects, or may recursively contain other such tuples (other sequence types are not accepted). ### If classinfo is not a type or tuple of types and such tuples, a TypeError exception is raised.

What do you think?

----------
nosy: +felipevolpone

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25432>
_______________________________________

From report at bugs.python.org  Mon Oct 26 16:28:49 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 26 Oct 2015 20:28:49 +0000
Subject: =?utf-8?q?=5Bissue25467=5D_Put_=E2=80=9Cdeprecated=E2=80=9D_warnings_firs?=
 =?utf-8?q?t?=
In-Reply-To: <1445621003.26.0.876373693451.issue25467@psf.upfronthosting.co.za>
Message-ID: <1445891329.89.0.77643081695.issue25467@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> I don't want to be distracted by "new in 3.1" tags when reading
> the 3.6 documentation.

This is true, but on the other hand you might want to see the [new in 3.4] while looking at 3.6 docs and working on a program that must support Python 3.3+.  Anyway we can discuss this again once we have a patch -- depending on how it is implemented, it might be easy enough to include the tag only for functions added in the last 2 releases, or perhaps the tag won't be particularly distracting and can be used for all versions.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25467>
_______________________________________

From report at bugs.python.org  Mon Oct 26 16:22:13 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 26 Oct 2015 20:22:13 +0000
Subject: [issue23749] asyncio missing wrap_socket (starttls)
In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za>
Message-ID: <1445890933.19.0.279188239719.issue23749@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Here's an example client implementation with writer.start_tls() (taken from my debug code):

        @asyncio.coroutine
        def client(addr):
            reader, writer = yield from asyncio.open_connection(
                *addr, loop=loop)

            print("CLIENT: ", (yield from reader.readexactly(4)))
            writer.write(b'ehlo')
            yield from writer.start_tls(sslctx)
            # encrypted channel from this point
            print("CLIENT: ", (yield from reader.readexactly(4)))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23749>
_______________________________________

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: [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 16:34:21 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 26 Oct 2015 20:34:21 +0000
Subject: [issue20438] inspect: Deprecate getfullargspec?
In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za>
Message-ID: <1445891661.91.0.18664933337.issue20438@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> The thing is, we've adopted a policy that if something exists in python2.7 we shouldn't delete it in python3 until after 2.7 is officially out of maintenance (at the earliest), in order to facilitate single-source porting to python3.  That policy was adopted relatively recently, after the deprecation warning mentioning 3.6 was added in this issue, as I recall it.

In this case we better resurrect getargspec().  Here's an issue for that: #25486

----------
dependencies: +Resurrect inspect.getargspec() in 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20438>
_______________________________________

From report at bugs.python.org  Mon Oct 26 16:19:21 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 26 Oct 2015 20:19:21 +0000
Subject: [issue23749] asyncio missing wrap_socket (starttls)
In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za>
Message-ID: <1445890761.24.0.781386683195.issue23749@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Guido, Victor,

Please find attached a first draft of the patch.  It's a very early attempt (i.e. I'm not including unit tests/docstrings), and its primary purpose is to gather initial feedback.

Some points:

1. As discussed earlier, the primary API point is new transports.TLSTransport class with a `start_tls(sslcontetx, *, server_side=False, server_hostname=None)` method.

2. While experimenting with the code and unit tests, I thought that it would be great if stream writers could do start_tls too, this patch has that too.  I like this new idea -- makes it so much simpler to write protocols.

----------
keywords: +patch
Added file: http://bugs.python.org/file40866/tls1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23749>
_______________________________________

From report at bugs.python.org  Mon Oct 26 16:37:11 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 26 Oct 2015 20:37:11 +0000
Subject: [issue20438] inspect: Deprecate getfullargspec?
In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za>
Message-ID: <1445891831.98.0.355816732662.issue20438@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> This is the situation I am in: coverage.py uses getargspec in a very simple way in its tooling.  I support 2.7 and 3.5, so I have to do this:

    try:
        getargspec = inspect.getfullargspec
    except AttributeError:
        getargspec = inspect.getargspec
    argspec = getargspec(function)

I think it was me who submitted this code to coverage.py.. :)  It might be worthwhile to keep it anyways, as getfullargspec uses the signature API, which supports a wider range of callables.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20438>
_______________________________________

From report at bugs.python.org  Mon Oct 26 16:37:45 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Oct 2015 20:37:45 +0000
Subject: [issue25432] isinstance documentation: explain behavior when type is
 a tuple
In-Reply-To: <1445093164.36.0.718439234598.issue25432@psf.upfronthosting.co.za>
Message-ID: <1445891865.72.0.126540958772.issue25432@psf.upfronthosting.co.za>


R. David Murray added the comment:

The fact that nested tuples are accepted is just bizarre, IMO :(.

It could say something like "If classinfo is a (possibly nested) list of types, return True if any of the types match."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25432>
_______________________________________

From report at bugs.python.org  Mon Oct 26 17:25:11 2015
From: report at bugs.python.org (Felipe Volpone)
Date: Mon, 26 Oct 2015 21:25:11 +0000
Subject: [issue25432] isinstance documentation: explain behavior when type is
 a tuple
In-Reply-To: <1445093164.36.0.718439234598.issue25432@psf.upfronthosting.co.za>
Message-ID: <1445894711.35.0.701642544948.issue25432@psf.upfronthosting.co.za>


Felipe Volpone added the comment:

r.david.murray: I liked your way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25432>
_______________________________________

From report at bugs.python.org  Mon Oct 26 18:13:14 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 26 Oct 2015 22:13:14 +0000
Subject: [issue25432] isinstance documentation: explain behavior when type is
 a tuple
In-Reply-To: <1445093164.36.0.718439234598.issue25432@psf.upfronthosting.co.za>
Message-ID: <1445897594.41.0.861751864625.issue25432@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

David, if you are suggesting that the initial negative clause of "If classinfo is not a class (type object)" is not needed, I agree.  If classinfo is a tuple, is is not a class.  'list of types' has to be 'tuple of types'. I think 'match' needs to be expanded to 'is an instance of'. How about

"If classinfo is a tuple of type objects (or recursively, other such tuples), return true if object is an instance of any of the types.

This leaves out the left to right ordering of the tests, but I think that is implied by how Python generally works.  Short circuiting certainly is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25432>
_______________________________________

From report at bugs.python.org  Mon Oct 26 18:50:48 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 26 Oct 2015 22:50:48 +0000
Subject: [issue25483] Improve f-string implementation: FORMAT_VALUE opcode
In-Reply-To: <1445874299.22.0.773155754186.issue25483@psf.upfronthosting.co.za>
Message-ID: <1445899848.18.0.0219796102671.issue25483@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

This patch addresses Larry's review, plus bumps the bytecode magic number.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25483>
_______________________________________

From report at bugs.python.org  Mon Oct 26 18:55:25 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Oct 2015 22:55:25 +0000
Subject: [issue25432] isinstance documentation: explain behavior when type is
 a tuple
In-Reply-To: <1445093164.36.0.718439234598.issue25432@psf.upfronthosting.co.za>
Message-ID: <1445900125.37.0.988277354625.issue25432@psf.upfronthosting.co.za>


R. David Murray added the comment:

Sure, that's fine with me.  I was trying to minimize words, but clarity is good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25432>
_______________________________________

From report at bugs.python.org  Mon Oct 26 19:00:33 2015
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 26 Oct 2015 23:00:33 +0000
Subject: [issue25486] Resurrect inspect.getargspec() in 3.6
In-Reply-To: <1445891623.91.0.591196153919.issue25486@psf.upfronthosting.co.za>
Message-ID: <1445900433.26.0.368377997729.issue25486@psf.upfronthosting.co.za>


Changes by Ned Batchelder <ned at nedbatchelder.com>:


----------
nosy: +nedbat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25486>
_______________________________________

From report at bugs.python.org  Mon Oct 26 20:00:58 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Oct 2015 00:00:58 +0000
Subject: [issue23391] Documentation of EnvironmentError (OSError) arguments
 disappeared
In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za>
Message-ID: <20151027000055.25483.79091@psf.io>


Roundup Robot added the comment:

New changeset cb554248ce54 by Martin Panter in branch '3.4':
Issue #23391: Restore OSError constructor argument documentation
https://hg.python.org/cpython/rev/cb554248ce54

New changeset 7b1a9a12eb77 by Martin Panter in branch '3.5':
Issue #23391: Merge OSError doc from 3.4 into 3.5
https://hg.python.org/cpython/rev/7b1a9a12eb77

New changeset e5df201c0846 by Martin Panter in branch 'default':
Issue #23391: Merge OSError doc from 3.5
https://hg.python.org/cpython/rev/e5df201c0846

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23391>
_______________________________________

From report at bugs.python.org  Mon Oct 26 20:11:39 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 27 Oct 2015 00:11:39 +0000
Subject: [issue25154] Drop the pyvenv script
In-Reply-To: <1442514921.37.0.255858283829.issue25154@psf.upfronthosting.co.za>
Message-ID: <1445904699.73.0.375645426013.issue25154@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Took Eric's advice in 8828d7847e92 as well as actually tested the results this time. :P

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25154>
_______________________________________

From report at bugs.python.org  Mon Oct 26 20:38:48 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 27 Oct 2015 00:38:48 +0000
Subject: [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  Mon Oct 26 20:51:15 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 27 Oct 2015 00:51:15 +0000
Subject: [issue23391] Documentation of EnvironmentError (OSError) arguments
 disappeared
In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za>
Message-ID: <1445907075.1.0.296279726175.issue23391@psf.upfronthosting.co.za>


Martin Panter added the comment:

I will leave opening a bug for the args issue for someone else. But if you come up with a sensible solution or find out all the details, I am happy to help write up or review the documentation changes.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23391>
_______________________________________

From report at bugs.python.org  Mon Oct 26 22:35:24 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Oct 2015 02:35:24 +0000
Subject: [issue20519] Replace uuid ctypes usage with an extension module.
In-Reply-To: <1391601143.27.0.910101155735.issue20519@psf.upfronthosting.co.za>
Message-ID: <1445913324.79.0.315867925952.issue20519@psf.upfronthosting.co.za>


STINNER Victor added the comment:

New review (question for Windows).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20519>
_______________________________________

From report at bugs.python.org  Mon Oct 26 22:39:28 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 27 Oct 2015 02:39:28 +0000
Subject: [issue25478] Consider adding a normalize() method to
 collections.Counter()
In-Reply-To: <1445826280.05.0.307309053044.issue25478@psf.upfronthosting.co.za>
Message-ID: <1445913568.63.0.245930259224.issue25478@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Counter is documented as being primarily intended for integer counts. While you can use them with floats, I'm not sure they're the right data type for this use case. Having some methods that only make sense with floats, and others (like elements) that only make sense with integers is just confusing.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25478>
_______________________________________

From report at bugs.python.org  Mon Oct 26 23:56:56 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 27 Oct 2015 03:56:56 +0000
Subject: [issue16785] Document the fact that constructing OSError with erron
 returns subclass if possible
In-Reply-To: <1356521712.57.0.0819210166931.issue16785@psf.upfronthosting.co.za>
Message-ID: <1445918216.2.0.500088260967.issue16785@psf.upfronthosting.co.za>


Martin Panter added the comment:

Hopefully revision cb554248ce54 is good enough to close this. The documentation now says

'''
The constructor often actually returns a subclass of OSError, as described in ?OS exceptions? below. The particular subclass depends on the final ?errno? value. This behaviour only occurs when constructing OSError directly or via an alias, and is not inherited when subclassing.
'''

Serhiy?s first case does not set the ?errno? attribute (by design I assume). In the second case, I suspect the behaviour has changed since 2012, or it depends on the platform. On Windows, the 'spam' argument is meant to become ?winerror?, which can override ?errno? if it is an integer. 3.6 on Linux:

>>> OSError(errno.ENOENT, 'error msg', 'filename', 'spam')
FileNotFoundError(2, 'error msg')

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16785>
_______________________________________

From report at bugs.python.org  Tue Oct 27 00:00:30 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 27 Oct 2015 04:00:30 +0000
Subject: [issue25472] Typing: Specialized subclasses of generics cannot be
 unpickled
In-Reply-To: <1445742573.23.0.0225018159767.issue25472@psf.upfronthosting.co.za>
Message-ID: <1445918430.12.0.557297059308.issue25472@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

FWIW the pickle produced looks like this, decoded with pickletools.dis():

    0: \x80 PROTO      3
    2: c    GLOBAL     '__main__ B'
   14: q    BINPUT     0
   16: )    EMPTY_TUPLE
   17: \x81 NEWOBJ
   18: q    BINPUT     1
   20: }    EMPTY_DICT
   21: q    BINPUT     2
   23: X    BINUNICODE 'x'
   29: q    BINPUT     3
   31: X    BINUNICODE 'hello'
   41: q    BINPUT     4
   43: s    SETITEM
   44: b    BUILD
   45: .    STOP

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25472>
_______________________________________

From report at bugs.python.org  Tue Oct 27 00:14:02 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 27 Oct 2015 04:14:02 +0000
Subject: [issue25472] Typing: Specialized subclasses of generics cannot be
 unpickled
In-Reply-To: <1445742573.23.0.0225018159767.issue25472@psf.upfronthosting.co.za>
Message-ID: <1445919242.48.0.90366175321.issue25472@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

The issue seems to be the line

            inst_dict = inst.__dict__


in _Unpickler.load_build().  (I found this out by forcing sys.modules['_pickle'] = None, so the pure-Python pickle.py code gets used.)

This leads to a simpler repro: 

# Use the same class definitions for A and B
b = B("hello")
print(b.__dict__)  # Same error message as before

That is, specialized subclasses of generics don't have a working __dict__ attribute!  Interestingly, A("hello").__dict__ works.

I have to ponder this more.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25472>
_______________________________________

From report at bugs.python.org  Tue Oct 27 00:28:35 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 27 Oct 2015 04:28:35 +0000
Subject: [issue25465] Pickle uses O(n) memory overhead
In-Reply-To: <1445593043.5.0.334623277706.issue25465@psf.upfronthosting.co.za>
Message-ID: <1445920115.69.0.864184569285.issue25465@psf.upfronthosting.co.za>


Martin Panter added the comment:

Perhaps by OS crash you mean either the Linux out-of-memory (OOM) killer, that takes a hueristic stab at killing the right process, or Linux running almost out of memory, and everything grinding to a halt presumably because each task switch needs to re-read its program off the hard disk.

If either is the case, I understand this is part of Linux?s design, called ?memory overcommit? or something. It is possible to disable it, though I haven?t tried myself, and many programs (probably including Python) are apparently not compatible.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25465>
_______________________________________

From report at bugs.python.org  Tue Oct 27 00:49:56 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 27 Oct 2015 04:49:56 +0000
Subject: [issue25482] signal.set_wakeup_fd() doesn't work if the signal don't
 have handler
In-Reply-To: <1445859296.06.0.537058365711.issue25482@psf.upfronthosting.co.za>
Message-ID: <1445921396.98.0.852031738085.issue25482@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Yes, you need to tell the kernel to not ignore SIGWINCH automatically for you.

----------
nosy: +benjamin.peterson
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25482>
_______________________________________

From report at bugs.python.org  Tue Oct 27 01:00:32 2015
From: report at bugs.python.org (eryksun)
Date: Tue, 27 Oct 2015 05:00:32 +0000
Subject: [issue25356] Idle (Python 3.4 on Ubuntu) does not allow typing accents
In-Reply-To: <1444404560.14.0.409888700573.issue25356@psf.upfronthosting.co.za>
Message-ID: <1445922032.4.0.236361197412.issue25356@psf.upfronthosting.co.za>


eryksun added the comment:

This seems to be a problem with Tk 8.6 when using an international keyboard layout on Linux. I ran the following test.tcl script via wish:

    text .t
    pack .t

Initially dead keys work, but they stop working if I switch away from the text entry to another window and then back. Using the menu to save a file in IDLE has the same effect. I suggest opening a ticket at http://core.tcl.tk/tk.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25356>
_______________________________________

From report at bugs.python.org  Tue Oct 27 01:18:42 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 27 Oct 2015 05:18:42 +0000
Subject: [issue25439] Add type checks to urllib.request.Request
In-Reply-To: <1445247083.91.0.927080887762.issue25439@psf.upfronthosting.co.za>
Message-ID: <1445923122.1.0.532852696458.issue25439@psf.upfronthosting.co.za>


Martin Panter added the comment:

There is already a check for request.data being str in do_request_(). Maybe it is okay to remove this check; I think it would be equivalent to the new check.

Regarding the dict check, here is a strange class that currently works, but would be broken by the patch. Maybe it is okay to break it though, since it certainly goes against the urlopen() documentation.

class ReaderMapping(dict):
    def __init__(self):
        super().__init__({"abc": "xyz"})
        self.mode = "r"
        self.data = "123"
    def read(self, size):
        data = self.data
        self.data = ""
        return data

urlopen(Request("http://localhost/", headers={"Content-Length": 3}, data=ReaderMapping()))

If we wanted to continue to support this kind of usage, perhaps the safest option would be to change the test to ?if type(data) is dict? rather than use isinstance().

I also left a comment about eliminating urlencode() in the test.

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25439>
_______________________________________

From report at bugs.python.org  Tue Oct 27 01:27:45 2015
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Tue, 27 Oct 2015 05:27:45 +0000
Subject: [issue25482] signal.set_wakeup_fd() doesn't work if the signal don't
 have handler
In-Reply-To: <1445859296.06.0.537058365711.issue25482@psf.upfronthosting.co.za>
Message-ID: <1445923665.02.0.69355565322.issue25482@psf.upfronthosting.co.za>


Atsuo Ishimoto added the comment:

Okay, so I think this needed to be documented in signal.set_wakeup_fd(). 

IMO this reduces usefulness of set_wakeup_fd(). If I need to install custom handler by my self, I can write to fd in my own custom handler.

And,  installing custom handler omits existing handler, but we can not execute existing signal handler from python script. In my real-world case, SIGWINCH signal does not delivered to curses library. 

pep-475(https://www.python.org/dev/peps/pep-0475/#backward-compatibility) claims that 

    "For applications using event loops, signal.set_wakeup_fd() is the recommanded option to handle signals. "

But I think side effect of signal.set_wakeup_fd() is lager than pep-475 authors expected.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
resolution: not a bug -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25482>
_______________________________________

From report at bugs.python.org  Tue Oct 27 02:22:02 2015
From: report at bugs.python.org (eryksun)
Date: Tue, 27 Oct 2015 06:22:02 +0000
Subject: [issue25481] PermissionError in subprocess.check_output() when
 running as a different user (not login shell)
In-Reply-To: <1445848797.06.0.600636578696.issue25481@psf.upfronthosting.co.za>
Message-ID: <1445926922.26.0.793935653314.issue25481@psf.upfronthosting.co.za>


eryksun added the comment:

In subprocess.py there's the following code that builds a sequence of potential paths for the executable [1]:

    executable = os.fsencode(executable)
    if os.path.dirname(executable):
        executable_list = (executable,)
    else:
        # This matches the behavior of os._execvpe().
        executable_list = tuple(
            os.path.join(os.fsencode(dir), executable)
            for dir in os.get_exec_path(env))

In this case it tries to execute "/home/user1/bin/asdf", which fails with EACCES (to log this using strace, use -f to follow the fork). This occurs in child_exec in _posixsubprocess.c, in the following loop [2]:

    /* This loop matches the Lib/os.py _execvpe()'s PATH search when */
    /* given the executable_list generated by Lib/subprocess.py.     */
    saved_errno = 0;
    for (i = 0; exec_array[i] != NULL; ++i) {
        const char *executable = exec_array[i];
        if (envp) {
            execve(executable, argv, envp);
        } else {
            execv(executable, argv);
        }
        if (errno != ENOENT && errno != ENOTDIR && saved_errno == 0) {
            saved_errno = errno;
        }
    }
    /* Report the first exec error, not the last. */
    if (saved_errno)
        errno = saved_errno;

saved_errno will be set to EACCES and stored back to errno after all attempts to execute potential paths fail. This is then reported back to the parent process, which raises a PermissionError.

[1]: https://hg.python.org/cpython/file/3.5/Lib/subprocess.py#l1463
[2]: https://hg.python.org/cpython/file/3.5/Modules/_posixsubprocess.c#l487

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25481>
_______________________________________

From report at bugs.python.org  Tue Oct 27 03:09:21 2015
From: report at bugs.python.org (mandeep)
Date: Tue, 27 Oct 2015 07:09:21 +0000
Subject: [issue24805] Python installer having problem in installing Python for
 all users in Windows
In-Reply-To: <1438838140.75.0.258560462687.issue24805@psf.upfronthosting.co.za>
Message-ID: <1445929761.51.0.391154536014.issue24805@psf.upfronthosting.co.za>


mandeep added the comment:

It works when I try it on a clean machine.

----------
nosy: +manddy221

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24805>
_______________________________________

From report at bugs.python.org  Tue Oct 27 03:14:58 2015
From: report at bugs.python.org (mandeep)
Date: Tue, 27 Oct 2015 07:14:58 +0000
Subject: [issue24805] Python installer having problem in installing Python for
 all users in Windows
In-Reply-To: <1438838140.75.0.258560462687.issue24805@psf.upfronthosting.co.za>
Message-ID: <1445930098.1.0.06770261591.issue24805@psf.upfronthosting.co.za>


mandeep added the comment:

But if there is a machine which  already has Python. If we remove python manually and try the script .

The python folder is created.
I can see python in start- all programs.
But PYTHON its missing from control panel. It does not allow me to uninstall.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24805>
_______________________________________

From report at bugs.python.org  Tue Oct 27 05:03:26 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Oct 2015 09:03:26 +0000
Subject: [issue23391] Documentation of EnvironmentError (OSError) arguments
 disappeared
In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za>
Message-ID: <1445936606.63.0.595340037641.issue23391@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is an outdated comment in Objects/exceptions.c that explains args hacking. It refers to no longer supported syntax:

    except OSError, (errno, strerror):

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23391>
_______________________________________

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: [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 05:34:48 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 27 Oct 2015 09:34:48 +0000
Subject: [issue25356] Idle (Python 3.4 on Ubuntu) does not allow typing accents
In-Reply-To: <1444404560.14.0.409888700573.issue25356@psf.upfronthosting.co.za>
Message-ID: <1445938488.6.0.092157695985.issue25356@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Thank you for the confirmation that this is a tcl/tk problem. At least this report is here for anyone else using 8.6 with non-US keyboard on linux.

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25356>
_______________________________________

From report at bugs.python.org  Tue Oct 27 07:18:51 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 27 Oct 2015 11:18:51 +0000
Subject: [issue25488] IDLE: Remove idlelib from sys.path when added
In-Reply-To: <1445937913.03.0.194834202195.issue25488@psf.upfronthosting.co.za>
Message-ID: <1445944731.76.0.817427866108.issue25488@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

When python is started without running a file (Windows icon or command line), '' is prepended to sys.path.  When IDLE is started from 3.5 icon, '' is prepended temporally after and spatially before '.../idlelib', so the latter, to be removed, is sys.path[1] and not sys.path[0].

'' in sys.path interpreted as the current working directory.

When IDLE is started from the command line with '-m idlelib' instead of '.../idlelib/idle.py' (for instance), the current working directory is added instead of .../idlelib (in second position).

Adding the startup current directory is redundant with '' until the user imports os and changes the cwd.  Then I expect the behavior of Shell to be different from python interactive mode, which would be a bug.  I will try to find a test case later.
  
PyShell.main manipulates 'sys.path' in lines 1521 and 1525, but these are sys.argv of the idle process, not the user process, each of which have their own sys.argv. If filenames are given on the command line to be edited, the directory of each is added to sys.path *for the idle process* (line 1521).  I suspect this is for completions. Line 1525 add the current working directory.  I don't know why.  Perhaps it is a holdover for -n single process mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25488>
_______________________________________

From report at bugs.python.org  Tue Oct 27 07:19:55 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 27 Oct 2015 11:19:55 +0000
Subject: [issue25476] close() behavior on non-blocking BufferedIO objects with
 sockets
In-Reply-To: <1445809592.17.0.674825265911.issue25476@psf.upfronthosting.co.za>
Message-ID: <1445944795.33.0.565624626345.issue25476@psf.upfronthosting.co.za>


Martin Panter added the comment:

David, what?s your use case for doing non-blocking buffered writing ?correctly?? Would you be able to use the context manager functionality? I would have thought you would explicitly call flush() as many times as necessary, but only call close() once when you are done.

At least in blocking mode, close() is meant do as much as possible, despite any intermediate exceptions. It doesn?t seem wise to break this rule in non-blocking mode.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25476>
_______________________________________

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: [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 07:52:45 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 27 Oct 2015 11:52:45 +0000
Subject: [issue7322] Socket timeout can cause file-like readline() method to
 lose data
In-Reply-To: <1258218993.08.0.764402701678.issue7322@psf.upfronthosting.co.za>
Message-ID: <1445946765.94.0.767454315222.issue7322@psf.upfronthosting.co.za>


Martin Panter added the comment:

IMO it might make sense in some cases to disallow subsequent reading from a buffered socket reader (or probably any BufferedReader) that raises an exception (not just a timeout). But the restriction seems unnecessary for unbuffered raw readers, and it also seems to go against the ?consenting adults? philosophy for David Murray?s test server case.

David Beazley: For non-blocking sockets, the documentation currently says ?the socket must be in blocking mode?. I?m not sure why that restriction is necessary; maybe it could be lifted at least for raw unbuffered streams.

Maybe you could make an argument for caching the partial data in the BufferedReader if a timeout (or no more non-blocking data, or other exception) occurs. The biggest problem is that it could mean storing more than the normal buffer size. I would think this would be a new feature (for 3.6+) rather than a behavioural bug fix though.

And see also Issue 13322 about inconsistencies with buffered reading non-blocking streams in general.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Tue Oct 27 08:17:00 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 27 Oct 2015 12:17:00 +0000
Subject: [issue23237] Interrupts are lost during readline PyOS_InputHook
 processing (reopening)
In-Reply-To: <1421201583.23.0.507661432161.issue23237@psf.upfronthosting.co.za>
Message-ID: <1445948220.08.0.651464852543.issue23237@psf.upfronthosting.co.za>


Martin Panter added the comment:

>From memory my biggest worry was changing the API (meaning of return value). I don?t know what the policy is, but it might need a new separate API. You might find more input from experts on the python-dev list or something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23237>
_______________________________________

From report at bugs.python.org  Tue Oct 27 08:29:01 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 27 Oct 2015 12:29:01 +0000
Subject: [issue25470] Random Malloc error raised
In-Reply-To: <1445695572.21.0.810479855368.issue25470@psf.upfronthosting.co.za>
Message-ID: <1445948941.26.0.531659870538.issue25470@psf.upfronthosting.co.za>


Martin Panter added the comment:

Are you able to reproduce this easily? Perhaps a GDB backtrace might be useful, or posting instructions or code (simplified if possible) to reproduce it.

I?m guessing the Valgrind errors may be caused by the same problem that causes the initial assertion error.

----------
nosy: +martin.panter
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25470>
_______________________________________

From report at bugs.python.org  Tue Oct 27 08:35:01 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 27 Oct 2015 12:35:01 +0000
Subject: [issue25017] htmllib deprecated: Which library to use? Missing sane
 default in docs
In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za>
Message-ID: <1445949301.84.0.578565301766.issue25017@psf.upfronthosting.co.za>


Martin Panter added the comment:

This looks good enough to me. I would have probably avoided littering the page with too many Deprecated and Note boxes, but I can respect your and Berker?s preference to add the separate box.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25017>
_______________________________________

From report at bugs.python.org  Tue Oct 27 08:35:29 2015
From: report at bugs.python.org (Pathangi Jatinshravan)
Date: Tue, 27 Oct 2015 12:35:29 +0000
Subject: [issue25228] Regression in cookie parsing with brackets and quotes
In-Reply-To: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za>
Message-ID: <1445949329.08.0.348590880798.issue25228@psf.upfronthosting.co.za>


Pathangi Jatinshravan added the comment:

Has there been any movement on this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25228>
_______________________________________

From report at bugs.python.org  Tue Oct 27 08:43:34 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 27 Oct 2015 12:43:34 +0000
Subject: [issue23735] Readline not adjusting width after resize with 6.3
In-Reply-To: <1426984974.32.0.405944458303.issue23735@psf.upfronthosting.co.za>
Message-ID: <1445949814.81.0.0743769263813.issue23735@psf.upfronthosting.co.za>


Martin Panter added the comment:

How does this patch affect a user-defined SIGWINCH handler, or is that not really supported when Readline is in use?

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23735>
_______________________________________

From report at bugs.python.org  Tue Oct 27 09:17:21 2015
From: report at bugs.python.org (Tony R.)
Date: Tue, 27 Oct 2015 13:17:21 +0000
Subject: =?utf-8?q?=5Bissue25467=5D_Put_=E2=80=9Cdeprecated=E2=80=9D_warnings_firs?=
 =?utf-8?q?t?=
In-Reply-To: <1445891329.89.0.77643081695.issue25467@psf.upfronthosting.co.za>
Message-ID: <1156CC23-00CB-4CAA-A1E2-E055E639D171@gmail.com>


Tony R. added the comment:

> On Oct 26, 2015, at 4:28 PM, Ezio Melotti <report at bugs.python.org> wrote:
> 
> This is true, but on the other hand you might want to see the [new in 3.4] while looking at 3.6 docs and working on a program that must support Python 3.3+.  Anyway we can discuss this again once we have a patch -- depending on how it is implemented, it might be easy enough to include the tag only for functions added in the last 2 releases, or perhaps the tag won't be particularly distracting and can be used for all versions.

Smart use of CSS and a sprinkle of JavaScript could solve this.  

- Add all versions in the markup
- By default, use CSS to hide all except latest version
- Using JavaScript and a simple `localStorage` variable, save a preference to ?lower the version threshold? if desired

I tend to prefer non-JS solutions when possible, but this would only take a few lines of code.  (And of course, one `localStorage` variable along the lines of `minimumAddedInPythonVersion = ?3.2?`, or whatever.)

?Tony

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25467>
_______________________________________

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: [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 09:56:17 2015
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 27 Oct 2015 13:56:17 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1445954177.7.0.105898698739.issue25300@psf.upfronthosting.co.za>


Stefan Krah added the comment:

> The Python MPX binary will be built with ?O0 because other optimization levels will change instruction order and cause crashes, making it useful for debugging purposes.

I've trouble understanding this: Is the gcc mpx feature not stable?



Looking at the patch, we'd introduce many new macros for everyone
to learn, but I'm generally not too enthusiastic about the proliferation
of memory protection schemes after having been bitten by a bug in
FORTIFY_SOURCE memmove wrappers. :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25300>
_______________________________________

From report at bugs.python.org  Tue Oct 27 10:05:55 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Oct 2015 14:05:55 +0000
Subject: [issue25481] PermissionError in subprocess.check_output() when an
 inaccessible directory on the path
In-Reply-To: <1445848797.06.0.600636578696.issue25481@psf.upfronthosting.co.za>
Message-ID: <1445954755.45.0.788563308089.issue25481@psf.upfronthosting.co.za>


R. David Murray added the comment:

So, two interesting questions: does this in fact match the behavior of os._execvpe, and does it match the behavior of the shell?  The latter would appear to be false, and could arguably be claimed to be a bug.  If we agree that it is, we need to learn what the behavior of the shell is in a bunch of corner cases (only inaccessible directories on path, only match is accessible but not executable, etc).

If this is a bug I'd guess it applies to all supported python versions.

Note that it should be possible to reproduce this using a single user, so I've changed the title accordingly.

----------
nosy: +gps
title: PermissionError in subprocess.check_output() when running as a different user (not login shell) -> PermissionError in subprocess.check_output() when an inaccessible directory on the path

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25481>
_______________________________________

From report at bugs.python.org  Tue Oct 27 10:20:06 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Oct 2015 14:20:06 +0000
Subject: [issue25489] sys.exit() caught in exception handler
In-Reply-To: <1445945156.1.0.415307859083.issue25489@psf.upfronthosting.co.za>
Message-ID: <1445955606.49.0.568608690835.issue25489@psf.upfronthosting.co.za>


R. David Murray added the comment:

I expected this function to be parallel to sys.excepthook, but I see that sys.excepthook does not get called if you call sys.exit() at the python prompt.  So I guess I agree with you that it is surprising, although I actually expected the opposite (that sys.excepthook would get called for sys.exit).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25489>
_______________________________________

From report at bugs.python.org  Tue Oct 27 10:24:32 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Oct 2015 14:24:32 +0000
Subject: [issue25017] htmllib deprecated: Which library to use? Missing sane
 default in docs
In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za>
Message-ID: <1445955872.66.0.955532925887.issue25017@psf.upfronthosting.co.za>


R. David Murray added the comment:

The note should actually be parallel to the http one (assuming 2to3 does do the translation), rather than say "use instead", which would be incorrect advice for a python2 user :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25017>
_______________________________________

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: [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 10:43:04 2015
From: report at bugs.python.org (Brian Sutherland)
Date: Tue, 27 Oct 2015 14:43:04 +0000
Subject: [issue25489] sys.exit() caught in exception handler
In-Reply-To: <1445945156.1.0.415307859083.issue25489@psf.upfronthosting.co.za>
Message-ID: <1445956984.45.0.623051111018.issue25489@psf.upfronthosting.co.za>


Brian Sutherland added the comment:

the workaround I am using at the moment is this:

def handler(loop, context):
    print('Got error, exiting')
    loop.call_soon(sys.exit, 42)

which actually does cause the process to exit

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25489>
_______________________________________

From report at bugs.python.org  Tue Oct 27 10:53:22 2015
From: report at bugs.python.org (Christian H)
Date: Tue, 27 Oct 2015 14:53:22 +0000
Subject: [issue21998] asyncio: support fork
In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za>
Message-ID: <1445957602.2.0.0639090829299.issue21998@psf.upfronthosting.co.za>


Changes by Christian H <kalvdans at gmail.com>:


----------
nosy: +Christian H

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21998>
_______________________________________

From report at bugs.python.org  Tue Oct 27 10:59:47 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Oct 2015 14:59:47 +0000
Subject: [issue25489] sys.exit() caught in exception handler
In-Reply-To: <1445945156.1.0.415307859083.issue25489@psf.upfronthosting.co.za>
Message-ID: <1445957987.82.0.107321157913.issue25489@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, I misunderstood your report, because I didn't actually run the example.  The exception is being ignored because it is raised during a __del__ method execution.  This has nothing to do with set_exception_handler.  And in fact if you raise sys.exit in an excepthook handler it is ignored completely, so the cases are parallel in that sense.  Interestingly, if you replace your Exception in boom with sys.exit, your sys.exit in the handler actually works, because in that case the handler isn't getting called from the Task __del__.

I don't think there's a bug in python here, I think the bug is in your program.  You aren't yielding from the task, so the exception from boom only gets dealt with during Task finalization.  I find this to be the most confusing part of asyncio programming, myself.  I don't know why the handler doesn't get called just from creating the Task and running the loop. I often end up writing wrapper functions that yield from a function that does the work inside a try/except, and/or yield from the task in a 'wait_closed' method.

Maybe someone with more asyncio inside knowledge will be able to clear this up, and we can figure out a doc improvement.
I suspect we need a "best practices" document about this...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25489>
_______________________________________

From report at bugs.python.org  Tue Oct 27 11:31:49 2015
From: report at bugs.python.org (Florin Papa)
Date: Tue, 27 Oct 2015 15:31:49 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1445959909.51.0.0967819838409.issue25300@psf.upfronthosting.co.za>


Florin Papa added the comment:

Hi Stefan,

The GCC MPX feature proved stable when using O0, having tested multiple times with regrtest on Skylake, Broadwell and Haswell.

Still, this is a new feature and GCC might improve it with time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25300>
_______________________________________

From report at bugs.python.org  Tue Oct 27 11:32:17 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 27 Oct 2015 15:32:17 +0000
Subject: =?utf-8?q?=5Bissue25467=5D_Put_=E2=80=9Cdeprecated=E2=80=9D_warnings_firs?=
 =?utf-8?q?t?=
In-Reply-To: <1445621003.26.0.876373693451.issue25467@psf.upfronthosting.co.za>
Message-ID: <1445959937.27.0.146244844886.issue25467@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I would rather avoid a JS-based solution.

It should be possible to create a mixin that adds the checks for deprecated/versionadded directives among the children of the node, and then define new directives for functions/methods/classes that inherit from the existing one and the mixin.
These directives can be added to https://hg.python.org/cpython/file/tip/Doc/tools/extensions/pyspecific.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25467>
_______________________________________

From report at bugs.python.org  Tue Oct 27 11:33:15 2015
From: report at bugs.python.org (George Prekas)
Date: Tue, 27 Oct 2015 15:33:15 +0000
Subject: [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 11:55:50 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Oct 2015 15:55:50 +0000
Subject: [issue25490] small mistake in example for random.choice()
In-Reply-To: <1445953930.63.0.811107354907.issue25490@psf.upfronthosting.co.za>
Message-ID: <1445961350.26.0.470489250183.issue25490@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is no mistake. weighted_choices is a list of pairs.

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25490>
_______________________________________

From report at bugs.python.org  Tue Oct 27 11:59:29 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 27 Oct 2015 15:59:29 +0000
Subject: [issue25487] imp module DeprecationWarning in test suite
In-Reply-To: <1445906327.87.0.677600064141.issue25487@psf.upfronthosting.co.za>
Message-ID: <1445961569.63.0.286768957258.issue25487@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25487>
_______________________________________

From report at bugs.python.org  Tue Oct 27 12:05:22 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 27 Oct 2015 16:05:22 +0000
Subject: [issue25489] sys.exit() caught in exception handler
In-Reply-To: <1445945156.1.0.415307859083.issue25489@psf.upfronthosting.co.za>
Message-ID: <1445961922.5.0.43998954963.issue25489@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> because in that case the handler isn't getting called from the Task __del__

It's possible to fix -- see the attached future.patch.  And perhaps this should be fixed in Future.__del__ and Task.__del__ -- ignoring BaseExceptions isn't good.

----------
keywords: +patch
Added file: http://bugs.python.org/file40869/future.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25489>
_______________________________________

From report at bugs.python.org  Tue Oct 27 12:12:51 2015
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 27 Oct 2015 16:12:51 +0000
Subject: [issue25481] PermissionError in subprocess.check_output() when an
 inaccessible directory on the path
In-Reply-To: <1445954755.45.0.788563308089.issue25481@psf.upfronthosting.co.za>
Message-ID: <CAGE7PN+YVp1r0ZYeqAKkcp1PbChueTU1ypEQacoRVD9bE4awdQ@mail.gmail.com>


Gregory P. Smith added the comment:

Definitely a bug. The path search should silently skip directories it can't
access.

On Tue, Oct 27, 2015, 7:05 AM R. David Murray <report at bugs.python.org>
wrote:

>
> R. David Murray added the comment:
>
> So, two interesting questions: does this in fact match the behavior of
> os._execvpe, and does it match the behavior of the shell?  The latter would
> appear to be false, and could arguably be claimed to be a bug.  If we agree
> that it is, we need to learn what the behavior of the shell is in a bunch
> of corner cases (only inaccessible directories on path, only match is
> accessible but not executable, etc).
>
> If this is a bug I'd guess it applies to all supported python versions.
>
> Note that it should be possible to reproduce this using a single user, so
> I've changed the title accordingly.
>
> ----------
> nosy: +gps
> title: PermissionError in subprocess.check_output() when running as a
> different user (not login shell) -> PermissionError in
> subprocess.check_output() when an inaccessible directory on the path
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue25481>
> _______________________________________
>

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25481>
_______________________________________

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: [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 12:54:25 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Oct 2015 16:54:25 +0000
Subject: [issue25489] sys.exit() caught in exception handler
In-Reply-To: <1445945156.1.0.415307859083.issue25489@psf.upfronthosting.co.za>
Message-ID: <1445964865.55.0.709090264947.issue25489@psf.upfronthosting.co.za>


R. David Murray added the comment:

So, any exception raised in the exception handler will be re-raised via call_soon.  I think the message would be clearer if it said that (that the exception comes from the registered exception handler).

But, I'm not sure this is a good idea.  Exceptions are ignored in __del__ because they are asynchronous to the currently running code when the exception is executed (because they are triggered by garbage collection)...that is, there's no currently active statement when the exception is raised.  Just because asyncio is an async framework doesn't really change this fundamental truth (between explicit yield points, asyncio code is synchronous, that's its big attraction).

Making this change would make asyncio inconsistent with python's normal practice, and I don't (yet?) see a coherent motivation for doing so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25489>
_______________________________________

From report at bugs.python.org  Tue Oct 27 12:58:06 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Oct 2015 16:58:06 +0000
Subject: [issue25493] warnings.warn: wrong stacklevel causes import of local
 file "sys"
In-Reply-To: <1445964361.88.0.406365225673.issue25493@psf.upfronthosting.co.za>
Message-ID: <1445965086.95.0.530181554792.issue25493@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25493>
_______________________________________

From report at bugs.python.org  Tue Oct 27 13:05:48 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 27 Oct 2015 17:05:48 +0000
Subject: [issue25493] warnings.warn: wrong stacklevel causes import of local
 file "sys"
In-Reply-To: <1445964361.88.0.406365225673.issue25493@psf.upfronthosting.co.za>
Message-ID: <1445965548.59.0.838840653935.issue25493@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I'll have to dig into this to figure out what's going on, but since the sys module is built into Python it makes it so import won't accidentally import some file named sys. the real question is who thinks the 'sys' file should be considered.

----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25493>
_______________________________________

From report at bugs.python.org  Tue Oct 27 13:06:58 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 27 Oct 2015 17:06:58 +0000
Subject: [issue25483] Improve f-string implementation: FORMAT_VALUE opcode
In-Reply-To: <1445874299.22.0.773155754186.issue25483@psf.upfronthosting.co.za>
Message-ID: <1445965618.6.0.350353642958.issue25483@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25483>
_______________________________________

From report at bugs.python.org  Tue Oct 27 13:07:42 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 27 Oct 2015 17:07:42 +0000
Subject: [issue25479] Increase unit test coverage for abc.py
In-Reply-To: <1445829241.77.0.00855893760535.issue25479@psf.upfronthosting.co.za>
Message-ID: <1445965662.88.0.62102599782.issue25479@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25479>
_______________________________________

From report at bugs.python.org  Tue Oct 27 13:23:19 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 27 Oct 2015 17:23:19 +0000
Subject: [issue25489] sys.exit() caught in exception handler
In-Reply-To: <1445945156.1.0.415307859083.issue25489@psf.upfronthosting.co.za>
Message-ID: <1445966599.72.0.945640673342.issue25489@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

I see your points, but we're talking about BaseExceptions here -- KeyboardInterrupt, SystemExit etc.  Those things usually mean that the program has to crash.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25489>
_______________________________________

From report at bugs.python.org  Tue Oct 27 13:25:27 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 27 Oct 2015 17:25:27 +0000
Subject: [issue25489] sys.exit() caught in exception handler
In-Reply-To: <1445945156.1.0.415307859083.issue25489@psf.upfronthosting.co.za>
Message-ID: <1445966727.14.0.325166314193.issue25489@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Trapping those exceptions in __del__ isn't good.

Another way to address this would be to at least modify call_exception_handler to log when an exception handler raises a BaseException error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25489>
_______________________________________

From report at bugs.python.org  Tue Oct 27 13:28:43 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Oct 2015 17:28:43 +0000
Subject: [issue25489] sys.exit() caught in exception handler
In-Reply-To: <1445945156.1.0.415307859083.issue25489@psf.upfronthosting.co.za>
Message-ID: <1445966923.42.0.243065771334.issue25489@psf.upfronthosting.co.za>


R. David Murray added the comment:

No, you are talking about *all* exceptions, since they all descend from BaseException.  Python's normal __del__ handling just prints the ignored exception to stdout, even if it is a BaseException.  Why should asyncio be different (other than logging it instead, which would be useful)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25489>
_______________________________________

From report at bugs.python.org  Tue Oct 27 13:33:32 2015
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 27 Oct 2015 17:33:32 +0000
Subject: [issue25492] subprocess with redirection fails after FreeConsole
In-Reply-To: <1445959994.99.0.328533880523.issue25492@psf.upfronthosting.co.za>
Message-ID: <1445967212.83.0.458885417123.issue25492@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
components: +Windows
nosy: +eryksun, paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25492>
_______________________________________

From report at bugs.python.org  Tue Oct 27 13:34:26 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 27 Oct 2015 17:34:26 +0000
Subject: [issue25493] warnings.warn: wrong stacklevel causes import of local
 file "sys"
In-Reply-To: <1445964361.88.0.406365225673.issue25493@psf.upfronthosting.co.za>
Message-ID: <1445967266.2.0.279053271359.issue25493@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25493>
_______________________________________

From report at bugs.python.org  Tue Oct 27 13:37:28 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 27 Oct 2015 17:37:28 +0000
Subject: [issue25489] sys.exit() caught in exception handler
In-Reply-To: <1445945156.1.0.415307859083.issue25489@psf.upfronthosting.co.za>
Message-ID: <1445967448.69.0.27630794002.issue25489@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> No, you are talking about *all* exceptions, since they all descend from BaseException.  Python's normal __del__ handling just prints the ignored exception to stdout, even if it is a BaseException.  Why should asyncio be different (other than logging it instead, which would be useful)?

My bad -- my current patch does indeed re-raise all exceptions.  But would you be OK with something like this:

        def __del__():
            ...

            try:
                self._loop.call_exception_handler(context)
            except Exception as ex:
                # log or re-raise
                logger.log(...)
            except BaseException as ex:
                logger.error(
                    'BaseException in Future.__del__, will be re-raised soon',
                    exc_info=True)
                def throw():
                    raise ex
                self._loop.call_soon(throw)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25489>
_______________________________________

From report at bugs.python.org  Tue Oct 27 13:44:49 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Oct 2015 17:44:49 +0000
Subject: [issue25489] sys.exit() caught in exception handler
In-Reply-To: <1445945156.1.0.415307859083.issue25489@psf.upfronthosting.co.za>
Message-ID: <1445967889.53.0.788170647893.issue25489@psf.upfronthosting.co.za>


R. David Murray added the comment:

Not until you convince me there is a reason for deviating from Python's normal __del__ handling :)  (Or other asyncio developers agree with you and not me.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25489>
_______________________________________

From report at bugs.python.org  Tue Oct 27 14:29:31 2015
From: report at bugs.python.org (Eric Price)
Date: Tue, 27 Oct 2015 18:29:31 +0000
Subject: [issue23735] Readline not adjusting width after resize with 6.3
In-Reply-To: <1426984974.32.0.405944458303.issue23735@psf.upfronthosting.co.za>
Message-ID: <1445970571.91.0.800556223044.issue23735@psf.upfronthosting.co.za>


Eric Price added the comment:

SIGWINCH handler for readline.  Fixed indentation issues.

----------
Added file: http://bugs.python.org/file40870/rl_sigwinch_update.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23735>
_______________________________________

From report at bugs.python.org  Tue Oct 27 14:29:55 2015
From: report at bugs.python.org (Eric Price)
Date: Tue, 27 Oct 2015 18:29:55 +0000
Subject: [issue23735] Readline not adjusting width after resize with 6.3
In-Reply-To: <1426984974.32.0.405944458303.issue23735@psf.upfronthosting.co.za>
Message-ID: <1445970595.66.0.577619942404.issue23735@psf.upfronthosting.co.za>


Changes by Eric Price <ecprice at gmail.com>:


Removed file: http://bugs.python.org/file40844/rl_sigwinch_update.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23735>
_______________________________________

From report at bugs.python.org  Tue Oct 27 14:36:14 2015
From: report at bugs.python.org (Eric Price)
Date: Tue, 27 Oct 2015 18:36:14 +0000
Subject: [issue23735] Readline not adjusting width after resize with 6.3
In-Reply-To: <1426984974.32.0.405944458303.issue23735@psf.upfronthosting.co.za>
Message-ID: <1445970974.87.0.587267153035.issue23735@psf.upfronthosting.co.za>


Eric Price added the comment:

At the moment, it just overwrites any existing SIGWINCH handler.

I don't know how to do anything better -- one could try to store an existing SIGWINCH handler and call it, but it still wouldn't really work for an application that wanted to add and remove handlers.  I think such applications are rare, though -- readline mucks with the terminal in various ways, so it's unlikely that other applications will also muck with the terminal and expect to be compatible with it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23735>
_______________________________________

From report at bugs.python.org  Tue Oct 27 15:41:56 2015
From: report at bugs.python.org (Mark Roseman)
Date: Tue, 27 Oct 2015 19:41:56 +0000
Subject: [issue8231] Unable to run IDLE without write-access to home directory
In-Reply-To: <1269531569.44.0.352644957859.issue8231@psf.upfronthosting.co.za>
Message-ID: <1445974916.09.0.732809767875.issue8231@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Can I suggest that this issue continues to be about IDLE not being able to write its preferences directory/files due to permissions, and we create a new issue for the fact that IDLE is storing it in the wrong place under Windows?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8231>
_______________________________________

From report at bugs.python.org  Tue Oct 27 16:41:58 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 27 Oct 2015 20:41:58 +0000
Subject: [issue25017] htmllib deprecated: Which library to use? Missing sane
 default in docs
In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za>
Message-ID: <1445978518.71.0.7314340036.issue25017@psf.upfronthosting.co.za>


Martin Panter added the comment:

Not quite. This is a two-step deprecation:

1. ?htmllib? is removed in favour of HTMLParser. The API is different, so no automatic 2to3 change would be practical.

2. HTMLParser is renamed to ?html.parser?, and 2to3 handles this. This is already documented at <https://docs.python.org/2/library/htmlparser.html>.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25017>
_______________________________________

From report at bugs.python.org  Tue Oct 27 17:07:41 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Oct 2015 21:07:41 +0000
Subject: [issue25493] warnings.warn: wrong stacklevel causes import of local
 file "sys"
In-Reply-To: <1445964361.88.0.406365225673.issue25493@psf.upfronthosting.co.za>
Message-ID: <1445980061.94.0.0140534359115.issue25493@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The "sys" file is not imported. It is read by linecache.

warnings.warn() tries to determine the file name by looking at __file__ in module's globals. If it fails, it falls back to the module name. Definitely it fails also for builtin modules, binary extensions and zipimported modules.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25493>
_______________________________________

From report at bugs.python.org  Tue Oct 27 17:26:22 2015
From: report at bugs.python.org (Stefano Mazzucco)
Date: Tue, 27 Oct 2015 21:26:22 +0000
Subject: [issue1117601] os.path.exists returns false negatives in MAC
 environments.
Message-ID: <1445981182.47.0.254691020083.issue1117601@psf.upfronthosting.co.za>


Stefano Mazzucco added the comment:

FWIW, I have just been experiencing this on CentOS 6.5 with Python 2.7.5 (sorry).

I could make the Python code happy by running chcon[1] with the correct context type, otherwise os.path.exists would happily return False for a file that actually existed.


[1] https://fedoraproject.org/wiki/SELinux/chcon

----------
nosy: +stefano-m

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1117601>
_______________________________________

From report at bugs.python.org  Tue Oct 27 17:40:28 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Oct 2015 21:40:28 +0000
Subject: [issue25017] htmllib deprecated: Which library to use? Missing sane
 default in docs
In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za>
Message-ID: <1445982028.47.0.660136645339.issue25017@psf.upfronthosting.co.za>


R. David Murray added the comment:

OK, then the note should be dropped.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25017>
_______________________________________

From report at bugs.python.org  Tue Oct 27 17:42:57 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Oct 2015 21:42:57 +0000
Subject: [issue25493] warnings.warn: wrong stacklevel causes import of local
 file "sys"
In-Reply-To: <1445964361.88.0.406365225673.issue25493@psf.upfronthosting.co.za>
Message-ID: <1445982177.04.0.939337513026.issue25493@psf.upfronthosting.co.za>


R. David Murray added the comment:

Hmm.  I remember fixing problems with linecache and inspect.  I wonder if this is a variation on that?  I don't remember the issue number.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25493>
_______________________________________

From report at bugs.python.org  Tue Oct 27 17:46:26 2015
From: report at bugs.python.org (augustin rieunier)
Date: Tue, 27 Oct 2015 21:46:26 +0000
Subject: [issue25470] Random Malloc error raised
In-Reply-To: <1445695572.21.0.810479855368.issue25470@psf.upfronthosting.co.za>
Message-ID: <1445982386.9.0.83132898052.issue25470@psf.upfronthosting.co.za>


augustin rieunier added the comment:

I should be able to reproduce it yes.
Can't really give the code, as it's in a big program i'm working on, and it's never at the same place ..
One thing though: it never happened on QA/UAT environments. So it might be linked to something (libs, programs) on my dev environment.

Will update this with gdb data when I have some time :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25470>
_______________________________________

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: [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 18:02:23 2015
From: report at bugs.python.org (John Mark Vandenberg)
Date: Tue, 27 Oct 2015 22:02:23 +0000
Subject: [issue25494] Four quotes used to begin docstring
In-Reply-To: <1445982538.24.0.273551712863.issue25494@psf.upfronthosting.co.za>
Message-ID: <1445983343.86.0.082492713413.issue25494@psf.upfronthosting.co.za>


John Mark Vandenberg added the comment:

The additional quotation mark is shown in help()

>>> help(statistics.median_grouped)
Help on function median_grouped in module statistics:

median_grouped(data, interval=1)
    "Return the 50th percentile (median) of grouped continuous data.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25494>
_______________________________________

From report at bugs.python.org  Tue Oct 27 18:12:56 2015
From: report at bugs.python.org (Camilla Montonen)
Date: Tue, 27 Oct 2015 22:12:56 +0000
Subject: [issue6860] Inconsistent naming of custom command in setup.py help
 output
In-Reply-To: <1252372114.27.0.565813299947.issue6860@psf.upfronthosting.co.za>
Message-ID: <1445983976.64.0.0345060710088.issue6860@psf.upfronthosting.co.za>


Camilla Montonen added the comment:

This is still an issue in Python 3.4.3, but I believe the relevant documentation has been changed already to alert users to the fact that the class name and the command name should be the same. 

Quoting from: https://docs.python.org/3/distutils/apiref.html#module-distutils.command

Copy this file to a new module with the same name as the new command you?re implementing. This module should implement a class with the same name as the module (and the command). So, for instance, to create the command peel_banana (so that users can run setup.py peel_banana), you?d copy command_template to distutils/command/peel_banana.py, then edit it so that it?s implementing the class peel_banana, a subclass of distutils.cmd.Command.


Following this documentation, a user would not implement a custom command class called 'TestClass' with a command called 'test'.

----------
nosy: +Winterflower

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6860>
_______________________________________

From report at bugs.python.org  Tue Oct 27 18:15:22 2015
From: report at bugs.python.org (Camilla Montonen)
Date: Tue, 27 Oct 2015 22:15:22 +0000
Subject: [issue6860] Inconsistent naming of custom command in setup.py help
 output
In-Reply-To: <1252372114.27.0.565813299947.issue6860@psf.upfronthosting.co.za>
Message-ID: <1445984122.15.0.872151151831.issue6860@psf.upfronthosting.co.za>


Camilla Montonen added the comment:

Apologies, I should have clarified:
I can still replicate the bug in the original post, but I no longer believe this is an issue, because the wording in the documentation has been changed 
for Python 2.X https://docs.python.org/2/distutils/apiref.html#creating-a-new-distutils-command

and for Python 3.X
https://docs.python.org/3/distutils/apiref.html#creating-a-new-distutils-command

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6860>
_______________________________________

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: [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  Tue Oct 27 20:09:08 2015
From: report at bugs.python.org (eryksun)
Date: Wed, 28 Oct 2015 00:09:08 +0000
Subject: [issue25492] subprocess with redirection fails after FreeConsole
In-Reply-To: <1445959994.99.0.328533880523.issue25492@psf.upfronthosting.co.za>
Message-ID: <1445990947.99.0.167753551951.issue25492@psf.upfronthosting.co.za>


eryksun added the comment:

For me, fails() lives up to its name in Windows 7, but it doesn't fail in Windows 10. It shouldn't fail in Windows 8, either. 

In Windows 8+ the console interface is implemented using a kernel device. Console handles reference virtual files on the ConDrv device, such as Connect, Input, and Output. The example doesn't fail because the I/O handles (Input and Output) are valid even if the main console handle (Connect) has been closed by calling FreeConsole. 

OTOH, prior to Windows 8, console I/O handles don't reference kernel objects. You may have noticed that the old API tags the values by setting the lower 2 bits (e.g. 3, 7, 11). This enables redirecting actions on console I/O handles to functions in the console host process (i.e. conhost.exe in Win 7, and csrss.exe in XP/Vista). For example, for a regular kernel object, the DuplicateHandle API is serviced by the system call NtDuplicateObject. But for a console handle, Windows instead sends the request to the console LPC port, to be dispatched to SrvDuplicateHandle in the console. Obviously this can't work after the client has called FreeConsole. 

Prior to Windows 8, this invalid-handle error can also be the result of running pythonw.exe from a console application such as python.exe or cmd.exe. See issue 3905. In this case Windows is copying the values of the parent's standard handles into the pythonw.exe process parameters, but they're meaningless values since pythonw.exe doesn't attach to a console automatically. (You could of course manually call AllocConsole or AttachConsole.) The new implementation in Windows 8 and 10 is smart enough to initialize the standard handles to 0 in this case. Thus in Windows 10 Terry's example in msg220218 doesn't raise and exception, and p.stdout.read() == b'32\r\n'.

A workaround for Python 3.4+ on older Windows versions would be to check os.get_handle_inheritable, which calls WinAPI GetHandleInformation [1]:

    ERROR_INVALID_HANDLE = 0x0006

    if stdin is None:
        p2cread = _winapi.GetStdHandle(_winapi.STD_INPUT_HANDLE)
        try:
            os.get_handle_inheritable(p2cread)
        except OSError as e:
            if e.winerror != ERROR_INVALID_HANDLE:
                raise
            p2cread = None
        if p2cread is None:
            p2cread, _ = _winapi.CreatePipe(None, 0)
            p2cread = Handle(p2cread)
            _winapi.CloseHandle(_)

For 2.7, GetHandleInformation could be added to _subprocess. But then it may as well be added to Python 3's _winapi as well. 

[1]: https://msdn.microsoft.com/en-us/library/ms724329

----------
versions: +Python 3.4, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25492>
_______________________________________

From report at bugs.python.org  Tue Oct 27 20:15:29 2015
From: report at bugs.python.org (eryksun)
Date: Wed, 28 Oct 2015 00:15:29 +0000
Subject: [issue25492] subprocess with redirection fails after FreeConsole
In-Reply-To: <1445959994.99.0.328533880523.issue25492@psf.upfronthosting.co.za>
Message-ID: <1445991329.1.0.497567530853.issue25492@psf.upfronthosting.co.za>


eryksun added the comment:

I forgot to first check whether p2cread is None:

    ERROR_INVALID_HANDLE = 0x0006
    
    if stdin is None:
        p2cread = _winapi.GetStdHandle(_winapi.STD_INPUT_HANDLE)
        if p2cread is not None:
            try:
                os.get_handle_inheritable(p2cread)
            except OSError as e:
                if e.winerror != ERROR_INVALID_HANDLE:
                    raise
                p2cread = None
        if p2cread is None:
            p2cread, _ = _winapi.CreatePipe(None, 0)
            p2cread = Handle(p2cread)
            _winapi.CloseHandle(_)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25492>
_______________________________________

From report at bugs.python.org  Tue Oct 27 20:39:28 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 28 Oct 2015 00:39:28 +0000
Subject: [issue8231] Unable to run IDLE without write-access to home directory
In-Reply-To: <1269531569.44.0.352644957859.issue8231@psf.upfronthosting.co.za>
Message-ID: <1445992768.65.0.544562716879.issue8231@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Yes, that is what this issue *is* about.  IDLE, like Python itself, expects to be run on machines that users can write to normally, that have not been crippled by bureaucratic policies, or by users. The editor is useless if the user cannot write files somewhere.  None of this is specific to Windows.

Ned's idea of a temporary directory seems easy.  Change the warning and replace'raise SystemExit' with 'td = tempfile.TemporaryDirectory(); userDir = td.name' (see msg222694).  For 2.7, however, TemporayDirectory is not available. For the underlying mkdtemp, the user "is responsible for deleting the temporary directory and its contents when done with it."  (I presume failure of apps to do this is why temp file cleanup is needed.)  My inclination for 2.7 would be to copy a stripped down copy of TemporaryDirectory with just the finalizer code.  In fact, since we do not need or want the implicit cleanup warning (do we?), we could do that for all versions.

We do not have to accommodate all possibilities. One report, possibly on Stackoverflow, was from a user whose home dir and, I presume, appdata dir, were on a remote server.  Maybe he also had an offline home dir, I don't remember.  In any case, IDLE was not happy with the setup.

As I said before, permanently and unconditionally moving user config files on Windows will break compatibility with all previous releases, so I would not do that unless we decide to break compatibility anyway, for reasons other than MS's recommendations.  However, after a general solution is applied we could consider in a separate issue using Appdata as future-looking, Windows-specific alternative to a temporary directory.  However, this would require careful though lest we end up with two userdirs because the non-writability of homedir is only temporary.

----------
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8231>
_______________________________________

From report at bugs.python.org  Tue Oct 27 20:44:45 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 28 Oct 2015 00:44:45 +0000
Subject: [issue25489] sys.exit() caught in exception handler
In-Reply-To: <1445945156.1.0.415307859083.issue25489@psf.upfronthosting.co.za>
Message-ID: <1445993084.99.0.904919481148.issue25489@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Whew. Complex issue!

The OP should probably use his workaround or call loop.stop() instead of raising SystemExit.

Asyncio in general is rather careless about "true" BaseExceptions (i.e. that aren't also Exceptions), we should decide what we want to do for these (there are definitely ways to get in a bad state if you catch one and then resume the loop).

call_exception_handler() tries to log and then ignore exceptions raised by the handler, so the except clause Yuri's patch adds to __del__ in fact will only see true BaseExceptions.

Adding an except clause to __del__ seems very unprincipled -- there's another __del__ that would require the same treatment (all our __del__ methods seem to call call_exception_handler()) and *if* we want to catch it we should probably do it in call_exception_handler().

boom() does in fact yield.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25489>
_______________________________________

From report at bugs.python.org  Tue Oct 27 20:52:04 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Oct 2015 00:52:04 +0000
Subject: [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1445993524.75.0.0352164006805.issue25495@psf.upfronthosting.co.za>


R. David Murray added the comment:

I agree that the documentation is not optimal.  To give you some background, binascii was primarily implemented to support the email module, and the standard it is referring to is in fact the MIME standard that references base64 (I believe at the time the independent base64 standard did not exist).  The number 57 is derived from the fact that 57 * 4/3 = 76; that is, input data of length 57 will result in an encoded line that is equal to the maximum recommended line length.  Thus in encoding an email the email package (originally, it no longer does this) passed the data in in 57 byte chunks and appended the resulting lines to the output buffer.

So, this documentation is historically correct, but no longer particularly useful.  Suggested improvements are welcome.  

This state of affairs exists because the binascii module doesn't really have a current maintainer. Someday I'd love to have enough time to pick it up, since I maintain email and it is still used by email (and could be used better, with some module improvements).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25495>
_______________________________________

From report at bugs.python.org  Tue Oct 27 20:52:19 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 28 Oct 2015 00:52:19 +0000
Subject: [issue25454] operator.methodcaller should accept additional arguments
 during the call
In-Reply-To: <1445453619.22.0.222588930326.issue25454@psf.upfronthosting.co.za>
Message-ID: <1445993539.24.0.881311499046.issue25454@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

I could see the argument for this to make methodcaller more like an unbound version of functools.partial. Partial lets you prebind some things and not others, you might want to do the same thing with methods, where you prebind the method name and some arguments, but dynamically bind the instance and some additional arguments.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25454>
_______________________________________

From report at bugs.python.org  Tue Oct 27 21:21:05 2015
From: report at bugs.python.org (Emanuel Barry)
Date: Wed, 28 Oct 2015 01:21:05 +0000
Subject: [issue25494] Four quotes used to begin docstring
In-Reply-To: <1445982538.24.0.273551712863.issue25494@psf.upfronthosting.co.za>
Message-ID: <1445995265.64.0.593460356816.issue25494@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

I don't know why you believe docstrings are programmatically linked to the library reference...

Here is the file that is used to make the online documentation: https://hg.python.org/cpython/file/tip/Doc/library/statistics.rst

----------
nosy: +ebarry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25494>
_______________________________________

From report at bugs.python.org  Tue Oct 27 21:35:27 2015
From: report at bugs.python.org (John Mark Vandenberg)
Date: Wed, 28 Oct 2015 01:35:27 +0000
Subject: [issue25494] Four quotes used to begin docstring
In-Reply-To: <1445982538.24.0.273551712863.issue25494@psf.upfronthosting.co.za>
Message-ID: <1445996127.4.0.042917931607.issue25494@psf.upfronthosting.co.za>


John Mark Vandenberg added the comment:

Thank you for clarifying that.
Does that mean that this issue should not be assigned to docs at python and should not have a Component of 'Documentation'?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25494>
_______________________________________

From report at bugs.python.org  Tue Oct 27 22:14:58 2015
From: report at bugs.python.org (Emanuel Barry)
Date: Wed, 28 Oct 2015 02:14:58 +0000
Subject: [issue25494] Four quotes used to begin docstring
In-Reply-To: <1445982538.24.0.273551712863.issue25494@psf.upfronthosting.co.za>
Message-ID: <1445998498.23.0.928469184408.issue25494@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

It probably shouldn't be assigned to docs at python, but it's still a typo in the source code, so it should probably be under Library anyway.

LGTM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25494>
_______________________________________

From report at bugs.python.org  Tue Oct 27 23:06:07 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Oct 2015 03:06:07 +0000
Subject: [issue25494] Four quotes used to begin docstring
In-Reply-To: <1445982538.24.0.273551712863.issue25494@psf.upfronthosting.co.za>
Message-ID: <20151028030603.24889.75342@psf.io>


Roundup Robot added the comment:

New changeset 041701817c5d by Zachary Ware in branch '3.4':
Issue #25494: Remove extra quote from docstring.
https://hg.python.org/cpython/rev/041701817c5d

New changeset 2dd97ad96021 by Zachary Ware in branch '3.5':
Issue #25494: Merge with 3.4
https://hg.python.org/cpython/rev/2dd97ad96021

New changeset d9bb7a3ed51e by Zachary Ware in branch 'default':
Closes #25494: Merge with 3.5
https://hg.python.org/cpython/rev/d9bb7a3ed51e

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25494>
_______________________________________

From report at bugs.python.org  Tue Oct 27 23:07:32 2015
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 28 Oct 2015 03:07:32 +0000
Subject: [issue25494] Four quotes used to begin docstring
In-Reply-To: <1445982538.24.0.273551712863.issue25494@psf.upfronthosting.co.za>
Message-ID: <1446001652.54.0.0274284099509.issue25494@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Documentation is fine for docstrings, it gets the attention of the docs@ list.  Library is also fine, since the change actually goes in Lib/.  Both is most correct :)

Thanks for the report and patch!

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25494>
_______________________________________

From report at bugs.python.org  Tue Oct 27 23:31:02 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 28 Oct 2015 03:31:02 +0000
Subject: [issue25454] operator.methodcaller should accept additional arguments
 during the call
In-Reply-To: <1445453619.22.0.222588930326.issue25454@psf.upfronthosting.co.za>
Message-ID: <1446003062.54.0.0390266700286.issue25454@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I would rather leave lambda or plain function definitions as the way to handle any cases not covered by itergetter, attrgettr, and methodcaller.   It feels like we're working way too hard to produce more ways to do it.   

Also, the suggested use cases with all() and map() would likely be expressed more cleanly (and readably) with a list comprehension.  The reduce() example isn't clear at all (that is part of the reason it was banished to the functools module).  I would not want to encounter any of the examples during a debugging session.

I think we should decline this feature request as being "a bridge too far" and not what the zen-of-python would encourage us to do.  I can't think of any existing code that would be improved by the availability of this extension.  Instead, we ought to focus on making the core language as expressive as possible.

----------
assignee:  -> rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25454>
_______________________________________

From report at bugs.python.org  Tue Oct 27 23:32:23 2015
From: report at bugs.python.org (Nan Wu)
Date: Wed, 28 Oct 2015 03:32:23 +0000
Subject: [issue25439] Add type checks to urllib.request.Request
In-Reply-To: <1445247083.91.0.927080887762.issue25439@psf.upfronthosting.co.za>
Message-ID: <1446003143.54.0.385756906835.issue25439@psf.upfronthosting.co.za>


Nan Wu added the comment:

The do_request_() method which is defined in AbstractHTTPHandler seems not cover the check at least for the first case Ezio brought up. `unknown_open` has been called and gives out a relatively confusing message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25439>
_______________________________________

From report at bugs.python.org  Wed Oct 28 00:26:56 2015
From: report at bugs.python.org (Nan Wu)
Date: Wed, 28 Oct 2015 04:26:56 +0000
Subject: [issue25439] Add type checks to urllib.request.Request
In-Reply-To: <1445247083.91.0.927080887762.issue25439@psf.upfronthosting.co.za>
Message-ID: <1446006416.86.0.912388791951.issue25439@psf.upfronthosting.co.za>


Nan Wu added the comment:

Will fix the other two issues. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25439>
_______________________________________

From report at bugs.python.org  Wed Oct 28 01:07:07 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 28 Oct 2015 05:07:07 +0000
Subject: [issue25439] Add type checks to urllib.request.Request
In-Reply-To: <1445247083.91.0.927080887762.issue25439@psf.upfronthosting.co.za>
Message-ID: <1446008827.95.0.294688126287.issue25439@psf.upfronthosting.co.za>


Martin Panter added the comment:

I meant removing one of the checks in AbstractHTTPHandler.do_request_(). I left a note in the review at the relevant line.

One more thing I forgot to mention, although I am afraid it is 90% nit picking the dict iterable check. For the ?http:? scheme, an iterable of ?bytes-like? objects is supported (again not documented though). For HTTPS (over SSL), not every bytes-like object is supported, but common ones like bytearray() still work I think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25439>
_______________________________________

From report at bugs.python.org  Wed Oct 28 02:36:03 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 28 Oct 2015 06:36:03 +0000
Subject: [issue8231] Unable to run IDLE without write-access to home directory
In-Reply-To: <1269531569.44.0.352644957859.issue8231@psf.upfronthosting.co.za>
Message-ID: <1446014163.16.0.0786848923129.issue8231@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Attached is a patch that I think will work.  I have not tested it because I do not know how to make my home directory, and only my home directory, read-only.

Brian, how did you do it?  I now have Win 10.

When I rt click user/terry and select properties, there is a tri-state box "[ ] Read-only (Only applies to files in folder)".  It initially has a solid square, and changes to blank and checkmark.  Try to apply, there is an unselectable grayed-out choice to apply to the directory only and a mandatory choice to also apply recursively to all files and subdirectories.  I am loath to do this since there are 47000 files (40000 in appdate, which seems grossly excessive, but that is the report)

I would like this tested anyway at least once on linux and mac.  Testing procedure: change name of .idlerc, lock home dir, run installed IDLE from command line.  Should exit with message.  Run patched repository IDLE.  Should run, reporting temp dir and deleting it on exit.  (Unlock home dir and rename .idlerc back).

----------
keywords: +patch
Added file: http://bugs.python.org/file40872/@cfgdir.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8231>
_______________________________________

From report at bugs.python.org  Wed Oct 28 02:57:03 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 28 Oct 2015 06:57:03 +0000
Subject: [issue25432] isinstance documentation: explain behavior when type is
 a tuple
In-Reply-To: <1445093164.36.0.718439234598.issue25432@psf.upfronthosting.co.za>
Message-ID: <1446015423.47.0.147584529353.issue25432@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Doing this now.

----------
assignee: docs at python -> terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25432>
_______________________________________

From report at bugs.python.org  Wed Oct 28 03:16:05 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Oct 2015 07:16:05 +0000
Subject: [issue25432] isinstance documentation: explain behavior when type is
 a tuple
In-Reply-To: <1445093164.36.0.718439234598.issue25432@psf.upfronthosting.co.za>
Message-ID: <20151028071602.21949.27018@psf.io>


Roundup Robot added the comment:

New changeset aaf8a25133ff by Terry Jan Reedy in branch '2.7':
Issue #25432: Explain isinstance behaviour when type is a tuple.
https://hg.python.org/cpython/rev/aaf8a25133ff

New changeset 8b1418e5dcc8 by Terry Jan Reedy in branch '3.4':
Issue #25432: Explain isinstance behaviour when type is a tuple.
https://hg.python.org/cpython/rev/8b1418e5dcc8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25432>
_______________________________________

From report at bugs.python.org  Wed Oct 28 03:16:54 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 28 Oct 2015 07:16:54 +0000
Subject: [issue25432] isinstance documentation: explain behavior when type is
 a tuple
In-Reply-To: <1445093164.36.0.718439234598.issue25432@psf.upfronthosting.co.za>
Message-ID: <1446016614.04.0.984573530599.issue25432@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25432>
_______________________________________

From report at bugs.python.org  Wed Oct 28 04:27:28 2015
From: report at bugs.python.org (Sworddragon)
Date: Wed, 28 Oct 2015 08:27:28 +0000
Subject: [issue19628] maxlevels -1 on compileall for unlimited recursion
In-Reply-To: <1384634450.77.0.212426893492.issue19628@psf.upfronthosting.co.za>
Message-ID: <1446020848.95.0.981636217298.issue19628@psf.upfronthosting.co.za>


Sworddragon added the comment:

I'm wondering what the recursion limit is if -l and -r are not given. Does it default to 10 too or is there no limit? If the first is the case maybe this should also get documented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19628>
_______________________________________

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: [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 04:43:16 2015
From: report at bugs.python.org (John Mark Vandenberg)
Date: Wed, 28 Oct 2015 08:43:16 +0000
Subject: [issue21827] textwrap.dedent() fails when largest common whitespace
 is a substring of smallest leading whitespace
In-Reply-To: <1403455487.85.0.474137406062.issue21827@psf.upfronthosting.co.za>
Message-ID: <1446021796.67.0.287153053806.issue21827@psf.upfronthosting.co.za>


John Mark Vandenberg added the comment:

Not surprising also occurs on Python 3.2, 3.3, & 3.6.
I'm not sure whether fixes like this are suitable to be merged into 3.2/3.3.(is there a document describing this?)

----------
nosy: +John.Mark.Vandenberg
versions: +Python 3.2, Python 3.3, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21827>
_______________________________________

From report at bugs.python.org  Wed Oct 28 05:09:55 2015
From: report at bugs.python.org (Brian Sutherland)
Date: Wed, 28 Oct 2015 09:09:55 +0000
Subject: [issue25489] sys.exit() caught in exception handler
In-Reply-To: <1445945156.1.0.415307859083.issue25489@psf.upfronthosting.co.za>
Message-ID: <1446023395.03.0.913080829015.issue25489@psf.upfronthosting.co.za>


Brian Sutherland added the comment:

Calling loop.stop() means that I need other, more complex code, to store and return the non-zero exit status.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25489>
_______________________________________

From report at bugs.python.org  Wed Oct 28 05:41:33 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 28 Oct 2015 09:41:33 +0000
Subject: [issue25496] Default value for compresslevel is not documented
In-Reply-To: <1446021567.06.0.820338275323.issue25496@psf.upfronthosting.co.za>
Message-ID: <1446025293.37.0.0193821893871.issue25496@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
keywords: +easy
nosy: +berker.peksag, docs at python
stage:  -> needs patch
versions: +Python 3.4, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25496>
_______________________________________

From report at bugs.python.org  Wed Oct 28 06:05:17 2015
From: report at bugs.python.org (Mark Summerfield)
Date: Wed, 28 Oct 2015 10:05:17 +0000
Subject: [issue20607] multiprocessing cx_Freeze windows GUI bug (& easy fixes)
In-Reply-To: <1392210007.55.0.703344543531.issue20607@psf.upfronthosting.co.za>
Message-ID: <1446026717.61.0.420456351272.issue20607@psf.upfronthosting.co.za>


Mark Summerfield added the comment:

I've now signed the contributor agreement.

However, with Python 3.4 I don't seem to get the same problem anymore even though there are a few places in the code where sys.std{err,out} are used without if ... is not None guards.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20607>
_______________________________________

From report at bugs.python.org  Wed Oct 28 06:58:37 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 28 Oct 2015 10:58:37 +0000
Subject: [issue25482] signal.set_wakeup_fd() doesn't work if the signal don't
 have handler
In-Reply-To: <1445859296.06.0.537058365711.issue25482@psf.upfronthosting.co.za>
Message-ID: <1446029917.5.0.249147152147.issue25482@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25482>
_______________________________________

From report at bugs.python.org  Wed Oct 28 07:04:14 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 28 Oct 2015 11:04:14 +0000
Subject: [issue21827] textwrap.dedent() fails when largest common whitespace
 is a substring of smallest leading whitespace
In-Reply-To: <1403455487.85.0.474137406062.issue21827@psf.upfronthosting.co.za>
Message-ID: <1446030254.09.0.150519094345.issue21827@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM. But the implementation can be more efficient. Here is optimized patch.

34e88a05562f.diff:
$ ./python -m timeit -s 'import textwrap; s = "{0} x\n{0}\tx\n".format(" "*100)' -- 'textwrap.dedent(s)'
10000 loops, best of 3: 87.5 usec per loop
$ ./python -m timeit -s 'import textwrap; s = "{0} x\n{0}\tx\n".format(" "*1000)' -- 'textwrap.dedent(s)'
1000 loops, best of 3: 780 usec per loop

issue21827.patch:
$ ./python -m timeit -s 'import textwrap; s = "{0} x\n{0}\tx\n".format(" "*100)' -- 'textwrap.dedent(s)'
10000 loops, best of 3: 51 usec per loop
$ ./python -m timeit -s 'import textwrap; s = "{0} x\n{0}\tx\n".format(" "*1000)' -- 'textwrap.dedent(s)'
1000 loops, best of 3: 395 usec per loop

----------
nosy: +serhiy.storchaka
stage: needs patch -> patch review
versions:  -Python 3.2, Python 3.3
Added file: http://bugs.python.org/file40873/issue21827.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21827>
_______________________________________

From report at bugs.python.org  Wed Oct 28 08:10:13 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 28 Oct 2015 12:10:13 +0000
Subject: [issue25485] Add a context manager to telnetlib.Telnet
In-Reply-To: <1445883619.21.0.032521861016.issue25485@psf.upfronthosting.co.za>
Message-ID: <1446034213.22.0.400282414173.issue25485@psf.upfronthosting.co.za>


Berker Peksag added the comment:

This seems like a reasonable request to me.

See https://docs.python.org/devguide/ to learn how to contribute to Python.

----------
nosy: +berker.peksag
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25485>
_______________________________________

From report at bugs.python.org  Wed Oct 28 09:36:07 2015
From: report at bugs.python.org (Gustavo J. A. M. Carneiro)
Date: Wed, 28 Oct 2015 13:36:07 +0000
Subject: [issue20519] Replace uuid ctypes usage with an extension module.
In-Reply-To: <1391601143.27.0.910101155735.issue20519@psf.upfronthosting.co.za>
Message-ID: <1446039367.52.0.532215686049.issue20519@psf.upfronthosting.co.za>


Gustavo J. A. M. Carneiro added the comment:

New patch that:

1. adds assert(sizeof(uuid_t) == 16); to the extension module;

2. fixes the code path when ctypes has to be used instead of the extension module (needed a bit more refactoring, apologies if it makes the diff harder to read);

3. Adjusts the uuid module tests to account for the possibility of ctypes not being imported.

----------
Added file: http://bugs.python.org/file40874/uuid.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20519>
_______________________________________

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: [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 10:41:25 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Oct 2015 14:41:25 +0000
Subject: [issue21827] textwrap.dedent() fails when largest common whitespace
 is a substring of smallest leading whitespace
In-Reply-To: <1403455487.85.0.474137406062.issue21827@psf.upfronthosting.co.za>
Message-ID: <1446043285.85.0.65383225368.issue21827@psf.upfronthosting.co.za>


R. David Murray added the comment:

It's one of the PEPs (I forget which one).  We only apply non-security fixes to the most recent non-development branch...except that for now we also apply bug fixes to 2.7.  So, 2.7, 3.5, and 3.6 are the targets for this issue.

----------
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21827>
_______________________________________

From report at bugs.python.org  Wed Oct 28 10:49:54 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Oct 2015 14:49:54 +0000
Subject: [issue25489] sys.exit() caught in exception handler
In-Reply-To: <1445945156.1.0.415307859083.issue25489@psf.upfronthosting.co.za>
Message-ID: <1446043794.95.0.181430831888.issue25489@psf.upfronthosting.co.za>


R. David Murray added the comment:

Using sys.exit means you are depending on garbage collection to clean up all of your program's resources.  In the general case this is a bad idea.  A better design is to call loop.stop, and then do cleanup (which might involve calling some wait_closed functions via loop.run_until_complete).  If you just call sys.exit, your resources may not get cleaned up correctly, or may not get cleaned up correctly somewhat randomly due to the indeterminacies in the order in which garbage collection is done.  This may not matter for a simple program, but I find it makes it easier for me if I just do it "the right way" always :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25489>
_______________________________________

From report at bugs.python.org  Wed Oct 28 10:54:44 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Oct 2015 14:54:44 +0000
Subject: [issue25482] signal.set_wakeup_fd() doesn't work if the signal don't
 have handler
In-Reply-To: <1445859296.06.0.537058365711.issue25482@psf.upfronthosting.co.za>
Message-ID: <1446044084.27.0.494145185003.issue25482@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> IMO this reduces usefulness of set_wakeup_fd(). (...)

Sorry, I don't understand your use case. Could you elaborate. What do you need?

--

According to the GNU libc doc, the signal SIGWINCH is *ignored* by default:
"Window size change. This is generated on some systems (including GNU) when the terminal driver?s record of the number of rows and columns on the screen is changed. The default action is to ignore it."
https://www.gnu.org/software/libc/manual/html_node/Miscellaneous-Signals.html

For signal.set_wakeup_fd() I agree that the doc can be enhanced. It's not explicit that only signals with a *Python* signal handler (at least, a signal handler registered by signal.signal) write into the "wakeup FD".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25482>
_______________________________________

From report at bugs.python.org  Wed Oct 28 11:32:36 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 28 Oct 2015 15:32:36 +0000
Subject: [issue25489] sys.exit() caught in exception handler
In-Reply-To: <1446023395.03.0.913080829015.issue25489@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJe_HgLCPFb9UiMsdzXL6SA8naKdWKMc-9ASy-M9QHJkQ@mail.gmail.com>


Guido van Rossum added the comment:

How about we extend loop.stop() so that you can pass it an exception to
raise once the loop is stopped? This exception would then be thrown out of
run_forever(). There may be some delay (callbacks already scheduled will
run first) but it is how things were meant to be.

FWIW this isn't really enough to ensure cleanup happens before destructors
run -- when the loop exits, tasks may still be active unless you keep track
of all of them and explicitly cancel them (and run the loop until they have
processed the cancellation).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25489>
_______________________________________

From report at bugs.python.org  Wed Oct 28 11:40:23 2015
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 28 Oct 2015 15:40:23 +0000
Subject: [issue8231] Unable to run IDLE without write-access to home directory
In-Reply-To: <1269531569.44.0.352644957859.issue8231@psf.upfronthosting.co.za>
Message-ID: <1446046822.99.0.410053610604.issue8231@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Checked on Linux and Mac - doesn't work correctly. mkdtemp() returns a different name every time it's called, and GetUserCfgDir() is called in three places, meaning we end up with three different tmp directories (which on quick examination didn't all get cleaned up at end).

I'd suggest changing it so that GetUserCfgDir() caches its result and returns the cached version on subsequent calls. Running out the door so don't have time to try this myself right now...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8231>
_______________________________________

From report at bugs.python.org  Wed Oct 28 11:46:50 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 28 Oct 2015 15:46:50 +0000
Subject: [issue21827] textwrap.dedent() fails when largest common whitespace
 is a substring of smallest leading whitespace
In-Reply-To: <1403455487.85.0.474137406062.issue21827@psf.upfronthosting.co.za>
Message-ID: <1446047210.82.0.563291701538.issue21827@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Serhiy, your way looks best.  Go ahead with it.

----------
assignee: rhettinger -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21827>
_______________________________________

From report at bugs.python.org  Wed Oct 28 12:04:54 2015
From: report at bugs.python.org (Michael Crouch)
Date: Wed, 28 Oct 2015 16:04:54 +0000
Subject: [issue21333] Document recommended exception for objects that
 shouldn't be pickled
In-Reply-To: <1398232634.34.0.847410110548.issue21333@psf.upfronthosting.co.za>
Message-ID: <1446048294.19.0.675989186886.issue21333@psf.upfronthosting.co.za>


Michael Crouch added the comment:

When pickling an object fails on line 70 of copy_reg.py, a "TypeError" is raised. However, according to section 11.1.3 of the Standard Library documentation, when an unpicklable object is passed to the dump() method the "PicklingError" exception will be raised.

----------
components: +Library (Lib) -Documentation
nosy: +Michael Crouch
versions: +Python 2.7 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21333>
_______________________________________

From report at bugs.python.org  Wed Oct 28 12:10:29 2015
From: report at bugs.python.org (Mouse)
Date: Wed, 28 Oct 2015 16:10:29 +0000
Subject: [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1446048629.51.0.822430885171.issue25495@psf.upfronthosting.co.za>


Mouse added the comment:

Yes I know where this came from. :-)

Here is my proposed change.

Replace the statement 

The length of data should be at most 57 to adhere to the base64 standard.

with:

To be MIME-compliant, the Base64 output (as defined in RFC4648) should be broken into lines of at most 76 characters long. This post-processing of the output is the responsibility of the caller. Note that the original PEM context-transfer encoding limited line length to 64 characters.


Would this change be agreeable to you?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25495>
_______________________________________

From report at bugs.python.org  Wed Oct 28 13:10:04 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 28 Oct 2015 17:10:04 +0000
Subject: [issue21333] Document recommended exception for objects that
 shouldn't be pickled
In-Reply-To: <1398232634.34.0.847410110548.issue21333@psf.upfronthosting.co.za>
Message-ID: <1446052204.45.0.960571450426.issue21333@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

PicklingError is raised in following cases:

1. Programmical Pickler error (Pickler.__init__() was not called by subclass' __init__()).

2. Due to protocol or implementation limitations: memoizing more than 2**32 objects, saving non-ASCII globals with protocol < 3, etc. Exception type is implementation depended. Sometimes OverflowError or struct.error can be raised instead.

3. When __reduce__/__reduce_ex__ returns invalid value: neither str or tuple, a tuple has wrong size, first tuple element is not a callable, first argument for __newobj__/__newobj_ex__ has no __new__ or doesn't match a type of pickled object, global lookup is failed or doesn't match pickled object, etc.

4. When extension code is not an integer or out of range.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21333>
_______________________________________

From report at bugs.python.org  Wed Oct 28 13:14:32 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 28 Oct 2015 17:14:32 +0000
Subject: [issue21827] textwrap.dedent() fails when largest common whitespace
 is a substring of smallest leading whitespace
In-Reply-To: <1403455487.85.0.474137406062.issue21827@psf.upfronthosting.co.za>
Message-ID: <1446052472.28.0.370043214093.issue21827@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I thought that 3.4 will switch to "security fixes only" mode after releasing first release since releasing 3.5.0. It was so with 3.2 and 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21827>
_______________________________________

From report at bugs.python.org  Wed Oct 28 13:22:46 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 28 Oct 2015 17:22:46 +0000
Subject: [issue25483] Improve f-string implementation: FORMAT_VALUE opcode
In-Reply-To: <1445874299.22.0.773155754186.issue25483@psf.upfronthosting.co.za>
Message-ID: <1446052966.4.0.806843115185.issue25483@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Oops. Forgot to include the diff with that last message. But it turns out it doesn't work, anyway, because I put the #define's in opcode.h, which is generated (so my code got deleted!).

I'll try to find some reasonable .h file to use and submit a new patch soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25483>
_______________________________________

From report at bugs.python.org  Wed Oct 28 13:25:52 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 28 Oct 2015 17:25:52 +0000
Subject: [issue25483] Improve f-string implementation: FORMAT_VALUE opcode
In-Reply-To: <1445874299.22.0.773155754186.issue25483@psf.upfronthosting.co.za>
Message-ID: <1446053152.63.0.19751047974.issue25483@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I know this issue is slowly turning into "make Eric update outdated docs", but if you find that https://docs.python.org/devguide/compiler.html#introducing-new-bytecode is outdated, could you update that doc?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25483>
_______________________________________

From report at bugs.python.org  Wed Oct 28 13:37:39 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Oct 2015 17:37:39 +0000
Subject: [issue21827] textwrap.dedent() fails when largest common whitespace
 is a substring of smallest leading whitespace
In-Reply-To: <1403455487.85.0.474137406062.issue21827@psf.upfronthosting.co.za>
Message-ID: <1446053859.88.0.870352753825.issue21827@psf.upfronthosting.co.za>


R. David Murray added the comment:

You are right, I'd forgotten we hadn't done 3.4 final yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21827>
_______________________________________

From report at bugs.python.org  Wed Oct 28 13:37:47 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Oct 2015 17:37:47 +0000
Subject: [issue21827] textwrap.dedent() fails when largest common whitespace
 is a substring of smallest leading whitespace
In-Reply-To: <1403455487.85.0.474137406062.issue21827@psf.upfronthosting.co.za>
Message-ID: <1446053867.96.0.876196639435.issue21827@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21827>
_______________________________________

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: [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 14:35:27 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 28 Oct 2015 18:35:27 +0000
Subject: [issue25483] Improve f-string implementation: FORMAT_VALUE opcode
In-Reply-To: <1445874299.22.0.773155754186.issue25483@psf.upfronthosting.co.za>
Message-ID: <1446057327.93.0.987167675724.issue25483@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> I'll try to find some reasonable .h file to use and submit a new patch soon.

It's Lib/opcode.py.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25483>
_______________________________________

From report at bugs.python.org  Wed Oct 28 14:46:09 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 28 Oct 2015 18:46:09 +0000
Subject: [issue25483] Improve f-string implementation: FORMAT_VALUE opcode
In-Reply-To: <1445874299.22.0.773155754186.issue25483@psf.upfronthosting.co.za>
Message-ID: <1446057969.5.0.528138195062.issue25483@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Brett: I'll take a look.

Serhiy: I'm looking for a place to put some #defines related to the bit masks and bit values that my FORMAT_VALUE opcode is using for opargs. One option is to just put them in Tools/scripts/generate_opcode_h.py, so that they end up in the generated opcode.h, but that seems a little sleazy. I can't find a better place they'd belong, though.

Specifically, I want to put these lines into a .h file to use by ceval.c and compile.c:

/* Masks and values for FORMAT_VALUE opcode. */
#define FVC_MASK      0x3
#define FVS_MASK      0x4
#define FVC_NONE      0x0
#define FVC_STR       0x1
#define FVC_REPR      0x2
#define FVC_ASCII     0x3
#define FVS_HAVE_SPEC 0x4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25483>
_______________________________________

From report at bugs.python.org  Wed Oct 28 14:50:53 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Oct 2015 18:50:53 +0000
Subject: [issue25498] Python 3.4.3 core dump with simple sample code
In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za>
Message-ID: <1446058253.84.0.156815480468.issue25498@psf.upfronthosting.co.za>


R. David Murray added the comment:

The program does not crash for me on gentoo running python 3.4 tip (--with-pydebug).  It does crash running gentoo's stock 3.4.3.  So, perhaps this bug has already been fixed.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25498>
_______________________________________

From report at bugs.python.org  Wed Oct 28 15:16:47 2015
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 28 Oct 2015 19:16:47 +0000
Subject: [issue25498] Python 3.4.3 core dump with simple sample code
In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za>
Message-ID: <1446059807.56.0.168441200253.issue25498@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I get the crash on OSX with recent builds of 3.4 and 3.6:

Assertion failed: (self->exports == 0), function mbuf_dealloc, file Objects/memoryobject.c, line 115.
Abort trap: 6

----------
nosy: +jnoller, sbt, zach.ware
stage:  -> needs patch
type:  -> crash
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25498>
_______________________________________

From report at bugs.python.org  Wed Oct 28 15:27:42 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 28 Oct 2015 19:27:42 +0000
Subject: [issue25483] Improve f-string implementation: FORMAT_VALUE opcode
In-Reply-To: <1445874299.22.0.773155754186.issue25483@psf.upfronthosting.co.za>
Message-ID: <1446060462.51.0.269650155037.issue25483@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Does the dis module need these constants? If no, you can use either ceval.h or compile.h.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25483>
_______________________________________

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: [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 15:46:09 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Oct 2015 19:46:09 +0000
Subject: [issue21827] textwrap.dedent() fails when largest common whitespace
 is a substring of smallest leading whitespace
In-Reply-To: <1403455487.85.0.474137406062.issue21827@psf.upfronthosting.co.za>
Message-ID: <20151028194539.496.97780@psf.io>


Roundup Robot added the comment:

New changeset faeeb8dbe432 by Serhiy Storchaka in branch '3.4':
Issue #21827: Fixed textwrap.dedent() for the case when largest common
https://hg.python.org/cpython/rev/faeeb8dbe432

New changeset c307ae7b3d9f by Serhiy Storchaka in branch '2.7':
Issue #21827: Fixed textwrap.dedent() for the case when largest common
https://hg.python.org/cpython/rev/c307ae7b3d9f

New changeset 3f29be82c944 by Serhiy Storchaka in branch '3.5':
Issue #21827: Fixed textwrap.dedent() for the case when largest common
https://hg.python.org/cpython/rev/3f29be82c944

New changeset 8d3932671e48 by Serhiy Storchaka in branch 'default':
Issue #21827: Fixed textwrap.dedent() for the case when largest common
https://hg.python.org/cpython/rev/8d3932671e48

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21827>
_______________________________________

From report at bugs.python.org  Wed Oct 28 15:50:48 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 28 Oct 2015 19:50:48 +0000
Subject: [issue21827] textwrap.dedent() fails when largest common whitespace
 is a substring of smallest leading whitespace
In-Reply-To: <1403455487.85.0.474137406062.issue21827@psf.upfronthosting.co.za>
Message-ID: <1446061848.58.0.187608620397.issue21827@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Robert for your report and patch.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21827>
_______________________________________

From report at bugs.python.org  Wed Oct 28 15:52:14 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 28 Oct 2015 19:52:14 +0000
Subject: [issue25499] use argparse for the calendar module
In-Reply-To: <1446061141.61.0.20686802528.issue25499@psf.upfronthosting.co.za>
Message-ID: <1446061934.33.0.0827283883123.issue25499@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is a duplicate of issue18973.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Use argparse in the calendar module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25499>
_______________________________________

From report at bugs.python.org  Wed Oct 28 15:57:47 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 28 Oct 2015 19:57:47 +0000
Subject: [issue25499] use argparse for the calendar module
In-Reply-To: <1446061141.61.0.20686802528.issue25499@psf.upfronthosting.co.za>
Message-ID: <1446062267.89.0.416331560529.issue25499@psf.upfronthosting.co.za>


St?phane Wirtel added the comment:

Why do you close it ? Ok, it's a duplicated issue, but the other issue is not closed. So, in that issue, there is no tests, maybe we can add some tests and re-submit a new patch.

What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25499>
_______________________________________

From report at bugs.python.org  Wed Oct 28 16:02:17 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 28 Oct 2015 20:02:17 +0000
Subject: [issue25496] Default value for compresslevel is not documented
In-Reply-To: <1446021567.06.0.820338275323.issue25496@psf.upfronthosting.co.za>
Message-ID: <1446062537.44.0.75864273904.issue25496@psf.upfronthosting.co.za>


St?phane Wirtel added the comment:

Hi Sworddragon,

Where compresslevel is not mentioned in the doc ?

Thank you

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25496>
_______________________________________

From report at bugs.python.org  Wed Oct 28 16:18:08 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 28 Oct 2015 20:18:08 +0000
Subject: [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1446063488.28.0.522148690394.issue25495@psf.upfronthosting.co.za>


St?phane Wirtel added the comment:

Here is a patch with the submitted description.

----------
keywords: +patch
nosy: +matrixise
Added file: http://bugs.python.org/file40878/issue25495.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25495>
_______________________________________

From report at bugs.python.org  Wed Oct 28 16:25:30 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 28 Oct 2015 20:25:30 +0000
Subject: [issue25499] use argparse for the calendar module
In-Reply-To: <1446061141.61.0.20686802528.issue25499@psf.upfronthosting.co.za>
Message-ID: <1446063930.93.0.0775980102202.issue25499@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Because we need only one issue for every feature.

Tests was committed in issue18982. The patch in issue18973 just waits for review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25499>
_______________________________________

From report at bugs.python.org  Wed Oct 28 16:44:03 2015
From: report at bugs.python.org (Mouse)
Date: Wed, 28 Oct 2015 20:44:03 +0000
Subject: [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1446065043.88.0.903708668232.issue25495@psf.upfronthosting.co.za>


Mouse added the comment:

Thank you for the quick turn-around, and for taking care of this issue!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25495>
_______________________________________

From report at bugs.python.org  Wed Oct 28 16:52:28 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 28 Oct 2015 20:52:28 +0000
Subject: [issue18973] Use argparse in the calendar module
In-Reply-To: <1378652776.38.0.50139824268.issue18973@psf.upfronthosting.co.za>
Message-ID: <1446065548.23.0.607217977953.issue18973@psf.upfronthosting.co.za>


St?phane Wirtel added the comment:

Hi Serhiy,

I just reviewed your patch, works fine with 3.6.

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18973>
_______________________________________

From report at bugs.python.org  Wed Oct 28 16:54:48 2015
From: report at bugs.python.org (SilentGhost)
Date: Wed, 28 Oct 2015 20:54:48 +0000
Subject: [issue18973] Use argparse in the calendar module
In-Reply-To: <1378652776.38.0.50139824268.issue18973@psf.upfronthosting.co.za>
Message-ID: <1446065688.14.0.0462145306001.issue18973@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18973>
_______________________________________

From report at bugs.python.org  Wed Oct 28 16:58:29 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 28 Oct 2015 20:58:29 +0000
Subject: [issue25485] Add a context manager to telnetlib.Telnet
In-Reply-To: <1445883619.21.0.032521861016.issue25485@psf.upfronthosting.co.za>
Message-ID: <1446065909.32.0.0971417483933.issue25485@psf.upfronthosting.co.za>


St?phane Wirtel added the comment:

Here is a small patch

----------
keywords: +patch
nosy: +matrixise
Added file: http://bugs.python.org/file40879/issue25485.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25485>
_______________________________________

From report at bugs.python.org  Wed Oct 28 16:59:49 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 28 Oct 2015 20:59:49 +0000
Subject: [issue25483] Improve f-string implementation: FORMAT_VALUE opcode
In-Reply-To: <1445874299.22.0.773155754186.issue25483@psf.upfronthosting.co.za>
Message-ID: <1446065989.9.0.320643423945.issue25483@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Thanks, Serihy. I looked at those, and neither one is a great fit. But not having a better option, I went with ceval.h. Here's the patch.

----------
Added file: http://bugs.python.org/file40880/format-opcode-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25483>
_______________________________________

From report at bugs.python.org  Wed Oct 28 17:04:24 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 28 Oct 2015 21:04:24 +0000
Subject: [issue25485] Add a context manager to telnetlib.Telnet
In-Reply-To: <1445883619.21.0.032521861016.issue25485@psf.upfronthosting.co.za>
Message-ID: <1446066264.01.0.266216365305.issue25485@psf.upfronthosting.co.za>


St?phane Wirtel added the comment:

Maybe, modify the documentation or improve the current examples.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25485>
_______________________________________

From report at bugs.python.org  Wed Oct 28 17:09:39 2015
From: report at bugs.python.org (SilentGhost)
Date: Wed, 28 Oct 2015 21:09:39 +0000
Subject: [issue25485] Add a context manager to telnetlib.Telnet
In-Reply-To: <1445883619.21.0.032521861016.issue25485@psf.upfronthosting.co.za>
Message-ID: <1446066579.28.0.0591798250871.issue25485@psf.upfronthosting.co.za>


SilentGhost added the comment:

This probably needs test

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25485>
_______________________________________

From report at bugs.python.org  Wed Oct 28 17:14:44 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 28 Oct 2015 21:14:44 +0000
Subject: [issue25485] Add a context manager to telnetlib.Telnet
In-Reply-To: <1445883619.21.0.032521861016.issue25485@psf.upfronthosting.co.za>
Message-ID: <1446066884.59.0.263401794287.issue25485@psf.upfronthosting.co.za>


St?phane Wirtel added the comment:

totally agree, I will work on this issue tomorrow

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25485>
_______________________________________

From report at bugs.python.org  Wed Oct 28 17:20:25 2015
From: report at bugs.python.org (desbma)
Date: Wed, 28 Oct 2015 21:20:25 +0000
Subject: [issue25485] Add a context manager to telnetlib.Telnet
In-Reply-To: <1445883619.21.0.032521861016.issue25485@psf.upfronthosting.co.za>
Message-ID: <1446067225.68.0.082724363567.issue25485@psf.upfronthosting.co.za>


desbma added the comment:

I was actually writing a patch with a test, but since St?phane beat me to it, I'll let him do the job :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25485>
_______________________________________

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: [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 17:37:23 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Oct 2015 21:37:23 +0000
Subject: [issue25500] _find_and_load_unlocked doesn't always use __import__
In-Reply-To: <1446068084.58.0.390651859443.issue25500@psf.upfronthosting.co.za>
Message-ID: <1446068243.81.0.868032268553.issue25500@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +brett.cannon, eric.snow

_______________________________________
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: [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 18:31:36 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 28 Oct 2015 22:31:36 +0000
Subject: [issue25501] Use async/await through asyncio docs
In-Reply-To: <1446071453.74.0.752401915255.issue25501@psf.upfronthosting.co.za>
Message-ID: <1446071496.43.0.223027301512.issue25501@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
nosy: +ezio.melotti
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25501>
_______________________________________

From report at bugs.python.org  Wed Oct 28 18:40:43 2015
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 28 Oct 2015 22:40:43 +0000
Subject: [issue8231] Unable to run IDLE without write-access to home directory
In-Reply-To: <1269531569.44.0.352644957859.issue8231@psf.upfronthosting.co.za>
Message-ID: <1446072043.05.0.338401981823.issue8231@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Just a note that the 'store things in APPDATA' is issue #24765

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8231>
_______________________________________

From report at bugs.python.org  Wed Oct 28 18:41:56 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 28 Oct 2015 22:41:56 +0000
Subject: [issue25500] docs claim __import__ checked for in globals,
 but IMPORT_NAME bytecode does not
In-Reply-To: <1446068084.58.0.390651859443.issue25500@psf.upfronthosting.co.za>
Message-ID: <1446072116.23.0.78782978.issue25500@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I think the documentation is wrong. Going all the way back to Python 2.7, you will see that importing a module emits IMPORT_NAME as the bytecode. That bytecode only looks for __import__ in the builtin  namespace: https://hg.python.org/cpython/file/2.7/Python/ceval.c#l2588 . That then calls PyImport_ImportModuleLevel(): https://hg.python.org/cpython/file/2.7/Python/bltinmodule.c#l49 . That then just ends up executing import.

If you look at PyImport_Import() in Python 2.7 that comes the closest to what the docs reference, but that still uses __builtins__.__import__ based on finding __builtins__ from the global namespace: https://hg.python.org/cpython/file/2.7/Python/import.c#l2825 . But that isn't directly called by import itself and is just a C-level API.

If you look in Python 3, then you will see that as far back as Python 3.3 the code in importlib is more or less the same: __import__ is used when importing a parent and then importlib is used for the rest: https://hg.python.org/cpython/file/default/Lib/importlib/_bootstrap.py#l944 . This was introduced so that the accelerated C version of __import__ would be used to import the parent rather than automatically going down the pure Python path for stuff such as resolving names and such. This was never done to explicitly import using something defined in the globals namespace (although this does lead to supporting it).

And if you go all the way back to Python 3.0 you will notice that getting __import__ from the builtins namespace only has been in place: https://hg.python.org/cpython/file/3.0/Python/ceval.c#l1959 .

So I think the key point here is that the bytecode for IMPORT_NAME doesn't match the docs. So the question is do we want to add the feature to Python 3 to look for import in the globals or would we rather leave it as is and fix the docs?

----------
title: _find_and_load_unlocked doesn't always use __import__ -> docs claim __import__ checked for in globals, but IMPORT_NAME bytecode does not

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25500>
_______________________________________

From report at bugs.python.org  Wed Oct 28 18:47:34 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 28 Oct 2015 22:47:34 +0000
Subject: [issue25498] Python 3.4.3 core dump with simple sample code
In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za>
Message-ID: <1446072454.61.0.111758504389.issue25498@psf.upfronthosting.co.za>


Martin Panter added the comment:

Crashes on Linux x86-64 for me with and without --with-pydebug, with the default 3.6 branch, 3.5.0, and 3.4 tip. No extra debugging output though in the --with-pydebug cases though.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25498>
_______________________________________

From report at bugs.python.org  Wed Oct 28 18:56:07 2015
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 28 Oct 2015 22:56:07 +0000
Subject: [issue24765] Move .idlerc to %APPDATA%\IDLE on Windows
In-Reply-To: <1438360301.06.0.841690925135.issue24765@psf.upfronthosting.co.za>
Message-ID: <1446072967.05.0.779304105904.issue24765@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Further to Terry's backwards compatibility issues (also discussed in #8231).

Storing things in the "correct" location (%APPDATA% on Windows, and Application Support on OS X) would presumably be the "right" thing to do if backwards compatibility weren't an issue.  

If "APPDATA" is the "correct" place, and "HOME" is what we've been using now, consider a solution like this:

- check if prefs exist in APPDATA; if so, use that
- check if prefs exist in HOME; if so, use that
- if neither, create prefs in APPDATA

This handles the common cases of existing user upgrading to new scheme (things stay stored in old location), new user upgrading to newer versions in future (things go in new place), but fails on the case of user starts with new version and then later uses an older version (results in two separate preferences, one used by newer versions, one used by older).

I think it's a legitimate question as to whether that latter case is common enough or problematic enough to worry about it (given "fails" doesn't break anything).

----------
nosy: +markroseman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24765>
_______________________________________

From report at bugs.python.org  Wed Oct 28 19:13:11 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 28 Oct 2015 23:13:11 +0000
Subject: [issue25501] Use async/await through asyncio docs
In-Reply-To: <1446071453.74.0.752401915255.issue25501@psf.upfronthosting.co.za>
Message-ID: <1446073991.79.0.289009115065.issue25501@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

It makes it more awkward to keep the asyncio docs in sync between 3.4 and 3.5. Also it makes copying examples harder for users who need compatibility with 3.4 or 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25501>
_______________________________________

From report at bugs.python.org  Wed Oct 28 19:15:46 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Oct 2015 23:15:46 +0000
Subject: [issue25500] docs claim __import__ checked for in globals,
 but IMPORT_NAME bytecode does not
In-Reply-To: <1446068084.58.0.390651859443.issue25500@psf.upfronthosting.co.za>
Message-ID: <1446074146.86.0.223912047638.issue25500@psf.upfronthosting.co.za>


R. David Murray added the comment:

Fix the docs.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25500>
_______________________________________

From report at bugs.python.org  Wed Oct 28 19:41:24 2015
From: report at bugs.python.org (desbma)
Date: Wed, 28 Oct 2015 23:41:24 +0000
Subject: [issue25156] shutil.copyfile should internally use os.sendfile when
 possible
In-Reply-To: <1442520485.03.0.419427125487.issue25156@psf.upfronthosting.co.za>
Message-ID: <1446075684.89.0.69114384925.issue25156@psf.upfronthosting.co.za>


desbma added the comment:

Thoughts anyone?
Here is a patch that implements the change.

My tests show a 30-40% performance improvement for 128KB-512MB single file copy:

128 KB file copy:

$ dd if=/dev/urandom of=/tmp/f1 bs=1K count=128

Without the patch:
$ ./python -m timeit -s 'import shutil; p1 = "/tmp/f1"; p2 = "/tmp/f2"' 'shutil.copyfile(p1, p2)'
10000 loops, best of 3: 109 usec per loop

With the patch:
$ ./python -m timeit -s 'import shutil; p1 = "/tmp/f1"; p2 = "/tmp/f2"' 'shutil.copyfile(p1, p2)'
10000 loops, best of 3: 75.7 usec per loop

--------
8 MB file copy:

$ dd if=/dev/urandom of=/tmp/f1 bs=1M count=8

Without the patch:
$ ./python -m timeit -s 'import shutil; p1 = "/tmp/f1"; p2 = "/tmp/f2"' 'shutil.copyfile(p1, p2)'
100 loops, best of 3: 4.99 msec per loop

With the patch:
$ ./python -m timeit -s 'import shutil; p1 = "/tmp/f1"; p2 = "/tmp/f2"' 'shutil.copyfile(p1, p2)'
100 loops, best of 3: 3.03 msec per loop

--------
512 MB file copy:

$ dd if=/dev/urandom of=/tmp/f1 bs=1M count=512

Without the patch:
$ ./python -m timeit -s 'import shutil; p1 = "/tmp/f1"; p2 = "/tmp/f2"' 'shutil.copyfile(p1, p2)'
10 loops, best of 3: 305 msec per loop

With the patch:
$ ./python -m timeit -s 'import shutil; p1 = "/tmp/f1"; p2 = "/tmp/f2"' 'shutil.copyfile(p1, p2)'
10 loops, best of 3: 178 msec per loop

----------
keywords: +patch
Added file: http://bugs.python.org/file40881/issue25156.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25156>
_______________________________________

From report at bugs.python.org  Wed Oct 28 19:49:19 2015
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 28 Oct 2015 23:49:19 +0000
Subject: [issue25501] Use async/await through asyncio docs
In-Reply-To: <1446071453.74.0.752401915255.issue25501@psf.upfronthosting.co.za>
Message-ID: <1446076159.1.0.240089883429.issue25501@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Also sphinx (pygments actually) still do not support async/await syntax highlighting yet.

----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25501>
_______________________________________

From report at bugs.python.org  Wed Oct 28 19:56:24 2015
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 28 Oct 2015 23:56:24 +0000
Subject: [issue25501] Use async/await through asyncio docs
In-Reply-To: <1446071453.74.0.752401915255.issue25501@psf.upfronthosting.co.za>
Message-ID: <1446076584.3.0.279554963401.issue25501@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

We have dropped 3.3 in aiohttp BTW.
Proper handling of resource leaks is too annoying without PEP 442 which don't crash with core dump starting from Python 3.4.1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25501>
_______________________________________

From report at bugs.python.org  Wed Oct 28 20:29:35 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 29 Oct 2015 00:29:35 +0000
Subject: [issue25498] Python 3.4.3 core dump with simple sample code
In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za>
Message-ID: <1446078575.38.0.102714522293.issue25498@psf.upfronthosting.co.za>


Martin Panter added the comment:

I traced this down to part of revision 1da9630e9b7f (Issue #22896). If I revert the changes to CDataType_from_buffer() at <https://hg.python.org/cpython/rev/1da9630e9b7f/#l4.3>, the crash no longer happens. I suspect the offending code is this, that is trying to stash the original buffer protocol supporting object into a memory view:

mv = PyMemoryView_FromBuffer(&buffer);
if (mv == NULL) {
    PyBuffer_Release(&buffer);
    return NULL;
}
/* Hack the memoryview so that it will release the buffer. */
((PyMemoryViewObject *)mv)->mbuf->master.obj = buffer.obj;
((PyMemoryViewObject *)mv)->view.obj = buffer.obj;
//~ Py_INCREF(buffer.obj);
if (-1 == KeepRef((CDataObject *)result, -1, mv))
    result = NULL;

If I enable my INCREF() line it also stops the crash, but I guess at the expense of a memory leak.

----------
components: +ctypes -Interpreter Core
keywords: +3.4regression
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25498>
_______________________________________

From report at bugs.python.org  Wed Oct 28 20:32:09 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 29 Oct 2015 00:32:09 +0000
Subject: [issue22896] Don't use PyObject_As*Buffer() functions
In-Reply-To: <1416319375.33.0.739222572648.issue22896@psf.upfronthosting.co.za>
Message-ID: <1446078729.57.0.917822706982.issue22896@psf.upfronthosting.co.za>


Martin Panter added the comment:

Please see Issue 25498 for a crash possibly caused by the memoryview hack in CDataType_from_buffer().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22896>
_______________________________________

From report at bugs.python.org  Wed Oct 28 20:51:01 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 29 Oct 2015 00:51:01 +0000
Subject: [issue25156] shutil.copyfile should internally use os.sendfile when
 possible
In-Reply-To: <1442520485.03.0.419427125487.issue25156@psf.upfronthosting.co.za>
Message-ID: <1446079861.01.0.652912192683.issue25156@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Adding interested parties from earlier ticket.

----------
nosy: +josh.r, martin.panter, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25156>
_______________________________________

From report at bugs.python.org  Wed Oct 28 21:18:14 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 29 Oct 2015 01:18:14 +0000
Subject: [issue25156] shutil.copyfile should internally use os.sendfile when
 possible
In-Reply-To: <1442520485.03.0.419427125487.issue25156@psf.upfronthosting.co.za>
Message-ID: <1446081494.07.0.446364835513.issue25156@psf.upfronthosting.co.za>


Martin Panter added the comment:

I?ve never used sendfile() nor shutil.copyfile(), but my immediate reaction is maybe we need a backup plan if os.sendfile() is available but not supported in the circumstances. E.g. if it is practical to use copyfile() to copy from a named socket in the filesystem, the Linux man page <http://man7.org/linux/man-pages/man2/sendfile.2.html> says it will raise EINVAL in this case. Maybe a test case would be good to prove this is still handled.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25156>
_______________________________________

From report at bugs.python.org  Wed Oct 28 21:24:17 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 29 Oct 2015 01:24:17 +0000
Subject: [issue25156] shutil.copyfile should internally use os.sendfile when
 possible
In-Reply-To: <1442520485.03.0.419427125487.issue25156@psf.upfronthosting.co.za>
Message-ID: <1446081857.43.0.0757828069985.issue25156@psf.upfronthosting.co.za>


Martin Panter added the comment:

Also, the os.sendfile() doc suggests that some platforms only support writing to sockets, so I definitely think a backup plan is needed.

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25156>
_______________________________________

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: [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  Wed Oct 28 23:06:27 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 29 Oct 2015 03:06:27 +0000
Subject: [issue25395] SIGSEGV using json.tool: highly nested OrderedDict
In-Reply-To: <1444765181.78.0.70980847428.issue25395@psf.upfronthosting.co.za>
Message-ID: <1446087987.55.0.893074191103.issue25395@psf.upfronthosting.co.za>


Martin Panter added the comment:

Left a comment about a minor English grammar problem.

The existing comment Serhiy mentioned was added way back in 2003 for Issue 668433. It appears to use the same underlying technique, reverting the nesting level before calling the base class dealloc. One paragraph talks about the extra increment used there compared to Serhiy?s method:

'''
But now it's possible that a chain of objects consisting solely of objects whose deallocator is subtype_dealloc() will defeat the trashcan mechanism completely: the decremented level means that the effective level never reaches the limit.  Therefore, we *increment* the level *before* entering the trashcan block, and matchingly decrement it after leaving.  This means the trashcan code will trigger a little early, but that's no big deal.
'''

I think we may not have to worry about this for ordered dict, assuming that PyDict_Type.tp_dealloc() can only recursively invoke odict_dealloc() from within its own trashcan block.

So as far as I can tell, this patch is good to apply, unless someone with more knowledge of garbage collection has any comments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25395>
_______________________________________

From report at bugs.python.org  Wed Oct 28 23:51:14 2015
From: report at bugs.python.org (John Mark Vandenberg)
Date: Thu, 29 Oct 2015 03:51:14 +0000
Subject: [issue25486] Resurrect inspect.getargspec() in 3.6
In-Reply-To: <1445891623.91.0.591196153919.issue25486@psf.upfronthosting.co.za>
Message-ID: <1446090674.45.0.565525246771.issue25486@psf.upfronthosting.co.za>


Changes by John Mark Vandenberg <jayvdb at gmail.com>:


----------
nosy: +John.Mark.Vandenberg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25486>
_______________________________________

From report at bugs.python.org  Thu Oct 29 00:34:15 2015
From: report at bugs.python.org (eryksun)
Date: Thu, 29 Oct 2015 04:34:15 +0000
Subject: [issue25498] Python 3.4.3 core dump with simple sample code
In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za>
Message-ID: <1446093255.12.0.131550663638.issue25498@psf.upfronthosting.co.za>


Changes by eryksun <eryksun at gmail.com>:


Added file: http://bugs.python.org/file40883/ctypes_crash.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25498>
_______________________________________

From report at bugs.python.org  Thu Oct 29 00:39:10 2015
From: report at bugs.python.org (eryksun)
Date: Thu, 29 Oct 2015 04:39:10 +0000
Subject: [issue25498] Python 3.4.3 core dump with simple sample code
In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za>
Message-ID: <1446093550.74.0.896363929643.issue25498@psf.upfronthosting.co.za>


Changes by eryksun <eryksun at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file40884/ctypes_from_buffer_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25498>
_______________________________________

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: [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 00:59:16 2015
From: report at bugs.python.org (John Mark Vandenberg)
Date: Thu, 29 Oct 2015 04:59:16 +0000
Subject: [issue25503] inspect.getdoc does find inherited property __doc__
In-Reply-To: <1446094420.64.0.595919822106.issue25503@psf.upfronthosting.co.za>
Message-ID: <1446094756.97.0.540910352615.issue25503@psf.upfronthosting.co.za>


Changes by John Mark Vandenberg <jayvdb at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25503>
_______________________________________

From report at bugs.python.org  Thu Oct 29 01:00:54 2015
From: report at bugs.python.org (mandeep)
Date: Thu, 29 Oct 2015 05:00:54 +0000
Subject: [issue24805] Python installer having problem in installing Python for
 all users in Windows
In-Reply-To: <1438838140.75.0.258560462687.issue24805@psf.upfronthosting.co.za>
Message-ID: <1446094854.5.0.519883066204.issue24805@psf.upfronthosting.co.za>


mandeep added the comment:

Team,

Please let me know , if there is a workaround to this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24805>
_______________________________________

From report at bugs.python.org  Thu Oct 29 01:25:37 2015
From: report at bugs.python.org (eryksun)
Date: Thu, 29 Oct 2015 05:25:37 +0000
Subject: [issue25498] Python 3.4.3 core dump with simple sample code
In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za>
Message-ID: <1446096337.84.0.323103122267.issue25498@psf.upfronthosting.co.za>


Changes by eryksun <eryksun at gmail.com>:


Removed file: http://bugs.python.org/file40884/ctypes_from_buffer_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25498>
_______________________________________

From report at bugs.python.org  Thu Oct 29 01:38:59 2015
From: report at bugs.python.org (Sworddragon)
Date: Thu, 29 Oct 2015 05:38:59 +0000
Subject: [issue25496] tarfile: Default value for compresslevel is not
 documented
In-Reply-To: <1446021567.06.0.820338275323.issue25496@psf.upfronthosting.co.za>
Message-ID: <1446097139.71.0.29638095227.issue25496@psf.upfronthosting.co.za>


Sworddragon added the comment:

At tarfile, but the compresslevel argument is mentioned there but not its default value.

----------
title: Default value for compresslevel is not documented -> tarfile: Default value for compresslevel is not documented

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25496>
_______________________________________

From report at bugs.python.org  Thu Oct 29 01:43:05 2015
From: report at bugs.python.org (John Mark Vandenberg)
Date: Thu, 29 Oct 2015 05:43:05 +0000
Subject: [issue25502] unnecessary re-imports
In-Reply-To: <1446083745.57.0.702787363915.issue25502@psf.upfronthosting.co.za>
Message-ID: <1446097385.65.0.160653337452.issue25502@psf.upfronthosting.co.za>


Changes by John Mark Vandenberg <jayvdb at gmail.com>:


Added file: http://bugs.python.org/file40886/re-imports.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25502>
_______________________________________

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: [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:17:25 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 29 Oct 2015 06:17:25 +0000
Subject: [issue25482] signal.set_wakeup_fd() doesn't work if the signal don't
 have handler
In-Reply-To: <1445859296.06.0.537058365711.issue25482@psf.upfronthosting.co.za>
Message-ID: <1446099445.7.0.636492072308.issue25482@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

The OP probably wants something like the Linux-specific signalfd() syscall.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25482>
_______________________________________

From report at bugs.python.org  Thu Oct 29 02:17:58 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 29 Oct 2015 06:17:58 +0000
Subject: [issue25502] unnecessary re-imports
In-Reply-To: <1446083745.57.0.702787363915.issue25502@psf.upfronthosting.co.za>
Message-ID: <20151029061701.21943.48595@psf.io>


Roundup Robot added the comment:

New changeset dec0a26d0b4d by Benjamin Peterson in branch '3.5':
remove duplicated imports (closes #25502)
https://hg.python.org/cpython/rev/dec0a26d0b4d

New changeset 695c50c8cc92 by Benjamin Peterson in branch 'default':
merge 3.5 (#25502)
https://hg.python.org/cpython/rev/695c50c8cc92

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25502>
_______________________________________

From report at bugs.python.org  Thu Oct 29 02:20:42 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 29 Oct 2015 06:20:42 +0000
Subject: [issue25503] inspect.getdoc does find inherited property __doc__
In-Reply-To: <1446094420.64.0.595919822106.issue25503@psf.upfronthosting.co.za>
Message-ID: <20151029062038.496.70364@psf.io>


Roundup Robot added the comment:

New changeset bbf00faf25ff by Serhiy Storchaka in branch '3.5':
Issue #25503: Fixed inspect.getdoc() for inherited docstrings of properties.
https://hg.python.org/cpython/rev/bbf00faf25ff

New changeset e80d1e9737d4 by Serhiy Storchaka in branch 'default':
Issue #25503: Fixed inspect.getdoc() for inherited docstrings of properties.
https://hg.python.org/cpython/rev/e80d1e9737d4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25503>
_______________________________________

From report at bugs.python.org  Thu Oct 29 02:22:55 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Oct 2015 06:22:55 +0000
Subject: [issue25503] inspect.getdoc does find inherited property __doc__
In-Reply-To: <1446094420.64.0.595919822106.issue25503@psf.upfronthosting.co.za>
Message-ID: <1446099775.09.0.676549526973.issue25503@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you John for your report and your patch.

Committed tests are slightly changed because "contradiction" was originally purposed to test properties.

----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25503>
_______________________________________

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: [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 02:38:47 2015
From: report at bugs.python.org (John Mark Vandenberg)
Date: Thu, 29 Oct 2015 06:38:47 +0000
Subject: [issue25505] undefined name 'window' in Tools/scripts/fixdiv.py
In-Reply-To: <1446100670.6.0.312090653047.issue25505@psf.upfronthosting.co.za>
Message-ID: <1446100727.5.0.625685089971.issue25505@psf.upfronthosting.co.za>


Changes by John Mark Vandenberg <jayvdb at gmail.com>:


Added file: http://bugs.python.org/file40889/fixdiv-remove-truncate.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25505>
_______________________________________

From report at bugs.python.org  Thu Oct 29 03:14:19 2015
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 29 Oct 2015 07:14:19 +0000
Subject: [issue13828] Further improve casefold documentation
In-Reply-To: <1326992763.46.0.576190503242.issue13828@psf.upfronthosting.co.za>
Message-ID: <1446102859.11.0.133821459272.issue13828@psf.upfronthosting.co.za>


Mark Summerfield added the comment:

I think the str.casefold() docs are fine as far as they go, rightly covering what it _does_ rather than _how_, yet providing a reference for the details. But what they lack is more complete information. For example I discovered this:

>>> x = "?les and shu?es"
>>> x
'?les and shu?es'
>>> x.casefold()
'files and shuffles'

In view of this I would add one sentence:

    In addition to lowercasing, this function also expands ligatures, for example, "?" becomes "fi".

----------
nosy: +mark

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13828>
_______________________________________

From report at bugs.python.org  Thu Oct 29 03:17:38 2015
From: report at bugs.python.org (eryksun)
Date: Thu, 29 Oct 2015 07:17:38 +0000
Subject: [issue25498] Python 3.4.3 core dump with simple sample code
In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za>
Message-ID: <1446103058.82.0.453926919817.issue25498@psf.upfronthosting.co.za>


Changes by eryksun <eryksun at gmail.com>:


Added file: http://bugs.python.org/file40890/ctypes_from_buffer_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25498>
_______________________________________

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: [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 03:27:12 2015
From: report at bugs.python.org (John Mark Vandenberg)
Date: Thu, 29 Oct 2015 07:27:12 +0000
Subject: [issue25506] test_pprint reuses test_user_dict
In-Reply-To: <1446103535.53.0.629816252417.issue25506@psf.upfronthosting.co.za>
Message-ID: <1446103632.98.0.392117612953.issue25506@psf.upfronthosting.co.za>


John Mark Vandenberg added the comment:

Sorry; the first patch includes unrelated fixes.

----------
Added file: http://bugs.python.org/file40892/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 03:48:54 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Oct 2015 07:48:54 +0000
Subject: [issue25498] Python 3.4.3 core dump with simple sample code
In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za>
Message-ID: <1446104934.41.0.0783571071989.issue25498@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
priority: normal -> high
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25498>
_______________________________________

From report at bugs.python.org  Thu Oct 29 03:54:17 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 29 Oct 2015 07:54:17 +0000
Subject: [issue25506] test_pprint reuses test_user_dict
In-Reply-To: <1446103535.53.0.629816252417.issue25506@psf.upfronthosting.co.za>
Message-ID: <20151029075409.12531.54366@psf.io>


Roundup Robot added the comment:

New changeset 0e0f3f5195f8 by Serhiy Storchaka in branch '3.5':
Issue25506: Fixed a copy-pasting error in test_pprint.
https://hg.python.org/cpython/rev/0e0f3f5195f8

New changeset 30b6c3bbefc7 by Serhiy Storchaka in branch 'default':
Issue25506: Fixed a copy-pasting error in test_pprint.
https://hg.python.org/cpython/rev/30b6c3bbefc7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25506>
_______________________________________

From report at bugs.python.org  Thu Oct 29 03:56:13 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Oct 2015 07:56:13 +0000
Subject: [issue25506] test_pprint reuses test_user_dict
In-Reply-To: <1446103535.53.0.629816252417.issue25506@psf.upfronthosting.co.za>
Message-ID: <1446105372.98.0.10885291364.issue25506@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you John.

----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25506>
_______________________________________

From report at bugs.python.org  Thu Oct 29 04:01:08 2015
From: report at bugs.python.org (John Mark Vandenberg)
Date: Thu, 29 Oct 2015 08:01:08 +0000
Subject: [issue25505] undefined name 'window' in Tools/scripts/fixdiv.py
In-Reply-To: <1446100670.6.0.312090653047.issue25505@psf.upfronthosting.co.za>
Message-ID: <1446105668.79.0.234187048349.issue25505@psf.upfronthosting.co.za>


Changes by John Mark Vandenberg <jayvdb at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25505>
_______________________________________

From report at bugs.python.org  Thu Oct 29 04:23:01 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Oct 2015 08:23:01 +0000
Subject: [issue24765] Move .idlerc to %APPDATA%\IDLE on Windows
In-Reply-To: <1438360301.06.0.841690925135.issue24765@psf.upfronthosting.co.za>
Message-ID: <1446106981.41.0.689446267962.issue24765@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I do not consider the presence of .idlec in $HOME on Windows to be a problem in itself.  There are numerous applications, unix-derived and otherwise, that do the same with config files.  Very few, if any, have the issue of sharing between multiple simultaneous versions. Installing a new versions deletes the old.  Many do not have the issue of users needing to edit the files.  These would be better candidates for making the switch.

Under current circumstances, I reject the proposal.  However, since I hope circumstances change, I am closing this as 'postponed' rather than 'rejected'.  What I hope we can do, to make me *want* to re-open this.

* Switch from almost-dependable sockets to always-dependable pipes and delete the backup single-process (-n) mode (see IDLE Help).

* Switch from one user-code execution process to one for each editor window (including the shell).

* Let any recent (and installed) python version be chosen for each execution process.

* Improve configuration handling to where the need for user editing is mostly gone.  Example: ability to add a custom theme from a file without the user copy and pasting.

Each of these has benefits in itself, and the net effect would be that most everyone would only need to run the latest IDLE they have and not need to touch the .cfg files.  At this point, we would want to change the format and put them in a different (and less accessible) place anyway.

----------
resolution:  -> postponed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24765>
_______________________________________

From report at bugs.python.org  Thu Oct 29 04:59:57 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Oct 2015 08:59:57 +0000
Subject: [issue8231] Unable to run IDLE without write-access to home directory
In-Reply-To: <1269531569.44.0.352644957859.issue8231@psf.upfronthosting.co.za>
Message-ID: <1446109197.29.0.460045710198.issue8231@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

OK: call GetUserCfgDir once on creation of idleConf instance and set .userdir attribute.  Replace repeated calls in PyShell and Editor with attributes accesses.  I tested that, with patch, IDLE starts and rewrites both breakpoints.lst and recent-files.lst as appropriate.

----------
Added file: http://bugs.python.org/file40893/@cfgdir2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8231>
_______________________________________

From report at bugs.python.org  Thu Oct 29 05:36:16 2015
From: report at bugs.python.org (desbma)
Date: Thu, 29 Oct 2015 09:36:16 +0000
Subject: [issue25156] shutil.copyfile should internally use os.sendfile when
 possible
In-Reply-To: <1442520485.03.0.419427125487.issue25156@psf.upfronthosting.co.za>
Message-ID: <1446111376.6.0.316113163623.issue25156@psf.upfronthosting.co.za>


desbma added the comment:

Thanks for the comment.

> Also, the os.sendfile() doc suggests that some platforms only support writing to sockets, so I definitely think a backup plan is needed.

You are right, the man page clearly says:
> Applications may wish to fall back to read(2)/write(2) in the case
> where sendfile() fails with EINVAL or ENOSYS.

I will improve the code and add tests for conditions where sendfile fails.

I have tested it manually, but I will also add a test with a copy of a file > 4GB (it causes several calls to sendfile).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25156>
_______________________________________

From report at bugs.python.org  Thu Oct 29 05:53:46 2015
From: report at bugs.python.org (eryksun)
Date: Thu, 29 Oct 2015 09:53:46 +0000
Subject: [issue24765] Move .idlerc to %APPDATA%\IDLE on Windows
In-Reply-To: <1438360301.06.0.841690925135.issue24765@psf.upfronthosting.co.za>
Message-ID: <1446112426.22.0.266131764612.issue24765@psf.upfronthosting.co.za>


eryksun added the comment:

On Windows, how about creating a junction (_winapi.CreateJunction in 3.5, or the shell's mklink /j) from ~\.idlerc to %APPDATA%\idle? If ~\.idlerc already exists, it could be moved to %APPDATA%\idle before creating the junction. New code would directly use %APPDATA%\idle, but old code would continue to use ~\.idlerc.

Creating junctions requires no special privilege, but IDLE would need write access to the user's home directory. If write access is denied, at least newer IDLE versions that use %APPDATA% would work.

On Linux, a symbolic link could be created from ~/.idlerc to [$XDG_CONFIG_HOME|~/.config]/idle.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24765>
_______________________________________

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: [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:18:15 2015
From: report at bugs.python.org (Nils Lindemann)
Date: Thu, 29 Oct 2015 10:18:15 +0000
Subject: [issue25444] Py Launch Icon
In-Reply-To: <1445315488.63.0.0387362218843.issue25444@psf.upfronthosting.co.za>
Message-ID: <1446113895.95.0.644768945346.issue25444@psf.upfronthosting.co.za>


Nils Lindemann added the comment:

i see now what you mean. I have this icon too (py 3.5.0 idle icon.png). Something is misconfigured with the icons in the python 3.5.0 windows installer, also python files in explorer have no icons.

Thanks for your hint with the python ideas list, i will post a message there.

----------
Added file: http://bugs.python.org/file40894/py 3.5.0 idle icon.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25444>
_______________________________________

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: [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: [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: [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 10:13:21 2015
From: report at bugs.python.org (Ryosuke Ito)
Date: Thu, 29 Oct 2015 14:13:21 +0000
Subject: [issue25510] fileinput.FileInput.readline() always returns str object
 at the end even if in 'rb' mode
In-Reply-To: <1446127939.75.0.173725539565.issue25510@psf.upfronthosting.co.za>
Message-ID: <1446128001.92.0.460174212625.issue25510@psf.upfronthosting.co.za>


Changes by Ryosuke Ito <rito.0305 at gmail.com>:


----------
components: +Library (Lib)
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25510>
_______________________________________

From report at bugs.python.org  Thu Oct 29 10:13:43 2015
From: report at bugs.python.org (Ryosuke Ito)
Date: Thu, 29 Oct 2015 14:13:43 +0000
Subject: [issue25510] fileinput.FileInput.readline() always returns str object
 at the end even if in 'rb' mode
In-Reply-To: <1446127939.75.0.173725539565.issue25510@psf.upfronthosting.co.za>
Message-ID: <1446128023.46.0.805011079761.issue25510@psf.upfronthosting.co.za>


Changes by Ryosuke Ito <rito.0305 at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25510>
_______________________________________

From report at bugs.python.org  Thu Oct 29 10:36:26 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Oct 2015 14:36:26 +0000
Subject: [issue25508] LogRecord attributes are not tuple,
 when logging only dict
In-Reply-To: <1446114122.71.0.187409652652.issue25508@psf.upfronthosting.co.za>
Message-ID: <1446129386.81.0.565580436728.issue25508@psf.upfronthosting.co.za>


R. David Murray added the comment:

I believe this is due to the way % formatting works, and so is a doc bug.  Vinay will know for sure, of course :)

----------
nosy: +r.david.murray, vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25508>
_______________________________________

From report at bugs.python.org  Thu Oct 29 10:44:24 2015
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Thu, 29 Oct 2015 14:44:24 +0000
Subject: [issue25482] signal.set_wakeup_fd() doesn't work if the signal don't
 have handler
In-Reply-To: <1445859296.06.0.537058365711.issue25482@psf.upfronthosting.co.za>
Message-ID: <1446129864.04.0.17027074771.issue25482@psf.upfronthosting.co.za>


Atsuo Ishimoto added the comment:

> Benjamin Peterson added the comment:
> 
> The OP probably wants something like the Linux-specific signalfd() syscall.

Yes.

Long explanation:

I have an console text editor written in Python/curses(http://kaaedit.github.io/).

This editor didn't work with Python 3.5 because select.select() stop raising InterruptedError.

Following is sample code to reproduce. This code displays size of terminal. If you resize your terminal, screen is updated and new size is displayed.

---------------------------

import curses, select, sys

def main(stdscr):
    i=0
    while True:
        y, x = stdscr.getmaxyx()
        stdscr.addstr(i % 10, 0, "%d x:%d y:%d" % (i, x, y))
        i+=1
        stdscr.refresh()
        try:
            s=select.select([sys.stdin], [], [])   # wait for user input and some sockets.
        except InterruptedError:
            stdscr.addstr(i % 10, 0, "%d InterruptedError" % i)
            i+=1
            continue
        try:
            c=stdscr.get_wch()
        except curses.error:
            stdscr.addstr(i % 10, 0, "%d curses.error" % i)
            i+=1
            continue
        if c == 'q':
            break

curses.wrapper(main)

---------------------------

Resizing terminal generates SIGIWNCH signal. In Python 3.4, select.select() raises InterruptedError when the signal sent. Also, Ncurses library catches the signal and update internal data to reflect new terminal size.

To detect resizing in Python 3.5, I had to set signal handler for SIGWINCH as following sample. 

---------------
import curses, select, sys, signal, os

rfd, wfd = os.pipe()
os.set_blocking(wfd, False)

def f(*args): pass
signal.signal(signal.SIGWINCH, f)
signal.set_wakeup_fd(wfd)

def main(stdscr):
    i=0
    while True:
        y, x = stdscr.getmaxyx()
        stdscr.addstr(i, 0, "%d x:%d y:%d" % (i, x, y))
        i+=1
        stdscr.refresh()
        try:
            s=select.select([sys.stdin, rfd], [], [])
        except InterruptedError:
            stdscr.addstr(i, 0, "%d InterruptedError" % i)
            i+=1
            continue
        try:
            c=stdscr.get_wch()
        except curses.error:
            stdscr.addstr(i, 0, "%d curses.error" % i)
            i+=1
            continue
        if c == 'q':
            break

curses.wrapper(main)
-------------

This code doesn't display updated size of terminal because SIGWINCH signal is not sent to nurses library. I have to call curses.resizeterm() manually to tell new terminal size to nurses.

I don't know this is common situation or not, but In general, it is not safe to set signal handler when the signal is used by third-party library.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25482>
_______________________________________

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: [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 11:33:13 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Oct 2015 15:33:13 +0000
Subject: [issue25510] fileinput.FileInput.readline() always returns str object
 at the end even if in 'rb' mode
In-Reply-To: <1446127939.75.0.173725539565.issue25510@psf.upfronthosting.co.za>
Message-ID: <1446132793.2.0.959506243.issue25510@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Would be nice to add a test in Lib/test/test_fileinput.py.

----------
nosy: +serhiy.storchaka
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25510>
_______________________________________

From report at bugs.python.org  Thu Oct 29 11:51:56 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Oct 2015 15:51:56 +0000
Subject: [issue25510] fileinput.FileInput.readline() always returns str object
 at the end even if in 'rb' mode
In-Reply-To: <1446127939.75.0.173725539565.issue25510@psf.upfronthosting.co.za>
Message-ID: <1446133916.38.0.797482888261.issue25510@psf.upfronthosting.co.za>


R. David Murray added the comment:

We need to think carefully about backward compatibility here.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25510>
_______________________________________

From report at bugs.python.org  Thu Oct 29 11:57:38 2015
From: report at bugs.python.org (Mark Roseman)
Date: Thu, 29 Oct 2015 15:57:38 +0000
Subject: [issue8231] Unable to run IDLE without write-access to home directory
In-Reply-To: <1269531569.44.0.352644957859.issue8231@psf.upfronthosting.co.za>
Message-ID: <1446134258.35.0.267174712591.issue8231@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Better, but alas still not quite. On further investigation, the issue is that a new instance of idleConf is instantiated in the subprocess, which then calls mkdtemp() returning a different name. You can see this by doing 'restart shell' and noting that it will hit the warning you added in GetUserCfgDir.

There are multiple places that the subprocess does access preferences, so just eliminating them is probably not the right way to go.

I'd probably recommend that the user prefs dir be communicated to the subprocess somehow. Two suggestions are via adding a command line parameter where we launch the subprocess (build_subprocess_arglist), or have the subprocess get it via 'remotecall' when it starts up (perhaps in MyHandler.handle). Either way this would then need to be communicated to idleConf so it uses that directory.

Would there be a preference and/or any other alternatives?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8231>
_______________________________________

From report at bugs.python.org  Thu Oct 29 12:00:11 2015
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 29 Oct 2015 16:00:11 +0000
Subject: [issue25498] Python 3.4.3 core dump with simple sample code
In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za>
Message-ID: <1446134411.2.0.398197225093.issue25498@psf.upfronthosting.co.za>


Stefan Krah added the comment:

We should ultimately do something like I suggested in msg235256.

Everything else is a hack (N.B.: the issues that 1da9630e9b7f
tried to fix were also hacks, so it isn't really the fault of
that commit).

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25498>
_______________________________________

From report at bugs.python.org  Thu Oct 29 12:08:42 2015
From: report at bugs.python.org (Mark Roseman)
Date: Thu, 29 Oct 2015 16:08:42 +0000
Subject: [issue25507] IDLE: user code 'import tkinter;
 tkinter.font' should fail
In-Reply-To: <1446113442.78.0.389498275803.issue25507@psf.upfronthosting.co.za>
Message-ID: <1446134922.64.0.0759154259126.issue25507@psf.upfronthosting.co.za>


Mark Roseman added the comment:

This (restructuring/refactoring to minimize the subprocess imports) does definitely sound like the right approach. There will be other benefits to breaking up PyShell a bit too..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25507>
_______________________________________

From report at bugs.python.org  Thu Oct 29 12:27:13 2015
From: report at bugs.python.org (Joshua Bronson)
Date: Thu, 29 Oct 2015 16:27:13 +0000
Subject: [issue17006] Add advice on best practices for hashing secrets
In-Reply-To: <1358758082.76.0.415880124971.issue17006@psf.upfronthosting.co.za>
Message-ID: <1446136033.92.0.124281138567.issue17006@psf.upfronthosting.co.za>


Changes by Joshua Bronson <jabronson at gmail.com>:


----------
nosy: +jab

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17006>
_______________________________________

From report at bugs.python.org  Thu Oct 29 12:27:27 2015
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 29 Oct 2015 16:27:27 +0000
Subject: [issue25501] Use async/await through asyncio docs
In-Reply-To: <1446071453.74.0.752401915255.issue25501@psf.upfronthosting.co.za>
Message-ID: <1446136047.84.0.7324888002.issue25501@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Once 3.4.4 launches the need to keep the docs synced with a version that doesn't support async/await goes away. And worrying about 3.3 isn't necessary since asyncio was added in 3.4.

So once 3.4.4 is released and we close the 3.4 branch to bugfixes can we update the docs in asyncio and add a note at the top saying the examples all use async/await from 3.5 and if you need 3.4 compatibility to please look at the 3.4 docs? Otherwise how long do you want to wait until we can start using async/await in the documentation? My worry is that people are going to blindly copy the examples and tweak them for their needs since the asyncio docs are a bit dense and thus just simply overlook the fact that async/await exists.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25501>
_______________________________________

From report at bugs.python.org  Thu Oct 29 13:09:25 2015
From: report at bugs.python.org (Vilnis Termanis)
Date: Thu, 29 Oct 2015 17:09:25 +0000
Subject: [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
In-Reply-To: <1445681395.35.0.393874869917.issue25469@psf.upfronthosting.co.za>
Message-ID: <1446138565.12.0.77712047836.issue25469@psf.upfronthosting.co.za>


Vilnis Termanis added the comment:

I realise that having type bug type of "performance" means it's less likely to be looked at than if I had marked is as "behaviour" or "resource usage" (which would not be completely unfair, I think).

Also, the patch should be applicable to 2.7 and 3.2 through to 3.5 (despite versions having been removed from the bug report).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25469>
_______________________________________

From report at bugs.python.org  Thu Oct 29 13:20:45 2015
From: report at bugs.python.org (Brian Sutherland)
Date: Thu, 29 Oct 2015 17:20:45 +0000
Subject: [issue25489] sys.exit() caught in exception handler
In-Reply-To: <1446043794.95.0.181430831888.issue25489@psf.upfronthosting.co.za>
Message-ID: <20151029172041.GA38847@Admins-MacBook-Air.local>


Brian Sutherland added the comment:

On Wed, Oct 28, 2015 at 02:49:55PM +0000, R. David Murray wrote:
> 
> R. David Murray added the comment:
> 
> Using sys.exit means you are depending on garbage collection to clean
> up all of your program's resources.  In the general case this is a bad
> idea.  A better design is to call loop.stop, and then do cleanup
> (which might involve calling some wait_closed functions via
> loop.run_until_complete).  If you just call sys.exit, your resources
> may not get cleaned up correctly, or may not get cleaned up correctly
> somewhat randomly due to the indeterminacies in the order in which
> garbage collection is done.  This may not matter for a simple program,
> but I find it makes it easier for me if I just do it "the right way"
> always :)

I think it depends on the problem, sometimes "crash-only" software is
safer. You have to design for immediate failure anyway, can't stop those
pesky hardware failures. So if you always immediately crash there is
only one, well-tested path to stopping a program.

Also saves a lot of cleanup code writing;)

Hmm, I suppose that means I should really be using os._exit(42) to avoid
garbage collection...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25489>
_______________________________________

From report at bugs.python.org  Thu Oct 29 13:50:38 2015
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 29 Oct 2015 17:50:38 +0000
Subject: [issue25509] PyImport_ImportModule inaccurately described
In-Reply-To: <1446120404.56.0.248022316134.issue25509@psf.upfronthosting.co.za>
Message-ID: <1446141038.87.0.352479141913.issue25509@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25509>
_______________________________________

From report at bugs.python.org  Thu Oct 29 13:51:55 2015
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 29 Oct 2015 17:51:55 +0000
Subject: [issue25509] PyImport_ImportModule inaccurately described
In-Reply-To: <1446120404.56.0.248022316134.issue25509@psf.upfronthosting.co.za>
Message-ID: <1446141115.61.0.977760571225.issue25509@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Semantic change was probably because of the lack of import hook support which is required since Python 3.3. So the docs just need to be fixed rather than the semantics.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25509>
_______________________________________

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: [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:26:37 2015
From: report at bugs.python.org (Bernd Dietzel)
Date: Thu, 29 Oct 2015 19:26:37 +0000
Subject: [issue24778] mailcap.findmatch: document shell command Injection
 danger in filename parameter
In-Reply-To: <1438503907.2.0.780338961431.issue24778@psf.upfronthosting.co.za>
Message-ID: <1446146797.06.0.358245124953.issue24778@psf.upfronthosting.co.za>


Bernd Dietzel added the comment:

My patch for mailcap.py. Please check and apply my patch please.

1) I have removed the os.system() calls for security reasons.

2) New "findmtach_list()" function witch returns the commandline as a [list] witch can be passed to subprocess instead of passing it to os.system().

3) New run() function to execute the cmd_list with subprocess. 

4) The test() function now uses findmatch_list() and run() instead of the old findmatch() and os.system() calls.  

5) The subst() function is now shorter an does a quote(filename) when its replacing %s with a filename.

6) The "old" findmatch() function is still there if the user still likes to have the commandline as a "string". 
Attention ! With this old findmatch() function it's still possible that a shell command in the filename like '$(ls).txt' will be executed when the users passes the string to os.system() outside the mailcap script. Use findmatch() only for backwards compatibility.

7) Use the new findmatch_list() an run() for future projects.

8) Add 1)-7) to the docs

Thank you.

----------
Added file: http://bugs.python.org/file40897/mailcap patch.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24778>
_______________________________________

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: [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 15:51:00 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Oct 2015 19:51:00 +0000
Subject: [issue25513] collections.abc.Iterable don't implement __bool__
In-Reply-To: <1446147504.48.0.238943227833.issue25513@psf.upfronthosting.co.za>
Message-ID: <1446148260.68.0.416827252598.issue25513@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is as designed.  The only method needed for something to qualify as an Iterable is __iter__, thus this is the only method defined on the ABC.  If you want your Iterable to be usable in a boolean test, add the __bool__ method to your concrete class.

In fact, you will note that no ABCs define __bool__.

Likewise __len__ is not part of being an Iterator, and in fact in the general case Iterators do not have a len (a given Iterator might be infinite, or it might not be practical to calculate the len).

----------
nosy: +r.david.murray
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25513>
_______________________________________

From report at bugs.python.org  Thu Oct 29 16:12:28 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 29 Oct 2015 20:12:28 +0000
Subject: [issue25501] Use async/await through asyncio docs
In-Reply-To: <1446071453.74.0.752401915255.issue25501@psf.upfronthosting.co.za>
Message-ID: <1446149548.48.0.382565913351.issue25501@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Honestly I think it's better if most people keep using coroutine/yield-from instead of async/await for a few more releases; their code will be more portable, since it takes forever to update old datacenters. We put in async/await with an eye towards the future. But we're keeping yield-from around for a long time too. And that's also why we support asyncio for 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25501>
_______________________________________

From report at bugs.python.org  Thu Oct 29 16:34:26 2015
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 29 Oct 2015 20:34:26 +0000
Subject: [issue25501] Use async/await through asyncio docs
In-Reply-To: <1446071453.74.0.752401915255.issue25501@psf.upfronthosting.co.za>
Message-ID: <1446150866.31.0.290280923172.issue25501@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25501>
_______________________________________

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: [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 17:31:59 2015
From: report at bugs.python.org (Laura Creighton)
Date: Thu, 29 Oct 2015 21:31:59 +0000
Subject: [issue25514] better startup error messages in IDLE when stdlib
 modules shadowed
In-Reply-To: <1446151640.74.0.583734209916.issue25514@psf.upfronthosting.co.za>
Message-ID: <1446154319.71.0.712541103832.issue25514@psf.upfronthosting.co.za>


Laura Creighton added the comment:

Note that the full path name of the file that is doing the shadow
is of important interest to teachers.  We get machines will all sorts of garbage written on them -- the amount of hell caused by a misnamed turtle.py is hard to measure -- and anything as helps in the finding of the file as needs removing or renaming will be eternally welcome.

----------
nosy: +lac

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25514>
_______________________________________

From report at bugs.python.org  Thu Oct 29 17:36:17 2015
From: report at bugs.python.org (Laura Creighton)
Date: Thu, 29 Oct 2015 21:36:17 +0000
Subject: [issue25514] better startup error messages in IDLE when stdlib
 modules shadowed
In-Reply-To: <1446151640.74.0.583734209916.issue25514@psf.upfronthosting.co.za>
Message-ID: <1446154577.3.0.0537030012379.issue25514@psf.upfronthosting.co.za>


Laura Creighton added the comment:

s/machines will/machines with/

(I was tired.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25514>
_______________________________________

From report at bugs.python.org  Thu Oct 29 18:09:31 2015
From: report at bugs.python.org (Camilla Montonen)
Date: Thu, 29 Oct 2015 22:09:31 +0000
Subject: [issue25041] document AF_PACKET socket address format
In-Reply-To: <1441804077.41.0.782475265278.issue25041@psf.upfronthosting.co.za>
Message-ID: <1446156571.19.0.0237866378849.issue25041@psf.upfronthosting.co.za>


Camilla Montonen added the comment:

Provided patch provides documentation for the AF_PACKET address_family.

----------
keywords: +patch
nosy: +Winterflower
Added file: http://bugs.python.org/file40898/af_packet_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25041>
_______________________________________

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: [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 18:31:26 2015
From: report at bugs.python.org (Alex Gaynor)
Date: Thu, 29 Oct 2015 22:31:26 +0000
Subject: [issue25515] Always use os.urandom for generating uuid4s
In-Reply-To: <1446157856.8.0.141271153447.issue25515@psf.upfronthosting.co.za>
Message-ID: <1446157886.49.0.401151483056.issue25515@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

(Note that the speed difference would be even bigger on a recent python, 2.7.3 was before the file descriptor was cached for os.urandom)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25515>
_______________________________________

From report at bugs.python.org  Thu Oct 29 18:33:04 2015
From: report at bugs.python.org (John Mark Vandenberg)
Date: Thu, 29 Oct 2015 22:33:04 +0000
Subject: [issue25515] Always use os.urandom for generating uuid4s
In-Reply-To: <1446157856.8.0.141271153447.issue25515@psf.upfronthosting.co.za>
Message-ID: <1446157984.72.0.651310161819.issue25515@psf.upfronthosting.co.za>


Changes by John Mark Vandenberg <jayvdb at gmail.com>:


----------
nosy: +John.Mark.Vandenberg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25515>
_______________________________________

From report at bugs.python.org  Thu Oct 29 18:58:35 2015
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 29 Oct 2015 22:58:35 +0000
Subject: [issue25515] Always use os.urandom for generating uuid4s
In-Reply-To: <1446157856.8.0.141271153447.issue25515@psf.upfronthosting.co.za>
Message-ID: <20151029185831.5fce5d05@limelight.wooz.org>


Barry A. Warsaw added the comment:

On Oct 29, 2015, at 10:30 PM, Alex Gaynor wrote:

>Right now uuid4 can be implemented one of 3 ways:

If you're hacking on the uuid module, keep in mind issue22807

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25515>
_______________________________________

From report at bugs.python.org  Thu Oct 29 19:21:46 2015
From: report at bugs.python.org (Anne Rosa Wangnick)
Date: Thu, 29 Oct 2015 23:21:46 +0000
Subject: [issue11796] Comprehensions in a class definition mostly cannot
 access class variable
In-Reply-To: <1302180921.17.0.22284518515.issue11796@psf.upfronthosting.co.za>
Message-ID: <1446160906.71.0.466072881851.issue11796@psf.upfronthosting.co.za>


Anne Rosa Wangnick added the comment:

With https://bugs.python.org/issue13557 closed, this one should be reopened to amend 6.2.8 Generator expressions: "[However, the leftmost for clause is immediately evaluated] (in the local context)[, so that an error produced by it can be seen ...]"

----------
nosy: +Anne Rosa Wangnick

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11796>
_______________________________________

From report at bugs.python.org  Thu Oct 29 19:25:28 2015
From: report at bugs.python.org (desbma)
Date: Thu, 29 Oct 2015 23:25:28 +0000
Subject: [issue25156] shutil.copyfile should internally use os.sendfile when
 possible
In-Reply-To: <1442520485.03.0.419427125487.issue25156@psf.upfronthosting.co.za>
Message-ID: <1446161128.54.0.375015233262.issue25156@psf.upfronthosting.co.za>


desbma added the comment:

I played a bit with Unix domain sockets, and it appears you can not open them like a file with open().
So they do no work with the current implementation of shutil.copyfile anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25156>
_______________________________________

From report at bugs.python.org  Thu Oct 29 19:37:58 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 29 Oct 2015 23:37:58 +0000
Subject: [issue25498] Python 3.4.3 core dump with simple sample code
In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za>
Message-ID: <1446161878.07.0.265717647024.issue25498@psf.upfronthosting.co.za>


Martin Panter added the comment:

Before the Issue 22896 changes, PyObject_AsWriteBuffer() was used, which requests a buffer with the PyBUF_WRITABLE flag. Currently we use ?w*? argument parsing format, which also uses PyBUF_WRITABLE. (Incidentally, I suspect the C-contiguity check is redundant for ?w*?; non-contiguous buffers trigger the ?read-write? error instead.)

Now Eryksun?s patch changes to PyMemoryView_FromObject(), which requests a buffer with the PyBUF_FULL_RO flag (the most liberal), and only then checks for writability and contiguity. Could this be a problem for some kind of object that returns different buffers depending on the request flags?

I agree that the existing buffer and memory view APIs don?t seem to be very practical and well understood. PyMemoryView_FromBuffer() is also used in the ?io? module. It doesn?t even try to save a reference to the underlying buffers, meaning it is possible for Python code to write into freed memory by saving the memory view object passed to the readinto() method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25498>
_______________________________________

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: [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  Thu Oct 29 21:01:11 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Oct 2015 01:01:11 +0000
Subject: [issue25514] better startup error messages in IDLE when stdlib
 modules shadowed
In-Reply-To: <1446151640.74.0.583734209916.issue25514@psf.upfronthosting.co.za>
Message-ID: <1446166871.69.0.0358361838091.issue25514@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Laura, I did not understand from your python-list post that you were complaining about shadowing disabling IDLE itself, as opposed to user code.  That is partly because you followed up on Peter Otten complaining because IDLE tries to run user code the same way that python does.

The solution for IDLE itself is for IDLE to do what python does on startup, which is to ensure that the stdlib modules it needs are indeed imported from the stdlib.  I presume that python only prepends '' to sys.path *after* it does its imports.  Example:

>>> import sys; list(sys.modules)
[..., abc, ...]
C:\Users\Terry>echo "print('abc')" >abc  # verified with dir
C:\Users\Terry>python
>>> >>> import sys; sys.modules['abc'].__file__
'C:\\Programs\\Python35\\lib\\abc.py'

So IDLE should remove sys.path[0] from sys.path and, in the user process, restore it only after normal imports. Ignore -n single process mode for now.

Aside from this, the popup message needs to be changed, but better that it occur less often (by the fix above) or never (by switching to pipes?).

As for user code: I have in mind that there should be a doc how-to about tracebacks and exception messages, with a sections giving possible explanations and remedies for specific messages, such as the above.  This I would make messages like the above a link to the how-to entry.  In the meanwhile, we could consider a special case search of error message lines.

-I just noticed that this issue is the result of a pydev thread. Off to read that.

----------
stage:  -> needs patch
type: enhancement -> behavior
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25514>
_______________________________________

From report at bugs.python.org  Thu Oct 29 21:17:19 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Oct 2015 01:17:19 +0000
Subject: [issue25514] better startup error messages in IDLE when stdlib
 modules shadowed
In-Reply-To: <1446151640.74.0.583734209916.issue25514@psf.upfronthosting.co.za>
Message-ID: <1446167839.45.0.226869592746.issue25514@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

"I think that removing '' from sys.path, so that IDLE can run, is better than a nicer warning that it cannot run. This, of course, requires that sys not be shadowed, so that sys.path can be accessed."  So after importing sys, we should check sys.__file__, or do the manipulation in try: except: <post error message>.  This will be part of a much more careful startup sequence.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25514>
_______________________________________

From report at bugs.python.org  Thu Oct 29 21:43:51 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Oct 2015 01:43:51 +0000
Subject: [issue25514] better startup error messages in IDLE when stdlib
 modules shadowed
In-Reply-To: <1446151640.74.0.583734209916.issue25514@psf.upfronthosting.co.za>
Message-ID: <1446169431.68.0.301007428621.issue25514@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Either tkinter and tkinter.messagebox or subprocess must be imported to display a message when IDLE is started from an icon, and there is no console.  With subprocess, '''python -i -c "print('Cannot start IDLE (or whatever)')"''' should work.  If nothing else, this would be a way to display a message when import tkinter fails.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25514>
_______________________________________

From report at bugs.python.org  Thu Oct 29 21:57:45 2015
From: report at bugs.python.org (Donald Stufft)
Date: Fri, 30 Oct 2015 01:57:45 +0000
Subject: [issue25515] Always use os.urandom for generating uuid4s
In-Reply-To: <1446157856.8.0.141271153447.issue25515@psf.upfronthosting.co.za>
Message-ID: <1446170265.5.0.0664658664317.issue25515@psf.upfronthosting.co.za>


Donald Stufft added the comment:

This looks like a good idea to me, faster and more secure seems like a total win.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25515>
_______________________________________

From report at bugs.python.org  Thu Oct 29 22:00:02 2015
From: report at bugs.python.org (Nir Soffer)
Date: Fri, 30 Oct 2015 02:00:02 +0000
Subject: [issue25516] threading.Condition._is_owned() is wrong when using
 threading.Lock
In-Reply-To: <1446165392.31.0.717642417411.issue25516@psf.upfronthosting.co.za>
Message-ID: <1446170402.66.0.775779157774.issue25516@psf.upfronthosting.co.za>


Nir Soffer added the comment:

The issue was introduced in this commit:

commit 8cb1ccbb8b9ed01c26d2c5be7cc86682e525dce7
Author: Guido van Rossum <guido at python.org>
Date:   Thu Apr 9 22:01:42 1998 +0000

    New Java-style threading module.  The doc strings are in a separate module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25516>
_______________________________________

From report at bugs.python.org  Thu Oct 29 22:06:50 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 30 Oct 2015 02:06:50 +0000
Subject: [issue25512] apparent memory leak using ctypes
In-Reply-To: <1446146196.34.0.00289106474644.issue25512@psf.upfronthosting.co.za>
Message-ID: <1446170810.08.0.737428432167.issue25512@psf.upfronthosting.co.za>


Martin Panter added the comment:

I am running your script with the Python 3.5.0 from Arch Linux on an x86-64 computer. The reported numbers slowly increase and then plateau at 221 million:

$ python ctype_stressor.py
       1  0.0000000e+00  3.8010880e+07
  100000  2.8538793e+00  1.4648934e+08
  200000  2.9961207e+00  1.5189606e+08
  300000  3.1383621e+00  1.5730278e+08
  400000  3.2806034e+00  1.6270950e+08
  500000  3.4512931e+00  1.6919757e+08
  600000  3.5935345e+00  1.7460429e+08
  700000  3.7357759e+00  1.8001101e+08
  800000  3.8780172e+00  1.8541773e+08
  900000  4.0202586e+00  1.9082445e+08
 1000000  4.1909483e+00  1.9731251e+08
 1100000  4.3331897e+00  2.0271923e+08
 1200000  4.4754310e+00  2.0812595e+08
 1300000  4.6176724e+00  2.1353267e+08
 1400000  4.7599138e+00  2.1893939e+08
 1500000  4.7883621e+00  2.2002074e+08
 1600000  4.7883621e+00  2.2002074e+08
. . .
 2700000  4.7883621e+00  2.2002074e+08
 2800000  4.8043103e+00  2.2062694e+08
. . .
 4100000  4.8043103e+00  2.2062694e+08
 4200000  4.8133621e+00  2.2097101e+08
. . .
13000000  4.8133621e+00  2.2097101e+08

Monitoring the process with ?htop?, I see the total virtual memory (VIRT) ramping up to about 79 MiB, and then jumping back to about 62 MiB, and the resident physical memory (RES) ramps within 36?53 MiB in a similar pattern.

Similarly, Python 2.7.10 ramps within RES = 32?43 MiB, and your script is showing 177 million:

11400000  5.5962126e+00  1.7691443e+08

Is this the same as what you are seeing? How long do you have to you run your script for?

The memory figures in your script seem to be out by a factor of four, assuming the third column is meant to be a number of bytes. But I don?t think there is a memory leak. At worst there is an unexpected dependency cycle between objects, meaning the memory builds up a bit until the garbage collector runs.

----------
nosy: +martin.panter
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25512>
_______________________________________

From report at bugs.python.org  Thu Oct 29 22:09:59 2015
From: report at bugs.python.org (Nir Soffer)
Date: Fri, 30 Oct 2015 02:09:59 +0000
Subject: [issue25516] threading.Condition._is_owned() is wrong when using
 threading.Lock
In-Reply-To: <1446165392.31.0.717642417411.issue25516@psf.upfronthosting.co.za>
Message-ID: <1446170999.85.0.376559438521.issue25516@psf.upfronthosting.co.za>


Changes by Nir Soffer <nirsof at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file40900/0001-Issue-25516-threading.Condition._is_owned-fails-when.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25516>
_______________________________________

From report at bugs.python.org  Thu Oct 29 23:04:45 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 30 Oct 2015 03:04:45 +0000
Subject: [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1446174285.77.0.67042339296.issue25495@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for bringing this up, it has often bugged me.

My understanding, based on the original wording and places where this is used, is that the data is often pre-processed into 57-byte chunks, rather than post-processing it. Maybe it is worthwhile restoring that info. It should help understanding the presence of the newline parameter (or why a newline is always added in 3.5).

Also, the link between RFC 4648 and this function could be made even more explicit. Maybe move ?as defined? into the first sentence, or change ?the Base64 output? to ?the function?s output?.

----------
nosy: +martin.panter
stage:  -> patch review
versions: +Python 2.7, Python 3.4, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25495>
_______________________________________

From report at bugs.python.org  Thu Oct 29 23:14:07 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Oct 2015 03:14:07 +0000
Subject: [issue25482] signal.set_wakeup_fd() doesn't work if the signal don't
 have handler
In-Reply-To: <1445859296.06.0.537058365711.issue25482@psf.upfronthosting.co.za>
Message-ID: <1446174847.48.0.547994124857.issue25482@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It's very easy to get the same behaviour on Python 3.4 (without PEP 475) and Python 3.5 (with PEP 475). Just add the following code at the top of your example:
----
import signal

def sighandler(signum, frame):
    raise InterruptedError

signal.signal(signal.SIGWINCH, sighandler)
---

You can use any Python exception, not only InterruptedError.

PEP 475 only changes the behaviour on signals with an handler which doesn't raise an exception.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25482>
_______________________________________

From report at bugs.python.org  Thu Oct 29 23:33:43 2015
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Fri, 30 Oct 2015 03:33:43 +0000
Subject: [issue25482] signal.set_wakeup_fd() doesn't work if the signal don't
 have handler
In-Reply-To: <1445859296.06.0.537058365711.issue25482@psf.upfronthosting.co.za>
Message-ID: <1446176023.24.0.0656408248728.issue25482@psf.upfronthosting.co.za>


Atsuo Ishimoto added the comment:

Thank you for good sample. This should be written in PEP 475.

But installing new signal handler can cause different behavior. 

As in my previous example, if other 3rd party libraries(ncurses in my case) need to handle the signal, signal is consumed by Python handler and not delivered to the library.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25482>
_______________________________________

From report at bugs.python.org  Thu Oct 29 23:40:45 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 30 Oct 2015 03:40:45 +0000
Subject: [issue25515] Always use os.urandom for generating uuid4s
In-Reply-To: <1446157856.8.0.141271153447.issue25515@psf.upfronthosting.co.za>
Message-ID: <20151030034041.10156.73396@psf.io>


Roundup Robot added the comment:

New changeset 24bdc4940e81 by Benjamin Peterson in branch '2.7':
always use os.urandom for the uuid4 algorithm (closes #25515)
https://hg.python.org/cpython/rev/24bdc4940e81

New changeset 70be1f9c9255 by Benjamin Peterson in branch '3.5':
always use os.urandom for the uuid4 algorithm (closes #25515)
https://hg.python.org/cpython/rev/70be1f9c9255

New changeset 756d040aa8e8 by Benjamin Peterson in branch 'default':
merge 3.5 (#25515)
https://hg.python.org/cpython/rev/756d040aa8e8

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25515>
_______________________________________

From report at bugs.python.org  Fri Oct 30 00:00:00 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Oct 2015 04:00:00 +0000
Subject: [issue8231] Unable to run IDLE without write-access to home directory
In-Reply-To: <1269531569.44.0.352644957859.issue8231@psf.upfronthosting.co.za>
Message-ID: <1446177600.87.0.0819720099389.issue8231@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I cannot currently think of any reason why the subprocess *needs* to access idleConf, so I want to put this on hold while investigating whether the accesses can be eliminated as part of #25507.

----------
dependencies: +IDLE: user code 'import tkinter; tkinter.font' should fail

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8231>
_______________________________________

From report at bugs.python.org  Fri Oct 30 00:11:38 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 30 Oct 2015 04:11:38 +0000
Subject: [issue25504] undefined name 'modules' in
 Tools/freeze/checkextensions_win32.py
In-Reply-To: <1446098438.41.0.333583396079.issue25504@psf.upfronthosting.co.za>
Message-ID: <20151030041135.8593.60233@psf.io>


Roundup Robot added the comment:

New changeset 31fd613a40aa by Benjamin Peterson in branch '2.7':
fix usage of undefined name (#25504)
https://hg.python.org/cpython/rev/31fd613a40aa

New changeset 114fb81a08e3 by Benjamin Peterson in branch '3.4':
fix usage of undefined name (#25504)
https://hg.python.org/cpython/rev/114fb81a08e3

New changeset e6ab376f575e by Benjamin Peterson in branch '3.5':
merge 3.4 (#25504)
https://hg.python.org/cpython/rev/e6ab376f575e

New changeset 2de616269f0e by Benjamin Peterson in branch 'default':
merge 3.5 (#25504)
https://hg.python.org/cpython/rev/2de616269f0e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25504>
_______________________________________

From report at bugs.python.org  Fri Oct 30 00:11:49 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 30 Oct 2015 04:11:49 +0000
Subject: [issue25504] undefined name 'modules' in
 Tools/freeze/checkextensions_win32.py
In-Reply-To: <1446098438.41.0.333583396079.issue25504@psf.upfronthosting.co.za>
Message-ID: <1446178309.66.0.87907285008.issue25504@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25504>
_______________________________________

From report at bugs.python.org  Fri Oct 30 00:15:29 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Oct 2015 04:15:29 +0000
Subject: [issue25507] IDLE: user code 'import tkinter;
 tkinter.font' should fail
In-Reply-To: <1446113442.78.0.389498275803.issue25507@psf.upfronthosting.co.za>
Message-ID: <1446178529.9.0.365714243226.issue25507@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

#8231 will benefit if indirect imports of configHandler and idleConf into the user process can be eliminated.  I do not currently believe it is needed.  Not importing PyShell will go part way.

AutoComplete imports idleConf to get the popup delay. run imports AutoComplete to access fetch_completions -- in particular, the part after 'else', after the logic to determine which process the code is in and if in the idle process, whether to fetch in the idle process (-n) or user process.  Fetch_completions is a function and not properly a method -- it only uses self to access get_entity.  Get_entity is a two line function the also should not be a method.  It is only called at the one place and the only reason to not put in inline would be for testing.  The code after 'else' could be made a function in a separate module and the AutoComplete import eliminated.

CallTip does not import idleConf, nor does CallTipWindow or HyperParser or PyParse.

----------
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25507>
_______________________________________

From report at bugs.python.org  Fri Oct 30 01:25:52 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Oct 2015 05:25:52 +0000
Subject: [issue25507] IDLE: user code 'import tkinter;
 tkinter.font' should fail
In-Reply-To: <1446113442.78.0.389498275803.issue25507@psf.upfronthosting.co.za>
Message-ID: <1446182752.94.0.742881025955.issue25507@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

To continue: CallTips.Calltips has a similar here-or-there logic that decides where to execute the actual get-calltip-logic.  In this case,  get_entity and get_argspec are already functions rather than methods (I changed get_entity from method to function in 02b4c62ce393.) The functions could be moved into a different module with the completions function.

RemoteDebugger imports Debugger which imports WindowList, ScrolledList, and macosxSupport, all without idleConf imports.

RemoteObjectBrowser import rpc, both without idleConf.  run also imports rpc.

StackViewer imports TreeWidget and ObjectBrowser, which are not issues.  It also imports PyShell for PyShellFileList, which would be an issue, except that this is only for the htest function _stack_viewer.  I will move the test-specific import into the function, as is my current policy.

IOBinding is imported for IOBinding.encoding. The code that calculates this could be put anywhere.  This is fortunate because IOBinding imports idleConf and three tkinter modules.

Conclusion: moving about 2-300 lines of code (about 6 objects) from PyShell, AutoComplete, and IOBinding into run (currently about 400 lines) would eliminate idleConf from the user process.  I did not check tkinter imports for all the above, but it might also fix the tkinter namespace problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25507>
_______________________________________

From report at bugs.python.org  Fri Oct 30 01:47:55 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Oct 2015 05:47:55 +0000
Subject: [issue25507] IDLE: user code 'import tkinter;
 tkinter.font' should fail
In-Reply-To: <1446113442.78.0.389498275803.issue25507@psf.upfronthosting.co.za>
Message-ID: <1446184075.87.0.190141550877.issue25507@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The subprocess command is built in PyShell.ModifiedInterpreter method build_subprocess_arglist (l.404). It imports run and calls run.main(args).

The test for this issue would be to import run and check that sys.modules does not contain configHandler and that tkinter does not contain any of its possible submodules.

----------
stage: needs patch -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25507>
_______________________________________

From report at bugs.python.org  Fri Oct 30 01:53:51 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Oct 2015 05:53:51 +0000
Subject: [issue8231] Unable to run IDLE without write-access to home directory
In-Reply-To: <1269531569.44.0.352644957859.issue8231@psf.upfronthosting.co.za>
Message-ID: <1446184431.83.0.468451801865.issue8231@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Without being able to make my homedir read-only, I don't, of course, see the messages.  Since run does not use idleConf (I am now sure), you should have been able to proceed after clicking away the admittedly obnoxious repeat messages.  The old extraneous user-process temporary should disappear when you restart.  Can you check that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8231>
_______________________________________

From report at bugs.python.org  Fri Oct 30 02:48:17 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 30 Oct 2015 06:48:17 +0000
Subject: [issue25507] IDLE: user code 'import tkinter;
 tkinter.font' should fail
In-Reply-To: <1446113442.78.0.389498275803.issue25507@psf.upfronthosting.co.za>
Message-ID: <20151030064814.74081.35868@psf.io>


Roundup Robot added the comment:

New changeset a37ea1d56e98 by Terry Jan Reedy in branch '2.7':
Issue #25507: move test-specific imports to test function (idlelib.IOBinding).
https://hg.python.org/cpython/rev/a37ea1d56e98

New changeset 38b6b7253ba1 by Terry Jan Reedy in branch '3.4':
Issue #25507: move test-specific imports to test function (idlelib.IOBinding).
https://hg.python.org/cpython/rev/38b6b7253ba1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25507>
_______________________________________

From report at bugs.python.org  Fri Oct 30 03:03:26 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 30 Oct 2015 07:03:26 +0000
Subject: [issue25512] apparent memory leak using ctypes
In-Reply-To: <1446146196.34.0.00289106474644.issue25512@psf.upfronthosting.co.za>
Message-ID: <1446188606.08.0.283439241102.issue25512@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

cast() always creates a ref cycle, which is probably what you are seeing.

>>> from ctypes import c_double, cast, POINTER
>>> samples = (c_double*23)()
>>> cast(samples, POINTER(c_double))
<__main__.LP_c_double object at 0x7f33bc920560>
>>> samples._objects
{139860183544448: <__main__.c_double_Array_23 object at 0x7f33bc8ef280>}
>>> samples
<__main__.c_double_Array_23 object at 0x7f33bc8ef280>

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25512>
_______________________________________

From report at bugs.python.org  Fri Oct 30 03:11:22 2015
From: report at bugs.python.org (Evgeny Kapun)
Date: Fri, 30 Oct 2015 07:11:22 +0000
Subject: [issue18531] Undocumented different between METH_KEYWORDS and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <1446189082.16.0.275745729226.issue18531@psf.upfronthosting.co.za>


Changes by Evgeny Kapun <abacabadabacaba at gmail.com>:


----------
nosy: +abacabadabacaba

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18531>
_______________________________________

From report at bugs.python.org  Fri Oct 30 03:17:05 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 30 Oct 2015 07:17:05 +0000
Subject: [issue25041] document AF_PACKET socket address format
In-Reply-To: <1441804077.41.0.782475265278.issue25041@psf.upfronthosting.co.za>
Message-ID: <1446189425.07.0.534394686494.issue25041@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks! The patch looks good to me. I left a few minor comments on Rietveld: http://bugs.python.org/review/25041/

----------
nosy: +berker.peksag
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25041>
_______________________________________

From report at bugs.python.org  Fri Oct 30 05:27:04 2015
From: report at bugs.python.org (Brian Sutherland)
Date: Fri, 30 Oct 2015 09:27:04 +0000
Subject: [issue25489] sys.exit() caught in exception handler
In-Reply-To: <CAP7+vJJe_HgLCPFb9UiMsdzXL6SA8naKdWKMc-9ASy-M9QHJkQ@mail.gmail.com>
Message-ID: <20151030092700.GA47689@Admins-MacBook-Air.local>


Brian Sutherland added the comment:

On Wed, Oct 28, 2015 at 03:32:36PM +0000, Guido van Rossum wrote:
> 
> Guido van Rossum added the comment:
> 
> How about we extend loop.stop() so that you can pass it an exception to
> raise once the loop is stopped? This exception would then be thrown out of
> run_forever(). There may be some delay (callbacks already scheduled will
> run first) but it is how things were meant to be.

It is better than the current situation where to call loop.stop() and
have the correct exit code I would need to resort to a global variable.

I would then probably try to write an exception handler like this:

    def exception_handler(loop, context):
        loop.stop(context.get('exception', Exception('unknown error')))

And then hope I don't lose the traceback!

> FWIW this isn't really enough to ensure cleanup happens before destructors
> run -- when the loop exits, tasks may still be active unless you keep track
> of all of them and explicitly cancel them (and run the loop until they have
> processed the cancellation).

At least in my situation I don't think this is a problem, the objective
is to shut down the process quickly to prevent bad things happening.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25489>
_______________________________________

From report at bugs.python.org  Fri Oct 30 06:02:26 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Oct 2015 10:02:26 +0000
Subject: [issue25482] signal.set_wakeup_fd() doesn't work if the signal don't
 have handler
In-Reply-To: <1446176023.24.0.0656408248728.issue25482@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwa6kEqL+U7cnQtxs_VZeNLTLxf-X-2RZmfJE2GKeUyP6w@mail.gmail.com>


STINNER Victor added the comment:

> As in my previous example, if other 3rd party libraries(ncurses in my case) need to handle the signal, signal is consumed by Python handler and not delivered to the library.

In the Python signal handler, can't you call the ncurses function that
should be called when the terminal is resized?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25482>
_______________________________________

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: [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 07:07:05 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 30 Oct 2015 11:07:05 +0000
Subject: [issue25517] regex howto example in "Lookahead Assertions"
In-Reply-To: <1446199646.71.0.249231376897.issue25517@psf.upfronthosting.co.za>
Message-ID: <1446203225.24.0.14475077483.issue25517@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Note that lookbehind assertions still are not documented in Regular Expression HOWTO.

The example that demonstrates negative lookahead assertion is ".*[.](?!bat$)[^.]*$". But then we should explain why ".*" is changed to "[^.]*".

----------
nosy: +akuchling, georg.brandl, serhiy.storchaka
stage:  -> needs patch
versions:  -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25517>
_______________________________________

From report at bugs.python.org  Fri Oct 30 07:13:06 2015
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Fri, 30 Oct 2015 11:13:06 +0000
Subject: [issue25482] signal.set_wakeup_fd() doesn't work if the signal don't
 have handler
In-Reply-To: <1445859296.06.0.537058365711.issue25482@psf.upfronthosting.co.za>
Message-ID: <1446203586.55.0.356333057399.issue25482@psf.upfronthosting.co.za>


Atsuo Ishimoto added the comment:

Yes, I can. So, for my custom text editor,  problem have solved already.

But I still think it is desirable for Python to have something like signalfd(),  because not all functions used in the signal handler of third party library can be called from user's Python script in general.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25482>
_______________________________________

From report at bugs.python.org  Fri Oct 30 07:29:12 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Oct 2015 11:29:12 +0000
Subject: [issue25482] signal.set_wakeup_fd() doesn't work if the signal don't
 have handler
In-Reply-To: <1446203586.55.0.356333057399.issue25482@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbbz3LAJx+g7QK7=u9vH3ts9FXmCQSxi65Sw-k8GfD6nw@mail.gmail.com>


STINNER Victor added the comment:

Atsuo Ishimoto added the comment:
> But I still think it is desirable for Python to have something like signalfd(),  because not all functions used in the signal handler of third party library can be called from user's Python script in general.

I don't think that you can use signalfd() in your case. When you use
signalfd(), signals must be blocked, so the signal handlers are *not*
called (not the Python signal handler, not the C signal handler, no
signal handler for the masked signals).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25482>
_______________________________________

From report at bugs.python.org  Fri Oct 30 07:39:35 2015
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Fri, 30 Oct 2015 11:39:35 +0000
Subject: [issue25482] signal.set_wakeup_fd() doesn't work if the signal don't
 have handler
In-Reply-To: <1445859296.06.0.537058365711.issue25482@psf.upfronthosting.co.za>
Message-ID: <1446205175.85.0.860687545067.issue25482@psf.upfronthosting.co.za>


Atsuo Ishimoto added the comment:

Ah, I didn't know it. Thank you for clarification.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25482>
_______________________________________

From report at bugs.python.org  Fri Oct 30 09:03:24 2015
From: report at bugs.python.org (Fredrik Averpil)
Date: Fri, 30 Oct 2015 13:03:24 +0000
Subject: [issue19143] Finding the Windows version getting messier (detect
 windows 8.1?)
In-Reply-To: <1380675004.25.0.239416620624.issue19143@psf.upfronthosting.co.za>
Message-ID: <1446210204.07.0.776685514084.issue19143@psf.upfronthosting.co.za>


Fredrik Averpil added the comment:

Will this fix be included in python 2.7.11?

----------
nosy: +Fredrik Averpil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19143>
_______________________________________

From report at bugs.python.org  Fri Oct 30 09:08:18 2015
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 30 Oct 2015 13:08:18 +0000
Subject: [issue19143] Finding the Windows version getting messier (detect
 windows 8.1?)
In-Reply-To: <1446210204.07.0.776685514084.issue19143@psf.upfronthosting.co.za>
Message-ID: <56336BAF.4010006@egenix.com>


Marc-Andre Lemburg added the comment:

On 30.10.2015 14:03, Fredrik Averpil wrote:
> Will this fix be included in python 2.7.11?

Yes. Steve also checked in the patch to Python 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19143>
_______________________________________

From report at bugs.python.org  Fri Oct 30 09:11:49 2015
From: report at bugs.python.org (Robin Roth)
Date: Fri, 30 Oct 2015 13:11:49 +0000
Subject: [issue2466] os.path.ismount doesn't work for mounts the user doesn't
 have permission to see
In-Reply-To: <1206293428.96.0.660613140218.issue2466@psf.upfronthosting.co.za>
Message-ID: <1446210709.85.0.579618671608.issue2466@psf.upfronthosting.co.za>


Robin Roth added the comment:

Is there any more info needed to the issue or the patch?
It would be really helpful to have this fixed and I don't see any critical changes due to the patch. 

There is an issue in ansible depending on this fix: https://github.com/ansible/ansible-modules-core/issues/2186

Also the current development version is affected (I manually checked 2.7, 3.0, 3.5, dev).

----------
versions: +Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2466>
_______________________________________

From report at bugs.python.org  Fri Oct 30 09:16:58 2015
From: report at bugs.python.org (Fredrik Averpil)
Date: Fri, 30 Oct 2015 13:16:58 +0000
Subject: [issue19143] Finding the Windows version getting messier (detect
 windows 8.1?)
In-Reply-To: <1380675004.25.0.239416620624.issue19143@psf.upfronthosting.co.za>
Message-ID: <1446211018.56.0.443450210367.issue19143@psf.upfronthosting.co.za>


Fredrik Averpil added the comment:

> Yes. Steve also checked in the patch to Python 2.7.

Excellent. I'll sit tight until the 2.7.11 comes out then (hopefully December), as platform.release() did not return "10" on Windows 10 for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19143>
_______________________________________

From report at bugs.python.org  Fri Oct 30 10:46:29 2015
From: report at bugs.python.org (Peter)
Date: Fri, 30 Oct 2015 14:46:29 +0000
Subject: [issue25144] 3.5 Win install fails with "TARGETDIR"
In-Reply-To: <1442424932.17.0.0389991499722.issue25144@psf.upfronthosting.co.za>
Message-ID: <1446216389.85.0.0622271243473.issue25144@psf.upfronthosting.co.za>


Peter added the comment:

We just hit this bug with "The TARGETDIR variable must be provided when invoking this installer" and an OK button (only) on a colleagues' machine.

We first tried https://www.python.org/ftp/python/3.5.0/python-3.5.0-webinstall.exe (default options) and then https://www.python.org/ftp/python/3.5.0/python-3.5.0.exe (default options plus checked add to PATH) with the same problem.

My colleague recalls having previously installed and then removed Python 3.5 on this machine (possibly a pre-release or beta version). Could anything in the registry or on left disk trigger this?

----------
nosy: +maubp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25144>
_______________________________________

From report at bugs.python.org  Fri Oct 30 10:48:00 2015
From: report at bugs.python.org (Chad Whitacre)
Date: Fri, 30 Oct 2015 14:48:00 +0000
Subject: [issue11315] Fix/add unicode support in Cookie module?
In-Reply-To: <1298606703.83.0.56959729812.issue11315@psf.upfronthosting.co.za>
Message-ID: <1446216480.13.0.934473529026.issue11315@psf.upfronthosting.co.za>


Chad Whitacre added the comment:

> in the 3.x version, only character strings (unicode) are accepted
> The code was changed to do this in r83361 #3788.

That seems like a bug to me. It looks like the intention was to avoid the `type("")` check for stylistic reasons, so `isinstance(rawdata, str)` is an understandable translation under 3.1 (which #3788 targets), but I suspect that `type("")` should never have survived the transition to Python 3 in the first place. The 2.7 branch still has `type("")` (not `str("")` as originally reported):

https://hg.python.org/cpython/file/2.7/Lib/Cookie.py#l639


> ?raw? would suggest to me than only bytes make sense.

Agreed. Cookie names and values are constrained to a subset of ASCII:

https://tools.ietf.org/html/rfc6265#section-4.1.1

I suggest cookies be thought of as a binary data store, with programmers responsible to encode/decode their data at the boundary with the cookies library.


> I would tend to edit the documentation but no[t] the behavior, given that 2.7 is stable and this behavior has been present and documented for a long time.

Leaving 2.7 as-is makes sense, but now I think it looks like we have a regression in 3, which should be fixed.

----

P.S. I arrived here from https://github.com/gratipay/aspen.py/pull/524.

----------
nosy: +whit537

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11315>
_______________________________________

From report at bugs.python.org  Fri Oct 30 10:51:23 2015
From: report at bugs.python.org (Chad Whitacre)
Date: Fri, 30 Oct 2015 14:51:23 +0000
Subject: [issue11315] Fix type regression in http.cookies.load (want bytes,
 not str)
In-Reply-To: <1298606703.83.0.56959729812.issue11315@psf.upfronthosting.co.za>
Message-ID: <1446216683.82.0.811182463225.issue11315@psf.upfronthosting.co.za>


Changes by Chad Whitacre <chad at zetaweb.com>:


----------
title: Fix/add unicode support in Cookie module? -> Fix type regression in http.cookies.load (want bytes, not str)
versions: +Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11315>
_______________________________________

From report at bugs.python.org  Fri Oct 30 11:13:15 2015
From: report at bugs.python.org (Chad Whitacre)
Date: Fri, 30 Oct 2015 15:13:15 +0000
Subject: [issue11315] Fix type regression in http.cookies.load (want bytes,
 not str)
In-Reply-To: <1298606703.83.0.56959729812.issue11315@psf.upfronthosting.co.za>
Message-ID: <1446217995.85.0.493546173474.issue11315@psf.upfronthosting.co.za>


Chad Whitacre added the comment:

Here's a patch with a couple failings tests for the type regression in 3.x.

----------
Added file: http://bugs.python.org/file40901/failing-tests-for-type-regression.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11315>
_______________________________________

From report at bugs.python.org  Fri Oct 30 11:24:14 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 30 Oct 2015 15:24:14 +0000
Subject: [issue25485] Add a context manager to telnetlib.Telnet
In-Reply-To: <1445883619.21.0.032521861016.issue25485@psf.upfronthosting.co.za>
Message-ID: <1446218654.26.0.308735475341.issue25485@psf.upfronthosting.co.za>


St?phane Wirtel added the comment:

New version of the patch, I have modified the 'test' function. In this function, I use the with statement with the __enter__ and __exit__.

----------
Added file: http://bugs.python.org/file40902/issue25485-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25485>
_______________________________________

From report at bugs.python.org  Fri Oct 30 11:26:17 2015
From: report at bugs.python.org (Steve Dower)
Date: Fri, 30 Oct 2015 15:26:17 +0000
Subject: [issue25144] 3.5 Win install fails with "TARGETDIR"
In-Reply-To: <1442424932.17.0.0389991499722.issue25144@psf.upfronthosting.co.za>
Message-ID: <1446218777.47.0.154727771037.issue25144@psf.upfronthosting.co.za>


Steve Dower added the comment:

That's a good idea.

Can you grab the log files from %UserProfile%\AppData\Local\Temp (sort by date - they'll all be grouped together) and upload to this issue? 

Like Felipe, you may want to censor some usernames/paths. If you do, please let me know if they contain anything other than letters or digits (spaces and punctuation may be very important here).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25144>
_______________________________________

From report at bugs.python.org  Fri Oct 30 11:37:31 2015
From: report at bugs.python.org (SilentGhost)
Date: Fri, 30 Oct 2015 15:37:31 +0000
Subject: [issue25485] Add a context manager to telnetlib.Telnet
In-Reply-To: <1445883619.21.0.032521861016.issue25485@psf.upfronthosting.co.za>
Message-ID: <1446219451.23.0.36221380923.issue25485@psf.upfronthosting.co.za>


SilentGhost added the comment:

That's fine as a code change, but that's not the kind of test I meant. There is a Lib/test/test_ftplib.py and it basically needs test_with_statement added to one or few test cases. Have a look at how the similar functions implemented in Lib/test/.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25485>
_______________________________________

From report at bugs.python.org  Fri Oct 30 11:39:41 2015
From: report at bugs.python.org (Chad Whitacre)
Date: Fri, 30 Oct 2015 15:39:41 +0000
Subject: [issue11315] Fix type regression in http.cookies.load (want bytes,
 not str)
In-Reply-To: <1298606703.83.0.56959729812.issue11315@psf.upfronthosting.co.za>
Message-ID: <1446219581.1.0.328786130425.issue11315@psf.upfronthosting.co.za>


Chad Whitacre added the comment:

Here's a patch that fixes the two new failing tests. Now a bunch of other tests are busted. :-)

----------
Added file: http://bugs.python.org/file40903/fix-the-two-new-tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11315>
_______________________________________

From report at bugs.python.org  Fri Oct 30 11:56:18 2015
From: report at bugs.python.org (Martin Smith)
Date: Fri, 30 Oct 2015 15:56:18 +0000
Subject: [issue25512] apparent memory leak using ctypes
In-Reply-To: <1446146196.34.0.00289106474644.issue25512@psf.upfronthosting.co.za>
Message-ID: <1446220578.5.0.0405917666485.issue25512@psf.upfronthosting.co.za>


Martin Smith added the comment:

I'm persuaded that this is not a sustained memory leak.

Thanks to Martin Panter and Benjamin Peterson for the tests and the careful explanations.

Apologies for distracting busy people.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25512>
_______________________________________

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: [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: [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 12:29:08 2015
From: report at bugs.python.org (Mouse)
Date: Fri, 30 Oct 2015 16:29:08 +0000
Subject: [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1446222548.62.0.494818619484.issue25495@psf.upfronthosting.co.za>


Mouse added the comment:

As far as I remember, the data was not "originally processed in 57-byte chunks". I've been around the first PEM and MIME standards and discussions (and code, though not in Python, which wasn't around then) to be in position to know. :)

Whether the user prefers to process data in chunks or not, is up to the user. 
Not to mention that PEM is long gone, and MIME also changed somewhat. 

The link between this function and RFC4648 can and should be more explicit, but I think just referring to it is enough. 

Do you have a recommendation for additional info to explain newline issues?

Yes, changing "Base64 output" to "function output" makes perfect sense.

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25495>
_______________________________________

From report at bugs.python.org  Fri Oct 30 12:34:02 2015
From: report at bugs.python.org (Laura Creighton)
Date: Fri, 30 Oct 2015 16:34:02 +0000
Subject: [issue25514] better startup error messages in IDLE when stdlib
 modules shadowed
In-Reply-To: <1446151640.74.0.583734209916.issue25514@psf.upfronthosting.co.za>
Message-ID: <1446222842.18.0.51883435447.issue25514@psf.upfronthosting.co.za>


Laura Creighton added the comment:

Re: misunderstanding

Sorry Terry.  From my end the great 4 day "weekend of mail.python.org needs to be rebuilt from scratch" happened precisely as I was about
to reply to your post.  The reply to Peter Otten showed up later 
as part of my mailer agent trying to send the thing every 4 hours for
a week.  So confusion reigns.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25514>
_______________________________________

From report at bugs.python.org  Fri Oct 30 12:34:07 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 30 Oct 2015 16:34:07 +0000
Subject: [issue25489] sys.exit() caught in exception handler
In-Reply-To: <1445945156.1.0.415307859083.issue25489@psf.upfronthosting.co.za>
Message-ID: <1446222847.76.0.38402035742.issue25489@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

OK, I'll wait for someone to submit a patch for this. (I tried a quick hack, but unless we limit this to BaseException instances that aren't also Exception instances it's complicated).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25489>
_______________________________________

From report at bugs.python.org  Fri Oct 30 12:46:36 2015
From: report at bugs.python.org (Laura Creighton)
Date: Fri, 30 Oct 2015 16:46:36 +0000
Subject: [issue25144] 3.5 Win install fails with "TARGETDIR"
In-Reply-To: <1442424932.17.0.0389991499722.issue25144@psf.upfronthosting.co.za>
Message-ID: <1446223596.58.0.746697792198.issue25144@psf.upfronthosting.co.za>


Laura Creighton added the comment:

webmaster just got mail from another person hit with this on Windows 10.

----------
nosy: +lac

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25144>
_______________________________________

From report at bugs.python.org  Fri Oct 30 13:19:40 2015
From: report at bugs.python.org (Nir Soffer)
Date: Fri, 30 Oct 2015 17:19:40 +0000
Subject: [issue25516] threading.Condition._is_owned() is wrong when using
 threading.Lock
In-Reply-To: <1446165392.31.0.717642417411.issue25516@psf.upfronthosting.co.za>
Message-ID: <1446225580.24.0.70659759213.issue25516@psf.upfronthosting.co.za>


Nir Soffer added the comment:

The commit hash in the previous message is a git commit from the github mirror:
https://github.com/python/cpython/commit/8cb1ccbb8b9ed01c26d2c5be7cc86682e525dce7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25516>
_______________________________________

From report at bugs.python.org  Fri Oct 30 13:39:59 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 30 Oct 2015 17:39:59 +0000
Subject: [issue25498] Python 3.4.3 core dump with simple sample code
In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za>
Message-ID: <1446226799.25.0.257074326061.issue25498@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Before committing any solution we first should have understood the cause of the crash. The peculiarity of example ctypes_crash.py is that the argument of ctypes.c_char.from_buffer is a memoryview. With current code we have following chain (the list creates a reference loop with itself):

    list->memoryview->ManagedBuffer->memoryview->ManagedBuffer->bytearray

Using PyMemoryView_FromObject or hypothetical PyMemoryView_FromObjectEx we could get shorter chain:

    list->memoryview->ManagedBuffer->bytearray

May be the cause not in current hack, but in memoryview that can't survive with breaking long chain? Or may be we just are lucky in latter case?

I share Martin's doubts about writability in Eryksun?s patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25498>
_______________________________________

From report at bugs.python.org  Fri Oct 30 13:44:48 2015
From: report at bugs.python.org (Chad Whitacre)
Date: Fri, 30 Oct 2015 17:44:48 +0000
Subject: [issue11315] Fix type regression in http.cookies.load (want bytes,
 not str)
In-Reply-To: <1298606703.83.0.56959729812.issue11315@psf.upfronthosting.co.za>
Message-ID: <1446227088.45.0.441972266063.issue11315@psf.upfronthosting.co.za>


Chad Whitacre added the comment:

Here's a start on converting to bytes everywhere for cookies. I'm not sure I fully understand the library's original worldview on type conversion. There's a value_{decode,encode} facility, and in the test suite attribute values in particular are often not even strings of any kind.

----------
Added file: http://bugs.python.org/file40904/start-converting-to-bytes-everywhere.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11315>
_______________________________________

From report at bugs.python.org  Fri Oct 30 14:32:43 2015
From: report at bugs.python.org (Wade Hedrick)
Date: Fri, 30 Oct 2015 18:32:43 +0000
Subject: [issue25144] 3.5 Win install fails with "TARGETDIR"
In-Reply-To: <1442424932.17.0.0389991499722.issue25144@psf.upfronthosting.co.za>
Message-ID: <1446229963.2.0.483944640515.issue25144@psf.upfronthosting.co.za>


Wade Hedrick added the comment:

I had the same problem when trying to install 3.5 with Windows 10. I got the same results as Felipe has listed in the post from 9/16.

----------
nosy: +WadeH
type: behavior -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25144>
_______________________________________

From report at bugs.python.org  Fri Oct 30 15:14:28 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Oct 2015 19:14:28 +0000
Subject: [issue11315] Fix type regression in http.cookies.load (want bytes,
 not str)
In-Reply-To: <1298606703.83.0.56959729812.issue11315@psf.upfronthosting.co.za>
Message-ID: <1446232468.52.0.195045190114.issue11315@psf.upfronthosting.co.za>


R. David Murray added the comment:

If strings and values are constrained to be ascii, there is no obvious reason to use bytes.  I don't see a bug here in python3.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11315>
_______________________________________

From report at bugs.python.org  Fri Oct 30 15:42:25 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 30 Oct 2015 19:42:25 +0000
Subject: [issue25485] Add a context manager to telnetlib.Telnet
In-Reply-To: <1446219451.23.0.36221380923.issue25485@psf.upfronthosting.co.za>
Message-ID: <CAE59B16-991E-4550-92B3-A87B1970BFD5@wirtel.be>


St?phane Wirtel added the comment:

Ok i will submit an other patch for the tests and the documentation

> On 30 oct. 2015, at 4:37 PM, SilentGhost <report at bugs.python.org> wrote:
> 
> 
> SilentGhost added the comment:
> 
> That's fine as a code change, but that's not the kind of test I meant. There is a Lib/test/test_ftplib.py and it basically needs test_with_statement added to one or few test cases. Have a look at how the similar functions implemented in Lib/test/.
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue25485>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25485>
_______________________________________

From report at bugs.python.org  Fri Oct 30 16:28:21 2015
From: report at bugs.python.org (Arkadiusz Miskiewicz Arkadiusz Miskiewicz)
Date: Fri, 30 Oct 2015 20:28:21 +0000
Subject: [issue25150] 3.5: Include/pyatomic.h is incompatible with OpenMP
 (compilation of the third-party yt module fails on Python 3.5)
In-Reply-To: <1442494739.31.0.584117765088.issue25150@psf.upfronthosting.co.za>
Message-ID: <1446236901.33.0.378634866201.issue25150@psf.upfronthosting.co.za>


Arkadiusz Miskiewicz				Arkadiusz Miskiewicz added the comment:

Should it work with /configure '--with-cxx-main=g++' && make?

Because currently it doesn't:

g++ -c -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes    -Werror=declaration-after-statement   -I. -IInclude -I./Include    -DPy_BUILD_CORE -o Programs/python.o ./Programs/python.c
cc1plus: warning: command line option ?-Wstrict-prototypes? is valid for C/ObjC but not for C++
In file included from Include/pyatomic.h:10:0,
                 from Include/Python.h:53,
                 from ./Programs/python.c:3:
/usr/lib64/gcc/x86_64-pld-linux/5.2.0/include/stdatomic.h:40:9: error: ?_Atomic? does not name a type
[...]

(testing 3.5.0 + patch for this issue from hg)

----------
nosy: +arekm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25150>
_______________________________________

From report at bugs.python.org  Fri Oct 30 16:32:56 2015
From: report at bugs.python.org (Arkadiusz Miskiewicz Arkadiusz Miskiewicz)
Date: Fri, 30 Oct 2015 20:32:56 +0000
Subject: [issue25150] 3.5: Include/pyatomic.h is incompatible with OpenMP
 (compilation of the third-party yt module fails on Python 3.5)
In-Reply-To: <1442494739.31.0.584117765088.issue25150@psf.upfronthosting.co.za>
Message-ID: <1446237176.77.0.896424628637.issue25150@psf.upfronthosting.co.za>


Arkadiusz Miskiewicz				Arkadiusz Miskiewicz added the comment:

Same for 3.5 branch from hg (git mirror actually).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25150>
_______________________________________

From report at bugs.python.org  Fri Oct 30 17:01:47 2015
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 30 Oct 2015 21:01:47 +0000
Subject: [issue25498] Python 3.4.3 core dump with simple sample code
In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za>
Message-ID: <1446238907.11.0.211386619448.issue25498@psf.upfronthosting.co.za>


Stefan Krah added the comment:

If memoryview B is created from memoryview A, then B must be
registered with the same ManagedBuffer as A, otherwise the
whole scheme breaks down (PyMemoryView_FromObject() performs
this check).


PyMemoryView_FromBuffer() is really a legacy function that
should be only used for creating temporary views within a
function.  As far as I know, it has usually been used that
way from the start (since 3.0).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25498>
_______________________________________

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: [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 17:19:22 2015
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 30 Oct 2015 21:19:22 +0000
Subject: [issue25498] Python 3.4.3 core dump with simple sample code
In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za>
Message-ID: <1446239962.44.0.910962508878.issue25498@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Per the docs the readonly flag must be consistent for all consumers,
so checking for writability after getting the view should be okay in
principle.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25498>
_______________________________________

From report at bugs.python.org  Fri Oct 30 17:25:26 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 30 Oct 2015 21:25:26 +0000
Subject: [issue25426] Deprecate the regex_compile benchmark
In-Reply-To: <1445023706.21.0.465528553225.issue25426@psf.upfronthosting.co.za>
Message-ID: <20151030212523.10158.60074@psf.io>


Roundup Robot added the comment:

New changeset 0da7b44c2ea3 by Brett Cannon in branch 'default':
Use re.purge() to clear the re cache.
https://hg.python.org/benchmarks/rev/0da7b44c2ea3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25426>
_______________________________________

From report at bugs.python.org  Fri Oct 30 17:25:51 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 30 Oct 2015 21:25:51 +0000
Subject: [issue25426] Deprecate the regex_compile benchmark
In-Reply-To: <1445023706.21.0.465528553225.issue25426@psf.upfronthosting.co.za>
Message-ID: <1446240351.05.0.431534349308.issue25426@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks for the pointer about re.purge(), Serhiy!

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25426>
_______________________________________

From report at bugs.python.org  Fri Oct 30 17:37:20 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 30 Oct 2015 21:37:20 +0000
Subject: [issue25443] Add a count of how many benchmarks are left to run
In-Reply-To: <1445292895.24.0.0847947042448.issue25443@psf.upfronthosting.co.za>
Message-ID: <20151030213717.24891.68016@psf.io>


Roundup Robot added the comment:

New changeset 71967658feb5 by Brett Cannon in branch 'default':
Issue #25443: Add a running count of benchmarks.
https://hg.python.org/benchmarks/rev/71967658feb5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25443>
_______________________________________

From report at bugs.python.org  Fri Oct 30 17:41:14 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 30 Oct 2015 21:41:14 +0000
Subject: [issue25487] imp module DeprecationWarning in test suite
In-Reply-To: <1445906327.87.0.677600064141.issue25487@psf.upfronthosting.co.za>
Message-ID: <20151030214111.100252.87563@psf.io>


Roundup Robot added the comment:

New changeset 3f924cb4c3eb by Brett Cannon in branch 'default':
Issue #25487: Fix tests not updated when the imp module moved to a
https://hg.python.org/cpython/rev/3f924cb4c3eb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25487>
_______________________________________

From report at bugs.python.org  Fri Oct 30 17:41:41 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 30 Oct 2015 21:41:41 +0000
Subject: [issue25487] imp module DeprecationWarning in test suite
In-Reply-To: <1445906327.87.0.677600064141.issue25487@psf.upfronthosting.co.za>
Message-ID: <1446241301.22.0.888318522079.issue25487@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks for the finding these, Martin!

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25487>
_______________________________________

From report at bugs.python.org  Fri Oct 30 17:42:06 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 30 Oct 2015 21:42:06 +0000
Subject: [issue25443] Add a count of how many benchmarks are left to run
In-Reply-To: <1445292895.24.0.0847947042448.issue25443@psf.upfronthosting.co.za>
Message-ID: <1446241326.85.0.161453656882.issue25443@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25443>
_______________________________________

From report at bugs.python.org  Fri Oct 30 17:57:18 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 30 Oct 2015 21:57:18 +0000
Subject: [issue25493] warnings.warn: wrong stacklevel causes import of local
 file "sys"
In-Reply-To: <1445964361.88.0.406365225673.issue25493@psf.upfronthosting.co.za>
Message-ID: <1446242238.75.0.778151351941.issue25493@psf.upfronthosting.co.za>


Brett Cannon added the comment:

So I'm going to close this as "won't fix" because linecache is horribly over-engineered and I'm afraid trying to fix this will break code that actually worked previously. This is obviously an odd edge case that I think we can live with.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25493>
_______________________________________

From report at bugs.python.org  Fri Oct 30 18:11:45 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Oct 2015 22:11:45 +0000
Subject: [issue25474] Weird behavior when setting f_trace in a context manager
In-Reply-To: <1445774698.38.0.095988844457.issue25474@psf.upfronthosting.co.za>
Message-ID: <1446243105.21.0.101299865859.issue25474@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

ZERO <__main__.Context object at 0x000000874AF3E0B8>
ONE <__main__.Context object at 0x000000874AF326D8>
Traceback (most recent call last):
  File "F:\Python\mypy\tem.py", line 45, in <module>
    print ('TWO', two)
NameError: name 'two' is not defined
Traceback (most recent call last):
  File "F:\Python\mypy\tem.py", line 53, in <module>
    print ('THREE', three)
NameError: name 'three' is not defined
FOUR <__main__.Context object at 0x000000874AF32748>
FIVE <__main__.Context object at 0x000000874B157EB8>

----------
nosy: +ncoghlan, terry.reedy
stage:  -> test needed
versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25474>
_______________________________________

From report at bugs.python.org  Fri Oct 30 18:31:37 2015
From: report at bugs.python.org (Nir Soffer)
Date: Fri, 30 Oct 2015 22:31:37 +0000
Subject: [issue25516] threading.Condition._is_owned() is wrong when using
 threading.Lock
In-Reply-To: <1446165392.31.0.717642417411.issue25516@psf.upfronthosting.co.za>
Message-ID: <1446244297.4.0.628751280011.issue25516@psf.upfronthosting.co.za>


Changes by Nir Soffer <nirsof at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25516>
_______________________________________

From report at bugs.python.org  Fri Oct 30 18:50:38 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 30 Oct 2015 22:50:38 +0000
Subject: [issue25495] binascii documentation incorrect
In-Reply-To: <1445987417.55.0.122139453671.issue25495@psf.upfronthosting.co.za>
Message-ID: <1446245438.49.0.294822901895.issue25495@psf.upfronthosting.co.za>


Martin Panter added the comment:

I was only referring to the original Python documentation and library. See the base64.encode() implementation for an example which does do this 57-byte pre-chunking. Simplified:

MAXLINESIZE = 76 # Excluding the CRLF
MAXBINSIZE = (MAXLINESIZE//4)*3  # 57
...
while True:
    s = input.read(MAXBINSIZE)
    if not s:
        break
    line = binascii.b2a_base64(s)
    output.write(line)

Here?s my attempt to rewrite the doc (3.6 version):

'''
Convert binary data to the base 64 encoding defined in :rfc:`4648`. The return value includes a trailing newline ``b"\n"`` if *newline* is true.

To be MIME-compliant, base 64 output should be broken into lines at most 76 characters long. One way to do this is to call this function with 57-byte chunks and ``newline=True``. Also, the original PEM context-transfer encoding limited the line length to 64 characters.
'''

But if PEM is long gone as you say, perhaps we don?t need that last sentence?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25495>
_______________________________________

From report at bugs.python.org  Fri Oct 30 18:53:31 2015
From: report at bugs.python.org (desbma)
Date: Fri, 30 Oct 2015 22:53:31 +0000
Subject: [issue25156] shutil.copyfile should internally use os.sendfile when
 possible
In-Reply-To: <1442520485.03.0.419427125487.issue25156@psf.upfronthosting.co.za>
Message-ID: <1446245611.91.0.971233441246.issue25156@psf.upfronthosting.co.za>


desbma added the comment:

Here is an improved patch with the following changes:
* Fallback to copyfileobj if sendfile fails with errno set to EINVAL or ENOSYS 
* Add a test for > 4GB file

----------
Added file: http://bugs.python.org/file40906/issue25156_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25156>
_______________________________________

From report at bugs.python.org  Fri Oct 30 19:20:38 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Oct 2015 23:20:38 +0000
Subject: [issue25505] undefined name 'window' in Tools/scripts/fixdiv.py
In-Reply-To: <1446100670.6.0.312090653047.issue25505@psf.upfronthosting.co.za>
Message-ID: <1446247238.42.0.670133220387.issue25505@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25505>
_______________________________________

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: [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  Fri Oct 30 19:26:26 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 30 Oct 2015 23:26:26 +0000
Subject: [issue25505] undefined name 'window' in Tools/scripts/fixdiv.py
In-Reply-To: <1446100670.6.0.312090653047.issue25505@psf.upfronthosting.co.za>
Message-ID: <20151030232624.8613.26849@psf.io>


Roundup Robot added the comment:

New changeset 2672ab3cfb23 by Terry Jan Reedy in branch '2.7':
Issue #25505: Remove unused buggy method.
https://hg.python.org/cpython/rev/2672ab3cfb23

New changeset ef435729bc80 by Terry Jan Reedy in branch '3.4':
Issue #25505: Remove unused buggy method.
https://hg.python.org/cpython/rev/ef435729bc80

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25505>
_______________________________________

From report at bugs.python.org  Fri Oct 30 19:28:00 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Oct 2015 23:28:00 +0000
Subject: [issue25505] undefined name 'window' in Tools/scripts/fixdiv.py
In-Reply-To: <1446100670.6.0.312090653047.issue25505@psf.upfronthosting.co.za>
Message-ID: <1446247680.28.0.673159664543.issue25505@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25505>
_______________________________________

From report at bugs.python.org  Fri Oct 30 19:31:12 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Oct 2015 23:31:12 +0000
Subject: [issue25519] Minor difflib documentation bug
In-Reply-To: <1446222100.88.0.105008703897.issue25519@psf.upfronthosting.co.za>
Message-ID: <1446247872.65.0.955465535887.issue25519@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee: docs at python -> terry.reedy
nosy: +terry.reedy
versions:  -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25519>
_______________________________________

From report at bugs.python.org  Fri Oct 30 19:42:03 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 30 Oct 2015 23:42:03 +0000
Subject: [issue25519] Minor difflib documentation bug
In-Reply-To: <1446222100.88.0.105008703897.issue25519@psf.upfronthosting.co.za>
Message-ID: <20151030234200.100246.23245@psf.io>


Roundup Robot added the comment:

New changeset 4ed175ee3cca by Terry Jan Reedy in branch '2.7':
Issue #25519: Mark difflib.ndiff as a functions where not already.
https://hg.python.org/cpython/rev/4ed175ee3cca

New changeset b7686cb0b698 by Terry Jan Reedy in branch '3.4':
Issue #25519: Mark difflib.ndiff as a functions where not already.
https://hg.python.org/cpython/rev/b7686cb0b698

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25519>
_______________________________________

From report at bugs.python.org  Fri Oct 30 19:42:45 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Oct 2015 23:42:45 +0000
Subject: [issue25519] Minor difflib documentation bug
In-Reply-To: <1446222100.88.0.105008703897.issue25519@psf.upfronthosting.co.za>
Message-ID: <1446248565.74.0.985691809753.issue25519@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25519>
_______________________________________

From report at bugs.python.org  Fri Oct 30 19:50:30 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 30 Oct 2015 23:50:30 +0000
Subject: [issue17214] http.client.HTTPConnection.putrequest encode  error
In-Reply-To: <1361011959.8.0.221376430084.issue17214@psf.upfronthosting.co.za>
Message-ID: <1446249030.47.0.983641825488.issue17214@psf.upfronthosting.co.za>


Martin Panter added the comment:

This bug only applies to Python 3. In Python 2, the non-ASCII bytes are sent through to the redirect target verbatim. I think this would also be the ideal way to handle the problem in 3, but percent-encoding them as proposed also seems good enough, and does not require hacking the HTTPConnection.putrequest() internals.

My patch updates Christian?s patch:
* Tested, so hopefully no typos :)
* Add test cases based on Issue 22248, as well as a URL already including a percent sign
* Process entire URL, not just the path component. A non-ASCII byte could just as easily be in the query component, for example.
* Remove redundant encoding of space character from redirect_request() method.

----------
stage: test needed -> patch review
versions: +Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40907/issue17214.redirect.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17214>
_______________________________________

From report at bugs.python.org  Fri Oct 30 23:18:43 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 31 Oct 2015 03:18:43 +0000
Subject: [issue25454] operator.methodcaller should accept additional arguments
 during the call
In-Reply-To: <1445453619.22.0.222588930326.issue25454@psf.upfronthosting.co.za>
Message-ID: <1446261523.79.0.837957866222.issue25454@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Closing this for the reasons mentions above.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25454>
_______________________________________

From report at bugs.python.org  Sat Oct 31 00:02:49 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 31 Oct 2015 04:02:49 +0000
Subject: [issue25041] document AF_PACKET socket address format
In-Reply-To: <1441804077.41.0.782475265278.issue25041@psf.upfronthosting.co.za>
Message-ID: <1446264169.64.0.0480173224324.issue25041@psf.upfronthosting.co.za>


Martin Panter added the comment:

Quickly looking through the history (annotate function on Mercurial web frontend):

* Revisions 3d4a7cd0bf17, c8ef864ba861 (2001): AF_PACKET support added on Linux. Partially documented in C comment and socket.bind() docstring. AF/PF_PACKET, PACKET_* constants also added.

* #947352 (Python 2.4), 8b3288f607e1: Support specifying hardware address, for sendto().

Here are some more things might be good to tease out:

1. Please don?t invent new parameter names without a good reason. I suggest (ifname, proto, pkttype, hatype, addr). These are already used in the bind() doc string, most are consistent with Linux?s struct sockaddr_ll fields, and ?proto? is consistent with Python?s socket() constructor.

2. There is an error message mentioning ?protoNumber? which could also be adjusted for consistency

3. When Python generates the ifname string, it uses the empty string for ifindex zero (matching any interface), although it does not look like parsing this back is supported

4. proto is endian-corrected, in contrast with Linux?s version being in network byte-order

5. Default pkttype is zero. This is equal to PACKET_HOST, so could be useful. Might also be worth changing the source code to explicitly use PACKET_HOST.

6. addr has to be a bytes-like object

7. Packet support is specific to Linux, and may not be compiled in

8. Existence of *_PACKET and PACKET_* constants

9. socket.bind() doc string needs updating since revision c8ef864ba861 (missing fifth parameter, addr)

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25041>
_______________________________________

From report at bugs.python.org  Sat Oct 31 01:30:26 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 31 Oct 2015 05:30:26 +0000
Subject: [issue15994] memoryview to freed memory can cause segfault
In-Reply-To: <1348173441.91.0.841080415833.issue15994@psf.upfronthosting.co.za>
Message-ID: <1446269426.78.0.428256888299.issue15994@psf.upfronthosting.co.za>


Martin Panter added the comment:

Saving a reference to the overall buffered reader is probably not good enough. I think the buffer is freed when close() is called, so a reference to this internal buffer would need to be saved instead (or as well). Unless we stop having close() free the buffer.

----------
components: +IO
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15994>
_______________________________________

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: [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 01:48:17 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 31 Oct 2015 05:48:17 +0000
Subject: [issue25498] Python 3.4.3 core dump with simple sample code
In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za>
Message-ID: <1446270497.16.0.340896227375.issue25498@psf.upfronthosting.co.za>


Martin Panter added the comment:

Okay, so <https://docs.python.org/dev/c-api/buffer.html#c.PyBUF_WRITABLE> says writability must be consistent. As far as I can see, there is no similar requirement for contiguity. So in theory PyBUF_FULL_RO could produce a discontiguous buffer when PyBUF_WRITABLE would have produced a contiguous one. But I guess this is rather unlikely, so Eryksun?s approach might be good enough.

I am starting to wonder why the current memory view hack should even be necessary. It seems like a memory view created by PyMemoryView_FromBuffer() will eventually do the equivalent of PyBuffer_Release(), except that it leaks a reference to the underlying Python object. This was also brought up at <https://bugs.python.org/issue15903#msg170658>, but the question is not resolved that I can see.

Possibly also related is Issue 15821, but I don?t know enough details or history to be sure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25498>
_______________________________________

From report at bugs.python.org  Sat Oct 31 01:56:24 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 31 Oct 2015 05:56:24 +0000
Subject: [issue25522] IDLE: warn if save-as name matches stdlib name
In-Reply-To: <1446270102.89.0.424617028731.issue25522@psf.upfronthosting.co.za>
Message-ID: <1446270984.22.0.955035529773.issue25522@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The lib messages should say "Neither you nor python will be able to import the stdlib module".  Example of python-imported lib names that a beginner might write are abc, io, os, nt, and stat.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25522>
_______________________________________

From report at bugs.python.org  Sat Oct 31 02:01:51 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 31 Oct 2015 06:01:51 +0000
Subject: [issue17214] http.client.HTTPConnection.putrequest encode  error
In-Reply-To: <1361011959.8.0.221376430084.issue17214@psf.upfronthosting.co.za>
Message-ID: <1446271311.5.0.94694979144.issue17214@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy:  -terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17214>
_______________________________________

From report at bugs.python.org  Sat Oct 31 03:36:33 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 31 Oct 2015 07:36:33 +0000
Subject: [issue25156] shutil.copyfile should internally use os.sendfile when
 possible
In-Reply-To: <1442520485.03.0.419427125487.issue25156@psf.upfronthosting.co.za>
Message-ID: <1446276993.19.0.0340860976938.issue25156@psf.upfronthosting.co.za>


Martin Panter added the comment:

I left a few comments. But it might be good if someone more familiar with the APIs could review this.

Have you seen the socket.sendfile() implementation? It?s a bit of a mess, and the circumstances are slightly different, but it may offer partial inspiration. It seems a shame to have two separate high-level sendfile() wrappers, but I guess the use cases are just a little too far apart to be worth sharing much code.

For the test case, it may be worth skipping the test if you run out of disk space. Similar to test_mmap and test_largefile.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25156>
_______________________________________

From report at bugs.python.org  Sat Oct 31 04:06:51 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 31 Oct 2015 08:06:51 +0000
Subject: [issue25521] optparse module does not emit DeprecationWarning
In-Reply-To: <1446247354.16.0.386152814173.issue25521@psf.upfronthosting.co.za>
Message-ID: <1446278811.26.0.481575753005.issue25521@psf.upfronthosting.co.za>


Martin Panter added the comment:

Under <https://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse> it says ?Importing optparse will issue a PendingDeprecationWarning? (not DeprecationWarning!), however even this does not appear to be the case. Maybe somebody forgot to do this, or maybe somebody decided not to do this; I dunno.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25521>
_______________________________________

From report at bugs.python.org  Sat Oct 31 04:08:00 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 31 Oct 2015 08:08:00 +0000
Subject: [issue25156] shutil.copyfile should internally use os.sendfile when
 possible
In-Reply-To: <1442520485.03.0.419427125487.issue25156@psf.upfronthosting.co.za>
Message-ID: <1446278880.37.0.421335821887.issue25156@psf.upfronthosting.co.za>


Martin Panter added the comment:

Also, man pages for Free BSD and OS X (where writing to a disk file is not supported) say it raises:

* ENOTSUP if ?the ?fd? argument does not refer to a regular file?
* EBADF if ?the ?s? argument is not a valid socket descriptor?
* ENOTSOCK if ?the ?s? argument is not a socket?
* EOPNOTSUPP if ?the file system for descriptor fd does not support sendfile()?

It is not clear what the priority of these errors is, so it might be safest to catch them all. But I wouldn?t catch any arbitrary OSError, because you may end up doing weird double copying or something for an out-of-space error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25156>
_______________________________________

From report at bugs.python.org  Sat Oct 31 07:13:24 2015
From: report at bugs.python.org (Aymeric Augustin)
Date: Sat, 31 Oct 2015 11:13:24 +0000
Subject: [issue24539] StreamReaderProtocol.eof_received() should return True
 to keep the transport open
In-Reply-To: <1435668886.87.0.254771488213.issue24539@psf.upfronthosting.co.za>
Message-ID: <1446290004.1.0.297771308822.issue24539@psf.upfronthosting.co.za>


Aymeric Augustin added the comment:

This change appears to have caused a non-obvious regression in `websockets`: https://github.com/aaugustin/websockets/issues/76

Perhaps I was relying on an implementation detail but that's annoying nonetheless.

----------
nosy: +aymeric.augustin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24539>
_______________________________________

From report at bugs.python.org  Sat Oct 31 07:40:02 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 31 Oct 2015 11:40:02 +0000
Subject: [issue25415] I can create instances of io.IOBase
In-Reply-To: <1444931934.97.0.280840323098.issue25415@psf.upfronthosting.co.za>
Message-ID: <1446291602.09.0.693117787277.issue25415@psf.upfronthosting.co.za>


Martin Panter added the comment:

If existing subclasses like FileIO call the base, that is an implementation detail. But custom subclasses of the Raw, Buffered, and Text base classes should not be prohibited from chain calling the base?s __init__() method, nor should they have to override __init__() if there is no special initialization to be done. For IOBase itself, I don?t see a strong argument either way, but it makes sense to keep it consistent with the other three base classes.

I propose this patch, which changes ?There is no public constructor? to ?The constructor accepts no arguments?. In my mind this blesses making custom subclasses, which already seems to be tested and used in practice.

----------
keywords: +patch
stage:  -> patch review
versions: +Python 2.7, Python 3.4, Python 3.6
Added file: http://bugs.python.org/file40908/no-args.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25415>
_______________________________________

From report at bugs.python.org  Sat Oct 31 08:32:10 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 31 Oct 2015 12:32:10 +0000
Subject: [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 08:33:24 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 31 Oct 2015 12:33:24 +0000
Subject: [issue25523] Correct "a" article to "an" article
In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za>
Message-ID: <1446294804.34.0.10475340406.issue25523@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


Removed 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 08:33:51 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 31 Oct 2015 12:33:51 +0000
Subject: [issue25523] Correct "a" article to "an" article
In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za>
Message-ID: <1446294831.65.0.30808668818.issue25523@psf.upfronthosting.co.za>


Martin Panter added the comment:

Rebased so it should be reviewable

----------
Added file: http://bugs.python.org/file40910/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:10:54 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Oct 2015 14:10:54 +0000
Subject: [issue25523] Correct "a" article to "an" article
In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za>
Message-ID: <1446300654.98.0.906971171865.issue25523@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I suppose that changes was generated by a script. But some changes looks not satisfying a simple rule.

In Doc/library/multiprocessing.rst, Doc/library/socket.rst, Doc/whatsnew/3.2.rst, Misc/HISTORY, Modules/_hashopenssl.c "a" is just deleted. Is it deliberately?

In Doc/library/smtplib.rst "a" is replaced to "an" before a word starting with consonant: SMTP. Is it correct?

Aren't files in Lib/test/decimaltestdata/ imported from external source? Then we shouldn't change them.

The rest of changes LGTM, but I'm not sure about mentioned above.

----------
nosy: +r.david.murray, serhiy.storchaka

_______________________________________
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: [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 10:21:24 2015
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 31 Oct 2015 14:21:24 +0000
Subject: [issue25524] Add PyMemoryView_FromObjectWithFlags()
In-Reply-To: <1446301264.7.0.598429050935.issue25524@psf.upfronthosting.co.za>
Message-ID: <1446301284.29.0.213861523886.issue25524@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan at bytereef.org>:


----------
assignee:  -> skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25524>
_______________________________________

From report at bugs.python.org  Sat Oct 31 10:23:26 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 31 Oct 2015 14:23:26 +0000
Subject: [issue25521] optparse module does not emit DeprecationWarning
In-Reply-To: <1446247354.16.0.386152814173.issue25521@psf.upfronthosting.co.za>
Message-ID: <1446301406.97.0.554362460771.issue25521@psf.upfronthosting.co.za>


R. David Murray added the comment:

Whether someone decided not to do it originally or not, it is probably a good idea to do it (as a DeprecationWarning, IMO), if someone wants to propose a patch.  The module isn't receiving maintenance any longer.  (Not that it couldn't, but no one is motivated to do so.)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25521>
_______________________________________

From report at bugs.python.org  Sat Oct 31 10:28:08 2015
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 31 Oct 2015 14:28:08 +0000
Subject: [issue25498] Python 3.4.3 core dump with simple sample code
In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za>
Message-ID: <1446301688.43.0.678798236634.issue25498@psf.upfronthosting.co.za>


Stefan Krah added the comment:

The current hack isn't necessary. I didn't review eryksun's patch
in depth, but on the surface it looks good.

I don't think the other issues you mentioned are closely related:
The cause here is that the obj fields of both the second memoryview
and the second mbuf are manually set to the address of the first
memoryview, which plays havoc with the rather complex deallocation
scheme.

I've opened #25524 in order to make it easier to create views
with detailed request flags.



As a practical matter, I think we should just revert the ctypes
change for 3.4 and 3.5 (after verifying a second time that
PyObject_AsWriteBuffer() is exactly the same as in 3.4.0).


Then we use the new function from #25524 for 3.6, which should
alleviate concerns about writablility (not all extension writers
read the docs:) etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25498>
_______________________________________

From report at bugs.python.org  Sat Oct 31 10:29:39 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 31 Oct 2015 14:29:39 +0000
Subject: [issue25156] shutil.copyfile should internally use os.sendfile when
 possible
In-Reply-To: <1442520485.03.0.419427125487.issue25156@psf.upfronthosting.co.za>
Message-ID: <1446301779.04.0.102241446568.issue25156@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'm not at all sure this is worth the maintenance burden at this point in time.  So let's say I'm -0.5.  I agree that a review and opinion by someone more familiar with the API would be best.  I'm adding gps as nosy since this feels like the kind of performance improvement he might find interesting, so if he thinks it is worth it I'll change my vote :)

----------
nosy: +gps

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25156>
_______________________________________

From report at bugs.python.org  Sat Oct 31 10:35:39 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 31 Oct 2015 14:35:39 +0000
Subject: [issue24539] StreamReaderProtocol.eof_received() should return True
 to keep the transport open
In-Reply-To: <1435668886.87.0.254771488213.issue24539@psf.upfronthosting.co.za>
Message-ID: <1446302139.45.0.0429990771736.issue24539@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, asyncio was still provisional, so annoyances like this were bound to happen occasionally.

Victor, is there a reason this issue is still open?  Is it because of the warnings question?  Maybe that should be a new issue?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24539>
_______________________________________

From report at bugs.python.org  Sat Oct 31 10:52:37 2015
From: report at bugs.python.org (Emanuel Barry)
Date: Sat, 31 Oct 2015 14:52:37 +0000
Subject: [issue25523] Correct "a" article to "an" article
In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za>
Message-ID: <1446303157.69.0.787665294129.issue25523@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

> In Doc/library/smtplib.rst "a" is replaced to "an" before a word starting with consonant: SMTP. Is it correct?

One of the peculiriarities of the English language is that, in front of acronyms, you have two different ways to decided which to use between "a" and "an" - first (and probably what you thought), is to think of what the acronym means (or which letter it begins with). The other way, which Martin probably used, is to use what would sound be if it was said out loud, and "An ess-emm-tee-pee" sounds better overall.

In other words, both work, and it's down to personal preference. However, if we decide to use "an" here for this reason, it should (IMO) remain consistent across all of the documentation. I've only briefly looked over the patch as I have to head out soon, but I wanted to make this point anyway.

----------
nosy: +ebarry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25523>
_______________________________________

From report at bugs.python.org  Sat Oct 31 10:58:08 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 31 Oct 2015 14:58:08 +0000
Subject: [issue24539] StreamReaderProtocol.eof_received() should return True
 to keep the transport open
In-Reply-To: <1446302139.45.0.0429990771736.issue24539@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJKpumq9CezJuaS3fzScLujBQQhSxMtw+gQbs7QMazZ7cQ@mail.gmail.com>


Guido van Rossum added the comment:

Well, the warning points to a deeper issue -- the fix doesn't work for TLS
connections. Also, the upstream issue (
https://github.com/python/asyncio/issues/251) is still open because there's
no test for this behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24539>
_______________________________________

From report at bugs.python.org  Sat Oct 31 10:58:55 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 31 Oct 2015 14:58:55 +0000
Subject: [issue25523] Correct "a" article to "an" article
In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za>
Message-ID: <1446303535.66.0.264556725356.issue25523@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, those deletions are intentional, they make the English read better (to me as a native speaker, at least :)  As Emanuel said, the SMTP thing comes from reading it as an acronym, which is how I generally do it, and I suppose most people do.  Given how thorough Martin has been here, I'm guessing this was the one place that an wasn't used :)

This all looks good to me, except that I would rewrite

  and an isfile and isdir check on it

as

  and isfile and isdir checks on it

Agree with Serhiy's caveat about decimaltestdata.  Adding Mark to nosy to double check, but I don't think that file should be changed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25523>
_______________________________________

From report at bugs.python.org  Sat Oct 31 10:59:16 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 31 Oct 2015 14:59:16 +0000
Subject: [issue25523] Correct "a" article to "an" article
In-Reply-To: <1446294729.19.0.0593417180133.issue25523@psf.upfronthosting.co.za>
Message-ID: <1446303556.59.0.673025866265.issue25523@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25523>
_______________________________________

From report at bugs.python.org  Sat Oct 31 11:02:15 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 31 Oct 2015 15:02:15 +0000
Subject: [issue24539] StreamReaderProtocol.eof_received() should return True
 to keep the transport open
In-Reply-To: <1435668886.87.0.254771488213.issue24539@psf.upfronthosting.co.za>
Message-ID: <1446303735.73.0.110964030108.issue24539@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, I thought Victor was saying he'd done the unit test; I guess he just meant he'd done the merge.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24539>
_______________________________________

From report at bugs.python.org  Sat Oct 31 11:05:22 2015
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 31 Oct 2015 15:05:22 +0000
Subject: [issue15994] memoryview to freed memory can cause segfault
In-Reply-To: <1348173441.91.0.841080415833.issue15994@psf.upfronthosting.co.za>
Message-ID: <1446303922.14.0.398015497259.issue15994@psf.upfronthosting.co.za>


Stefan Krah added the comment:

> But I think there should be some way of guaranteeing that a memoryview will not try to access memory which has already been freed.

Unless the "buffered *self" parameter in _buffered_raw_read() is
made a full PEP-3118 exporter, I'm not sure how it would be possible
to prevent all examples of this kind.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15994>
_______________________________________

From report at bugs.python.org  Sat Oct 31 11:36:13 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 31 Oct 2015 15:36:13 +0000
Subject: [issue13828] Further improve casefold documentation
In-Reply-To: <1326992763.46.0.576190503242.issue13828@psf.upfronthosting.co.za>
Message-ID: <1446305773.79.0.792292359439.issue13828@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> In addition to lowercasing, this function also expands ligatures, for example, "?" becomes "fi".

+1 I would have found that sentence to be helpful.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13828>
_______________________________________

From report at bugs.python.org  Sat Oct 31 11:40:10 2015
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 31 Oct 2015 15:40:10 +0000
Subject: [issue25300] Enable Intel MPX (Memory protection Extensions) feature
In-Reply-To: <1443788737.62.0.174147088714.issue25300@psf.upfronthosting.co.za>
Message-ID: <1446306010.25.0.546905439179.issue25300@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Florin, thanks for the explanation.  I'd suggest to wait until
the mpx support is stable in gcc.

Some security features in gcc never take off (-ftrapv is broken,
libmudflap is deprecated, ...) so it would be nice to have some
reassurance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25300>
_______________________________________

From report at bugs.python.org  Sat Oct 31 12:13:50 2015
From: report at bugs.python.org (desbma)
Date: Sat, 31 Oct 2015 16:13:50 +0000
Subject: [issue25156] shutil.copyfile should internally use os.sendfile when
 possible
In-Reply-To: <1442520485.03.0.419427125487.issue25156@psf.upfronthosting.co.za>
Message-ID: <1446308030.13.0.419248435155.issue25156@psf.upfronthosting.co.za>


desbma added the comment:

Here is an updated patch that takes into account Martin's suggestions, both here and in the code review.

----------
Added file: http://bugs.python.org/file40911/issue25156_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25156>
_______________________________________

From report at bugs.python.org  Sat Oct 31 13:02:49 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Sat, 31 Oct 2015 17:02:49 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1446310969.9.0.285757562948.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

UPDATE: Finslly rebuilding Python from github clone after having to factory reset my tablet for reasons (root access).  Hopefully build and tests will benefit from paving and starting over.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Sat Oct 31 13:56:47 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Oct 2015 17:56:47 +0000
Subject: [issue25498] Python 3.4.3 core dump with simple sample code
In-Reply-To: <1446055572.58.0.349657416945.issue25498@psf.upfronthosting.co.za>
Message-ID: <1446314207.72.0.0106497688409.issue25498@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I rather inclined to commit eryksun's patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25498>
_______________________________________

From report at bugs.python.org  Sat Oct 31 15:01:15 2015
From: report at bugs.python.org (Nan Wu)
Date: Sat, 31 Oct 2015 19:01:15 +0000
Subject: [issue25439] Add type checks to urllib.request.Request
In-Reply-To: <1445247083.91.0.927080887762.issue25439@psf.upfronthosting.co.za>
Message-ID: <1446318075.96.0.0512362385049.issue25439@psf.upfronthosting.co.za>


Nan Wu added the comment:

Martin: Sorry for missing that line.

Under https, byte iterable seems has not been supported:
>>> r = Request('https://www.python.org', {b'post': 'data'}, {'Content-Length':10})
>>> urlopen(r)

... hanging here...

Meanwhile, I assumed bytearray works as expected.
>>> r = Request('https://www.python.org', bytearray('post=data', 'utf-8'))
>>> urlopen(r)
....
....
urllib.error.HTTPError: HTTP Error 403: FORBIDDEN

In *4.patch, I updated Request class doc to add these observations and fixed issues appeared in last patch.

----------
Added file: http://bugs.python.org/file40912/urllib_request_param_type_check_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25439>
_______________________________________

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: [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 16:08:08 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 31 Oct 2015 20:08:08 +0000
Subject: [issue25450] Python 3.5 starts in C:\Windows\system32 as current
 directory
In-Reply-To: <1445376716.84.0.123418793499.issue25450@psf.upfronthosting.co.za>
Message-ID: <20151031200805.74103.77696@psf.io>


Roundup Robot added the comment:

New changeset df12c29882b1 by Steve Dower in branch '3.5':
Issue #25450: Updates shortcuts to start Python in installation directory.
https://hg.python.org/cpython/rev/df12c29882b1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25450>
_______________________________________

From report at bugs.python.org  Sat Oct 31 16:09:37 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 31 Oct 2015 20:09:37 +0000
Subject: [issue25450] Python 3.5 starts in C:\Windows\system32 as current
 directory
In-Reply-To: <1445376716.84.0.123418793499.issue25450@psf.upfronthosting.co.za>
Message-ID: <1446322177.33.0.100186728012.issue25450@psf.upfronthosting.co.za>


Steve Dower added the comment:

I've fixed the shortcuts. Let me know if you add any extra command line options to Idle for setting a more useful start directory and I can add those to the shortcuts as well.

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25450>
_______________________________________

From report at bugs.python.org  Sat Oct 31 16:09:51 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 31 Oct 2015 20:09:51 +0000
Subject: [issue25450] Python 3.5 starts in C:\Windows\system32 as current
 directory
In-Reply-To: <1445376716.84.0.123418793499.issue25450@psf.upfronthosting.co.za>
Message-ID: <1446322191.06.0.701795190298.issue25450@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25450>
_______________________________________

From report at bugs.python.org  Sat Oct 31 16:40:31 2015
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 31 Oct 2015 20:40:31 +0000
Subject: [issue25525] Deallocation scheme for memoryview is unsafe
In-Reply-To: <1446318862.67.0.0722395026507.issue25525@psf.upfronthosting.co.za>
Message-ID: <1446324031.04.0.801735667784.issue25525@psf.upfronthosting.co.za>


Stefan Krah added the comment:

The "chained memoryviews" you refer to are a hack and simply
aren't supported. Please stop spreading FUD.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25525>
_______________________________________

From report at bugs.python.org  Sat Oct 31 16:47:35 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 31 Oct 2015 20:47:35 +0000
Subject: [issue25525] Deallocation scheme for memoryview is unsafe
In-Reply-To: <1446318862.67.0.0722395026507.issue25525@psf.upfronthosting.co.za>
Message-ID: <1446324455.16.0.369228046401.issue25525@psf.upfronthosting.co.za>


Martin Panter added the comment:

Did you forget your patch? :)

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25525>
_______________________________________

From report at bugs.python.org  Sat Oct 31 17:10:21 2015
From: report at bugs.python.org (John Hagen)
Date: Sat, 31 Oct 2015 21:10:21 +0000
Subject: [issue25521] optparse module does not emit DeprecationWarning
In-Reply-To: <1446247354.16.0.386152814173.issue25521@psf.upfronthosting.co.za>
Message-ID: <1446325821.59.0.808272291721.issue25521@psf.upfronthosting.co.za>


John Hagen added the comment:

First time trying to contribute to the Python standard library.

I attached a patch that is modeled off the deprecated imp module.  The DeprecationWarning message is taken from the Python docs: https://docs.python.org/3/library/optparse.html

----------
keywords: +patch
Added file: http://bugs.python.org/file40913/optparse_deprecationwarning.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25521>
_______________________________________

From report at bugs.python.org  Sat Oct 31 17:29:13 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 31 Oct 2015 21:29:13 +0000
Subject: [issue24539] StreamReaderProtocol.eof_received() should return True
 to keep the transport open
In-Reply-To: <1435668886.87.0.254771488213.issue24539@psf.upfronthosting.co.za>
Message-ID: <1446326953.19.0.108195445679.issue24539@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"Victor, is there a reason this issue is still open?  Is it because of the warnings question?  Maybe that should be a new issue?"

I just merged from Github to CPython. I don't know if something remains to do in this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24539>
_______________________________________

From report at bugs.python.org  Sat Oct 31 17:42:33 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 31 Oct 2015 21:42:33 +0000
Subject: [issue25194] Opt-in motivations & affiliations page for core
 contributors
In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za>
Message-ID: <1446327753.33.0.942096583884.issue25194@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

New patch attached that revises the preamble to include an explicit goals section that links out to the issue tracker stats page that demonstrates that we have a problem with a lack of core reviewer time.

Much of the rest of that section has been moved up from its former location in the "Limitations" section, but some of it is new (in particular, the paragraph specifically encouraging people to look for ways to spend work time on mentoring new contributors).

The preamble is already really long (and I'm definitely open to suggestions for making it shorter), so I *didn't* try to include an explanation of how the inequitable distribution of free time means that getting more paid involvement in core development should also help improve the diversity of the core reviewer list. The gist is that as more opportunities exist to pursue CPython development as a paid activity (even if it's only one part of a larger job), then that helps remove "has lots of spare time for volunteer software development" as a gating criterion for becoming a core reviewer.

I'll ping the folks I was talking to off list to see if they'd like to comment here, or otherwise provide feedback on the new draft.

----------
Added file: http://bugs.python.org/file40914/motivations-preamble-with-goals.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25194>
_______________________________________

From report at bugs.python.org  Sat Oct 31 17:43:59 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 31 Oct 2015 21:43:59 +0000
Subject: [issue25194] Opt-in motivations & affiliations page for core
 contributors
In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za>
Message-ID: <1446327839.88.0.590210203352.issue25194@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

One other note: I've only linked to OpenHub, and not GitHub, as I don't know how to get a "last 12 months" statistics link for GitHub, instead of either a fixed date range or the entire commit history.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25194>
_______________________________________

From report at bugs.python.org  Sat Oct 31 17:59:03 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Oct 2015 21:59:03 +0000
Subject: [issue25525] Deallocation scheme for memoryview is unsafe
In-Reply-To: <1446318862.67.0.0722395026507.issue25525@psf.upfronthosting.co.za>
Message-ID: <1446328743.46.0.0502677617657.issue25525@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, the "chained memoryviews" in ctypes are a hack and it will be eliminated. But this hack exposed possible weak point in memoryview.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25525>
_______________________________________

From report at bugs.python.org  Sat Oct 31 18:33:22 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 31 Oct 2015 22:33:22 +0000
Subject: [issue22450] urllib doesn't put Accept: */* in the headers
In-Reply-To: <1411257032.38.0.526589346468.issue22450@psf.upfronthosting.co.za>
Message-ID: <1446330802.14.0.137307081793.issue22450@psf.upfronthosting.co.za>


Martin Panter added the comment:

I propose rejecting this one, in favour of the caller adding their own ?Accept: */*? (or more preferably, ?Accept: application/json?) header. What do you think, Raymond or Senthil?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22450>
_______________________________________

From report at bugs.python.org  Sat Oct 31 18:44:01 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 31 Oct 2015 22:44:01 +0000
Subject: [issue25439] Add type checks to urllib.request.Request
In-Reply-To: <1445247083.91.0.927080887762.issue25439@psf.upfronthosting.co.za>
Message-ID: <1446331441.74.0.0565411233503.issue25439@psf.upfronthosting.co.za>


Martin Panter added the comment:

The bytes-like thing applies equally well to both the direct and iterable cases. Your first attempt hangs because the client only sends the four bytes in b"post", but the server is waiting for a total of 10 bytes.

The SSL problem doesn?t show up unless you use more obscure types like ctypes or array.array, where len() does not work as expected. Here is a demo:

>>> import ctypes
>>> byteslike = ctypes.c_char(b"x")
>>> urlopen("http://python.org/", data=byteslike)  # Succeeds
<http.client.HTTPResponse object at 0xb6bc876c>
>>> urlopen("https://python.org/", data=byteslike)
  File "/usr/lib/python3.4/ssl.py", line 720, in sendall
    amount = len(data)
TypeError: object of type 'c_char' has no len()

During handling of the above exception, another exception occurred:

TypeError: data should be a bytes-like object or an iterable, got <class 'ctypes.c_char'>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25439>
_______________________________________

From report at bugs.python.org  Sat Oct 31 19:15:51 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 31 Oct 2015 23:15:51 +0000
Subject: [issue25439] Add type checks to urllib.request.Request
In-Reply-To: <1445247083.91.0.927080887762.issue25439@psf.upfronthosting.co.za>
Message-ID: <1446333351.07.0.566814850732.issue25439@psf.upfronthosting.co.za>


Martin Panter added the comment:

This illustrates my concern with the dict-of-bytes check:

>>> headers = {"Content-Length": "3"}
>>> byteslike_iterable = {memoryview(b"123"): None}
>>> urlopen(Request("http://python.org/", headers=headers, data=byteslike_iterable))

With the current patch I think this would become an error. But maybe I am being too nitpicky and paranoid. Ezio?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25439>
_______________________________________

From report at bugs.python.org  Sat Oct 31 20:11:23 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 01 Nov 2015 00:11:23 +0000
Subject: [issue25450] Python 3.5 starts in C:\Windows\system32 as current
 directory
In-Reply-To: <1445376716.84.0.123418793499.issue25450@psf.upfronthosting.co.za>
Message-ID: <1446336683.53.0.730930657803.issue25450@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Steve, I am adding you as nosy on #22121, which is now about adding a new startup option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25450>
_______________________________________

From report at bugs.python.org  Sat Oct 31 20:12:00 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Sun, 01 Nov 2015 00:12:00 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1446336720.26.0.879638204528.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

Unfortunately, in spite of the other minor issues that resolved,I am still getting a bus error when the hash test runs.

Before I dive back into trying to get gdb working to debug this, is there any way to skip this test to see of the others run?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Sat Oct 31 21:58:58 2015
From: report at bugs.python.org (Memeplex)
Date: Sun, 01 Nov 2015 01:58:58 +0000
Subject: [issue25509] PyImport_ImportModule inaccurately described
In-Reply-To: <1446120404.56.0.248022316134.issue25509@psf.upfronthosting.co.za>
Message-ID: <1446343138.26.0.104349348162.issue25509@psf.upfronthosting.co.za>


Memeplex added the comment:

Brett, I'm not sure about that, notice that the "import hook" as is mentioned in the docs is just the current __import__ in the builtins module (which could have been replaced and in this sense would be a "hook") but not proper import hooks. I think the original distinction between PyImport_ImportModule and PyImport_Import is still sensible today. Originally PyImport_ImportModule directly called the import machinery, while PyImport_Import called it indirectly through builtins.__import__ (which could have been replaced). Now, for some reason, for good or for bad, PyImport_ImportModule also goes through builtins.__import__. The documentation is wrong but what is the fix? Revert PyImport_ImportModule or redocument it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25509>
_______________________________________

From report at bugs.python.org  Sat Oct 31 22:17:18 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 01 Nov 2015 02:17:18 +0000
Subject: [issue22121] IDLE should start with HOME as the initial working
 directory
In-Reply-To: <1406966032.01.0.548285467026.issue22121@psf.upfronthosting.co.za>
Message-ID: <1446344238.57.0.0253103084866.issue22121@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I retract my previous statement "Splattering .py files in ~HOME is not tremendously better than doing the same in the executable directory." and agree that when started with the default Windows icon, IDLE should start in %USERPROFILE%. 

Discussion for #25450 clarified some of the practical issues.  Windows icons have a Shortcut tab with a Start-in field.  We should like to put %USERPROFILE% there, but this does not work -- msg253393.

Steve Dower suggested to instead add a new command line option to set the starting directory for code entered in the shell window.  (IDLE currently uses getopt with
  USAGE: idle  [-deins] [-t title] [file]*
         idle  [-dns] [-t title] (-c cmd | -r file) [arg]*
I suggest adding option '-w path' (w for 'working directory' or 'workspace', d already being used).  Any better ideas?  Like d, s, t, c, and r, the new option would imply -i, open a shell window.

Shortcut tabs also have a 'target' field.  For 3.5, this is an editable command line.  I tested that adding "-t %USERPROFILE%" changes the Shell title accordingly.  Steve has already change the installed icon.  

Users could copy the icon and add a subdirectory, such as 'python', where they put python code.  I presume users on other systems could do the equivalent, so the benefit of this is not limited to Windows.

For prior Python versions, the Shortcut 'target' is a read-only grayed-out 'Python x.y.z (nn bits)'.  I do not know how this is resolved to running IDLE with the specified binary, but it likely would not be easy to change to the 3.5 editable field version (and not create other problems in the process). So I will not even ask MVL, the previous Windows installer maintainer, to do that.

idlelib/idle.bat was added to get around the inability to edit this field. (ADD DOC for this.)  So the new startup option could be used by Windows users to start older IDLEs in their home directory.

----------
nosy: +steve.dower
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22121>
_______________________________________

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: [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>
_______________________________________

From report at bugs.python.org  Sat Oct 31 23:01:37 2015
From: report at bugs.python.org (Memeplex)
Date: Sun, 01 Nov 2015 03:01:37 +0000
Subject: [issue25509] PyImport_ImportModule inaccurately described
In-Reply-To: <1446120404.56.0.248022316134.issue25509@psf.upfronthosting.co.za>
Message-ID: <1446346897.84.0.676231747221.issue25509@psf.upfronthosting.co.za>


Memeplex added the comment:

Well it's like that since 2.1 so I guess the doc is wrong indeee.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25509>
_______________________________________