From report at bugs.python.org  Fri Apr  1 00:09:02 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 01 Apr 2016 04:09:02 +0000
Subject: [issue26682] Ttk Notebook tabs do not show with 1-2 char names
In-Reply-To: <1459470501.64.0.00235900367072.issue26682@psf.upfronthosting.co.za>
Message-ID: <1459483742.19.0.944259436275.issue26682@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I see the names of the first 4 tabs: 0-3. Tab header for the last tab is empty. If use longer name (e.g. "45678") I see it without two last characters ("456").

Yes, it looks as Ttk bug. Have you reported this to the mainstream?

----------

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

From report at bugs.python.org  Fri Apr  1 00:46:29 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 01 Apr 2016 04:46:29 +0000
Subject: [issue26684] pathlib.Path.with_name() and .with_suffix do not allow
 combining with an empty Path
In-Reply-To: <1459479889.57.0.867705716846.issue26684@psf.upfronthosting.co.za>
Message-ID: <1459485989.6.0.595038321013.issue26684@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is no a bug. This is the documented and reasonable behavior. What behavior you expect?

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

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

From report at bugs.python.org  Fri Apr  1 00:49:37 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 01 Apr 2016 04:49:37 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1459486177.27.0.586943123943.issue26680@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Agree with Raymond.

float.is_integer(x) is more efficient than x==int(x), but is this method used anywhere at all? It was added as a part of issue2224.

----------
nosy: +christian.heimes, serhiy.storchaka

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

From report at bugs.python.org  Fri Apr  1 00:53:44 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 Apr 2016 04:53:44 +0000
Subject: [issue26683] Questionable terminology for describing what locals()
 does
In-Reply-To: <1459474292.87.0.515226107717.issue26683@psf.upfronthosting.co.za>
Message-ID: <1459486424.89.0.597390584648.issue26683@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> A national variable maybe :)

I would think that "nonlocal" is exactly the right term given that that is how you would declare it if you wanted to write to it.

>>> w = 5

>>> def f(x):
        def g(y):
            nonlocal x
            global w
            z = x + y
            x += 1
            print(locals())
            print(globals())
        return g

>>> f(10)(20)
{'y': 20, 'x': 11, 'z': 30}
{'w': 5, ...}

----------

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

From report at bugs.python.org  Fri Apr  1 02:13:00 2016
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 01 Apr 2016 06:13:00 +0000
Subject: [issue26684] pathlib.Path.with_name() and .with_suffix do not allow
 combining with an empty Path
In-Reply-To: <1459479889.57.0.867705716846.issue26684@psf.upfronthosting.co.za>
Message-ID: <1459491180.81.0.776829524725.issue26684@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Never mind.

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

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

From report at bugs.python.org  Fri Apr  1 03:22:31 2016
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 01 Apr 2016 07:22:31 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1459495351.81.0.348140357792.issue26680@psf.upfronthosting.co.za>


Stefan Krah added the comment:

is_integer() is very important for writing new functions. libmpdec has
it and it's used a lot inside mpdecimal.c.


In this case though I assume Robert needs it for duck typing.

----------

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

From report at bugs.python.org  Fri Apr  1 03:26:25 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Apr 2016 07:26:25 +0000
Subject: [issue26676] Add missing XMLPullParser to ElementTree.__all__
In-Reply-To: <1459411869.75.0.477396717658.issue26676@psf.upfronthosting.co.za>
Message-ID: <20160401072620.97187.32213.7E514AA9@psf.io>


Roundup Robot added the comment:

New changeset 3d6b67361749 by Martin Panter in branch 'default':
Issue #26676: Add missing XMLPullParser to ElementTree.__all__
https://hg.python.org/cpython/rev/3d6b67361749

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

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

From report at bugs.python.org  Fri Apr  1 04:48:34 2016
From: report at bugs.python.org (Robert Smallshire)
Date: Fri, 01 Apr 2016 08:48:34 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1459500514.14.0.215494833413.issue26680@psf.upfronthosting.co.za>


Robert Smallshire added the comment:

As for whether the shortcut float.is_integer(x) was needed, it has different behavior to x==int(x) when x is either NaN or an infinity.  We must even deal with two different exception types OverflowError or ValueError respectively for these two values on conversion to int. That float.is_integer() simply returns False for these values makes it more straightforward to use robustly. The same would go for Decimal, which has the same behavior with respect to NaNs and infinities as float.

I agree that is_integral may have been a better name, although is_integer has the advantage that it avoids conflating numeric values with either of the types 'int' or 'Integral'.

The motivation for my patches is to converge the interfaces of the various number types so that we can simply, and robustly, check for integer values (as opposed to integer types) without needing to be concerned about the concrete number type, so long as it is Real.  Indeed, this is largely the point of having a numeric tower at all.  I am more motivated by usability and concision and correctness than efficiency concerns: I believe that where
possible we should allow one number type to be substituted for another, and in particular `int` for any other Real type where purely mathematical - rather than representational operations - are in play.

Use of the existing float.is_integer is compromised by the fact that people have an entirely reasonably habit of passing integers (particularly literals) to functions which accept floats which then fail if they use float.is_integer.

Adding this method would reduce the educational load as the various number types would be more similar, not less.

I work in industrial fields where computational geometry, and hence rationals, floats, infinities and large integers are a day-to-day occurrence. Ultimately, I care more about consistency within the numeric tower types (Real, float, int, Rational, Integral, Fraction) than I do about Decimal, which is why I separated my changes to Decimal into a separate patch.

----------

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

From report at bugs.python.org  Fri Apr  1 04:52:44 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Fri, 01 Apr 2016 08:52:44 +0000
Subject: [issue26488] hashlib command line interface
In-Reply-To: <1457214866.19.0.989950954277.issue26488@psf.upfronthosting.co.za>
Message-ID: <1459500764.04.0.787067548694.issue26488@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

I am adding a new patch with changes from Martin CR (Thanks for the review) and support in the "check" option.
I also changed to examples in the Documentation to use sha256 instead of md5 as Christian asked. I left one example with sha1 so when someone read it he will see that other algorithms are supported.
As for the multi-threading feature I checked on my PC and I never reach 100% CPU when calculating a single hash so I think leaving this feature out is better.

----------
Added file: http://bugs.python.org/file42340/hashlib-script-mod-md5sum-style-3.patch

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

From report at bugs.python.org  Fri Apr  1 04:57:27 2016
From: report at bugs.python.org (=?utf-8?b?SsSBbmlzIMWgbGFwacWGxaE=?=)
Date: Fri, 01 Apr 2016 08:57:27 +0000
Subject: [issue26606] logging.baseConfig is missing the encoding parameter
In-Reply-To: <1458598626.88.0.490041392552.issue26606@psf.upfronthosting.co.za>
Message-ID: <1459501047.17.0.738118360482.issue26606@psf.upfronthosting.co.za>


J?nis ?lapi?? added the comment:

Yes, it also works. But then you have also to remember to restore sys.stdout to the initial state at the end. In addition, for non-English languages it would be more appropriate to use codecs.open() instead of just open() in this case.
The complexity of the code grows and increases a danger of "more code, more bugs".

Why to use a "detour" and try always to remember that a part of a module is not useful for you due to particual drawbacks if it is possible to implement a small addition in it that does not break anything?

----------

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

From report at bugs.python.org  Fri Apr  1 05:14:57 2016
From: report at bugs.python.org (Andy Maier)
Date: Fri, 01 Apr 2016 09:14:57 +0000
Subject: [issue26678] Incorrect linking to elements in datetime package
In-Reply-To: <1459445799.81.0.161788997927.issue26678@psf.upfronthosting.co.za>
Message-ID: <1459502097.3.0.909175874189.issue26678@psf.upfronthosting.co.za>


Andy Maier added the comment:

Hi Martin!

The intersphinx stuff is simply linking from a Sphinx RST documentation to a different Sphinx RST documentation, using support from the intersphinx extension of Sphinx. I think the name comes from the interwiki links in MediaWiki. It only comes into play here because my particular documentation is outside of the Python documentation. The same issues would arise when linking from other places in the Python documentation.

Your explanation about :noindex: hits the nail on the head, I think. It seems to me that a minimal variant for fixing this would be:

* add :noindex: to the class markup for the short descriptions of tzinfo and timezone.
* add a class markup for tzinfo at its long description.

I don't know whether that solves the method linking issue, though, but its worth a try.

----------

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

From report at bugs.python.org  Fri Apr  1 05:15:43 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 01 Apr 2016 09:15:43 +0000
Subject: [issue26676] Add missing XMLPullParser to ElementTree.__all__
In-Reply-To: <1459411869.75.0.477396717658.issue26676@psf.upfronthosting.co.za>
Message-ID: <1459502143.22.0.014809229645.issue26676@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium at yahoo.com.au>:


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

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

From report at bugs.python.org  Fri Apr  1 05:34:10 2016
From: report at bugs.python.org (Werner Van Geit)
Date: Fri, 01 Apr 2016 09:34:10 +0000
Subject: [issue13952] mimetypes doesn't recognize .csv
In-Reply-To: <1328550236.31.0.476108753678.issue13952@psf.upfronthosting.co.za>
Message-ID: <1459503250.54.0.570610816239.issue13952@psf.upfronthosting.co.za>


Werner Van Geit added the comment:

Will this patch ever make it into the main python version ? I just ran into exactly this issue (mimetypes returns None as mimetype of csv file on Windows)

----------
nosy: +Werner Van Geit
versions: +Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Apr  1 05:42:49 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 01 Apr 2016 09:42:49 +0000
Subject: [issue26682] Ttk Notebook tabs do not show with 1-2 char names
In-Reply-To: <1459470501.64.0.00235900367072.issue26682@psf.upfronthosting.co.za>
Message-ID: <1459503769.49.0.611538971336.issue26682@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

No, I can't remember where it is and do not have an account on their tracker, if one is needed.

----------

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

From report at bugs.python.org  Fri Apr  1 05:44:26 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 01 Apr 2016 09:44:26 +0000
Subject: [issue26682] Ttk Notebook tabs do not show with 1-2 char names
In-Reply-To: <1459470501.64.0.00235900367072.issue26682@psf.upfronthosting.co.za>
Message-ID: <1459503866.95.0.701107553705.issue26682@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I am not surprised, somehow, that details of bug should depend on system.  I should have said Win 10, 3.5.1/8.6.4.

----------

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

From report at bugs.python.org  Fri Apr  1 05:50:29 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 01 Apr 2016 09:50:29 +0000
Subject: [issue21069] test_fileno of test_urllibnet intermittently fails
In-Reply-To: <1395821437.54.0.612861702522.issue21069@psf.upfronthosting.co.za>
Message-ID: <1459504229.69.0.00970134744354.issue21069@psf.upfronthosting.co.za>


Martin Panter added the comment:

Mark: My understanding is on Windows, winsock file descriptors and C library file descriptors are different beasts; see <https://docs.python.org/3/library/socket.html#socket.socket.fileno>. Perhaps the test should call socket functions like socket.recv() on the FD rather than C library functions via os.fdopen().

Victor: The test in this bug has started failing again, very likely due to your revision 7bd4736195ce enabling a timeout on the HTTP request. I guess this causes the socket to be in non-blocking mode, and read() to return None. This is what Issue 10119 tried to fix. Example:

http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.x/builds/3404/steps/test/logs/stdio
======================================================================
FAIL: test_fileno (test.test_urllibnet.urlopenNetworkTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_urllibnet.py", line 110, in test_fileno
    self.assertTrue(f.read(), "reading from file created using fd "
AssertionError: None is not true : reading from file created using fd returned by fileno failed

A less serious and long-standing problem with the test is that it attempts to close the socket twice. We are just lucky that socket.close() is called second, which does not raise any errors: <https://hg.python.org/cpython/annotate/8938b3132caa/Modules/socketmodule.c#l259>.

Regarding the purpose and use cases of fileno(), I agree with Senthil that using it to read the HTTP response behind the HTTPResponse object?s back in Python 3 is a bad idea, and I don?t think it is practical to make this work without losing the benefits of buffering. But there are probably other valid use cases such as calling getsockname() on the socket, or sending and receiving non-HTTP data after setting up a CONNECT tunnel.

Proposals:

1. Change the test to do use socket(fileno=...), rather than os.fdopen(...), so that it will be usable on Windows.

2. Ensure that the secondary socket object is not closed; use socket.detach()

3. Rewrite the test to test http.client directly, rather than indirectly through urlopen(). As far as I can see the purpose is only to test HTTPResponse.fileno(), not urlopen().

4. Rewrite the test to test a local server run in a background thread, rather than relying external web sites (currently Google, previously IETF, and Python). This would eliminate the need for setting a timeout.

5. Rewrite to the test for a more realistic use case that does not depend on specific internal HTTPResponse buffering and the HTTP protocol. I suggest mocking a CONNECT request, and uploading some non-HTTP data through the proxy.

----------
components: +Tests
keywords: +buildbot -patch
nosy: +haypo, martin.panter
stage: test needed -> needs patch
title: test_fileno of test_urllibnet intermittently fails when using www.example.com -> test_fileno of test_urllibnet intermittently fails
type:  -> behavior
versions: +Python 3.6 -Python 3.4

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

From report at bugs.python.org  Fri Apr  1 06:16:21 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 01 Apr 2016 10:16:21 +0000
Subject: [issue26671] Clean up path_converter in posixmodule.c
In-Reply-To: <1459330274.5.0.616265410958.issue26671@psf.upfronthosting.co.za>
Message-ID: <1459505781.46.0.271632302739.issue26671@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Good catch! Here is updated patch. It fixes also hiding exception in dir_fd converter.

----------
Added file: http://bugs.python.org/file42341/path_converter_cleanup_2.patch

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

From report at bugs.python.org  Fri Apr  1 06:52:23 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 01 Apr 2016 10:52:23 +0000
Subject: [issue21069] test_fileno of test_urllibnet intermittently fails
In-Reply-To: <1395821437.54.0.612861702522.issue21069@psf.upfronthosting.co.za>
Message-ID: <1459507943.18.0.110199012362.issue21069@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

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

From report at bugs.python.org  Fri Apr  1 07:16:28 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 01 Apr 2016 11:16:28 +0000
Subject: [issue26685] Raise errors from socket.close()
Message-ID: <1459509388.35.0.801044830009.issue26685@psf.upfronthosting.co.za>


New submission from Martin Panter:

While looking at a recent failure of test_fileno() in test_urllibnet, I discovered that socket.close() ignores the return value of the close() system call. It looks like it has always been this way: <https://docs.python.org/3/library/socket.html#socket.socket.fileno>.

On the other hand, both FileIO.close() and os.close() raise an exception if the underlying close() call fails. So I propose to make socket.close() also raise an exception for any failure indicated by the underlying close() call. The benefit is that a programming error causing EBADF would be more easily noticed.

----------
components: Extension Modules
files: socket.close.patch
keywords: patch
messages: 262735
nosy: martin.panter
priority: normal
severity: normal
stage: patch review
status: open
title: Raise errors from socket.close()
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42342/socket.close.patch

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

From report at bugs.python.org  Fri Apr  1 07:17:49 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 01 Apr 2016 11:17:49 +0000
Subject: [issue26685] Raise errors from socket.close()
In-Reply-To: <1459509388.35.0.801044830009.issue26685@psf.upfronthosting.co.za>
Message-ID: <1459509469.43.0.547584524153.issue26685@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium at yahoo.com.au>:


----------
dependencies: +test_fileno of test_urllibnet intermittently fails

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

From report at bugs.python.org  Fri Apr  1 07:45:09 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 01 Apr 2016 11:45:09 +0000
Subject: [issue26678] Incorrect linking to elements in datetime package
In-Reply-To: <1459445799.81.0.161788997927.issue26678@psf.upfronthosting.co.za>
Message-ID: <1459511109.1.0.18463087272.issue26678@psf.upfronthosting.co.za>


Martin Panter added the comment:

I?m happy to make those two minimal changes (:noindex: and tzinfo class), but I have a feeling they won?t help your problem linking to datetime.tzinfo.utcoffset() and dst(). The markup for those methods already generates index entries, see <https://docs.python.org/dev/genindex-U.html> for instance.

----------

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

From report at bugs.python.org  Fri Apr  1 08:10:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Apr 2016 12:10:24 +0000
Subject: [issue26685] Raise errors from socket.close()
In-Reply-To: <1459509388.35.0.801044830009.issue26685@psf.upfronthosting.co.za>
Message-ID: <1459512623.99.0.622209123279.issue26685@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I like the idea :-)

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

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

From report at bugs.python.org  Fri Apr  1 08:26:23 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Apr 2016 12:26:23 +0000
Subject: [issue26671] Clean up path_converter in posixmodule.c
In-Reply-To: <1459330274.5.0.616265410958.issue26671@psf.upfronthosting.co.za>
Message-ID: <1459513583.48.0.620470673504.issue26671@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/issue26671>
_______________________________________

From report at bugs.python.org  Fri Apr  1 09:13:23 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Fri, 01 Apr 2016 13:13:23 +0000
Subject: [issue17436] hashlib: add a method to hash the content of a file
In-Reply-To: <1363428672.22.0.18562351596.issue17436@psf.upfronthosting.co.za>
Message-ID: <1459516403.26.0.458800853443.issue17436@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

While working on issue 26488 I found a real need for this feature.
I added a new method to the hash object named fromfile(). The function update the hash object with the content of the file like object it receives.

I only added the feature to hash algorithm provided by OpenSSL. If there will be good reviews on this I will do the work of adding this to all hash algorithms.

----------
keywords: +patch
nosy: +palaviv
versions: +Python 3.6 -Python 3.4
Added file: http://bugs.python.org/file42343/17436.patch

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

From report at bugs.python.org  Fri Apr  1 09:23:23 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Apr 2016 13:23:23 +0000
Subject: [issue17436] hashlib: add a method to hash the content of a file
In-Reply-To: <1363428672.22.0.18562351596.issue17436@psf.upfronthosting.co.za>
Message-ID: <1459517003.98.0.634944122485.issue17436@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I added a new method to the hash object named fromfile().

Usually, fromxxx() is used to create a new object. In your case, it's more to update an existing hash object. So I would prefer the name "readfile".

IMHO you need two methods:

* hashobj.readfile(filename: str)
* hashobj.readfileobj(file) where file is an object with a read() method which returns bytes strings

The implementation of the two methods can be very different. In readfile(), you know that it's a regular file which exists on the file system. So you can directly uses _Py_fstat() to get st_blksize and then loop on _Py_read().

For readfileobj(), the file object doesn't need to exist on disk, fileno() can raises an exception or not exist at all.

I suggest to look at copyfile() and copyfileobj() functions of the shutil module. For example, copyfileobj() has an optional parameter for the buffer size. You should probably uses that to avoid complex heuristic to guess the optimal buffer size.

----------

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

From report at bugs.python.org  Fri Apr  1 09:27:36 2016
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 01 Apr 2016 13:27:36 +0000
Subject: [issue17436] hashlib: add a method to hash the content of a file
In-Reply-To: <1363428672.22.0.18562351596.issue17436@psf.upfronthosting.co.za>
Message-ID: <1459517256.01.0.792882252568.issue17436@psf.upfronthosting.co.za>


Christian Heimes added the comment:

For readfile() it might make more sense to implement it directly in C and let OpenSSL's BIO layer handle IO internally. It's more efficient and you can release the GIL around the whole operation.

----------
nosy: +christian.heimes

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

From report at bugs.python.org  Fri Apr  1 10:02:39 2016
From: report at bugs.python.org (wysaard)
Date: Fri, 01 Apr 2016 14:02:39 +0000
Subject: [issue26673] Tkinter error when opening IDLE configuration menu
In-Reply-To: <1459351920.73.0.899924616631.issue26673@psf.upfronthosting.co.za>
Message-ID: <1459519359.37.0.00185899259594.issue26673@psf.upfronthosting.co.za>


wysaard added the comment:

I'm having the problem if I'm running idle with Python 2.7.11 too.

----------

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

From report at bugs.python.org  Fri Apr  1 10:03:58 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 01 Apr 2016 14:03:58 +0000
Subject: [issue26673] Tkinter error when opening IDLE configuration menu
In-Reply-To: <1459351920.73.0.899924616631.issue26673@psf.upfronthosting.co.za>
Message-ID: <1459519438.9.0.387378720165.issue26673@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
versions: +Python 2.7

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

From report at bugs.python.org  Fri Apr  1 10:08:18 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Apr 2016 14:08:18 +0000
Subject: [issue26670] Add a developer mode: -X dev command line option
In-Reply-To: <1459326014.81.0.126746862215.issue26670@psf.upfronthosting.co.za>
Message-ID: <1459519698.86.0.214330339226.issue26670@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Why does this patch execv() the interpreter to set options? I'd expect it to be possible to get the same result by updating the argument parsing code in Py_Main.

It's to set PYTHONMALLOC env var which must be set before Py_Main() is called.

Since I got negative feedback on python-ideas, I close this issue and will investigate the documentation option.

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

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

From report at bugs.python.org  Fri Apr  1 10:17:52 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 01 Apr 2016 14:17:52 +0000
Subject: [issue26670] Add a developer mode: -X dev command line option
In-Reply-To: <1459326014.81.0.126746862215.issue26670@psf.upfronthosting.co.za>
Message-ID: <1459520272.9.0.885361571308.issue26670@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
resolution: fixed -> rejected
stage:  -> resolved

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

From report at bugs.python.org  Fri Apr  1 11:39:33 2016
From: report at bugs.python.org (Andy Maier)
Date: Fri, 01 Apr 2016 15:39:33 +0000
Subject: [issue26678] Incorrect linking to elements in datetime package
In-Reply-To: <1459445799.81.0.161788997927.issue26678@psf.upfronthosting.co.za>
Message-ID: <1459525173.75.0.316832616541.issue26678@psf.upfronthosting.co.za>


Andy Maier added the comment:

Ok. If these methods generate index entries, maybe the problem is on my side by not linking them correctly. So let's try with the other two changes.

Unfortunately, I cannot easily build cpython at the moment to verify, I moved to Linux and when trying to build cpython, bash rejects the configure script because of trailing CR characters. This is a freshly installed hg package on Ubuntu 14.04, against a fresh clone of the cpython repo. Any idea what is happening there?

----------

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

From report at bugs.python.org  Fri Apr  1 11:43:11 2016
From: report at bugs.python.org (Christian Kleineidam)
Date: Fri, 01 Apr 2016 15:43:11 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1459525391.54.0.847845341376.issue18844@psf.upfronthosting.co.za>


Christian Kleineidam added the comment:

A user can use map(), filter(), zip() without knowing anything about generators. In most cases those function will do their magic and provide a finite number of outputs. 

The weighted_choice_generator on the other hand isn't as easy to use. If the user wants 5 values from it, they need to know about `take()` from itertools or call `next()`.

----------

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

From report at bugs.python.org  Fri Apr  1 11:43:47 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 01 Apr 2016 15:43:47 +0000
Subject: [issue26679] curses: Descripton of KEY_NPAGE and KEY_PPAGE inverted
In-Reply-To: <1459452822.7.0.402599297468.issue26679@psf.upfronthosting.co.za>
Message-ID: <1459525427.89.0.323277832251.issue26679@psf.upfronthosting.co.za>


SilentGhost added the comment:

Here is the patch.

----------
nosy: +SilentGhost
stage:  -> patch review
type: enhancement -> behavior
Added file: http://bugs.python.org/file42344/issue26679.diff

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

From report at bugs.python.org  Fri Apr  1 12:03:29 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 01 Apr 2016 16:03:29 +0000
Subject: [issue26606] logging.baseConfig is missing the encoding parameter
In-Reply-To: <1458598626.88.0.490041392552.issue26606@psf.upfronthosting.co.za>
Message-ID: <1459526609.06.0.53041135429.issue26606@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

> you have also to remember to restore sys.stdout

I'm not sure you understand how it works. The value of sys.stdout isn't changed, so why does it need to be restored?

> for non-English languages it would be more appropriate to use codecs.open() instead of just open()

codecs.open() for older versions of Python, perhaps, but in newer Pythons (this issue is marked for Python 3.5), open is io.open which takes an encoding parameter.

basicConfig() is meant for the simplest cases, so you have to draw the line somewhere as to what "basic" means. I don't propose to change where the line is drawn - and AFAIK this is the first time it's come up, so it looks as if the many non-English speaking Python users are managing just fine with basicConfig() as it is ... note that this kind of thing is always a judgement call.

> The complexity of the code grows and increases a danger of "more code, more bugs".

Maybe that's why I'm choosing not to increase the complexity of my code ;-)

----------

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

From report at bugs.python.org  Fri Apr  1 12:41:19 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 01 Apr 2016 16:41:19 +0000
Subject: [issue26488] hashlib command line interface
In-Reply-To: <1457214866.19.0.989950954277.issue26488@psf.upfronthosting.co.za>
Message-ID: <1459528879.7.0.394771991067.issue26488@psf.upfronthosting.co.za>


SilentGhost added the comment:

Left comments on Rietveld.

----------

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

From report at bugs.python.org  Fri Apr  1 13:10:59 2016
From: report at bugs.python.org (=?utf-8?b?6YSt5pmv5paH?=)
Date: Fri, 01 Apr 2016 17:10:59 +0000
Subject: [issue26664] find a bug in activate.fish of venv of cpython3.6
In-Reply-To: <1459255585.37.0.253753371111.issue26664@psf.upfronthosting.co.za>
Message-ID: <1459530659.83.0.284643272518.issue26664@psf.upfronthosting.co.za>


??? added the comment:

First, I use python 3.5.1 to create virtual environment. It works fine with fish. There is no $ in the activate.fish file.
Second, after I removed the $, It works fine, both in ubuntu and arch linux.

I guess it is because the $ is for bash not for fish, the activate.fish didn't work.
These are why I assert the $ is unwanted.

----------

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

From report at bugs.python.org  Fri Apr  1 13:12:30 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Apr 2016 17:12:30 +0000
Subject: [issue26488] hashlib command line interface
In-Reply-To: <1457214866.19.0.989950954277.issue26488@psf.upfronthosting.co.za>
Message-ID: <1459530750.87.0.921518010068.issue26488@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The blocksize should be fixed and large (perhaps 256kB).

I used strace to check md5sum & sha1sum: they use read() syscalls of 32,768 bytes.

stat().st_blksize is 4,096 bytes.

I'm not sure that it matters so much to use large read. But I don't really care, I'm also ok to use something large like 256 kB.

Note: The cp command uses read() syscalls of 131,072 bytes.

----------

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

From report at bugs.python.org  Fri Apr  1 13:46:30 2016
From: report at bugs.python.org (Mark Sapiro)
Date: Fri, 01 Apr 2016 17:46:30 +0000
Subject: [issue26686] email.parser stops parsing headers too soon.
Message-ID: <1459532790.12.0.415003614976.issue26686@psf.upfronthosting.co.za>


New submission from Mark Sapiro:

Given an admittedly defective (the folded Content-Type: isn't indented) message part with the following headers/body

-------------------------------
Content-Disposition: inline; filename="04EBD_xxxx.xxxx_A546BB.zip"
Content-Type: application/x-rar-compressed; x-unix-mode=0600;
name="04EBD_xxxx.xxxx_A546BB.zip"
Content-Transfer-Encoding: base64

UmFyIRoHAM+QcwAADQAAAAAAAABKRXQgkC4ApAMAAEAHAAACJLrQXYFUfkgdMwkAIAAAAGEw
ZjEwZi5qcwDwrrI/DB2NDI0TzcGb3Gpb8HzsS0UlpwELvdyWnVaBQt7Sl2zbJpx1qqFCGGk6
...
-------------------------------

email.parser parses the headers as

-------------------------------
Content-Disposition: inline; filename="04EBD_xxxx.xxxx_A546BB.zip"
Content-Type: application/x-rar-compressed; x-unix-mode=0600;
-------------------------------

and the body as

-------------------------------
name="04EBD_xxxx.xxxx_A546BB.zip"
Content-Transfer-Encoding: base64

UmFyIRoHAM+QcwAADQAAAAAAAABKRXQgkC4ApAMAAEAHAAACJLrQXYFUfkgdMwkAIAAAAGEw
ZjEwZi5qcwDwrrI/DB2NDI0TzcGb3Gpb8HzsS0UlpwELvdyWnVaBQt7Sl2zbJpx1qqFCGGk6
...
-------------------------------

and shows no defects.

This is wrong. RFC5322 section 2.1 is clear that everything up to the first empty line is headers. Even the docstring in the email/parser.py module says "The header block is terminated either by the end of the string or by a blank line."

Since the message is defective, it isn't clear what the correct result should be, but I think

Headers:
Content-Disposition: inline; filename="04EBD_xxxx.xxxx_A546BB.zip"
Content-Type: application/x-rar-compressed; x-unix-mode=0600;
Content-Transfer-Encoding: base64

Body:
UmFyIRoHAM+QcwAADQAAAAAAAABKRXQgkC4ApAMAAEAHAAACJLrQXYFUfkgdMwkAIAAAAGEw
ZjEwZi5qcwDwrrI/DB2NDI0TzcGb3Gpb8HzsS0UlpwELvdyWnVaBQt7Sl2zbJpx1qqFCGGk6
...

Defects:
name="04EBD_xxxx.xxxx_A546BB.zip"

would be more appropriate. The problem is that the Content-Transfer-Encoding: base64 header is not in the headers so that get_payload(decode=True) doesn't decode the base64 encoded body making malware recognition difficult.

----------
components: Library (Lib)
messages: 262750
nosy: msapiro
priority: normal
severity: normal
status: open
title: email.parser stops parsing headers too soon.
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Apr  1 13:50:49 2016
From: report at bugs.python.org (Mark Sapiro)
Date: Fri, 01 Apr 2016 17:50:49 +0000
Subject: [issue26686] email.parser stops parsing headers too soon.
In-Reply-To: <1459532790.12.0.415003614976.issue26686@psf.upfronthosting.co.za>
Message-ID: <1459533049.27.0.998108309302.issue26686@psf.upfronthosting.co.za>


Mark Sapiro added the comment:

Added Python 2.7 to versions:

----------
versions: +Python 2.7

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

From report at bugs.python.org  Fri Apr  1 13:51:18 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 01 Apr 2016 17:51:18 +0000
Subject: [issue26673] Tkinter error when opening IDLE configuration menu
In-Reply-To: <1459351920.73.0.899924616631.issue26673@psf.upfronthosting.co.za>
Message-ID: <1459533078.64.0.0158699136235.issue26673@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Serhiy, what do you make of the TclError?  Could it be an ArchLinux-specific bug in tk?

Here is the entire function:

    def SetFontSample(self, event=None):
        fontName = self.fontName.get()
        fontWeight = tkFont.BOLD if self.fontBold.get() else tkFont.NORMAL
        newFont = (fontName, self.fontSize.get(), fontWeight)
        self.labelFontSample.config(font=newFont)
        self.textHighlightSample.configure(font=newFont)

The first 3 lines were last touched on 2014-08-03, the last 3 on 2012-10-22. The code seem unexceptional.  This works fine for me and, I presume, most everyone else.

wysaard: What tk version does Arch Linux provide you?  Check Help => About IDLE before you hit configure.

----------

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

From report at bugs.python.org  Fri Apr  1 14:12:01 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 01 Apr 2016 18:12:01 +0000
Subject: [issue26686] email.parser stops parsing headers too soon.
In-Reply-To: <1459532790.12.0.415003614976.issue26686@psf.upfronthosting.co.za>
Message-ID: <1459534321.45.0.0266182968134.issue26686@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
components: +email
nosy: +barry, r.david.murray
versions: +Python 3.5 -Python 3.4

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

From report at bugs.python.org  Fri Apr  1 14:24:59 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 01 Apr 2016 18:24:59 +0000
Subject: [issue26683] Questionable terminology for describing what locals()
 does
In-Reply-To: <1459474292.87.0.515226107717.issue26683@psf.upfronthosting.co.za>
Message-ID: <1459535099.79.0.193181068981.issue26683@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I requested that we stop (mis)using 'free variable' in the docs years ago.  A strong +1 from me.

The 'locals' function what named when 'local' and 'non-global' were synonyms.  When non-local, non-global names were added, nonlocals were included with 'locals' as 'non-global'.  (This must have been thought to be more useful than adding nonlocals() or excluding them.)

They are, of course, local in some surrounding non-global context.  And for most purposes, their entries in locals() should also be treated as read-only.  I think the doc should say that function locals() includes the locals of surrounding function contexts, even though they are called 'nonlocal' within the nested function.

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

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

From report at bugs.python.org  Fri Apr  1 14:37:10 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 01 Apr 2016 18:37:10 +0000
Subject: [issue26687] Use Py_RETURN_NONE in sqlite3 module
Message-ID: <1459535830.63.0.539238949684.issue26687@psf.upfronthosting.co.za>


New submission from Berker Peksag:

The attached patch replaces all "Py_INCREF(Py_None); return Py_None;" lines with the Py_RETURN_NONE macro in sqlite3 module.

----------
components: Extension Modules
messages: 262754
nosy: berker.peksag
priority: normal
severity: normal
stage: patch review
status: open
title: Use Py_RETURN_NONE in sqlite3 module
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Fri Apr  1 14:37:32 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 01 Apr 2016 18:37:32 +0000
Subject: [issue26687] Use Py_RETURN_NONE in sqlite3 module
In-Reply-To: <1459535830.63.0.539238949684.issue26687@psf.upfronthosting.co.za>
Message-ID: <1459535852.09.0.907226534879.issue26687@psf.upfronthosting.co.za>


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


----------
keywords: +patch
Added file: http://bugs.python.org/file42345/py_return_none_macro.diff

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

From report at bugs.python.org  Fri Apr  1 14:53:18 2016
From: report at bugs.python.org (wysaard)
Date: Fri, 01 Apr 2016 18:53:18 +0000
Subject: [issue26673] Tkinter error when opening IDLE configuration menu
In-Reply-To: <1459351920.73.0.899924616631.issue26673@psf.upfronthosting.co.za>
Message-ID: <1459536798.42.0.697124988449.issue26673@psf.upfronthosting.co.za>


wysaard added the comment:

In the screen of `About IDLE` it shows "Tk version 8.6.4".
It used to work, as least since last september (when I installed this) I've had no problems. I assumed reinstalling would solve it but that did nothing. I've removed the entire python package, made my package manager download a fresh version and install it from scratch, and did the same with Tk.

Trying to find any related bug reports on the Arch Linux bug tracker I found something linking to this (open) issue: https://bugs.python.org/issue24951
I'm not sure the cause is exactly the same,  but the traceback is near identical.

It seems to have something to do with a config file. Maybe there's something broken in there, or perhaps a something is missing?
A broken config file would be weird as reinstalling doesn't fix anything, unless my package manager doesn't remove the config file when uninstalling the package, which isn't impossible either.

----------

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

From report at bugs.python.org  Fri Apr  1 15:11:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Apr 2016 19:11:24 +0000
Subject: [issue26687] Use Py_RETURN_NONE in sqlite3 module
In-Reply-To: <1459535830.63.0.539238949684.issue26687@psf.upfronthosting.co.za>
Message-ID: <1459537884.66.0.669758105672.issue26687@psf.upfronthosting.co.za>


STINNER Victor added the comment:

py_return_none_macro.diff looks good to me.

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

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

From report at bugs.python.org  Fri Apr  1 15:15:06 2016
From: report at bugs.python.org (Sascha Silbe)
Date: Fri, 01 Apr 2016 19:15:06 +0000
Subject: [issue18293] ssl.wrap_socket (cert_reqs=...), getpeercert,
 and unvalidated certificates
In-Reply-To: <1372100693.76.0.99629035685.issue18293@psf.upfronthosting.co.za>
Message-ID: <1459538106.41.0.0685040416623.issue18293@psf.upfronthosting.co.za>


Sascha Silbe added the comment:

Has there been any progress on this? For my application I'd very much like "ssh-like" operation, using the public key itself as identifier rather than requiring some kind of automated CA setup.

Being able to set a custom verification callback would be great, but just being able to cause a dummy callback that accepts any certificate to be used would go a long way. The validation could be done after the connection was established in this case. For some applications, that may even be the best approach, presenting any verification error via the application layer (e.g. HTTP) where they are closer to the problem domain and thus make more sense to the user.

----------
nosy: +sascha_silbe

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

From report at bugs.python.org  Fri Apr  1 15:25:10 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Apr 2016 19:25:10 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1459538710.64.0.00804684630735.issue26647@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I reviewed wpy3.patch.

I concur with Raymond, it's really nice to have a regular structure for the bytecode.

--

Serhiy proposed to *reduce* the size of bytecode by adding new specialized bytecode which include the argument. For example (LOAD_CONST, 0) => LOAD_CONST_0. I would like to hear his opinion on this change.
https://mail.python.org/pipermail/python-ideas/2016-February/038276.html

Data+code loaded by import is the top #1 memory consumer on basic scripts according to tracemalloc:
https://docs.python.org/dev/library/tracemalloc.html#examples

I don't know the ratio between data and code. But here we are only talking about the co_code fields of code objects. I guess that the file size of .pyc is a good estimation.

I don't think that the memory footprint of bytecode (co_code fields of code objects) really matters on computers (and smartphones?) of 2016.

*If* I have to choose between CPU performance and memory footprint, I choose the CPU!

--

> This does _not_ include having f_lasti be -1 instead of -2

IMHO it's ok to break the C API, but I would prefer to keep the backward compatibility for the Python API (replace any negative number with -1 for the Python API).

----------

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

From report at bugs.python.org  Fri Apr  1 15:26:04 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Apr 2016 19:26:04 +0000
Subject: [issue2943] Distutils should generate a better error message when the
 SDK is not installed
In-Reply-To: <1211455981.94.0.404413935613.issue2943@psf.upfronthosting.co.za>
Message-ID: <1459538764.73.0.697733138266.issue2943@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/issue2943>
_______________________________________

From report at bugs.python.org  Fri Apr  1 15:33:53 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Apr 2016 19:33:53 +0000
Subject: [issue26509] asyncio: spurious ConnectionAbortedError logged on
 Windows
In-Reply-To: <1457412256.22.0.929855467044.issue26509@psf.upfronthosting.co.za>
Message-ID: <1459539233.06.0.0509045577757.issue26509@psf.upfronthosting.co.za>


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


----------
title: spurious ConnectionAbortedError logged on Windows -> asyncio: spurious ConnectionAbortedError logged on Windows

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

From report at bugs.python.org  Fri Apr  1 15:43:02 2016
From: report at bugs.python.org (wysaard)
Date: Fri, 01 Apr 2016 19:43:02 +0000
Subject: [issue26673] Tkinter error when opening IDLE configuration menu
In-Reply-To: <1459351920.73.0.899924616631.issue26673@psf.upfronthosting.co.za>
Message-ID: <1459539782.86.0.972429726938.issue26673@psf.upfronthosting.co.za>


wysaard added the comment:

I just fixed this problem.

In my ~/.idlerc/ folder there was no `config-main.cfg` so I created it and used the settings found here: https://svn.python.org/projects/python/trunk/Mac/IDLE/config-main.def

After doing that everything worked fine again.

I'm not sure where this bug came from though, whether it's my package manager, or some bug in IDLE itself that created this problem; I also don't know if this is normal behavior for a missing config file; so I do n't know whether to close this or not, so I'll leave that to you.

----------

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

From report at bugs.python.org  Fri Apr  1 15:45:15 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Apr 2016 19:45:15 +0000
Subject: [issue26509] asyncio: spurious ConnectionAbortedError logged on
 Windows
In-Reply-To: <1457412256.22.0.929855467044.issue26509@psf.upfronthosting.co.za>
Message-ID: <20160401194505.62153.25265.F0729F36@psf.io>


Roundup Robot added the comment:

New changeset 68e694475483 by Victor Stinner in branch '3.5':
asyncio: Don't log ConnectionAbortedError
https://hg.python.org/cpython/rev/68e694475483

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

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

From report at bugs.python.org  Fri Apr  1 15:45:34 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Apr 2016 19:45:34 +0000
Subject: [issue26509] asyncio: spurious ConnectionAbortedError logged on
 Windows
In-Reply-To: <1457412256.22.0.929855467044.issue26509@psf.upfronthosting.co.za>
Message-ID: <1459539934.3.0.583999989434.issue26509@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Can someone please commit the patch?

Done.

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

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

From report at bugs.python.org  Fri Apr  1 15:47:31 2016
From: report at bugs.python.org (=?utf-8?b?SsSBbmlzIMWgbGFwacWGxaE=?=)
Date: Fri, 01 Apr 2016 19:47:31 +0000
Subject: [issue26606] logging.baseConfig is missing the encoding parameter
In-Reply-To: <1458598626.88.0.490041392552.issue26606@psf.upfronthosting.co.za>
Message-ID: <1459540051.67.0.836733968292.issue26606@psf.upfronthosting.co.za>


J?nis ?lapi?? added the comment:

Many examples in the internet only show the usage of the filename parameter of basicConfig() and almost no one shows how to use the stream. That's why I wanted to use the filename parameter. But now I tested other options and they work for me. My case may be very specific as I need to log words in very different languages including not only those having the Latin script but also cyrillic - Russian, Greek etc.

Regarding the codecs module and open() - yes, I made a mistake. There is no need for that in Python3.

About sys.stdout. I understand the redirection in the following way (also shown in the Dive Into Python book):
normal_stdout = sys.stdout
sys.stdout = open(mylogfile, 'w', encoding='utf-8')
logging.basicConfig(level=logging.INFO, stream=sys.stdout)

After that, all the STDOUT goes to mylogfile. In order to send the output to the terminal window again, sys.stdout must be set back to normal:
sys.stdout = normal_stdout

----------

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

From report at bugs.python.org  Fri Apr  1 15:48:50 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Apr 2016 19:48:50 +0000
Subject: [issue26295] Random failures when running test suite in parallel (-m
 test -j0) caused by test_regrtest
In-Reply-To: <1454663707.24.0.201658170139.issue26295@psf.upfronthosting.co.za>
Message-ID: <1459540130.14.0.62966962801.issue26295@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Finally, I fixed the issue differently: test_regrtest now creates a temporary directory and uses --testdir command line parameter.

Before, using --testdir didn't work because regrtest always added "test." prefix to module names (ex: test_os => test.test_os). It isn't the case anymore when --testdir is used.

Buildbots are green, so I close the issue.

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

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

From report at bugs.python.org  Fri Apr  1 15:49:23 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 01 Apr 2016 19:49:23 +0000
Subject: [issue26348] activate.fish sets VENV prompt incorrectly
In-Reply-To: <1455282539.52.0.733684318611.issue26348@psf.upfronthosting.co.za>
Message-ID: <1459540163.73.0.607407917235.issue26348@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

Implementing this patch has led to another issue being raised: #26664. Dan - would you care to take a look and comment? Thanks.

----------

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

From report at bugs.python.org  Fri Apr  1 15:51:02 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Apr 2016 19:51:02 +0000
Subject: [issue26668] Remove Lib/test/test_importlib/regrtest.py?
In-Reply-To: <1459300468.22.0.543956048142.issue26668@psf.upfronthosting.co.za>
Message-ID: <1459540262.79.0.180498016021.issue26668@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Do you mean that you are ok to remove this file in Python 3.6? The file is not used by test_importlib.

----------

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

From report at bugs.python.org  Fri Apr  1 15:52:30 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 01 Apr 2016 19:52:30 +0000
Subject: [issue26606] logging.baseConfig is missing the encoding parameter
In-Reply-To: <1458598626.88.0.490041392552.issue26606@psf.upfronthosting.co.za>
Message-ID: <1459540350.46.0.600753971611.issue26606@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

> and almost no one shows how to use the stream.

Because most examples out there don't care about Unicode, etc.

> I understand the redirection in the following way (also shown in the Dive Into Python book)

There's certainly no need to do that, and that would not be a normal way of using logging. The use of stream= should be clear from the documentation for basicConfig() parameters.

----------

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

From report at bugs.python.org  Fri Apr  1 16:39:29 2016
From: report at bugs.python.org (Ashley Anderson)
Date: Fri, 01 Apr 2016 20:39:29 +0000
Subject: [issue26688] unittest2 referenced in unittest.mock documentation
Message-ID: <1459543169.0.0.250942982333.issue26688@psf.upfronthosting.co.za>


New submission from Ashley Anderson:

I noticed a few references to `unittest2` in the documentation in the `unittest.mock` "getting started" section:

https://docs.python.org/3.6/library/unittest.mock-examples.html#patch-decorators

I am attaching a patch that just changes these occurrences from `unittest2` to `unittest`.

----------
assignee: docs at python
components: Documentation
files: unittest2.patch
keywords: patch
messages: 262767
nosy: aganders3, docs at python
priority: normal
severity: normal
status: open
title: unittest2 referenced in unittest.mock documentation
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42346/unittest2.patch

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

From report at bugs.python.org  Fri Apr  1 16:43:23 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Fri, 01 Apr 2016 20:43:23 +0000
Subject: [issue26488] hashlib command line interface
In-Reply-To: <1457214866.19.0.989950954277.issue26488@psf.upfronthosting.co.za>
Message-ID: <1459543403.97.0.284006288383.issue26488@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

Publishing another patch after SilentGhost and Victor CR. I also changed the block size to 256 KB. If someone can remove the dependency on issue 14156 (I don't think I have permissions).

----------
Added file: http://bugs.python.org/file42347/hashlib-script-mod-md5sum-style-4.patch

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

From report at bugs.python.org  Fri Apr  1 16:50:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 01 Apr 2016 20:50:58 +0000
Subject: [issue26687] Use Py_RETURN_NONE in sqlite3 module
In-Reply-To: <1459535830.63.0.539238949684.issue26687@psf.upfronthosting.co.za>
Message-ID: <1459543858.3.0.750122203269.issue26687@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This patch and more can be generated by ?occinelle [1] semantic patch.

    spatch --in-place --dir . --sp-file py_return_none_macro.cocci

But be aware that some maintainers consider such sort of changes a code churn.

[1] http://coccinelle.lip6.fr/

----------
nosy: +serhiy.storchaka
Added file: http://bugs.python.org/file42348/py_return_none_macro.cocci

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

From report at bugs.python.org  Fri Apr  1 16:51:05 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 01 Apr 2016 20:51:05 +0000
Subject: [issue26673] Tkinter error when opening IDLE configuration menu
In-Reply-To: <1459351920.73.0.899924616631.issue26673@psf.upfronthosting.co.za>
Message-ID: <1459543865.54.0.687283220998.issue26673@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I should have thought of .idlerc as being a possible problem.  The usual fix is to delete its contents.

For this tracker, exiting with a traceback is a behavior issue; a crash is something worse, a core dump or whatever the MAC equivalent is.

.idlerc should not have config-main.cfg unless you change one of the values in idlelib/config-main.def.  If you change anything, the redundant entries will be removed.  Similarly for the other .idlerc/*.cfg versus idlelib/*.def files.

So missing that file should not have been a problem.  But it might have been if idlelib/config-main.def is corrupt.  I suggest you check it.  However, it it were, I would expect IDLE startup to fail, but it did not.

Since .idlerc is common to all installed version of Python, and hence to all IDLEs, it is not touched by installation or removal of any particular version.

The file you copied is perhaps a decade old.  However, the only changes should be

[EditorWindow]
font= TkFixedFont
[General]
print-command-posix=lpr %%s
print-command-win=start /min notepad /p %%s
[Theme]
name2=
# name2 set in user config-main.cfg for themes added after 2015 Oct 1

The third is needed if you select the new IDLE Dark color theme.

In ConfigDialog, self.fontSize is a StringVar, so it would seem that the error was it being '' rather than something like '10'.  Since you have 'fixed' the problem, I don't anticipate being to verify what its value was or why.  Hence I will close this.  However, feel free to post additional relevant information.  (Interpret 'Not a bug' here as 'cause unknown' ;-).

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: crash -> behavior

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

From report at bugs.python.org  Fri Apr  1 17:02:50 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Apr 2016 21:02:50 +0000
Subject: [issue26668] Remove Lib/test/test_importlib/regrtest.py?
In-Reply-To: <1459300468.22.0.543956048142.issue26668@psf.upfronthosting.co.za>
Message-ID: <1459544570.49.0.709654480498.issue26668@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Yes, I'm fine with removing it once I/someone double-checks that all the tests in test.test_importlib.import_ are doing the right thing in regards to util.test_both(..., __import__=util.__import__).

----------

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

From report at bugs.python.org  Fri Apr  1 17:08:02 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Apr 2016 21:08:02 +0000
Subject: [issue26642] Replace stdout and stderr with simple standard printers
 at Python exit
In-Reply-To: <1458911597.09.0.705997743741.issue26642@psf.upfronthosting.co.za>
Message-ID: <1459544882.22.0.237659182074.issue26642@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Patch version 2:

* check if the stream was already "closed" (see below and comment in the patch)
* first replace stream and then close it and DECREF the object
* don't close stdin anymore


> 1. Is there a reason only name is closed, not dunder_name? (Josh's question, but I'm interesting too).

Fixed.

> 2. Is it worth to first replace standard streams with "standard printers", and then close original streams? This allows to log warnings from closing streams.

Fixed.

> 3. "standard printers" are used at startup and at shutdown. Can we reuse some code?

I looked at the code creating standard printer during Python startup: it's just a few lines and it doesn't handle the case when stdout/stderr is already open. I don't think that it's worth to reuse code.

Anyway, with my new patch, the code is much more complex to handle the case if stderr and/or __stderr__ is "closed" (is NULL, None, getting closed attribute raises an error, or closed attribute is false).

> 4. Daemons close standard streams and fileno(stdout) can return unrelevant value.

Fixed.

----------
Added file: http://bugs.python.org/file42349/replace_stdio-2.patch

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

From report at bugs.python.org  Fri Apr  1 17:09:21 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Apr 2016 21:09:21 +0000
Subject: [issue26668] Remove Lib/test/test_importlib/regrtest.py?
In-Reply-To: <1459300468.22.0.543956048142.issue26668@psf.upfronthosting.co.za>
Message-ID: <1459544961.23.0.657123428059.issue26668@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> once I/someone double-checks that all the tests in test.test_importlib.import_ are doing the right thing in regards to util.test_both(..., __import__=util.__import__).

Ah, I didn't understand that it was a question. I'm not interested to check that.

----------

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

From report at bugs.python.org  Fri Apr  1 17:12:57 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Apr 2016 21:12:57 +0000
Subject: [issue26642] Replace stdout and stderr with simple standard printers
 at Python exit
In-Reply-To: <1458911597.09.0.705997743741.issue26642@psf.upfronthosting.co.za>
Message-ID: <1459545177.27.0.877866503989.issue26642@psf.upfronthosting.co.za>


STINNER Victor added the comment:

+    if (!closed) {
+        PyObject *res = PyObject_CallMethod(file, "close", "");
+        PyErr_Clear();
+        Py_XDECREF(res);
+    }
+    if (!dunder_closed) {
+        PyObject *res = PyObject_CallMethod(dunder_file, "close", "");
+        PyErr_Clear();
+        Py_XDECREF(res);
+    }

Hum, since it's common to have sys.__stderr__ = sys.stderr, maybe it's worth to skip the second close if dunder_file == file?

----------

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

From report at bugs.python.org  Fri Apr  1 17:58:08 2016
From: report at bugs.python.org (Daniel Shaulov)
Date: Fri, 01 Apr 2016 21:58:08 +0000
Subject: [issue26646] Allow built-in module in package
In-Reply-To: <1459023628.39.0.77878937212.issue26646@psf.upfronthosting.co.za>
Message-ID: <1459547888.75.0.714915570448.issue26646@psf.upfronthosting.co.za>


Daniel Shaulov added the comment:

Hi Brett,

I don't think that the patch from that issue is relevant anymore.
I did take the test case that was proposed in that issue and I am attaching a fixed version here.

I did realize from the discussion that my patch probably doesn't work on Windows (I think the change itself is fine - It's just won't have the test module), I will try to get a working Windows environment and make the appropriate changes tomorrow.

Also, the other issue was also asking for built-in packages and not just built-in submodules. I already have a note about that in my original message.
Can we move forward as-is or do you want me to add support for built-in packages as well?

----------
Added file: http://bugs.python.org/file42350/test_builtin_submodule.py

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

From report at bugs.python.org  Fri Apr  1 18:10:27 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 01 Apr 2016 22:10:27 +0000
Subject: [issue26686] email.parser stops parsing headers too soon.
In-Reply-To: <1459532790.12.0.415003614976.issue26686@psf.upfronthosting.co.za>
Message-ID: <1459548627.72.0.506353856658.issue26686@psf.upfronthosting.co.za>


Martin Panter added the comment:

Also see Issue 24363, basically the same bug in the HTTP parser, which (ab?)uses the email package to do most of the work. In that case, according to my note the faulty header field ends with:

X-Frame-Options: SAMEORIGIN\r\n
Set-Cookie: mb-CookieP=; HttpOnly; \r\n
Secure\r\n
Set-Cookie: mb-CookieP=; HttpOnly; Secure\r\n
\r\n

But in this case, perhaps because of the implications of dropping the ?Secure? flag, people are asking that the faulty line be appended to the previous header field. IMO I don?t think that is super important though. An alternative would be to add it to the defect list, and then raise an exception or warning if any defects are detected.

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

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

From report at bugs.python.org  Fri Apr  1 18:14:54 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Apr 2016 22:14:54 +0000
Subject: [issue26646] Allow built-in module in package
In-Reply-To: <1459023628.39.0.77878937212.issue26646@psf.upfronthosting.co.za>
Message-ID: <1459548894.48.0.542126128086.issue26646@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Referring to the other issue was more about tying the two issues together than necessarily expecting the other patch to work.

As for supporting packages as well as submodules, I'm not sure. It seems a little odd not to support the idea, but then again if something is built-in then there really isn't a need to support the concept of a directory containing more modules. But then again since there is a difference in terms of how a module vs package looks it should probably be supported.

And if you do try and support it, there might be nothing more needed than to have the module be named pkg.__init__ and have some special handling to strip out the '__init__' part of the name and to set `__path__ = []` in importlib. Then importlib can simply try for `name` and `name.__init__` and then use that to figure out if the module should be considered a package or not.

This whole issue is unfortunately one of those things where it's uncommon enough to have to think about all edge cases and the overall impact on other users if the suggested changes are made and to not have a clear-cut answer.

----------

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

From report at bugs.python.org  Fri Apr  1 20:03:30 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Apr 2016 00:03:30 +0000
Subject: [issue26678] Incorrect linking to elements in datetime package
In-Reply-To: <1459445799.81.0.161788997927.issue26678@psf.upfronthosting.co.za>
Message-ID: <20160402000327.28271.12111.9679B7B4@psf.io>


Roundup Robot added the comment:

New changeset 30e077f886cc by Martin Panter in branch '3.5':
Issue #26678: Fix indexing of datetime.tzinfo and timezone classes
https://hg.python.org/cpython/rev/30e077f886cc

New changeset 854db1a2cd98 by Martin Panter in branch 'default':
Issue #26678: Merge datetime doc fixes from 3.5
https://hg.python.org/cpython/rev/854db1a2cd98

New changeset 4cad272cec82 by Martin Panter in branch '2.7':
Issue #26678: Fix datetime.tzinfo indexing and ?tzinfo? attribute links
https://hg.python.org/cpython/rev/4cad272cec82

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

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

From report at bugs.python.org  Fri Apr  1 20:24:15 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 02 Apr 2016 00:24:15 +0000
Subject: [issue26678] Incorrect linking to elements in datetime package
In-Reply-To: <1459445799.81.0.161788997927.issue26678@psf.upfronthosting.co.za>
Message-ID: <1459556655.96.0.309797999635.issue26678@psf.upfronthosting.co.za>


Martin Panter added the comment:

Can you link to other methods? E.g. try io.IOBase.close(), which is done the normal way as a method indented under its class, and nntplib.NNTP.quit(), which is listed separately from its class definition. 

Regarding CRLFs in ?configure?, all I can guess is some strange Mercurial user configuration. Maybe you can work around it by using the ?dos2unix? command, or rebuilding the script with ?autoreconf?.

----------
versions: +Python 2.7, Python 3.5

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

From report at bugs.python.org  Fri Apr  1 20:32:18 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 02 Apr 2016 00:32:18 +0000
Subject: [issue26488] hashlib command line interface
In-Reply-To: <1457214866.19.0.989950954277.issue26488@psf.upfronthosting.co.za>
Message-ID: <1459557138.63.0.678066384307.issue26488@psf.upfronthosting.co.za>


Martin Panter added the comment:

I left some replies to Rietveld comments (sending review emails seems buggy).

For a chunk size, don?t worry too much about it. I would say keep it large enough to limit time spent executing Python code and syscalls, keep it small to avoid wasting high speed cache memory, and keep it a power of two to work with OS and filesystem buffers.

----------
dependencies:  -argparse.FileType for '-' doesn't work for a mode of 'rb'

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

From report at bugs.python.org  Fri Apr  1 21:32:27 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Apr 2016 01:32:27 +0000
Subject: [issue26688] unittest2 referenced in unittest.mock documentation
In-Reply-To: <1459543169.0.0.250942982333.issue26688@psf.upfronthosting.co.za>
Message-ID: <20160402013223.9986.14540.43FCA12C@psf.io>


Roundup Robot added the comment:

New changeset 73279e4a1107 by Berker Peksag in branch '3.5':
Issue #26688: Fix module name in mock docs
https://hg.python.org/cpython/rev/73279e4a1107

New changeset 24efe844e598 by Berker Peksag in branch 'default':
Issue #26688: Fix module name in mock docs
https://hg.python.org/cpython/rev/24efe844e598

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

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

From report at bugs.python.org  Fri Apr  1 21:34:19 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 02 Apr 2016 01:34:19 +0000
Subject: [issue26688] unittest2 referenced in unittest.mock documentation
In-Reply-To: <1459543169.0.0.250942982333.issue26688@psf.upfronthosting.co.za>
Message-ID: <1459560859.41.0.43386437561.issue26688@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Good catch, thanks Ashley!

3.3 and 3.4 are in security-fix-only mode so we don't fix documentation issues in those branches.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior
versions:  -Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Apr  1 21:48:48 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Apr 2016 01:48:48 +0000
Subject: [issue26679] curses: Descripton of KEY_NPAGE and KEY_PPAGE inverted
In-Reply-To: <1459452822.7.0.402599297468.issue26679@psf.upfronthosting.co.za>
Message-ID: <20160402014844.9980.29226.7416B3E6@psf.io>


Roundup Robot added the comment:

New changeset f41d3321007f by Berker Peksag in branch '3.5':
Issue #26679: Fix description of KEY_PPAGE and KEY_NPAGE constants
https://hg.python.org/cpython/rev/f41d3321007f

New changeset 23d986228c6b by Berker Peksag in branch 'default':
Issue #26679: Fix description of KEY_PPAGE and KEY_NPAGE constants
https://hg.python.org/cpython/rev/23d986228c6b

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

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

From report at bugs.python.org  Fri Apr  1 21:50:38 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 02 Apr 2016 01:50:38 +0000
Subject: [issue26679] curses: Descripton of KEY_NPAGE and KEY_PPAGE inverted
In-Reply-To: <1459452822.7.0.402599297468.issue26679@psf.upfronthosting.co.za>
Message-ID: <1459561838.66.0.943453023172.issue26679@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks, Robert and SilentGhost.

I verified the patch with the following script:

import curses


def main(stdscr):
    while True:
        c = stdscr.getch()
        if c == curses.KEY_PPAGE:
            stdscr.addstr('Page Up')
        elif c == curses.KEY_NPAGE:
            stdscr.addstr('Page Down')
        else:
            stdscr.addstr('Another key')

curses.wrapper(main)

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Apr  1 22:00:48 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 02 Apr 2016 02:00:48 +0000
Subject: [issue21069] test_fileno of test_urllibnet intermittently fails
In-Reply-To: <1395821437.54.0.612861702522.issue21069@psf.upfronthosting.co.za>
Message-ID: <1459562448.21.0.506793557956.issue21069@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a patch implementing my ideas. Let me know what you think of the ideas and/or the patch :)

If people think this change is too much for 3.5, I could try making a more minimal patch that calls something like socket.getpeername() rather than read(). That should also avoid the non-blocking problem.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file42351/rewrite-fileno.patch

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

From report at bugs.python.org  Fri Apr  1 23:59:55 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 02 Apr 2016 03:59:55 +0000
Subject: [issue26657] Directory traversal with http.server and
 SimpleHTTPServer on windows
In-Reply-To: <1459179015.77.0.509336394494.issue26657@psf.upfronthosting.co.za>
Message-ID: <1459569595.75.0.451230687393.issue26657@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thomas: My check for os.path.devnull was just a half-hearted attempt to check for special device names like NUL on Windows. It is far from foolproof, and would fail my CON.fusion test that I mentioned above. Anyway, to address this specific bug it would be better to keep the changes to a minimum and not add any new APIs.

One slight concern I have with Philipp?s patch is the new os_path parameter. I am a bit squeamish about adding parameters that are just to help testing. Perhaps it is enough to just rely on testing this on Windows, or to monkey-patch os.path = ntpath in the test suite? What do others think?

I am posting a modified version (v3) of Philipp?s patch. This version monkey-patches os.path in the tests and avoids the os_path parameter. It is also stricter, by ignoring any path component that does not appear to be a simple file or directory name.

This version will change how some questionable URLs are handled, but I expect that all of these URLs won?t have genuine use cases. Let me know if you think it is okay or not.

----------
stage:  -> patch review
Added file: http://bugs.python.org/file42352/fix-path-traversal-26657.v3.patch

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

From report at bugs.python.org  Sat Apr  2 00:07:02 2016
From: report at bugs.python.org (Demur Rumed)
Date: Sat, 02 Apr 2016 04:07:02 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1459570022.15.0.864994683455.issue26647@psf.upfronthosting.co.za>


Demur Rumed added the comment:

Got f_lasti working as -1. Applied PEP7. Unrelated: fixed a misnamed variable in test_grammar because it ran into a peephole bug (const -> jump_if_false erase didn't work when EXTENDED_ARGs were involved). dis has argval/arg set to None instead of the unused argument value

Things are seeming more brittle with f_lasti as -1. But maybe it's all in my head

----------
Added file: http://bugs.python.org/file42353/wpy4.patch

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

From report at bugs.python.org  Sat Apr  2 01:45:19 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 02 Apr 2016 05:45:19 +0000
Subject: [issue5901] missing meta-info in documentation pdf
In-Reply-To: <1241246578.79.0.771794251259.issue5901@psf.upfronthosting.co.za>
Message-ID: <1459575919.82.0.443678822367.issue5901@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I get the following output when I try Python 3.5.1 docs:

$ pdfinfo using.pdf 
Title:          
Subject:        
Keywords:       
Author:         
Creator:        LaTeX with hyperref package
Producer:       pdfTeX-1.40.14
CreationDate:   Sat Apr  2 00:17:54 2016
ModDate:        Sat Apr  2 00:17:54 2016
Tagged:         no
Pages:          69
Encrypted:      no
Page size:      595.276 x 841.89 pts (A4)
File size:      368343 bytes
Optimized:      no
PDF version:    1.5

----------
nosy: +berker.peksag
stage:  -> needs patch
type: resource usage -> behavior
versions: +Python 3.5, Python 3.6 -Python 3.3

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

From report at bugs.python.org  Sat Apr  2 02:17:34 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 02 Apr 2016 06:17:34 +0000
Subject: [issue13952] mimetypes doesn't recognize .csv
In-Reply-To: <1328550236.31.0.476108753678.issue13952@psf.upfronthosting.co.za>
Message-ID: <1459577854.36.0.885484685683.issue13952@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I will commit issue13952.patch this weekend to 2.7, 3.5 and default.

----------
nosy: +berker.peksag
stage: needs patch -> patch review
versions:  -Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Apr  2 02:26:18 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 02 Apr 2016 06:26:18 +0000
Subject: [issue23371] mimetypes initialization fails on Windows because of
 TypeError
In-Reply-To: <1422806320.68.0.990065034592.issue23371@psf.upfronthosting.co.za>
Message-ID: <1459578378.17.0.262458955439.issue23371@psf.upfronthosting.co.za>


Berker Peksag added the comment:

This is a duplicate of issue 22028 (fixed in 2.7 in 7c4c4e43c452).

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Python 3.4.1 Installer ended prematurely (Windows msi)

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

From report at bugs.python.org  Sat Apr  2 03:53:14 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 02 Apr 2016 07:53:14 +0000
Subject: [issue21718] sqlite3 cursor.description seems to rely on incomplete
 statement parsing for detection
In-Reply-To: <1402492269.75.0.610341668437.issue21718@psf.upfronthosting.co.za>
Message-ID: <1459583594.19.0.306678280214.issue21718@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I adapted the reproducer in msg220263 and added more tests.

----------
nosy: +berker.peksag
stage: test needed -> patch review
versions:  -Python 3.4
Added file: http://bugs.python.org/file42354/issue21718_tests.diff

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

From report at bugs.python.org  Sat Apr  2 04:39:24 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 02 Apr 2016 08:39:24 +0000
Subject: [issue26488] hashlib command line interface
In-Reply-To: <1457214866.19.0.989950954277.issue26488@psf.upfronthosting.co.za>
Message-ID: <1459586364.82.0.179630404477.issue26488@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

Adding new patch after CR changes.

----------
Added file: http://bugs.python.org/file42355/hashlib-script-mod-md5sum-style-5.patch

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

From report at bugs.python.org  Sat Apr  2 06:07:46 2016
From: report at bugs.python.org (Thomas)
Date: Sat, 02 Apr 2016 10:07:46 +0000
Subject: [issue26657] Directory traversal with http.server and
 SimpleHTTPServer on windows
In-Reply-To: <1459179015.77.0.509336394494.issue26657@psf.upfronthosting.co.za>
Message-ID: <1459591666.15.0.984957199346.issue26657@psf.upfronthosting.co.za>


Thomas added the comment:

Looks ok to me security-wise. But I just noticed that it the trailing slash is inconsistent on Windows, e.g.:

translate_path('asdf/')
==
'C:\\Users\\User\\Desktop\\temp\\asdf/' <- this slash

because path += '/' is used instead of os.path.sep. But apparently nobody complained about this yet, so it probably is not an issue.

----------

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

From report at bugs.python.org  Sat Apr  2 07:16:19 2016
From: report at bugs.python.org (Andy Maier)
Date: Sat, 02 Apr 2016 11:16:19 +0000
Subject: [issue26678] Incorrect linking to elements in datetime package
In-Reply-To: <1459445799.81.0.161788997927.issue26678@psf.upfronthosting.co.za>
Message-ID: <1459595779.74.0.757769213297.issue26678@psf.upfronthosting.co.za>


Andy Maier added the comment:

Martin, I can now link to the two methods e.g. via :meth:`py:datetime.tzinfo.utcoffset`, and it resolves nicely.

See here (linking to Python 2): 
https://pywbem.readthedocs.org/en/latest/#pywbem.MinutesFromUTC

Don't know why it now works, probably user error I would say.

Your change is still appreciated, and it would be great if it could also go into Python 2.7 :-) Hope I'm not asking for too much.

On Python build: hg config problem sounds like a good path. Thanks!

----------

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

From report at bugs.python.org  Sat Apr  2 07:29:18 2016
From: report at bugs.python.org (Andy Maier)
Date: Sat, 02 Apr 2016 11:29:18 +0000
Subject: [issue26678] Incorrect linking to elements in datetime package
In-Reply-To: <1459445799.81.0.161788997927.issue26678@psf.upfronthosting.co.za>
Message-ID: <1459596558.34.0.193481848571.issue26678@psf.upfronthosting.co.za>


Andy Maier added the comment:

Martin,
I just noticed that your fix must already be active. My link to tzinfo now lands on the long description. So maybe it was not a user error of mine that resolved the problem with the two methods (I was pretty sure I had tried the same syntax I use now), but whatever did the trick in your change.

Anyway, thanks much for this quick turnaround!!

Andy

----------

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

From report at bugs.python.org  Sat Apr  2 10:34:40 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 02 Apr 2016 14:34:40 +0000
Subject: [issue17436] hashlib: add a method to hash the content of a file
In-Reply-To: <1363428672.22.0.18562351596.issue17436@psf.upfronthosting.co.za>
Message-ID: <1459607680.4.0.833769980479.issue17436@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

> * hashobj.readfile(filename: str)
> * hashobj.readfileobj(file) where file is an object with a read() method which returns bytes strings

I changed the API to the one Victor suggested.

> For readfile() it might make more sense to implement it directly in C and let OpenSSL's BIO layer handle IO internally. It's more efficient and you can release the GIL around the whole operation.

The readfile method use the openSSL BIO and releases the GIL around the all operation.

> I suggest to look at copyfile() and copyfileobj() functions of the shutil module. For example, copyfileobj() has an optional parameter for the buffer size. You should probably uses that to avoid complex heuristic to guess the optimal buffer size.

Added a block_size optional argument to the readfileobj().

> In readfile(), you know that it's a regular file which exists on the file system. So you can directly uses _Py_fstat() to get st_blksize

Currently using constant block size in readfile(). From the discussion in issue 26488 I am not sure if this should be changed.

----------
Added file: http://bugs.python.org/file42356/17436-2.patch

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

From report at bugs.python.org  Sat Apr  2 11:15:02 2016
From: report at bugs.python.org (wysaard)
Date: Sat, 02 Apr 2016 15:15:02 +0000
Subject: [issue26673] Tkinter error when opening IDLE configuration menu
In-Reply-To: <1459351920.73.0.899924616631.issue26673@psf.upfronthosting.co.za>
Message-ID: <1459610102.85.0.588874001285.issue26673@psf.upfronthosting.co.za>


wysaard added the comment:

For some reason the freshly downloaded files have this problem too. If I remove my config-main.def and let my package manager get a new one it breaks again. I don't really know the implications of this; is this just a problem with my particular setup or does this mean that maybe the file in the package is invalid?

----------

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

From report at bugs.python.org  Sat Apr  2 11:51:21 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 02 Apr 2016 15:51:21 +0000
Subject: [issue26657] Directory traversal with http.server and
 SimpleHTTPServer on windows
In-Reply-To: <1459179015.77.0.509336394494.issue26657@psf.upfronthosting.co.za>
Message-ID: <1459612281.27.0.719457291565.issue26657@psf.upfronthosting.co.za>


Steve Dower added the comment:

Windows-only tests are fine, and certainly better than adding a new parameter just for testing.

Forward slashes are valid path segment separators on Windows 99% of the time, so that'll be why nobody has complained. Personally I prefer consistency, but not strongly enough to force a change here.

----------

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

From report at bugs.python.org  Sat Apr  2 12:40:21 2016
From: report at bugs.python.org (Thomas Caswell)
Date: Sat, 02 Apr 2016 16:40:21 +0000
Subject: [issue22757] TclStackFree: incorrect freePtr. Call out of sequence?
In-Reply-To: <1414552754.88.0.540025463882.issue22757@psf.upfronthosting.co.za>
Message-ID: <1459615221.98.0.537567579356.issue22757@psf.upfronthosting.co.za>


Thomas Caswell added the comment:

I do not think this got reported to mpl, is a year and a half old, and has no example, probably can be closed.

----------
nosy: +tcaswell

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

From report at bugs.python.org  Sat Apr  2 17:02:50 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sat, 02 Apr 2016 21:02:50 +0000
Subject: [issue25987] collections.abc.Reversible
In-Reply-To: <1451685633.1.0.273350637631.issue25987@psf.upfronthosting.co.za>
Message-ID: <1459630970.14.0.64769805127.issue25987@psf.upfronthosting.co.za>


Ivan Levkivskyi added the comment:

I was not sure whether Andrew is still interested. I made a simple-minded patch following his proposal. I also added tests and changed docs accordingly. Note that I also changed the expected MRO for MutableSequence in one of the functools tests according to the new hierarchy (otherwise test_functools fails).

Please review.

PS: Some tests was skipped on my machine, here is the list:
    test_bz2 test_curses test_dbm_gnu test_dbm_ndbm test_devpoll
    test_idle test_kqueue test_lzma test_msilib test_ossaudiodev
    test_smtpnet test_socketserver test_ssl test_startfile test_tcl
    test_timeout test_tix test_tk test_ttk_guionly test_ttk_textonly
    test_urllib2net test_urllibnet test_winreg test_winsound
    test_xmlrpc_net test_zipfile64

----------
keywords: +patch
Added file: http://bugs.python.org/file42357/reversible.patch

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

From report at bugs.python.org  Sat Apr  2 18:31:56 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 02 Apr 2016 22:31:56 +0000
Subject: [issue1346874] httplib simply ignores CONTINUE
Message-ID: <1459636316.82.0.985610096901.issue1346874@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patrick, can you elaborate on the problem with Apache and renegotiation? How does the 100-continue request, or anticipating the 100 response, help? Perhaps Issue 25919 is relevant in this case, where we want the client to receive an error response before the request data is completely sent.

----------

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

From report at bugs.python.org  Sat Apr  2 18:50:20 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 02 Apr 2016 22:50:20 +0000
Subject: [issue26586] Simple enhancement to BaseHTTPRequestHandler
In-Reply-To: <1458273976.86.0.666454727881.issue26586@psf.upfronthosting.co.za>
Message-ID: <1459637420.05.0.832070189253.issue26586@psf.upfronthosting.co.za>


Martin Panter added the comment:

I propose to commit the ?Too many headers? handler as a bug fix, and the other changes to only 3.6. Currently when more than 100 header fields are sent, the connection is killed and the server logs an unhandled exception.

----------
stage: patch review -> commit review
versions: +Python 2.7, Python 3.5

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

From report at bugs.python.org  Sat Apr  2 19:03:16 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 02 Apr 2016 23:03:16 +0000
Subject: [issue26609] Wrong request target in test_httpservers.py
In-Reply-To: <1458636980.12.0.779581831419.issue26609@psf.upfronthosting.co.za>
Message-ID: <1459638196.8.0.949317820263.issue26609@psf.upfronthosting.co.za>


Martin Panter added the comment:

Perhaps tempdir_name could get the slash prefixed in setUp() rather than in every test. There is one case that creates index.html which could probably be changed to use self.tempdir, and then the rest could be renamed to say self.base_url.

Rejecting requests that do not start with a slash could be a compatibility problem. Do you think potential security benefits (i.e. having unexpected variations on the format of the URL) outweigh that?

Either way, it would be good to retain a test without a slash.

----------
stage:  -> patch review

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

From report at bugs.python.org  Sat Apr  2 19:29:15 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 02 Apr 2016 23:29:15 +0000
Subject: [issue26678] Incorrect linking to elements in datetime package
In-Reply-To: <1459445799.81.0.161788997927.issue26678@psf.upfronthosting.co.za>
Message-ID: <1459639755.38.0.234120226378.issue26678@psf.upfronthosting.co.za>


Martin Panter added the comment:

That?s good news. I did not expect it, but I seem to have fixed the problem anyway.

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

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

From report at bugs.python.org  Sat Apr  2 20:31:21 2016
From: report at bugs.python.org (Sylvain Corlay)
Date: Sun, 03 Apr 2016 00:31:21 +0000
Subject: [issue26689] Add `has_flag` method to `distutils.CCompiler`
Message-ID: <1459643481.74.0.720699620632.issue26689@psf.upfronthosting.co.za>


New submission from Sylvain Corlay:

I would be very useful to have a `has_flag` method in `distutils.CCompiler` similar to `has_function`, allowing to check if the compiler supports certain flags.

Cmake has a `CHECK_CXX_COMPILER_FLAG` macro for that purpose, which checks if a simple C++ file compiles with the said flag.

----------
components: Distutils
messages: 262805
nosy: dstufft, eric.araujo, sylvain.corlay
priority: normal
severity: normal
status: open
title: Add `has_flag` method to `distutils.CCompiler`
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/issue26689>
_______________________________________

From report at bugs.python.org  Sat Apr  2 20:36:14 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 03 Apr 2016 00:36:14 +0000
Subject: [issue26657] Directory traversal with http.server and
 SimpleHTTPServer on windows
In-Reply-To: <1459179015.77.0.509336394494.issue26657@psf.upfronthosting.co.za>
Message-ID: <1459643774.52.0.988518498503.issue26657@psf.upfronthosting.co.za>


Martin Panter added the comment:

Regarding the trailing slash: this is certainly inconsistent, but one call site of translate_path() appears to depend on this being a forward slash. There seems to be confusion about whether the output is an OS path or a URL. I think this is just more thing to look at in a hypothetical future overhaul of path and URL handling (e.g. see Zhang?s links above).

----------

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

From report at bugs.python.org  Sat Apr  2 21:04:08 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 03 Apr 2016 01:04:08 +0000
Subject: [issue19959] argparse.FileType does not expand tilde "~"
In-Reply-To: <1386844263.55.0.374493919931.issue19959@psf.upfronthosting.co.za>
Message-ID: <1459645448.25.0.918750018448.issue19959@psf.upfronthosting.co.za>


Martin Panter added the comment:

I?m not super familiar with argparse, but to get a Path or FilePath object, can?t you use that directly instead of argparse?s FileType class?

The proposal would conflict with escaping a literal tilde (~) in the shell. It would make it harder for the end user to specify a real file name that starts with a tilde.

----------
status: open -> closed

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

From report at bugs.python.org  Sat Apr  2 21:30:09 2016
From: report at bugs.python.org (Sylvain Corlay)
Date: Sun, 03 Apr 2016 01:30:09 +0000
Subject: [issue26689] Add `has_flag` method to `distutils.CCompiler`
In-Reply-To: <1459643481.74.0.720699620632.issue26689@psf.upfronthosting.co.za>
Message-ID: <1459647009.54.0.960952878138.issue26689@psf.upfronthosting.co.za>


Sylvain Corlay added the comment:

I attached a patch for ccompiler.py adding the new `has_flag` method.

----------
keywords: +patch
Added file: http://bugs.python.org/file42358/has_flag.diff

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

From report at bugs.python.org  Sat Apr  2 22:02:23 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Apr 2016 02:02:23 +0000
Subject: [issue26586] Simple enhancement to BaseHTTPRequestHandler
In-Reply-To: <1458273976.86.0.666454727881.issue26586@psf.upfronthosting.co.za>
Message-ID: <20160403020219.9086.28307.ECB4822B@psf.io>


Roundup Robot added the comment:

New changeset f5247195238f by Martin Panter in branch '3.5':
Issue #26586: Handle excessive header fields in http.server, by Xiang Zhang
https://hg.python.org/cpython/rev/f5247195238f

New changeset e8edddb4f74b by Martin Panter in branch 'default':
Issue #26586: Merge excessive HTTP header handling from 3.5
https://hg.python.org/cpython/rev/e8edddb4f74b

New changeset 1b696c744559 by Martin Panter in branch 'default':
Issue #26586: Simple enhancements to BaseHTTPRequestHandler by Xiang Zhang
https://hg.python.org/cpython/rev/1b696c744559

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

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

From report at bugs.python.org  Sat Apr  2 22:38:09 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Apr 2016 02:38:09 +0000
Subject: [issue25951] SSLSocket.sendall() does not return None on success like
 socket.sendall()
In-Reply-To: <1451054715.95.0.578529633079.issue25951@psf.upfronthosting.co.za>
Message-ID: <20160403023805.94584.43917.64FBE621@psf.io>


Roundup Robot added the comment:

New changeset 92947704321c by Martin Panter in branch 'default':
Issue #25951: Fix SSLSocket.sendall() to return None, by Aviv Palivoda
https://hg.python.org/cpython/rev/92947704321c

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

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

From report at bugs.python.org  Sat Apr  2 23:27:54 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 03 Apr 2016 03:27:54 +0000
Subject: [issue26586] Simple enhancement to BaseHTTPRequestHandler
In-Reply-To: <1458273976.86.0.666454727881.issue26586@psf.upfronthosting.co.za>
Message-ID: <1459654074.41.0.759640576748.issue26586@psf.upfronthosting.co.za>


Martin Panter added the comment:

I didn?t touch 2.7 because that doesn?t have the same header parsing code as Python 3.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
versions:  -Python 2.7

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

From report at bugs.python.org  Sat Apr  2 23:58:59 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 03 Apr 2016 03:58:59 +0000
Subject: [issue25951] SSLSocket.sendall() does not return None on success like
 socket.sendall()
In-Reply-To: <1451054715.95.0.578529633079.issue25951@psf.upfronthosting.co.za>
Message-ID: <1459655939.97.0.555989005466.issue25951@psf.upfronthosting.co.za>


Martin Panter added the comment:

I made some simple tweaks to avoid long lines.

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

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

From report at bugs.python.org  Sun Apr  3 00:21:04 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Apr 2016 04:21:04 +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: <20160403042101.49893.27200.9D8F107F@psf.io>


Roundup Robot added the comment:

New changeset b29edd0108ee by Martin Panter in branch '3.5':
Issue #23735: Add SIGWINCH handler for Readline 6.3+ support, by Eric Price
https://hg.python.org/cpython/rev/b29edd0108ee

New changeset 41c2f8742bfe by Martin Panter in branch 'default':
Issue #23735: Merge Readline resize handling from 3.5
https://hg.python.org/cpython/rev/41c2f8742bfe

New changeset 9f237e81cd15 by Martin Panter in branch '2.7':
Issue #23735: Add SIGWINCH handler for Readline 6.3+ support, by Eric Price
https://hg.python.org/cpython/rev/9f237e81cd15

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

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

From report at bugs.python.org  Sun Apr  3 00:40:49 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 03 Apr 2016 04:40:49 +0000
Subject: [issue26585] Use html.escape to replace _quote_html in http.server
In-Reply-To: <1458271086.94.0.0961534377342.issue26585@psf.upfronthosting.co.za>
Message-ID: <1459658449.59.0.490742888292.issue26585@psf.upfronthosting.co.za>


Martin Panter added the comment:

I left a couple notes on minor style nits (which I can fix when I commit this). But perhaps we should fix the business with tempdir_name and absolute URL paths (Issue 26609) first.

----------
dependencies: +Wrong request target in test_httpservers.py

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

From report at bugs.python.org  Sun Apr  3 02:11:01 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 03 Apr 2016 06:11:01 +0000
Subject: [issue26689] Add `has_flag` method to `distutils.CCompiler`
In-Reply-To: <1459643481.74.0.720699620632.issue26689@psf.upfronthosting.co.za>
Message-ID: <1459663861.65.0.442740725606.issue26689@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
stage:  -> patch review
versions:  -Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Apr  3 02:39:09 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Apr 2016 06:39:09 +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: <1459665549.23.0.270880613167.issue23735@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/10490/steps/compile/logs/warnings%20%282%29

/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/readline.c:939: warning: implicit declaration of function 'sigwinch_ohandler'

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

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

From report at bugs.python.org  Sun Apr  3 03:15:23 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 03 Apr 2016 07:15:23 +0000
Subject: [issue21069] test_fileno of test_urllibnet intermittently fails
In-Reply-To: <1395821437.54.0.612861702522.issue21069@psf.upfronthosting.co.za>
Message-ID: <1459667723.26.0.933607216486.issue21069@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I added a timeout because test_urllibnet fails with a timeout after 15 minutes on the ARM buildbot and other tests of the same file also use a timeout.

I tried but failed to reproduce the timeout.

I ran the test after my change and it passes so I considered that it was ok. I understand your rationale for timeout, non blocking socket and read() returning None.

Can we modify the test to use a selector to wait until the socket is ready and only read available bytes, rather than reading all data?

Using a local server would also avoid blocking too long (take less than 15 min).

----------

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

From report at bugs.python.org  Sun Apr  3 03:56:03 2016
From: report at bugs.python.org (Upendra Kumar)
Date: Sun, 03 Apr 2016 07:56:03 +0000
Subject: [issue23551] IDLE to provide menu link to PIP gui.
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1459670163.3.0.663055400644.issue23551@psf.upfronthosting.co.za>


Upendra Kumar added the comment:

I have one doubt about writing unittests for pip_gui. For writing the unittest what should I use as a test instance? For example, if we take particular pip package like : Flask

Now, if I have to test the 'get_data_show()' function in temp_pip_v3.py (using the assertXYZ functions), then I will use the output of 'pip show flask' as an example test case. But, it may be the case that Flask is not installed in others' machine. In this case the test would fail. Therefore, what should I use as a example test case?

----------

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

From report at bugs.python.org  Sun Apr  3 04:19:31 2016
From: report at bugs.python.org (Patrick J McNerthney)
Date: Sun, 03 Apr 2016 08:19:31 +0000
Subject: [issue1346874] httplib simply ignores CONTINUE
Message-ID: <1459671571.54.0.143414866831.issue1346874@psf.upfronthosting.co.za>


Patrick J McNerthney added the comment:

Martin,

My understanding of the intention of the "Expect: 100-continue" header would address being able to receive an error response that is determined solely from the http request headers sent. So I do think that that would be the proper way to address that other issue, and without having to worry about sending and receiving data at once.

However, what I am running into is a different issue caused by the same root cause of not properly handling "Expect: 100-continue" header in the client.

In my case, what is occurring is the URL being called is configured to require an SSL client certificate. Apache is only able to determine that the client certificate is required after the http request headers are sent. Once Apache has the headers and determines that the client certificate is required, the ssl connection is renegotiated. While performing this renegotiation, Apache holds the request data in progress in a "SSLRenegBuffer". If the data sent is larger then the SSLRenegBufferSize configuration, then Apache will fail the request as being to large.

With the current HttpsConnection, the sequence of events leading to the failure are:

1. HttpsConnection sends all the headers, including the Expect: 100-continue header, and sends all the 128K of data as fast as the socket allows.
2. Apache receives the request headers and looks at the request URL and determines that a client certificate is required, precipitating a ssl renegotiation.
3. Apache attempts to buffer the data received so far so that the ssl renegotiation can occur. However, the body of the request has already been sent and it is larger then SSLRenegBufferSize.
4. Apache fails the request as being to large.
5. HttpsConnection gets the error response about too large of a request.

I have created my own fork of httplib.py that does proper Expect: 100-continue handling, requesting in the following successful steps:

1. HttpsConnection sends all headers, including the Expect: 100-continue header. The Expect: 100-continue header was detected, so HttpsConnection does not send the body yet.
2. HttpsConnection waits for a response.
3. Apache httpd receives the headers and detects that the request url requires a client certificate.
4. The ssl connection is renegotiated using the client certificate.
5. Apache sends the response status of 100. This is the only header sent, in addition to a blank line.
6. HttpsConnection receives the response status 100, which means all is good to go.
7. HttpsConnection sends the body of the request.
8. Apache gets the request body, which now can be very, very large, because it does not have to be held in the SSLRenegBuffer.
9. Apache processes request and returns the response.
10. HttpsConnection receives the response and processes.

Note that if Apache detected some error detected with the headers, then the sequence would go like so:

1. HttpsConnection sends all headers, including the Expect: 100-continue header. The Expect: 100-continue header was detected, so HttpsConnection does not send the body yet.
2. HttpsConnection waits for a response.
3. Apache httpd receives the headers and detects some kind of error. Maybe the URL is not handled at all.
4. Apache sends the error response.
5. HttpsConnection receives the error response and uses that as the final response of the request. The body of the request is never sent at all.

One unexpected side effect of using the Expect: 100-continue header I found was that requests smaller then the SSLRenegBufferSize were handled by Apache almost 3 times faster then without the Expect: 100-continue header. I assume this is because Apache does have to mess around with all the extra overhead of staging the request in the SSLRenegBuffer, but can instead route the body of the request directly to the request handler.

----------

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

From report at bugs.python.org  Sun Apr  3 04:28:22 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Apr 2016 08:28:22 +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: <20160403082819.97869.42987.E2ED7464@psf.io>


Roundup Robot added the comment:

New changeset e3f375047edf by Martin Panter in branch '3.5':
Issue #23735: Avoid sighandler_t Gnu-ism
https://hg.python.org/cpython/rev/e3f375047edf

New changeset 0e576d094dc4 by Martin Panter in branch 'default':
Issue #23735: Merge sighandler_t fix from 3.5
https://hg.python.org/cpython/rev/0e576d094dc4

New changeset 596946c06a31 by Martin Panter in branch '2.7':
Issue #23735: Avoid sighandler_t Gnu-ism
https://hg.python.org/cpython/rev/596946c06a31

----------

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

From report at bugs.python.org  Sun Apr  3 06:04:33 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 03 Apr 2016 10:04:33 +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: <1459677873.72.0.798261465007.issue23735@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for pointing that out Serhiy. It turns out sighandler_t is non-standard. My latest tweak seems to have fixed things.

Also thankyou Eric for your persistence with this patch :)

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

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

From report at bugs.python.org  Sun Apr  3 06:19:55 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 03 Apr 2016 10:19:55 +0000
Subject: [issue26689] Add `has_flag` method to `distutils.CCompiler`
In-Reply-To: <1459643481.74.0.720699620632.issue26689@psf.upfronthosting.co.za>
Message-ID: <1459678795.22.0.691185089859.issue26689@psf.upfronthosting.co.za>


SilentGhost added the comment:

I've left a comment on Rietveld

----------
nosy: +SilentGhost

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

From report at bugs.python.org  Sun Apr  3 06:34:04 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 03 Apr 2016 10:34:04 +0000
Subject: [issue21069] test_fileno of test_urllibnet intermittently fails
In-Reply-To: <1395821437.54.0.612861702522.issue21069@psf.upfronthosting.co.za>
Message-ID: <1459679644.16.0.205684286602.issue21069@psf.upfronthosting.co.za>


Martin Panter added the comment:

Yes using select() would be another way to fix the immediate problem of read() returning None. In the long term I was hoping to use something like my patch to avoid the problems with reading the HTTP response (already discussed in this report) at the same time.

----------

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

From report at bugs.python.org  Sun Apr  3 06:35:01 2016
From: report at bugs.python.org (Samuel Colvin)
Date: Sun, 03 Apr 2016 10:35:01 +0000
Subject: [issue26479] Init documentation typo "may be return" > "may NOT be
 returned"
In-Reply-To: <1457097258.8.0.064409213234.issue26479@psf.upfronthosting.co.za>
Message-ID: <1459679701.69.0.400503142333.issue26479@psf.upfronthosting.co.za>


Samuel Colvin added the comment:

Sorry, I'm going mad, misread it.

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

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

From report at bugs.python.org  Sun Apr  3 07:29:33 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 03 Apr 2016 11:29:33 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1459682973.73.0.474097096493.issue26680@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I've been thinking about this, and I'm +1 for the change now.

These structural typing issues for numbers come up regularly
(see also msg257088), and the functions are so simple and
self-explanatory that API-complexity does not really increase.


In general, I understand the argument that Python has become
too complex in some areas -- recently I had to go back to
Python-2.7 in order to understand a certain detail about
.pyc files (in 2.7 it was immediately obvious).


But here I see on such problems.

----------

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

From report at bugs.python.org  Sun Apr  3 07:44:02 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Apr 2016 11:44:02 +0000
Subject: [issue26200] SETREF adds unnecessary work in some cases
In-Reply-To: <1453745024.51.0.674954872761.issue26200@psf.upfronthosting.co.za>
Message-ID: <1459683842.67.0.369281330261.issue26200@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Reraised this issue on Python-Dev: http://comments.gmane.org/gmane.comp.python.devel/156809 .

----------

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

From report at bugs.python.org  Sun Apr  3 07:59:59 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 03 Apr 2016 11:59:59 +0000
Subject: [issue25974] Fix statistics.py after the Decimal.as_integer_ratio()
 change
In-Reply-To: <1451393371.35.0.476117922354.issue25974@psf.upfronthosting.co.za>
Message-ID: <1459684799.2.0.48948944382.issue25974@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Ping. Just a reminder that it would be nice to get this into 3.6-alpha-1. :)

----------

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

From report at bugs.python.org  Sun Apr  3 08:04:18 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 03 Apr 2016 12:04:18 +0000
Subject: [issue1346874] httplib simply ignores CONTINUE
Message-ID: <1459685058.47.0.00808146089104.issue1346874@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thankyou, I think I understand your situation better now (though I don?t understand why Apache doesn?t renegotiate while the request body is being sent).

I would still argue that this is a new feature to be added rather than a bug though, and should only go into Python 3.6+. The original HTTP 1.1 specification (RFC 2068) did not even mention an ?Expect: 100-continue? header field, although it does mention the ?100 Continue? response. And any change will probably need new APIs and documentation.

Rather than parsing the headers for ?100-continue?, I wonder if it would be cleaner adding an API flag to add the header. Or perhaps a new method that explicitly waits for the 100 response.

----------

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

From report at bugs.python.org  Sun Apr  3 11:41:48 2016
From: report at bugs.python.org (Dimitry Andric)
Date: Sun, 03 Apr 2016 15:41:48 +0000
Subject: [issue10910] pyport.h FreeBSD/Mac OS X "fix" causes errors in C++
 compilation
In-Reply-To: <1295040100.28.0.0907494738582.issue10910@psf.upfronthosting.co.za>
Message-ID: <1459698108.75.0.74566251663.issue10910@psf.upfronthosting.co.za>


Dimitry Andric added the comment:

I am a FreeBSD committer, and I recently ran into this issue too, since I am working on an update of libc++ in the FreeBSD base system.  As part of this work, we attempt to recompile all ports with the proposed change (see [1]).  During such a recompile, we get many errors in ports that include pyport.h in C++ mode, similar to (see [2]):

In file included from scipy/interpolate/src/_interpolate.cpp:4:
In file included from scipy/interpolate/src/interpolate.h:3:
In file included from /usr/include/c++/v1/iostream:38:
In file included from /usr/include/c++/v1/ios:216:
/usr/include/c++/v1/__locale:468:15: error: C++ requires a type specifier for all declarations
    char_type toupper(char_type __c) const
              ^
/usr/local/include/python2.7/pyport.h:731:29: note: expanded from macro 'toupper'
#define toupper(c) towupper(btowc(c))
                            ^

I think Ronald's proposed workaround is fine, since messing with ctype macros is risky in C++ mode.  E.g. the libc++ <ctype.h> header explicitly undefines all ctype macros, and replaces them with inline functions.

Additionally, the original issue mentioned in changeset 32950 [3] was fixed in October 2007 for FreeBSD 8.x [4], and subsequently the fix was merged back to FreeBSD 6.x and 7.x [5].

I'm adding an additional diff that corrects the __FreeBSD_version number checks.  This will also be submitted to the FreeBSD ports bug tracker.

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208158
[2] http://package18.nyi.freebsd.org/data/headamd64PR208158-default/2016-03-22_18h30m05s/logs/errors/py27-scipy-0.16.1.log
[3] https://hg.python.org/cpython/rev/adfe7d39a049
[4] https://svnweb.freebsd.org/base?view=revision&revision=172619
[5] https://svnweb.freebsd.org/base?view=revision&revision=172929

----------
nosy: +dim
Added file: http://bugs.python.org/file42359/issue10910-fix-versionchecks-1.diff

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

From report at bugs.python.org  Sun Apr  3 11:44:41 2016
From: report at bugs.python.org (=?utf-8?b?SsSBbmlzIMWgbGFwacWGxaE=?=)
Date: Sun, 03 Apr 2016 15:44:41 +0000
Subject: [issue26606] logging.baseConfig is missing the encoding parameter
In-Reply-To: <1458598626.88.0.490041392552.issue26606@psf.upfronthosting.co.za>
Message-ID: <1459698281.56.0.617359937901.issue26606@psf.upfronthosting.co.za>


J?nis ?lapi?? added the comment:

> that's why I'm choosing not to increase the complexity of my code

I disagree about the classification of my proposal. This is not about increasing the complexity (changing algorithms, adding a new functionality and so on). It is just about getting the most out of the code with a minimum effort.

----------

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

From report at bugs.python.org  Sun Apr  3 16:12:33 2016
From: report at bugs.python.org (Jason Madden)
Date: Sun, 03 Apr 2016 20:12:33 +0000
Subject: [issue24291] wsgiref.handlers.SimpleHandler truncates large output
 blobs
In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za>
Message-ID: <1459714353.51.0.543504147245.issue24291@psf.upfronthosting.co.za>


Jason Madden added the comment:

gevent has another simple reproducer for this. I do believe it's not gevent's fault, the fault is in the standard library; SimpleHandler._write needs to loop until `sent += self.stdeout.write(data)` is `len(data)`.

I have written up more on this at https://github.com/gevent/gevent/issues/778#issuecomment-205046001 For convenience I'll reproduce the bulk of that comment here:

The user supplied a django application that produced a very large response that was getting truncated when using gevent under Python 3.4. (I believe gevent's non-blocking sockets are simply running into a different buffering behaviour, making it more likely to be hit under those conditions simply because they are faster).

This looks like a bug in the standard library's `wsgiref` implementation.

I tracked this down to a call to `socket.send(data)`. This method only sends whatever portion of the data it is possible to send at the time, and it returns the count of the data that was sent. The caller of `socket.send()` is responsible for looping to make sure the full `len` of the data is sent. This [is clearly documented](https://docs.python.org/3/library/socket.html#socket.socket.send). 

In this case, there is a call to `send` trying to send the full response, but only a portion of it is able to be immediately written. Here's a transcript of the first request (I modified gevent's `socket.send` method to print how much data is actually sent each time):

```
Django version 1.9.5, using settings 'gdc.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
SENDING 17
SENT 17 OF 17
SENDING 37
SENT 37 OF 37
SENDING 38
SENT 38 OF 38
SENDING 71
SENT 71 OF 71
SENDING 1757905
SENT 555444 OF 1757905
[03/Apr/2016 19:48:31] "GET / HTTP/1.1" 200 1757905
```

Note that there's no retry on the short send.

Here's the stack trace for that short send; we can clearly see that there is no retry loop in place:

```
  //3.4/lib/python3.4/wsgiref/handlers.py(138)run()
    136             self.setup_environ()
    137             self.result = application(self.environ, self.start_response)
--> 138             self.finish_response()
    139         except:
    140             try:

  //3.4/lib/python3.4/wsgiref/handlers.py(180)finish_response()
    178             if not self.result_is_file() or not self.sendfile():
    179                 for data in self.result:
--> 180                     self.write(data)
    181                 self.finish_content()
    182         finally:

  //3.4/lib/python3.4/wsgiref/handlers.py(279)write()
    277
    278         # XXX check Content-Length and truncate if too many bytes written?
--> 279         self._write(data)
    280         self._flush()
    281

  //3.4/lib/python3.4/wsgiref/handlers.py(453)_write()
    451
    452     def _write(self,data):
--> 453         self.stdout.write(data)
    454
    455     def _flush(self):

  //3.4/lib/python3.4/socket.py(398)write()
    396         self._checkWritable()
    397         try:
--> 398             return self._sock.send(b)
    399         except error as e:
    400             # XXX what about EINTR?

> //gevent/_socket3.py(384)send()
    382                 from IPython.core.debugger import Tracer; Tracer()() ## DEBUG ##
    383
--> 384             return count
```

`self.stdout` is an instance of `socket.SocketIO` (which is returned from `socket.makefile`). This is not documented on the web, but the [docstring also clearly documents](https://github.com/python/cpython/blob/3.4/Lib/socket.py#L389) that callers of `write` should loop to make sure all data gets sent.

----------
nosy: +jmadden
versions: +Python 3.4

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

From report at bugs.python.org  Sun Apr  3 16:24:21 2016
From: report at bugs.python.org (Jason Madden)
Date: Sun, 03 Apr 2016 20:24:21 +0000
Subject: [issue24291] wsgiref.handlers.SimpleHandler truncates large output
 blobs
In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za>
Message-ID: <1459715061.3.0.579318688238.issue24291@psf.upfronthosting.co.za>


Jason Madden added the comment:

Django uses a `wsgiref.simple_server` to serve requests, which in turn uses `socketserver.StreamRequestHandler` to implement its `WSGIRequestHandler`. That base class explicitly turns off buffering for writes (`wbufsize = 0` is the class default which gets passed to `socket.makefile`). So that explains how there's no `BufferedWriter` wrapped around the `SocketIO` instance.

----------

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

From report at bugs.python.org  Sun Apr  3 16:54:35 2016
From: report at bugs.python.org (Patrick J McNerthney)
Date: Sun, 03 Apr 2016 20:54:35 +0000
Subject: [issue1346874] httplib simply ignores CONTINUE
Message-ID: <1459716875.05.0.427261727725.issue1346874@psf.upfronthosting.co.za>


Patrick J McNerthney added the comment:

"(though I don?t understand why Apache doesn?t renegotiate while the request body is being sent)"

Apache does attempt to do this, but HttpsConnection is immediately sending the body of the request as fast as the socket will allow, which fills up the SSLRenegBuffer before the renegotiation can occur.

"Or perhaps a new method that explicitly waits for the 100 response."

That is likely a good idea. My httplib.py fork did change the behavior of the endheaders method to return a response object if there was an error returned in response to the "Expect: 100-continue".

----------

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

From report at bugs.python.org  Sun Apr  3 18:14:08 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 03 Apr 2016 22:14:08 +0000
Subject: [issue24291] wsgiref.handlers.SimpleHandler truncates large output
 blobs
In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za>
Message-ID: <1459721648.73.0.238343241384.issue24291@psf.upfronthosting.co.za>


Martin Panter added the comment:

Okay now I see the conflict. The use of WSGIRequestHandler with wbufsize = 0 was the missing key. I see two possible solutions:

1. Change SimpleHandler._write() to allow self.stdout to be a RawIOBase writer, and loop over stdout.write() until all the data is written. This seems to be what most people are suggesting here. But it requires that stdout.write() returns the number of bytes written, so could be a compatibility problem.

2. Document that the SimpleHandler(stdout=...) parameter should be a BufferedIOBase writer, and fix WSGIRequestHandler to pass in a BufferedWriter (by overriding the wbufsize attribute with -1 or io.DEFAULT_BUFFER_SIZE).

I am not super familiar with the wsgiref package, but the second option seems more preferable to me and more in line with my understanding of how it was intended to work.

----------
stage: test needed -> needs patch
versions: +Python 3.6 -Python 3.4

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

From report at bugs.python.org  Sun Apr  3 18:52:34 2016
From: report at bugs.python.org (Jason Madden)
Date: Sun, 03 Apr 2016 22:52:34 +0000
Subject: [issue24291] wsgiref.handlers.SimpleHandler truncates large output
 blobs
In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za>
Message-ID: <1459723954.54.0.857375518735.issue24291@psf.upfronthosting.co.za>


Jason Madden added the comment:

Is there an expected `self.stdout` implementation that doesn't return the number of bytes it writes? `sys.stdout` does, as does `io.RawIOBase`. It doesn't seem clear to me that practically speaking there's a compatibility problem with requiring that for `self.stdout`.

----------

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

From report at bugs.python.org  Sun Apr  3 19:01:08 2016
From: report at bugs.python.org (Jason Madden)
Date: Sun, 03 Apr 2016 23:01:08 +0000
Subject: [issue24291] wsgiref.handlers.SimpleHandler truncates large output
 blobs
In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za>
Message-ID: <1459724468.55.0.996654685775.issue24291@psf.upfronthosting.co.za>


Jason Madden added the comment:

`self.stdin` and `self.stderr` are documented to be `wsgi.input` and `wsgi.errors`, which are both described as "file-like" objects, meaning that the `write` method should return bytes written. It seems like the same could reasonably be said to be true for `self.stdout`, though it isn't strictly documented as such.

The WSGI spec says that each chunk the application yields should be written immediately, with no buffering (https://www.python.org/dev/peps/pep-3333/#buffering-and-streaming), so I don't think having the default output stream be buffered would be in compliance.

If there is a compatibility problem, writing the loop this way could bypass it (untested):

  def _write(self, data):
    written = self.stdout.write(data)
    while written is not None and written < len(data):
        written += self.stdout.write(data[written:])

----------

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

From report at bugs.python.org  Sun Apr  3 19:56:52 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 03 Apr 2016 23:56:52 +0000
Subject: [issue24291] wsgiref.handlers.SimpleHandler truncates large output
 blobs
In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za>
Message-ID: <1459727812.61.0.474159523345.issue24291@psf.upfronthosting.co.za>


Martin Panter added the comment:

My worry was that it is easy to make a write() method that does not return anything, but is still useful in most cases. Since BufferedIOBase.write() has to guarantee to write everything, it may not seem important to return a value. But we could explicitly check for None as you suggested.

In the BaseHandler class, each chunk yielded by the application is passed to BaseHandler.write(). But that method calls self._flush(), which should avoid any buffering problem. SimpleHandler._flush() implements this by calling self.stdout.flush().

----------

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

From report at bugs.python.org  Sun Apr  3 20:10:24 2016
From: report at bugs.python.org (Jason Madden)
Date: Mon, 04 Apr 2016 00:10:24 +0000
Subject: [issue24291] wsgiref.handlers.SimpleHandler truncates large output
 blobs
In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za>
Message-ID: <1459728624.11.0.886289938166.issue24291@psf.upfronthosting.co.za>


Jason Madden added the comment:

I'm sorry, I'm still not following the argument that `write` is likely to return nothing. `RawIOBase` and `BufferedIOBase` both document that `write` must return the number of written bytes; if you don't return that, you break anything that assumes you do, as documented (because both patterns for checking if you need to keep looping are both TypeErrors: `written = 0; written += None` and `None < len(data)`); and if you ignore the return value, you fail when using any `IOBase` object that *isn't* buffered (exactly this case).

But you are definitely right, explicitly checking for None can be done. It adds a trivial amount of overhead, but this isn't a production server. The only cost is code readability.

Good point about the explicit calls to `flush()`, I thought flush was a no-op in some streams, but that's only the case for streams where it doesn't already matter.

----------

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

From report at bugs.python.org  Sun Apr  3 21:44:49 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 04 Apr 2016 01:44:49 +0000
Subject: [issue26685] Raise errors from socket.close()
In-Reply-To: <1459509388.35.0.801044830009.issue26685@psf.upfronthosting.co.za>
Message-ID: <1459734289.77.0.132237258723.issue26685@psf.upfronthosting.co.za>


Martin Panter added the comment:

Victor suggested making these errors be reported by the finalize method (garbage collection). I started investigating this, but faced various test suite failures (test_io, test_curses), as well as many new unhandled exceptions printed out during the tests which do not actually trigger failures. Maybe this could become a worthwhile change, but it needs more investigation and wasn?t my original intention. Finalize-exception.patch is my patch so far.

There are many comments over the place that make me uneasy about this change, so I think it should be investigated separately. E.g. Modules/_io/iobase.c:

/* Silencing I/O errors is bad, but printing spurious tracebacks is
   equally as bad, and potentially more frequent (because of
   shutdown issues). */

Lib/_pyio.py:

# The try/except block is in case this is called at program
# exit time, when it's possible that globals have already been
# deleted, and then the close() call might fail.  Since
# there's nothing we can do about such failures and they annoy
# the end users, we suppress the traceback.

----------
Added file: http://bugs.python.org/file42360/finalize-exception.patch

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

From report at bugs.python.org  Sun Apr  3 22:03:37 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 04 Apr 2016 02:03:37 +0000
Subject: [issue26685] Raise errors from socket.close()
In-Reply-To: <1459509388.35.0.801044830009.issue26685@psf.upfronthosting.co.za>
Message-ID: <1459735417.26.0.902492899891.issue26685@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is socket.close.v2.patch which hopefully fixes the test for Windows (still untested by me though)

----------
Added file: http://bugs.python.org/file42361/socket.close.v2.patch

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

From report at bugs.python.org  Sun Apr  3 22:16:04 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 04 Apr 2016 02:16:04 +0000
Subject: [issue24911] Context manager of socket.socket is not documented
In-Reply-To: <1440189246.69.0.0632097129757.issue24911@psf.upfronthosting.co.za>
Message-ID: <1459736164.74.0.472084672536.issue24911@psf.upfronthosting.co.za>


Martin Panter added the comment:

FWIW I discovered that socket.close() or __exit__() does not actually raise exceptions for cases like EBADF, see Issue 26685.

----------

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

From report at bugs.python.org  Sun Apr  3 23:10:58 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 04 Apr 2016 03:10:58 +0000
Subject: [issue6953] readline documentation needs work
In-Reply-To: <1253456012.32.0.661240289209.issue6953@psf.upfronthosting.co.za>
Message-ID: <1459739458.05.0.27929542953.issue6953@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is v3 which adds ?. . . in the underlying library? for all the function and variable references.

----------
Added file: http://bugs.python.org/file42362/readline-doc.v3.patch

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

From report at bugs.python.org  Sun Apr  3 23:27:11 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 04 Apr 2016 03:27:11 +0000
Subject: [issue15112] argparse: nargs='*' positional argument doesn't accept
 any items if preceded by an option and another positional
In-Reply-To: <1340165747.87.0.563099760163.issue15112@psf.upfronthosting.co.za>
Message-ID: <1459740431.13.0.374957744273.issue15112@psf.upfronthosting.co.za>


Martin Panter added the comment:

Playing with Steven and Paul?s patches, they both seem to work well. Paul?s seems to have debug printing included, which should be removed. I confirmed both patches also seem to address the nargs="?" case (Issue 24223).

At the moment I have zero knowledge of how the argparse internals work. Are there any advantages of one patch over the other?

----------
stage:  -> patch review

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

From report at bugs.python.org  Mon Apr  4 00:29:58 2016
From: report at bugs.python.org (Sylvain Corlay)
Date: Mon, 04 Apr 2016 04:29:58 +0000
Subject: [issue26689] Add `has_flag` method to `distutils.CCompiler`
In-Reply-To: <1459643481.74.0.720699620632.issue26689@psf.upfronthosting.co.za>
Message-ID: <1459744198.1.0.720052319507.issue26689@psf.upfronthosting.co.za>


Sylvain Corlay added the comment:

New version of the patch using the context manager.

----------
Added file: http://bugs.python.org/file42363/has_flag.diff

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

From report at bugs.python.org  Mon Apr  4 02:01:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 04 Apr 2016 06:01:35 +0000
Subject: [issue26257] Eliminate buffer_tests.py
In-Reply-To: <1454323795.43.0.12298865479.issue26257@psf.upfronthosting.co.za>
Message-ID: <1459749695.94.0.800291194829.issue26257@psf.upfronthosting.co.za>


Martin Panter added the comment:

I see what you meant about making the diff smaller. However in your patch you also moved three extra methods into BaseTest: test_additional_(r)split() and test_strip().

I prefer to handle these three methods in a separate patch that deals with test_bytes.BytesBaseTest, which also has split() and strip() tests. So this third patch moves those three methods back to CommonTest.

----------
Added file: http://bugs.python.org/file42364/buffer_tests_3.patch

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

From report at bugs.python.org  Mon Apr  4 02:26:02 2016
From: report at bugs.python.org (Robert Cope)
Date: Mon, 04 Apr 2016 06:26:02 +0000
Subject: [issue13285] signal module ignores external signal changes
In-Reply-To: <1319801278.56.0.946220269602.issue13285@psf.upfronthosting.co.za>
Message-ID: <1459751162.55.0.549874068474.issue13285@psf.upfronthosting.co.za>


Changes by Robert Cope <rpcope1 at gmail.com>:


----------
nosy: +rpcope1

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

From report at bugs.python.org  Mon Apr  4 02:41:24 2016
From: report at bugs.python.org (Robert Cope)
Date: Mon, 04 Apr 2016 06:41:24 +0000
Subject: [issue23863] Fix EINTR Socket Module issues in 2.7
In-Reply-To: <1428115885.34.0.897753768137.issue23863@psf.upfronthosting.co.za>
Message-ID: <1459752084.27.0.781268719779.issue23863@psf.upfronthosting.co.za>


Changes by Robert Cope <rpcope1 at gmail.com>:


----------
nosy: +rpcope1

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

From report at bugs.python.org  Mon Apr  4 03:48:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Apr 2016 07:48:35 +0000
Subject: [issue26257] Eliminate buffer_tests.py
In-Reply-To: <1454323795.43.0.12298865479.issue26257@psf.upfronthosting.co.za>
Message-ID: <1459756115.07.0.634891372777.issue26257@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Unfortunately Mercurial can't handle moving file fragments. The history of these methods will be lost. That is why I prefer the patch with minimal moving.

Are there any disadvantages of having test_additional_(r)split() and test_strip() in BaseTest?

----------

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

From report at bugs.python.org  Mon Apr  4 04:02:20 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 04 Apr 2016 08:02:20 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1459756940.62.0.643621312041.issue26680@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> the functions are so simple and self-explanatory 
> that API-complexity does not really increase.

It increases complexity because it will show-up everywhere including places where it makes little sense.

One place is int objects where its meaning and purpose will seem arcane to most Python programmers.  For int objects, this is just total waste.

With the fractions module, the method is also unnecessary because integral fractions all have a denominator of 1.

With the decimal module, we were careful not to grow the API beyond what was in the spec or what was necessary to integrate it into Python (i.e. the usual magic methods).  I think that was a good decision and would like to keep it that way. 

In general, the need for this method is almost nil (it would be a very, very rare Python programmer who would ever need this, and those that might what it are perfectly capable of writing a short function to handle their own requirements).  In the OPs case, the motivation isn't inability to determine whether something is integral, it is more a desire for the test to be polymorphic with other types where the methods do not add any real value.  

The OPs notion of "absurd" behavior implies a rule that all float methods should be available for ints.  That would suggest the is_integer, hex, fromhex, and as_integer_ratio would all need to propagate to the other types as well.  I don't think we should start sliding down that slope.

Another thought is that future updates to the decimal spec could make conflicting choices about what Decimal.is_integral() would return for Decimal('Infinity').  There could be a case to be made for true, for false, for NaN, or for setting one or more of the signal flags or traps.  

I'm glad that the OP separated out the request for Decimal given that his actual use cases involve everything except Decimal.  The decimal class is intentionally not registered a Real (only as a Number) because it isn't interoperable with binary floats; hence, there has been no need to copy all the float methods into Decimal.

AFAICT, this comes down to whether to push a float method into other types where we otherwise wouldn't do it, just to save the OP from one-line function:

is_integral = lambda x:  isinstance(x, int) or isinstance(x, Fraction) and x.denominator == 1 or isinstance(x, float) and x.is_integer()

----------
nosy: +tim.peters

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

From report at bugs.python.org  Mon Apr  4 04:04:21 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 04 Apr 2016 08:04:21 +0000
Subject: [issue26257] Eliminate buffer_tests.py
In-Reply-To: <1454323795.43.0.12298865479.issue26257@psf.upfronthosting.co.za>
Message-ID: <1459757061.51.0.337969911839.issue26257@psf.upfronthosting.co.za>


Martin Panter added the comment:

Okay you convinced me to leave those methods in the same relative position as in your patch. I can sympathize with keeping the Mercurial history small. :)

The only disadvantage is a couple extra microseconds wasted doing redundant tests. I will try and work on factoring out some of those tests next.

----------

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

From report at bugs.python.org  Mon Apr  4 04:19:49 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 04 Apr 2016 08:19:49 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1459757989.04.0.569999958185.issue26680@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

FWIW, I think the reasoning in http://bugs.python.org/issue1093 applies here as well.  The need is insufficient to warrant inclusion in the numeric tower and propagation to types like int and Fraction.

----------

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

From report at bugs.python.org  Mon Apr  4 04:21:56 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Apr 2016 08:21:56 +0000
Subject: [issue26257] Eliminate buffer_tests.py
In-Reply-To: <1454323795.43.0.12298865479.issue26257@psf.upfronthosting.co.za>
Message-ID: <1459758116.8.0.998392014179.issue26257@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

And would be nice to backport these changes to 2.7. This will help backporting new future tests.

----------
assignee:  -> martin.panter
stage: patch review -> commit review

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

From report at bugs.python.org  Mon Apr  4 05:57:52 2016
From: report at bugs.python.org (Robert Smallshire)
Date: Mon, 04 Apr 2016 09:57:52 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1459763872.89.0.130321518283.issue26680@psf.upfronthosting.co.za>


Robert Smallshire added the comment:

To be clear, I'm not arguing that is_integer is in the same category as hex and fromhex; is_integer is a mathematical property of the number, whereas hex and from hex are representational. Nobody expects interoperability of string representations of the different number types.

Neither do I take issue with the general argument against enlarging the API. In fact, if float.is_integer did not exist, I would not be campaigning for it to be invented.

What I do take issue with is already having a method on float which makes sense for all Real numbers, but then not supporting it for those other Real types. This just gets in the way of programming generally in terms of *numbers* rather than concrete types, especially when the is_integer method is being advocated as the *right way* to do such a test. This is can lead to other problems as people unthinkingly convert other number types to floats, with loss of information, just to get access to this convenience method. 

I'm (really) surprised that structural typing and polymorphism over numbers carries so little weight ? a cursory look at StackOverflow* shows that there are already too many people being encouraged to answer the 'is integral' question with isinstance(x, int) when that is not what they mean or need.

As a precedent we already have int.numerator, int.denominator, int.real and int.imag which are presumably using Raymond's argument are also 'total waste', but the reality is that the presence of these attributes causes no impediment to learning and makes many tasks easier with fewer special cases. When working with rationals, I frequently rely on the fact that ints implement the Rational interface.  When working with complex numbers, I frequently rely on the fact that both int and float implement the Complex interface. For example. I have used use these attributes in the constructor for a fixed-point number type, and was thankful for their existence.

I'm also happy to set the Decimal aspect of my proposal to one side as Decimal is explicitly outside the numeric tower.

This isn't about me avoiding writing trivial one-line functions or "the OPs use case". I'm trying to help you make Python more predictable and easier to use.  I'm far from the first person to be surprised by this.

I'd be happy to trade adding is_integer to the numeric tower for a deprecation notice on float.is_integer - the outcome is the same - polymorphic number types with fewer special cases.

<http://stackoverflow.com/questions/17170226/is-integer-not-working>
<http://stackoverflow.com/questions/6239967/determining-whether-an-value-is-a-whole-number-in-python/6239987#6239987>
<http://stackoverflow.com/questions/33002747/try-except-float-but-not-integer/33002796#33002796>
<http://stackoverflow.com/a/22053804/107907>
<http://stackoverflow.com/questions/36209324/trouble-using-is-integer-in-python>

----------

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

From report at bugs.python.org  Mon Apr  4 06:01:26 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 04 Apr 2016 10:01:26 +0000
Subject: [issue26689] Add `has_flag` method to `distutils.CCompiler`
In-Reply-To: <1459643481.74.0.720699620632.issue26689@psf.upfronthosting.co.za>
Message-ID: <1459764086.01.0.572907761907.issue26689@psf.upfronthosting.co.za>


SilentGhost added the comment:

I understand that you're copying approach of has_function, but shouldn't you remove this temporary file at the end of the function? Perhaps using tempfile.NamedTemporaryFile would be a better solution (both in has_flag and has_function). Also import can be moved to the top level, since it's used in more than one method.

----------

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

From report at bugs.python.org  Mon Apr  4 06:10:01 2016
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 04 Apr 2016 10:10:01 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1459764601.91.0.551055540918.issue26680@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I agree that Robert's "absurdity" argument was unfortunate and could
be reversed: Many people would consider an (10).is_integer() method
absurd.

I'm also only moderately interested in OOP or classification in general, but  we *do* have a numeric tower modeled after Scheme,
so here goes:

scheme@(guile-user)> (integer? 487)
$1 = #t
scheme@(guile-user)> (integer? 1.2)
$2 = #f
scheme@(guile-user)> (integer? 1.0)
$3 = #t
scheme@(guile-user)> (integer? 1/7)
$4 = #f
scheme@(guile-user)> (integer? 100/10)
$5 = #t
scheme@(guile-user)> 


The ACL2 theorem prover has the same:

ACL2 !>(integerp 100)
T
ACL2 !>(integerp 100/10)
T
ACL2 !>(integerp 100/7)
NIL


For me, these functions are something fundamental. I'd prefer
them to be exposed in a functional manner like above, but we
do have the numeric tower.

----------

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

From report at bugs.python.org  Mon Apr  4 08:42:31 2016
From: report at bugs.python.org (Austin Bingham)
Date: Mon, 04 Apr 2016 12:42:31 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1459773751.93.0.367764634548.issue26680@psf.upfronthosting.co.za>


Changes by Austin Bingham <austin at sixty-north.com>:


----------
nosy: +Austin Bingham

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

From report at bugs.python.org  Mon Apr  4 11:11:52 2016
From: report at bugs.python.org (Robert Cope)
Date: Mon, 04 Apr 2016 15:11:52 +0000
Subject: [issue25942] subprocess.call SIGKILLs too liberally
In-Reply-To: <1451006108.23.0.113868196098.issue25942@psf.upfronthosting.co.za>
Message-ID: <1459782712.7.0.637772068055.issue25942@psf.upfronthosting.co.za>


Changes by Robert Cope <rpcope1 at gmail.com>:


----------
nosy: +rpcope1

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

From report at bugs.python.org  Mon Apr  4 12:35:30 2016
From: report at bugs.python.org (Sylvain Corlay)
Date: Mon, 04 Apr 2016 16:35:30 +0000
Subject: [issue26689] Add `has_flag` method to `distutils.CCompiler`
In-Reply-To: <1459643481.74.0.720699620632.issue26689@psf.upfronthosting.co.za>
Message-ID: <1459787730.54.0.435280625459.issue26689@psf.upfronthosting.co.za>


Sylvain Corlay added the comment:

@minrk submitted http://bugs.python.org/file40933/0001-cleanup-temporary-files-in-ccompiler.has_function.patch
doing what you describe for `has_function`. 

I don't know much about the process to contribute to cpython. I would be glad to open a "PR" incorporating Min's commits too.

----------

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

From report at bugs.python.org  Mon Apr  4 12:48:43 2016
From: report at bugs.python.org (Bob Alexander)
Date: Mon, 04 Apr 2016 16:48:43 +0000
Subject: [issue24505] shutil.which wrong result on Windows
In-Reply-To: <1435183779.2.0.13075721906.issue24505@psf.upfronthosting.co.za>
Message-ID: <1459788523.56.0.167107322103.issue24505@psf.upfronthosting.co.za>


Bob Alexander added the comment:

Since there seems to be ongoing work on the "which"
function, here are a few more thoughts on this function's
future:

  - The existing version does not prepend the current
    directory to the path if it is already in the path.
    If the current directory is in the path but is not
    the first element, it will not be the first directory
    searched. It seems that the desired behavior is to
    search the current directory first, so the current
    directory should *always* be prepended. The existing
    "which" function already has an optimization to only
    search each directory once, so it's not a problem if
    the current directory is unconditionally prepended
    and may end up in there twice. This change would
    actually be a "correction", since the doc says the
    current directory is prepended

  - The function should always return an absolute path,
    which is the behavior of the Unix(1) "which" command
    and, I think, is the typical expected behavior of a
    "which"-type request. The existing implementation
    returns a relative path in certain cases, such as if
    the file is found via a relative directory reference
    in the path. This change is not inconsistent with
    the doc, since the doc does not address it.

  - It would be nice if the extension added when the
    given command has no extension were lower case,
    instead of the upper case extension retrieved from
    the PATHEXT environment variable. Several other
    "which" implementations work that way (e.g.
    see Go's os/exec.LookPath function), producing
    a more aesthetically pleasing name, as well as
    being more consistent with naming practices of the
    last 20+ years. The shocking-looking upper case
    sxtensions remind me of VERY OLD DOS programs  :-)
    This presents no conflict with the doc, and does
    not affect "correctness" since Windows file names
    are case-independent.

    A previous commenter objected to adding lower case
    extensions, but consider:
      - The current version never returns the extension
        case of the actual file. It returns the extension
        of the command string passed to the function,
        if any, otherwise it adds the extension from the
        PATHEXT environment variable, either of which
        might not match the actual file.
      - Returning the actual extension of the found file
        might be nice, but would require additional I/O;
        added expense for little return. This is not
        done in the current version.
      - The PATHEXT variable that ships with Windows
        contains the allowable extensions in upper case,
        an old DOS artifact. Few executable files these
        days have uppercase extensions. Using a lower
        case extension when the function has to invent
        one is a "modernization".

  - It would be nice if the returned file path were
    normalized. Currently, sometimes an unnormalized
    path is returned with a leading ".\".

I did write an update to "which" with the above changes,
and also updated the unit tests with:
  - 2 new tests to catch the bug that is the subject of
    this issue.
  - some tests were updated for the small changes such
    as normalization and lower case added extensions.
A zip file is attached with my updates. I'm not an
official "contributor", but feel free incorporate the
contents in any way you deem appropriate. The files are:

shutil.py
    updated shutil module
shutil.py_3_5_1
    existing 3.5.1 shutil module -- basis for updates
test_shutil_for_current_w_added_tests.py
    unit tests for existing 3.5.1 version of shutil with
    new tests to catch this bug
test_shutil_for_new_version.py
    unit tests for attached updated version of shutil
test_shutil_3_5_1.py
    existing 3.5.1 unit tests -- basis for updates

Bob

----------
Added file: http://bugs.python.org/file42365/new_which_bug_files.zip

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

From report at bugs.python.org  Mon Apr  4 13:00:56 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 04 Apr 2016 17:00:56 +0000
Subject: [issue26689] Add `has_flag` method to `distutils.CCompiler`
In-Reply-To: <1459643481.74.0.720699620632.issue26689@psf.upfronthosting.co.za>
Message-ID: <1459789256.8.0.791360649692.issue26689@psf.upfronthosting.co.za>


SilentGhost added the comment:

I guess it would make sense to depend on issue25544 and implement the has_flag with minrk's patch in mind. I guess his patch didn't get a second look because it didn't apply cleanly.

In any case, for implementing has_flag using current best practice is what I'd recommend.

----------
dependencies: +cleanup temporary files in distutils.has_function

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

From report at bugs.python.org  Mon Apr  4 13:03:27 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 04 Apr 2016 17:03:27 +0000
Subject: [issue25544] cleanup temporary files in distutils.has_function
In-Reply-To: <1446560146.63.0.814875607484.issue25544@psf.upfronthosting.co.za>
Message-ID: <1459789407.78.0.697214489578.issue25544@psf.upfronthosting.co.za>


SilentGhost added the comment:

Hi Min RK, could you please update your patch so that it would cleanly apply to the tip of default branch. Also since you're re-writing a big chunk of that function, could I ask you to use with context manager for the temporary source file.

----------
nosy: +SilentGhost
stage:  -> needs patch
versions:  -Python 3.4

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

From report at bugs.python.org  Mon Apr  4 13:22:30 2016
From: report at bugs.python.org (Mahmoud Lababidi)
Date: Mon, 04 Apr 2016 17:22:30 +0000
Subject: [issue26623] JSON encode: more informative error
In-Reply-To: <1458744500.18.0.912653699585.issue26623@psf.upfronthosting.co.za>
Message-ID: <1459790550.62.0.10878772566.issue26623@psf.upfronthosting.co.za>


Mahmoud Lababidi added the comment:

Serhiy,

I've attached a patch without the Object representation. Choose whichever you feel is better.

----------
Added file: http://bugs.python.org/file42366/json_encode.patch

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

From report at bugs.python.org  Mon Apr  4 13:41:04 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 04 Apr 2016 17:41:04 +0000
Subject: [issue25987] collections.abc.Reversible
In-Reply-To: <1451685633.1.0.273350637631.issue25987@psf.upfronthosting.co.za>
Message-ID: <1459791664.36.0.634733923645.issue25987@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Looks good. I'll merge this in a sec.

----------

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

From report at bugs.python.org  Mon Apr  4 13:59:58 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Apr 2016 17:59:58 +0000
Subject: [issue25987] collections.abc.Reversible
In-Reply-To: <1451685633.1.0.273350637631.issue25987@psf.upfronthosting.co.za>
Message-ID: <20160404175955.9082.76215.C666ACFE@psf.io>


Roundup Robot added the comment:

New changeset 07f73360ea8e by Guido van Rossum in branch 'default':
Add collections.Reversible. Patch by Ivan Levkivskyi. Fixes issue #25987.
https://hg.python.org/cpython/rev/07f73360ea8e

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

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

From report at bugs.python.org  Mon Apr  4 14:00:23 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 04 Apr 2016 18:00:23 +0000
Subject: [issue25987] collections.abc.Reversible
In-Reply-To: <1451685633.1.0.273350637631.issue25987@psf.upfronthosting.co.za>
Message-ID: <1459792823.04.0.104208419301.issue25987@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Done. Thanks!

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

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

From report at bugs.python.org  Mon Apr  4 14:05:54 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 04 Apr 2016 18:05:54 +0000
Subject: [issue26391] typing: Specialized sub-classes of Generic never call
 __init__
In-Reply-To: <1455882742.53.0.118642694532.issue26391@psf.upfronthosting.co.za>
Message-ID: <1459793154.14.0.669554676255.issue26391@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

This is fixed upstream (https://github.com/python/typing/commit/8c6aaf30751fec28f1a7e467139ae23c9cc30c81). I'm keeping this open until I've merged typing.py into CPython 3.5 and 3.6.

----------

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

From report at bugs.python.org  Mon Apr  4 14:49:39 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 04 Apr 2016 18:49:39 +0000
Subject: [issue19944] Make importlib.find_spec load packages as needed
In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za>
Message-ID: <1459795779.52.0.852988234573.issue19944@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

pyclbr.py has this comment
       # XXX This will change once issue19944 lands.
above the line that was changed by the patch applied.  Am I correct in thinking that the comment is obsolete and should be removed?

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

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

From report at bugs.python.org  Mon Apr  4 15:10:10 2016
From: report at bugs.python.org (Sylvain Corlay)
Date: Mon, 04 Apr 2016 19:10:10 +0000
Subject: [issue26689] Add `has_flag` method to `distutils.CCompiler`
In-Reply-To: <1459643481.74.0.720699620632.issue26689@psf.upfronthosting.co.za>
Message-ID: <1459797010.33.0.453783817458.issue26689@psf.upfronthosting.co.za>


Sylvain Corlay added the comment:

A new version of the patch using `NamedTemporaryFile` instead a the regular fdopen.

----------
Added file: http://bugs.python.org/file42367/has_flag.diff

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

From report at bugs.python.org  Mon Apr  4 15:25:58 2016
From: report at bugs.python.org (mike bayer)
Date: Mon, 04 Apr 2016 19:25:58 +0000
Subject: [issue26690] PyUnicode_Decode breaks when Python / sqlite3 is built
 with sqlite 3.12.0
Message-ID: <1459797958.48.0.726816942134.issue26690@psf.upfronthosting.co.za>


New submission from mike bayer:

So I really don't know *where* the issue is in this one, because I don't know enough about the different bits.

Step 1:  Save this C program to demo.c:

#include <Python.h>

static PyObject *
unicode_thing(PyObject *self, PyObject *value)
{
    char *str;
    Py_ssize_t len;

    if (value == Py_None)
        Py_RETURN_NONE;

    if (PyString_AsStringAndSize(value, &str, &len))
        return NULL;

   return PyUnicode_Decode(str, len, "utf-8", "ignore");
}


static PyMethodDef UnicodeMethods[] = {
    {"unicode_thing",  unicode_thing, METH_O,
     "do a unicode thing."},
    {NULL, NULL, 0, NULL}        /* Sentinel */
};



PyMODINIT_FUNC
initdemo(void)
{
    (void) Py_InitModule("demo", UnicodeMethods);
}


Step 2:  Build with a setup.py:

from distutils.core import setup, Extension

module1 = Extension('demo',
                    sources = ['demo.c'])

setup (name = 'PackageName',
       version = '1.0',
       description = 'This is a demo package',
       ext_modules = [module1])


$ python setup.py build_ext

3. Run with a normal Python that is *not* built against SQLite 3.12.0:

$ python
Python 2.7.10 (default, Sep  8 2015, 17:20:17) 
[GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import demo
>>> demo.unicode_thing('sql')
u'sql'

4. Now build Python 2.7.11 *with* SQLite 3.12.0 in the -I / -L paths.  Run the same program *With* that Python:

$ /opt/Python-2.7.11-sqlite-3.12.0/bin/python
Python 2.7.11 (default, Apr  4 2016, 14:20:47) 
[GCC 5.3.1 20151207 (Red Hat 5.3.1-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import demo
>>> demo.unicode_thing('sql')
u's\x00q'

Somehow the presence of sqlite-3.12.0 in the build is breaking the Python interpreter.   I think.  I really don't know.   The bad news is, this is the code for SQLAlchemy's unicode processor, and as SQlite 3.12.0 starts getting put in distros, the world is going to break.  So this is kind of really hard to test, I don't understand it, and it's totally urgent.  Any insights would be appreciated!

----------
components: Extension Modules
messages: 262864
nosy: zzzeek
priority: normal
severity: normal
status: open
title: PyUnicode_Decode breaks when Python / sqlite3 is built with sqlite 3.12.0
versions: Python 2.7

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

From report at bugs.python.org  Mon Apr  4 15:38:05 2016
From: report at bugs.python.org (mike bayer)
Date: Mon, 04 Apr 2016 19:38:05 +0000
Subject: [issue26690] PyUnicode_Decode breaks when Python / sqlite3 is built
 with sqlite 3.12.0
In-Reply-To: <1459797958.48.0.726816942134.issue26690@psf.upfronthosting.co.za>
Message-ID: <1459798685.73.0.866661434758.issue26690@psf.upfronthosting.co.za>


mike bayer added the comment:

i realized this is probably with my build overall.  let me do some more testing and ill reopen if i can confirm this more closely.

----------
resolution:  -> works for me
status: open -> closed

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

From report at bugs.python.org  Mon Apr  4 15:43:34 2016
From: report at bugs.python.org (Eric Snow)
Date: Mon, 04 Apr 2016 19:43:34 +0000
Subject: [issue19944] Make importlib.find_spec load packages as needed
In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za>
Message-ID: <1459799014.34.0.682821704979.issue19944@psf.upfronthosting.co.za>


Eric Snow added the comment:

Yeah, I'm pretty sure that TODO is out of date.

----------

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

From report at bugs.python.org  Mon Apr  4 16:23:22 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 04 Apr 2016 20:23:22 +0000
Subject: [issue21048] Index 'as' in import and with statements
In-Reply-To: <1395638558.42.0.404654056681.issue21048@psf.upfronthosting.co.za>
Message-ID: <1459801402.06.0.417542327816.issue21048@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Test email to see if I can get tracker email at different address, now the google is dumping some tracker email.  Issue selected as it is closed and I am only nosy listed.

----------

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

From report at bugs.python.org  Mon Apr  4 16:51:44 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 04 Apr 2016 20:51:44 +0000
Subject: [issue12494] subprocess: check_output() doesn't close pipes on error
In-Reply-To: <1309817625.67.0.269796238759.issue12494@psf.upfronthosting.co.za>
Message-ID: <1459803104.65.0.131565776371.issue12494@psf.upfronthosting.co.za>


Martin Panter added the comment:

As I understand it, this change only made it to 3.3+

----------
nosy: +martin.panter
versions:  -Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Apr  4 16:53:53 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 04 Apr 2016 20:53:53 +0000
Subject: [issue21048] Index 'as' in import and with statements
In-Reply-To: <1395638558.42.0.404654056681.issue21048@psf.upfronthosting.co.za>
Message-ID: <1459803233.55.0.104685471571.issue21048@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Second try.

----------

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

From report at bugs.python.org  Mon Apr  4 16:59:10 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 04 Apr 2016 20:59:10 +0000
Subject: [issue25609] Add a ContextManager ABC and type
In-Reply-To: <1447355679.68.0.225089426373.issue25609@psf.upfronthosting.co.za>
Message-ID: <1459803550.5.0.534336458802.issue25609@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

A slight problem is that I'd really like to keep the source of typing.py identical in Python 3.5 and 3.6. So maybe the definition should be conditional on the presence of AbstractContextManager?

----------

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

From report at bugs.python.org  Mon Apr  4 17:03:23 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 04 Apr 2016 21:03:23 +0000
Subject: [issue25942] subprocess.call SIGKILLs too liberally
In-Reply-To: <1451006108.23.0.113868196098.issue25942@psf.upfronthosting.co.za>
Message-ID: <1459803803.36.0.564276369277.issue25942@psf.upfronthosting.co.za>


Martin Panter added the comment:

Even if we can?t agree on any behaviour change, I think it might be worth documenting how these functions behave on exceptions (interrupts) other than TimeoutExpired. Currently all I can find is ?If the timeout expires, the child process will be killed and waited for.? I think this could be expanded to also say what happens if the parent is interrupted by a signal such as KeyboardInterrupt:

* Current behaviour: Immediately kill child (i.e. timeout expiry is not special)

* Previous behaviour: Return without waiting for child, which will become a zombie

* Mike?s proposal: Wait indefinitely for child without killing it, which could defeat the purpose of the timeout, especially if the child ignores or does not receive the same signal as the parent

----------

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

From report at bugs.python.org  Mon Apr  4 17:34:26 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 04 Apr 2016 21:34:26 +0000
Subject: [issue25609] Add a ContextManager ABC and type
In-Reply-To: <1447355679.68.0.225089426373.issue25609@psf.upfronthosting.co.za>
Message-ID: <1459805666.95.0.721713752438.issue25609@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

(Everything else looks great BTW.)

----------

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

From report at bugs.python.org  Mon Apr  4 18:02:25 2016
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 04 Apr 2016 22:02:25 +0000
Subject: [issue25609] Add a ContextManager ABC and type
In-Reply-To: <1447355679.68.0.225089426373.issue25609@psf.upfronthosting.co.za>
Message-ID: <1459807345.64.0.888689304677.issue25609@psf.upfronthosting.co.za>


Brett Cannon added the comment:

When I have a chance I'll do up a new patch where the definition of typing.ContextManager is guarded, add a What's New entry, and commit it. My planned guard will be:

if hasattr(contextlib, 'AbstractContextManager'):
    class ContextManager(...): ...
    __all__.append('ContextManager')

----------

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

From report at bugs.python.org  Mon Apr  4 18:26:30 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 04 Apr 2016 22:26:30 +0000
Subject: [issue25609] Add a ContextManager ABC and type
In-Reply-To: <1459807345.64.0.888689304677.issue25609@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLEDT+BsaRMX-xjXWGX97T9-F_bBMPgn-6k6+YBtBh7Cw@mail.gmail.com>


Guido van Rossum added the comment:

I have some significant changes to typing.py (and test_typing.py)
upstream in https://github.com/python/typing/. We should coordinate
our changes to stdlib (test_)typing.py.

----------

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

From report at bugs.python.org  Mon Apr  4 18:28:28 2016
From: report at bugs.python.org (Bob Alexander)
Date: Mon, 04 Apr 2016 22:28:28 +0000
Subject: [issue24505] shutil.which wrong result on Windows
In-Reply-To: <1435183779.2.0.13075721906.issue24505@psf.upfronthosting.co.za>
Message-ID: <1459808908.83.0.862957425797.issue24505@psf.upfronthosting.co.za>


Bob Alexander added the comment:

Oops, clarification...

I just reread my kind of long previous post, and realized it wasn't very explicit that anything concerning file extensions or prepending the current directory to the PATH apply to Windows only; not Unix (of course).

The "returning absolute, normalized paths" suggestions are multi-platform

I only tested the modified code on Windows.

----------

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

From report at bugs.python.org  Mon Apr  4 18:50:17 2016
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 04 Apr 2016 22:50:17 +0000
Subject: [issue25609] Add a ContextManager ABC and type
In-Reply-To: <1447355679.68.0.225089426373.issue25609@psf.upfronthosting.co.za>
Message-ID: <1459810217.01.0.91965949284.issue25609@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Is there a tracking issue I can set as a dependency?

----------

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

From report at bugs.python.org  Mon Apr  4 18:57:17 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 04 Apr 2016 22:57:17 +0000
Subject: [issue25609] Add a ContextManager ABC and type
In-Reply-To: <1459810217.01.0.91965949284.issue25609@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJKS7tZ_VmxcDZ1NVqstpiF1n1eyyBrPF71Xqg8JUvVcnw@mail.gmail.com>


Guido van Rossum added the comment:

No, but feel free to create one and assign it to me -- I will take
care of the rest then.

----------

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

From report at bugs.python.org  Mon Apr  4 19:03:09 2016
From: report at bugs.python.org (Josh Lee)
Date: Mon, 04 Apr 2016 23:03:09 +0000
Subject: [issue24209] Allow IPv6 bind in http.server
In-Reply-To: <1431784485.93.0.0140060801451.issue24209@psf.upfronthosting.co.za>
Message-ID: <1459810989.39.0.285121292445.issue24209@psf.upfronthosting.co.za>


Changes by Josh Lee <jleedev at gmail.com>:


----------
nosy: +jleedev

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

From report at bugs.python.org  Mon Apr  4 19:04:12 2016
From: report at bugs.python.org (Josh Lee)
Date: Mon, 04 Apr 2016 23:04:12 +0000
Subject: [issue3213] "pydoc -p" should listen to [::] if IPv6 is supported
In-Reply-To: <1214525489.78.0.574038651579.issue3213@psf.upfronthosting.co.za>
Message-ID: <1459811052.82.0.923669546979.issue3213@psf.upfronthosting.co.za>


Changes by Josh Lee <jleedev at gmail.com>:


----------
nosy: +jleedev

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

From report at bugs.python.org  Mon Apr  4 19:05:02 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 04 Apr 2016 23:05:02 +0000
Subject: [issue26632] __all__ decorator
In-Reply-To: <1458786797.31.0.0749407715279.issue26632@psf.upfronthosting.co.za>
Message-ID: <1459811102.82.0.375286885882.issue26632@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Here's my implementation based on eryksun's idea:

def public(thing=None, **kws):
    mdict = (sys._getframe(1).f_globals
             if thing is None
             else sys.modules[thing.__module__].__dict__)
    dunder_all = mdict.setdefault('__all__', [])
    if thing is not None:
        dunder_all.append(thing.__name__)
    for key, value in kws.items():
        dunder_all.append(key)
        mdict[key] = value
    return thing

----------

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

From report at bugs.python.org  Mon Apr  4 19:28:08 2016
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 04 Apr 2016 23:28:08 +0000
Subject: [issue26691] Update the typing module to match what's in
 github.com/python/typing
Message-ID: <1459812488.48.0.790121011173.issue26691@psf.upfronthosting.co.za>


New submission from Brett Cannon:

The code in Lib/typing.py is outdated compared to what's at github.com/python/typing.

----------
assignee: gvanrossum
messages: 262879
nosy: brett.cannon, gvanrossum
priority: normal
severity: normal
status: open
title: Update the typing module to match what's in github.com/python/typing

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

From report at bugs.python.org  Mon Apr  4 19:28:23 2016
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 04 Apr 2016 23:28:23 +0000
Subject: [issue25609] Add a ContextManager ABC and type
In-Reply-To: <1447355679.68.0.225089426373.issue25609@psf.upfronthosting.co.za>
Message-ID: <1459812503.97.0.802423746329.issue25609@psf.upfronthosting.co.za>


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


----------
dependencies: +Update the typing module to match what's in github.com/python/typing

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

From report at bugs.python.org  Mon Apr  4 19:28:45 2016
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 04 Apr 2016 23:28:45 +0000
Subject: [issue25609] Add a ContextManager ABC and type
In-Reply-To: <1447355679.68.0.225089426373.issue25609@psf.upfronthosting.co.za>
Message-ID: <1459812525.04.0.274109055196.issue25609@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Tracker issue created and assigned.

----------

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

From report at bugs.python.org  Mon Apr  4 20:46:11 2016
From: report at bugs.python.org (Satrajit Ghosh)
Date: Tue, 05 Apr 2016 00:46:11 +0000
Subject: [issue26692] cgroups support in multiprocessing
Message-ID: <1459817171.82.0.158211239936.issue26692@psf.upfronthosting.co.za>


New submission from Satrajit Ghosh:

multiprocessing cpucount returns the number of cpus on the system as returned by /proc/cpuinfo. 

this is true even on machines where linux kernel cgroups is being used to restrict cpu usage for a given process. this results in significant thread swithcing on systems with many cores. 

some ideas have been implemented in the following repos to handle cgroups:

https://github.com/peo3/cgroup-utils
http://cpachecker.googlecode.com/svn-history/r12889/trunk/scripts/benchmark/runexecutor.py

it would be nice if multiprocessing was a little more intelligent and queried process characteristics.

----------
components: Library (Lib)
messages: 262881
nosy: Satrajit Ghosh
priority: normal
severity: normal
status: open
title: cgroups support in multiprocessing
type: behavior

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

From report at bugs.python.org  Mon Apr  4 20:50:55 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 05 Apr 2016 00:50:55 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1459817455.51.0.815252539686.issue26680@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

* For most users, this will just be noise (even the existing float method is rarely used).   It is unimportant enough that Python existed without it for a very long time and it is unimportant enough that it didn't arise during the lengthy process of creating the decimal module.  

* The numeric tower doesn't require that we take new methods and push them to every type whether or not it makes sense.  Most of the ABCs have only a subset of the methods in the concrete types.

* There are already simple workarounds using a try/except or a conditional expression.

-1 I really don't want more clutter added to all the numeric classes.  (Clutter being something rarely needed, easily implemented in other ways, something that looks weird or confusing in classes like int or Fraction, something that we have done without to 26 years, something not covered by the decimal spec, and something that isn't part of the floats API for either Java* or Smalltalk)

* http://www.tutorialspoint.com/java/lang/java_lang_float.htm

----------

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

From report at bugs.python.org  Mon Apr  4 21:23:41 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 05 Apr 2016 01:23:41 +0000
Subject: [issue3213] "pydoc -p" should listen to [::] if IPv6 is supported
In-Reply-To: <1214525489.78.0.574038651579.issue3213@psf.upfronthosting.co.za>
Message-ID: <1459819421.79.0.188144679859.issue3213@psf.upfronthosting.co.za>


Martin Panter added the comment:

I understand Windows XP isn?t so important these days. So maybe we just need to disable IPV6_V6ONLY. (Unless we want this for 2.7 maybe?)

----------
stage:  -> needs patch
versions: +Python 3.6 -Python 3.3

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

From report at bugs.python.org  Mon Apr  4 21:51:45 2016
From: report at bugs.python.org (skydoom)
Date: Tue, 05 Apr 2016 01:51:45 +0000
Subject: [issue26693] Exception exceptions.AttributeError '_shutdown' in
 <module 'threading' >
Message-ID: <1459821105.82.0.884891417565.issue26693@psf.upfronthosting.co.za>


New submission from skydoom:

I did a search and find the issue 1947, however it's set to "not a bug". In its last note, it's suggested a 'packaging/environment issue'. But since I can reliably reproduce the issue with the "official python package"(that installed by the system, such as I am not building the python from source), Also, the same issue does not occurred on python 2.6.2, but 3.4.3 and 3.5.1. Even though it seems the "AssertionError" message is non-harmful but it's still a bit annoying. I am wondering if you can take a look my issue?

Please compile the attached source codes to reproduce my issue. Note that it only occurred when we (explicitly or implicitly) import the 'threading' module. If we comment out that line, it works fine.

----------
components: Library (Lib)
files: test2.C
messages: 262884
nosy: skydoom
priority: normal
severity: normal
status: open
title: Exception exceptions.AttributeError '_shutdown' in <module 'threading' >
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file42368/test2.C

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

From report at bugs.python.org  Mon Apr  4 22:01:01 2016
From: report at bugs.python.org (skydoom)
Date: Tue, 05 Apr 2016 02:01:01 +0000
Subject: [issue26693] Exception exceptions.AttributeError '_shutdown' in
 <module 'threading' >
In-Reply-To: <1459821105.82.0.884891417565.issue26693@psf.upfronthosting.co.za>
Message-ID: <1459821661.46.0.528264948635.issue26693@psf.upfronthosting.co.za>


skydoom added the comment:

This is how I compile my code:
CFLAG is obtained from `python3.5m-config --includes`
LDFLAG is obtained from `"python-3.5m-config --ldflags`
g++ ${CFLAG} ${LDFLAG} test2.C 

I am running on Linux.

----------

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

From report at bugs.python.org  Mon Apr  4 22:28:37 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 05 Apr 2016 02:28:37 +0000
Subject: [issue26609] Wrong request target in test_httpservers.py
In-Reply-To: <1458636980.12.0.779581831419.issue26609@psf.upfronthosting.co.za>
Message-ID: <1459823317.84.0.0555599473782.issue26609@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Get the slash prefixed path in Setup() is a good idea. I change the patch. I retain self.tempdir_name so we can use it in a test for no leading slash. The case creating index.html is OK with self.tempdir_name since we have changed our working directory to basetempdir.

I didn't think about compatibility but I know it's important. So rejecting the invalid request-targets is not a good idea to me now.

----------
Added file: http://bugs.python.org/file42369/request_target_in_test_httpservers_v2.patch

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

From report at bugs.python.org  Mon Apr  4 22:39:13 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 05 Apr 2016 02:39:13 +0000
Subject: [issue25928] Add Decimal.as_integer_ratio()
In-Reply-To: <1450822705.24.0.946819992184.issue25928@psf.upfronthosting.co.za>
Message-ID: <1459823953.45.0.455946375074.issue25928@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I don't think a new public method should have been added.

Historically, we've been careful to not grow the API beyond what is in the spec or the dunder methods required to interface with standard Python.

The feature creep is at odds with the intended goals for the module that have been present since the outset.  As long as the spec remains unchanged, the API for this module should be treated as stable.

Another issue is that the API for the module is already so large that it impairs usability.  Please don't make it worse by adding new methods and inventing details that aren't in the spec.

----------
nosy: +tim.peters

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

From report at bugs.python.org  Mon Apr  4 23:32:44 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 05 Apr 2016 03:32:44 +0000
Subject: [issue26693] Exception exceptions.AttributeError '_shutdown' in
 <module 'threading' >
In-Reply-To: <1459821105.82.0.884891417565.issue26693@psf.upfronthosting.co.za>
Message-ID: <1459827164.95.0.722256985581.issue26693@psf.upfronthosting.co.za>


Zachary Ware added the comment:

After your `import threading` line, try `print(threading.__file__)`.  The path should be something like `/usr/local/lib/python3.4/threading.py`; if it's not (particularly if the current directory is part of the path), you've found the source of your problem, and you should move/rename the extra threading.py, as suggested by Brandon in msg144004.

----------
nosy: +zach.ware
resolution:  -> duplicate
status: open -> pending
superseder:  -> Exception exceptions.AttributeError '_shutdown' in <module 'threading'

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

From report at bugs.python.org  Tue Apr  5 00:41:47 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 05 Apr 2016 04:41:47 +0000
Subject: [issue26693] Exception exceptions.AttributeError '_shutdown' in
 <module 'threading' >
In-Reply-To: <1459821105.82.0.884891417565.issue26693@psf.upfronthosting.co.za>
Message-ID: <1459831307.95.0.146650096386.issue26693@psf.upfronthosting.co.za>


Martin Panter added the comment:

I am seeing an AssertionError, but no AttributeError. In your original post you did mention AssertionError, but that contradicts the report title. Please clarify what the problem is.

$ CFLAG="$(python3.5m-config --includes)"
$ LDFLAG="$(python3.5m-config --ldflags)"
$ g++ ${CFLAG} ${LDFLAG} test2.C
$ ./a.out
['/home/proj/python/lib', '/usr/lib/python35.zip', '/usr/lib/python3.5', '/usr/lib/python3.5/plat-linux', '/usr/lib/python3.5/lib-dynload', '/home/.local/lib/python3.5/site-packages', '/usr/lib/python3.5/site-packages']
Exception ignored in: <module 'threading' from '/usr/lib/python3.5/threading.py'>
Traceback (most recent call last):
  File "/usr/lib/python3.5/threading.py", line 1292, in _shutdown
    assert tlock.locked()
AssertionError:

----------
nosy: +martin.panter
status: pending -> open

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

From report at bugs.python.org  Tue Apr  5 01:15:10 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 05 Apr 2016 05:15:10 +0000
Subject: [issue6953] readline documentation needs work
In-Reply-To: <1253456012.32.0.661240289209.issue6953@psf.upfronthosting.co.za>
Message-ID: <1459833310.4.0.511417262923.issue6953@psf.upfronthosting.co.za>


Berker Peksag added the comment:

readline-doc.v3.patch looks good to me.

----------
stage: patch review -> commit review

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

From report at bugs.python.org  Tue Apr  5 01:22:37 2016
From: report at bugs.python.org (Min RK)
Date: Tue, 05 Apr 2016 05:22:37 +0000
Subject: [issue25544] cleanup temporary files in distutils.has_function
In-Reply-To: <1446560146.63.0.814875607484.issue25544@psf.upfronthosting.co.za>
Message-ID: <1459833757.68.0.189004323834.issue25544@psf.upfronthosting.co.za>


Min RK added the comment:

Absolutely, I'll try to do that tomorrow.

----------

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

From report at bugs.python.org  Tue Apr  5 02:18:39 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 05 Apr 2016 06:18:39 +0000
Subject: [issue26692] cgroups support in multiprocessing
In-Reply-To: <1459817171.82.0.158211239936.issue26692@psf.upfronthosting.co.za>
Message-ID: <1459837119.68.0.662139161715.issue26692@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +jnoller, sbt
versions: +Python 3.6

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

From report at bugs.python.org  Tue Apr  5 02:35:51 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 05 Apr 2016 06:35:51 +0000
Subject: [issue23551] IDLE to provide menu link to PIP gui.
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1459838151.43.0.442331683951.issue23551@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Looking at the last two prototypes, an 'Installed packages' page would not need install, only update and remove.  A minor issue.  The PyCharm page with Install appears to contain part of an alphabetical listing of all packages on PyPI  (there are 10000s I believe).  This suggests that there is a PyPI interface to get such.  This would mostly be useful if someone know at least the first few letter of a name -- sort of like identifier autocompletion.

I am downloading and looking at the v3.py from each of you.

----------

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

From report at bugs.python.org  Tue Apr  5 03:27:01 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 05 Apr 2016 07:27:01 +0000
Subject: [issue9694] argparse required arguments displayed under "optional
 arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1459841221.82.0.624229794419.issue9694@psf.upfronthosting.co.za>


Martin Panter added the comment:

Posting argparse_option.v2.patch, which is minimally complete version of Ryan?s patch. I have dropped all the nonessential code and documentation tweaks. I also added a What?s New entry. I?d like to know if people think this is the right direction to move in.

----------
versions:  -Python 2.7, Python 3.5
Added file: http://bugs.python.org/file42370/argparse_option.v2.patch

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

From report at bugs.python.org  Tue Apr  5 05:49:17 2016
From: report at bugs.python.org (Morb)
Date: Tue, 05 Apr 2016 09:49:17 +0000
Subject: [issue26682] Ttk Notebook tabs do not show with 1-2 char names
In-Reply-To: <1459470501.64.0.00235900367072.issue26682@psf.upfronthosting.co.za>
Message-ID: <1459849757.73.0.697234129191.issue26682@psf.upfronthosting.co.za>


Morb added the comment:

Hello, I'm the one who posted on stackoverflow.

I'm on Windows 7 Entreprise 64 bits (6.1, version 7601).
Here is my first line when I run python:
"Python 2.7.9 (default, Dec 10 2014, 12:28:03) [MSC v.1500 64 bit (AMD64)] on win32".

I think it's linked to the font and its size.
I tested some combinations:
  1 alphanumeric character, bugs (can only see 3 tabs on the 5)
  2 AN chars, bugs (last tabs almost hidden)
  3 AN chars, works
  1 space and 2 AN chars, bugs
  2 spaces and 2 AN chars, works
  2 spaces and 1 AN char, bugs (the last tab is almost hidden)
  3 spaces and 1 AN char, bugs
  4 spaces and 1 AN char, works
I tried the same with a different font (Courier, 12):
  1 alphanumeric character, bugs (the last tab is hidden)
  2 AN chars, works
  3 AN chars, works
  1 space and 2 AN chars, works
  2 spaces and 2 AN chars, works
  2 spaces and 1 AN char, works
  3 spaces and 1 AN char, works
  4 spaces and 1 AN char, works

The code I added for the font:
cfont = tkFont.Font(family="Courier", size=12)
s = ttk.Style()
s.configure('.', font=cfont)

----------
nosy: +Morb

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

From report at bugs.python.org  Tue Apr  5 05:51:17 2016
From: report at bugs.python.org (=?utf-8?q?Szymon_Kuli=C5=84ski?=)
Date: Tue, 05 Apr 2016 09:51:17 +0000
Subject: [issue26694] Disasembler fall with Key Error while disassemble
 obfuscated code.
Message-ID: <1459849877.74.0.679437404849.issue26694@psf.upfronthosting.co.za>


New submission from Szymon Kuli?ski:

Many obfuscators use simple technice for block disasemblation. Add broken instructions (for example unknown op codes) and use flow control (SETUP_EXCEPT or JUMP_FORWARD) to skip broken instructions. Interpreter work in right way skipping broken instruction or catch error and go to except instructions but disasembler iterate over all instructions and every where assume that code is correct and doing something like :

elif op in hasname:
                print '(' + co.co_names[oparg] + ')',


Which fails because variable oparg not in co_names table or refer to not existing name or const. Why dis lib not assume that code can be broken and try disassemble it as good as it can any way. 

   15 JUMP_IF_TRUE             3 (to 19)
   18 <WRONG INSTRUCTION>      (33333333)
   19 LOAD_NAME                1 (b)

Or if we rely on the assumption that if code disasseblation done with no problem this mean that code is good. We can add flag where we can disassemble unsteady code or even add other method like dis_unsafe or something like that. 

Include: obfuscated and unobfuscated pyc files for testing. 

Change proposition:

Cherry-pick code dis module from 3.5 python with some changes required to normal working. Working example included.

----------
components: Library (Lib)
files: example.zip
messages: 262895
nosy: Szymon.Kuli?ski
priority: normal
severity: normal
status: open
title: Disasembler fall with Key Error while disassemble obfuscated code.
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file42371/example.zip

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

From report at bugs.python.org  Tue Apr  5 05:55:23 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 05 Apr 2016 09:55:23 +0000
Subject: [issue26694] Disasembler fall with Key Error while disassemble
 obfuscated code.
In-Reply-To: <1459849877.74.0.679437404849.issue26694@psf.upfronthosting.co.za>
Message-ID: <1459850123.49.0.241896211099.issue26694@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +ncoghlan, yselivanov

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

From report at bugs.python.org  Tue Apr  5 06:10:41 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 05 Apr 2016 10:10:41 +0000
Subject: [issue25928] Add Decimal.as_integer_ratio()
In-Reply-To: <1450822705.24.0.946819992184.issue25928@psf.upfronthosting.co.za>
Message-ID: <1459851041.85.0.977674471671.issue25928@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Raymond, you added your support in msg257097.  I'm not very happy to spend my time implementing the feature and then rehashing everything after 3 months.

----------
nosy: +gvanrossum

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

From report at bugs.python.org  Tue Apr  5 06:27:56 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 05 Apr 2016 10:27:56 +0000
Subject: [issue26694] Disasembler fall with Key Error while disassemble
 obfuscated code.
In-Reply-To: <1459849877.74.0.679437404849.issue26694@psf.upfronthosting.co.za>
Message-ID: <1459852076.41.0.984393297647.issue26694@psf.upfronthosting.co.za>


Changes by Steven D'Aprano <steve+python at pearwood.info>:


----------
nosy: +steven.daprano

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

From report at bugs.python.org  Tue Apr  5 06:31:43 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Apr 2016 10:31:43 +0000
Subject: [issue6953] readline documentation needs work
In-Reply-To: <1253456012.32.0.661240289209.issue6953@psf.upfronthosting.co.za>
Message-ID: <20160405103135.94590.35197.540F69E8@psf.io>


Roundup Robot added the comment:

New changeset 6137c46cb8df by Martin Panter in branch '2.7':
Issue #6953: Rearrange and expand Readline module documentation
https://hg.python.org/cpython/rev/6137c46cb8df

New changeset b1acd6cf15b6 by Martin Panter in branch '3.5':
Issue #6953: Rearrange and expand Readline module documentation
https://hg.python.org/cpython/rev/b1acd6cf15b6

New changeset 856d50130154 by Martin Panter in branch 'default':
Issue #6953: Merge readline doc from 3.5
https://hg.python.org/cpython/rev/856d50130154

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

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

From report at bugs.python.org  Tue Apr  5 06:31:45 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Apr 2016 10:31:45 +0000
Subject: [issue10796] Improve doc for readline.set_completer_delims()
In-Reply-To: <1293714489.48.0.717157988045.issue10796@psf.upfronthosting.co.za>
Message-ID: <20160405103134.94590.49662.9C9A0E48@psf.io>


Roundup Robot added the comment:

New changeset 6137c46cb8df by Martin Panter in branch '2.7':
Issue #6953: Rearrange and expand Readline module documentation
https://hg.python.org/cpython/rev/6137c46cb8df

New changeset b1acd6cf15b6 by Martin Panter in branch '3.5':
Issue #6953: Rearrange and expand Readline module documentation
https://hg.python.org/cpython/rev/b1acd6cf15b6

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

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

From report at bugs.python.org  Tue Apr  5 06:37:03 2016
From: report at bugs.python.org (Thomas)
Date: Tue, 05 Apr 2016 10:37:03 +0000
Subject: [issue26628] Undefined behavior calling C functions with ctypes.Union
 arguments
In-Reply-To: <1458766336.13.0.0388960184699.issue26628@psf.upfronthosting.co.za>
Message-ID: <1459852623.88.0.759746135751.issue26628@psf.upfronthosting.co.za>


Changes by Thomas <bugs.python at zulan.net>:


Added file: http://bugs.python.org/file42372/libfoo.c

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

From report at bugs.python.org  Tue Apr  5 06:40:32 2016
From: report at bugs.python.org (Thomas)
Date: Tue, 05 Apr 2016 10:40:32 +0000
Subject: [issue26628] Undefined behavior calling C functions with ctypes.Union
 arguments
In-Reply-To: <1458766336.13.0.0388960184699.issue26628@psf.upfronthosting.co.za>
Message-ID: <1459852832.59.0.581977556033.issue26628@psf.upfronthosting.co.za>


Thomas added the comment:

Thanks Eryk for the additional explanation. I added a more elaborate example that doesn't abuse the standard c function that actually doesn't expect a union:

 % gcc -shared -fPIC libfoo.c -o libfoo.so -Wall
 % python pyfoo.py                             
*** stack smashing detected ***: python terminated
[1]    28463 segmentation fault (core dumped)  python pyfoo.py

The underling issue is exactly the same as previously described.

I still argue that ctypes should refuse to attempt such a call, and the documentation should be clarified, as long as libffi does not support unions.

----------
Added file: http://bugs.python.org/file42373/pyfoo.py

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

From report at bugs.python.org  Tue Apr  5 09:10:25 2016
From: report at bugs.python.org (Robert Smallshire)
Date: Tue, 05 Apr 2016 13:10:25 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1459861825.86.0.60666600361.issue26680@psf.upfronthosting.co.za>


Robert Smallshire added the comment:

Java makes no claim to have a numeric tower.  Amongst the dynamic languages I surveyed Matlab (isinteger), Javascript ES6 (isInteger), PHP (is_integer), R (is.integer), TCL (is entier), and as we have seen Scheme (integer?) all have methods for testing for integer values. Python has a numeric tower modelled on Scheme. In the Scheme documentation we find this:

"...the integer 5 may have several representations. Scheme's numerical operations treat number objects as abstract data, as independent of their representation as possible. Although an implementation of Scheme may use many different representations for numbers, this should not be apparent to a casual programmer writing simple programs."

This is what I'm advocating.

There isn't a single mathematical (as opposed to representational) method on int that isn't 'inherited' from the numeric tower.  There are exactly two methods on float which aren't inherited from the tower: is_integer and as_integer_ratio.  So I think it's would be a stretch to claim that "Most of the [numerical] ABCs have only a subset of the [numerical] methods in the [numerical] concrete types."

Rather than looking at the numeric tower as a construct which forces proliferation of methods, it would be better to look on it as a device to prevent bloat. I risk straying off topic here, but I want to give an example of why the numeric tower is important:

Were float to inherit from Rational, rather than Real (all finite floats are rationals with a power-of-two denominator, all Decimals are rationals with a power-of-ten denominator, so this is reasonable) then the as_integer_ratio method which was added to float and latterly Decimal (http://bugs.python.org/issue25928), arguably cluttering their interfaces, may have been deemed unnecessary. The numerator and denominator attributes present in Rational could have been used instead.  I think this is an example of lack of adherence to the numeric tower (at least in spirit in the case of Decimal) resulting in interface clutter or bloat.

The consequent control-flow complexity required handle numeric objects as 'abstract data' is surprising: statistics._exact_ratio is a good example of this. I count five API tests just to be able to treat numbers as, well, just numbers.

----------

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

From report at bugs.python.org  Tue Apr  5 09:49:18 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 05 Apr 2016 13:49:18 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459861825.86.0.60666600361.issue26680@psf.upfronthosting.co.za>
Message-ID: <20160405134907.GA5523@bytereef.org>


Stefan Krah added the comment:

On Tue, Apr 05, 2016 at 01:10:25PM +0000, Robert Smallshire wrote:
> Were float to inherit from Rational, rather than Real ...

This would break the Liskov substitution principle.

----------

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

From report at bugs.python.org  Tue Apr  5 10:06:47 2016
From: report at bugs.python.org (skydoom)
Date: Tue, 05 Apr 2016 14:06:47 +0000
Subject: [issue26693] Exception exceptions.AttributeError '_shutdown' in
 <module 'threading' >
In-Reply-To: <1459821105.82.0.884891417565.issue26693@psf.upfronthosting.co.za>
Message-ID: <1459865207.96.0.716110688566.issue26693@psf.upfronthosting.co.za>


skydoom added the comment:

I print out the threading.__file__ and can see it's "${PYTHONHOME}/lib/python3.5/threading.py" . I don't have any other "threading.py" elsewhere. so what should I do?

----------

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

From report at bugs.python.org  Tue Apr  5 10:08:51 2016
From: report at bugs.python.org (skydoom)
Date: Tue, 05 Apr 2016 14:08:51 +0000
Subject: [issue26693] Exception exceptions.AttributeError '_shutdown' in
 <module 'threading' >
In-Reply-To: <1459821105.82.0.884891417565.issue26693@psf.upfronthosting.co.za>
Message-ID: <1459865331.84.0.573545077875.issue26693@psf.upfronthosting.co.za>


skydoom added the comment:

sorry Martin, you are right, my original title was simply (and wrongly) copied over from the issue 1947. You get my identical error message in your post.

----------

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

From report at bugs.python.org  Tue Apr  5 10:20:19 2016
From: report at bugs.python.org (Robert Smallshire)
Date: Tue, 05 Apr 2016 14:20:19 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1459866019.75.0.0135797844922.issue26680@psf.upfronthosting.co.za>


Robert Smallshire added the comment:

>> Were float to inherit from Rational, rather than Real ...

> This would break the Liskov substitution principle.

How so?  Rational extends Real with only numerator, denominator and __float__. Isn't the existence of float.as_integer_ratio demonstration that numerator and denominator could be implemented?

----------

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

From report at bugs.python.org  Tue Apr  5 10:22:41 2016
From: report at bugs.python.org (skydoom)
Date: Tue, 05 Apr 2016 14:22:41 +0000
Subject: [issue26693] Exception ignored in: <module 'threading' from
 ...threading.py> in _shutdown, assert tlock.locked()
In-Reply-To: <1459821105.82.0.884891417565.issue26693@psf.upfronthosting.co.za>
Message-ID: <1459866161.92.0.279448144313.issue26693@psf.upfronthosting.co.za>


skydoom added the comment:

I just update the title to be precise.
Exception ignored in: <module 'threading' from ...threading.py> in _shutdown, assert tlock.locked()
AssertionError:

----------
title: Exception exceptions.AttributeError '_shutdown' in <module 'threading' > -> Exception ignored in: <module 'threading' from ...threading.py> in _shutdown, assert tlock.locked()

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

From report at bugs.python.org  Tue Apr  5 10:37:39 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 05 Apr 2016 14:37:39 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459866019.75.0.0135797844922.issue26680@psf.upfronthosting.co.za>
Message-ID: <20160405143725.GA5902@bytereef.org>


Stefan Krah added the comment:

On Tue, Apr 05, 2016 at 02:20:19PM +0000, Robert Smallshire wrote:
> >> Were float to inherit from Rational, rather than Real ...
> 
> > This would break the Liskov substitution principle.
> 
> How so?  Rational extends Real with only numerator, denominator and __float__. Isn't the existence of float.as_integer_ratio demonstration that numerator and denominator could be implemented?

Substitution principle:

Let phi(x) be a property provable about objects x of type T. Then phi(y) should
be true for objects y of type S where S is a subtype of T.

Use:

  Let phi(n) = forall n: n elt nat => (1 / n) * n == 1

Counterexample:

   n == 9992

----------

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

From report at bugs.python.org  Tue Apr  5 11:01:29 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 05 Apr 2016 15:01:29 +0000
Subject: [issue26693] Exception ignored in: <module 'threading' from
 ...threading.py> in _shutdown, assert tlock.locked()
In-Reply-To: <1459821105.82.0.884891417565.issue26693@psf.upfronthosting.co.za>
Message-ID: <1459868489.02.0.430323896197.issue26693@psf.upfronthosting.co.za>


Zachary Ware added the comment:

So there is actually no relation to #1947.

----------
resolution: duplicate -> 
superseder: Exception exceptions.AttributeError '_shutdown' in <module 'threading' -> 

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

From report at bugs.python.org  Tue Apr  5 11:01:46 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 05 Apr 2016 15:01:46 +0000
Subject: [issue26695] pickle and _pickle accelerator have different behavior
 when unpickling an object with falsy __getstate__ return
Message-ID: <1459868506.3.0.857595967516.issue26695@psf.upfronthosting.co.za>


New submission from Josh Rosenberg:

According to a note on the pickle docs ( https://docs.python.org/3/library/pickle.html#object.__getstate__ ): "If __getstate__() returns a false value, the __setstate__() method will not be called upon unpickling."

The phrasing is a little odd (since according to the __setstate__ docs, there is a behavior for classes without __setstate__ where it just assigns the contents of the pickled state dict to the __dict__ of the object), but to me, this means that any falsy value should prevent any __setstate__-like behavior.

But this is not how it works. Both the C accelerator and Python code treat None specially (they don't pickle state at all if it's None), which prevents __setstate__ or the __setstate__-like fallback from being executed.

But if it's any other falsy value, the behaviors differ, and diverge from the docs. Specifically, on load of a pickle with a non-None falsy state (say, False itself, or 0, or () or []):

Without __setstate__:
Pure Python pickle: Does not execute fallback code, behaves as expected (it just stored state it will never use), matching spirit of docs
C accelerated _pickle: Fails on anything but the empty dict with an UnpicklingError: state is not a dictionary, violating spirit of docs

With __setstate__:
Both versions call __setstate__ even though the documentation explicitly says they will not.

Seems like if nothing else, the docs should agree with the code, and the C and Python modules should agree on behavior.

I would not be at all surprised if outside code depends on being able to pickle falsy state and have its __setstate__ receive the falsy state (if nothing else, when the state is a container or number, being empty or 0 would be reasonable; failing to call __setstate__ in that case would be surprising). So it's probably not a good idea to make the implementation match the docs.

My proposal would be that at pickle time, if the class lacks __setstate__, treat any falsy return value as None. This means:

1. pickles are smaller (no storing junk that the default __setstate__-like behavior can't use)
2. pickles are valid (no UnpicklingError from the default __setstate__-like behavior)

The docs would also have to change, to indicate that, if defined, __setstate__ will be called even if __getstate__ returned a falsy (but not None) value.

Downside is the description of what happens is a little complex, since the behavior for non-None falsy values differs depending on the presence of a real __setstate__. Upside is that any code depending on the current behavior of falsy state being passed to __setstate__ keeps working, CPython and other interpreters will match behavior, and classes without __setstate__ will have smaller pickles.

----------
assignee: docs at python
components: Documentation
messages: 262908
nosy: docs at python, josh.r
priority: normal
severity: normal
status: open
title: pickle and _pickle accelerator have different behavior when unpickling an object with falsy __getstate__ return
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/issue26695>
_______________________________________

From report at bugs.python.org  Tue Apr  5 11:14:30 2016
From: report at bugs.python.org (Robert Smallshire)
Date: Tue, 05 Apr 2016 15:14:30 +0000
Subject: [issue26680] Incorporating float.is_integer into the numeric tower
 and Decimal
In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>
Message-ID: <1459869270.81.0.739229049353.issue26680@psf.upfronthosting.co.za>


Robert Smallshire added the comment:

Thanks Stefan for the illuminating example.

I knew I shouldn't have strayed off-topic.

----------

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

From report at bugs.python.org  Tue Apr  5 11:35:48 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Apr 2016 15:35:48 +0000
Subject: [issue26234] The typing module includes 're' and 'io' in __all__
In-Reply-To: <1454026053.81.0.969583520836.issue26234@psf.upfronthosting.co.za>
Message-ID: <20160405153543.13853.37348.214A7B46@psf.io>


Roundup Robot added the comment:

New changeset be3c4151d9bf by Guido van Rossum in branch '3.5':
Many changes from the upstream repo (https://github.com/python/typing).
https://hg.python.org/cpython/rev/be3c4151d9bf

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

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

From report at bugs.python.org  Tue Apr  5 11:35:48 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Apr 2016 15:35:48 +0000
Subject: [issue26391] typing: Specialized sub-classes of Generic never call
 __init__
In-Reply-To: <1455882742.53.0.118642694532.issue26391@psf.upfronthosting.co.za>
Message-ID: <20160405153543.13853.82113.F088C718@psf.io>


Roundup Robot added the comment:

New changeset be3c4151d9bf by Guido van Rossum in branch '3.5':
Many changes from the upstream repo (https://github.com/python/typing).
https://hg.python.org/cpython/rev/be3c4151d9bf

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

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

From report at bugs.python.org  Tue Apr  5 11:37:30 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Apr 2016 15:37:30 +0000
Subject: [issue26234] The typing module includes 're' and 'io' in __all__
In-Reply-To: <1454026053.81.0.969583520836.issue26234@psf.upfronthosting.co.za>
Message-ID: <1459870650.47.0.58197775407.issue26234@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/issue26234>
_______________________________________

From report at bugs.python.org  Tue Apr  5 11:37:50 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Apr 2016 15:37:50 +0000
Subject: [issue26391] typing: Specialized sub-classes of Generic never call
 __init__
In-Reply-To: <1455882742.53.0.118642694532.issue26391@psf.upfronthosting.co.za>
Message-ID: <1459870670.97.0.39371672184.issue26391@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/issue26391>
_______________________________________

From report at bugs.python.org  Tue Apr  5 11:38:33 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Apr 2016 15:38:33 +0000
Subject: [issue26691] Update the typing module to match what's in
 github.com/python/typing
In-Reply-To: <1459812488.48.0.790121011173.issue26691@psf.upfronthosting.co.za>
Message-ID: <1459870713.53.0.269583075807.issue26691@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Done!

changeset:   100854:78b84ae0b745
tag:         tip
parent:      100852:856d50130154
parent:      100853:be3c4151d9bf
user:        Guido van Rossum <guido at dropbox.com>
date:        Tue Apr 05 08:35:22 2016 -0700
summary:     Merge upstream typing.py changes from 3.5 branch.

changeset:   100853:be3c4151d9bf
branch:      3.5
parent:      100851:b1acd6cf15b6
user:        Guido van Rossum <guido at python.org>
date:        Tue Apr 05 08:28:52 2016 -0700
summary:     Many changes from the upstream repo (https://github.com/python/typing).

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

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

From report at bugs.python.org  Tue Apr  5 11:48:15 2016
From: report at bugs.python.org (skydoom)
Date: Tue, 05 Apr 2016 15:48:15 +0000
Subject: [issue26693] Exception ignored in: <module 'threading' from
 ...threading.py> in _shutdown, assert tlock.locked()
In-Reply-To: <1459821105.82.0.884891417565.issue26693@psf.upfronthosting.co.za>
Message-ID: <1459871295.9.0.347443673064.issue26693@psf.upfronthosting.co.za>


skydoom added the comment:

I quote the "issue 1947" just because I did a search in the db before I file this issue and find its output is similar to what I see, (except that it has "AttributeError" which mine does not have.) and because it's filed for 2.5 and I am not sure if this is just some minor "wording changes".

I tend to believe my issue is not the same issue with 1947 now.

----------

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

From report at bugs.python.org  Tue Apr  5 12:29:35 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Apr 2016 16:29:35 +0000
Subject: [issue26691] Update the typing module to match what's in
 github.com/python/typing
In-Reply-To: <1459812488.48.0.790121011173.issue26691@psf.upfronthosting.co.za>
Message-ID: <1459873775.36.0.0364639679393.issue26691@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

(Testing assignment to my alter ego. :-)

----------
assignee: gvanrossum -> Guido.van.Rossum
nosy: +Guido.van.Rossum

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

From report at bugs.python.org  Tue Apr  5 12:31:26 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Apr 2016 16:31:26 +0000
Subject: [issue26691] Update the typing module to match what's in
 github.com/python/typing
In-Reply-To: <1459812488.48.0.790121011173.issue26691@psf.upfronthosting.co.za>
Message-ID: <1459873886.08.0.259697712508.issue26691@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

(And back. Guido.van.Rossum no longer has developer privileges.)

----------
assignee: Guido.van.Rossum -> gvanrossum

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

From report at bugs.python.org  Tue Apr  5 12:35:05 2016
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 05 Apr 2016 16:35:05 +0000
Subject: [issue26667] Update importlib to accept pathlib.Path objects
In-Reply-To: <1459275774.9.0.416740988554.issue26667@psf.upfronthosting.co.za>
Message-ID: <1459874105.33.0.00633506162063.issue26667@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/issue26667>
_______________________________________

From report at bugs.python.org  Tue Apr  5 13:46:31 2016
From: report at bugs.python.org (Goneri Le Bouder)
Date: Tue, 05 Apr 2016 17:46:31 +0000
Subject: [issue26677] pyvenv: activate.fish breaks $PATH for bash scripts
In-Reply-To: <1459439361.75.0.379052301641.issue26677@psf.upfronthosting.co.za>
Message-ID: <1459878391.22.0.119868850556.issue26677@psf.upfronthosting.co.za>


Goneri Le Bouder added the comment:

A work around is to unset the _OLD_VIRTUAL_PATH variable before the activate:

set -e _OLD_VIRTUAL_PATH

----------
nosy: +Goneri Le Bouder

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

From report at bugs.python.org  Tue Apr  5 13:55:15 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 05 Apr 2016 17:55:15 +0000
Subject: [issue26664] find a bug in activate.fish of venv of cpython3.6
In-Reply-To: <1459255585.37.0.253753371111.issue26664@psf.upfronthosting.co.za>
Message-ID: <1459878915.25.0.41601197171.issue26664@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

I've asked the person who sent in the patch for #26348 to comment on this issue.

----------

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

From report at bugs.python.org  Tue Apr  5 14:36:35 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 05 Apr 2016 18:36:35 +0000
Subject: [issue26664] find a bug in activate.fish of venv of cpython3.6
In-Reply-To: <1459255585.37.0.253753371111.issue26664@psf.upfronthosting.co.za>
Message-ID: <1459881395.32.0.374128723471.issue26664@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/issue26664>
_______________________________________

From report at bugs.python.org  Tue Apr  5 14:39:04 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 05 Apr 2016 18:39:04 +0000
Subject: [issue26696] Document collections.abc.ByteString
Message-ID: <1459881544.79.0.834895685887.issue26696@psf.upfronthosting.co.za>


New submission from Brett Cannon:

[typing.ByteString](https://docs.python.org/3.5/library/typing.html#typing.ByteString) references collections.abc.ByteString, but no such type is documented.

----------
components: Library (Lib)
messages: 262918
nosy: brett.cannon, gvanrossum
priority: normal
severity: normal
stage: needs patch
status: open
title: Document collections.abc.ByteString
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Apr  5 14:39:12 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 05 Apr 2016 18:39:12 +0000
Subject: [issue26696] Document collections.abc.ByteString
In-Reply-To: <1459881544.79.0.834895685887.issue26696@psf.upfronthosting.co.za>
Message-ID: <1459881552.97.0.358917065949.issue26696@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python

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

From report at bugs.python.org  Tue Apr  5 15:12:18 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 Apr 2016 19:12:18 +0000
Subject: [issue15012] test issue
In-Reply-To: <1338954222.11.0.497891813063.issue15012@psf.upfronthosting.co.za>
Message-ID: <1459883538.69.0.295932098762.issue15012@psf.upfronthosting.co.za>


R. David Murray added the comment:

Test nosy email with ipv4 only in postfix.

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

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

From report at bugs.python.org  Tue Apr  5 15:32:03 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Apr 2016 19:32:03 +0000
Subject: [issue15012] test issue
In-Reply-To: <1459883538.69.0.295932098762.issue15012@psf.upfronthosting.co.za>
Message-ID: <CAAuNNr7Xdr+H_36xdh89Db48P_S58JO_rs_n1pLSBR-m8yFxeQ@mail.gmail.com>


Serhiy Storchaka added the comment:

Hurray! This works!

----------

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

From report at bugs.python.org  Tue Apr  5 15:33:44 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 Apr 2016 19:33:44 +0000
Subject: [issue15012] test issue
In-Reply-To: <1338954222.11.0.497891813063.issue15012@psf.upfronthosting.co.za>
Message-ID: <1459884824.88.0.321693337535.issue15012@psf.upfronthosting.co.za>


R. David Murray added the comment:

Oh, good, thank you for the confirmation.  It is not a complete cure, but at least it helps.  (I won't be surprised if rietveld emails still get blocked, for example.)

----------

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

From report at bugs.python.org  Tue Apr  5 16:56:35 2016
From: report at bugs.python.org (jcristau)
Date: Tue, 05 Apr 2016 20:56:35 +0000
Subject: [issue25731] Assigning and deleting __new__ attr on the class does
 not allow to create instances of this class
In-Reply-To: <1448454590.41.0.350843358205.issue25731@psf.upfronthosting.co.za>
Message-ID: <1459889795.59.0.836453416626.issue25731@psf.upfronthosting.co.za>


jcristau added the comment:

This change in 2.7 seems to break things:

$ cat foo.pxd 
cdef class B:
    cdef object b
$ cat foo.pyx 
cdef class A:
    pass

cdef class B:
    def __init__(self, b):
        self.b = b
$ cat bar.py
from foo import A, B

class C(A, B):
    def __init__(self):
        B.__init__(self, 1)

C()
$ cython foo.pyx && gcc -I/usr/include/python2.7 -Wall -shared -fPIC -o foo.so foo.c
$ python -c 'import bar'
Segmentation fault

C's tp_new is set to A's tp_new function, thus the b slot is never initialized to Py_None, and C's __init__ calls DECREF on a NULL pointer.

Reverting changeset e7062dd9085e makes things work again, with C's tp_new being B's tp_new.

----------
nosy: +jcristau

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

From report at bugs.python.org  Tue Apr  5 17:33:16 2016
From: report at bugs.python.org (Eric Johnson)
Date: Tue, 05 Apr 2016 21:33:16 +0000
Subject: [issue26697] tkFileDialog crash on askopenfilename Python 2.7 64-bit
 Win7
Message-ID: <1459891996.57.0.225918514546.issue26697@psf.upfronthosting.co.za>


New submission from Eric Johnson:

Attempting to run tkFileDialog.askopenfilename() using Python 64-bit on Windows 7 crashes.

Running SysWOW64\cmd.exe:

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Windows\SysWOW64>python
Python 2.7.11rc1 (v2.7.11rc1:82dd9545bd93, Nov 21 2015, 23:25:27) [MSC v.1500 64
 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import Tkinter
>>> Tkinter.Tcl().eval('info patchlevel')
'8.5.15'
>>> import tkFileDialog
>>> filename = tkFileDialog.askopenfilename()

C:\Windows\SysWOW64>


The application abruptly stops.

Running the same application with Python 32-bit does not crash.

----------
components: Tkinter
files: fileopendialog.py
messages: 262923
nosy: Eric Johnson
priority: normal
severity: normal
status: open
title: tkFileDialog crash on askopenfilename Python 2.7 64-bit Win7
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file42374/fileopendialog.py

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

From report at bugs.python.org  Tue Apr  5 17:48:59 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 05 Apr 2016 21:48:59 +0000
Subject: [issue26697] tkFileDialog crash on askopenfilename Python 2.7 64-bit
 Win7
In-Reply-To: <1459891996.57.0.225918514546.issue26697@psf.upfronthosting.co.za>
Message-ID: <1459892939.56.0.671247237498.issue26697@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware 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/issue26697>
_______________________________________

From report at bugs.python.org  Tue Apr  5 18:11:25 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 05 Apr 2016 22:11:25 +0000
Subject: [issue6953] readline documentation needs work
In-Reply-To: <1253456012.32.0.661240289209.issue6953@psf.upfronthosting.co.za>
Message-ID: <1459894285.78.0.680444149707.issue6953@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the reviews.

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

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

From report at bugs.python.org  Tue Apr  5 18:23:53 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 05 Apr 2016 22:23:53 +0000
Subject: [issue10796] Improve doc for readline.set_completer_delims()
In-Reply-To: <1293714489.48.0.717157988045.issue10796@psf.upfronthosting.co.za>
Message-ID: <1459895033.77.0.905339278962.issue10796@psf.upfronthosting.co.za>


Martin Panter added the comment:

My update includes a new section called Completion, with the following text:

By default, Readline is set up to be used by ?rlcompleter? to complete Python identifiers for the interactive interpreter. If the ?readline? module is to be used with a custom completer, a different set of word delimiters should be set.

I hope that is enough to call this fixed :)

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
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/issue10796>
_______________________________________

From report at bugs.python.org  Tue Apr  5 20:16:53 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Wed, 06 Apr 2016 00:16:53 +0000
Subject: [issue26039] More flexibility in zipfile write interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1459901813.33.0.525953631508.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Sorry for the delay, this fell off my radar because emails from both the bug tracker and Rietveld tend to fall foul of my spam filters, so I have to go and check.

I have implemented Serhiy's suggestions, but there turns out to be a test (test_write_after_read) that calls writestr while a reading handle is open, and it now fails. This is absolutely expected according to the design we discussed, but if there's a test, I guess that means we need to keep that functionality working?

In principle, the only thing that's not possible is interleaving writes to multiple files within the zip - because we don't know where to start writing the second file. We should be able to have one writer and n readers going at once, but every time I start looking into that I get mired in complexity. Maybe (hopefully) there's some critical abstraction that hasn't occurred to me.

----------
Added file: http://bugs.python.org/file42375/zipfile-open-w5.patch

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

From report at bugs.python.org  Tue Apr  5 20:52:17 2016
From: report at bugs.python.org (Sylvain Corlay)
Date: Wed, 06 Apr 2016 00:52:17 +0000
Subject: [issue26689] Add `has_flag` method to `distutils.CCompiler`
In-Reply-To: <1459643481.74.0.720699620632.issue26689@psf.upfronthosting.co.za>
Message-ID: <1459903937.0.0.313231212169.issue26689@psf.upfronthosting.co.za>


Sylvain Corlay added the comment:

Are you fine with the new state of the patch?

----------

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

From report at bugs.python.org  Tue Apr  5 21:16:16 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 06 Apr 2016 01:16:16 +0000
Subject: [issue23551] IDLE to provide menu link to PIP gui.
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1459905376.59.0.184325390869.issue23551@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Ensurepip: for the present, I am willing to assume that is pip imports, it is ready to go.

try: import pip
except ImportError: <ask whether to install>

Testing: testing that runpip works will initially be done by running the app on our live systems.  For automated testing of the gui, runpip should be replaced with a mock that looks up a response string in a dictionary of argument-response pairs.  The response string should have the same format as pip responses, though they will usually be shorted.  For instance, the dummy 'machine' might have only two packages.  The description might be 'Description of package x' as that would be enough to test that a description is displayed when a line is double clicked.

In the last week, I have learned more about how to write functional tests for a GUI.  I will try to do one soon for IDLE.

Upendra: tem_pip_v3.py runs as I believe you intended from command line.  The details will need a scroll bar.

When run from Idle editor on my machine, it behaves strangely.  first, it restarts in a new shell window instead of the existing one.  This is wrong and I have not seen it before.  I have not yet figured out why.

Next, a blank console window appears before the tkinter gui window and disappears when the tkwindow appears.  Ditto. When an entry is double-click, a console window is opened and closed and no details are displayed.  Changing ["pip"] to ["pythonw", "-m", "pip"] fixes these issues.

The _get_data function is not needed for tests that I can think of.  Please remove debug prints and the 'are you sure you want to quit' box.

Eric: the vscroll is on a row above the Treeview.  Give explicit row and column for each grid call, and group together the grid calls for a given frame.

----------

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

From report at bugs.python.org  Tue Apr  5 21:20:12 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 06 Apr 2016 01:20:12 +0000
Subject: [issue23551] IDLE to provide menu link to PIP gui.
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1459905612.41.0.644152614887.issue23551@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Eric: some of my comments on Upendra's file apply to yours also.

----------

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

From report at bugs.python.org  Tue Apr  5 22:53:48 2016
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Wed, 06 Apr 2016 02:53:48 +0000
Subject: [issue26698] IDLE DPI Awareness
Message-ID: <1459911228.34.0.00983454800259.issue26698@psf.upfronthosting.co.za>


New submission from Westley Mart?nez:

IDLE is blurry on High DPI Windows, because IDLE is not DPI aware. IDLE should be made to be DPI aware so that the text is more readable.

----------
components: IDLE, Library (Lib), Tkinter
messages: 262930
nosy: westley.martinez
priority: normal
severity: normal
status: open
title: IDLE DPI Awareness
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Wed Apr  6 00:11:00 2016
From: report at bugs.python.org (Eric Khoo Jiun Hooi)
Date: Wed, 06 Apr 2016 04:11:00 +0000
Subject: [issue23551] IDLE to provide menu link to PIP gui.
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1459915860.4.0.0561291755003.issue23551@psf.upfronthosting.co.za>


Eric Khoo Jiun Hooi added the comment:

Terry, how do you run the script on idle? I try to run the script with idle -r "script name" and it was ok.

----------

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

From report at bugs.python.org  Wed Apr  6 00:12:23 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Apr 2016 04:12:23 +0000
Subject: [issue15012] test issue
In-Reply-To: <1459884824.88.0.321693337535.issue15012@psf.upfronthosting.co.za>
Message-ID: <2743298.NfnsIauykt@raxxla>


Serhiy Storchaka added the comment:

Rietveld emails received too, but fall in spam folder as always.

----------

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

From report at bugs.python.org  Wed Apr  6 02:08:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Apr 2016 06:08:35 +0000
Subject: [issue26200] SETREF adds unnecessary work in some cases
In-Reply-To: <1453745024.51.0.674954872761.issue26200@psf.upfronthosting.co.za>
Message-ID: <1459922915.11.0.179141382288.issue26200@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Since several core devs agree that we should have doual macros, I'll rename Py_SETREF to Py_XSETREF and add new Py_SETREF.

----------

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

From report at bugs.python.org  Wed Apr  6 02:37:29 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 06 Apr 2016 06:37:29 +0000
Subject: [issue26200] SETREF adds unnecessary work in some cases
In-Reply-To: <1453745024.51.0.674954872761.issue26200@psf.upfronthosting.co.za>
Message-ID: <1459924649.12.0.29925852593.issue26200@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Please apply the new macros so that all the original DECREFs are restored rather than blindly converted to XDECREFs.

----------

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

From report at bugs.python.org  Wed Apr  6 02:52:01 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 06 Apr 2016 06:52:01 +0000
Subject: [issue22570] Better stdlib support for Path objects
In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za>
Message-ID: <20160406065158.51421.74848.6453D92A@psf.io>


Roundup Robot added the comment:

New changeset d0c8b2c1544e by Serhiy Storchaka in branch '3.5':
Issue #22570: Renamed Py_SETREF to Py_XSETREF.
https://hg.python.org/cpython/rev/d0c8b2c1544e

New changeset 719c11b6b6ff by Serhiy Storchaka in branch 'default':
Issue #22570: Renamed Py_SETREF to Py_XSETREF.
https://hg.python.org/cpython/rev/719c11b6b6ff

New changeset 7197809a7428 by Serhiy Storchaka in branch '2.7':
Issue #22570: Renamed Py_SETREF to Py_XSETREF.
https://hg.python.org/cpython/rev/7197809a7428

----------

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

From report at bugs.python.org  Wed Apr  6 03:29:49 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 06 Apr 2016 07:29:49 +0000
Subject: [issue26699] locale.str docstring is incorrect: "Convert float to
 integer"
Message-ID: <1459927789.02.0.138982751213.issue26699@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

[Observed by one of my colleagues]

The locale.str docstring currently looks like this (and apparently has been
this way since the dawn of time):

    def str(val):
        """Convert float to integer, taking the locale into account."""

The output of str doesn't *look* like an integer on my machine. :-)

    Python 2.7.10 |Master 2.1.0.dev1829 (64-bit)| (default, Oct 21 2015, 09:09:19) 
    [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.6)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import locale
    >>> locale.setlocale(locale.LC_NUMERIC, 'fr_FR')
    'fr_FR'
    >>> locale.str(34.56)
    '34,56'

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 262936
nosy: docs at python, mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: locale.str docstring is incorrect: "Convert float to integer"
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Apr  6 03:34:52 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 06 Apr 2016 07:34:52 +0000
Subject: [issue23551] IDLE to provide menu link to PIP gui.
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1459928092.32.0.97838492562.issue23551@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

F5 from the editor, with a Shell window already present.

----------

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

From report at bugs.python.org  Wed Apr  6 03:45:34 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Apr 2016 07:45:34 +0000
Subject: [issue22570] Better stdlib support for Path objects
In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za>
Message-ID: <1459928734.4.0.494010926557.issue22570@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Sorry, these changesets were related to issue26200.

----------

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

From report at bugs.python.org  Wed Apr  6 03:48:18 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Apr 2016 07:48:18 +0000
Subject: [issue26200] SETREF adds unnecessary work in some cases
In-Reply-To: <1453745024.51.0.674954872761.issue26200@psf.upfronthosting.co.za>
Message-ID: <1459928898.62.0.435753668135.issue26200@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Py_SETREF was renamed to Py_XSETREF in 719c11b6b6ff, d0c8b2c1544e and 7197809a7428.

Here is a patch that introduces new Py_SETREF and uses it instead Py_XSETREF if Py_DECREF was used before.

----------
keywords: +patch
Added file: http://bugs.python.org/file42376/py_setref.patch

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

From report at bugs.python.org  Wed Apr  6 03:59:10 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 06 Apr 2016 07:59:10 +0000
Subject: [issue26700] Make digest_size a class variable
Message-ID: <1459929550.45.0.656140899063.issue26700@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

It would be nicer if this worked:

     >>> hashlib.md5.digest_size
     64

----------
assignee: gregory.p.smith
components: Extension Modules
messages: 262940
nosy: gregory.p.smith, rhettinger
priority: normal
severity: normal
status: open
title: Make digest_size a class variable
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Wed Apr  6 05:01:52 2016
From: report at bugs.python.org (Robert Smallshire)
Date: Wed, 06 Apr 2016 09:01:52 +0000
Subject: [issue26701] Documentation for int constructor mentions __int__ but
 not __trunc__
Message-ID: <1459933312.1.0.479151701513.issue26701@psf.upfronthosting.co.za>


New submission from Robert Smallshire:

The documentation for the int(x) constructor explains that if possible, it delegates to x.__int__().   The documentation does not explain that there is a fallback to x.__trunc__() if x.__int__() is not available.

The only mention of __trunc__ in the Python documentation is in the entry for math.trunc; the documentation for the numbers module does not describe the underlying special methods.

Given that all Real numbers are required to implement __trunc__ but only Integral subclasses are required to implement __int__ this could be important to implementers of other Real types, although in practice I imagine that most Real types will implement __int__ as float does.

----------
assignee: docs at python
components: Documentation
messages: 262941
nosy: Robert Smallshire2, docs at python
priority: normal
severity: normal
status: open
title: Documentation for int constructor mentions __int__ but not __trunc__
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Apr  6 07:15:28 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 06 Apr 2016 11:15:28 +0000
Subject: [issue26689] Add `has_flag` method to `distutils.CCompiler`
In-Reply-To: <1459643481.74.0.720699620632.issue26689@psf.upfronthosting.co.za>
Message-ID: <1459941328.92.0.731474543355.issue26689@psf.upfronthosting.co.za>


SilentGhost added the comment:

I'm largely fine with it, bar the in-function import. It would also be good if you could verify that no other temporary files are left after the function is run.

As I said earlier, issue 25544 should have priority and it should get a refreshed patch soon.

Donald, I'm assigning issue to you since you're maintaining this module.

----------
assignee:  -> dstufft
stage: patch review -> commit review
status: open -> pending

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

From report at bugs.python.org  Wed Apr  6 07:17:04 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 06 Apr 2016 11:17:04 +0000
Subject: [issue26689] Add `has_flag` method to `distutils.CCompiler`
In-Reply-To: <1459643481.74.0.720699620632.issue26689@psf.upfronthosting.co.za>
Message-ID: <1459941424.51.0.0871956822829.issue26689@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
status: pending -> open

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

From report at bugs.python.org  Wed Apr  6 08:12:39 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 06 Apr 2016 12:12:39 +0000
Subject: [issue26257] Eliminate buffer_tests.py
In-Reply-To: <1454323795.43.0.12298865479.issue26257@psf.upfronthosting.co.za>
Message-ID: <1459944759.96.0.887547330933.issue26257@psf.upfronthosting.co.za>


Martin Panter added the comment:

I discovered a flaw in the bytearray tests: most of them don?t actually test bytearray objects! This is easy to fix in Python 3, and I added a test case to ensure that the arguments are converted to the expected type.

However porting this fix to Python 2 was trickier. A few of the bytearray methods do not accept bytearray arguments:

>>> bytearray(b"abc").ljust(10, bytearray(b"*"))
TypeError: ljust() argument 2 must be char, not bytearray
>>> bytearray(b"abc").rjust(10, bytearray(b"*"))
TypeError: rjust() argument 2 must be char, not bytearray
>>> bytearray(b"abc").center(10, bytearray(b"*"))
TypeError: center() argument 2 must be char, not bytearray

I adapted the tests from the deleted buffer_tests.py file to override the relevant tests from string_tests.py, so that we continue to test bytearray methods but with str a.k.a. bytes arguments.

----------
versions: +Python 2.7
Added file: http://bugs.python.org/file42377/buffer_tests.py2.patch

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

From report at bugs.python.org  Wed Apr  6 09:32:45 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Apr 2016 13:32:45 +0000
Subject: [issue26257] Eliminate buffer_tests.py
In-Reply-To: <1454323795.43.0.12298865479.issue26257@psf.upfronthosting.co.za>
Message-ID: <1459949565.39.0.583869625709.issue26257@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Nice.

> I discovered a flaw in the bytearray tests: most of them don?t actually test bytearray objects!

Good catch!

> I adapted the tests from the deleted buffer_tests.py file to override the relevant tests from string_tests.py, so that we continue to test bytearray methods but with str a.k.a. bytes arguments.

The patch LGTM. But may be instead of duplicating tests add fixfillchartype() (calling fixtype() by default)? If this don't complicate tests too much.

----------

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

From report at bugs.python.org  Wed Apr  6 09:53:46 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Apr 2016 13:53:46 +0000
Subject: [issue26701] Documentation for int constructor mentions __int__ but
 not __trunc__
In-Reply-To: <1459933312.1.0.479151701513.issue26701@psf.upfronthosting.co.za>
Message-ID: <1459950826.6.0.641384950146.issue26701@psf.upfronthosting.co.za>


R. David Murray added the comment:

It is documented in the relevant PEP (pep 3141), but should indeed be added to the appropriate places in the regular documentation.

----------
nosy: +r.david.murray
versions: +Python 3.6

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

From report at bugs.python.org  Wed Apr  6 10:43:37 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 06 Apr 2016 14:43:37 +0000
Subject: [issue26702] A better assert statement
Message-ID: <1459953817.06.0.108745447257.issue26702@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

Too many times I hit failing assert statements, and have no idea what value is causing the assertion to fail.  Sure, you can provide a value to print (instead of just the failing code) but it seems to be fairly rarely used.  And it can also lead to code duplication.  As an example, I saw this today in some installed code:

assert k.replace('.', '').replace('-', '').replace('_', '').isalum()

So now I have to sudo edit the installed system file, duplicate everything up to but not including the .isalum() as the second argument to assert, then try to reproduce the problem.  IWBNI assert could make this better.

One idea would be to split the value and the conditional being asserted on that value, but we can't use two-argument asserts for that.  Crazy syntax thought: reuse the 'with' keyword:

assert k.replace('.', '').replace('-', '').replace('_', '') with isalum

where the part before the 'with' is 'value' and the part after the 'with' is conditional, and the two parts together imply the expression.

This would be equivalent to:

if __debug__:
    if not value.conditional():
        raise AssertionError(expression, value, conditional)

I suppose you then want to support arguments:

assert foo with can_bar, 1, 2, x=3

but maybe that's YAGNI and we can just say to use a better 2-value assert in those more complicated cases.

----------
messages: 262946
nosy: barry
priority: normal
severity: normal
status: open
title: A better assert statement
versions: Python 3.6

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

From report at bugs.python.org  Wed Apr  6 11:03:17 2016
From: report at bugs.python.org (Eric Khoo Jiun Hooi)
Date: Wed, 06 Apr 2016 15:03:17 +0000
Subject: [issue23551] IDLE to provide menu link to PIP gui.
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1459954997.51.0.859613688069.issue23551@psf.upfronthosting.co.za>


Eric Khoo Jiun Hooi added the comment:

I try to open the script in editor mode and run the script. It restart shell and run the script. I upload the picture of it, is there any wrong with it?

----------
Added file: http://bugs.python.org/file42378/tem_v3_idle.png

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

From report at bugs.python.org  Wed Apr  6 11:07:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Apr 2016 15:07:12 +0000
Subject: [issue26702] A better assert statement
In-Reply-To: <1459953817.06.0.108745447257.issue26702@psf.upfronthosting.co.za>
Message-ID: <1459955232.66.0.424285638384.issue26702@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think in this particular case you are more interesting in the value of k than k.replace('.', '').replace('-', '').replace('_', '').

----------
nosy: +rhettinger, serhiy.storchaka

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

From report at bugs.python.org  Wed Apr  6 11:11:25 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 06 Apr 2016 15:11:25 +0000
Subject: [issue26702] A better assert statement
In-Reply-To: <1459955232.66.0.424285638384.issue26702@psf.upfronthosting.co.za>
Message-ID: <20160406111121.67398254@anarchist.wooz.org>


Barry A. Warsaw added the comment:

On Apr 06, 2016, at 03:07 PM, Serhiy Storchaka wrote:

>I think in this particular case you are more interesting in the value of k
>than k.replace('.', '').replace('-', '').replace('_', '').

Possibly so.

----------

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

From report at bugs.python.org  Wed Apr  6 11:42:25 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 06 Apr 2016 15:42:25 +0000
Subject: [issue26698] IDLE DPI Awareness
In-Reply-To: <1459911228.34.0.00983454800259.issue26698@psf.upfronthosting.co.za>
Message-ID: <1459957345.98.0.857452975837.issue26698@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +gpolo, kbk, roger.serwy, serhiy.storchaka, terry.reedy

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

From report at bugs.python.org  Wed Apr  6 13:10:41 2016
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 06 Apr 2016 17:10:41 +0000
Subject: [issue26671] Clean up path_converter in posixmodule.c
In-Reply-To: <1459330274.5.0.616265410958.issue26671@psf.upfronthosting.co.za>
Message-ID: <1459962641.07.0.277640531256.issue26671@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Can you post the updated patch please?

----------

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

From report at bugs.python.org  Wed Apr  6 13:57:20 2016
From: report at bugs.python.org (Eric Khoo Jiun Hooi)
Date: Wed, 06 Apr 2016 17:57:20 +0000
Subject: [issue23551] IDLE to provide menu link to PIP gui.
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1459965440.39.0.525570880373.issue23551@psf.upfronthosting.co.za>


Changes by Eric Khoo Jiun Hooi <erichooi1995 at gmail.com>:


Added file: http://bugs.python.org/file42379/pip_gui_v4.py

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

From report at bugs.python.org  Wed Apr  6 14:07:05 2016
From: report at bugs.python.org (JoshN)
Date: Wed, 06 Apr 2016 18:07:05 +0000
Subject: [issue26703] Socket state corrupts when original assignment goes out
 of scope
Message-ID: <1459966025.84.0.875779742702.issue26703@psf.upfronthosting.co.za>


New submission from JoshN:

Creating a socket in one thread and sharing it with another will cause the socket to corrupt as soon as the thread it was created in exits.

Example code:
import socket, threading, time, os

def start():
    a = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    a.bind(("", 8080))
    a.set_inheritable(True)

    thread = threading.Thread(target=abc, args=(a.fileno(),))
    thread.start()

    time.sleep(2)
    print("Main thread exiting, socket is still valid: " + str(a) + "\n")

def abc(b):
    sock = socket.socket(fileno=b)
    for _ in range(3):
        print("Passed as an argument:" + str(sock) + "\n=====================")

        time.sleep(1.1)

start()

Note that, as soon as the main thread exits, the socket isn't closed, nor is the fd=-1, etc. Doing anything with this corrupted object throws WinError 10038 ('operation performed on something that is not a socket').

I should note that the main thread exiting doesn't seem to be the cause, it is the original object containing the socket going out of scope that causes the socket to become corrupted.

-JoshN

----------
components: IO
messages: 262951
nosy: JoshN
priority: normal
severity: normal
status: open
title: Socket state corrupts when original assignment goes out of scope
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Wed Apr  6 14:11:14 2016
From: report at bugs.python.org (JoshN)
Date: Wed, 06 Apr 2016 18:11:14 +0000
Subject: [issue26703] Socket state corrupts when original socket object goes
 out of scope in a different thread
In-Reply-To: <1459966025.84.0.875779742702.issue26703@psf.upfronthosting.co.za>
Message-ID: <1459966274.77.0.948410422054.issue26703@psf.upfronthosting.co.za>


Changes by JoshN <cameronm670 at gmail.com>:


----------
title: Socket state corrupts when original assignment goes out of scope -> Socket state corrupts when original socket object goes out of scope in a different thread

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

From report at bugs.python.org  Wed Apr  6 14:29:02 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 06 Apr 2016 18:29:02 +0000
Subject: [issue26703] Socket state corrupts when original socket object goes
 out of scope in a different thread
In-Reply-To: <1459966025.84.0.875779742702.issue26703@psf.upfronthosting.co.za>
Message-ID: <1459967342.84.0.393547443903.issue26703@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +pitrou

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

From report at bugs.python.org  Wed Apr  6 14:30:34 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 06 Apr 2016 18:30:34 +0000
Subject: [issue23551] IDLE to provide menu link to PIP gui.
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1459967434.91.0.730182041263.issue23551@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

It is wrong for Run Module to open a new shell window when there is a shell window already.  But I am not seeing this today with IDLE restarted, so for now, forget about it.

V4 is improved, but the list of installed packages is repeated and 2/3 repeated again, for a total of 2 2/3 appearances  - like 'abcabcab', where a, b, and c are packages.

----------

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

From report at bugs.python.org  Wed Apr  6 14:57:57 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Apr 2016 18:57:57 +0000
Subject: [issue26671] Clean up path_converter in posixmodule.c
In-Reply-To: <1459330274.5.0.616265410958.issue26671@psf.upfronthosting.co.za>
Message-ID: <1459969077.79.0.837268238018.issue26671@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here it is.

----------
Added file: http://bugs.python.org/file42380/path_converter_cleanup_3.patch

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

From report at bugs.python.org  Wed Apr  6 15:01:31 2016
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 06 Apr 2016 19:01:31 +0000
Subject: [issue26671] Clean up path_converter in posixmodule.c
In-Reply-To: <1459330274.5.0.616265410958.issue26671@psf.upfronthosting.co.za>
Message-ID: <1459969291.88.0.0606186000633.issue26671@psf.upfronthosting.co.za>


Larry Hastings added the comment:

LGTM.

----------

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

From report at bugs.python.org  Wed Apr  6 15:19:14 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 06 Apr 2016 19:19:14 +0000
Subject: [issue26671] Clean up path_converter in posixmodule.c
In-Reply-To: <1459330274.5.0.616265410958.issue26671@psf.upfronthosting.co.za>
Message-ID: <20160406191910.13853.62967.CEE65B6E@psf.io>


Roundup Robot added the comment:

New changeset a866f5727b7f by Serhiy Storchaka in branch 'default':
Issue #26671: Enhanced path_converter.
https://hg.python.org/cpython/rev/a866f5727b7f

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

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

From report at bugs.python.org  Wed Apr  6 15:20:25 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Apr 2016 19:20:25 +0000
Subject: [issue26671] Clean up path_converter in posixmodule.c
In-Reply-To: <1459330274.5.0.616265410958.issue26671@psf.upfronthosting.co.za>
Message-ID: <1459970425.91.0.870214723557.issue26671@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your review Larry.

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

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

From report at bugs.python.org  Wed Apr  6 15:30:06 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 06 Apr 2016 19:30:06 +0000
Subject: [issue26703] Socket state corrupts when original socket object goes
 out of scope in a different thread
In-Reply-To: <1459966025.84.0.875779742702.issue26703@psf.upfronthosting.co.za>
Message-ID: <1459971006.57.0.671496818835.issue26703@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

You used the `fileno` based initialization in the child, which creates a wrapper around the same file descriptor without duplicating it, so when the first socket disappears, that file descriptor becomes invalid.

I think this is a doc bug more than a behavior bug; the docs say "Unlike socket.fromfd(), fileno will return the same socket and not a duplicate." which almost seems like the idea is that the Python level socket object it returns is cached in some way that allows it to be looked up by file descriptor (making mysock2 = socket.socket(fileno=mysock.fileno()) equivalent to mysock2 = mysock), but what it really means is that there are two Python level socket objects referencing the same C level file descriptor; the normal cleanup behavior still applies though, so the first Python level socket object to be destroyed also closes the file descriptor, leaving the other socket object in a broken state.

The correct approach to this would be to just pass the socket object to the thread directly, or pass along the address family and type and use socket.fromfd (which dups the underlying file descriptor).

----------
nosy: +josh.r

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

From report at bugs.python.org  Wed Apr  6 15:32:57 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 06 Apr 2016 19:32:57 +0000
Subject: [issue26703] Socket state corrupts when original socket object goes
 out of scope in a different thread
In-Reply-To: <1459966025.84.0.875779742702.issue26703@psf.upfronthosting.co.za>
Message-ID: <1459971177.01.0.969202829028.issue26703@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

For source reference, the behavior for this case is to just copy out the file descriptor and stick it in a new socket object ( https://hg.python.org/cpython/file/3.5/Modules/socketmodule.c#l4289 ); no work is being done to somehow collaboratively manage the file descriptor to ensure it remains alive for the life of the socket object you're creating.

----------

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

From report at bugs.python.org  Wed Apr  6 15:55:52 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 06 Apr 2016 19:55:52 +0000
Subject: [issue26671] Clean up path_converter in posixmodule.c
In-Reply-To: <1459330274.5.0.616265410958.issue26671@psf.upfronthosting.co.za>
Message-ID: <20160406195549.28259.72317.A4FD9BC7@psf.io>


Roundup Robot added the comment:

New changeset 8dc144e47252 by Serhiy Storchaka in branch 'default':
Issue #26671: Fixed #ifdef indentation.
https://hg.python.org/cpython/rev/8dc144e47252

----------

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

From report at bugs.python.org  Wed Apr  6 16:01:26 2016
From: report at bugs.python.org (Anthony Sottile)
Date: Wed, 06 Apr 2016 20:01:26 +0000
Subject: [issue26704] unittest.mock.patch: Double patching instance method:
 AttributeError: Mock object has no attribute '__name__'
Message-ID: <1459972886.32.0.234738617564.issue26704@psf.upfronthosting.co.za>


New submission from Anthony Sottile:

Originally from https://github.com/testing-cabal/mock/issues/350

## Example
```python
from unittest import mock

class C(object):
    def f(self):
        pass

c = C()

with mock.patch.object(c, 'f', autospec=True):
    with mock.patch.object(c, 'f', autospec=True):
        pass
```

## Python3.3

```
$ test.py
$
```

## Python3.4 / 3.5 / 3.6 (From gitbhub.com/python/cpython at fa3fc6d7)

```
Traceback (most recent call last):
  File "test.py", line 10, in <module>
    with mock.patch.object(c, 'f', autospec=True):
  File "/home/asottile/workspace/cpython/Lib/unittest/mock.py", line 1320, in __enter__
    _name=self.attribute, **kwargs)
  File "/home/asottile/workspace/cpython/Lib/unittest/mock.py", line 2220, in create_autospec
    _check_signature(original, new, skipfirst=skipfirst)
  File "/home/asottile/workspace/cpython/Lib/unittest/mock.py", line 112, in _check_signature
    _copy_func_details(func, checksig)
  File "/home/asottile/workspace/cpython/Lib/unittest/mock.py", line 117, in _copy_func_details
    funcopy.__name__ = func.__name__
  File "/home/asottile/workspace/cpython/Lib/unittest/mock.py", line 578, in __getattr__
    raise AttributeError("Mock object has no attribute %r" % name)
AttributeError: Mock object has no attribute '__name__'
```

----------
components: Library (Lib)
messages: 262960
nosy: asottile
priority: normal
severity: normal
status: open
title: unittest.mock.patch: Double patching instance method: AttributeError: Mock object has no attribute '__name__'
type: crash
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Apr  6 16:03:07 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 06 Apr 2016 20:03:07 +0000
Subject: [issue26671] Clean up path_converter in posixmodule.c
In-Reply-To: <1459330274.5.0.616265410958.issue26671@psf.upfronthosting.co.za>
Message-ID: <20160406200304.7823.32333.B47DE301@psf.io>


Roundup Robot added the comment:

New changeset 4acdb324a430 by Serhiy Storchaka in branch 'default':
Issue #26671: Fixed #ifdef indentation.
https://hg.python.org/cpython/rev/4acdb324a430

----------

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

From report at bugs.python.org  Wed Apr  6 16:03:38 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Wed, 06 Apr 2016 20:03:38 +0000
Subject: [issue26705] logging.Handler.handleError should be called from
 logging.Handler.handle
Message-ID: <1459973017.82.0.820573021891.issue26705@psf.upfronthosting.co.za>


New submission from Aviv Palivoda:

Currently all the stdlib logging handlers (except BufferingHandler) emit method have the following structure:
    def emit(self, record):
        try:
            // do the emit
        except Exception:
            self.handleError(record)

I suggest changing this so that the handle method will do the exception handling of the emit:

    def handle(self, record): 
        rv = self.filter(record)
        if rv:
            self.acquire()
            try:
                self.emit(record)
            except Exception:
                self.handleError(record)
            finally:
                self.release()
        return rv

Now the emit() method can be override without the need to handle it's own exceptions.

I think this is more clear with the current documentation as well. For example in the handleError function it says that "This method should be called from handlers when an exception is encountered during an emit() call". In addition in the only example that implement the emit() function https://docs.python.org/3/howto/logging-cookbook.html#speaking-logging-messages there is no error handling at all.

----------
components: Library (Lib)
files: logging-handle-error.patch
keywords: patch
messages: 262962
nosy: palaviv, vinay.sajip
priority: normal
severity: normal
status: open
title: logging.Handler.handleError should be called from logging.Handler.handle
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file42381/logging-handle-error.patch

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

From report at bugs.python.org  Wed Apr  6 16:33:56 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Apr 2016 20:33:56 +0000
Subject: [issue26027] Support Path objects in the posix module
In-Reply-To: <1452114329.99.0.617690911804.issue26027@psf.upfronthosting.co.za>
Message-ID: <1459974836.59.0.516209111412.issue26027@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is preliminary patch without tests. Writing tests will be tiresome.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file42382/path_converter_path.patch

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

From report at bugs.python.org  Wed Apr  6 16:36:27 2016
From: report at bugs.python.org (Shaun Walbridge)
Date: Wed, 06 Apr 2016 20:36:27 +0000
Subject: [issue26706] Update OpenSSL version in readme
Message-ID: <1459974987.74.0.0926215654006.issue26706@psf.upfronthosting.co.za>


New submission from Shaun Walbridge:

Sync documentation with the OpenSSL version update (1.0.2g vs 1.0.2f). Mismatch present in both head and 3.5 branch.

----------
assignee: docs at python
components: Documentation
files: readme-openssl.diff
keywords: patch
messages: 262964
nosy: docs at python, scw
priority: normal
severity: normal
status: open
title: Update OpenSSL version in readme
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42383/readme-openssl.diff

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

From report at bugs.python.org  Wed Apr  6 17:16:35 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 06 Apr 2016 21:16:35 +0000
Subject: [issue26705] logging.Handler.handleError should be called from
 logging.Handler.handle
In-Reply-To: <1459973017.82.0.820573021891.issue26705@psf.upfronthosting.co.za>
Message-ID: <1459977395.54.0.277116956662.issue26705@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

Thanks for the suggestion, but I'm not sure this can be accepted without violating backward compatibility. It forces each handler implementation to either accept the base implementation of handleError(), or to override it. And if there are existing handler implementations out there (i.e. not in the stdlib) which don't call handleError in their emit() (i.e. allow exceptions to propagate upwards), their behaviour would change, wouldn't it? That's not backwards-compatible.

----------

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

From report at bugs.python.org  Wed Apr  6 17:17:51 2016
From: report at bugs.python.org (Anthony Sottile)
Date: Wed, 06 Apr 2016 21:17:51 +0000
Subject: [issue26704] unittest.mock.patch: Double patching instance method:
 AttributeError: Mock object has no attribute '__name__'
In-Reply-To: <1459972886.32.0.234738617564.issue26704@psf.upfronthosting.co.za>
Message-ID: <1459977471.57.0.92007997296.issue26704@psf.upfronthosting.co.za>


Anthony Sottile added the comment:

The root cause seems to be that autospecced functions return a function object (not a Mock instance) which a '.mock' attribute which is a MagicMock ( assigned here: https://github.com/python/cpython/blob/ae775ab1eb72f42de2d070158bade4bf261ac04f/Lib/unittest/mock.py#L198 )

I took a first stab at a patch (attached)

----------
Added file: http://bugs.python.org/file42384/patch

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

From report at bugs.python.org  Wed Apr  6 18:11:45 2016
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Wed, 06 Apr 2016 22:11:45 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1459980705.26.0.17031619235.issue18844@psf.upfronthosting.co.za>


Westley Mart?nez added the comment:

I still like Serhiy's implementation more. A function that returns a list instead of the item is unnatural and doesn't fit with the rest of the module.

I think there's need to be some discussion about use cases. What do users actually want? Maybe post this on the ideas list.

----------

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

From report at bugs.python.org  Wed Apr  6 18:12:00 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 06 Apr 2016 22:12:00 +0000
Subject: [issue26703] Socket state corrupts when original socket object goes
 out of scope in a different thread
In-Reply-To: <1459966025.84.0.875779742702.issue26703@psf.upfronthosting.co.za>
Message-ID: <1459980720.64.0.263892201581.issue26703@psf.upfronthosting.co.za>


Martin Panter added the comment:

The documentation already says ?Sockets are automatically closed when they are garbage-collected?. If for some reason you want to release a socket object but keep the file descriptor open, I suggest socket.detach(). Otherwise, pass the original socket, not the fileno.

I think this is at best a documentation issue, if you have any suggestions.

----------
assignee:  -> docs at python
components: +Documentation -IO
nosy: +docs at python, martin.panter
type: crash -> behavior

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

From report at bugs.python.org  Wed Apr  6 18:15:24 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 06 Apr 2016 22:15:24 +0000
Subject: [issue26703] Socket state corrupts when original socket object goes
 out of scope in a different thread
In-Reply-To: <1459966025.84.0.875779742702.issue26703@psf.upfronthosting.co.za>
Message-ID: <1459980924.87.0.555219016932.issue26703@psf.upfronthosting.co.za>


Martin Panter added the comment:

Also, if you enable warnings (e.g. python -Wall), you should see that the socket is being closed:

-c:22: ResourceWarning: unclosed <socket.socket fd=3, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('0.0.0.0', 8080)>

----------

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

From report at bugs.python.org  Wed Apr  6 18:46:02 2016
From: report at bugs.python.org (Steven Basart)
Date: Wed, 06 Apr 2016 22:46:02 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1459982762.74.0.883345216767.issue18844@psf.upfronthosting.co.za>


Steven Basart added the comment:

Okay so I added a few lines of code.  One to make it return a single number if amount == 1 and the other to check that the amount > 1.

The main difference I've noticed between this implementation and previous versions compared to say R is that in R they provide a boolean flag to ask if sampling with replacement.

Here's there documentation and source code:
https://github.com/wch/r-source/blob/e5b21d0397c607883ff25cca379687b86933d730/src/library/base/man/sample.Rd

https://github.com/wch/r-source/blob/e5b21d0397c607883ff25cca379687b86933d730/src/library/base/R/sample.R

Maybe someone else can comment more on the use cases.  I can only say for myself that I've needed this function plenty of times when working with samples that have a non uniform distribution.

----------
Added file: http://bugs.python.org/file42385/weighted_choice_v3.patch

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

From report at bugs.python.org  Wed Apr  6 18:48:05 2016
From: report at bugs.python.org (Steven Basart)
Date: Wed, 06 Apr 2016 22:48:05 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1459982885.27.0.563892993211.issue18844@psf.upfronthosting.co.za>


Changes by Steven Basart <progressive_o at yahoo.com>:


Removed file: http://bugs.python.org/file42385/weighted_choice_v4.patch

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

From report at bugs.python.org  Wed Apr  6 18:49:33 2016
From: report at bugs.python.org (Steven Basart)
Date: Wed, 06 Apr 2016 22:49:33 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1459982973.72.0.809499929741.issue18844@psf.upfronthosting.co.za>


Steven Basart added the comment:

I reuploaded the file.  The spacing on the if amount < 1 was off.  Hopefully its fixed now.

----------
Added file: http://bugs.python.org/file42386/weighted_choice_v4.patch

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

From report at bugs.python.org  Wed Apr  6 19:32:02 2016
From: report at bugs.python.org (Anthony Sottile)
Date: Wed, 06 Apr 2016 23:32:02 +0000
Subject: [issue26704] unittest.mock.patch: Double patching instance method:
 AttributeError: Mock object has no attribute '__name__'
In-Reply-To: <1459972886.32.0.234738617564.issue26704@psf.upfronthosting.co.za>
Message-ID: <1459985522.07.0.639941029072.issue26704@psf.upfronthosting.co.za>


Anthony Sottile added the comment:

Here's an improved patch which:

- passes the tests
- puts the test in the correct place

I'm not entirely happy with the approach -- open to suggestions :)

----------
Added file: http://bugs.python.org/file42387/patch2

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

From report at bugs.python.org  Wed Apr  6 20:32:35 2016
From: report at bugs.python.org (JoshN)
Date: Thu, 07 Apr 2016 00:32:35 +0000
Subject: [issue26703] Socket state corrupts when original socket object goes
 out of scope in a different thread
In-Reply-To: <1459966025.84.0.875779742702.issue26703@psf.upfronthosting.co.za>
Message-ID: <1459989155.42.0.380872594554.issue26703@psf.upfronthosting.co.za>


JoshN added the comment:

I do understand that the docs are a bit strange on the issue. For example, actually testing the line you referenced ("...fileno will return the same socket and not a duplicate.") by creating 2 sockets and testing sameness with the 'is' operator returns false.

I tried to trim the example code as much as possible - I did test disabling the garbage collector, playing with inheritance, etc, but trimmed them out as they didn't have any effect on my system.


I think my main issue was, when this occurs, the socket 'breaks' as you mentioned instead of closing. Was almost sure it was a bug. Using detach works for this UDP example, but I wasn't sure if detaching the socket actually closes it (e.g. in a stream oriented connection).

So this is considered normal behavior then?

----------

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

From report at bugs.python.org  Wed Apr  6 21:34:01 2016
From: report at bugs.python.org (John Lehr)
Date: Thu, 07 Apr 2016 01:34:01 +0000
Subject: [issue26707] plistlib fails to parse bplist with 0x80 UID values
Message-ID: <1459992841.57.0.391610307965.issue26707@psf.upfronthosting.co.za>


New submission from John Lehr:

libplist raises an invalid file exception on loading properly formed binary plists containing UID (0x80) values.  The binary files were tested for form with plutil.

Comments at line 706 state the value is defined but not in use in plists, and the object is not handled.  However, I find them frequently in bplists, e.g., iOS Snapchat application files.  I have attached a proposed patch that I have tested on these files and can now successfully parse them with the _read_object method in the _BinaryPlistParser class.

My proposed patch is pasted below for others consideration while waiting for the issue to be resolved.

706,707c706,708
<         # tokenH == 0x80 is documented as 'UID' and appears to be used for
<         # keyed-archiving, not in plists.
---
>         elif tokenH == 0x80: #UID
>             s = self._get_size(tokenL)
>             return self._fp.read(s).decode('ascii')

Thanks for your consideration.

----------
components: Library (Lib)
files: plistlib_uid.diff
keywords: patch
messages: 262974
nosy: slo.sleuth
priority: normal
severity: normal
status: open
title: plistlib fails to parse bplist with 0x80 UID values
type: crash
versions: Python 3.5
Added file: http://bugs.python.org/file42388/plistlib_uid.diff

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

From report at bugs.python.org  Wed Apr  6 21:54:02 2016
From: report at bugs.python.org (Mike Kaplinskiy)
Date: Thu, 07 Apr 2016 01:54:02 +0000
Subject: [issue26388] Disabling changing sys.argv[0] with
 runpy.run_module(...alter_sys=True)
In-Reply-To: <1455835021.39.0.133039555561.issue26388@psf.upfronthosting.co.za>
Message-ID: <1459994042.82.0.927614620319.issue26388@psf.upfronthosting.co.za>


Mike Kaplinskiy added the comment:

ping

----------

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

From report at bugs.python.org  Wed Apr  6 22:24:45 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 07 Apr 2016 02:24:45 +0000
Subject: [issue26703] Socket state corrupts when original socket object goes
 out of scope in a different thread
In-Reply-To: <1459966025.84.0.875779742702.issue26703@psf.upfronthosting.co.za>
Message-ID: <1459995885.51.0.139925107129.issue26703@psf.upfronthosting.co.za>


Martin Panter added the comment:

Yes, I think this is the expected behaviour, and I can?t think of any improvements that could be made. If you call fileno(), you have to ensure that you don?t close the file descriptor until you have finished using it. It is a bit like accessing memory after it has been freed. Python doesn?t make raw memory addresses easily accessible, but it does make fileno() accessible without much protection.

Perhaps there is some confusion about the term socket. Normally (without using the fileno=... parameter), Python?s socket() constructor does two things. First, it creates a new OS socket using the socket() system call (or Winsock equivalent), which returns a file descriptor or handle (an integer). Then, it creates a Python socket object, which wraps the file descriptor.

When you use socket(fileno=...), only the second step is taken. You get a _new_ socket object, which wraps the given existing OS socket file descriptor. So when it says ?the same socket?, I think it means the same OS-level socket. It still creates a new Python object.

----------

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

From report at bugs.python.org  Wed Apr  6 23:32:24 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 07 Apr 2016 03:32:24 +0000
Subject: [issue26388] Disabling changing sys.argv[0] with
 runpy.run_module(...alter_sys=True)
In-Reply-To: <1455835021.39.0.133039555561.issue26388@psf.upfronthosting.co.za>
Message-ID: <1459999944.87.0.270360163899.issue26388@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Thanks for the ping.

The actual code changes look OK to me for the initially proposed design, which means the main missing piece would be documentation updates (both to the docstrings and to runpy module reference).

However, thinking about how those docs might be written, I'm starting to think the specific proposed design would be inherently confusing for folks that aren't already familiar with runpy's internals, and it might be better to use a callback API with a few predefined helper functions.

That is, suppose the new parameter was a callback accepting the following parameters:

* "module" - the module about to be executed
* "argv" - sys.argv prior to module execution

And then we have 3 predefined callbacks/callback factories in runpy:

def keep_argv(module, argv):
    return argv

def set_argv0(module, argv):
    return module.__file__ + argv[1:]

def set_argv(argv, *, implicit_argv0=True):
    argv_override = list(argv)
    if implicit_argv0:
        def _set_argv(module, original_argv):
            return [module.__file__] + argv_override
    else:
        def _set_argv(module, original_argv):
            return argv_override
    return _set_argv

Then the three scenarios in your original post would look like:

    runpy.run_module(mod_name, argv=set_argv0)
    runpy.run_module(mod_name, argv=keep_argv)
    runpy.run_module(mod_name, argv=set_argv(iterable))

(and similarly for run_path)

"argv=None" would be the default, and equivalent to specifying "argv=set_argv0"

"argv=set_argv(iterable, implicit_argv0=False)" would allow even more precise control of the argv settings seen by the running module.

Future and/or custom variations would be straightforward, since we're just passing in a callable.

The documentation benefit is that the "argv" parameter docs can just describe the callback signature and the use of "set_argv0" as the default, with the details of the individual behaviours moving to the definitions of the corresponding functions.

----------

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

From report at bugs.python.org  Thu Apr  7 00:05:25 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Apr 2016 04:05:25 +0000
Subject: [issue26707] plistlib fails to parse bplist with 0x80 UID values
In-Reply-To: <1459992841.57.0.391610307965.issue26707@psf.upfronthosting.co.za>
Message-ID: <1460001925.94.0.502585799225.issue26707@psf.upfronthosting.co.za>


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


----------
nosy: +ronaldoussoren, serhiy.storchaka
type: crash -> behavior

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

From report at bugs.python.org  Thu Apr  7 02:18:17 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Apr 2016 06:18:17 +0000
Subject: [issue26708] Constify C string pointers in the posix module
Message-ID: <1460009897.32.0.801268253531.issue26708@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch adds the "const" qualifier to char and wchar_t pointers in the posix module to prevents possible bugs. These pointers point to internal data of PyBytes or PyUnicode objects or to C string literals, and unintentional changing the content is a hard bug. I expect that the patch can also eliminate some compiler warnings.

Since large part of the code is Windows specific, the patch needs to be tested on Windows.

----------
components: Extension Modules
files: posixmodule_constify.patch
keywords: patch
messages: 262978
nosy: larry, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Constify C string pointers in the posix module
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42389/posixmodule_constify.patch

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

From report at bugs.python.org  Thu Apr  7 02:33:07 2016
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 07 Apr 2016 06:33:07 +0000
Subject: [issue26708] Constify C string pointers in the posix module
In-Reply-To: <1460009897.32.0.801268253531.issue26708@psf.upfronthosting.co.za>
Message-ID: <1460010787.55.0.521111888356.issue26708@psf.upfronthosting.co.za>


Larry Hastings added the comment:

You should find a different reviewer.  I don't really care about "const".  I'll live with it if it's there but I'm not going to go around adding it.

----------

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

From report at bugs.python.org  Thu Apr  7 02:44:52 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Apr 2016 06:44:52 +0000
Subject: [issue26703] Socket state corrupts when original socket object goes
 out of scope in a different thread
In-Reply-To: <1459966025.84.0.875779742702.issue26703@psf.upfronthosting.co.za>
Message-ID: <1460011492.71.0.393410043354.issue26703@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The general answer here is you should avoid mixing calls to different abstraction layers. Either use only the file descriptor or only the socket object.

This is not limited to lifetime issues, other issues can occur. For example, setting a timeout on a socket puts the underlying file descriptor in non-blocking mode. So code using the file descriptor can fail with EAGAIN.

If you really want to use *both* a file descriptor and a socket object, you can use os.dup() on the file descriptor, so that the OS resources are truly independent.

----------

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

From report at bugs.python.org  Thu Apr  7 03:21:09 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Apr 2016 07:21:09 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1460013669.64.0.566648461725.issue18844@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> One to make it return a single number if amount == 1 and the other to check that the amount > 1.

I think that's a dangerous API. Any code making a call to "weighted_choice(..., amount=n)" for variable n now has to be prepared to deal with two possible result types. It would be easy to introduce buggy code that fails in the corner case n = 1.

----------

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

From report at bugs.python.org  Thu Apr  7 03:43:46 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Apr 2016 07:43:46 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1460015026.03.0.697693220372.issue18844@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> One to make it return a single number if amount == 1 and the other to check that the amount > 1.

Suggestion: if you want to go that way, return a single number if `amount` is not provided (so make the default value for `amount` None rather than 1). If `amount=1` is explicitly given, a list containing one item should be returned.

I also think there's no reason to raise an exception when `amount = 0`: just return an empty list.

For comparison, here's NumPy's "uniform" generator, which generates a scalar if the "size" parameter is not given, and an array if "size" is given, even if it's 1.

>>> np.random.uniform()
0.4964992470265117
>>> np.random.uniform(size=1)
array([ 0.64817717])
>>> np.random.uniform(size=0)
array([], dtype=float64)

----------

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

From report at bugs.python.org  Thu Apr  7 03:47:20 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Apr 2016 07:47:20 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1460015240.76.0.791920158192.issue18844@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Suggestion: if you want to go that way, return a single number if `amount` is not provided (so make the default value for `amount` None rather than 1). If `amount=1` is explicitly given, a list containing one item should be returned.

+1

----------

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

From report at bugs.python.org  Thu Apr  7 03:51:26 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 07 Apr 2016 07:51:26 +0000
Subject: [issue26707] plistlib fails to parse bplist with 0x80 UID values
In-Reply-To: <1459992841.57.0.391610307965.issue26707@psf.upfronthosting.co.za>
Message-ID: <1460015486.59.0.0590173416447.issue26707@psf.upfronthosting.co.za>


SilentGhost added the comment:

Here is the version of the patch suitable for the Rietveld. John, could you perhaps provide an example file that uses UID values?

Also, the code is identical to handling of 0x50 token, perhaps it could be incorporated into it.

----------
nosy: +SilentGhost
stage:  -> patch review
versions: +Python 3.6
Added file: http://bugs.python.org/file42390/issue26707.diff

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

From report at bugs.python.org  Thu Apr  7 04:46:31 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Apr 2016 08:46:31 +0000
Subject: [issue26707] plistlib fails to parse bplist with 0x80 UID values
In-Reply-To: <1459992841.57.0.391610307965.issue26707@psf.upfronthosting.co.za>
Message-ID: <1460018791.03.0.741685663284.issue26707@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

UID is rather int than bytes. And I would use a special UID type.

According to Apple's sources [1], the size of UID data is tokenL+1, not self._get_size(tokenL).

[1] http://www.opensource.apple.com/source/CF/CF-1153.18/CFBinaryPList.c

----------

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

From report at bugs.python.org  Thu Apr  7 05:46:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Apr 2016 09:46:22 +0000
Subject: [issue26709] Year 2038 problem in plistlib
Message-ID: <1460022382.4.0.161874143104.issue26709@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Plistlib fails to load dates before year 1901 and after year 2038 in binary format on platforms with 32-bit time_t.

>>> data = plistlib.dumps(datetime.datetime(1901, 1, 1), fmt=plistlib.FMT_BINARY)
>>> plistlib.loads(data)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/plistlib.py", line 1006, in loads
    fp, fmt=fmt, use_builtin_types=use_builtin_types, dict_type=dict_type)
  File "/home/serhiy/py/cpython/Lib/plistlib.py", line 997, in load
    return p.parse(fp)
  File "/home/serhiy/py/cpython/Lib/plistlib.py", line 623, in parse
    return self._read_object(self._object_offsets[top_object])
  File "/home/serhiy/py/cpython/Lib/plistlib.py", line 688, in _read_object
    return datetime.datetime.utcfromtimestamp(f + (31 * 365 + 8) * 86400)
OverflowError: timestamp out of range for platform time_t
>>> data = plistlib.dumps(datetime.datetime(2039, 1, 1), fmt=plistlib.FMT_BINARY)
>>> plistlib.loads(data)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/plistlib.py", line 1006, in loads
    fp, fmt=fmt, use_builtin_types=use_builtin_types, dict_type=dict_type)
  File "/home/serhiy/py/cpython/Lib/plistlib.py", line 997, in load
    return p.parse(fp)
  File "/home/serhiy/py/cpython/Lib/plistlib.py", line 623, in parse
    return self._read_object(self._object_offsets[top_object])
  File "/home/serhiy/py/cpython/Lib/plistlib.py", line 688, in _read_object                                                                                                                    
    return datetime.datetime.utcfromtimestamp(f + (31 * 365 + 8) * 86400)                                                                                                                      
OverflowError: timestamp out of range for platform time_t

Proposed patch fixes this issue.

----------
components: Library (Lib)
files: plistlib_large_timestamp.patch
keywords: patch
messages: 262986
nosy: belopolsky, ronaldoussoren, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Year 2038 problem in plistlib
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42391/plistlib_large_timestamp.patch

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

From report at bugs.python.org  Thu Apr  7 10:50:00 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 07 Apr 2016 14:50:00 +0000
Subject: [issue26704] unittest.mock.patch: Double patching instance method:
 AttributeError: Mock object has no attribute '__name__'
In-Reply-To: <1459972886.32.0.234738617564.issue26704@psf.upfronthosting.co.za>
Message-ID: <1460040600.27.0.808321537999.issue26704@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +michael.foord
stage:  -> patch review
type: crash -> behavior
versions:  -Python 3.4

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

From report at bugs.python.org  Thu Apr  7 10:57:02 2016
From: report at bugs.python.org (Marc Abramowitz)
Date: Thu, 07 Apr 2016 14:57:02 +0000
Subject: [issue23239] SSL match_hostname does not accept IP Address
In-Reply-To: <1421226292.77.0.451398063166.issue23239@psf.upfronthosting.co.za>
Message-ID: <1460041022.1.0.437396280395.issue23239@psf.upfronthosting.co.za>


Marc Abramowitz added the comment:

`ip_certs_comment.patch` is a simple patch that just removes the verbiage about not supporting IP addresses in hostnames, as that restriction was removed by an earlier commit from Antoine.

----------

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

From report at bugs.python.org  Thu Apr  7 11:06:31 2016
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 07 Apr 2016 15:06:31 +0000
Subject: [issue23239] SSL match_hostname does not accept IP Address
In-Reply-To: <1421226292.77.0.451398063166.issue23239@psf.upfronthosting.co.za>
Message-ID: <1460041591.44.0.724282858528.issue23239@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I'm -1 on the patch for a practical reason: The current API is broken and I don't want to have it documented as officially supported.

In fact it is not only broken but also incompatible with more modern releases of OpenSSL. Recently OpenSSL got proper implementation of hostname and IP checking. Hostname and IP must be set with different API calls:

https://www.openssl.org/docs/manmaster/crypto/X509_VERIFY_PARAM_add1_host.html
https://www.openssl.org/docs/manmaster/crypto/X509_check_host.html

----------
stage: resolved -> commit review
versions: +Python 3.6

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

From report at bugs.python.org  Thu Apr  7 11:10:26 2016
From: report at bugs.python.org (Marc Abramowitz)
Date: Thu, 07 Apr 2016 15:10:26 +0000
Subject: [issue26710] ConfigParser: Values in DEFAULT section override
 defaults passed to constructor
Message-ID: <1460041826.4.0.857287965169.issue26710@psf.upfronthosting.co.za>


New submission from Marc Abramowitz:

My expectation was that any defaults I passed to ConfigParser when creating one would override values in the DEFAULT section of the config file. This is because I'd like the DEFAULT section to have the default values, but then I want to be able to override those with settings from environment variables.

However, this is not the way it works. The defaults in the file take precedence over the defaults passed to the constructor. I didn't see a mention of this in the docs, but I might've missed it.

Take this short program (`configparsertest.py`):

```
import configparser

cp = configparser.ConfigParser({'foo': 'dog'})
print(cp.defaults())
cp.read('app.ini')
print(cp.defaults())
```

and this config file (`app.ini`):

```
[DEFAULT]
foo = bar
```

I was expecting that I would see foo equal to dog twice, but what I get is:

```
$ python configparsertest.py
OrderedDict([('foo', 'dog')])
OrderedDict([('foo', 'bar')])
```

The reason that I want the programmatic default values to override the default values in the file is that I want the file to have low-precedence defaults that are used as a last resort, and I want to be able to override the defaults with the values from environment variables.

As a concrete example, imagine that I have a config file for the stdlib `logging` module that looks something like this:

```
[DEFAULT]
logging_logger_root_level = WARN
...
[logger_root]
level = %(logging_logger_root_level)s
handlers = console
```

The desired behavior is that normally the app would use the WARN level for logging, but I'd like to be able to do something like:

```
$ LOGGING_LOGGER_ROOT_LEVEL=DEBUG python my_app.py
```

to get DEBUG logging.

Maybe there is some other mechanism to accomplish this?

----------
components: Library (Lib)
messages: 262989
nosy: Marc.Abramowitz
priority: normal
severity: normal
status: open
title: ConfigParser: Values in DEFAULT section override defaults passed to constructor
type: behavior

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

From report at bugs.python.org  Thu Apr  7 11:21:54 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 07 Apr 2016 15:21:54 +0000
Subject: [issue26710] ConfigParser: Values in DEFAULT section override
 defaults passed to constructor
In-Reply-To: <1460041826.4.0.857287965169.issue26710@psf.upfronthosting.co.za>
Message-ID: <1460042514.15.0.922523003108.issue26710@psf.upfronthosting.co.za>


SilentGhost added the comment:

You can override the level if an environmental variable was defined. Not sure why it needs to be responsibility of the ConfigParser.

While I'm not going to immediately close this issue, I don't think such a backward-incompatible proposal is viable.

----------
nosy: +SilentGhost, lukasz.langa
type: behavior -> enhancement

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

From report at bugs.python.org  Thu Apr  7 11:35:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Apr 2016 15:35:30 +0000
Subject: [issue25339] sys.stdout.errors is set to "surrogateescape"
In-Reply-To: <1444287088.0.0.588605250096.issue25339@psf.upfronthosting.co.za>
Message-ID: <1460043330.15.0.355884634552.issue25339@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What do you think about this Victor?

----------

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

From report at bugs.python.org  Thu Apr  7 11:41:54 2016
From: report at bugs.python.org (Marc Abramowitz)
Date: Thu, 07 Apr 2016 15:41:54 +0000
Subject: [issue26710] ConfigParser: Values in DEFAULT section override
 defaults passed to constructor
In-Reply-To: <1460041826.4.0.857287965169.issue26710@psf.upfronthosting.co.za>
Message-ID: <1460043714.38.0.358477782064.issue26710@psf.upfronthosting.co.za>


Marc Abramowitz added the comment:

Some more info on the logging example I gave.

So here is a program called `my_app.py`:

```
import os
import logging.config

logging.config.fileConfig('logging.ini', defaults=os.environ)
logger = logging.getLogger(__name__)
logger.debug('debug msg')
logger.info('info msg')
logger.warn('warn msg')
logger.error('error msg')
root_logger = logging.getLogger()
print('root_logger.level = %d; logging.WARN = %d; logging.DEBUG = %d'
      % (root_logger.level, logging.WARN, logging.DEBUG))
```

Note that it calls logging.config.fileConfig with defaults=os.environ so that environment variables can be used to affect the logging configuration.


And here is `logging.ini`:

```
###
# logging configuration
# http://docs.pylonsproject.org/projects/pyramid/en/1.7-branch/narr/logging.html
###

[loggers]
keys = root, fakeproject, sqlalchemy

[handlers]
keys = console

[formatters]
keys = generic

[logger_root]
level = %(logging_logger_root_level)s
handlers = console

[logger_fakeproject]
level = DEBUG
handlers =
qualname = fakeproject

[logger_sqlalchemy]
level = INFO
handlers =
qualname = sqlalchemy.engine
# "level = INFO" logs SQL queries.
# "level = DEBUG" logs SQL queries and results.
# "level = WARN" logs neither.  (Recommended for production systems.)

[handler_console]
class = StreamHandler
args = (sys.stderr,)
level = NOTSET
formatter = generic

[formatter_generic]
format = %(asctime)s %(levelname)-5.5s [%(name)s:%(lineno)s][%(threadName)s] %(message)s
```

Note that in the `logger_root` section of `logging.ini`, the variable `logging_logger_root_level` is referenced but not defined. For now, we are going to rely on getting that from an environment variable.


If I provide an environment variable when running the program:

```
$ LOGGING_LOGGER_ROOT_LEVEL=DEBUG python my_app.py
2016-04-07 08:26:36,184 DEBUG [__main__:6][MainThread] debug msg
2016-04-07 08:26:36,184 INFO  [__main__:7][MainThread] info msg
2016-04-07 08:26:36,184 WARNI [__main__:8][MainThread] warn msg
2016-04-07 08:26:36,184 ERROR [__main__:9][MainThread] error msg
root_logger.level = 10; logging.WARN = 30; logging.DEBUG = 10
```

then it works and the root logger level is DEBUG as expected. Great!

But what happens if the user leaves out the environment variable?

```
$ python my_app.py
Traceback (most recent call last):
  File "my_app.py", line 4, in <module>
    logging.config.fileConfig('logging.ini', defaults=os.environ)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/logging/config.py", line 86, in fileConfig
    _install_loggers(cp, handlers, disable_existing_loggers)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/logging/config.py", line 196, in _install_loggers
    level = cp.get(sectname, "level")
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ConfigParser.py", line 623, in get
    return self._interpolate(section, option, value, d)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ConfigParser.py", line 669, in _interpolate
    option, section, rawval, e.args[0])
ConfigParser.InterpolationMissingOptionError: Bad value substitution:
	section: [logger_root]
	option : level
	key    : logging_logger_root_level
	rawval : %(logging_logger_root_level)s
```

An error occurs as expected. 

But I'd like to be able to provide a default value so that user doesn't have to set the environment variable, so let's add this to the top of `logging.ini`:

```
[DEFAULT]
logging_logger_root_level = WARN
```

Now let's run the program again without the environment variable to see if that fixed the problem:

```
$ python my_app.py
2016-04-07 08:33:07,101 WARNI [__main__:8][MainThread] warn msg
2016-04-07 08:33:07,101 ERROR [__main__:9][MainThread] error msg
root_logger.level = 30; logging.WARN = 30; logging.DEBUG = 10
```

Awesome! It worked and set the root logger level to the default of WARN, as expected.

Now what happens if we try to override the default with an environment variable?

```
$ LOGGING_LOGGER_ROOT_LEVEL=DEBUG python my_app.py
2016-04-07 08:33:56,047 WARNI [__main__:8][MainThread] warn msg
2016-04-07 08:33:56,048 ERROR [__main__:9][MainThread] error msg
root_logger.level = 30; logging.WARN = 30; logging.DEBUG = 10
```

Doh! The root logger level is still WARN. So the default in the ini file took precedence over what the user provided. This is unfortunate.

So how does one provide defaults while also allowing overriding those defaults?

----------

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

From report at bugs.python.org  Thu Apr  7 11:43:22 2016
From: report at bugs.python.org (Marc Abramowitz)
Date: Thu, 07 Apr 2016 15:43:22 +0000
Subject: [issue26710] ConfigParser: Values in DEFAULT section override
 defaults passed to constructor
In-Reply-To: <1460041826.4.0.857287965169.issue26710@psf.upfronthosting.co.za>
Message-ID: <1460043802.67.0.0464524688418.issue26710@psf.upfronthosting.co.za>


Marc Abramowitz added the comment:

So I think changing the behavior of `defaults` might break backwards compatibility for folks who are relying on the old behavior.

So I guess I would propose adding a new parameter called `overrides`. These would take precedence over `defaults` and that allows retaining backwards compatibility.

----------

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

From report at bugs.python.org  Thu Apr  7 12:23:32 2016
From: report at bugs.python.org (Steven Basart)
Date: Thu, 07 Apr 2016 16:23:32 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1460046212.22.0.351681869848.issue18844@psf.upfronthosting.co.za>


Steven Basart added the comment:

Re-implemented with suggested improvements taken into account. Thanks @mark.dickinson and @pitrou for the suggestions.  

I also removed the redundant "fast path" portion for this code since it doesn't deal with generators anyways.

Let me know additional thoughts about it.

----------
Added file: http://bugs.python.org/file42392/weighted_choice_v5.patch

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

From report at bugs.python.org  Thu Apr  7 12:24:47 2016
From: report at bugs.python.org (Steven Basart)
Date: Thu, 07 Apr 2016 16:24:47 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1460046287.55.0.651355789405.issue18844@psf.upfronthosting.co.za>


Changes by Steven Basart <progressive_o at yahoo.com>:


Removed file: http://bugs.python.org/file42392/weighted_choice_v5.patch

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

From report at bugs.python.org  Thu Apr  7 12:25:19 2016
From: report at bugs.python.org (Steven Basart)
Date: Thu, 07 Apr 2016 16:25:19 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1460046319.92.0.75746078472.issue18844@psf.upfronthosting.co.za>


Steven Basart added the comment:

Left in a line of code that was supposed to be removed. Fixed.

----------
Added file: http://bugs.python.org/file42393/weighted_choice_v5.patch

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

From report at bugs.python.org  Thu Apr  7 12:45:46 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 07 Apr 2016 16:45:46 +0000
Subject: [issue26698] Tk DPI awareness
In-Reply-To: <1459911228.34.0.00983454800259.issue26698@psf.upfronthosting.co.za>
Message-ID: <1460047546.53.0.771245333349.issue26698@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This is not an IDLE issue, and probably not a tkinter issue.  The display of characters on a screen is done by the OS font software under direction of tcl/tk.

What OS are you running and what version of Tk (see IDLE -> Help -> About IDLE)?

----------
components:  -IDLE, Library (Lib)
nosy: +wordtech -kbk, roger.serwy
title: IDLE DPI Awareness -> Tk DPI awareness

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

From report at bugs.python.org  Thu Apr  7 13:55:06 2016
From: report at bugs.python.org (skydoom)
Date: Thu, 07 Apr 2016 17:55:06 +0000
Subject: [issue26693] Exception ignored in: <module 'threading' from
 ...threading.py> in _shutdown, assert tlock.locked()
In-Reply-To: <1459821105.82.0.884891417565.issue26693@psf.upfronthosting.co.za>
Message-ID: <1460051706.01.0.474388417893.issue26693@psf.upfronthosting.co.za>


skydoom added the comment:

It looks like there is a bug in the _shutdown function of threading.py, that it does not check whether the _main_thread.is_alive() or not.  My temporary fix is to add the following checking in the beginning of _shutdown and it seems no more error message pop up:

if( _main_thread.is_active() is False ):
  return

Please see if this makes sense.

----------

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

From report at bugs.python.org  Thu Apr  7 14:02:52 2016
From: report at bugs.python.org (skydoom)
Date: Thu, 07 Apr 2016 18:02:52 +0000
Subject: [issue26693] Exception ignored in: <module 'threading' from
 ...threading.py> in _shutdown, assert tlock.locked()
In-Reply-To: <1459821105.82.0.884891417565.issue26693@psf.upfronthosting.co.za>
Message-ID: <1460052172.13.0.859637497637.issue26693@psf.upfronthosting.co.za>


skydoom added the comment:

sorry typo above, is_active should be read as is_alive.

----------

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

From report at bugs.python.org  Thu Apr  7 14:14:10 2016
From: report at bugs.python.org (John Lehr)
Date: Thu, 07 Apr 2016 18:14:10 +0000
Subject: [issue26707] plistlib fails to parse bplist with 0x80 UID values
In-Reply-To: <1460015486.59.0.0590173416447.issue26707@psf.upfronthosting.co.za>
Message-ID: <238DD4AD-B354-4BD8-92F8-2DBEF1062CB8@gmail.com>


John Lehr added the comment:

I?m sorry, but the files in which I detected the problem cannot be circulated.  I will try to create a test account on Snapchat and generate some test data, but I can?t do this anytime soon.

> On Apr 7, 2016, at 12:51 AM, SilentGhost <report at bugs.python.org> wrote:
> 
> 
> SilentGhost added the comment:
> 
> Here is the version of the patch suitable for the Rietveld. John, could you perhaps provide an example file that uses UID values?
> 
> Also, the code is identical to handling of 0x50 token, perhaps it could be incorporated into it.
> 
> ----------
> nosy: +SilentGhost
> stage:  -> patch review
> versions: +Python 3.6
> Added file: http://bugs.python.org/file42390/issue26707.diff
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue26707>
> _______________________________________

----------

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

From report at bugs.python.org  Thu Apr  7 14:15:55 2016
From: report at bugs.python.org (John Lehr)
Date: Thu, 07 Apr 2016 18:15:55 +0000
Subject: [issue26707] plistlib fails to parse bplist with 0x80 UID values
In-Reply-To: <1460018791.03.0.741685663284.issue26707@psf.upfronthosting.co.za>
Message-ID: <EFA998E8-C58C-4640-8D9F-98DAE76A8347@gmail.com>


John Lehr added the comment:

I?m glad you found it in the Apple specification.  I looked, but missed it.  I would absolutely defer to you on your assessment of the decoding.

> On Apr 7, 2016, at 1:46 AM, Serhiy Storchaka <report at bugs.python.org> wrote:
> 
> 
> Serhiy Storchaka added the comment:
> 
> UID is rather int than bytes. And I would use a special UID type.
> 
> According to Apple's sources [1], the size of UID data is tokenL+1, not self._get_size(tokenL).
> 
> [1] http://www.opensource.apple.com/source/CF/CF-1153.18/CFBinaryPList.c
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue26707>
> _______________________________________

----------

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

From report at bugs.python.org  Thu Apr  7 15:39:45 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Apr 2016 19:39:45 +0000
Subject: [issue26707] plistlib fails to parse bplist with 0x80 UID values
In-Reply-To: <1459992841.57.0.391610307965.issue26707@psf.upfronthosting.co.za>
Message-ID: <1460057985.85.0.226000806403.issue26707@psf.upfronthosting.co.za>


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


----------
assignee:  -> ronaldoussoren

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

From report at bugs.python.org  Thu Apr  7 16:06:42 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Apr 2016 20:06:42 +0000
Subject: [issue26711] Fix comparison of plistlib.Data
Message-ID: <1460059602.28.0.307914137302.issue26711@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes several bugs in plistlib.Data.__eq__().

* isinstance(other, str) was used instead of isinstance(other, bytes). Data always wraps bytes and should be comparable with bytes. str was correct type in Python 2.

* id(self) == id(other) is always false, because if other is self, the first condition (isinstance(other, self.__class__)) should be true. NotImplemented should be returned as fallback. This allows comparing with Data subclasses and correct work of __ne__().

* The __eq__() method should be used instead of the equality operator. This is needed for correct work in case if value is bytes subclass with overloaded __eq__().

----------
components: Library (Lib)
files: plistlib_data_eq.patch
keywords: patch
messages: 263001
nosy: ronaldoussoren, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix comparison of plistlib.Data
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42394/plistlib_data_eq.patch

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

From report at bugs.python.org  Thu Apr  7 16:16:51 2016
From: report at bugs.python.org (Mike Miller)
Date: Thu, 07 Apr 2016 20:16:51 +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: <1460060211.92.0.990163475873.issue25320@psf.upfronthosting.co.za>


Mike Miller added the comment:

Just as a side note, the patch also works for soft links that point to files that don't exist. Thanks for getting this fixed!

----------
nosy: +Mike Miller

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

From report at bugs.python.org  Thu Apr  7 16:54:10 2016
From: report at bugs.python.org (John Lehr)
Date: Thu, 07 Apr 2016 20:54:10 +0000
Subject: [issue26707] plistlib fails to parse bplist with 0x80 UID values
In-Reply-To: <1459992841.57.0.391610307965.issue26707@psf.upfronthosting.co.za>
Message-ID: <1460062450.68.0.336143566645.issue26707@psf.upfronthosting.co.za>


John Lehr added the comment:

Based on the format specification pointed to by Serhiy, perhaps this a better patch, correcting size from previous patch submission and treating:

706,707c706,708
<         # tokenH == 0x80 is documented as 'UID' and appears to be used for
<         # keyed-archiving, not in plists.
---
>         elif tokenH == 0x80:  # UID
>             s = self._get_size(tokenL + 1)
>             return int.from_bytes(self._fp.read(s), 'big')

I have compared output with OS X plutil and plistlib.load() with this patch and the values are identical for UID fields.

----------
Added file: http://bugs.python.org/file42395/plistlib_uid.diff

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

From report at bugs.python.org  Thu Apr  7 22:13:56 2016
From: report at bugs.python.org (Eric Khoo Jiun Hooi)
Date: Fri, 08 Apr 2016 02:13:56 +0000
Subject: [issue23551] IDLE to provide menu link to PIP gui.
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1460081636.3.0.294042576974.issue23551@psf.upfronthosting.co.za>


Eric Khoo Jiun Hooi added the comment:

The search button of search tab still not done yet, so it still cannot be used now

----------
Added file: http://bugs.python.org/file42396/pip_gui_v5.py

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

From report at bugs.python.org  Fri Apr  8 01:10:04 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 08 Apr 2016 05:10:04 +0000
Subject: [issue26671] Clean up path_converter in posixmodule.c
In-Reply-To: <1459330274.5.0.616265410958.issue26671@psf.upfronthosting.co.za>
Message-ID: <1460092204.6.0.450839681471.issue26671@psf.upfronthosting.co.za>


Martin Panter added the comment:

Looks like the tests may need updating for a changed exception message:

http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/12996/steps/test/logs/stdio
======================================================================
FAIL: test_stat (test.test_posix.PosixTester)
----------------------------------------------------------------------
TypeError: stat: path should be string, bytes or integer, not NoneType

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_posix.py", line 415, in test_stat
    posix.stat, None)
AssertionError: "can't specify None for path argument" does not match "stat: path should be string, bytes or integer, not NoneType"

======================================================================
FAIL: test_stat_dir_fd (test.test_posix.PosixTester)
----------------------------------------------------------------------
TypeError: argument should be integer or None, not str

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_posix.py", line 867, in test_stat_dir_fd
    posix.stat, support.TESTFN, dir_fd=posix.getcwd())
AssertionError: "should be integer, not" does not match "argument should be integer or None, not str"

----------
nosy: +martin.panter
status: closed -> open

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

From report at bugs.python.org  Fri Apr  8 01:32:36 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 08 Apr 2016 05:32:36 +0000
Subject: [issue26257] Eliminate buffer_tests.py
In-Reply-To: <1454323795.43.0.12298865479.issue26257@psf.upfronthosting.co.za>
Message-ID: <20160408053232.30035.51566.F4C016C7@psf.io>


Roundup Robot added the comment:

New changeset 197e1f8b28b7 by Martin Panter in branch '3.5':
Issue #26257: Eliminate buffer_tests.py and fix ByteArrayAsStringTest
https://hg.python.org/cpython/rev/197e1f8b28b7

New changeset ea598d69b7d3 by Martin Panter in branch 'default':
Issue #26257: Merge buffer_tests cleanup from 3.5
https://hg.python.org/cpython/rev/ea598d69b7d3

New changeset 26f1543e806c by Martin Panter in branch '2.7':
Issue #26257: Eliminate buffer_tests.py and fix ByteArrayAsStringTest
https://hg.python.org/cpython/rev/26f1543e806c

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

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

From report at bugs.python.org  Fri Apr  8 01:48:50 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 08 Apr 2016 05:48:50 +0000
Subject: [issue26671] Clean up path_converter in posixmodule.c
In-Reply-To: <1459330274.5.0.616265410958.issue26671@psf.upfronthosting.co.za>
Message-ID: <20160408054846.125085.76612.3E513ADD@psf.io>


Roundup Robot added the comment:

New changeset 633bb190fb76 by Serhiy Storchaka in branch 'default':
Issue #26671: Fixed tests for changed error messages.
https://hg.python.org/cpython/rev/633bb190fb76

----------

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

From report at bugs.python.org  Fri Apr  8 01:49:25 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 08 Apr 2016 05:49:25 +0000
Subject: [issue26671] Clean up path_converter in posixmodule.c
In-Reply-To: <1459330274.5.0.616265410958.issue26671@psf.upfronthosting.co.za>
Message-ID: <1460094565.62.0.30551147373.issue26671@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Martin.

----------
status: open -> closed

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

From report at bugs.python.org  Fri Apr  8 03:00:16 2016
From: report at bugs.python.org (JoshN)
Date: Fri, 08 Apr 2016 07:00:16 +0000
Subject: [issue26703] Socket state corrupts when original socket object goes
 out of scope in a different thread
In-Reply-To: <1459966025.84.0.875779742702.issue26703@psf.upfronthosting.co.za>
Message-ID: <1460098816.78.0.286142885167.issue26703@psf.upfronthosting.co.za>


JoshN added the comment:

Josh/Martin/Antoine: Thank you for the tips - I was not aware of the underlying mechanics, especially the separate abstraction layers.

I did RTFM up and down before posting this, to be sure. My apologies for the inconvenience.

----------

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

From report at bugs.python.org  Fri Apr  8 04:58:54 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Apr 2016 08:58:54 +0000
Subject: [issue26703] Socket state corrupts when original socket object goes
 out of scope in a different thread
In-Reply-To: <1459966025.84.0.875779742702.issue26703@psf.upfronthosting.co.za>
Message-ID: <1460105934.32.0.211176573565.issue26703@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

No need to apologize :) Perhaps we need to make the docs a bit clearer.

----------

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

From report at bugs.python.org  Fri Apr  8 05:02:55 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 08 Apr 2016 09:02:55 +0000
Subject: [issue26712] Unify (r)split(), (l/r)strip() method tests
Message-ID: <1460106175.71.0.116518416175.issue26712@psf.upfronthosting.co.za>


New submission from Martin Panter:

This follows on from Issue 26257, where I moved tests for these string/bytes methods into a more common class. So this patch merges and removes some existing tests from test_bytes.py that cover the same ground. I copied a couple tests to the common class that tend to test negative and degenerate cases, which the original common tests were weak on.

----------
components: Tests
files: split-strip.patch
keywords: patch
messages: 263011
nosy: martin.panter, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Unify (r)split(), (l/r)strip() method tests
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42397/split-strip.patch

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

From report at bugs.python.org  Fri Apr  8 05:37:07 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 08 Apr 2016 09:37:07 +0000
Subject: [issue25339] sys.stdout.errors is set to "surrogateescape"
In-Reply-To: <1444287088.0.0.588605250096.issue25339@psf.upfronthosting.co.za>
Message-ID: <1460108227.04.0.42648387389.issue25339@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I believe the problem may be that we can't readily tell the difference between "PYTHONIOENCODING=ascii" and "PYTHONIOENCODING=ascii:strict", and in the former case we'd ideally still end up using "surrogateescape" by default.

That said, the real intent of the change was "If the detected encoding is ASCII, enable surrogateescape automatically", and detecting the POSIX locale was a proxy for that. We didn't account for PYTHONIOENCODING being used to select a more sensible encoding.

----------

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

From report at bugs.python.org  Fri Apr  8 05:56:53 2016
From: report at bugs.python.org (Erwin Mayer)
Date: Fri, 08 Apr 2016 09:56:53 +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: <1460109413.03.0.471130587404.issue18820@psf.upfronthosting.co.za>


Erwin Mayer added the comment:

Will this be merged? I also believe it is an unexpected behavior to not serialize dictionary keys when the default option is used.

----------
nosy: +Erwin Mayer

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

From report at bugs.python.org  Fri Apr  8 06:02:16 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 08 Apr 2016 10:02:16 +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: <1460109736.14.0.827361654426.issue18820@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> 
components:  -Documentation
versions:  -Python 3.4

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

From report at bugs.python.org  Fri Apr  8 06:06:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 08 Apr 2016 10:06:39 +0000
Subject: [issue26712] Unify (r)split(), (l/r)strip() method tests
In-Reply-To: <1460106175.71.0.116518416175.issue26712@psf.upfronthosting.co.za>
Message-ID: <1460109999.04.0.680036889241.issue26712@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added comments on Rietveld.

----------

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

From report at bugs.python.org  Fri Apr  8 06:46:09 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 08 Apr 2016 10:46:09 +0000
Subject: [issue25339] sys.stdout.errors is set to "surrogateescape"
In-Reply-To: <1444287088.0.0.588605250096.issue25339@psf.upfronthosting.co.za>
Message-ID: <1460112369.78.0.351601508503.issue25339@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Making "PYTHONIOENCODING=ascii" to mean "PYTHONIOENCODING=ascii:surrogateescape" is different (and may be more complex) issue. What error handler should use open(name, encoding='ascii')? open(name) in POSIX locale?

This issue is about incorrect working of PYTHONIOENCODING in POSIX locale.

----------

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

From report at bugs.python.org  Fri Apr  8 06:53:28 2016
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 08 Apr 2016 10:53:28 +0000
Subject: [issue26707] plistlib fails to parse bplist with 0x80 UID values
In-Reply-To: <1459992841.57.0.391610307965.issue26707@psf.upfronthosting.co.za>
Message-ID: <1460112808.59.0.67435675498.issue26707@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

How can you create plist files that contain UID values using Apple's APIs?

The plist library is meant to be interoperable with files created using Apple's APIs for creating plist files, and I didn't find an API that created UID values at the time.

----------

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

From report at bugs.python.org  Fri Apr  8 06:54:26 2016
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 08 Apr 2016 10:54:26 +0000
Subject: [issue26709] Year 2038 problem in plistlib
In-Reply-To: <1460022382.4.0.161874143104.issue26709@psf.upfronthosting.co.za>
Message-ID: <1460112866.19.0.148597714485.issue26709@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

Patch looks good to me.

----------

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

From report at bugs.python.org  Fri Apr  8 06:56:56 2016
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 08 Apr 2016 10:56:56 +0000
Subject: [issue26711] Fix comparison of plistlib.Data
In-Reply-To: <1460059602.28.0.307914137302.issue26711@psf.upfronthosting.co.za>
Message-ID: <1460113016.8.0.97240612721.issue26711@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

I don't understand the explicit use of __eq__ in the bytes case. Why is that needed?

----------

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

From report at bugs.python.org  Fri Apr  8 07:01:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 08 Apr 2016 11:01:10 +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: <1460113270.07.0.660647406947.issue18820@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also

https://github.com/simplejson/simplejson/issues/42
https://github.com/simplejson/simplejson/issues/100
https://github.com/simplejson/simplejson/issues/103

And allowing non-string keys leads to other issue:

https://github.com/simplejson/simplejson/issues/77

Thus there is an argument for disallowing serializing non-string keys.

----------
nosy: +bob.ippolito, serhiy.storchaka

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

From report at bugs.python.org  Fri Apr  8 07:24:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 08 Apr 2016 11:24:19 +0000
Subject: [issue26711] Fix comparison of plistlib.Data
In-Reply-To: <1460059602.28.0.307914137302.issue26711@psf.upfronthosting.co.za>
Message-ID: <1460114659.45.0.149207937372.issue26711@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

>>> import plistlib
>>> class MyData(bytes):
...     def __eq__(self, other):
...         if isinstance(other, plistlib.Data):
...             return super().__eq__(other.value)
...         return False
... 
>>> plistlib.Data(b'x') == MyData(b'x')
True

If use the equality operator the result is False.

I don't know if this is good example. In any case this is corner case and we can manage with "==".

----------

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

From report at bugs.python.org  Fri Apr  8 07:44:01 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 08 Apr 2016 11:44:01 +0000
Subject: [issue26711] Fix comparison of plistlib.Data
In-Reply-To: <1460059602.28.0.307914137302.issue26711@psf.upfronthosting.co.za>
Message-ID: <1460115841.14.0.157638103253.issue26711@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file42398/plistlib_data_eq_2.patch

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

From report at bugs.python.org  Fri Apr  8 07:53:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 08 Apr 2016 11:53:19 +0000
Subject: [issue26707] plistlib fails to parse bplist with 0x80 UID values
In-Reply-To: <1459992841.57.0.391610307965.issue26707@psf.upfronthosting.co.za>
Message-ID: <1460116399.04.0.161664687916.issue26707@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The size of UID data is just tokenL + 1, not self._get_size(tokenL + 1).

FYI, the code for support UIDs and other types was proposed in issue14455, but was excluded from the final patch.

----------

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

From report at bugs.python.org  Fri Apr  8 08:01:05 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 08 Apr 2016 12:01:05 +0000
Subject: [issue26709] Year 2038 problem in plistlib
In-Reply-To: <1460022382.4.0.161874143104.issue26709@psf.upfronthosting.co.za>
Message-ID: <20160408120050.21698.50526.7AE574A1@psf.io>


Roundup Robot added the comment:

New changeset ba35b0404163 by Serhiy Storchaka in branch '3.5':
Issue #26709: Fixed Y2038 problem in loading binary PLists.
https://hg.python.org/cpython/rev/ba35b0404163

New changeset 778ccbe3cf74 by Serhiy Storchaka in branch 'default':
Issue #26709: Fixed Y2038 problem in loading binary PLists.
https://hg.python.org/cpython/rev/778ccbe3cf74

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

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

From report at bugs.python.org  Fri Apr  8 08:06:41 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 08 Apr 2016 12:06:41 +0000
Subject: [issue26709] Year 2038 problem in plistlib
In-Reply-To: <1460022382.4.0.161874143104.issue26709@psf.upfronthosting.co.za>
Message-ID: <1460117201.62.0.571986664091.issue26709@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks Ronald.

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

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

From report at bugs.python.org  Fri Apr  8 08:08:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 08 Apr 2016 12:08:39 +0000
Subject: [issue22993] Plistlib fails on certain valid plist values
In-Reply-To: <1417674874.83.0.611673896272.issue22993@psf.upfronthosting.co.za>
Message-ID: <1460117319.93.0.991124476067.issue22993@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

An issue with out of range timestamps was resolved in issue26709.

----------

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

From report at bugs.python.org  Fri Apr  8 08:41:34 2016
From: report at bugs.python.org (Erwin Mayer)
Date: Fri, 08 Apr 2016 12:41:34 +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: <1460119294.28.0.857451806495.issue18820@psf.upfronthosting.co.za>


Erwin Mayer added the comment:

Regarding the issues mentioned in https://github.com/simplejson/simplejson/issues/77, they already apply with the current implementation anyway (true is serialized as 'true'), so users must already be careful.

The JSONEncoder with default parameters could definitely keep rejecting complex keys, but an optional 'encode_complex_keys=False' parameter could be added to __init__ to provide this functionality. There would be zero performance impact as the parameter check would only be done if all else has failed instead of raising the TypeError (the same way _skipkeys does).

In that respect, the patch of this issue would need to be amended (and the C version would also need to be changed).

I am trying to fork the json core module to achieve this (to not have to wait for the next Python release, assuming it gets implemented), if you are familiar with the packaging process of core modules into standalone modules, your advice would be much appreciated (and could well help others contribute to Python):
http://stackoverflow.com/questions/36498527/how-to-create-a-customized-version-of-a-core-python-module-that-includes-c-code

----------

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

From report at bugs.python.org  Fri Apr  8 10:10:35 2016
From: report at bugs.python.org (skydoom)
Date: Fri, 08 Apr 2016 14:10:35 +0000
Subject: [issue26693] Exception ignored in: <module 'threading' from
 ...threading.py> in _shutdown, assert tlock.locked()
In-Reply-To: <1459821105.82.0.884891417565.issue26693@psf.upfronthosting.co.za>
Message-ID: <1460124635.01.0.543540221384.issue26693@psf.upfronthosting.co.za>


Changes by skydoom <skydoom at 163.com>:


----------
nosy: +pitrou

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

From report at bugs.python.org  Fri Apr  8 10:53:50 2016
From: report at bugs.python.org (flying sheep)
Date: Fri, 08 Apr 2016 14:53:50 +0000
Subject: =?utf-8?q?=5Bissue26713=5D_Change_f-literal_grammar_so_that_escaping_isn?=
 =?utf-8?q?=E2=80=99t_possible_or_necessary?=
Message-ID: <1460127230.9.0.116557671628.issue26713@psf.upfronthosting.co.za>


New submission from flying sheep:

code inside of the braces of an f-literal should have the exact same lexing rules than outside *except* for an otherwise unparsable !, :, or } signifying the end of the replacement field

1. every other language with template literals has it that way
2. it makes sense that the content of the f-literal is a ?hole? in which normal code goes until a !, : or } signifies its end
3. escaping code that will be evaluated reeks of ?eval? even though it isn?t

as it is now, it?s very confusing as the contents are neither code nor string content.

that might be one reason why many people get it wrong and think it can be stored unevaluatedly and thus provides a security risk (which is obv. wrong)

the whole section after ?A consequence of sharing the same syntax as regular string literals is?? has to be removed and made unnecessary by allowing everything otherwise legal inside.

e.g. f'spam{(lambda: 1)():<4}' would be legal and be exactly the same as '{:<4}'.format((lambda: 1)())

----------
messages: 263026
nosy: flying sheep
priority: normal
severity: normal
status: open
title: Change f-literal grammar so that escaping isn?t possible or necessary

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

From report at bugs.python.org  Fri Apr  8 10:54:09 2016
From: report at bugs.python.org (flying sheep)
Date: Fri, 08 Apr 2016 14:54:09 +0000
Subject: =?utf-8?q?=5Bissue26713=5D_Change_f-literal_grammar_so_that_escaping_isn?=
 =?utf-8?q?=E2=80=99t_possible_or_necessary?=
In-Reply-To: <1460127230.9.0.116557671628.issue26713@psf.upfronthosting.co.za>
Message-ID: <1460127249.52.0.970632696188.issue26713@psf.upfronthosting.co.za>


Changes by flying sheep <flying-sheep at web.de>:


----------
type:  -> behavior
versions: +Python 3.6

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

From report at bugs.python.org  Fri Apr  8 10:54:29 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 08 Apr 2016 14:54:29 +0000
Subject: =?utf-8?q?=5Bissue26713=5D_Change_f-literal_grammar_so_that_escaping_isn?=
 =?utf-8?q?=E2=80=99t_possible_or_necessary?=
In-Reply-To: <1460127230.9.0.116557671628.issue26713@psf.upfronthosting.co.za>
Message-ID: <1460127269.77.0.0609768677109.issue26713@psf.upfronthosting.co.za>


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


----------
nosy: +eric.smith

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

From report at bugs.python.org  Fri Apr  8 11:27:37 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Apr 2016 15:27:37 +0000
Subject: =?utf-8?q?=5Bissue26713=5D_Change_f-literal_grammar_so_that_escaping_isn?=
 =?utf-8?q?=E2=80=99t_possible_or_necessary?=
In-Reply-To: <1460127230.9.0.116557671628.issue26713@psf.upfronthosting.co.za>
Message-ID: <1460129257.06.0.543813007509.issue26713@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is not a topic appropriate for the bug tracker.  Please bring it up on python-ideas, after reviewing the PEP (which probably addresses the reason the design is the way it is, but there may be additional concerns that arise from practical experience with the results).

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Apr  8 13:06:32 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 08 Apr 2016 17:06:32 +0000
Subject: [issue18461] X Error in tkinter
In-Reply-To: <1373895500.91.0.409503402666.issue18461@psf.upfronthosting.co.za>
Message-ID: <1460135192.43.0.480469391587.issue18461@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Opened Tk ticket: http://core.tcl.tk/tk/tktview/bffa794b1b50745e0cf81c860b0bcbf36ccfb21a .

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Apr  8 13:28:24 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 08 Apr 2016 17:28:24 +0000
Subject: =?utf-8?q?=5Bissue26713=5D_Change_f-literal_grammar_so_that_escaping_isn?=
 =?utf-8?q?=E2=80=99t_possible_or_necessary?=
In-Reply-To: <1460127230.9.0.116557671628.issue26713@psf.upfronthosting.co.za>
Message-ID: <1460136504.32.0.624261257545.issue26713@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I agree with David here, this isn't a bug tracker level issue.

But, to the specifics of your example, it already works:

Python 3.6.0a0 (default:9095a5787a82+, Feb  5 2016, 18:24:55) 
[GCC 5.2.1 20151010] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> f'spam{(lambda: 1)():<4}'
'spam1   '
>>> 

The section of the docs you cited is only talking about single quotes, double quotes, escaped quotes, triple quotes and the like.

So I'm not clear what changes you'd be proposing. If you bring this up on python-ideas, please be specific about what you'd change.

Thanks!

----------

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

From report at bugs.python.org  Fri Apr  8 13:40:20 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Apr 2016 17:40:20 +0000
Subject: =?utf-8?q?=5Bissue26713=5D_Change_f-literal_grammar_so_that_escaping_isn?=
 =?utf-8?q?=E2=80=99t_possible_or_necessary?=
In-Reply-To: <1460127230.9.0.116557671628.issue26713@psf.upfronthosting.co.za>
Message-ID: <1460137220.32.0.754557113566.issue26713@psf.upfronthosting.co.za>


R. David Murray added the comment:

If it turns out it is just a doc issue we can reopen this to address that.

----------

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

From report at bugs.python.org  Fri Apr  8 13:44:51 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 08 Apr 2016 17:44:51 +0000
Subject: [issue26714] telnetlib.Telnet should act as a context manager
Message-ID: <1460137491.63.0.283583119898.issue26714@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

Telnet instances should support the context manager protocol so they can be used in with statements.

>>> import telnetlib
>>> with telnetlib.Telnet('192.168.86.7') as tn:
...   pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: __exit__

----------
components: Library (Lib)
keywords: easy
messages: 263031
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: telnetlib.Telnet should act as a context manager
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Fri Apr  8 13:47:19 2016
From: report at bugs.python.org (Min RK)
Date: Fri, 08 Apr 2016 17:47:19 +0000
Subject: [issue25544] cleanup temporary files in distutils.has_function
In-Reply-To: <1446560146.63.0.814875607484.issue25544@psf.upfronthosting.co.za>
Message-ID: <1460137639.04.0.505125125256.issue25544@psf.upfronthosting.co.za>


Min RK added the comment:

update patch to use file context manager on temporary source file

it should apply cleanly on current default (778ccbe3cf74)

----------
Added file: http://bugs.python.org/file42399/0001-cleanup-tempfiles-in-has_function.patch

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

From report at bugs.python.org  Fri Apr  8 14:00:07 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 08 Apr 2016 18:00:07 +0000
Subject: [issue25544] cleanup temporary files in distutils.has_function
In-Reply-To: <1446560146.63.0.814875607484.issue25544@psf.upfronthosting.co.za>
Message-ID: <1460138407.45.0.485312919688.issue25544@psf.upfronthosting.co.za>


SilentGhost added the comment:

Here is the review-able patch.

----------
Added file: http://bugs.python.org/file42400/minrk_issue25544.diff

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

From report at bugs.python.org  Fri Apr  8 14:33:40 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Apr 2016 18:33:40 +0000
Subject: [issue21048] Index 'as' in import and with statements
In-Reply-To: <1395638558.42.0.404654056681.issue21048@psf.upfronthosting.co.za>
Message-ID: <1460140420.6.0.76454137764.issue21048@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Three

----------

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

From report at bugs.python.org  Fri Apr  8 14:40:14 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 08 Apr 2016 18:40:14 +0000
Subject: [issue26714] telnetlib.Telnet should act as a context manager
In-Reply-To: <1460137491.63.0.283583119898.issue26714@psf.upfronthosting.co.za>
Message-ID: <1460140814.7.0.187494984543.issue26714@psf.upfronthosting.co.za>


SilentGhost added the comment:

issue25485 seem to have addressed this.

----------
nosy: +SilentGhost
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Apr  8 15:01:10 2016
From: report at bugs.python.org (Giga Image)
Date: Fri, 08 Apr 2016 19:01:10 +0000
Subject: [issue26715] can not deactivate venv (deactivate.bat) if the venv was
 activated by activate.ps1.
Message-ID: <1460142070.89.0.361834041489.issue26715@psf.upfronthosting.co.za>


New submission from Giga Image:

Win10/Python 3.5.1

If virtual environment was activated using powershell script, it can not deactivate the environment using only provided deactivate.bat.

Pre-condition : Virtual environment already in place.

1. Open elevated Powershell (Administrator access).

2. Activate virtual environment using activate.ps1 (must).

3  Deactivate the environment in powershell using deactivate.bat (since there is no deactivate.ps1).

Observation : Virtual environment never exit.
Expected: deactivate script should be working as expected (as the script name suggests).

NOTE: See attached screenshot.

----------
components: Windows
files: one.JPG
messages: 263036
nosy: Giga Image, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: can not deactivate venv (deactivate.bat) if the venv was activated by activate.ps1.
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file42401/one.JPG

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

From report at bugs.python.org  Fri Apr  8 15:16:29 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 08 Apr 2016 19:16:29 +0000
Subject: [issue25609] Add a ContextManager ABC and type
In-Reply-To: <1447355679.68.0.225089426373.issue25609@psf.upfronthosting.co.za>
Message-ID: <20160408191625.21704.81884.1A9CD912@psf.io>


Roundup Robot added the comment:

New changeset 841a263c0c56 by Brett Cannon in branch 'default':
Issue #25609: Introduce contextlib.AbstractContextManager and
https://hg.python.org/cpython/rev/841a263c0c56

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

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

From report at bugs.python.org  Fri Apr  8 15:17:15 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 08 Apr 2016 19:17:15 +0000
Subject: [issue25609] Add a ContextManager ABC and type
In-Reply-To: <1447355679.68.0.225089426373.issue25609@psf.upfronthosting.co.za>
Message-ID: <1460143035.44.0.919818627398.issue25609@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks to everyone for the feedback! I will now go backport this to python/typing on GitHub.

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

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

From report at bugs.python.org  Fri Apr  8 15:21:13 2016
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 08 Apr 2016 19:21:13 +0000
Subject: [issue26715] can not deactivate venv (deactivate.bat) if the venv was
 activated by activate.ps1.
In-Reply-To: <1460142070.89.0.361834041489.issue26715@psf.upfronthosting.co.za>
Message-ID: <1460143273.59.0.457285521188.issue26715@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Activate.ps1 creates a 'deactivate' function, just like activate.*sh on UNIX.  deactivate.bat is an implementation detail, because Windows cmd does not support functions.  In any activated venv on any platform, simply doing `deactivate` should work to deactivate the venv.

----------
nosy: +vinay.sajip
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Apr  8 15:25:36 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 08 Apr 2016 19:25:36 +0000
Subject: [issue26714] telnetlib.Telnet should act as a context manager
In-Reply-To: <1460137491.63.0.283583119898.issue26714@psf.upfronthosting.co.za>
Message-ID: <1460143536.74.0.0580649634957.issue26714@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

hah, i should've tested this in an up to date client. :)

----------

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

From report at bugs.python.org  Fri Apr  8 15:29:13 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 08 Apr 2016 19:29:13 +0000
Subject: [issue26668] Remove Lib/test/test_importlib/regrtest.py?
In-Reply-To: <1459300468.22.0.543956048142.issue26668@psf.upfronthosting.co.za>
Message-ID: <20160408192909.12630.83582.50EABF5F@psf.io>


Roundup Robot added the comment:

New changeset d214b30e8ef0 by Brett Cannon in branch 'default':
Issue #26668: Remove the redundant Lib/test/test_importlib/regrtest.py
https://hg.python.org/cpython/rev/d214b30e8ef0

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

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

From report at bugs.python.org  Fri Apr  8 15:29:43 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 08 Apr 2016 19:29:43 +0000
Subject: [issue26668] Remove Lib/test/test_importlib/regrtest.py?
In-Reply-To: <1459300468.22.0.543956048142.issue26668@psf.upfronthosting.co.za>
Message-ID: <1460143783.96.0.272992211169.issue26668@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/issue26668>
_______________________________________

From report at bugs.python.org  Fri Apr  8 15:50:33 2016
From: report at bugs.python.org (Jack Zhou)
Date: Fri, 08 Apr 2016 19:50:33 +0000
Subject: [issue26716] EINTR handling in fcntl
Message-ID: <1460145033.33.0.165294517839.issue26716@psf.upfronthosting.co.za>


New submission from Jack Zhou:

According to PEP 475, standard library modules should handle EINTR, but this appears to not be the case for the fcntl module.

Test script:


import fcntl
import signal
import os


def handle_alarm(signum, frame):
    print("Received alarm in process {}!".format(os.getpid()))


child = os.fork()
if child:
    signal.signal(signal.SIGALRM, handle_alarm)
    signal.alarm(1)
    with open("foo", "w") as f:
        print("Locking in process {}...".format(os.getpid()))
        fcntl.flock(f, fcntl.LOCK_EX)
        print("Locked in process {}.".format(os.getpid()))
        os.waitpid(child, 0)
else:
    signal.signal(signal.SIGALRM, handle_alarm)
    signal.alarm(1)
    with open("foo", "w") as f:
        print("Locking in process {}...".format(os.getpid()))
        fcntl.flock(f, fcntl.LOCK_EX)
        print("Locked in process {}.".format(os.getpid()))

----------
components: IO
messages: 263042
nosy: Jack Zhou
priority: normal
severity: normal
status: open
title: EINTR handling in fcntl
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Apr  8 16:14:30 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 08 Apr 2016 20:14:30 +0000
Subject: [issue26716] EINTR handling in fcntl
In-Reply-To: <1460145033.33.0.165294517839.issue26716@psf.upfronthosting.co.za>
Message-ID: <1460146470.17.0.892978495448.issue26716@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Extension Modules
nosy: +haypo, neologix, twouters
versions: +Python 3.6

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

From report at bugs.python.org  Fri Apr  8 16:48:05 2016
From: report at bugs.python.org (Anthony Sottile)
Date: Fri, 08 Apr 2016 20:48:05 +0000
Subject: [issue26717] wsgiref.simple_server: mojibake with cp1252 bytes in
 PATH_INFO
Message-ID: <1460148485.6.0.00224363970956.issue26717@psf.upfronthosting.co.za>


New submission from Anthony Sottile:

Patch attached with test.

In summary:

A request to the url b'/\x80' appears to the application as a request to b'\xc2\x80' -- The issue being the latin1 decoded PATH_INFO is re-encoded as UTF-8 and then decoded as latin1

(on the wire) b'\x80' -(decode latin1)-> u'\x80' -(encode utf-8)-> b'\xc2\x80' -(decode latin1)-> b'\xc2\x80'

My patch cuts out the encode(utf-8)->decode(latin1)

----------
components: Library (Lib)
files: patch
messages: 263043
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: wsgiref.simple_server: mojibake with cp1252 bytes in PATH_INFO
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42402/patch

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

From report at bugs.python.org  Fri Apr  8 16:53:29 2016
From: report at bugs.python.org (Anthony Sottile)
Date: Fri, 08 Apr 2016 20:53:29 +0000
Subject: [issue26717] wsgiref.simple_server: mojibake with cp1252 bytes in
 PATH_INFO
In-Reply-To: <1460148485.6.0.00224363970956.issue26717@psf.upfronthosting.co.za>
Message-ID: <1460148809.43.0.859393198242.issue26717@psf.upfronthosting.co.za>


Anthony Sottile added the comment:

A few typos in my previous comment, pressed enter too quickly, here's an updated comment:

Patch attached with test.

In summary:

A request to the url b'/\x80' appears to the application as a request to b'/\xc2\x80' -- The issue being the latin1 decoded PATH_INFO is re-encoded as UTF-8 and then decoded as latin1

    (on the wire) b'\x80' -(decode latin1)-> u'\x80' -(encode utf-8)-> b'\xc2\x80' -(decode latin1)-> u'\xc2\x80'

My patch cuts out the encode(utf-8)->decode(latin1):

    (on the wire) b'\x80' -(decode latin1) -> u'\x80'

----------

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

From report at bugs.python.org  Fri Apr  8 18:04:37 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 08 Apr 2016 22:04:37 +0000
Subject: [issue26587] Possible duplicate entries in sys.path if .pth files are
 used with zip's
In-Reply-To: <1458296580.88.0.236395091392.issue26587@psf.upfronthosting.co.za>
Message-ID: <20160408220433.32896.24095.75D0334E@psf.io>


Roundup Robot added the comment:

New changeset bd1af1a97c2e by Brett Cannon in branch 'default':
Issue #26587: Allow .pth files to specify file paths as well as
https://hg.python.org/cpython/rev/bd1af1a97c2e

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

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

From report at bugs.python.org  Fri Apr  8 18:08:09 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 08 Apr 2016 22:08:09 +0000
Subject: [issue26587] Possible duplicate entries in sys.path if .pth files are
 used with zip's
In-Reply-To: <1458296580.88.0.236395091392.issue26587@psf.upfronthosting.co.za>
Message-ID: <20160408220805.7486.78034.E631B53C@psf.io>


Roundup Robot added the comment:

New changeset 09dc97edf454 by Brett Cannon in branch '3.5':
Issue #26587: Remove an incorrect statement from the docs
https://hg.python.org/cpython/rev/09dc97edf454

New changeset 94d5c57ee835 by Brett Cannon in branch 'default':
Merge w/ 3.5 for issue #26587
https://hg.python.org/cpython/rev/94d5c57ee835

----------

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

From report at bugs.python.org  Fri Apr  8 18:10:20 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 08 Apr 2016 22:10:20 +0000
Subject: [issue26587] Possible duplicate entries in sys.path if .pth files are
 used with zip's
In-Reply-To: <1458296580.88.0.236395091392.issue26587@psf.upfronthosting.co.za>
Message-ID: <1460153420.31.0.457237387296.issue26587@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I simplified Wolfgang's patch by simply using os.path.exists(). That eliminated the one place where os.path.isdir() was in use that was too specific to directories where files were reasonable to expect.

I also quickly tweaked the docs for the site  module in 3.5 to not promise that files would work.

If you think there is still an issue with keeping things tied together, SilentGhost, feel free to open another issue to track it.

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

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

From report at bugs.python.org  Fri Apr  8 18:34:31 2016
From: report at bugs.python.org (Anthony Sottile)
Date: Fri, 08 Apr 2016 22:34:31 +0000
Subject: [issue26717] wsgiref.simple_server: mojibake with cp1252 bytes in
 PATH_INFO
In-Reply-To: <1460148485.6.0.00224363970956.issue26717@psf.upfronthosting.co.za>
Message-ID: <1460154871.31.0.0886419186185.issue26717@psf.upfronthosting.co.za>


Anthony Sottile added the comment:

Oops, broke b'/%80'.

Here's a better fix that now takes:

    (on the wire) b'\x80' -(decode latin1)-> u'\x80' -(encode utf-8)-> b'\xc2\x80' -(decode latin1)-> u'\xc2\x80'

to:

    (on the wire) b'\x80' -(decode latin1)-> u'\x80' -(encode latin1) -> b'\x80' -(decode latin1)-> u'\x80'

----------
Added file: http://bugs.python.org/file42403/patch

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

From report at bugs.python.org  Fri Apr  8 18:49:31 2016
From: report at bugs.python.org (Paul Sokolovsky)
Date: Fri, 08 Apr 2016 22:49:31 +0000
Subject: [issue1103213] Adding a recvexactly() to socket.socket: receive
 exactly n bytes
Message-ID: <1460155771.19.0.965890323122.issue1103213@psf.upfronthosting.co.za>


Changes by Paul Sokolovsky <pfalcon at users.sourceforge.net>:


----------
nosy: +pfalcon

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

From report at bugs.python.org  Fri Apr  8 19:03:36 2016
From: report at bugs.python.org (Dan Mick)
Date: Fri, 08 Apr 2016 23:03:36 +0000
Subject: [issue8027] distutils fail to determine c++ linker with unixcompiler
 if using ccache
In-Reply-To: <1267284243.46.0.756608052144.issue8027@psf.upfronthosting.co.za>
Message-ID: <1460156616.04.0.368238431833.issue8027@psf.upfronthosting.co.za>


Dan Mick added the comment:

So the original author of the code says it's "likely no longer relevant", and it's clearly wrong, but no one has touched this in six years?

Even moving the "linker[i] = self.compiler_cxx[i]" inside the if that checks for "env" would *still* limit the exposure of this bug significantly without affecting the mystery-reason-for-the-workaround...

We probably spent a man-week on this bug.

Small wonder why Python packaging continues to be met with utter terror.

----------
nosy: +Dan Mick

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

From report at bugs.python.org  Fri Apr  8 19:50:19 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 08 Apr 2016 23:50:19 +0000
Subject: [issue26717] wsgiref.simple_server: mojibake with cp1252 bytes in
 PATH_INFO
In-Reply-To: <1460148485.6.0.00224363970956.issue26717@psf.upfronthosting.co.za>
Message-ID: <1460159419.5.0.409167975971.issue26717@psf.upfronthosting.co.za>


Martin Panter added the comment:

I was going to say your original fix was the reverse of a change in r86146. But you seem to be fixing the problems before I express them :)

For the fix I would suggest something like unquote(path, "latin-1") would be simpler. I left some other review comments about the tests.

----------
nosy: +martin.panter
stage:  -> patch review
type:  -> behavior
versions:  -Python 3.4

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

From report at bugs.python.org  Fri Apr  8 20:38:15 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 09 Apr 2016 00:38:15 +0000
Subject: [issue26257] Eliminate buffer_tests.py
In-Reply-To: <1454323795.43.0.12298865479.issue26257@psf.upfronthosting.co.za>
Message-ID: <1460162295.1.0.901855508393.issue26257@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for you help with this Serhiy. Instead of your fixfillchartype(), I went with special ?if self.type2test is bytearray? checks in the common tests.

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

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

From report at bugs.python.org  Fri Apr  8 20:50:26 2016
From: report at bugs.python.org (=?utf-8?q?Arkady_=E2=80=9CKindDragon=E2=80=9D_Shapkin?=)
Date: Sat, 09 Apr 2016 00:50:26 +0000
Subject: [issue13207] os.path.expanduser breaks when using unicode character
 in the username
In-Reply-To: <1318937669.16.0.167083698894.issue13207@psf.upfronthosting.co.za>
Message-ID: <1460163026.68.0.75067506718.issue13207@psf.upfronthosting.co.za>


Arkady ?KindDragon? Shapkin added the comment:

At least Python 2.7 should return in locale.getpreferredencoding() encoding

----------
nosy: +Arkady ?KindDragon? Shapkin

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

From report at bugs.python.org  Fri Apr  8 21:02:03 2016
From: report at bugs.python.org (Kevin Modzelewski)
Date: Sat, 09 Apr 2016 01:02:03 +0000
Subject: [issue26718] super.__init__ leaks memory if called multiple times
Message-ID: <1460163723.35.0.208266777223.issue26718@psf.upfronthosting.co.za>


New submission from Kevin Modzelewski:

The super() __init__ function fills in the fields of a super object without checking if they were already set.  If someone happens to call __init__ again, the previously-set references will end up getting forgotten and leak memory.

For example:

import sys
print(sys.gettotalrefcount())
sp = super(int, 1)
for i in range(100000):
  super.__init__(sp, float, 1.0)
print(sys.gettotalrefcount())

----------
components: Interpreter Core
messages: 263053
nosy: Kevin Modzelewski
priority: normal
severity: normal
status: open
title: super.__init__ leaks memory if called multiple times
versions: Python 2.7, Python 3.6

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

From report at bugs.python.org  Fri Apr  8 21:47:58 2016
From: report at bugs.python.org (Anthony Sottile)
Date: Sat, 09 Apr 2016 01:47:58 +0000
Subject: [issue26717] wsgiref.simple_server: mojibake with cp1252 bytes in
 PATH_INFO
In-Reply-To: <1460148485.6.0.00224363970956.issue26717@psf.upfronthosting.co.za>
Message-ID: <1460166478.66.0.234535077414.issue26717@psf.upfronthosting.co.za>


Anthony Sottile added the comment:

Updates after review.

----------
Added file: http://bugs.python.org/file42404/patch

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

From report at bugs.python.org  Fri Apr  8 22:41:20 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 09 Apr 2016 02:41:20 +0000
Subject: [issue26717] wsgiref.simple_server: mojibake with cp1252 bytes in
 PATH_INFO
In-Reply-To: <1460148485.6.0.00224363970956.issue26717@psf.upfronthosting.co.za>
Message-ID: <1460169680.55.0.959714631376.issue26717@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks, this version looks pretty good to me.

----------

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

From report at bugs.python.org  Fri Apr  8 22:55:45 2016
From: report at bugs.python.org (Anthony Sottile)
Date: Sat, 09 Apr 2016 02:55:45 +0000
Subject: [issue26717] wsgiref.simple_server: mojibake with cp1252 bytes in
 PATH_INFO
In-Reply-To: <1460148485.6.0.00224363970956.issue26717@psf.upfronthosting.co.za>
Message-ID: <1460170545.03.0.863511045476.issue26717@psf.upfronthosting.co.za>


Anthony Sottile added the comment:

Forgot to remove the pyver code (leaning a bit too much on pre-commit)

----------
Added file: http://bugs.python.org/file42405/patch

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

From report at bugs.python.org  Fri Apr  8 22:56:09 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 09 Apr 2016 02:56:09 +0000
Subject: [issue26712] Unify (r)split(), (l/r)strip() method tests
In-Reply-To: <1460106175.71.0.116518416175.issue26712@psf.upfronthosting.co.za>
Message-ID: <1460170569.91.0.841327776339.issue26712@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for your comments Serhiy; here is an update

----------
Added file: http://bugs.python.org/file42406/split-strip.v2.patch

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

From report at bugs.python.org  Fri Apr  8 23:15:35 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 09 Apr 2016 03:15:35 +0000
Subject: [issue23397] PEP 431 implementation
In-Reply-To: <1423124685.79.0.871732052041.issue23397@psf.upfronthosting.co.za>
Message-ID: <1460171735.76.0.153466745546.issue23397@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Closing this since the PEP has been withdrawn. See https://www.python.org/dev/peps/pep-0431/#withdrawal for details.

----------
resolution:  -> postponed
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Apr  8 23:31:37 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 09 Apr 2016 03:31:37 +0000
Subject: [issue26718] super.__init__ leaks memory if called multiple times
In-Reply-To: <1460163723.35.0.208266777223.issue26718@psf.upfronthosting.co.za>
Message-ID: <1460172697.42.0.233640190036.issue26718@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +brett.cannon
type:  -> behavior
versions: +Python 3.5

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

From report at bugs.python.org  Fri Apr  8 23:40:04 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 09 Apr 2016 03:40:04 +0000
Subject: [issue25609] Add a ContextManager ABC and type
In-Reply-To: <1447355679.68.0.225089426373.issue25609@psf.upfronthosting.co.za>
Message-ID: <1460173204.82.0.95440980442.issue25609@psf.upfronthosting.co.za>


Martin Panter added the comment:

The docs buildbot is complaining:

http://buildbot.python.org/all/builders/Docs%203.x/builds/1156/steps/lint/logs/stdio
[2] whatsnew/3.6.rst:199: default role used

I guess this is complaining about the `__enter__()` syntax with back-ticks. Maybe it should be either :meth:`__enter__` or ``__enter__()``, etc.

----------

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

From report at bugs.python.org  Sat Apr  9 00:08:08 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 09 Apr 2016 04:08:08 +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: <1460174888.76.0.289348903053.issue25314@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch with the outstanding change for const, plus an extra fix under the main description.

----------
Added file: http://bugs.python.org/file42407/store_const.v2.patch

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

From report at bugs.python.org  Sat Apr  9 00:15:07 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 09 Apr 2016 04:15:07 +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: <1460175307.46.0.217124500991.issue25314@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file42407/store_const.v2.patch

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

From report at bugs.python.org  Sat Apr  9 00:15:45 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 09 Apr 2016 04:15:45 +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: <1460175345.47.0.66143127226.issue25314@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file42408/store_const.v2.patch

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

From report at bugs.python.org  Sat Apr  9 00:34:06 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Apr 2016 04:34:06 +0000
Subject: [issue26687] Use Py_RETURN_NONE in sqlite3 module
In-Reply-To: <1459535830.63.0.539238949684.issue26687@psf.upfronthosting.co.za>
Message-ID: <20160409043403.21942.53830.C7F63EB2@psf.io>


Roundup Robot added the comment:

New changeset b72f2d699563 by Berker Peksag in branch 'default':
Issue #26687: Use Py_RETURN_NONE macro in sqlite3 module
https://hg.python.org/cpython/rev/b72f2d699563

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

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

From report at bugs.python.org  Sat Apr  9 00:39:44 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 09 Apr 2016 04:39:44 +0000
Subject: [issue26687] Use Py_RETURN_NONE in sqlite3 module
In-Reply-To: <1459535830.63.0.539238949684.issue26687@psf.upfronthosting.co.za>
Message-ID: <1460176784.31.0.102568848962.issue26687@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks Victor and Serhiy.

?occinelle looks like a useful tool, but I'm not planning to touch modules that I don't know well enough.

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

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

From report at bugs.python.org  Sat Apr  9 00:52:28 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Apr 2016 04:52:28 +0000
Subject: [issue13952] mimetypes doesn't recognize .csv
In-Reply-To: <1328550236.31.0.476108753678.issue13952@psf.upfronthosting.co.za>
Message-ID: <20160409045226.557.24466.D576EC11@psf.io>


Roundup Robot added the comment:

New changeset 711672506b40 by Berker Peksag in branch '3.5':
Issue #13952: Add .csv to mimetypes.types_map
https://hg.python.org/cpython/rev/711672506b40

New changeset 5143f86ffe57 by Berker Peksag in branch 'default':
Issue #13952: Add .csv to mimetypes.types_map
https://hg.python.org/cpython/rev/5143f86ffe57

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

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

From report at bugs.python.org  Sat Apr  9 01:00:21 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Apr 2016 05:00:21 +0000
Subject: [issue16329] mimetypes does not support webm type
In-Reply-To: <1351258498.52.0.166970519729.issue16329@psf.upfronthosting.co.za>
Message-ID: <20160409050017.73282.22630.E3597C49@psf.io>


Roundup Robot added the comment:

New changeset 0327a5a11108 by Berker Peksag in branch '3.5':
Issue #16329: Add .webm to mimetypes.types_map
https://hg.python.org/cpython/rev/0327a5a11108

New changeset f92e6785b9f0 by Berker Peksag in branch 'default':
Issue #16329: Add .webm to mimetypes.types_map
https://hg.python.org/cpython/rev/f92e6785b9f0

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

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

From report at bugs.python.org  Sat Apr  9 01:06:20 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Apr 2016 05:06:20 +0000
Subject: [issue16329] mimetypes does not support webm type
In-Reply-To: <1351258498.52.0.166970519729.issue16329@psf.upfronthosting.co.za>
Message-ID: <20160409050617.13541.3439.98BD0904@psf.io>


Roundup Robot added the comment:

New changeset 6ed3cb699be6 by Berker Peksag in branch '2.7':
Issue #16329: Add .webm to mimetypes.types_map
https://hg.python.org/cpython/rev/6ed3cb699be6

----------

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

From report at bugs.python.org  Sat Apr  9 01:06:20 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Apr 2016 05:06:20 +0000
Subject: [issue13952] mimetypes doesn't recognize .csv
In-Reply-To: <1328550236.31.0.476108753678.issue13952@psf.upfronthosting.co.za>
Message-ID: <20160409050617.13541.91925.A27A1066@psf.io>


Roundup Robot added the comment:

New changeset e704e0786332 by Berker Peksag in branch '2.7':
Issue #13952: Add .csv to mimetypes.types_map
https://hg.python.org/cpython/rev/e704e0786332

----------

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

From report at bugs.python.org  Sat Apr  9 01:17:20 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Apr 2016 05:17:20 +0000
Subject: [issue19377] Backport SVG mime type to Python 2
In-Reply-To: <1382622251.64.0.363936372729.issue19377@psf.upfronthosting.co.za>
Message-ID: <20160409051717.28632.34882.5605E489@psf.io>


Roundup Robot added the comment:

New changeset 43a6e7104b78 by Berker Peksag in branch '2.7':
Issue #19377: Add .svg to mimetypes.types_map
https://hg.python.org/cpython/rev/43a6e7104b78

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

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

From report at bugs.python.org  Sat Apr  9 01:18:16 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 09 Apr 2016 05:18:16 +0000
Subject: [issue19377] Backport SVG mime type to Python 2
In-Reply-To: <1382622251.64.0.363936372729.issue19377@psf.upfronthosting.co.za>
Message-ID: <1460179096.8.0.395045532439.issue19377@psf.upfronthosting.co.za>


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


----------
nosy: +berker.peksag
resolution:  -> fixed
status: open -> closed
versions:  -Python 2.6

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

From report at bugs.python.org  Sat Apr  9 01:19:25 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 09 Apr 2016 05:19:25 +0000
Subject: [issue16329] mimetypes does not support webm type
In-Reply-To: <1351258498.52.0.166970519729.issue16329@psf.upfronthosting.co.za>
Message-ID: <1460179165.22.0.899063141886.issue16329@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks!

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.6

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

From report at bugs.python.org  Sat Apr  9 01:19:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Apr 2016 05:19:33 +0000
Subject: [issue26712] Unify (r)split(), (l/r)strip() method tests
In-Reply-To: <1460106175.71.0.116518416175.issue26712@psf.upfronthosting.co.za>
Message-ID: <1460179173.54.0.855447123818.issue26712@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM. Thanks for this work Martin.

----------
assignee:  -> martin.panter
stage: patch review -> commit review

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

From report at bugs.python.org  Sat Apr  9 01:20:24 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 09 Apr 2016 05:20:24 +0000
Subject: [issue13952] mimetypes doesn't recognize .csv
In-Reply-To: <1328550236.31.0.476108753678.issue13952@psf.upfronthosting.co.za>
Message-ID: <1460179224.67.0.577312612743.issue13952@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Geoff.

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

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

From report at bugs.python.org  Sat Apr  9 02:07:55 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Apr 2016 06:07:55 +0000
Subject: [issue17264] Update Building C and C++ Extensions with distutils
 documentation
In-Reply-To: <1361424697.21.0.435186366661.issue17264@psf.upfronthosting.co.za>
Message-ID: <20160409060751.16627.99670.0165D0B6@psf.io>


Roundup Robot added the comment:

New changeset ca6f174f5932 by Berker Peksag in branch '3.5':
Issue #17264: Fix cross refs and a markup error in extending/building.rst
https://hg.python.org/cpython/rev/ca6f174f5932

New changeset 7f7988ea908f by Berker Peksag in branch 'default':
Issue #17264: Fix cross refs and a markup error in extending/building.rst
https://hg.python.org/cpython/rev/7f7988ea908f

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

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

From report at bugs.python.org  Sat Apr  9 02:08:31 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 09 Apr 2016 06:08:31 +0000
Subject: [issue17264] Update Building C and C++ Extensions with distutils
 documentation
In-Reply-To: <1361424697.21.0.435186366661.issue17264@psf.upfronthosting.co.za>
Message-ID: <1460182111.27.0.835534732385.issue17264@psf.upfronthosting.co.za>


Berker Peksag added the comment:

bad92d696866 has already been removed all Python 1.4 and 2.0 references. I fixed a markup error and two broken references.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> behavior
versions: +Python 3.5, Python 3.6 -Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Apr  9 03:05:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Apr 2016 07:05:48 +0000
Subject: [issue26718] super.__init__ leaks memory if called multiple times
In-Reply-To: <1460163723.35.0.208266777223.issue26718@psf.upfronthosting.co.za>
Message-ID: <1460185548.01.0.0703775174223.issue26718@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If super used __new__ instead of __init__, this issue probably wouldn't arise.

I'm surprised that super is subclassable.

----------
nosy: +gvanrossum, serhiy.storchaka

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

From report at bugs.python.org  Sat Apr  9 03:11:50 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 09 Apr 2016 07:11:50 +0000
Subject: [issue16679] Add advice about non-ASCII wsgiref PATH_INFO
In-Reply-To: <1355473710.36.0.278942451351.issue16679@psf.upfronthosting.co.za>
Message-ID: <1460185910.36.0.801577556784.issue16679@psf.upfronthosting.co.za>


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


----------
title: Wrong URL path decoding -> Add advice about non-ASCII wsgiref PATH_INFO

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

From report at bugs.python.org  Sat Apr  9 04:17:23 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 09 Apr 2016 08:17:23 +0000
Subject: [issue21069] test_fileno of test_urllibnet intermittently fails
In-Reply-To: <1395821437.54.0.612861702522.issue21069@psf.upfronthosting.co.za>
Message-ID: <1460189843.85.0.949462713262.issue21069@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I saw test_fileno failure again on the Gentoo buildbot: http://buildbot.python.org/all/builders/x86%20Gentoo%20Installed%20with%20X%203.x/builds/459/steps/test/logs/stdio

rewrite-fileno.patch looks good to me.

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

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

From report at bugs.python.org  Sat Apr  9 05:52:22 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Apr 2016 09:52:22 +0000
Subject: [issue26716] EINTR handling in fcntl
In-Reply-To: <1460145033.33.0.165294517839.issue26716@psf.upfronthosting.co.za>
Message-ID: <20160409095219.90800.71526.78DC6A89@psf.io>


Roundup Robot added the comment:

New changeset 60ac28b612af by Victor Stinner in branch '3.5':
Update fcntl doc: replace IOError with OSError
https://hg.python.org/cpython/rev/60ac28b612af

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

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

From report at bugs.python.org  Sat Apr  9 05:54:25 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 09 Apr 2016 09:54:25 +0000
Subject: [issue26716] EINTR handling in fcntl
In-Reply-To: <1460145033.33.0.165294517839.issue26716@psf.upfronthosting.co.za>
Message-ID: <1460195665.03.0.837636734273.issue26716@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, we forgot the fcntl module in the PEP 475.

Here is a fix for Python 3.5 (and 3.6).

----------
keywords: +patch
nosy: +serhiy.storchaka
Added file: http://bugs.python.org/file42409/fcntl_eintr.patch

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

From report at bugs.python.org  Sat Apr  9 06:06:03 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Apr 2016 10:06:03 +0000
Subject: [issue26719] More efficient formatting of ints and floats in json
Message-ID: <1460196363.48.0.347398118701.issue26719@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch provide more efficient solution of issue18264. Instead of creating new int or float object and then converting it to string, the patch directly uses functions that does int and float conversion to string.

----------
components: Extension Modules, Library (Lib)
files: json_int_float_formatting.patch
keywords: patch
messages: 263077
nosy: amaury.forgeotdarc, barry, cvrebert, eli.bendersky, eric.snow, ethan.furman, ezio.melotti, giampaolo.rodola, gvanrossum, ncoghlan, pitrou, python-dev, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: More efficient formatting of ints and floats in json
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42410/json_int_float_formatting.patch

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

From report at bugs.python.org  Sat Apr  9 06:26:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Apr 2016 10:26:33 +0000
Subject: [issue26716] EINTR handling in fcntl
In-Reply-To: <1460145033.33.0.165294517839.issue26716@psf.upfronthosting.co.za>
Message-ID: <1460197593.31.0.676648399867.issue26716@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It looks to me that interrupting fcntl can be used for implementing blocking lock with a timeout. If automatically retry fcntl() on EINTR, this will break such code.

----------

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

From report at bugs.python.org  Sat Apr  9 06:52:18 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 09 Apr 2016 10:52:18 +0000
Subject: [issue24291] wsgiref.handlers.SimpleHandler truncates large output
 blobs
In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za>
Message-ID: <1460199138.14.0.452327147696.issue24291@psf.upfronthosting.co.za>


Martin Panter added the comment:

I suspect this bug does not affect Python 2. See my demo script wsgi-partial.py as evidence, which interrupts a 20 MB write with a signal.

Jason: If you look at Python 2?s file.write() API <https://docs.python.org/2/library/stdtypes.html#file.write>, perhaps that will convince you that it is easy for someone to write a write() method that has no return value.

Anyway, I think this bug is bigger than first thought. It affects most servers based on socketserver.StreamRequestHandler, not just the ?wsgiref? one. In Python 3.5 I propose to patch the existing servers to avoid the possibility of truncated writes (patch forthcoming). In 3.6, I am thinking we should change StreamRequestHandler.wfile to prevent write() doing partial writes.

----------
versions:  -Python 2.7
Added file: http://bugs.python.org/file42411/wsgi-partial.py

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

From report at bugs.python.org  Sat Apr  9 06:57:05 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 09 Apr 2016 10:57:05 +0000
Subject: [issue26719] More efficient formatting of ints and floats in json
In-Reply-To: <1460196363.48.0.347398118701.issue26719@psf.upfronthosting.co.za>
Message-ID: <1460199425.66.0.635088461003.issue26719@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

+1 This is a nice improvement.

----------

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

From report at bugs.python.org  Sat Apr  9 07:55:03 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Apr 2016 11:55:03 +0000
Subject: [issue15516] exception-handling bug in PyString_Format
In-Reply-To: <1343764780.71.0.604975878578.issue15516@psf.upfronthosting.co.za>
Message-ID: <1460202903.72.0.575036221126.issue15516@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This fixed an issue for str, but not for unicode. See issue13410.

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

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

From report at bugs.python.org  Sat Apr  9 07:56:05 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Apr 2016 11:56:05 +0000
Subject: [issue13410] String formatting bug in interactive mode
In-Reply-To: <1321394690.57.0.254973831289.issue13410@psf.upfronthosting.co.za>
Message-ID: <1460202965.45.0.709903377736.issue13410@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The issue for str was fixed in issue15516. The issue for unicode is not fixed yet.

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

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

From report at bugs.python.org  Sat Apr  9 08:02:31 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Apr 2016 12:02:31 +0000
Subject: [issue10289] Document magic methods called by built-in functions
In-Reply-To: <1288655696.94.0.809001507215.issue10289@psf.upfronthosting.co.za>
Message-ID: <1460203351.79.0.842454193149.issue10289@psf.upfronthosting.co.za>


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


----------
nosy: +serhiy.storchaka
versions: +Python 3.6 -Python 3.4

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

From report at bugs.python.org  Sat Apr  9 08:08:46 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 09 Apr 2016 12:08:46 +0000
Subject: [issue26720] memoryview from BufferedWriter becomes garbage
Message-ID: <1460203726.07.0.470306343445.issue26720@psf.upfronthosting.co.za>


New submission from Martin Panter:

>>> class Raw(RawIOBase):
...     def writable(self): return True
...     def write(self, b):
...         global written
...         written = b
...         return len(b)
... 
>>> writer = BufferedWriter(Raw())
>>> writer.write(b"blaua")
5
>>> raw = writer.detach()
>>> written
<memory at 0x7fd37f7b1aa8>
>>> written.tobytes()
b'blaua'
>>> del writer
>>> written.tobytes()  # Garbage
b'\x80f\xab\x00\x00'

Assuming this is pointing into unallocated memory, maybe it could trigger a segfault, though I haven?t seen that.

I haven?t looked at the implementation. But I am guessing that BufferedWriter is passing a view of its internal buffer to write(). For Python 2, perhaps the fix is to check if that memoryview is still referenced, and allocate a new buffer if so. 3.5 should probably inherit this fix.

Another option for 3.6 might be to call release() when write() returns. This should be documented (along with the fact that memoryview is possible in the first place; see Issue 20699).

----------
components: IO
messages: 263083
nosy: martin.panter
priority: normal
severity: normal
status: open
title: memoryview from BufferedWriter becomes garbage
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Apr  9 08:13:29 2016
From: report at bugs.python.org (Piotr Dobrogost)
Date: Sat, 09 Apr 2016 12:13:29 +0000
Subject: [issue23434] RFC6266 support (Content-Disposition for HTTP)
In-Reply-To: <1423580087.81.0.367611213854.issue23434@psf.upfronthosting.co.za>
Message-ID: <1460204009.74.0.892548684237.issue23434@psf.upfronthosting.co.za>


Changes by Piotr Dobrogost <pd at bugs.python.dobrogost.net>:


----------
nosy: +piotr.dobrogost

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

From report at bugs.python.org  Sat Apr  9 08:19:55 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 09 Apr 2016 12:19:55 +0000
Subject: [issue26721] Avoid socketserver.StreamRequestHandler.wfile doing
 partial writes
Message-ID: <1460204395.72.0.250418211057.issue26721@psf.upfronthosting.co.za>


New submission from Martin Panter:

This is a follow-on from Issue 24291. Currently, for stream servers (as opposed to datagram servers), the wfile attribute is a raw SocketIO object. This means that wfile.write() is a simple wrapper around socket.send(), and can do partial writes.

There is a comment inherited from Python 2 that reads:

# . . . we make
# wfile unbuffered because (a) often after a write() we want to
# read and we need to flush the line; (b) big writes to unbuffered
# files are typically optimized by stdio even when big reads
# aren't.

Python 2 only has one kind of ?file? object, and it seems partial writes are impossible: <https://docs.python.org/2/library/stdtypes.html#file.write>. But in Python 3, unbuffered mode means that the lower-level RawIOBase API is involved rather than the higher-level BufferedIOBase API.

I propose to change the ?wfile? attribute to be a BufferedIOBase object, yet still be ?unbuffered?. This could be implemented with a class that looks something like

class _SocketWriter(BufferedIOBase):
    """Simple writable BufferedIOBase implementation for a socket
    
    Does not hold data in a buffer, avoiding any need to call flush()."""
    def write(self, b):
        self._sock.sendall(b)
        return len(b)

----------
components: Library (Lib)
messages: 263084
nosy: martin.panter
priority: normal
severity: normal
status: open
title: Avoid socketserver.StreamRequestHandler.wfile doing partial writes
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sat Apr  9 08:22:16 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 09 Apr 2016 12:22:16 +0000
Subject: [issue24291] wsgiref.handlers.SimpleHandler truncates large output
 blobs
In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za>
Message-ID: <1460204536.86.0.92249514471.issue24291@psf.upfronthosting.co.za>


Martin Panter added the comment:

wfile-partial.patch tries to avoid partial writes in every relevant wfile.write() call I could find. Usually I do this by building a BufferedWriter around wfile.

I propose to apply my patch to 3.5 (if people think it is reasonable). For 3.6 I opened Issue 26721 to change the class used for wfile instead.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file42412/wfile-partial.patch

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

From report at bugs.python.org  Sat Apr  9 08:33:43 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 09 Apr 2016 12:33:43 +0000
Subject: [issue26716] EINTR handling in fcntl
In-Reply-To: <1460197593.31.0.676648399867.issue26716@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaW90r1OKAfJ_6ftRv0fkiXUJPNDJ3L9oCj4r_u19kuwA@mail.gmail.com>


STINNER Victor added the comment:

Serhiy Storchaka added the comment:
> It looks to me that interrupting fcntl can be used for implementing
blocking lock with a timeout. If automatically retry fcntl() on EINTR, this
will break such code.

If the signal handler doesn't raise an exception, the code is not reliable.
It's a common complain about the PEP 475.

If the signal handler raises an exception, it's work on Python 2.7 and on
Python 3.5 with my patch.

----------

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

From report at bugs.python.org  Sat Apr  9 08:35:57 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 09 Apr 2016 12:35:57 +0000
Subject: [issue24291] wsgiref.handlers.SimpleHandler truncates large output
 blobs
In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za>
Message-ID: <1460205357.16.0.682887214523.issue24291@psf.upfronthosting.co.za>


Martin Panter added the comment:

I did not write a test case for the test suite. Doing so would probably involve too many non-trivial things, so I thought it wouldn?t be worth it:

1. A background thread or process to run a client in
2. Signal handling to trigger a partial write
3. Some way to synchronize the threads and the signal (sleep, sigwait, etc)

----------

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

From report at bugs.python.org  Sat Apr  9 08:36:02 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Apr 2016 12:36:02 +0000
Subject: [issue17339] bytes() TypeError message is misleadingly narrow
In-Reply-To: <1362254314.39.0.995387791388.issue17339@psf.upfronthosting.co.za>
Message-ID: <1460205362.46.0.882615905761.issue17339@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch.

----------
keywords: +patch
nosy: +serhiy.storchaka
stage: needs patch -> patch review
versions: +Python 3.6 -Python 3.4
Added file: http://bugs.python.org/file42413/bytes_from_object_error_msg.patch

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

From report at bugs.python.org  Sat Apr  9 08:43:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Apr 2016 12:43:12 +0000
Subject: [issue26720] memoryview from BufferedWriter becomes garbage
In-Reply-To: <1460203726.07.0.470306343445.issue26720@psf.upfronthosting.co.za>
Message-ID: <1460205792.12.0.506772006534.issue26720@psf.upfronthosting.co.za>


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


----------
nosy: +benjamin.peterson, pitrou, serhiy.storchaka, stutzbach

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

From report at bugs.python.org  Sat Apr  9 08:52:24 2016
From: report at bugs.python.org (Alexander Marshalov)
Date: Sat, 09 Apr 2016 12:52:24 +0000
Subject: [issue26722] Fold compare operators on constants (peephole)
Message-ID: <1460206344.63.0.870327472601.issue26722@psf.upfronthosting.co.za>


New submission from Alexander Marshalov:

Missed peephole optimization:
   1 > 2  ->  False
   3 < 4  ->  True
   5 == 6  ->  False
   6 != 7  ->  True
   7 >= 8  ->  False
   8 <= 9  ->  True
   10 is 11 -> False
   12 is not 13  ->  True
   14 in (15, 16, 17)  ->  False
   18 not in (19, 20, 21)  ->  True

----------
components: Interpreter Core
files: peephole_compareops.patch
keywords: patch
messages: 263089
nosy: amper
priority: normal
severity: normal
status: open
title: Fold compare operators on constants (peephole)
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42414/peephole_compareops.patch

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

From report at bugs.python.org  Sat Apr  9 08:53:00 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 09 Apr 2016 12:53:00 +0000
Subject: [issue25339] sys.stdout.errors is set to "surrogateescape"
In-Reply-To: <1460112369.78.0.351601508503.issue25339@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZ6RwSXu7RWjjZxdJngG_A+6LWQwd72A566SqJGH09RtQ@mail.gmail.com>


STINNER Victor added the comment:

Ok, I now understand the issue. Your change looks good to me.

I agree that strict error handler is good choice for PYTHONIOENCODING=ascii.

----------

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

From report at bugs.python.org  Sat Apr  9 08:53:45 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 09 Apr 2016 12:53:45 +0000
Subject: [issue25339] sys.stdout.errors is set to "surrogateescape"
In-Reply-To: <CAMpsgwZ6RwSXu7RWjjZxdJngG_A+6LWQwd72A566SqJGH09RtQ@mail.gmail.com>
Message-ID: <CAMpsgwbJirXQ=yfRNtajBUQHAhxbQGySJdeyDLXR4SdRNoRn4A@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/issue25339>
_______________________________________

From report at bugs.python.org  Sat Apr  9 08:56:10 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 09 Apr 2016 12:56:10 +0000
Subject: [issue26722] Fold compare operators on constants (peephole)
In-Reply-To: <1460206344.63.0.870327472601.issue26722@psf.upfronthosting.co.za>
Message-ID: <1460206570.53.0.0376961789659.issue26722@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +benjamin.peterson, brett.cannon, georg.brandl, haypo, ncoghlan, yselivanov
stage:  -> patch review

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

From report at bugs.python.org  Sat Apr  9 09:01:49 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 09 Apr 2016 13:01:49 +0000
Subject: [issue10289] Document magic methods called by built-in functions
In-Reply-To: <1288655696.94.0.809001507215.issue10289@psf.upfronthosting.co.za>
Message-ID: <1460206909.75.0.326993846851.issue10289@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

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

From report at bugs.python.org  Sat Apr  9 09:15:16 2016
From: report at bugs.python.org (Demur Rumed)
Date: Sat, 09 Apr 2016 13:15:16 +0000
Subject: [issue26722] Fold compare operators on constants (peephole)
In-Reply-To: <1460206344.63.0.870327472601.issue26722@psf.upfronthosting.co.za>
Message-ID: <1460207716.17.0.215269082908.issue26722@psf.upfronthosting.co.za>


Demur Rumed added the comment:

Do you have any numbers on how common constant comparisons are in real code?

----------
nosy: +Demur Rumed

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

From report at bugs.python.org  Sat Apr  9 09:17:01 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 09 Apr 2016 13:17:01 +0000
Subject: [issue26722] Fold compare operators on constants (peephole)
In-Reply-To: <1460206344.63.0.870327472601.issue26722@psf.upfronthosting.co.za>
Message-ID: <1460207821.01.0.346955813527.issue26722@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hi, it looks like the author of the peephole optimizer is Raymond Hettinger and he doesn't look to want to handle too many cases, he prefers to keep the code simple.

FYI I reimplemented recently the peephole optimizer in pure Python as part of the bytecode project:
https://bytecode.readthedocs.org/en/latest/peephole.html

I didn't write it to replace the C implementation, it was more a tool to discuss modifying bytecode (when discussing the PEP 511).

More generally, there is an ongoging discussion of rewriting the peephole optimizer to work on the AST rather than working on the Python code. The FAT Python implements that in pure Python:
https://faster-cpython.readthedocs.org/fat_python.html

FAT Python is more than a peephole optimizer, it's more a framework to implement more optimizations. Well, take a look.

----------

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

From report at bugs.python.org  Sat Apr  9 09:18:30 2016
From: report at bugs.python.org (Demur Rumed)
Date: Sat, 09 Apr 2016 13:18:30 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1460207910.49.0.24627267439.issue26647@psf.upfronthosting.co.za>


Demur Rumed added the comment:

[12:36] <serprex> Could I get a code review for wordcode's 4th patchset? http://bugs.python.org/review/26647/#ps16875
...
[13:13] <SilentGhost> serprex: you'd be better off bumping the issue

----------

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

From report at bugs.python.org  Sat Apr  9 09:19:14 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 09 Apr 2016 13:19:14 +0000
Subject: [issue26722] Fold compare operators on constants (peephole)
In-Reply-To: <1460206344.63.0.870327472601.issue26722@psf.upfronthosting.co.za>
Message-ID: <1460207954.78.0.355987417051.issue26722@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Do you have any numbers on how common constant comparisons are in real code?

In my experience, it almost never occur in real application. But it's common when you start with a constant propogation optimization:

* https://faster-cpython.readthedocs.org/optimizations.html#constant-propagation
* https://fatoptimizer.readthedocs.org/en/latest/optimizations.html#constant-propagation

If you extend constant propagation to things like os.name, it's even more common, but it requires to specialize the code, to disable optimization if os.name is modified (that's one feature provided by FAT Python).

----------

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

From report at bugs.python.org  Sat Apr  9 09:44:39 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Apr 2016 13:44:39 +0000
Subject: [issue26609] Wrong request target in test_httpservers.py
In-Reply-To: <1458636980.12.0.779581831419.issue26609@psf.upfronthosting.co.za>
Message-ID: <20160409134435.110016.73102.6E921D97@psf.io>


Roundup Robot added the comment:

New changeset 0e19f421dc9e by Martin Panter in branch '3.5':
Issue #26609: Fix HTTP server tests to request an absolute URL path
https://hg.python.org/cpython/rev/0e19f421dc9e

New changeset 34ebf79acd78 by Martin Panter in branch 'default':
Issue #26609: Merge HTTP tests from 3.5
https://hg.python.org/cpython/rev/34ebf79acd78

New changeset 2691f81a89a7 by Martin Panter in branch '2.7':
Issue #26609: Fix HTTP server tests to request an absolute URL path
https://hg.python.org/cpython/rev/2691f81a89a7

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

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

From report at bugs.python.org  Sat Apr  9 09:46:08 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Apr 2016 13:46:08 +0000
Subject: [issue26609] Wrong request target in test_httpservers.py
In-Reply-To: <1458636980.12.0.779581831419.issue26609@psf.upfronthosting.co.za>
Message-ID: <20160409134606.90798.91651.9B0737ED@psf.io>


Roundup Robot added the comment:

New changeset 4f64b1c87a56 by Martin Panter in branch '2.7':
Issue #26609: Fix up Python 2 port
https://hg.python.org/cpython/rev/4f64b1c87a56

----------

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

From report at bugs.python.org  Sat Apr  9 10:03:02 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 09 Apr 2016 14:03:02 +0000
Subject: [issue17339] bytes() TypeError message is misleadingly narrow
In-Reply-To: <1362254314.39.0.995387791388.issue17339@psf.upfronthosting.co.za>
Message-ID: <1460210582.14.0.757451454526.issue17339@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think this patch is okay.

I would have suggested ?Cannot construct bytes from [. . .]? to avoid the problem with ?convert?, but this message is produced in places other than the constructor, e.g.

>>> int.from_bytes("str", "little")
TypeError: cannot convert unicode object to bytes

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

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

From report at bugs.python.org  Sat Apr  9 10:12:54 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Apr 2016 14:12:54 +0000
Subject: [issue21069] test_fileno of test_urllibnet intermittently fails
In-Reply-To: <1395821437.54.0.612861702522.issue21069@psf.upfronthosting.co.za>
Message-ID: <20160409141250.16615.64798.E2B53244@psf.io>


Roundup Robot added the comment:

New changeset 00240ddce1d0 by Martin Panter in branch '3.5':
Issue #21069: Move test_fileno() from test_urllibnet and rewrite it
https://hg.python.org/cpython/rev/00240ddce1d0

New changeset 4c19396bd4a0 by Martin Panter in branch 'default':
Issue #21069: Merge test_fileno() from 3.5
https://hg.python.org/cpython/rev/4c19396bd4a0

----------

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

From report at bugs.python.org  Sat Apr  9 11:14:10 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 09 Apr 2016 15:14:10 +0000
Subject: [issue26719] More efficient formatting of ints and floats in json
In-Reply-To: <1460199425.66.0.635088461003.issue26719@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJKz88QnL3GRNLZU21zEcn2p8VDLg-PY8GtRenMqV8+kzA@mail.gmail.com>


Guido van Rossum added the comment:

Please also backport to 3.5.2...

On Saturday, April 9, 2016, Raymond Hettinger <report at bugs.python.org>
wrote:

>
> Raymond Hettinger added the comment:
>
> +1 This is a nice improvement.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org <javascript:;>>
> <http://bugs.python.org/issue26719>
> _______________________________________
>

----------

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

From report at bugs.python.org  Sat Apr  9 12:10:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Apr 2016 16:10:30 +0000
Subject: [issue17339] bytes() TypeError message is misleadingly narrow
In-Reply-To: <1362254314.39.0.995387791388.issue17339@psf.upfronthosting.co.za>
Message-ID: <1460218230.08.0.456452719664.issue17339@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Martin.

Interesting, int.from_bytes() accepts lists (and other iterables):

>>> int.from_bytes([1, 2, 3], "little")
197121

Is it intentional?

----------

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

From report at bugs.python.org  Sat Apr  9 12:14:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Apr 2016 16:14:47 +0000
Subject: [issue26719] More efficient formatting of ints and floats in json
In-Reply-To: <1460196363.48.0.347398118701.issue26719@psf.upfronthosting.co.za>
Message-ID: <1460218487.54.0.141386054001.issue26719@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is similar issue with unneeded strings copying: issue26057.

----------

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

From report at bugs.python.org  Sat Apr  9 12:28:52 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 09 Apr 2016 16:28:52 +0000
Subject: [issue26718] super.__init__ leaks memory if called multiple times
In-Reply-To: <1460163723.35.0.208266777223.issue26718@psf.upfronthosting.co.za>
Message-ID: <1460219332.84.0.604741855893.issue26718@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Any uses of super() beyond the documented idioms are uninteresting, except they should not be usable as crash or DoS vectors.

----------

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

From report at bugs.python.org  Sat Apr  9 13:52:41 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 09 Apr 2016 17:52:41 +0000
Subject: [issue25609] Add a ContextManager ABC and type
In-Reply-To: <1447355679.68.0.225089426373.issue25609@psf.upfronthosting.co.za>
Message-ID: <1460224361.44.0.131427331333.issue25609@psf.upfronthosting.co.za>


Brett Cannon added the comment:

The typing changes need to be backported to 3.5 as-is to keep the files in sync.

----------
status: closed -> open
versions: +Python 3.5

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

From report at bugs.python.org  Sat Apr  9 14:40:00 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Sat, 09 Apr 2016 18:40:00 +0000
Subject: [issue26723] Add an option to skip _decimal module
Message-ID: <1460227200.51.0.75268683171.issue26723@psf.upfronthosting.co.za>


New submission from Chi Hsuan Yen:

As said by Stefan Krah in http://bugs.python.org/issue23496#msg236886, Android ports can use pure python decimal module. Of course I can, but _decimal is always built and error messages are spamming. This change allow disabling _decimal from ./configure.

For the complete build process, have a look into scripts and patches from https://github.com/yan12125/python3-android.

----------
components: Build, Cross-Build, Extension Modules
files: allow-disable-libmpdec.patch
keywords: patch
messages: 263105
nosy: Alex.Willmer, Chi Hsuan Yen
priority: normal
severity: normal
status: open
title: Add an option to skip _decimal module
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42415/allow-disable-libmpdec.patch

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

From report at bugs.python.org  Sat Apr  9 15:17:31 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 09 Apr 2016 19:17:31 +0000
Subject: [issue26723] Add an option to skip _decimal module
In-Reply-To: <1460227200.51.0.75268683171.issue26723@psf.upfronthosting.co.za>
Message-ID: <1460229451.6.0.633369541307.issue26723@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I thought you solved the locale problem in #20305. So it still does not build?

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

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

From report at bugs.python.org  Sat Apr  9 15:35:17 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 09 Apr 2016 19:35:17 +0000
Subject: [issue26723] Add an option to skip _decimal module
In-Reply-To: <1460227200.51.0.75268683171.issue26723@psf.upfronthosting.co.za>
Message-ID: <1460230517.26.0.837362383255.issue26723@psf.upfronthosting.co.za>


Stefan Krah added the comment:

In any case:  It is not uncommon that some C module does not build.

You can disable modules in setup.py:

  # This global variable is used to hold the list of modules to be disabled.
  disabled_module_list = []

----------
assignee:  -> skrah
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Apr  9 16:03:30 2016
From: report at bugs.python.org (anton-ryzhov)
Date: Sat, 09 Apr 2016 20:03:30 +0000
Subject: =?utf-8?q?=5Bissue26724=5D_Serialize_dict_with_non-string_keys_to_JSON_?=
 =?utf-8?q?=E2=80=94_unexpected_result?=
Message-ID: <1460232210.14.0.690770793503.issue26724@psf.upfronthosting.co.za>


New submission from anton-ryzhov:

JSON doesn't allow to have non-sting keys in objects, so json.dumps converts its to string. But if several keys has one string representation ? we'll get damaged result as follows:

>>> import json
>>> json.dumps({1: 2, "1": "2"})
'{"1": 2, "1": "2"}'

I think it should raise ValueError in this case.

I've tested this case on 2.7, 3.4 and on trunk version 3.6.

----------
components: Library (Lib)
messages: 263108
nosy: anton-ryzhov
priority: normal
severity: normal
status: open
title: Serialize dict with non-string keys to JSON ? unexpected result
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/issue26724>
_______________________________________

From report at bugs.python.org  Sat Apr  9 16:11:06 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Sat, 09 Apr 2016 20:11:06 +0000
Subject: [issue26723] Add an option to skip _decimal module
In-Reply-To: <1460227200.51.0.75268683171.issue26723@psf.upfronthosting.co.za>
Message-ID: <1460232666.76.0.618058552689.issue26723@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Regarding #20305: Now building is fine, while some runtime errors exist. I don't see reasons running ncurses on Android, so kicking those errors are not in my plan.

For this change: Thanks for pointing that variable - not noticing it before. Seems I still need to patch setup.py for disabling some specific modules? I don't like patches. They're just temporary workarounds for me. I see issue20210 proposing a general solution for disabling modules. Maybe I'll working on that instead.

----------

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

From report at bugs.python.org  Sat Apr  9 16:20:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Apr 2016 20:20:58 +0000
Subject: =?utf-8?q?=5Bissue26724=5D_Serialize_dict_with_non-string_keys_to_JSON_?=
 =?utf-8?q?=E2=80=94_unexpected_result?=
In-Reply-To: <1460232210.14.0.690770793503.issue26724@psf.upfronthosting.co.za>
Message-ID: <1460233258.2.0.665987129422.issue26724@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also https://github.com/simplejson/simplejson/issues/77 .

----------
nosy: +serhiy.storchaka
versions:  -Python 3.4

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

From report at bugs.python.org  Sat Apr  9 16:22:26 2016
From: report at bugs.python.org (Steven Reed)
Date: Sat, 09 Apr 2016 20:22:26 +0000
Subject: [issue26725] list() destroys map object data
Message-ID: <1460233346.79.0.373711296036.issue26725@psf.upfronthosting.co.za>


New submission from Steven Reed:

Example repro:

Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:54:25) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> x=map(bool,[1,0,0,1,1,0])
>>> x
<map object at 0x0000000000AC51D0>
>>> list(x)
[True, False, False, True, True, False]
>>> list(x)
[]
>>> x
<map object at 0x0000000000AC51D0>

----------
components: Library (Lib)
messages: 263111
nosy: Steven Reed
priority: normal
severity: normal
status: open
title: list() destroys map object data
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sat Apr  9 16:28:54 2016
From: report at bugs.python.org (Ned Deily)
Date: Sat, 09 Apr 2016 20:28:54 +0000
Subject: [issue26725] list() destroys map object data
In-Reply-To: <1460233346.79.0.373711296036.issue26725@psf.upfronthosting.co.za>
Message-ID: <1460233734.39.0.631652399693.issue26725@psf.upfronthosting.co.za>


Ned Deily added the comment:

This is behaving as expected.  In Python 3, map() returns an iterator, so the first list(x) exhausts that iterator so that the second list(x) returns an empty list.  This is a difference from Python 2 where map() returns a list.  See:

https://docs.python.org/3.5/whatsnew/3.0.html#views-and-iterators-instead-of-lists
https://docs.python.org/3/library/functions.html#map

----------
nosy: +ned.deily
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Apr  9 17:39:51 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Apr 2016 21:39:51 +0000
Subject: [issue26720] memoryview from BufferedWriter becomes garbage
In-Reply-To: <1460203726.07.0.470306343445.issue26720@psf.upfronthosting.co.za>
Message-ID: <1460237991.77.0.717989172088.issue26720@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Another option is to use the bytes object as internal buffer. If its refcount is == 1 (normal case), it is modified in-place, otherwise (if the reference is saved outside) new bytes object is created.

----------

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

From report at bugs.python.org  Sat Apr  9 18:11:44 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 09 Apr 2016 22:11:44 +0000
Subject: [issue26720] memoryview from BufferedWriter becomes garbage
In-Reply-To: <1460203726.07.0.470306343445.issue26720@psf.upfronthosting.co.za>
Message-ID: <1460239904.08.0.482811064163.issue26720@psf.upfronthosting.co.za>


Martin Panter added the comment:

On further thought, I think releasing the buffer would not be the best long-term solution. I encountered this bug when wrapping custom AuditableBytesIO objects (Lib/test/test_httpservers.py) with BufferedWriter, where the raw object just saves each write() buffer in a list for later use.

Serhiy: what you say sounds like what I had in mind, except I suspect it doesn?t matter whether the memoryview is backed by a bytes object or something else. The main point is we allocate a new buffer if the old one is still referenced by the memoryview.

It seems this problem has already been discovered, along with BufferedReader and PyUnicode_Decode(): <https://bugs.python.org/issue15903#msg170642>. The BufferedReader case can have more serious consequences because it is writable (Issue 15994).

----------

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

From report at bugs.python.org  Sat Apr  9 18:27:15 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 09 Apr 2016 22:27:15 +0000
Subject: [issue21069] test_fileno of test_urllibnet intermittently fails
In-Reply-To: <1395821437.54.0.612861702522.issue21069@psf.upfronthosting.co.za>
Message-ID: <1460240835.92.0.381447054338.issue21069@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/issue21069>
_______________________________________

From report at bugs.python.org  Sat Apr  9 18:31:02 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 09 Apr 2016 22:31:02 +0000
Subject: [issue26609] Wrong request target in test_httpservers.py
In-Reply-To: <1458636980.12.0.779581831419.issue26609@psf.upfronthosting.co.za>
Message-ID: <1460241062.11.0.092337306821.issue26609@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the patch

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.5

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

From report at bugs.python.org  Sat Apr  9 18:53:33 2016
From: report at bugs.python.org (Grady Martin)
Date: Sat, 09 Apr 2016 22:53:33 +0000
Subject: [issue26726] Incomplete Internationalization in Argparse Module
Message-ID: <1460242413.52.0.89369314936.issue26726@psf.upfronthosting.co.za>


New submission from Grady Martin:

The attached, teensy-weensy patch passes to gettext() a string which had previously been passed as-is.  Relevant mailing list message:

http://article.gmane.org/gmane.comp.python.devel/157035

----------
files: argparse_i18n.patch
keywords: patch
messages: 263116
nosy: IronGrid
priority: normal
severity: normal
status: open
title: Incomplete Internationalization in Argparse Module
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file42416/argparse_i18n.patch

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

From report at bugs.python.org  Sat Apr  9 20:07:55 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Apr 2016 00:07:55 +0000
Subject: =?utf-8?q?=5Bissue26724=5D_Serialize_dict_with_non-string_keys_to_JSON_?=
 =?utf-8?q?=E2=80=94_unexpected_result?=
In-Reply-To: <1460232210.14.0.690770793503.issue26724@psf.upfronthosting.co.za>
Message-ID: <1460246875.8.0.363072031506.issue26724@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I think etrepum's comment on Aug 27, 2013 display's sound reasoning:
'''
I expect that this error checking feature would be expensive to implement (both in runtime cost and lines of code). I think the most sensible thing to do would be to just mention this in the docs, or do nothing. In the past ~8 years, this is the only time this potential issue has ever been brought up here. It's not technically invalid JSON, but the decode semantics aren't well defined by the spec.
'''

 
I think this should be closed as "not a bug" since the semantics aren't well defined and because currently deployed code may rely on the behavior which isn't unreasonable or shocking. In general, Python tools aim more for practicality than for lint-like advisories about all possible input oddities.

----------
assignee:  -> bob.ippolito
nosy: +bob.ippolito, rhettinger
priority: normal -> low

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

From report at bugs.python.org  Sat Apr  9 20:19:43 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Apr 2016 00:19:43 +0000
Subject: [issue26722] Fold compare operators on constants (peephole)
In-Reply-To: <1460206344.63.0.870327472601.issue26722@psf.upfronthosting.co.za>
Message-ID: <1460247583.4.0.0302425562573.issue26722@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

AFAICT, the cases the OP listed would be rarely found in real code. 

Victor is correct is saying that we want to limit the scope of the peepholer to the most useful cases.  

He is also correct in saying that we've long desired constant folding to be moved upstream to the AST and don't want to go further down the path of doing more work at the bytecode level.  Ideally, the only optimizations at the peephole level would be limited to rejuggling opcodes into cheaper execution sequences without regard to higher level object semantics.

I recommend rejecting this and suggesting that more effort be focused on the AST optimizations.

----------
nosy: +rhettinger
priority: normal -> low

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

From report at bugs.python.org  Sat Apr  9 20:55:02 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Apr 2016 00:55:02 +0000
Subject: [issue10289] Document magic methods called by built-in functions
In-Reply-To: <1288655696.94.0.809001507215.issue10289@psf.upfronthosting.co.za>
Message-ID: <1460249702.83.0.607268258393.issue10289@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Most of the proposed update look reasonable updates and would improve the documentation.  

That said, please take care to not accidentally document and unintentionally guarantee implementation details rather than language requirements (leaving freedom for future changes to implementation and freedom for IronPython, PyPy, and Jython to use their best possible implementations).

Sizeof is a CPython specific implementation detail.

I also have reservations about class.__instancecheck__() and class.__subclasscheck__() which are more appropriately described in a section on abstract base classes than for the otherwise simple and clear docs for isinstance() and issubclass().

The sort() method does guarantee use of __lt__ but other tools that make comparisons make or may not follow that lead (i.e. heapq used to use __le__ and collections.abc.Set uses both __le__ and __ge__).  Accordingly, there is a PEP 8 recommendation to use @functools.total_ordering rather than supplying just a single rich comparison method).

One other thought is to keep the additions as brief as possible to not distract from the main message of each section; keeping the docs primarily focused on what a function does rather than how it does it, and remembering that making the docs more lengthly impairs their utility for everyday use.  Our docs are already much more chatty than equivalents in Java and Go (it used to take five minutes to read the docs for the builtin functions and now it takes an hour). 

There is also a matter of keeping the docs approachable for normal people.  For most folks, saying that hex(num) returns a string with the number in hexadecimal would suffice.  Adding notes about the exact case of the letters, handling of negatives, use of __int__ and __index__, and comparisons with string formatting, and multiple examples beats a dead horse and makes a simple tool seem more complex.

Though I think this so go forward, I'm marking it with "low" priority because we don't have any evidence that users have found the current docs to be inadequate -- they have served well over Python's long history.   Cases we've gone into details like __format__ or __next__ were there because they we essential to the tool; in contrast, it is unlikely that a user would ever need to know the sys.getsizeof() delegated its work to __sizeof__.

----------
nosy: +rhettinger
priority: normal -> low

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

From report at bugs.python.org  Sat Apr  9 22:41:19 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 10 Apr 2016 02:41:19 +0000
Subject: [issue26721] Avoid socketserver.StreamRequestHandler.wfile doing
 partial writes
In-Reply-To: <1460204395.72.0.250418211057.issue26721@psf.upfronthosting.co.za>
Message-ID: <1460256079.97.0.708534550111.issue26721@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a patch with my proposal.

----------
keywords: +patch
Added file: http://bugs.python.org/file42417/buffered-wfile.patch

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

From report at bugs.python.org  Sat Apr  9 22:44:27 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Apr 2016 02:44:27 +0000
Subject: [issue25609] Add a ContextManager ABC and type
In-Reply-To: <1447355679.68.0.225089426373.issue25609@psf.upfronthosting.co.za>
Message-ID: <20160410024424.34567.68836.E1DD5B41@psf.io>


Roundup Robot added the comment:

New changeset 5c0e332988b2 by Martin Panter in branch 'default':
Issue #25609: Double back-ticks to avoid ?make check? buildbot failure
https://hg.python.org/cpython/rev/5c0e332988b2

----------

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

From report at bugs.python.org  Sat Apr  9 22:48:52 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 10 Apr 2016 02:48:52 +0000
Subject: [issue26722] Fold compare operators on constants (peephole)
In-Reply-To: <1460206344.63.0.870327472601.issue26722@psf.upfronthosting.co.za>
Message-ID: <1460256532.3.0.279193706456.issue26722@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Nice work on getting this running, Alexander. However, as Victor and Raymond noted, we're looking to head in a different direction with our bytecode optimisation efforts, which is to better support pluggable AST level optimisations that can make more assumptions about the runtime environment.

If this is a topic you'd like to explore further, then in addition to Victor's FAT Python project, you may also be interested in his proposals to add some supporting infrastructure for that to Python 3.6:

* Dict versioning: https://www.python.org/dev/peps/pep-0509/
* Function specialisation: https://www.python.org/dev/peps/pep-0510/
* Code transformers: https://www.python.org/dev/peps/pep-0511/

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

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

From report at bugs.python.org  Sat Apr  9 23:55:08 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 10 Apr 2016 03:55:08 +0000
Subject: [issue15984] Wrong documentation for PyUnicode_FromObject() and
 PyUnicode_FromEncodedObject()
In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za>
Message-ID: <1460260508.62.0.284633989177.issue15984@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a modified patch that avoids ?coercion? and is hopefully more explicit. I also fixed the comment in Include/unicodeobject.h.

----------
nosy: +martin.panter
stage: needs patch -> patch review
versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4
Added file: http://bugs.python.org/file42418/from_object_v3.patch

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

From report at bugs.python.org  Sun Apr 10 00:08:20 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 10 Apr 2016 04:08:20 +0000
Subject: [issue15984] Wrong documentation for PyUnicode_FromObject() and
 PyUnicode_FromEncodedObject()
In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za>
Message-ID: <1460261300.16.0.236539975501.issue15984@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file42418/from_object_v3.patch

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

From report at bugs.python.org  Sun Apr 10 00:10:05 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 10 Apr 2016 04:10:05 +0000
Subject: [issue15984] Wrong documentation for PyUnicode_FromObject() and
 PyUnicode_FromEncodedObject()
In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za>
Message-ID: <1460261405.89.0.167428063955.issue15984@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file42419/from_object_v3.patch

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

From report at bugs.python.org  Sun Apr 10 01:08:29 2016
From: report at bugs.python.org (Alexander Marshalov)
Date: Sun, 10 Apr 2016 05:08:29 +0000
Subject: [issue26722] Fold compare operators on constants (peephole)
In-Reply-To: <1460256532.3.0.279193706456.issue26722@psf.upfronthosting.co.za>
Message-ID: <7280541460264906@web6g.yandex.ru>


Alexander Marshalov added the comment:

Hi all, this is my first patch to Python.
I'm interested in the performance of python code, I even worked on the development of the static optimizer based on modifications of the AST.
I had a few ideas for improving peepholer (for example, the expression "x, y = 1, 2" according to my benchmarks is about 7-11% slower than the expression "x = 1; y = 2", this can be fixed by using a peepholer), but I already understood that it is not necessary to do it. 
Thanks for the clarification, I will continue to work towards AST-optimizations.

----------

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

From report at bugs.python.org  Sun Apr 10 02:11:16 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 10 Apr 2016 06:11:16 +0000
Subject: [issue26057] Avoid nonneeded use of PyUnicode_FromObject()
In-Reply-To: <1452328901.15.0.65828251852.issue26057@psf.upfronthosting.co.za>
Message-ID: <1460268676.9.0.503310549313.issue26057@psf.upfronthosting.co.za>


Martin Panter added the comment:

Left some comments

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

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

From report at bugs.python.org  Sun Apr 10 02:26:00 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 10 Apr 2016 06:26:00 +0000
Subject: [issue26726] Incomplete Internationalization in Argparse Module
In-Reply-To: <1460242413.52.0.89369314936.issue26726@psf.upfronthosting.co.za>
Message-ID: <1460269560.94.0.0801492262162.issue26726@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Library (Lib)
nosy: +berker.peksag
stage:  -> patch review

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

From report at bugs.python.org  Sun Apr 10 06:16:26 2016
From: report at bugs.python.org (Henri Starmans)
Date: Sun, 10 Apr 2016 10:16:26 +0000
Subject: [issue26727] ctypes.util.find_msvcrt() does not work in python 3.5.1
Message-ID: <1460283386.16.0.225166865628.issue26727@psf.upfronthosting.co.za>


New submission from Henri Starmans:

Function find_msvcrt() returns None in Python 3.5.1, I expected
'msvcr100.dll'.

test code:
from ctypes.util import find_msvcrt
print(find_msvcrt())

----------
components: Windows
messages: 263126
nosy: Henri Starmans, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: ctypes.util.find_msvcrt() does not work in python 3.5.1
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sun Apr 10 06:28:12 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Apr 2016 10:28:12 +0000
Subject: [issue26712] Unify (r)split(), (l/r)strip() method tests
In-Reply-To: <1460106175.71.0.116518416175.issue26712@psf.upfronthosting.co.za>
Message-ID: <20160410102809.34567.19056.BE13420E@psf.io>


Roundup Robot added the comment:

New changeset 15cbeb389f17 by Martin Panter in branch '3.5':
Issue #26712: Unify (r)split, (l/r)strip tests into string_tests
https://hg.python.org/cpython/rev/15cbeb389f17

New changeset bb3cfca9c431 by Martin Panter in branch 'default':
Issue #26712: Merge string_tests cleanup from 3.5
https://hg.python.org/cpython/rev/bb3cfca9c431

New changeset 4dc347c5c8a8 by Martin Panter in branch '2.7':
Issue #26712: Unify (r)split(), (l/r)strip() tests into string_tests
https://hg.python.org/cpython/rev/4dc347c5c8a8

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

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

From report at bugs.python.org  Sun Apr 10 06:44:10 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 10 Apr 2016 10:44:10 +0000
Subject: [issue26706] Update OpenSSL version in readme
In-Reply-To: <1459974987.74.0.0926215654006.issue26706@psf.upfronthosting.co.za>
Message-ID: <1460285050.7.0.893707241533.issue26706@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


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

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

From report at bugs.python.org  Sun Apr 10 06:51:23 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Apr 2016 10:51:23 +0000
Subject: [issue26057] Avoid nonneeded use of PyUnicode_FromObject()
In-Reply-To: <1452328901.15.0.65828251852.issue26057@psf.upfronthosting.co.za>
Message-ID: <1460285483.33.0.777402694874.issue26057@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch addresses Martin's comments.

----------
Added file: http://bugs.python.org/file42421/no_unicode_copy_2.patch

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

From report at bugs.python.org  Sun Apr 10 07:07:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Apr 2016 11:07:46 +0000
Subject: [issue15984] Wrong documentation for PyUnicode_FromObject() and
 PyUnicode_FromEncodedObject()
In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za>
Message-ID: <1460286466.0.0.72374978265.issue15984@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added a comment on Rietveld.

----------

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

From report at bugs.python.org  Sun Apr 10 07:45:44 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Apr 2016 11:45:44 +0000
Subject: [issue25339] sys.stdout.errors is set to "surrogateescape"
In-Reply-To: <1444287088.0.0.588605250096.issue25339@psf.upfronthosting.co.za>
Message-ID: <20160410114541.110022.89721.75C4358F@psf.io>


Roundup Robot added the comment:

New changeset 56eca1c08738 by Serhiy Storchaka in branch '3.5':
Issue #25339: PYTHONIOENCODING now has priority over locale in setting the
https://hg.python.org/cpython/rev/56eca1c08738

New changeset 9c6623099da1 by Serhiy Storchaka in branch 'default':
Issue #25339: PYTHONIOENCODING now has priority over locale in setting the
https://hg.python.org/cpython/rev/9c6623099da1

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

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

From report at bugs.python.org  Sun Apr 10 07:45:44 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Apr 2016 11:45:44 +0000
Subject: [issue17339] bytes() TypeError message is misleadingly narrow
In-Reply-To: <1362254314.39.0.995387791388.issue17339@psf.upfronthosting.co.za>
Message-ID: <20160410114541.110022.38215.7AB522FA@psf.io>


Roundup Robot added the comment:

New changeset 6b16eec56854 by Serhiy Storchaka in branch 'default':
Issue #17339: Improved TypeError message in bytes constructor.
https://hg.python.org/cpython/rev/6b16eec56854

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

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

From report at bugs.python.org  Sun Apr 10 07:45:45 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Apr 2016 11:45:45 +0000
Subject: [issue26719] More efficient formatting of ints and floats in json
In-Reply-To: <1460196363.48.0.347398118701.issue26719@psf.upfronthosting.co.za>
Message-ID: <20160410114540.110022.31951.7A7B7456@psf.io>


Roundup Robot added the comment:

New changeset 4d4febb76864 by Serhiy Storchaka in branch '3.5':
Issue #26719: More efficient formatting of ints and floats in json.
https://hg.python.org/cpython/rev/4d4febb76864

New changeset 36b15a9776ae by Serhiy Storchaka in branch 'default':
Issue #26719: More efficient formatting of ints and floats in json.
https://hg.python.org/cpython/rev/36b15a9776ae

----------

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

From report at bugs.python.org  Sun Apr 10 07:50:50 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Apr 2016 11:50:50 +0000
Subject: [issue25339] sys.stdout.errors is set to "surrogateescape"
In-Reply-To: <1444287088.0.0.588605250096.issue25339@psf.upfronthosting.co.za>
Message-ID: <1460289050.93.0.365899566427.issue25339@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your review Victor. I have added yet one minor change in tests because -I doesn't suppress PYTHONIOENCODING.

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

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

From report at bugs.python.org  Sun Apr 10 07:51:37 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Apr 2016 11:51:37 +0000
Subject: [issue17339] bytes() TypeError message is misleadingly narrow
In-Reply-To: <1362254314.39.0.995387791388.issue17339@psf.upfronthosting.co.za>
Message-ID: <1460289097.65.0.33383861053.issue17339@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Apr 10 07:51:45 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Apr 2016 11:51:45 +0000
Subject: [issue17339] bytes() TypeError message is misleadingly narrow
In-Reply-To: <1362254314.39.0.995387791388.issue17339@psf.upfronthosting.co.za>
Message-ID: <1460289105.51.0.576267746458.issue17339@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Apr 10 07:52:51 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Apr 2016 11:52:51 +0000
Subject: [issue26719] More efficient formatting of ints and floats in json
In-Reply-To: <1460196363.48.0.347398118701.issue26719@psf.upfronthosting.co.za>
Message-ID: <1460289171.62.0.851128981176.issue26719@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Apr 10 08:01:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Apr 2016 12:01:33 +0000
Subject: [issue26716] EINTR handling in fcntl
In-Reply-To: <1460145033.33.0.165294517839.issue26716@psf.upfronthosting.co.za>
Message-ID: <1460289693.25.0.687555302848.issue26716@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The signal handler doesn't raise an exception in the example on StackOverflow. [1]

I think it would be nice to publish somewhere (on ActoveState receipts, on StackOverflow) well-searchable correct example.

[1] http://stackoverflow.com/questions/5255220/fcntl-flock-how-to-implement-a-timeout

----------

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

From report at bugs.python.org  Sun Apr 10 08:22:09 2016
From: report at bugs.python.org (irdb)
Date: Sun, 10 Apr 2016 12:22:09 +0000
Subject: [issue26728] make pdb.set_trace() accept debugger commands as
 arguments and run them after entering the debugger
Message-ID: <1460290929.06.0.199912788484.issue26728@psf.upfronthosting.co.za>


New submission from irdb:

I usually insert the following line in the middle of code to start the debugger from there:

import pdb; pdb.set_trace()

More often than not, I need to run some commands immediately after entering the debug mode, e.g. watch (display) some variables, create some additional break points, etc.

AFAIK currently you have to enter those commands manually on each run and there is no simple way to pass those commands from the source code.

Of-course one can invoke pdb as a script ("python3 -m pdb -c ...") and pass the desired commands to the script. But still using pdb.set_trace() is a popular method and I think it would be very useful to have set_trace() accept a list of strings as arguments and execute them right after entering the debugger.

----------
components: Interpreter Core
messages: 263135
nosy: irdb
priority: normal
severity: normal
status: open
title: make pdb.set_trace() accept debugger commands as arguments and run them after entering the debugger
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sun Apr 10 08:27:36 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Apr 2016 12:27:36 +0000
Subject: [issue15516] exception-handling bug in PyString_Format
In-Reply-To: <1343764780.71.0.604975878578.issue15516@psf.upfronthosting.co.za>
Message-ID: <20160410122733.27674.1451.CE8E2CF7@psf.io>


Roundup Robot added the comment:

New changeset a06654ca0134 by Serhiy Storchaka in branch '2.7':
Issue #13410: Fixed a bug in PyUnicode_Format where it failed to properly
https://hg.python.org/cpython/rev/a06654ca0134

----------

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

From report at bugs.python.org  Sun Apr 10 08:27:36 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Apr 2016 12:27:36 +0000
Subject: [issue13410] String formatting bug in interactive mode
In-Reply-To: <1321394690.57.0.254973831289.issue13410@psf.upfronthosting.co.za>
Message-ID: <20160410122733.27674.12237.1CFC3E8A@psf.io>


Roundup Robot added the comment:

New changeset a06654ca0134 by Serhiy Storchaka in branch '2.7':
Issue #13410: Fixed a bug in PyUnicode_Format where it failed to properly
https://hg.python.org/cpython/rev/a06654ca0134

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

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

From report at bugs.python.org  Sun Apr 10 08:28:36 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Apr 2016 12:28:36 +0000
Subject: [issue13410] String formatting bug in interactive mode
In-Reply-To: <1321394690.57.0.254973831289.issue13410@psf.upfronthosting.co.za>
Message-ID: <1460291316.66.0.877035382593.issue13410@psf.upfronthosting.co.za>


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


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Apr 10 08:29:33 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 10 Apr 2016 12:29:33 +0000
Subject: [issue20210] Provide configure options to enable/disable Python
 modules and extensions
In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za>
Message-ID: <1460291373.87.0.157868532689.issue20210@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Normally I hate environment variables, but perhaps in this case
PYTHON_DISABLE_MODULES="foo,bar,quux" would be sufficient?

Setup.py already has the "disabled_module_list" variable, it's
just a matter of setting this variable somehow.


This is really something for specialists, not general users.

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

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

From report at bugs.python.org  Sun Apr 10 08:40:32 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Apr 2016 12:40:32 +0000
Subject: [issue26623] JSON encode: more informative error
In-Reply-To: <1458744500.18.0.912653699585.issue26623@psf.upfronthosting.co.za>
Message-ID: <1460292032.79.0.594983932094.issue26623@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/issue26623>
_______________________________________

From report at bugs.python.org  Sun Apr 10 08:46:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Apr 2016 12:46:07 +0000
Subject: [issue26623] JSON encode: more informative error
In-Reply-To: <1458744500.18.0.912653699585.issue26623@psf.upfronthosting.co.za>
Message-ID: <1460292367.7.0.68078066282.issue26623@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Is there a use case where the representation is too long?

For example large bytes, bytearray or set object.

----------

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

From report at bugs.python.org  Sun Apr 10 08:47:15 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Apr 2016 12:47:15 +0000
Subject: [issue26623] JSON encode: more informative error
In-Reply-To: <1458744500.18.0.912653699585.issue26623@psf.upfronthosting.co.za>
Message-ID: <20160410124710.16611.76121.8CFB9B6B@psf.io>


Roundup Robot added the comment:

New changeset cb1ad434f10e by Serhiy Storchaka in branch 'default':
Issue #26623: TypeError message for JSON unserializible object now contains
https://hg.python.org/cpython/rev/cb1ad434f10e

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

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

From report at bugs.python.org  Sun Apr 10 08:48:02 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Apr 2016 12:48:02 +0000
Subject: [issue26623] JSON encode: more informative error
In-Reply-To: <1458744500.18.0.912653699585.issue26623@psf.upfronthosting.co.za>
Message-ID: <1460292482.89.0.184205699259.issue26623@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your contribution Mahmoud.

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

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

From report at bugs.python.org  Sun Apr 10 10:16:11 2016
From: report at bugs.python.org (Demur Rumed)
Date: Sun, 10 Apr 2016 14:16:11 +0000
Subject: [issue26722] Fold compare operators on constants (peephole)
In-Reply-To: <7280541460264906@web6g.yandex.ru>
Message-ID: <CAA1B2JyZfncuMnOZ3tU+q_mhAq=FkRFajC7EoyrGZ_TUMprGJg@mail.gmail.com>


Demur Rumed added the comment:

I submitted a patch years ago that addressses the ''x,y = 1, 2' case:
http://bugs.python.org/issue10648 & it was not met with enthusiasm

2016-04-10 5:08 GMT+00:00 Alexander Marshalov <report at bugs.python.org>:

>
> Alexander Marshalov added the comment:
>
> Hi all, this is my first patch to Python.
> I'm interested in the performance of python code, I even worked on the
> development of the static optimizer based on modifications of the AST.
> I had a few ideas for improving peepholer (for example, the expression "x,
> y = 1, 2" according to my benchmarks is about 7-11% slower than the
> expression "x = 1; y = 2", this can be fixed by using a peepholer), but I
> already understood that it is not necessary to do it.
> Thanks for the clarification, I will continue to work towards
> AST-optimizations.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue26722>
> _______________________________________
>

----------

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

From report at bugs.python.org  Sun Apr 10 10:38:31 2016
From: report at bugs.python.org (Steve Dower)
Date: Sun, 10 Apr 2016 14:38:31 +0000
Subject: [issue26727] ctypes.util.find_msvcrt() does not work in python 3.5.1
In-Reply-To: <1460283386.16.0.225166865628.issue26727@psf.upfronthosting.co.za>
Message-ID: <1460299111.75.0.129552241258.issue26727@psf.upfronthosting.co.za>


Steve Dower added the comment:

See issue23606.

Not only is your expectation incorrect, you wouldn't get sensible behavior if it was. You should generally avoid using this function, and use the msvcrt module or ctypes.cdll.msvcrt (if you don't need to interoperate with CPython itself).

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> ctypes.util.find_library("c") no longer makes sense

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

From report at bugs.python.org  Sun Apr 10 10:58:11 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 10 Apr 2016 14:58:11 +0000
Subject: [issue26728] make pdb.set_trace() accept debugger commands as
 arguments and run them after entering the debugger
In-Reply-To: <1460290929.06.0.199912788484.issue26728@psf.upfronthosting.co.za>
Message-ID: <1460300291.7.0.993294545038.issue26728@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Extension Modules, Library (Lib) -Interpreter Core
nosy: +georg.brandl

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

From report at bugs.python.org  Sun Apr 10 11:12:38 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Apr 2016 15:12:38 +0000
Subject: [issue26200] SETREF adds unnecessary work in some cases
In-Reply-To: <1453745024.51.0.674954872761.issue26200@psf.upfronthosting.co.za>
Message-ID: <20160410151235.16621.84646.C9D8CBA6@psf.io>


Roundup Robot added the comment:

New changeset 9cf8572abe58 by Serhiy Storchaka in branch '2.7':
Issue #26200: Added Py_SETREF and replaced Py_XSETREF with Py_SETREF
https://hg.python.org/cpython/rev/9cf8572abe58

New changeset 66fafa13a711 by Serhiy Storchaka in branch '3.5':
Issue #26200: Added Py_SETREF and replaced Py_XSETREF with Py_SETREF
https://hg.python.org/cpython/rev/66fafa13a711

New changeset d758c5965199 by Serhiy Storchaka in branch 'default':
Issue #26200: Added Py_SETREF and replaced Py_XSETREF with Py_SETREF
https://hg.python.org/cpython/rev/d758c5965199

----------

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

From report at bugs.python.org  Sun Apr 10 11:45:06 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 10 Apr 2016 15:45:06 +0000
Subject: [issue20210] Provide configure options to enable/disable Python
 modules and extensions
In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za>
Message-ID: <1460303106.82.0.923293128633.issue20210@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

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

From report at bugs.python.org  Sun Apr 10 13:54:40 2016
From: report at bugs.python.org (Erik Welch)
Date: Sun, 10 Apr 2016 17:54:40 +0000
Subject: [issue26729] Incorrect __text_signature__ for sorted
Message-ID: <1460310880.55.0.462687598027.issue26729@psf.upfronthosting.co.za>


New submission from Erik Welch:

The first argument to sorted is positional-only, so the text signature should be:

sorted($module, iterable, /, key=None, reverse=False)

instead of

sorted($module, iterable, key=None, reverse=False)

To reproduce the issue, attempt to use "iterable" as a keyword argument:

>>> import inspect
>>> sig = inspect.signature(sorted)
>>> sig.bind(iterable=[])  # should raise, but doesn't
>>> sorted(iterable=[])  # raises TypeError

----------
components: Extension Modules, Library (Lib)
files: sorted_1.diff
keywords: patch
messages: 263145
nosy: eriknw
priority: normal
severity: normal
status: open
title: Incorrect __text_signature__ for sorted
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file42422/sorted_1.diff

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

From report at bugs.python.org  Sun Apr 10 14:49:01 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 10 Apr 2016 18:49:01 +0000
Subject: [issue26729] Incorrect __text_signature__ for sorted
In-Reply-To: <1460310880.55.0.462687598027.issue26729@psf.upfronthosting.co.za>
Message-ID: <1460314141.7.0.80236080707.issue26729@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Interpreter Core -Extension Modules, Library (Lib)
nosy: +ncoghlan
stage:  -> patch review
versions: +Python 3.6

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

From report at bugs.python.org  Sun Apr 10 15:04:59 2016
From: report at bugs.python.org (Bernard Spil)
Date: Sun, 10 Apr 2016 19:04:59 +0000
Subject: [issue24557] Refactor LibreSSL / EGD detection
In-Reply-To: <1435926751.49.0.18395819216.issue24557@psf.upfronthosting.co.za>
Message-ID: <1460315099.65.0.0288313111715.issue24557@psf.upfronthosting.co.za>


Bernard Spil added the comment:

This is now also required for the upcoming OpenSSL 1.1.0 which also removed EGD by default

----------

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

From report at bugs.python.org  Sun Apr 10 15:11:43 2016
From: report at bugs.python.org (James Hennessy)
Date: Sun, 10 Apr 2016 19:11:43 +0000
Subject: [issue26730] SpooledTemporaryFile doesn't correctly preserve data for
 text (non-binary) SpooledTemporaryFile objects when Unicode
 characters are written
Message-ID: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>


New submission from James Hennessy:

The tempfile.SpooledTemporaryFile class doesn't correctly preserve data for text (non-binary) SpooledTemporaryFile objects when Unicode characters are written.  The attached program demonstrates the failure.  It creates a SpooledTemporaryFile object, writes 20 string characters to it, and then tries to read them back.  If the SpooledTemporaryFile has rolled over to disk, as it does in the demonstration program, then the data is not read back correctly.  Instead, an exception is recognized due to the data in the SpooledTemporaryFile being corrupted.

The problem is this statement in tempfile.py, in the rollover() method:
        newfile.seek(file.tell(), 0)
The "file" variable references a StringIO object, whose tell() and seek() methods count in characters, not bytes, yet this value is applied to a TemporaryFile object, whose tell() and seek() methods deal in bytes, not characters.  The demonstration program writes 10 characters to the SpooledTemporaryFile.  Since 10 exceeds the rollover size of 5, the implementation writes the 10 characters to the TemporaryFile and then seeks to position 10 in the TemporaryFile, which it thinks is the end of the stream.  But those 10 characters got encoded to 30 bytes, and seek position 10 is in the middle of the UTF-8 sequence for the fourth character.  The next write to the SpooledTemporaryFile starts overlaying bytes from there.  The attempt to read back the data fails because the byte stream no longer represents a valid UTF-8 stream of data.

The related problem is the inconsistency of the behavior of tell() and seek() for text (non-binary) SpooledTemporaryFile objects.  If the data hasn't yet rolled over to a TemporaryFile, they count in string characters.  If the data has rolled over, they count in bytes.

A quick fix for this is to remove the seek() in the rollover() method.  I presume it's there to preserve the stream position if an explicit call to rollover() is made, since for an implicit call, the position would be at the end of the stream already.  This quick fix, therefore, would introduce an external incompatibility in the behavior of rollover().

Another possibility is to never use a StringIO object, but to always buffer data in a BytesIO object, as is done for binary SpooledTemporaryFile objects.  This has the advantage of "fixing" the tell() and seek() inconsistency, making them count bytes all the time.  The downside, of course, is that data that doesn't end up being rolled over to a TemporaryFile gets encoded and decoded, a round trip that could otherwise be avoided.

This problem can be circumvented by a user of SpooledTemporaryFile by explicitly seeking to the end of the stream after every write to the SpooledTemporaryFile object:  spool.seek(0, io.SEEK_END)

----------
components: Library (Lib)
files: showbug.py
messages: 263147
nosy: James Hennessy
priority: normal
severity: normal
status: open
title: SpooledTemporaryFile doesn't correctly preserve data for text (non-binary) SpooledTemporaryFile objects when Unicode characters are written
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file42423/showbug.py

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

From report at bugs.python.org  Sun Apr 10 15:25:33 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 10 Apr 2016 19:25:33 +0000
Subject: [issue26730] SpooledTemporaryFile doesn't correctly preserve data for
 text (non-binary) SpooledTemporaryFile objects when Unicode
 characters are written
In-Reply-To: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>
Message-ID: <1460316333.97.0.179320766086.issue26730@psf.upfronthosting.co.za>


R. David Murray added the comment:

I can't see why it even does the seek.  The existing tests pass without it.  Does your example?

Either way, the first step here is for someone to turn this into a unit test for the tempfile module (in test_tempfile).

----------
nosy: +r.david.murray
stage:  -> needs patch
versions: +Python 3.5, Python 3.6 -Python 3.4

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

From report at bugs.python.org  Sun Apr 10 16:21:53 2016
From: report at bugs.python.org (Matt Peters)
Date: Sun, 10 Apr 2016 20:21:53 +0000
Subject: [issue26731] subprocess on windows leaks stdout/stderr handle to
 child process when stdout/stderr overridden
Message-ID: <1460319713.01.0.037399080694.issue26731@psf.upfronthosting.co.za>


New submission from Matt Peters:

Tested in on Windows 8.1 with python 2.7.5.

I have a parent process that creates a child process and calls communicate to get stdout/stderr from the child.  The child process calls a persistent process, with stdout/stderr/stdin set to os.devnull, and then exits without waiting on the child process.  Sample code is below.

The child process exits successfully, but communicate on the the parent process does not return until the persistent process is terminated.  Expected behavior is that the child process closes its stdout/stderr pipes on exit, and those pipes are not open anywhere else, so the parent process returns from communicate once the child process exits.

One fix that stops the bug from manifesting is to edit subprocess.py:954 and pass in FALSE for inherit_handles in the call to _subprocess.CreateProcess rather than passing in int(not close_fds).  With the current code there is no way for the user of subprocess to trigger this behavior, because close_fds is necessarily False when redirecting stdout/stderr/stdin due to an exception raised in the Popen constructor.

I believe the proper fix to set close_fds to True, and pass in the handles through startupinfo, if any one of the pipes has been redirected.  This will require some changes to _get_handles and some significant testing.

A workaround fix that is easier to implement is to remove the assertion in the Popen constructor and allow the caller to specify close_fds=True even when redirecting one of the inputs.

Test case:
Three programs: parent.py, child.py, and persistent.py.
Launch parent.py.
Behavior:
child.py returns immediately
resident.py exits after 10 seconds
parent.py prints its output and exits immediately after resident.py exits

Expected Behavior:
child.py returns immediately
parent.py prints its output and exits immediately after child.py exits
resident.py exits after 10 seconds


############### parent.py ##########################
import subprocess

proc = subprocess.Popen("python child.py", stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
(output, error) = proc.communicate()
print 'parent complete'

############### child.py ###########################
import os
import subprocess

with open(os.devnull, 'w') as devnull:
    proc = subprocess.Popen('python resident.py', stdout=devnull, stderr=devnull, stdin=devnull)

############### resident.py ########################
import time
time.sleep(10)

----------
components: Windows
messages: 263149
nosy: paul.moore, saifujinaro, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: subprocess on windows leaks stdout/stderr handle to child process when stdout/stderr overridden
versions: Python 2.7

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

From report at bugs.python.org  Sun Apr 10 16:40:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Apr 2016 20:40:07 +0000
Subject: [issue26730] SpooledTemporaryFile doesn't correctly preserve data for
 text (non-binary) SpooledTemporaryFile objects when Unicode
 characters are written
In-Reply-To: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>
Message-ID: <1460320807.17.0.838246431873.issue26730@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch that fixes SpooledTemporaryFile by getting rid of StringIO.

----------
keywords: +patch
nosy: +serhiy.storchaka
stage: needs patch -> patch review
Added file: http://bugs.python.org/file42424/spooled_text_tempfile.patch

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

From report at bugs.python.org  Sun Apr 10 17:12:00 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sun, 10 Apr 2016 21:12:00 +0000
Subject: [issue26705] logging.Handler.handleError should be called from
 logging.Handler.handle
In-Reply-To: <1459973017.82.0.820573021891.issue26705@psf.upfronthosting.co.za>
Message-ID: <1460322720.17.0.348532926697.issue26705@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

I see the backwards compatibility issue. I have two suggestion's how to improve the code without breaking backwards compatibility:

1. Add a new Handler class named SafeHandler that will implement handle in the way suggested in the previous patch. All the stdlib handler's will inherit from SafeHandler and in the documentation we will suggest using this handler. I am adding a patch (logging-SafeGandle.patch) with this suggestion.

2. Add new module-level attribute handleException that will deprecate raiseException. When raiseException is set or when handleException is at the default value the current behavior will remain. You can set handleException to the following values:
   a. print - print exception to stderr
   b. propagate - propagate exception
   c. ignore - swallow the exception

The current behavior has a few inconsistencies with raiseException. For example when raiseException is True the handleError method don't propagate the excpetion as will be expected. This patch will solve this problem in addition to the one named in the previous message. I am adding a patch with this suggested behavior (logging-handleException). 

Both patch's are in initial steps and are just to show more clearly what i am suggesting. There are currently no tests or documentation for either patch. Both patch's pass all logging test's without any changes to prove the backwards compatibility.

----------
Added file: http://bugs.python.org/file42425/logging-SafeHandle.patch

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

From report at bugs.python.org  Sun Apr 10 17:12:18 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sun, 10 Apr 2016 21:12:18 +0000
Subject: [issue26705] logging.Handler.handleError should be called from
 logging.Handler.handle
In-Reply-To: <1459973017.82.0.820573021891.issue26705@psf.upfronthosting.co.za>
Message-ID: <1460322738.93.0.824061477316.issue26705@psf.upfronthosting.co.za>


Changes by Aviv Palivoda <palaviv at gmail.com>:


Added file: http://bugs.python.org/file42426/logging-handleException.patch

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

From report at bugs.python.org  Sun Apr 10 17:20:19 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 10 Apr 2016 21:20:19 +0000
Subject: [issue25609] Add a ContextManager ABC and type
In-Reply-To: <1447355679.68.0.225089426373.issue25609@psf.upfronthosting.co.za>
Message-ID: <1460323219.61.0.991905050035.issue25609@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks for fixing the doc bug, Martin. Too much Markdown lately. :)

----------

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

From report at bugs.python.org  Sun Apr 10 17:58:21 2016
From: report at bugs.python.org (Kevin Quick)
Date: Sun, 10 Apr 2016 21:58:21 +0000
Subject: [issue26732] multiprocessing sentinel resource leak
Message-ID: <1460325501.58.0.225914662536.issue26732@psf.upfronthosting.co.za>


New submission from Kevin Quick:

The sentinel creates a named pipe, but the parent's end of the pipe is inherited by subsequently created children.  

import multiprocessing,signal,sys
def sproc(x): signal.pause()
for each in range(int(sys.argv[1])):
  multiprocessing.Process(target=sproc, args=(each,)).start()
signal.pause()

Running the above on Linux with varying numbers of child processes (expressed as the argument to the above) and using techniques like "$ sudo ls /proc/NNNN/fd" it is possible to see an ever growing number of pipe connections for subsequent children.

----------
components: Library (Lib)
messages: 263153
nosy: quick-b
priority: normal
severity: normal
status: open
title: multiprocessing sentinel resource leak
type: resource usage
versions: Python 3.5

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

From report at bugs.python.org  Sun Apr 10 17:59:12 2016
From: report at bugs.python.org (Kevin Quick)
Date: Sun, 10 Apr 2016 21:59:12 +0000
Subject: [issue26732] multiprocessing sentinel resource leak
In-Reply-To: <1460325501.58.0.225914662536.issue26732@psf.upfronthosting.co.za>
Message-ID: <1460325552.09.0.586345714702.issue26732@psf.upfronthosting.co.za>


Kevin Quick added the comment:

(Sorry, an unnamed pipe, but a pipe nonetheless.)

----------

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

From report at bugs.python.org  Sun Apr 10 18:00:01 2016
From: report at bugs.python.org (Davin Potts)
Date: Sun, 10 Apr 2016 22:00:01 +0000
Subject: [issue26732] multiprocessing sentinel resource leak
In-Reply-To: <1460325501.58.0.225914662536.issue26732@psf.upfronthosting.co.za>
Message-ID: <1460325601.65.0.397029324046.issue26732@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/issue26732>
_______________________________________

From report at bugs.python.org  Sun Apr 10 18:46:59 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 10 Apr 2016 22:46:59 +0000
Subject: [issue26729] Incorrect __text_signature__ for sorted
In-Reply-To: <1460310880.55.0.462687598027.issue26729@psf.upfronthosting.co.za>
Message-ID: <1460328419.8.0.0515674732819.issue26729@psf.upfronthosting.co.za>


Martin Panter added the comment:

This is a strange case. It looks like ?iterable? is half-supported as a keyword argument. So Silent Ghost?s patch fixes the signature, but the code still tries to accept keyword arguments:

>>> sorted(iterable=None)
TypeError: 'NoneType' object is not iterable
>>> sorted(iterable=())
TypeError: 'iterable' is an invalid keyword argument for this function

The problem is that sorted() blindly passes the keyword arguments to list.sort(). I guess we could delete "iterable" from them, but maybe it is not worth the trouble.

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

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

From report at bugs.python.org  Sun Apr 10 18:58:44 2016
From: report at bugs.python.org (Sai)
Date: Sun, 10 Apr 2016 22:58:44 +0000
Subject: [issue26731] subprocess on windows leaks stdout/stderr handle to
 child process when stdout/stderr overridden
In-Reply-To: <1460319713.01.0.037399080694.issue26731@psf.upfronthosting.co.za>
Message-ID: <1460329124.94.0.138885617941.issue26731@psf.upfronthosting.co.za>


Sai added the comment:

You can workaround this problem by adding a middleman process that sets close_fds=True:

############### childworkaround.py #################
import os
import subprocess

with open(os.devnull, 'w') as devnull:
    script = "import subprocess; import sys; subprocess.Popen(sys.argv[1:], close_fds=True)"
    proc = subprocess.Popen(['python', '-c', script, 'python', 'resident.py'], stdout=devnull, stderr=devnull, stdin=devnull)

----------

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

From report at bugs.python.org  Sun Apr 10 19:52:26 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 10 Apr 2016 23:52:26 +0000
Subject: [issue26730] SpooledTemporaryFile doesn't correctly preserve data for
 text (non-binary) SpooledTemporaryFile objects when Unicode
 characters are written
In-Reply-To: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>
Message-ID: <1460332345.99.0.862545107012.issue26730@psf.upfronthosting.co.za>


Martin Panter added the comment:

David: I guess the seek() is to support rollover() when you are positioned halfway through the file.

Serhiy?s patch seems to be about the best we can do, although it does break the documented promise that the ? ?_file? attribute is either an io.BytesIO or io.StringIO?.

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

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

From report at bugs.python.org  Sun Apr 10 20:21:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 11 Apr 2016 00:21:35 +0000
Subject: [issue26712] Unify (r)split(), (l/r)strip() method tests
In-Reply-To: <1460106175.71.0.116518416175.issue26712@psf.upfronthosting.co.za>
Message-ID: <1460334095.37.0.968151473497.issue26712@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/issue26712>
_______________________________________

From report at bugs.python.org  Sun Apr 10 21:20:28 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Apr 2016 01:20:28 +0000
Subject: [issue26685] Raise errors from socket.close()
In-Reply-To: <1459509388.35.0.801044830009.issue26685@psf.upfronthosting.co.za>
Message-ID: <20160411012024.18857.45880.16CCCB7A@psf.io>


Roundup Robot added the comment:

New changeset bd665613ed67 by Martin Panter in branch 'default':
Issue #26685: Raise OSError if closing a socket fails
https://hg.python.org/cpython/rev/bd665613ed67

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

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

From report at bugs.python.org  Sun Apr 10 21:20:28 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Apr 2016 01:20:28 +0000
Subject: [issue26585] Use html.escape to replace _quote_html in http.server
In-Reply-To: <1458271086.94.0.0961534377342.issue26585@psf.upfronthosting.co.za>
Message-ID: <20160411012024.18857.22692.95E65121@psf.io>


Roundup Robot added the comment:

New changeset bf44913588b7 by Martin Panter in branch 'default':
Issue #26585: Eliminate _quote_html() and use html.escape(quote=False)
https://hg.python.org/cpython/rev/bf44913588b7

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

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

From report at bugs.python.org  Sun Apr 10 22:47:20 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Apr 2016 02:47:20 +0000
Subject: [issue14456] Relation between threads and signals unclear
In-Reply-To: <1333149178.59.0.333821086904.issue14456@psf.upfronthosting.co.za>
Message-ID: <20160411024717.11838.98224.540BC77A@psf.io>


Roundup Robot added the comment:

New changeset 73050563053f by Martin Panter in branch '3.5':
Issue #14456: Remove contradiction about blocking signals from bad merge
https://hg.python.org/cpython/rev/73050563053f

New changeset a8dbe6016a31 by Martin Panter in branch 'default':
Issue #14456: Merge signal doc fix from 3.5
https://hg.python.org/cpython/rev/a8dbe6016a31

----------

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

From report at bugs.python.org  Sun Apr 10 22:51:21 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 11 Apr 2016 02:51:21 +0000
Subject: [issue26685] Raise errors from socket.close()
In-Reply-To: <1459509388.35.0.801044830009.issue26685@psf.upfronthosting.co.za>
Message-ID: <1460343081.96.0.685374450715.issue26685@psf.upfronthosting.co.za>


Martin Panter added the comment:

I tweaked the test again for Windows, anticipating that it will raise ENOTSOCK rather than EBADF.

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

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

From report at bugs.python.org  Sun Apr 10 23:34:05 2016
From: report at bugs.python.org (David Ward)
Date: Mon, 11 Apr 2016 03:34:05 +0000
Subject: [issue25187] bdist_rpm fails due to wrong hardcoded assumption about
 RPM filename format
In-Reply-To: <1442715156.03.0.0265256317041.issue25187@psf.upfronthosting.co.za>
Message-ID: <1460345645.06.0.396478822181.issue25187@psf.upfronthosting.co.za>


David Ward added the comment:

Ping to review patch please...

----------

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

From report at bugs.python.org  Sun Apr 10 23:46:22 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 11 Apr 2016 03:46:22 +0000
Subject: [issue24291] wsgiref.handlers.SimpleHandler truncates large output
 blobs
In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za>
Message-ID: <1460346382.6.0.826070872738.issue24291@psf.upfronthosting.co.za>


Martin Panter added the comment:

In patch v2 I integrated a version of the test into test_wsgiref. I swapped the sleep() calls for a threading.Event object.

Because my patch is such a large change, it would be good to get other people?s opinions or reviews.

----------
Added file: http://bugs.python.org/file42427/wfile-partial.v2.patch

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

From report at bugs.python.org  Mon Apr 11 00:04:32 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 11 Apr 2016 04:04:32 +0000
Subject: [issue26585] Use html.escape to replace _quote_html in http.server
In-Reply-To: <1458271086.94.0.0961534377342.issue26585@psf.upfronthosting.co.za>
Message-ID: <1460347472.69.0.519390726125.issue26585@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the patch Xiang

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

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

From report at bugs.python.org  Mon Apr 11 01:29:35 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 Apr 2016 05:29:35 +0000
Subject: [issue26200] SETREF adds unnecessary work in some cases
In-Reply-To: <1453745024.51.0.674954872761.issue26200@psf.upfronthosting.co.za>
Message-ID: <1460352575.44.0.300700177247.issue26200@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thank you.  Can this be closed now?

----------

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

From report at bugs.python.org  Mon Apr 11 02:02:52 2016
From: report at bugs.python.org (leycec)
Date: Mon, 11 Apr 2016 06:02:52 +0000
Subject: [issue25061] Add native enum support for argparse
In-Reply-To: <1441908245.42.0.23532628335.issue25061@psf.upfronthosting.co.za>
Message-ID: <1460354572.86.0.975431106972.issue25061@psf.upfronthosting.co.za>


leycec added the comment:

I strongly support this feature request. Unsurprisingly, I wholeheartedly agree with desbma's heroic persistence and wholeheartedly disagree with rhettinger's curt dismissal.

> IMO, this adds more complexity than it solves.

Strongly disagree. Because "argparse" fails to support the core "Enum" type out-of-the-box, I now have to either (A) duplicate desbma's boilerplate or (B) duplicate paul.j3's original "EnumType" factory or desbma's revised "EnumType" factory across multiple "argparse"-based CLI interfaces in multiple Python applications having discrete codebases.

Both approaches are noxious, substantially increasing implementation burden and technical debt. While obviously feasible, both approaches violate DRY, invite code desynchronization and concomitant bugs, inhibit maintainability, intelligibility, and documentability, and... the list just crawls on.

DRY violations add complexity. Avoiding DRY violations decreases complexity.

> Argparse already has more options than people can remember.

That's what front-facing documentation, queryable docstrings, and https://docs.python.org/3/library/argparse.html are for. No one remembers even a tenth of the functionality provided by "argparse" or any other reasonably deep module (e.g., "importlib", "subprocess") in the stdlib, yet the stdlib justifiably grows, improves, and strengthens with time.

This is a good thing. API memorability and mnemonics, however, are not. We have machine lookup. Ergo, API memorability and mnemonics are poor metrics by which to gauge feature creep.

I'd hoped it would be intuitively obvious that "Enum" support should be officially added to "argparse". Enums are a core type native to most high-level languages, now including Python. Enum-based argument parsing is a Pythonic solution for string arguments accepting only a well-known set of valid alternatives. The stdlib itself is internally (albeit incrementally) migrating from non-Enums to Enums.

This needs to happen.

----------
nosy: +leycec

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

From report at bugs.python.org  Mon Apr 11 02:58:13 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Apr 2016 06:58:13 +0000
Subject: [issue26200] SETREF adds unnecessary work in some cases
In-Reply-To: <1453745024.51.0.674954872761.issue26200@psf.upfronthosting.co.za>
Message-ID: <20160411065810.19044.37519.76851CBB@psf.io>


Roundup Robot added the comment:

New changeset aa5dbc32d313 by Serhiy Storchaka in branch '3.5':
Issue #26200: Restored more safe usages of Py_SETREF.
https://hg.python.org/cpython/rev/aa5dbc32d313

New changeset f21740a1abde by Serhiy Storchaka in branch '2.7':
Issue #26200: Restored more safe usages of Py_SETREF.
https://hg.python.org/cpython/rev/f21740a1abde

New changeset 144b78ac2077 by Serhiy Storchaka in branch 'default':
Issue #26200: Restored more safe usages of Py_SETREF.
https://hg.python.org/cpython/rev/144b78ac2077

----------

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

From report at bugs.python.org  Mon Apr 11 03:02:41 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 11 Apr 2016 07:02:41 +0000
Subject: [issue26200] SETREF adds unnecessary work in some cases
In-Reply-To: <1453745024.51.0.674954872761.issue26200@psf.upfronthosting.co.za>
Message-ID: <1460358161.4.0.169498771255.issue26200@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Restored safe usage of Py_SETREFs introduced not in issue20440: in issue25928, changeset 3292b4862627, and issue25945.

----------

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

From report at bugs.python.org  Mon Apr 11 03:06:25 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 11 Apr 2016 07:06:25 +0000
Subject: [issue26200] SETREF adds unnecessary work in some cases
In-Reply-To: <1453745024.51.0.674954872761.issue26200@psf.upfronthosting.co.za>
Message-ID: <1460358385.43.0.661682622482.issue26200@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch that adds extra usages of the Py_SETREF() macro (in particular in deque implementation). It doesn't fix bugs or improve performance, but makes the code shorter and perhaps makes it more readable.

If you think that some of these changes really improve readability (I think not all of them), let me know and I'll commit selected changes. Otherwise I'll just close this issue.

Currently Py_XSETREF is used 118 times and Py_SETREF is used 59 times. py_setref_extra.patch adds 44 new usages of Py_SETREF.

----------
Added file: http://bugs.python.org/file42428/py_setref_extra.patch

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

From report at bugs.python.org  Mon Apr 11 03:15:56 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 11 Apr 2016 07:15:56 +0000
Subject: [issue26585] Use html.escape to replace _quote_html in http.server
In-Reply-To: <1458271086.94.0.0961534377342.issue26585@psf.upfronthosting.co.za>
Message-ID: <1460358956.6.0.742066998298.issue26585@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Happy to see it works. Thanks for your reviews too. :)

----------

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

From report at bugs.python.org  Mon Apr 11 03:40:55 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 11 Apr 2016 07:40:55 +0000
Subject: [issue22659] SyntaxError in the configure_ctypes
In-Reply-To: <1413565915.5.0.655058689376.issue22659@psf.upfronthosting.co.za>
Message-ID: <1460360455.54.0.0949846567264.issue22659@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report.

I think this is a problem in your dev environment (wrong path or something like that). For some reason, you are trying to run Python 3 setup.py in Python 2.

----------
nosy: +berker.peksag
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: compile error -> behavior

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

From report at bugs.python.org  Mon Apr 11 04:40:24 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 11 Apr 2016 08:40:24 +0000
Subject: [issue26732] multiprocessing sentinel resource leak
In-Reply-To: <1460325501.58.0.225914662536.issue26732@psf.upfronthosting.co.za>
Message-ID: <1460364024.89.0.231622941529.issue26732@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +jnoller, sbt

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

From report at bugs.python.org  Mon Apr 11 05:29:54 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 11 Apr 2016 09:29:54 +0000
Subject: [issue26720] memoryview from BufferedWriter becomes garbage
In-Reply-To: <1460203726.07.0.470306343445.issue26720@psf.upfronthosting.co.za>
Message-ID: <1460366994.81.0.301546229033.issue26720@psf.upfronthosting.co.za>


Martin Panter added the comment:

To create a memoryview with unlimited lifetime, I understand we need to nominate an ?exporting object?, which becomes memoryview.obj. Using a bytes object here might be the simplest fix for just BufferedWriter.

However it looks like the buffer is shared with BufferedReader and others. To fix the analogous bug with BufferedReader, a bytearray might be better, because the user could see it being mutated when reading into the memoryview.

I think bytearray might be okay for BufferedWriter too, as long as we prevent it being resized. The user would be able to alter the contents of the buffer, but I don?t see that as a problem. An alternative would be a new opaque object that doesn?t do much except have a reference count.

----------

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

From report at bugs.python.org  Mon Apr 11 05:39:53 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Apr 2016 09:39:53 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <20160411093947.16631.42576.8F4A9DFE@psf.io>


Roundup Robot added the comment:

New changeset ce721df212cf by Serhiy Storchaka in branch '3.5':
Issue #25910: Fixed dead links in the docs.
https://hg.python.org/cpython/rev/ce721df212cf

New changeset 14e00e7e4d51 by Georg Brandl in branch '2.7':
Closes #25910: fix dead and permanently redirected links in the docs. Thanks to SilentGhost for the patch.
https://hg.python.org/cpython/rev/14e00e7e4d51

New changeset 00addbb47c5c by Serhiy Storchaka in branch '2.7':
Issue #25910: Fixed dead links in the docs.
https://hg.python.org/cpython/rev/00addbb47c5c

New changeset 15c4557af8e0 by Serhiy Storchaka in branch 'default':
Issue #25910: Fixed dead links in the docs.
https://hg.python.org/cpython/rev/15c4557af8e0

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

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

From report at bugs.python.org  Mon Apr 11 05:40:43 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 11 Apr 2016 09:40:43 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1460367643.52.0.632102179483.issue25910@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Following dead links left:

Doc/library/xmlrpc.client.rst
(line   42) broken    http://ontosys.com/xml-rpc/extensions.php - <urlopen error timed out>

Doc/license.rst
(line   22) broken    http://www.zope.com/ - <urlopen error [Errno -2] Name or service not known>
(line  131) broken    http://www.pythonlabs.com/logos.html - HTTP Error 404: Not Found

Doc/using/windows.rst
(line  271) broken    http://www.swaroopch.com/notes/python/#install_windows - Anchor 'install_windows' not found

Doc/whatsnew/2.1.rst
(line  543) broken    http://www.vex.net/parnassus/ - HTTP Error 404: Not Found

Doc/whatsnew/2.6.rst
(line  174) broken    http://svn.python.org/view/tracker/importer/ - HTTP Error 404: Not Found
(line  193) broken    http://svn.python.org/view/tracker/importer/ - HTTP Error 404: Not Found

Doc/whatsnew/2.7.rst
(line 1529) broken    http://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT - Anchor 'CIPHER_LIST_FORMAT' not found
(line 1618) broken    http://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT - Anchor 'CIPHER_LIST_FORMAT' not found

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

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

From report at bugs.python.org  Mon Apr 11 05:50:05 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 11 Apr 2016 09:50:05 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1460368205.24.0.132916604462.issue25910@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Apr 11 05:56:33 2016
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 11 Apr 2016 09:56:33 +0000
Subject: [issue26673] Tkinter error when opening IDLE configuration menu
In-Reply-To: <1459351920.73.0.899924616631.issue26673@psf.upfronthosting.co.za>
Message-ID: <1460368593.84.0.331239331624.issue26673@psf.upfronthosting.co.za>


Petr Viktorin added the comment:

I can reproduce this with Python 2.7.11 and somewhat recent build from hg default (3.6.0a0) on Fedora 23.
Putting these lines in my personal config-main.cfg solves this::

    [EditorWindow]
    font= courier

idlelib/config-main.def has a different default::

    [EditorWindow]
    font= TkFixedFont

Putting that value in my personal config-main.cfg makes the bug manifest itself again.
With "nonexistent-font-name-7202125ed0a", the bug does not appear.
With an existing font, "DejaVu Sans Mono", the bug does not appear.

I hacked the code to get the values used in the line, ``self.tk.call(_flatten((self._w, cmd)) + self._options(cnf))``. For TkFixedFont (the buggy case), they are::

    self._w: '.139719100555208.139719021773312.139719021373632.139719021374064.139719021375144.13971902101484
0.139719021045736.139719021045880'
    cmd: 'configure'
    cnf: {'font': ('dejavu sans mono', '', 'normal')}
    _flatten((self._w, cmd)): ('.139719100555208.139719021773312.139719021373632.139719021374064.139719021375144.1397190210148
40.139719021045736.139719021045880', 'configure')
    self._options(cnf): ('-font', u'{dejavu sans mono} {} normal')

For the good case ("courier" font):

    self._w:'.140181531287496.140181452501216.140181451999568.140181451999712.140181452055904.140181451660176.140181451660464',
    cmd: 'configure'
    cnf: {'font': ('courier', '10', 'normal')}
    _flatten((self._w, cmd)): ('.140181531287496.140181452501216.140181451999568.140181451999712.140181452055904.140181451660176.140181451660464', 'configure')
    self._options(cnf):  ('-font', u'courier 10 normal')

The difference is indeed that it's getting an empty string for the font size.
This happens even if "font-size= 10" is explicitly in the config file.

At this point I'm not sure how to investigate further. Could someone more familiar with Tk look at the issue? I'll be happy to provide more information. (Hopefully bugs.python.org notifications reach my inbox.)

----------
nosy: +encukou

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

From report at bugs.python.org  Mon Apr 11 06:19:34 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 11 Apr 2016 10:19:34 +0000
Subject: [issue26733] staticmethod and classmethod are ignored when
 disassemble class
Message-ID: <1460369974.2.0.716803365246.issue26733@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

Though the documentation tells when disassembling a class, it disassembles all methods for dis.dis, but staticmethod and classmethod are ignored. I don't know whether this is intended.

I write to patch to add staticmethod and classmethod. But unfortunately when I write tests, one unrelated test fails and I cannot figure out why.

----------
files: add_staticmethod_and_classmethod_when_dis.dis_a_class.patch
keywords: patch
messages: 263176
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title: staticmethod and classmethod are ignored when disassemble class
Added file: http://bugs.python.org/file42429/add_staticmethod_and_classmethod_when_dis.dis_a_class.patch

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

From report at bugs.python.org  Mon Apr 11 06:20:08 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 11 Apr 2016 10:20:08 +0000
Subject: [issue26733] staticmethod and classmethod are ignored when
 disassemble class
In-Reply-To: <1460369974.2.0.716803365246.issue26733@psf.upfronthosting.co.za>
Message-ID: <1460370008.7.0.534791274722.issue26733@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
components: +Library (Lib)
type:  -> behavior
versions: +Python 3.6

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

From report at bugs.python.org  Mon Apr 11 06:31:21 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 11 Apr 2016 10:31:21 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1460370681.66.0.213726055291.issue25910@psf.upfronthosting.co.za>


SilentGhost added the comment:

Licence text shouldn't be touched, I think.

http://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT became https://www.openssl.org/docs/manmaster/apps/ciphers.html#CIPHER-LIST-FORMAT

If Martin still have the importer code somewhere, he probably could provide an up to date link.

----------

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

From report at bugs.python.org  Mon Apr 11 06:39:34 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 11 Apr 2016 10:39:34 +0000
Subject: [issue26733] staticmethod and classmethod are ignored when
 disassemble class
In-Reply-To: <1460369974.2.0.716803365246.issue26733@psf.upfronthosting.co.za>
Message-ID: <1460371174.6.0.137580608285.issue26733@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Though don't know why but simply replace %-4d with %3d in dis_bug708901 can fix the test. I updated the patch so all the tests pass and then I'll spend some time figuring out why.

----------
Added file: http://bugs.python.org/file42430/add_staticmethod_and_classmethod_when_dis.dis_a_class_v2.patch

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

From report at bugs.python.org  Mon Apr 11 06:58:15 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 11 Apr 2016 10:58:15 +0000
Subject: [issue26733] staticmethod and classmethod are ignored when
 disassemble class
In-Reply-To: <1460369974.2.0.716803365246.issue26733@psf.upfronthosting.co.za>
Message-ID: <1460372295.56.0.495361068424.issue26733@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +ncoghlan, yselivanov
stage:  -> patch review

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

From report at bugs.python.org  Mon Apr 11 07:33:39 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 11 Apr 2016 11:33:39 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1460374419.32.0.832450896647.issue25910@psf.upfronthosting.co.za>


Martin Panter added the comment:

The bug tracker importer still exists if you know what revision to look it up in: <http://svn.python.org/view/tracker/importer/?pathrev=88980>

----------

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

From report at bugs.python.org  Mon Apr 11 09:29:10 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 11 Apr 2016 13:29:10 +0000
Subject: [issue25731] Assigning and deleting __new__ attr on the class does
 not allow to create instances of this class
In-Reply-To: <1448454590.41.0.350843358205.issue25731@psf.upfronthosting.co.za>
Message-ID: <1460381350.91.0.683036935178.issue25731@psf.upfronthosting.co.za>


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


----------
status: closed -> open

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

From report at bugs.python.org  Mon Apr 11 10:13:19 2016
From: report at bugs.python.org (Antti Haapala)
Date: Mon, 11 Apr 2016 14:13:19 +0000
Subject: [issue26601] Use new madvise()'s MADV_FREE on the private heap
In-Reply-To: <1458557514.95.0.774301964914.issue26601@psf.upfronthosting.co.za>
Message-ID: <1460383999.12.0.00920568585057.issue26601@psf.upfronthosting.co.za>


Antti Haapala added the comment:

... and it turns out that munmapping is not always that smart thing to do: http://stackoverflow.com/questions/36548518/variable-assignment-faster-than-one-liner

----------
nosy: +ztane

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

From report at bugs.python.org  Mon Apr 11 10:29:05 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Apr 2016 14:29:05 +0000
Subject: [issue26601] Use new madvise()'s MADV_FREE on the private heap
In-Reply-To: <1458557514.95.0.774301964914.issue26601@psf.upfronthosting.co.za>
Message-ID: <1460384945.46.0.55942539388.issue26601@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> ... and it turns out that munmapping is not always that smart thing to do: http://stackoverflow.com/questions/36548518/variable-assignment-faster-than-one-liner

py -3 -m timeit "tuple(range(2000)) == tuple(range(2000))"
10000 loops, best of 3: 97.7 usec per loop
py -3 -m timeit "a = tuple(range(2000));  b = tuple(range(2000)); a==b"
10000 loops, best of 3: 70.7 usec per loop

Hum, it looks like this specific benchmark spends a lot of time to allocate one arena and then release it.

Maybe we should keep one "free" arena to avoid the slow mmap/munmap. But it means that we keep 256 KB of unused memory.

Maybe we need an heuristic to release the free arena after N calls to object allocator functions which don't need this free arena.

----------

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

From report at bugs.python.org  Mon Apr 11 10:38:56 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Apr 2016 14:38:56 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <20160411143851.11585.5170.945E7467@psf.io>


Roundup Robot added the comment:

New changeset bb10867ffe28 by Serhiy Storchaka in branch '3.5':
Issue #25910: Fixed more links in the docs.
https://hg.python.org/cpython/rev/bb10867ffe28

New changeset 61c7deea9e6a by Serhiy Storchaka in branch '2.7':
Issue #25910: Fixed more links in the docs.
https://hg.python.org/cpython/rev/61c7deea9e6a

New changeset e3c9a47a83fb by Serhiy Storchaka in branch 'default':
Issue #25910: Fixed more links in the docs.
https://hg.python.org/cpython/rev/e3c9a47a83fb

----------

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

From report at bugs.python.org  Mon Apr 11 10:40:19 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 11 Apr 2016 14:40:19 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1460385619.93.0.061523730652.issue25910@psf.upfronthosting.co.za>


SilentGhost added the comment:

Serhiy, the OpenSSL links are now https

----------

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

From report at bugs.python.org  Mon Apr 11 10:49:12 2016
From: report at bugs.python.org (Antti Haapala)
Date: Mon, 11 Apr 2016 14:49:12 +0000
Subject: [issue26601] Use new madvise()'s MADV_FREE on the private heap
In-Reply-To: <1458557514.95.0.774301964914.issue26601@psf.upfronthosting.co.za>
Message-ID: <1460386152.95.0.244838186708.issue26601@psf.upfronthosting.co.za>


Antti Haapala added the comment:

> Maybe we need an heuristic to release the free arena after N calls to object allocator functions which don't need this free arena.

That'd be my thought; again I believe that `madvise` could be useful there; now `mmap`/`munmap` I believe is particularly slow because it actually needs to supply 256kbytes of *zeroed* pages.

----------

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

From report at bugs.python.org  Mon Apr 11 10:56:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 11 Apr 2016 14:56:47 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1460386607.95.0.402639145537.issue25910@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Fixed links to "A Byte of Python" and OpenSSL.

Not fixed dead links:

http://www.zope.com/
http://www.pythonlabs.com/logos.html (http://www.pythonlabs.com/ exists but is not too useful)
http://www.vex.net/parnassus/ (looks as this project is dead)
http://ontosys.com/xml-rpc/extensions.php (sad, this was a specification)
http://svn.python.org/view/tracker/importer/ (removed in r88981 and not moved to https://hg.python.org/tracker)

----------

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

From report at bugs.python.org  Mon Apr 11 10:59:41 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 11 Apr 2016 14:59:41 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1460386781.34.0.435947108585.issue25910@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Serhiy, the OpenSSL links are now https

They works with http.

Some links (including python.org) are now redirected from http to https. It may be worth to add https explicitly.

----------

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

From report at bugs.python.org  Mon Apr 11 11:00:54 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 11 Apr 2016 15:00:54 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1460386854.62.0.453187832215.issue25910@psf.upfronthosting.co.za>


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


----------
nosy: +barry, tim.peters

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

From report at bugs.python.org  Mon Apr 11 11:29:39 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 11 Apr 2016 15:29:39 +0000
Subject: [issue26733] staticmethod and classmethod are ignored when
 disassemble class
In-Reply-To: <1460369974.2.0.716803365246.issue26733@psf.upfronthosting.co.za>
Message-ID: <1460388579.51.0.228134373774.issue26733@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

After researching the code, I think changing ' %-4d' to '%3d' in dis_bug708901 is right. Since I added some some lines and the lineno of test_bug708901 has arrived at 100+ and the leading space should not be there. According to the code of dis.dis, the right format string should be '%3d'. Not only test_bug708901, all the other ' %-4d' should be changed to '%3d'. If we add 1000+ lines at the head of the file, then all the ' %-4d' format string will lead to test failures.

I update my patch.

----------
Added file: http://bugs.python.org/file42431/add_staticmethod_and_classmethod_when_dis.dis_a_class_v3.patch

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

From report at bugs.python.org  Mon Apr 11 12:13:24 2016
From: report at bugs.python.org (David Ward)
Date: Mon, 11 Apr 2016 16:13:24 +0000
Subject: [issue25187] bdist_rpm fails due to wrong hardcoded assumption about
 RPM filename format
In-Reply-To: <1442715156.03.0.0265256317041.issue25187@psf.upfronthosting.co.za>
Message-ID: <1460391204.66.0.957872518739.issue25187@psf.upfronthosting.co.za>


David Ward added the comment:

Please review this revised patch. Thank you.

----------
Added file: http://bugs.python.org/file42432/python-bdist_rpm-evaluate-_rpmfilename.patch

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

From report at bugs.python.org  Mon Apr 11 12:50:02 2016
From: report at bugs.python.org (Bar Harel)
Date: Mon, 11 Apr 2016 16:50:02 +0000
Subject: [issue26734] Repeated mmap\munmap calls during temporary allocation
Message-ID: <1460393402.14.0.550689084671.issue26734@psf.upfronthosting.co.za>


New submission from Bar Harel:

After asking a question regarding performance in StackOverflow, I received an answer which seemed like a design problem in object allocation.
This is the question: http://stackoverflow.com/q/36548518/1658617
Seems like it ignores the garbage allocation settings (as timeit is supposed to disable it as far as I know) and I might not be proficient in low-level programming but there should be a way to implement it that doesn't cause endless allocations.

----------
components: Benchmarks, Interpreter Core, Tests
messages: 263189
nosy: bar.harel, brett.cannon, pitrou
priority: normal
severity: normal
status: open
title: Repeated mmap\munmap calls during temporary allocation
type: performance
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/issue26734>
_______________________________________

From report at bugs.python.org  Mon Apr 11 13:01:12 2016
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 11 Apr 2016 17:01:12 +0000
Subject: [issue26734] Repeated mmap\munmap calls during temporary allocation
In-Reply-To: <1460393402.14.0.550689084671.issue26734@psf.upfronthosting.co.za>
Message-ID: <1460394072.39.0.812189427129.issue26734@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/issue26734>
_______________________________________

From report at bugs.python.org  Mon Apr 11 13:01:38 2016
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 11 Apr 2016 17:01:38 +0000
Subject: [issue26734] Repeated mmap\munmap calls during temporary allocation
In-Reply-To: <1460393402.14.0.550689084671.issue26734@psf.upfronthosting.co.za>
Message-ID: <1460394098.86.0.503233794074.issue26734@psf.upfronthosting.co.za>


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


----------
components:  -Benchmarks

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

From report at bugs.python.org  Mon Apr 11 13:11:14 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Apr 2016 17:11:14 +0000
Subject: [issue26734] Repeated mmap\munmap calls during temporary allocation
In-Reply-To: <1460393402.14.0.550689084671.issue26734@psf.upfronthosting.co.za>
Message-ID: <1460394674.77.0.475095104179.issue26734@psf.upfronthosting.co.za>


STINNER Victor added the comment:

FYI a discussion started in the issue #26601.

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

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

From report at bugs.python.org  Mon Apr 11 13:17:47 2016
From: report at bugs.python.org (Bar Harel)
Date: Mon, 11 Apr 2016 17:17:47 +0000
Subject: [issue26601] Use new madvise()'s MADV_FREE on the private heap
In-Reply-To: <1458557514.95.0.774301964914.issue26601@psf.upfronthosting.co.za>
Message-ID: <1460395067.28.0.489580662743.issue26601@psf.upfronthosting.co.za>


Changes by Bar Harel <bzvi7919 at gmail.com>:


----------
nosy: +bar.harel

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

From report at bugs.python.org  Mon Apr 11 13:33:15 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Apr 2016 17:33:15 +0000
Subject: [issue26734] Repeated mmap\munmap calls during temporary allocation
In-Reply-To: <1460393402.14.0.550689084671.issue26734@psf.upfronthosting.co.za>
Message-ID: <1460395995.67.0.114710005017.issue26734@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Use new madvise()'s MADV_FREE on the private heap

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

From report at bugs.python.org  Mon Apr 11 13:35:08 2016
From: report at bugs.python.org (Matthew Ryan)
Date: Mon, 11 Apr 2016 17:35:08 +0000
Subject: [issue26735] os.urandom(2500) fails on Solaris 11.3
Message-ID: <1460396108.06.0.541477402311.issue26735@psf.upfronthosting.co.za>


New submission from Matthew Ryan:

On Solaris 11.3 (intel tested, but I assume issue is on SPARC as well),
I found the following fails:
  import os
  os.urandom(2500)

The above throws OSError: [Errno 22] Invalid argument.

It turns out that the Solaris version of getrandom() is limited to returning
no more than 1024 bytes, per the manpage:
  The getrandom() and getentropy() functions fail if:

  EINVAL    The flags are not set to GRND_RANDOM, GRND_NONBLOCK or  both,
            or bufsz is <= 0 or > 1024.

I've attached a possible patch for this issue, against the 3.5.1 source
tree.

----------
files: python3-getrandom.patch
keywords: patch
messages: 263191
nosy: mryan1539
priority: normal
severity: normal
status: open
title: os.urandom(2500) fails on Solaris 11.3
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file42433/python3-getrandom.patch

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

From report at bugs.python.org  Mon Apr 11 13:35:34 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Apr 2016 17:35:34 +0000
Subject: [issue26601] Use new madvise()'s MADV_FREE on the private heap
In-Reply-To: <1458557514.95.0.774301964914.issue26601@psf.upfronthosting.co.za>
Message-ID: <1460396134.13.0.888011520895.issue26601@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> ... and it turns out that munmapping is not always that smart thing to do:

I don't think a silly benchmark says anything about the efficiency of our allocation strategy. If you have a real-world use case where this turns up, then please post about it.

----------
nosy: +pitrou

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

From report at bugs.python.org  Mon Apr 11 13:50:03 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Mon, 11 Apr 2016 17:50:03 +0000
Subject: [issue14265] Fully qualified test name in failure output
In-Reply-To: <1331582387.93.0.923571160232.issue14265@psf.upfronthosting.co.za>
Message-ID: <1460397003.75.0.882893586362.issue14265@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

Included is a patch with the suggested change.
I changed the TestCase.__str__ method to:
    return "%s (%s.%s)" % (self._testMethodName, strclass(self.__class__), self._testMethodName)
instead of
    return "%s (%s)" % (self._testMethodName, strclass(self.__class__))

So now a failed test look like this:

======================================================================
ERROR: test_error_handling (Lib.test.test_logging.StreamHandlerTest.test_error_handling)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aviv/dev/cpython/Lib/test/test_logging.py", line 641, in test_error_handling
    self.assertIs(h.error_record, r)
AttributeError: 'TestStreamHandler' object has no attribute 'error_record'

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

----------
keywords: +patch
nosy: +palaviv
versions: +Python 3.6 -Python 3.3
Added file: http://bugs.python.org/file42434/14265.patch

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

From report at bugs.python.org  Mon Apr 11 13:55:22 2016
From: report at bugs.python.org (skydoom)
Date: Mon, 11 Apr 2016 17:55:22 +0000
Subject: [issue26693] Exception ignored in: <module 'threading' from
 ...threading.py> in _shutdown, assert tlock.locked()
In-Reply-To: <1459821105.82.0.884891417565.issue26693@psf.upfronthosting.co.za>
Message-ID: <1460397322.02.0.152404537734.issue26693@psf.upfronthosting.co.za>


skydoom added the comment:

Hi Pitrou, 

would you be able to look at my issue and the proposed pathc?

Thanks

----------

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

From report at bugs.python.org  Mon Apr 11 14:01:29 2016
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 11 Apr 2016 18:01:29 +0000
Subject: [issue26718] super.__init__ leaks memory if called multiple times
In-Reply-To: <1460163723.35.0.208266777223.issue26718@psf.upfronthosting.co.za>
Message-ID: <1460397689.11.0.427527148964.issue26718@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Based on Guido's feedback and the fact that this isn't documented usage of super() and hence no promises to not re-initialize, I'm closing as "not a bug". Sorry, Kevin.

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

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

From report at bugs.python.org  Mon Apr 11 14:05:41 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 11 Apr 2016 18:05:41 +0000
Subject: [issue26718] super.__init__ leaks memory if called multiple times
In-Reply-To: <1460163723.35.0.208266777223.issue26718@psf.upfronthosting.co.za>
Message-ID: <1460397941.33.0.191946935943.issue26718@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Actually, the refcount bug is still a bug.

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

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

From report at bugs.python.org  Mon Apr 11 14:28:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 11 Apr 2016 18:28:22 +0000
Subject: [issue26736] Use HTTPS protocol in links
Message-ID: <1460399300.6.0.985736947814.issue26736@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch makes links in the docs to use the HTTPS protocol if possible. All changed links are tested manually.

----------
assignee: docs at python
components: Documentation
files: links_https.patch
keywords: patch
messages: 263197
nosy: alex, christian.heimes, docs at python, dstufft, georg.brandl, giampaolo.rodola, janssen, pitrou, serhiy.storchaka, tim.golden
priority: normal
severity: normal
stage: patch review
status: open
title: Use HTTPS protocol in links
type: security
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42435/links_https.patch

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

From report at bugs.python.org  Mon Apr 11 14:36:20 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 11 Apr 2016 18:36:20 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1460399780.57.0.40772484844.issue25910@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

For XML-RPC extensions we can use a web archive: https://web.archive.org/web/20130120074804/http://ontosys.com/xml-rpc/extensions.php. There are precedences of using it for other dead links.

Opened separate issue26736 for https-zation.

----------

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

From report at bugs.python.org  Mon Apr 11 14:38:37 2016
From: report at bugs.python.org (Bayo Opadeyi)
Date: Mon, 11 Apr 2016 18:38:37 +0000
Subject: [issue26737] csv.DictReader throws generic error when fieldnames is
 accessed on non-text file
Message-ID: <1460399917.95.0.594939363664.issue26737@psf.upfronthosting.co.za>


New submission from Bayo Opadeyi:

If you use the csv.DictReader to open a non-text file and try to access fieldnames on it, it crashes with a generic error instead of something specific.

----------
messages: 263199
nosy: boyombo
priority: normal
severity: normal
status: open
title: csv.DictReader throws generic error when fieldnames is accessed on non-text file
versions: Python 2.7

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

From report at bugs.python.org  Mon Apr 11 14:39:15 2016
From: report at bugs.python.org (Bayo Opadeyi)
Date: Mon, 11 Apr 2016 18:39:15 +0000
Subject: [issue26737] csv.DictReader throws generic error when fieldnames is
 accessed for non-text file
In-Reply-To: <1460399917.95.0.594939363664.issue26737@psf.upfronthosting.co.za>
Message-ID: <1460399955.93.0.65154355588.issue26737@psf.upfronthosting.co.za>


Changes by Bayo Opadeyi <bayokrapht at gmail.com>:


----------
title: csv.DictReader throws generic error when fieldnames is accessed on non-text file -> csv.DictReader throws generic error when fieldnames is accessed for non-text file

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

From report at bugs.python.org  Mon Apr 11 15:36:29 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Apr 2016 19:36:29 +0000
Subject: [issue26736] Use HTTPS protocol in links
In-Reply-To: <1460399300.6.0.985736947814.issue26736@psf.upfronthosting.co.za>
Message-ID: <1460403389.71.0.0271268101667.issue26736@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/issue26736>
_______________________________________

From report at bugs.python.org  Mon Apr 11 15:38:32 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 11 Apr 2016 19:38:32 +0000
Subject: [issue24745] Better default font for editor
In-Reply-To: <1438129028.22.0.104228147207.issue24745@psf.upfronthosting.co.za>
Message-ID: <1460403512.36.0.0523160009507.issue24745@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The change from "Courier" to "TkDefaultFont" causes Options => Configure IDLE to fail at least on Arch Linux (#26673) and Fedora 23 (also #24951).  The reason is still obscure to me.  I will leave this closed, close #24951 as duplicate, and patch on #26673 (which has more information).

----------

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

From report at bugs.python.org  Mon Apr 11 15:42:07 2016
From: report at bugs.python.org (Antti Haapala)
Date: Mon, 11 Apr 2016 19:42:07 +0000
Subject: [issue26601] Use new madvise()'s MADV_FREE on the private heap
In-Reply-To: <1458557514.95.0.774301964914.issue26601@psf.upfronthosting.co.za>
Message-ID: <1460403727.03.0.44361162596.issue26601@psf.upfronthosting.co.za>


Antti Haapala added the comment:

I said that *munmapping* is not the smart thing to do: and it is not, if you're going to *mmap* soon again.

----------

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

From report at bugs.python.org  Mon Apr 11 15:56:10 2016
From: report at bugs.python.org (Antti Haapala)
Date: Mon, 11 Apr 2016 19:56:10 +0000
Subject: [issue26601] Use new madvise()'s MADV_FREE on the private heap
In-Reply-To: <1458557514.95.0.774301964914.issue26601@psf.upfronthosting.co.za>
Message-ID: <1460404570.66.0.288032444157.issue26601@psf.upfronthosting.co.za>


Antti Haapala added the comment:

Also what is important to notice is that the behaviour occurs *exactly* because the current heuristics *work*; the allocations were successfully organized so that one arena could be freed as soon as possible. The question is that is it sane to try to free the few bits of free memory asap - say you're now holding 100M of memory - it does not often matter much if you hold the 100M of memory for *one second longer* than you actually ended up needing.

----------

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

From report at bugs.python.org  Mon Apr 11 15:57:32 2016
From: report at bugs.python.org (dileep k)
Date: Mon, 11 Apr 2016 19:57:32 +0000
Subject: [issue26738] listname.strip does not work right if the name ends with
 an 'o'
Message-ID: <1460404652.51.0.927437963251.issue26738@psf.upfronthosting.co.za>


New submission from dileep k:

12:54:38 | ~ | #1 $ python -V
Python 2.7.6

12:54:41 | ~ | #2 $ python
Python 2.7.6 (default, Jun 22 2015, 17:58:13) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>>> 'media.log'.strip('.log')
'media'

>>> 'video.log'.strip('.log')
'vide'

>>> 

The output should have been 'video' instead of 'vide' !

----------
components: Library (Lib)
messages: 263203
nosy: dileep k
priority: normal
severity: normal
status: open
title: listname.strip does not work right if the name ends with an 'o'
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Apr 11 15:58:04 2016
From: report at bugs.python.org (dileep k)
Date: Mon, 11 Apr 2016 19:58:04 +0000
Subject: [issue26738] listname.strip() does not work right if the name ends
 with an 'o'
In-Reply-To: <1460404652.51.0.927437963251.issue26738@psf.upfronthosting.co.za>
Message-ID: <1460404684.54.0.0670093703679.issue26738@psf.upfronthosting.co.za>


Changes by dileep k <eadgc5 at gmail.com>:


----------
title: listname.strip does not work right if the name ends with an 'o' -> listname.strip() does not work right if the name ends with an 'o'

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

From report at bugs.python.org  Mon Apr 11 16:03:43 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 11 Apr 2016 20:03:43 +0000
Subject: [issue26738] listname.strip() does not work right if the name ends
 with an 'o'
In-Reply-To: <1460404652.51.0.927437963251.issue26738@psf.upfronthosting.co.za>
Message-ID: <1460405023.72.0.283666208445.issue26738@psf.upfronthosting.co.za>


SilentGhost added the comment:

Documentation [0] has a very clear explanation of how str.strip works.

[0] https://docs.python.org/2/library/stdtypes.html#str.strip

----------
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Apr 11 16:11:43 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 11 Apr 2016 20:11:43 +0000
Subject: [issue24951] Idle test_configdialog fails on Fedora 23, 3.6
In-Reply-To: <1440744246.57.0.722923206189.issue24951@psf.upfronthosting.co.za>
Message-ID: <1460405503.51.0.754920824575.issue24951@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This and #26673 are duplicates.  The latter also reports failure on Arch Linux and other Python versions.  While our default policy is to keep the earliest report open, I am closing this as #26673 has more information, including from Petr.

----------
resolution:  -> duplicate
stage: test needed -> resolved
status: open -> closed
superseder:  -> Tkinter error when opening IDLE configuration menu

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

From report at bugs.python.org  Mon Apr 11 17:01:20 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Mon, 11 Apr 2016 21:01:20 +0000
Subject: [issue2943] Distutils should generate a better error message when the
 SDK is not installed
In-Reply-To: <1211455981.94.0.404413935613.issue2943@psf.upfronthosting.co.za>
Message-ID: <1460408480.47.0.385150228607.issue2943@psf.upfronthosting.co.za>


Ivan Pozdeev added the comment:

The vsvarsall.bat message should direct to https://wiki.python.org/moin/WindowsCompilers rather than some 3rd-party site (even more so, one with user-generated content like SO).

E.g.: "Unable to find vcvarsall.bat. A required version of MS VC++ compilers is not installed or used improperly. See https://wiki.python.org/moin/WindowsCompilers for instructions."

----------
nosy: +Ivan.Pozdeev

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

From report at bugs.python.org  Mon Apr 11 17:06:31 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Apr 2016 21:06:31 +0000
Subject: [issue26601] Use new madvise()'s MADV_FREE on the private heap
In-Reply-To: <1458557514.95.0.774301964914.issue26601@psf.upfronthosting.co.za>
Message-ID: <1460408791.58.0.226042249715.issue26601@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Another question is how often this situation occurs in practice and whether it's worth spending some bits, CPU cycles and developer time on "fixing" this.

----------

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

From report at bugs.python.org  Mon Apr 11 17:24:19 2016
From: report at bugs.python.org (MICHAEL JACOBSON)
Date: Mon, 11 Apr 2016 21:24:19 +0000
Subject: [issue26739] Errno 10035 a non-blocking socket operation could not be
 completed immediately
Message-ID: <1460409859.89.0.789703447955.issue26739@psf.upfronthosting.co.za>


New submission from MICHAEL JACOBSON:

So far I've got past the "bug in program" stage of debugging, but this came up:
IDLE internal error in runcode()
Traceback (most recent call last):
  File "C:\Python27\lib\idlelib\rpc.py", line 235, in asyncqueue
    self.putmessage((seq, request))
  File "C:\Python27\lib\idlelib\rpc.py", line 332, in putmessage
    n = self.sock.send(s[:BUFSIZE])
error: [Errno 10035] A non-blocking socket operation could not be completed immediately
I have no idea what a "socket" is so if you know please tell me!

----------
components: Windows
files: Skier
messages: 263208
nosy: MICHAEL JACOBSON, paul.moore, 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
type: resource usage
versions: Python 2.7
Added file: http://bugs.python.org/file42436/Skier

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

From report at bugs.python.org  Mon Apr 11 17:25:47 2016
From: report at bugs.python.org (MICHAEL JACOBSON)
Date: Mon, 11 Apr 2016 21:25:47 +0000
Subject: [issue26739] Errno 10035 a non-blocking socket operation could not be
 completed immediately
In-Reply-To: <1460409859.89.0.789703447955.issue26739@psf.upfronthosting.co.za>
Message-ID: <1460409947.99.0.849576304779.issue26739@psf.upfronthosting.co.za>


Changes by MICHAEL JACOBSON <922129 at isd624.org>:


----------
nosy:  -MICHAEL JACOBSON, paul.moore, steve.dower, tim.golden, zach.ware

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

From report at bugs.python.org  Mon Apr 11 17:26:27 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Apr 2016 21:26:27 +0000
Subject: [issue26739] idle: Errno 10035 a non-blocking socket operation could
 not be completed immediately
In-Reply-To: <1460409859.89.0.789703447955.issue26739@psf.upfronthosting.co.za>
Message-ID: <1460409987.75.0.61330796444.issue26739@psf.upfronthosting.co.za>


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


----------
components: +IDLE
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
title: Errno 10035 a non-blocking socket operation could not be completed immediately -> idle: Errno 10035 a non-blocking socket operation could not be completed immediately

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

From report at bugs.python.org  Mon Apr 11 17:39:03 2016
From: report at bugs.python.org (Daniel Lenski)
Date: Mon, 11 Apr 2016 21:39:03 +0000
Subject: [issue23129] sqlite3 COMMIT nested in SELECT returns unexpected
 results
In-Reply-To: <1419873078.33.0.518262497665.issue23129@psf.upfronthosting.co.za>
Message-ID: <1460410743.32.0.987848068984.issue23129@psf.upfronthosting.co.za>


Daniel Lenski added the comment:

I agree on the nastiness of this bug. It's been plaguing my production code for months and I had been at a loss to explain why I've been getting duplicate rows until I found this SO post:

http://stackoverflow.com/questions/27624049/python-sqlite3-cursor-returns-duplicates-when-a-commit-intervenes

By the way, the test case in Jim Carroll's report appears to come from this StackOverflow question.

----------
nosy: +dlenski

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

From report at bugs.python.org  Mon Apr 11 17:47:39 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 11 Apr 2016 21:47:39 +0000
Subject: [issue26673] Tkinter error when opening IDLE configuration menu
In-Reply-To: <1459351920.73.0.899924616631.issue26673@psf.upfronthosting.co.za>
Message-ID: <1460411259.64.0.240212982983.issue26673@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

#24745 changed the default fixed font from Courier to TkFixedFontin 3.5.0, 3.4.4, and 2.7.11  when using tcl/tk 8.5+.  On some OSes, the latter is not Courier and looks much better.  I don't know why the two behave differently on some systems.

Since this is not a unique problem on one machine, I am reopening this to at least provide a workaround.  Regardless of ultimate cause, we can at least force a blank font size to a default int string, such as '10'.  I closed #24951 as a duplicate of this.

In class idlelib.configDialog.ConfigDialog, method CreatePageFontTab (line 114) creates StringVar self.fontSize, initialized to ''.  The Var is passed to class dynOptionMenuWidget.DynOptionMenu(tkinter.OptionMenu). The instance is bound to self.optMenuFontSize.  Method LoadFontCfg (line 963) sets retrieves the current Editor font as local name configeredFont and local fontSize therefrom. It passes fontSize to self.optMenuFontSize.SetMenu.  This in turns sets the stored self.fontSize to the passed in fontSize, overwriting the initial value.

(The OptionMenu.__init__ docstring and http://infohost.nmt.edu/tcc/help/pubs/tkinter/web/optionmenu.html suggest that the variable must be a StringVar, which I presume is why self.fontSize is.  Experiment suggest otherwise in 8.6.  This would have to be verified on 8.5 and even 8.4 before changing to IntVar.)

If my understanding based on the above, fontSize must be set to '' when the current font is TkFixedFont, but not when the font is Courier.  Petr, could you confirm by adding "print(configuredFont, fontsize)" to LoadFontCfg after both names are set and running both buggy and good cases?

----------
resolution: not a bug -> 
stage: resolved -> test needed
status: closed -> open
versions: +Python 3.6

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

From report at bugs.python.org  Mon Apr 11 18:03:47 2016
From: report at bugs.python.org (Cherniavsky Beni)
Date: Mon, 11 Apr 2016 22:03:47 +0000
Subject: [issue9334] argparse does not accept options taking arguments
 beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1460412227.57.0.197657062063.issue9334@psf.upfronthosting.co.za>


Cherniavsky Beni added the comment:

+1, is there anything missing to apply Paul's patch?

Can I additional suggest a change to the error message, e.g.:

  $ prog --foo -bar
  prog: error: argument --foo: expected one argument
  (tip: use --foo=-bar to force interpretation as argument of --foo)

This can be safely added in the current mode with no opt-in required, and will relieve the immediate "but what can I do?" confusions of users.  The workaround is hard to discover otherwise, as `--foo=x` is typically equivalent to `--foo x`.

--- more discussion, though I suspect it's not productive ---

I've tried to find what the GNU Standards or POSIX say about this and was surprised to see neither explains how exactly `--opt_with_mandatory_argument -quux` behaves.

man getopt says:

     If such a character is followed by a colon, the option requires an argument, so getopt() places a pointer to the following text in the same argv-element, or the text of the following argv-element, in optarg. Two colons mean an option takes an optional arg; if there is text in the current argv-element (i.e., in the same word as the option name itself, for example, "-oarg"), then it is returned in optarg, otherwise optarg is set to zero. This is a GNU extension.

POSIX similarly does explain that an optional arg after an option must follow within the same argument:

    (2)(b) If the SYNOPSIS shows an optional option-argument (as with [ -f[ option_argument]] in the example), a conforming application shall place any option-argument for that option directly adjacent to the option in the same argument string, without intervening <blank> characters. If the utility receives an argument containing only the option, it shall behave as specified in its description for an omitted option-argument; it shall not treat the next argument (if any) as the option-argument for that option.

    -- http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html

Anyway, every argument parsing library I've ever seen parses options in a left-to-right pass, consuming non-optional arguments after an option whatever they look like.  I've never seen a difference between `--foo bar` and `--foo=bar` when bar is *non-optional*.

Both behaviors (--opt_with_mandatory_argument bar, --opt_with_optional_argument[=bar]) were clearly designed to avoid ambiguity.
Whereas argparse innovated some constructs eg. '--opt', nargs='*' that are inherently ambiguous.  But for the simple constructs, most notably nargs=1, there should be a way to get the traditional unix meaning.

----------
nosy: +cben

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

From report at bugs.python.org  Mon Apr 11 18:04:42 2016
From: report at bugs.python.org (Bar Harel)
Date: Mon, 11 Apr 2016 22:04:42 +0000
Subject: [issue26601] Use new madvise()'s MADV_FREE on the private heap
In-Reply-To: <1458557514.95.0.774301964914.issue26601@psf.upfronthosting.co.za>
Message-ID: <1460412282.67.0.0752887584957.issue26601@psf.upfronthosting.co.za>


Bar Harel added the comment:

Any idea how to test it then? I found this happening by chance because I care about efficiency too much. We can't just stick timeit in random areas and hope to get results.

----------

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

From report at bugs.python.org  Mon Apr 11 20:45:17 2016
From: report at bugs.python.org (David Ward)
Date: Tue, 12 Apr 2016 00:45:17 +0000
Subject: [issue25627] distutils : file "bdist_rpm.py" does not quote filenames
 when executing the rpm command
In-Reply-To: <1447535612.69.0.122030151224.issue25627@psf.upfronthosting.co.za>
Message-ID: <1460421917.47.0.734005273013.issue25627@psf.upfronthosting.co.za>


David Ward added the comment:

This revised patch has a small change so that the subprocess output is decoded from a byte sequence to a string, which is necessary when running this under Python 3.

With this change, this worked for me on Fedora 23 with Python 3.4.3.

It also worked on Fedora 23 with Python 2.7.11, but I had to apply the patch by hand, because of small differences in the original file as a result of SVN revisions 54854 and 57699 for Python 3.0. I also had to add "import subprocess" to the top of this file.

----------
nosy: +dpward
Added file: http://bugs.python.org/file42437/issue25627_6.diff

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

From report at bugs.python.org  Mon Apr 11 20:59:07 2016
From: report at bugs.python.org (David Ward)
Date: Tue, 12 Apr 2016 00:59:07 +0000
Subject: [issue25187] bdist_rpm fails due to wrong hardcoded assumption about
 RPM filename format
In-Reply-To: <1442715156.03.0.0265256317041.issue25187@psf.upfronthosting.co.za>
Message-ID: <1460422747.82.0.507899488468.issue25187@psf.upfronthosting.co.za>


David Ward added the comment:

Thanks again for your feedback. I revised this patch as requested to conform to changes also being made in issue 25627. Please review this new patch.

I tested this successfully under both Python 3.4.3 and Python 2.7.11 on Fedora 23. Note that "import subprocess" must additionally be added to this file for Python 2.7, after applying this patch and/or the one in issue 25627. (I also tested this successfully with the latest patch from both issues applied at the same time.)

----------
Added file: http://bugs.python.org/file42438/python-bdist_rpm-evaluate-_rpmfilename.patch

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

From report at bugs.python.org  Mon Apr 11 21:25:00 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 12 Apr 2016 01:25:00 +0000
Subject: [issue9334] argparse does not accept options taking arguments
 beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1460424300.11.0.701386505976.issue9334@psf.upfronthosting.co.za>


Martin Panter added the comment:

My main concern with the patch is that it only half fixes the problem. It sounds like it will allow parsing ?--opt -x? (if ?-x? is not registered as an option), but will still refuse ?--opt -h?, assuming ?-h? is registered by default. What is the barrier to parsing an argument to the option syntax independently of what option names are registered?

Also the name ?args_default_to_positional=True? name is both unwieldy and vague to me. The purpose seems to be to disable option-lookalike-strings from being reserved. Maybe call it something like ?reserve_all_options=False? or ?reserve_unregistered_options=False??

I left some thoughts in the code review for the documentation too.

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

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

From report at bugs.python.org  Mon Apr 11 21:52:35 2016
From: report at bugs.python.org (paul j3)
Date: Tue, 12 Apr 2016 01:52:35 +0000
Subject: [issue25061] Add native enum support for argparse
In-Reply-To: <1441908245.42.0.23532628335.issue25061@psf.upfronthosting.co.za>
Message-ID: <1460425955.31.0.473531875132.issue25061@psf.upfronthosting.co.za>


paul j3 added the comment:

The best way to get an idea added is to write a good complete patch.  2nd best is to provide constructive input on ideas that are already here.  3rd is to illustrate how you would hope to use such a feature.  Include ideas on how the usage/help/error display would work.

At the risk of repeating myself, I'm still not convinced that being a 'native type' makes any difference.  Argparse does not support any native type, at least not directly.

----------

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

From report at bugs.python.org  Mon Apr 11 21:52:37 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 12 Apr 2016 01:52:37 +0000
Subject: [issue26737] csv.DictReader throws generic error when fieldnames is
 accessed for non-text file
In-Reply-To: <1460399917.95.0.594939363664.issue26737@psf.upfronthosting.co.za>
Message-ID: <1460425957.32.0.250623370895.issue26737@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

This already behaves usefully in 3.5 where reading fieldnames from a DictReader wrapping a file opened in binary mode gets you:

_csv.Error: iterator should return strings, not bytes (did you open the file in text mode?)

And 2.7 is highly unlikely to make fit and finish fixes at this stage in the game.

That said, not sure what you'd expect in 2.7; standard open in binary mode is correct there, and you'd get str either way. Is the problem that it's not a CSV file in the first place? Because Python 2's csv isn't encoding aware; as long as it doesn't have embedded NULs, anything could be legitimate data (csv doesn't have the context to say that it should be latin-1, EBCDIC, or whatever).

----------
nosy: +josh.r

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

From report at bugs.python.org  Mon Apr 11 21:55:43 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 12 Apr 2016 01:55:43 +0000
Subject: [issue11205] Evaluation order of dictionary display is different from
 reference manual.
In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za>
Message-ID: <1460426143.83.0.300920806395.issue11205@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Temporarily reopening this as a docs bug - I think it's worth mentioning in the "Porting to Python 3.5" section of the What's New docs and as a "version changed" note in the dis module docs, as even though it's obscure, anyone that was inadvertently relying on the prior deviation from the spec is going to be confused by the behavioural change in 3.5.

(The specific case where this came up was Russell Keith-Magee encountering the semantic change in BUILD_MAP's expectations for argument order on the stack for his VOD bytecode transpiler)

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python
priority: high -> normal
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open
versions: +Python 3.5 -Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Apr 11 22:20:45 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 12 Apr 2016 02:20:45 +0000
Subject: [issue26733] staticmethod and classmethod are ignored when
 disassemble class
In-Reply-To: <1460369974.2.0.716803365246.issue26733@psf.upfronthosting.co.za>
Message-ID: <1460427645.09.0.22640462181.issue26733@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The code and test changes in the latest patch look good to me. For documentation, I suggest updating https://docs.python.org/3/library/dis.html#dis.dis to:

- say "it disassembles all methods (including class and static methods)" when describing how classes are handled.

- add a version changed note for 3.6 to say that class and static methods are disassembled in addition to normal instance methods when disassembling a class

----------

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

From report at bugs.python.org  Mon Apr 11 22:54:33 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 12 Apr 2016 02:54:33 +0000
Subject: [issue26733] staticmethod and classmethod are ignored when
 disassemble class
In-Reply-To: <1460369974.2.0.716803365246.issue26733@psf.upfronthosting.co.za>
Message-ID: <1460429673.56.0.053883420032.issue26733@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I update the documentation. Learning from devguide, the change of whatsnew is the committer's work. ;)

----------
Added file: http://bugs.python.org/file42439/add_staticmethod_and_classmethod_when_dis.dis_a_class_v4.patch

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

From report at bugs.python.org  Tue Apr 12 00:29:03 2016
From: report at bugs.python.org (Luiz Poleto)
Date: Tue, 12 Apr 2016 04:29:03 +0000
Subject: [issue26699] locale.str docstring is incorrect: "Convert float to
 integer"
In-Reply-To: <1459927789.02.0.138982751213.issue26699@psf.upfronthosting.co.za>
Message-ID: <1460435343.52.0.17722033606.issue26699@psf.upfronthosting.co.za>


Changes by Luiz Poleto <luiz.poleto at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file42440/issue26699.patch

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

From report at bugs.python.org  Tue Apr 12 01:37:01 2016
From: report at bugs.python.org (Erik Welch)
Date: Tue, 12 Apr 2016 05:37:01 +0000
Subject: [issue26729] Incorrect __text_signature__ for sorted
In-Reply-To: <1460310880.55.0.462687598027.issue26729@psf.upfronthosting.co.za>
Message-ID: <1460439421.14.0.581412862214.issue26729@psf.upfronthosting.co.za>


Erik Welch added the comment:

Interesting observation, Martin.

Upon further consideration, the call signature for sorted really is quite odd.  It doesn't behave like any other builtin function.  Currently, "iterable" is positional-only, and "key=" and "reverse=" are keyword only.  I would only expect such behavior for functions with variadic *args.

I uploaded a new patch so that the call signature matches the original __text_signature__.  This means "iterable" may be given as a keyword argument, and "key" and "reverse" may be given as positional arguments.

I added tests for the new behavior, and all tests pass for me.

----------
Added file: http://bugs.python.org/file42441/sorted_2.patch

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

From report at bugs.python.org  Tue Apr 12 01:42:49 2016
From: report at bugs.python.org (paul j3)
Date: Tue, 12 Apr 2016 05:42:49 +0000
Subject: [issue25061] Add native enum support for argparse
In-Reply-To: <1441908245.42.0.23532628335.issue25061@psf.upfronthosting.co.za>
Message-ID: <1460439769.37.0.850434993785.issue25061@psf.upfronthosting.co.za>


paul j3 added the comment:

desbma:

Rereading your latest code and comment:

> * The meaning of the 'type' parameter for StoreEnumAction is somewhat different than for other actions (enum class vs callable that validates)

it occurred to me that that parameter does not have to be named 'type'.  It could just as well be 'enumClass' or something else.  It's just local to the class __init__ method.

Something that's come up with other Action classes is that the parameter list is not well documented.  While there's a generic set of parameters, the subclasses vary in what they accept or require or ignore.  The docs don't elaborate, and the error messages can be cryptic.  A new class with a new parameter (whether new in name or meaning) can add to that confusion.

We need to think more abstractly, so we aren't just improving the handling of 'enums', but also all their derived and meta classes.  And possibly other mappings, where we want to do a 'key' lookup, and form help strings of the choices.

----------

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

From report at bugs.python.org  Tue Apr 12 01:48:08 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Apr 2016 05:48:08 +0000
Subject: [issue26733] staticmethod and classmethod are ignored when
 disassemble class
In-Reply-To: <1460369974.2.0.716803365246.issue26733@psf.upfronthosting.co.za>
Message-ID: <1460440088.22.0.666727373524.issue26733@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If this is new feature, perhaps the docs need the versionchanged directive. Otherwise the patch should be applied to all maintained branches.

Added other comments on Rietveld.

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

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

From report at bugs.python.org  Tue Apr 12 01:48:39 2016
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 12 Apr 2016 05:48:39 +0000
Subject: [issue26736] Use HTTPS protocol in links
In-Reply-To: <1460399300.6.0.985736947814.issue26736@psf.upfronthosting.co.za>
Message-ID: <1460440119.11.0.820186767972.issue26736@psf.upfronthosting.co.za>


Georg Brandl added the comment:

+1

----------

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

From report at bugs.python.org  Tue Apr 12 01:48:47 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Apr 2016 05:48:47 +0000
Subject: [issue26733] staticmethod and classmethod are ignored when
 disassemble class
In-Reply-To: <1460369974.2.0.716803365246.issue26733@psf.upfronthosting.co.za>
Message-ID: <20160412054845.19154.71216.C62D6909@psf.io>


Roundup Robot added the comment:

New changeset b114a0650c44 by Serhiy Storchaka in branch '3.5':
Issue #26733: Fixed formatting line numbers in test_dis.
https://hg.python.org/cpython/rev/b114a0650c44

New changeset e0816ce68952 by Serhiy Storchaka in branch 'default':
Issue #26733: Fixed formatting line numbers in test_dis.
https://hg.python.org/cpython/rev/e0816ce68952

New changeset 16a27e38e9b5 by Serhiy Storchaka in branch '2.7':
Issue #26733: Fixed formatting line numbers in test_dis.
https://hg.python.org/cpython/rev/16a27e38e9b5

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

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

From report at bugs.python.org  Tue Apr 12 01:50:04 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Apr 2016 05:50:04 +0000
Subject: [issue26729] Incorrect __text_signature__ for sorted
In-Reply-To: <1460310880.55.0.462687598027.issue26729@psf.upfronthosting.co.za>
Message-ID: <1460440204.88.0.634322323993.issue26729@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I don't think we should start down the path of changing APIs just to accommodate weakness in the generation of the text signature.

We don't want to encourage unreadable oddities like sorted(reverse=False, iterable=source).  Best readability comes from the required positional argument for the iterable.  Please don't create a new and unnecessary keyword argument.   The current API is intentional.

----------
assignee:  -> rhettinger
nosy: +rhettinger

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

From report at bugs.python.org  Tue Apr 12 01:55:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Apr 2016 05:55:33 +0000
Subject: [issue26736] Use HTTPS protocol in links
In-Reply-To: <1460399300.6.0.985736947814.issue26736@psf.upfronthosting.co.za>
Message-ID: <1460440533.65.0.556894889869.issue26736@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If these changes are acceptable, we should change the :rfc:, :pep:, etc roles to produce links with https.

I was not sure that these changes are worth, it was just interesting to me to research how many links support the HTTPS protocol now.

----------

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

From report at bugs.python.org  Tue Apr 12 02:11:26 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Apr 2016 06:11:26 +0000
Subject: [issue25061] Add native enum support for argparse
In-Reply-To: <1441908245.42.0.23532628335.issue25061@psf.upfronthosting.co.za>
Message-ID: <1460441486.82.0.300352791406.issue25061@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Enum is just one tool among many, no more special than named tuples, nested dicts, string.Templates, regexes, pickles etc.  

The second issue is keeping the scope of argparse focused on its core task rather than trying to incorporate other parts of the standard library.  That is called separation-of-concerns or orthogonality.  A little parsimony is necessary for loose coupling and high cohesion.  We also don't want module sprawl or feature creep to impair maintainability or affect learnability.

That said, this is up to the module creator and maintainer, Steven Bethard.  He has the most experience with module and has the clearest vision of what its boundaries should be.

----------

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

From report at bugs.python.org  Tue Apr 12 02:16:37 2016
From: report at bugs.python.org (Erik Welch)
Date: Tue, 12 Apr 2016 06:16:37 +0000
Subject: [issue26729] Incorrect __text_signature__ for sorted
In-Reply-To: <1460310880.55.0.462687598027.issue26729@psf.upfronthosting.co.za>
Message-ID: <1460441797.72.0.194442593456.issue26729@psf.upfronthosting.co.za>


Erik Welch added the comment:

That's a fair and valid point, Raymond.  "sorted_2.patch" was submitted for consideration.  Either __text_signature__ is wrong, or the call argument handling is wrong.  One should be fixed.

Having a flexible call signature as if sorted were a user-defined function, such as "def sorted(iterable, key=None, reverse=False):", does allow for programmatic use of the introspected signature.  Here, using "iterable=" as a keyword can be convenient.

"sorted_1.diff" is wrong.  To match the existing call signature, __text_signature__ should be:

sorted($module, iterable, /, *, key=None, reverse=False)

I don't know any other builtin with a signature like this.  Such a signature may be a point of confusion for people learning Python ("what are those funny symbols?!"), who often encounter sorted early on.

----------

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

From report at bugs.python.org  Tue Apr 12 02:17:32 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 12 Apr 2016 06:17:32 +0000
Subject: [issue26735] os.urandom(2500) fails on Solaris 11.3
In-Reply-To: <1460396108.06.0.541477402311.issue26735@psf.upfronthosting.co.za>
Message-ID: <1460441852.54.0.908000228668.issue26735@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Interpreter Core
nosy: +haypo
stage:  -> patch review

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

From report at bugs.python.org  Tue Apr 12 02:20:24 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Apr 2016 06:20:24 +0000
Subject: [issue26729] Incorrect __text_signature__ for sorted
In-Reply-To: <1460310880.55.0.462687598027.issue26729@psf.upfronthosting.co.za>
Message-ID: <1460442024.48.0.520824518999.issue26729@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See issue26282.

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

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

From report at bugs.python.org  Tue Apr 12 02:22:54 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Apr 2016 06:22:54 +0000
Subject: [issue26737] csv.DictReader throws generic error when fieldnames is
 accessed for non-text file
In-Reply-To: <1460399917.95.0.594939363664.issue26737@psf.upfronthosting.co.za>
Message-ID: <1460442174.58.0.944279084322.issue26737@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/issue26737>
_______________________________________

From report at bugs.python.org  Tue Apr 12 02:23:54 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Apr 2016 06:23:54 +0000
Subject: [issue26735] os.urandom(2500) fails on Solaris 11.3
In-Reply-To: <1460396108.06.0.541477402311.issue26735@psf.upfronthosting.co.za>
Message-ID: <1460442234.87.0.370062949366.issue26735@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/issue26735>
_______________________________________

From report at bugs.python.org  Tue Apr 12 02:31:28 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Apr 2016 06:31:28 +0000
Subject: [issue26718] super.__init__ leaks memory if called multiple times
In-Reply-To: <1460163723.35.0.208266777223.issue26718@psf.upfronthosting.co.za>
Message-ID: <1460442688.39.0.876767635848.issue26718@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Possible solutions:

1. Correctly decref old values.
2. Raise an exception if super.__init__ is caled multiple times.
3. Remove super.__init__ and add super.__new__.

What is more preferable?

----------

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

From report at bugs.python.org  Tue Apr 12 02:43:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Apr 2016 06:43:40 +0000
Subject: [issue26491] Defer DECREFs until enum object is in a consistent state
 for re-entrancy
In-Reply-To: <1457264726.34.0.955181545994.issue26491@psf.upfronthosting.co.za>
Message-ID: <1460443420.63.0.32299290297.issue26491@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/issue26491>
_______________________________________

From report at bugs.python.org  Tue Apr 12 02:52:46 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 12 Apr 2016 06:52:46 +0000
Subject: [issue26733] staticmethod and classmethod are ignored when
 disassemble class
In-Reply-To: <1460369974.2.0.716803365246.issue26733@psf.upfronthosting.co.za>
Message-ID: <1460443966.21.0.0115574677481.issue26733@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Thanks for your comments Serhiy. I update the patch according to your comments.

Actually I don't think this is a new feature. Maybe staticmethod and classmethod are just forgotten.

As for separate tests for staticmethod and classmethod, I think they are not needed for this patch since right now we can use dis.dis to disassemble them explicitly. Only when dis.dis a class they are missing. But since there are no tests for them, adding tests for them is good.

----------
Added file: http://bugs.python.org/file42442/add_staticmethod_and_classmethod_when_dis.dis_a_class_v5.patch

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

From report at bugs.python.org  Tue Apr 12 03:53:49 2016
From: report at bugs.python.org (Bayo Opadeyi)
Date: Tue, 12 Apr 2016 07:53:49 +0000
Subject: [issue26737] csv.DictReader throws generic error when fieldnames is
 accessed for non-text file
In-Reply-To: <1460399917.95.0.594939363664.issue26737@psf.upfronthosting.co.za>
Message-ID: <1460447629.2.0.120838675474.issue26737@psf.upfronthosting.co.za>


Bayo Opadeyi added the comment:

Yes, the problem is that the file is not csv. The scenario is a web application allowing people to upload csv files, but they can upload any files they like.

----------
status: pending -> open

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

From report at bugs.python.org  Tue Apr 12 04:03:56 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2016 08:03:56 +0000
Subject: [issue26735] os.urandom(2500) fails on Solaris 11.3
In-Reply-To: <1460396108.06.0.541477402311.issue26735@psf.upfronthosting.co.za>
Message-ID: <1460448236.71.0.526371524245.issue26735@psf.upfronthosting.co.za>


STINNER Victor added the comment:

See also the issue #25003 and the changeset 835085cc28cd:

Issue #25003: On Solaris 11.3 or newer, os.urandom() now uses the getrandom() function instead of the getentropy() function. The getentropy() function is blocking to generate very good quality entropy, os.urandom() doesn't need such high-quality entropy.

----------

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

From report at bugs.python.org  Tue Apr 12 04:15:47 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2016 08:15:47 +0000
Subject: [issue26735] os.urandom(2500) fails on Solaris 11.3
In-Reply-To: <1460396108.06.0.541477402311.issue26735@psf.upfronthosting.co.za>
Message-ID: <1460448947.52.0.566628347647.issue26735@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I've attached a possible patch for this issue, against the 3.5.1 source
tree.

I guess that you are already using Python 3.5.1 which uses getrandom(). You should try to confirm using strace.

I updated your patch. I replaced "#if defined(__sun__)" with "#ifdef sun", since "#ifdef sun" looks more common in the Python code base, and I never saw "#if defined(__sun__)" in the Python code base.

I also avoided the new len variable, I reused the n variable.

I don't have Solaris, so I cannot test. I didn't find getrandom() manual page neither, I only found this blog post which doesn't mention the 1024 bytes limitation on Solaris:
https://blogs.oracle.com/darren/entry/solaris_new_system_calls_getentropy

----------
Added file: http://bugs.python.org/file42443/urandom_solaris.patch

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

From report at bugs.python.org  Tue Apr 12 04:32:18 2016
From: report at bugs.python.org (Tomas Tomecek)
Date: Tue, 12 Apr 2016 08:32:18 +0000
Subject: [issue26740] tarfile: accessing (listing and extracting) tarball
 fails with UnicodeDecodeError
Message-ID: <1460449938.56.0.948695426963.issue26740@psf.upfronthosting.co.za>


New submission from Tomas Tomecek:

I have a tarball (generated by docker-1.10 via `docker export`) and am trying to extract it with python 2.7 tarfile:

```
with tarfile.open(name=tarball_path) as tar_fd:
    tar_fd.extractall(path=path)
```

Output from a pytest run:

```
/usr/lib64/python2.7/tarfile.py:2072: in extractall
    for tarinfo in members:
/usr/lib64/python2.7/tarfile.py:2507: in next
    tarinfo = self.tarfile.next()
/usr/lib64/python2.7/tarfile.py:2355: in next
    tarinfo = self.tarinfo.fromtarfile(self)
/usr/lib64/python2.7/tarfile.py:1254: in fromtarfile
    return obj._proc_member(tarfile)
/usr/lib64/python2.7/tarfile.py:1276: in _proc_member
    return self._proc_pax(tarfile)
/usr/lib64/python2.7/tarfile.py:1406: in _proc_pax
    value = value.decode("utf8")
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

input = '\x01\x00\x00\x02\xc0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00', errors = 'strict'

    def decode(input, errors='strict'):
>       return codecs.utf_8_decode(input, errors, True)
E       UnicodeDecodeError: 'utf8' codec can't decode byte 0xc0 in position 4: invalid start byte

/usr/lib64/python2.7/encodings/utf_8.py:16: UnicodeDecodeError
```

Since I know nothing about tars, I have no idea if this is a bug or there is a proper solution/workaround.

When using GNU tar, I'm able to to list and extract the tarball.

----------
components: Unicode
messages: 263237
nosy: Tomas Tomecek, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: tarfile: accessing (listing and extracting) tarball fails with UnicodeDecodeError
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr 12 04:36:25 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 12 Apr 2016 08:36:25 +0000
Subject: [issue26740] tarfile: accessing (listing and extracting) tarball
 fails with UnicodeDecodeError
In-Reply-To: <1460449938.56.0.948695426963.issue26740@psf.upfronthosting.co.za>
Message-ID: <1460450185.02.0.768726125963.issue26740@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +lars.gustaebel
type:  -> behavior

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

From report at bugs.python.org  Tue Apr 12 04:42:18 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 12 Apr 2016 08:42:18 +0000
Subject: [issue26729] Incorrect __text_signature__ for sorted
In-Reply-To: <1460310880.55.0.462687598027.issue26729@psf.upfronthosting.co.za>
Message-ID: <1460450538.24.0.821119622316.issue26729@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

+1 for Serhiy's suggestion of enhancing the C API to specifically handle these cases.

----------
dependencies: +Add support for partial keyword arguments in extension functions

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

From report at bugs.python.org  Tue Apr 12 04:42:52 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2016 08:42:52 +0000
Subject: [issue26740] tarfile: accessing (listing and extracting) tarball
 fails with UnicodeDecodeError
In-Reply-To: <1460449938.56.0.948695426963.issue26740@psf.upfronthosting.co.za>
Message-ID: <1460450572.37.0.700880580508.issue26740@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Can you give a link to the tar archive, or for example the first 256 KB of the archive?

----------

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

From report at bugs.python.org  Tue Apr 12 04:57:14 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 12 Apr 2016 08:57:14 +0000
Subject: [issue26737] csv.DictReader throws generic error when fieldnames is
 accessed for non-text file
In-Reply-To: <1460399917.95.0.594939363664.issue26737@psf.upfronthosting.co.za>
Message-ID: <1460451434.96.0.564102268019.issue26737@psf.upfronthosting.co.za>


Berker Peksag added the comment:

> The scenario is a web application allowing people to upload csv files, but they can upload any files they like.

This looks like a potential security flaw in the application. The application should reject any non-CSV files from being uploaded (instead of relying on the CSV module).

Thanks for the report.

----------
nosy: +berker.peksag
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Apr 12 06:00:44 2016
From: report at bugs.python.org (Tomas Tomecek)
Date: Tue, 12 Apr 2016 10:00:44 +0000
Subject: [issue26740] tarfile: accessing (listing and extracting) tarball
 fails with UnicodeDecodeError
In-Reply-To: <1460449938.56.0.948695426963.issue26740@psf.upfronthosting.co.za>
Message-ID: <1460455244.76.0.644564454095.issue26740@psf.upfronthosting.co.za>


Tomas Tomecek added the comment:

Unfortunately I can't, since it's internal docker image. I have found a bug report in Red Hat bugzilla with more info: https://bugzilla.redhat.com/show_bug.cgi?id=1194473 Here's even a commit with a fix (via monkeypatching): https://github.com/goldmann/docker-squash/commit/81d1c4c18960a5d940be9b986ccbfaa7853aceb1

If needed, I can construct a minimal reporoducer.

----------

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

From report at bugs.python.org  Tue Apr 12 06:01:15 2016
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 12 Apr 2016 10:01:15 +0000
Subject: [issue26673] Tkinter error when opening IDLE configuration menu
In-Reply-To: <1459351920.73.0.899924616631.issue26673@psf.upfronthosting.co.za>
Message-ID: <1460455275.62.0.439248963032.issue26673@psf.upfronthosting.co.za>


Petr Viktorin added the comment:

buggy:
    configuredFont: ('DejaVu Sans Mono', 0, 'normal')
    fontSize: 0

good:
    configuredFont: ('courier', 10, 'normal')
    fontSize: 10

----------

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

From report at bugs.python.org  Tue Apr 12 06:42:36 2016
From: report at bugs.python.org (WGH)
Date: Tue, 12 Apr 2016 10:42: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: <1460457756.9.0.96260363092.issue25330@psf.upfronthosting.co.za>


WGH added the comment:

I think it can even be considered a security bug. A classic path traversal. The fact that documentation falsely suggests that there's no such vulnerability is clearly not helping.

Python 2.7 is affected as well, by the way.

----------
nosy: +WGH

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

From report at bugs.python.org  Tue Apr 12 08:37:07 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 12 Apr 2016 12:37:07 +0000
Subject: [issue26729] Incorrect __text_signature__ for sorted
In-Reply-To: <1460310880.55.0.462687598027.issue26729@psf.upfronthosting.co.za>
Message-ID: <1460464627.1.0.326805297346.issue26729@psf.upfronthosting.co.za>


Martin Panter added the comment:

I didn?t realize about the keyword-only parameters. This is inherited from list.sort(). The signature can be corrected in 3.5.

There is also Issue 21314 about documenting the slash notation for signatures (it comes from PEP 457).

----------

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

From report at bugs.python.org  Tue Apr 12 09:12:46 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 12 Apr 2016 13:12:46 +0000
Subject: [issue15994] memoryview to freed memory can cause segfault
In-Reply-To: <1348173441.91.0.841080415833.issue15994@psf.upfronthosting.co.za>
Message-ID: <1460466766.45.0.764792073138.issue15994@psf.upfronthosting.co.za>


Martin Panter added the comment:

I recently created Issue 26720 about a similar situation with BufferedWriter. However I am starting to believe that the problem cannot be solved the way I originally wanted. Instead, the best solution there would be similar what I would suggest here: we need to avoid the user accessing the memoryview after readinto() or write() has returned. Some ideas, not all perfect:

1. Call memoryview.release() after the method returns. This would be simple and practical, but could be cheated by making a second memoryview of the original. Also, memoryview.release() is not guaranteed to succeed; there is code that raises BufferError("memoryview has exported buffers").

2. Raise an exception (BufferError or RuntimeError?) if readinto() or write() returns and the memoryview(s) are not all released. This doesn?t prevent a determined programmer from overwriting memory or losing written data, but it might let them know about the problem when it happens.

3. Try to force the memoryview.release() state on all views into the original memory. Is this practical? I guess this would be a bit inconsistent if some other thread was in the middle of a system call using the buffer at the time that we want to do the release.

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

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

From report at bugs.python.org  Tue Apr 12 09:16:17 2016
From: report at bugs.python.org (Erik Welch)
Date: Tue, 12 Apr 2016 13:16:17 +0000
Subject: [issue26729] Incorrect __text_signature__ for sorted
In-Reply-To: <1460310880.55.0.462687598027.issue26729@psf.upfronthosting.co.za>
Message-ID: <1460466977.97.0.632136227675.issue26729@psf.upfronthosting.co.za>


Erik Welch added the comment:

sorted_3.patch corrects the __text_signature__.  Behavior of sorted is unchanged.

>>> def raises(err, lamda):
...     try:
...         lamda()
...         return False
...     except err:
...         return True
...
>>> import inspect
>>> sig = inspect.signature(sorted) 
>>> # `iterable` is positional-only
>>> assert raises(TypeError, lambda: sorted(iterable=[]))
>>> assert raises(TypeError, lambda: sig.bind(iterable=[]))
>>> # `key` and `reverse` are keyword-only
>>> assert raises(TypeError, lambda: sorted([], lambda x: x))
>>> assert raises(TypeError, lambda: sig.bind([], lambda x: x))

----------
Added file: http://bugs.python.org/file42444/sorted_3.patch

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

From report at bugs.python.org  Tue Apr 12 09:25:06 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 12 Apr 2016 13:25:06 +0000
Subject: [issue20699] Document that binary IO classes work with bytes-likes
 objects
In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za>
Message-ID: <1460467506.92.0.354702598883.issue20699@psf.upfronthosting.co.za>


Martin Panter added the comment:

After thinking about Issue 26720 (see also Issue 15994), I think it might be worth documenting not only that bytes-like objects may be passed, but in some cases the class should not be access the object after the method returns. This applies to at least RawIOBase.readinto() and especially RawIOBase.write(). If you want to save the write() data in memory, you have to make a copy, because the original may be lost when BufferedWriter overwrites its internal buffeer.

----------

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

From report at bugs.python.org  Tue Apr 12 09:33:34 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 12 Apr 2016 13:33:34 +0000
Subject: [issue15994] memoryview to freed memory can cause segfault
In-Reply-To: <1348173441.91.0.841080415833.issue15994@psf.upfronthosting.co.za>
Message-ID: <1460468014.84.0.0500532619957.issue15994@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

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

From report at bugs.python.org  Tue Apr 12 09:39:11 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 12 Apr 2016 13:39:11 +0000
Subject: [issue26720] memoryview from BufferedWriter becomes garbage
In-Reply-To: <1460203726.07.0.470306343445.issue26720@psf.upfronthosting.co.za>
Message-ID: <1460468351.16.0.241200715938.issue26720@psf.upfronthosting.co.za>


Martin Panter added the comment:

I realize there is another problem, and doing tricks with a bytes object won?t help that. BufferedWriter bypasses its own buffer for large writes:

>>> writer = BufferedWriter(Raw())
>>> large = bytearray(10000)
>>> writer.write(large)
10000
>>> written.tobytes()[:10]
b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
>>> large[:5] = b"blaua"
>>> written.tobytes()[:10]
b'blaua\x00\x00\x00\x00\x00'

BufferedWriter is passing a view of the original input through, without any copying. Perhaps the simplest thing is to warn and prevent the user from accessing the buffer after write() returns. I suggested some imperfect ideas in Issue 15994. Maybe I should just close this as a duplicate.

----------

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

From report at bugs.python.org  Tue Apr 12 10:22:50 2016
From: report at bugs.python.org (Anthony S Valencia)
Date: Tue, 12 Apr 2016 14:22:50 +0000
Subject: [issue25931] os.fork() command distributed in windows Python27 (in
 SocketServer module)
In-Reply-To: <1450840231.57.0.83917358919.issue25931@psf.upfronthosting.co.za>
Message-ID: <1460470970.83.0.554693294543.issue25931@psf.upfronthosting.co.za>


Changes by Anthony S Valencia <anthonysvalencia at gmail.com>:


----------
nosy: +antvalencia

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

From report at bugs.python.org  Tue Apr 12 10:52:56 2016
From: report at bugs.python.org (supriyanto maftuh,st)
Date: Tue, 12 Apr 2016 14:52:56 +0000
Subject: [issue26699] locale.str docstring is incorrect: "Convert float to
 integer"
In-Reply-To: <1459927789.02.0.138982751213.issue26699@psf.upfronthosting.co.za>
Message-ID: <1460472776.75.0.0197804750468.issue26699@psf.upfronthosting.co.za>


Changes by supriyanto maftuh,st <supriyantomaftuh at gmail.com>:


----------
nosy: +supriyanto maftuh

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

From report at bugs.python.org  Tue Apr 12 10:59:14 2016
From: report at bugs.python.org (supriyanto maftuh,st)
Date: Tue, 12 Apr 2016 14:59:14 +0000
Subject: [issue25609] Add a ContextManager ABC and type
In-Reply-To: <1447355679.68.0.225089426373.issue25609@psf.upfronthosting.co.za>
Message-ID: <1460473154.12.0.772943558797.issue25609@psf.upfronthosting.co.za>


Changes by supriyanto maftuh,st <supriyantomaftuh at gmail.com>:


----------
nosy: +supriyanto maftuh

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

From report at bugs.python.org  Tue Apr 12 11:03:18 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 12 Apr 2016 15:03:18 +0000
Subject: [issue26718] super.__init__ leaks memory if called multiple times
In-Reply-To: <1460442688.39.0.876767635848.issue26718@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJKhPQYfCnb+uwEdeDwcnLx6E81HzwJz1=sd8DtQDs7Kvg@mail.gmail.com>


Guido van Rossum added the comment:

Do #1.

--Guido (mobile)
On Apr 11, 2016 11:31 PM, "Serhiy Storchaka" <report at bugs.python.org> wrote:

>
> Serhiy Storchaka added the comment:
>
> Possible solutions:
>
> 1. Correctly decref old values.
> 2. Raise an exception if super.__init__ is caled multiple times.
> 3. Remove super.__init__ and add super.__new__.
>
> What is more preferable?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue26718>
> _______________________________________
>

----------

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

From report at bugs.python.org  Tue Apr 12 11:26:02 2016
From: report at bugs.python.org (supriyanto maftuh,st)
Date: Tue, 12 Apr 2016 15:26:02 +0000
Subject: [issue25931] os.fork() command distributed in windows Python27 (in
 SocketServer module)
In-Reply-To: <1450840231.57.0.83917358919.issue25931@psf.upfronthosting.co.za>
Message-ID: <1460474762.95.0.835124567751.issue25931@psf.upfronthosting.co.za>


Changes by supriyanto maftuh,st <supriyantomaftuh at gmail.com>:


----------
nosy: +supriyanto maftuh
versions: +Python 3.4

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

From report at bugs.python.org  Tue Apr 12 11:29:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2016 15:29:03 +0000
Subject: [issue26718] super.__init__ leaks memory if called multiple times
In-Reply-To: <1460163723.35.0.208266777223.issue26718@psf.upfronthosting.co.za>
Message-ID: <1460474943.67.0.715468267721.issue26718@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/issue26718>
_______________________________________

From report at bugs.python.org  Tue Apr 12 11:34:15 2016
From: report at bugs.python.org (supriyanto maftuh,st)
Date: Tue, 12 Apr 2016 15:34:15 +0000
Subject: [issue24136] document PEP 448: unpacking generalization
In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za>
Message-ID: <1460475255.53.0.760017668845.issue24136@psf.upfronthosting.co.za>


supriyanto maftuh,st added the comment:

Hy

----------
components: +Benchmarks, Build, IO, Unicode, Windows, XML, email
hgrepos: +336
nosy: +barry, brett.cannon, ezio.melotti, haypo, paul.moore, pitrou, r.david.murray, steve.dower, supriyanto maftuh, supriyanto maftuh,st, tim.golden, zach.ware
versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr 12 11:40:56 2016
From: report at bugs.python.org (supriyanto maftuh,st)
Date: Tue, 12 Apr 2016 15:40:56 +0000
Subject: [issue24557] Refactor LibreSSL / EGD detection
In-Reply-To: <1435926751.49.0.18395819216.issue24557@psf.upfronthosting.co.za>
Message-ID: <1460475656.81.0.197280393547.issue24557@psf.upfronthosting.co.za>


supriyanto maftuh,st added the comment:

Easy to review with issues phyton, maintenanca by supriyanto maftuh

----------
assignee:  -> docs at python
components: +2to3 (2.x to 3.x conversion tool), Argument Clinic, Benchmarks, Cross-Build, Demos and Tools, Devguide, Distutils, Documentation, Extension Modules, IDLE, IO, Installation, Interpreter Core, Macintosh, Regular Expressions, Tests, Tkinter, Unicode, Windows, XML, asyncio, ctypes, email
hgrepos: +337
nosy: +Alex.Willmer, barry, brett.cannon, docs at python, dstufft, eric.araujo, ezio.melotti, gvanrossum, haypo, larry, mrabarnett, ned.deily, paul.moore, pitrou, r.david.murray, ronaldoussoren, steve.dower, supriyanto maftuh, supriyanto maftuh,st, tim.golden, willingc, yselivanov, zach.ware
versions: +Python 3.2, Python 3.6

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

From report at bugs.python.org  Tue Apr 12 11:43:36 2016
From: report at bugs.python.org (supriyanto maftuh,st)
Date: Tue, 12 Apr 2016 15:43:36 +0000
Subject: [issue19217] Calling assertEquals for moderately long list takes too
 long
In-Reply-To: <1381410286.72.0.514206486634.issue19217@psf.upfronthosting.co.za>
Message-ID: <1460475816.46.0.0902773593591.issue19217@psf.upfronthosting.co.za>


supriyanto maftuh,st added the comment:

Hy easy patch with editing maintenance by supriyanto maftuh

----------
components: +Build, Documentation, Unicode, Windows, XML
hgrepos: +338
nosy: +paul.moore, steve.dower, supriyanto maftuh, supriyanto maftuh,st, tim.golden, zach.ware
versions: +Python 3.2, Python 3.3, Python 3.6

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

From report at bugs.python.org  Tue Apr 12 11:43:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Apr 2016 15:43:40 +0000
Subject: [issue26718] super.__init__ leaks memory if called multiple times
In-Reply-To: <1460163723.35.0.208266777223.issue26718@psf.upfronthosting.co.za>
Message-ID: <1460475820.33.0.932855583561.issue26718@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch.

----------
keywords: +patch
stage:  -> patch review
type: behavior -> resource usage
Added file: http://bugs.python.org/file42445/super_init_leaks.patch

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

From report at bugs.python.org  Tue Apr 12 11:44:31 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 12 Apr 2016 15:44:31 +0000
Subject: [issue25931] os.fork() command distributed in windows Python27 (in
 SocketServer module)
In-Reply-To: <1450840231.57.0.83917358919.issue25931@psf.upfronthosting.co.za>
Message-ID: <1460475871.56.0.957574538213.issue25931@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
versions:  -Python 3.4

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

From report at bugs.python.org  Tue Apr 12 11:45:28 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2016 15:45:28 +0000
Subject: [issue26718] super.__init__ leaks memory if called multiple times
In-Reply-To: <1460163723.35.0.208266777223.issue26718@psf.upfronthosting.co.za>
Message-ID: <1460475928.29.0.3932603179.issue26718@psf.upfronthosting.co.za>


STINNER Victor added the comment:

super_init_leaks.patch LGTM, it fixes. I confirm that the patch fixes the refleak. I checked with:

$ ./python -m test -R 3:3 test_super

----------

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

From report at bugs.python.org  Tue Apr 12 11:46:17 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2016 15:46:17 +0000
Subject: [issue26642] Replace stdout and stderr with simple standard printers
 at Python exit
In-Reply-To: <1458911597.09.0.705997743741.issue26642@psf.upfronthosting.co.za>
Message-ID: <1460475977.05.0.223658392308.issue26642@psf.upfronthosting.co.za>


STINNER Victor added the comment:

@Serhiy: Would you mind reviewing replace_stdio-2.patch?

----------

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

From report at bugs.python.org  Tue Apr 12 11:46:51 2016
From: report at bugs.python.org (supriyanto maftuh,st)
Date: Tue, 12 Apr 2016 15:46:51 +0000
Subject: [issue20767] Some python extensions can't be compiled with clang 3.4
In-Reply-To: <1393335198.15.0.97052317234.issue20767@psf.upfronthosting.co.za>
Message-ID: <1460476011.81.0.998368506387.issue20767@psf.upfronthosting.co.za>


Changes by supriyanto maftuh,st <supriyantomaftuh at gmail.com>:


----------
components: +Build, Extension Modules, Interpreter Core, Tkinter, Unicode, Windows, XML
hgrepos: +339
nosy: +dstufft, eric.araujo, ezio.melotti, paul.moore, steve.dower, tim.golden, zach.ware
versions: +Python 3.2

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

From report at bugs.python.org  Tue Apr 12 11:47:14 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2016 15:47:14 +0000
Subject: [issue26639] Tools/i18n/pygettext.py: replace deprecated imp module
 with importlib
In-Reply-To: <1458903005.49.0.704638577802.issue26639@psf.upfronthosting.co.za>
Message-ID: <1460476034.34.0.213215585262.issue26639@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Can someone please review pygettext_imp.patch?

(I send a ping since Roundup email notifications were broken recently.)

----------

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

From report at bugs.python.org  Tue Apr 12 11:48:52 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2016 15:48:52 +0000
Subject: [issue26610] test_venv.test_with_pip() fails when ctypes is missing
In-Reply-To: <1458643946.17.0.878468383793.issue26610@psf.upfronthosting.co.za>
Message-ID: <1460476132.71.0.55167501477.issue26610@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Since the initial issue is fixed, I close the issue.

You can revert my change if a new pip version works (again?) without ctypes.

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

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

From report at bugs.python.org  Tue Apr 12 11:52:45 2016
From: report at bugs.python.org (supriyanto maftuh,st)
Date: Tue, 12 Apr 2016 15:52:45 +0000
Subject: [issue26639] Tools/i18n/pygettext.py: replace deprecated imp module
 with importlib
In-Reply-To: <1458903005.49.0.704638577802.issue26639@psf.upfronthosting.co.za>
Message-ID: <1460476365.4.0.433518391374.issue26639@psf.upfronthosting.co.za>


Changes by supriyanto maftuh,st <supriyantomaftuh at gmail.com>:


----------
components: +Benchmarks, Demos and Tools, Unicode
hgrepos: +340
nosy: +ezio.melotti, pitrou, supriyanto maftuh
type:  -> compile error
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/issue26639>
_______________________________________

From report at bugs.python.org  Tue Apr 12 11:54:35 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2016 15:54:35 +0000
Subject: [issue26716] EINTR handling in fcntl
In-Reply-To: <1460145033.33.0.165294517839.issue26716@psf.upfronthosting.co.za>
Message-ID: <1460476475.51.0.05381657922.issue26716@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I think it would be nice to publish somewhere (on ActoveState receipts, on StackOverflow) well-searchable correct example.

Yeah, it's always possible to enhance the doc. I'm not an user of ActiveState or StackOverflow websites. Don't hesitate to submit a comment to explain the PEP 475 ;-)

Is it ok to fix Python 3.5? Or is it safer to only fix the issue in Python 3.6?

----------

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

From report at bugs.python.org  Tue Apr 12 11:57:52 2016
From: report at bugs.python.org (Matthew Ryan)
Date: Tue, 12 Apr 2016 15:57:52 +0000
Subject: [issue26735] os.urandom(2500) fails on Solaris 11.3
In-Reply-To: <1460448947.52.0.566628347647.issue26735@psf.upfronthosting.co.za>
Message-ID: <CACDhJGGW3z=GcO55b7DxMf_AxAFYUQQyZo0fagDf0XOu2RuyPA@mail.gmail.com>


Matthew Ryan added the comment:

The new patch looks fine; I used __sun__ rather than sun out of habit
(C standard requires
system specific macros be in the reserved namespace), but either will work.

I found the original problem through debugging with GDB, so I know
getrandom() was being
called, and the test case I provided (taken from Lib/Random.py) fails
without the patch,
and succeeds with it.

Oddly, the blog post you linked to describes getrandom as:
"Recent Linux kernels have a getrandom(2) system call that reads
between 1 and 1024 bytes of randomness"

But no such limit current exists in the Linux version that I can see;
however, the Solaris
version definitely does have that limit:
https://docs.oracle.com/cd/E53394_01/html/E54765/getrandom-2.html

On Tue, Apr 12, 2016 at 1:15 AM, STINNER Victor <report at bugs.python.org> wrote:
>
> STINNER Victor added the comment:
>
>> I've attached a possible patch for this issue, against the 3.5.1 source
> tree.
>
> I guess that you are already using Python 3.5.1 which uses getrandom(). You should try to confirm using strace.
>
> I updated your patch. I replaced "#if defined(__sun__)" with "#ifdef sun", since "#ifdef sun" looks more common in the Python code base, and I never saw "#if defined(__sun__)" in the Python code base.
>
> I also avoided the new len variable, I reused the n variable.
>
> I don't have Solaris, so I cannot test. I didn't find getrandom() manual page neither, I only found this blog post which doesn't mention the 1024 bytes limitation on Solaris:
> https://blogs.oracle.com/darren/entry/solaris_new_system_calls_getentropy
>
> ----------
> Added file: http://bugs.python.org/file42443/urandom_solaris.patch
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue26735>
> _______________________________________

----------

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

From report at bugs.python.org  Tue Apr 12 11:58:43 2016
From: report at bugs.python.org (supriyanto maftuh,st)
Date: Tue, 12 Apr 2016 15:58:43 +0000
Subject: [issue15984] Wrong documentation for PyUnicode_FromObject() and
 PyUnicode_FromEncodedObject()
In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za>
Message-ID: <1460476723.66.0.388071134046.issue15984@psf.upfronthosting.co.za>


Changes by supriyanto maftuh,st <supriyantomaftuh at gmail.com>:


----------
components: +Build, Tests, Unicode, Windows, XML
hgrepos: +341
nosy: +ezio.melotti, paul.moore, steve.dower, supriyanto maftuh, tim.golden, zach.ware

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

From report at bugs.python.org  Tue Apr 12 11:59:06 2016
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 12 Apr 2016 15:59:06 +0000
Subject: [issue15984] Wrong documentation for PyUnicode_FromObject() and
 PyUnicode_FromEncodedObject()
In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za>
Message-ID: <1460476746.12.0.734522288543.issue15984@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
nosy:  -brian.curtin

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

From report at bugs.python.org  Tue Apr 12 12:07:54 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2016 16:07:54 +0000
Subject: [issue25942] subprocess.call SIGKILLs too liberally
In-Reply-To: <1451006108.23.0.113868196098.issue25942@psf.upfronthosting.co.za>
Message-ID: <1460477274.89.0.575307619141.issue25942@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Again, the problem is that the exception exits from the function which owns the last reference to the Popen object. If the Popen is left alive when you exit the function, you create a zombi process, you can leave open pipes, etc.

It's unclear to me if CTRL+c sends SIGTERM to all processes or only a few of them (only the parent process?). Even if SIGTERM is sent to all processes, a child process can decide to completly ignore it, or can block in a deadlock or whatever.

Giving a few seconds to the child process to wait until it ends is not easy because it's hard to choose an arbitrary timeout. If the timeout is too low, you kill the child process (SIGKILL) before it flushes files. If the timeout is too long, the parent process is blocked too long when the child process is really blocked.

I suggest to keep the current behaviour by default.

If you really want to give time to the child process, I suggest to add a *new* optional parameter . For example ctrlc_timeout=5.0 to send SIGTERM and then wait 5 seconds.

I don't know if the parent process must always send a SIGTERM to the child process or not. One signal or two don't have the same behaviour. It's possible to explicitly send a SIGTERM to only one process using the kill command.

----------

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

From report at bugs.python.org  Tue Apr 12 12:12:59 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2016 16:12:59 +0000
Subject: [issue26735] os.urandom(2500) fails on Solaris 11.3
In-Reply-To: <1460396108.06.0.541477402311.issue26735@psf.upfronthosting.co.za>
Message-ID: <1460477579.8.0.59083910104.issue26735@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The new patch looks fine

Do you mean that it fixes your issue? Can it be applied to Python 3.5 & 3.6?

----------

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

From report at bugs.python.org  Tue Apr 12 12:19:03 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 12 Apr 2016 16:19:03 +0000
Subject: [issue24136] document PEP 448: unpacking generalization
In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za>
Message-ID: <1460477943.63.0.847372354388.issue24136@psf.upfronthosting.co.za>


Berker Peksag added the comment:

supriyanto maftuh,st, please don't play with tracker items.

----------
components:  -Benchmarks, Build, IO, Unicode, Windows, XML, email
versions:  -Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr 12 12:19:28 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 12 Apr 2016 16:19:28 +0000
Subject: [issue24136] document PEP 448: unpacking generalization
In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za>
Message-ID: <1460477968.34.0.142308761035.issue24136@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Apr 12 12:23:45 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 12 Apr 2016 16:23:45 +0000
Subject: [issue24557] Refactor LibreSSL / EGD detection
In-Reply-To: <1435926751.49.0.18395819216.issue24557@psf.upfronthosting.co.za>
Message-ID: <1460478225.65.0.631915619653.issue24557@psf.upfronthosting.co.za>


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


----------
components:  -2to3 (2.x to 3.x conversion tool), Argument Clinic, Benchmarks, Build, Cross-Build, Demos and Tools, Devguide, Distutils, Documentation, Extension Modules, IDLE, IO, Installation, Interpreter Core, Macintosh, Regular Expressions, Tests, Tkinter, Unicode, Windows, XML, asyncio, ctypes, email
stage:  -> patch review
versions:  -Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr 12 12:26:05 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 12 Apr 2016 16:26:05 +0000
Subject: [issue24557] Refactor LibreSSL / EGD detection
In-Reply-To: <1435926751.49.0.18395819216.issue24557@psf.upfronthosting.co.za>
Message-ID: <1460478365.95.0.882524177759.issue24557@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


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

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

From report at bugs.python.org  Tue Apr 12 12:28:29 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 12 Apr 2016 16:28:29 +0000
Subject: [issue19217] Calling assertEquals for moderately long list takes too
 long
In-Reply-To: <1381410286.72.0.514206486634.issue19217@psf.upfronthosting.co.za>
Message-ID: <1460478509.74.0.309564645558.issue19217@psf.upfronthosting.co.za>


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


----------
components:  -Build, Documentation, Unicode, Windows, XML
nosy:  -supriyanto maftuh, supriyantomaftuh
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/issue19217>
_______________________________________

From report at bugs.python.org  Tue Apr 12 12:28:39 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 12 Apr 2016 16:28:39 +0000
Subject: [issue19217] Calling assertEquals for moderately long list takes too
 long
In-Reply-To: <1381410286.72.0.514206486634.issue19217@psf.upfronthosting.co.za>
Message-ID: <1460478519.02.0.331156196966.issue19217@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Apr 12 12:29:01 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2016 16:29:01 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1460478541.92.0.877293529733.issue26647@psf.upfronthosting.co.za>


STINNER Victor added the comment:

module_finder.patch: cleanup (optimize?) modulefinder.ModuleFinder.scan_opcodes_25(): Use an index rather than creating a lot of substrings.

It's unrelated to Wordcode, it's just that I noticed the inefficient code while reviewing the whole patch.

----------
Added file: http://bugs.python.org/file42446/module_finder.patch

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

From report at bugs.python.org  Tue Apr 12 12:30:27 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 12 Apr 2016 16:30:27 +0000
Subject: [issue26639] Tools/i18n/pygettext.py: replace deprecated imp module
 with importlib
In-Reply-To: <1458903005.49.0.704638577802.issue26639@psf.upfronthosting.co.za>
Message-ID: <1460478627.95.0.544819641395.issue26639@psf.upfronthosting.co.za>


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


----------
components:  -Benchmarks, Unicode
stage:  -> patch review
type: compile error -> 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/issue26639>
_______________________________________

From report at bugs.python.org  Tue Apr 12 12:35:17 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 12 Apr 2016 16:35:17 +0000
Subject: [issue26639] Tools/i18n/pygettext.py: replace deprecated imp module
 with importlib
In-Reply-To: <1458903005.49.0.704638577802.issue26639@psf.upfronthosting.co.za>
Message-ID: <1460478917.87.0.00663034020611.issue26639@psf.upfronthosting.co.za>


Berker Peksag added the comment:

pygettext_imp.patch looks good to me. I left a comment on Rietveld.

----------

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

From report at bugs.python.org  Tue Apr 12 12:41:12 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 12 Apr 2016 16:41:12 +0000
Subject: [issue20767] Some python extensions can't be compiled with clang 3.4
In-Reply-To: <1393335198.15.0.97052317234.issue20767@psf.upfronthosting.co.za>
Message-ID: <1460479272.36.0.622811808982.issue20767@psf.upfronthosting.co.za>


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


----------
components:  -Build, Extension Modules, Interpreter Core, Tkinter, Unicode, Windows, XML
stage:  -> patch review
versions:  -Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr 12 12:42:39 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 12 Apr 2016 16:42:39 +0000
Subject: [issue15984] Wrong documentation for PyUnicode_FromObject() and
 PyUnicode_FromEncodedObject()
In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za>
Message-ID: <1460479359.1.0.600982378229.issue15984@psf.upfronthosting.co.za>


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


----------
components:  -Build, Tests, Unicode, Windows, XML

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

From report at bugs.python.org  Tue Apr 12 12:44:17 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Apr 2016 16:44:17 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <20160412164414.11595.96685.928329CC@psf.io>


Roundup Robot added the comment:

New changeset 7bf08a11d4c9 by Victor Stinner in branch 'default':
Issue #26647: Cleanup opcode
https://hg.python.org/cpython/rev/7bf08a11d4c9

New changeset 423e2a96189e by Victor Stinner in branch 'default':
Issue #26647: Cleanup modulefinder
https://hg.python.org/cpython/rev/423e2a96189e

New changeset f8398dba48fb by Victor Stinner in branch '3.5':
Issue #26647: Fix typo in test_grammar
https://hg.python.org/cpython/rev/f8398dba48fb

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

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

From report at bugs.python.org  Tue Apr 12 12:46:19 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Apr 2016 16:46:19 +0000
Subject: [issue26639] Tools/i18n/pygettext.py: replace deprecated imp module
 with importlib
In-Reply-To: <1458903005.49.0.704638577802.issue26639@psf.upfronthosting.co.za>
Message-ID: <20160412164616.18841.41551.582F4FA3@psf.io>


Roundup Robot added the comment:

New changeset cd03ff74eaea by Victor Stinner in branch 'default':
Update pygettext.py to get ride of imp
https://hg.python.org/cpython/rev/cd03ff74eaea

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

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

From report at bugs.python.org  Tue Apr 12 12:47:15 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2016 16:47:15 +0000
Subject: [issue26639] Tools/i18n/pygettext.py: replace deprecated imp module
 with importlib
In-Reply-To: <1458903005.49.0.704638577802.issue26639@psf.upfronthosting.co.za>
Message-ID: <1460479635.13.0.10061738969.issue26639@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> pygettext_imp.patch looks good to me.

Thanks for the review.

> I left a comment on Rietveld.

Oops, I added it but then inlined the function in caller sites. I removed the now empty function :-)

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

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

From report at bugs.python.org  Tue Apr 12 13:40:12 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 12 Apr 2016 17:40:12 +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: <1460482812.75.0.561831840608.issue25330@psf.upfronthosting.co.za>


Brett Cannon added the comment:

This can't change in Python 2.7 because of backwards-compatibility. And I would argue this isn't a serious security risk as pkgutil.get_data() typically works with string constants and values provided by the library and not user-provided values. This is basically the same as taking a value for open() and has the same risks.

----------

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

From report at bugs.python.org  Tue Apr 12 13:41:15 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 12 Apr 2016 17:41:15 +0000
Subject: [issue24136] document PEP 448: unpacking generalization
In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za>
Message-ID: <1460482875.23.0.535310514122.issue24136@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/issue24136>
_______________________________________

From report at bugs.python.org  Tue Apr 12 14:29:30 2016
From: report at bugs.python.org (Matthew Ryan)
Date: Tue, 12 Apr 2016 18:29:30 +0000
Subject: [issue26735] os.urandom(2500) fails on Solaris 11.3
In-Reply-To: <1460477579.8.0.59083910104.issue26735@psf.upfronthosting.co.za>
Message-ID: <CACDhJGEgffvT-6nd=ZXf8StXY=udX5K+pr6hF2RCpJbVFoNE1A@mail.gmail.com>


Matthew Ryan added the comment:

Yes, I've verified that:
* the issue existed in the default branch as of this morning.
* the patch applies cleanly against both 3.5 and default, and
addresses the issue in both branches.

----------

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

From report at bugs.python.org  Tue Apr 12 14:47:29 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Apr 2016 18:47:29 +0000
Subject: [issue26718] super.__init__ leaks memory if called multiple times
In-Reply-To: <1460163723.35.0.208266777223.issue26718@psf.upfronthosting.co.za>
Message-ID: <1460486849.49.0.967805944326.issue26718@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added more comments as suggested by Guido.

----------
Added file: http://bugs.python.org/file42447/super_init_leaks_2.patch

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

From report at bugs.python.org  Tue Apr 12 14:52:33 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 12 Apr 2016 18:52:33 +0000
Subject: [issue24557] Refactor LibreSSL / EGD detection
In-Reply-To: <1435926751.49.0.18395819216.issue24557@psf.upfronthosting.co.za>
Message-ID: <1460487153.87.0.864354486625.issue24557@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> 
nosy:  -docs at python, supriyanto maftuh, supriyantomaftuh, zach.ware
versions: +Python 2.7

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

From report at bugs.python.org  Tue Apr 12 14:52:44 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 12 Apr 2016 18:52:44 +0000
Subject: [issue24557] Refactor LibreSSL / EGD detection
In-Reply-To: <1435926751.49.0.18395819216.issue24557@psf.upfronthosting.co.za>
Message-ID: <1460487164.29.0.236385265071.issue24557@psf.upfronthosting.co.za>


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


----------
hgrepos:  -337

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

From report at bugs.python.org  Tue Apr 12 14:52:57 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 12 Apr 2016 18:52:57 +0000
Subject: [issue20767] Some python extensions can't be compiled with clang 3.4
In-Reply-To: <1393335198.15.0.97052317234.issue20767@psf.upfronthosting.co.za>
Message-ID: <1460487177.14.0.932042426215.issue20767@psf.upfronthosting.co.za>


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


----------
hgrepos:  -339

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

From report at bugs.python.org  Tue Apr 12 14:54:43 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 12 Apr 2016 18:54:43 +0000
Subject: [issue19217] Calling assertEquals for moderately long list takes too
 long
In-Reply-To: <1381410286.72.0.514206486634.issue19217@psf.upfronthosting.co.za>
Message-ID: <1460487283.45.0.335079216654.issue19217@psf.upfronthosting.co.za>


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


----------
hgrepos:  -338

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

From report at bugs.python.org  Tue Apr 12 15:04:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Apr 2016 19:04:48 +0000
Subject: [issue26716] EINTR handling in fcntl
In-Reply-To: <1460145033.33.0.165294517839.issue26716@psf.upfronthosting.co.za>
Message-ID: <1460487888.7.0.578787247761.issue26716@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I just don't know whether the patch will break existing code that relies on current behavior. If EINTR handling in other functions was not backported to older versions, I think this is good argument against fixing this issue in 3.5.

Could you write tests with signal handlers raising and not raising an exception?

----------

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

From report at bugs.python.org  Tue Apr 12 15:05:58 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 12 Apr 2016 19:05:58 +0000
Subject: [issue15984] Wrong documentation for PyUnicode_FromObject() and
 PyUnicode_FromEncodedObject()
In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za>
Message-ID: <1460487958.68.0.264701473027.issue15984@psf.upfronthosting.co.za>


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


----------
hgrepos:  -341

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

From report at bugs.python.org  Tue Apr 12 15:06:40 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 12 Apr 2016 19:06:40 +0000
Subject: [issue26639] Tools/i18n/pygettext.py: replace deprecated imp module
 with importlib
In-Reply-To: <1458903005.49.0.704638577802.issue26639@psf.upfronthosting.co.za>
Message-ID: <1460488000.91.0.68877096968.issue26639@psf.upfronthosting.co.za>


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


----------
hgrepos:  -340

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

From report at bugs.python.org  Tue Apr 12 15:07:42 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 12 Apr 2016 19:07:42 +0000
Subject: [issue24136] document PEP 448: unpacking generalization
In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za>
Message-ID: <1460488062.59.0.149546376589.issue24136@psf.upfronthosting.co.za>


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


----------
hgrepos:  -336

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

From report at bugs.python.org  Tue Apr 12 15:11:39 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 12 Apr 2016 19:11:39 +0000
Subject: [issue15216] Support setting the encoding on a text stream after
 creation
In-Reply-To: <1340880558.16.0.0136840668667.issue15216@psf.upfronthosting.co.za>
Message-ID: <1460488299.01.0.931716986.issue15216@psf.upfronthosting.co.za>


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


----------
hgrepos:  -334

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

From report at bugs.python.org  Tue Apr 12 15:12:57 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 12 Apr 2016 19:12:57 +0000
Subject: [issue23076] list(pathlib.Path().glob("")) fails with IndexError
In-Reply-To: <1418860780.4.0.558535328721.issue23076@psf.upfronthosting.co.za>
Message-ID: <1460488377.45.0.667841570225.issue23076@psf.upfronthosting.co.za>


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


----------
hgrepos:  -331

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

From report at bugs.python.org  Tue Apr 12 15:14:04 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 12 Apr 2016 19:14:04 +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: <1460488444.44.0.493951613939.issue25496@psf.upfronthosting.co.za>


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


----------
hgrepos:  -330

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

From report at bugs.python.org  Tue Apr 12 15:17:01 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 12 Apr 2016 19:17:01 +0000
Subject: [issue25835] httplib uses print for debugging
In-Reply-To: <1449799961.35.0.0559647845102.issue25835@psf.upfronthosting.co.za>
Message-ID: <1460488621.75.0.798053339203.issue25835@psf.upfronthosting.co.za>


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


----------
hgrepos:  -327

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

From report at bugs.python.org  Tue Apr 12 15:39:06 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Apr 2016 19:39:06 +0000
Subject: [issue26720] memoryview from BufferedWriter becomes garbage
In-Reply-To: <1460203726.07.0.470306343445.issue26720@psf.upfronthosting.co.za>
Message-ID: <1460489946.13.0.11121730078.issue26720@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I meant getting rid of memoryview at all and passing bytes buffer object directly to underlying write. But now I see that this idea perhaps is not feasible since we must write not only from the start of the buffer.

A writer like AuditableBytesIO is very attractive implementation. I used it multiple times, especially in tests. Your initial proposition LGTM, and perhaps this is only the solution applicable in maintained releases. Thus we should implement it in any case. In 3.6 we can add a warning.

Note that there are two kinds of references to a buffer: a reference to memoryview object and new memoryview that refers to the same buffer.

----------

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

From report at bugs.python.org  Tue Apr 12 15:44:57 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 12 Apr 2016 19:44:57 +0000
Subject: [issue26673] Tkinter error when opening IDLE configuration menu
In-Reply-To: <1459351920.73.0.899924616631.issue26673@psf.upfronthosting.co.za>
Message-ID: <1460490297.26.0.898764070329.issue26673@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Thank you.  I believe a see a bug in configHandler.)idleConf.GetFont(self, 'main', 'EditorWindow') returning a size of 0.  Could you post the result of running the following for the bad case?

import tkinter as tk
from tkinter.font import Font
root=tk.Tk()
f = Font(name='TkFixedFont', exists=True, root=root)
print(Font.actual(f))

There is still a question of how fontSize=0 becomes self.fontSize=='', but that will not matter when fontSize=0 is prevented.

----------

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

From report at bugs.python.org  Tue Apr 12 16:16:49 2016
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 12 Apr 2016 20:16:49 +0000
Subject: [issue24557] Refactor LibreSSL / EGD detection
In-Reply-To: <1435926751.49.0.18395819216.issue24557@psf.upfronthosting.co.za>
Message-ID: <1460492209.02.0.0846323439187.issue24557@psf.upfronthosting.co.za>


Changes by Matthew Barnett <python at mrabarnett.plus.com>:


----------
nosy:  -mrabarnett

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

From report at bugs.python.org  Tue Apr 12 16:22:14 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 12 Apr 2016 20:22:14 +0000
Subject: [issue24557] Refactor LibreSSL / EGD detection
In-Reply-To: <1435926751.49.0.18395819216.issue24557@psf.upfronthosting.co.za>
Message-ID: <1460492534.27.0.0789399733745.issue24557@psf.upfronthosting.co.za>


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


----------
nosy:  -gvanrossum

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

From report at bugs.python.org  Tue Apr 12 16:39:57 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Apr 2016 20:39:57 +0000
Subject: [issue26735] os.urandom(2500) fails on Solaris 11.3
In-Reply-To: <1460396108.06.0.541477402311.issue26735@psf.upfronthosting.co.za>
Message-ID: <20160412203954.7567.637.3D9E14C5@psf.io>


Roundup Robot added the comment:

New changeset fb7628e8dfef by Victor Stinner in branch '3.5':
Fix os.urandom() on Solaris 11.3
https://hg.python.org/cpython/rev/fb7628e8dfef

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

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

From report at bugs.python.org  Tue Apr 12 16:40:59 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2016 20:40:59 +0000
Subject: [issue26735] os.urandom(2500) fails on Solaris 11.3
In-Reply-To: <1460396108.06.0.541477402311.issue26735@psf.upfronthosting.co.za>
Message-ID: <1460493659.39.0.575279019171.issue26735@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Yes, I've verified that: (...)

Cool, thanks for the bug report and for the check.

It's now fixed. In the meanwhile, you can workaround the issue by limiting yourself calls to os.urandom() to 1024 bytes (and then concatenate the result).

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

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

From report at bugs.python.org  Tue Apr 12 16:42:07 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2016 20:42:07 +0000
Subject: [issue26718] super.__init__ leaks memory if called multiple times
In-Reply-To: <1460163723.35.0.208266777223.issue26718@psf.upfronthosting.co.za>
Message-ID: <1460493727.68.0.954819421982.issue26718@psf.upfronthosting.co.za>


STINNER Victor added the comment:

super_init_leaks_2.patch LGTM.

----------

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

From report at bugs.python.org  Tue Apr 12 16:44:39 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2016 20:44:39 +0000
Subject: [issue26716] EINTR handling in fcntl
In-Reply-To: <1460487888.7.0.578787247761.issue26716@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZk_2x=6NwB89Sf25q51_mAH6bwmDSuPzR1zhzny8KTJA@mail.gmail.com>


STINNER Victor added the comment:

Ok, I will update the patch to include an unit test and only apply it
to Python 3.5.

----------

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

From report at bugs.python.org  Tue Apr 12 17:49:13 2016
From: report at bugs.python.org (Paul Moore)
Date: Tue, 12 Apr 2016 21:49:13 +0000
Subject: [issue24557] Refactor LibreSSL / EGD detection
In-Reply-To: <1435926751.49.0.18395819216.issue24557@psf.upfronthosting.co.za>
Message-ID: <1460497753.87.0.135766772492.issue24557@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/issue24557>
_______________________________________

From report at bugs.python.org  Tue Apr 12 18:01:37 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2016 22:01:37 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1460498497.09.0.198954623629.issue26647@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Demur Rumed: can you please rebase your patch? And can you please generate a patch without the git format?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Tue Apr 12 18:11:02 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 12 Apr 2016 22:11:02 +0000
Subject: [issue25942] subprocess.call SIGKILLs too liberally
In-Reply-To: <1451006108.23.0.113868196098.issue25942@psf.upfronthosting.co.za>
Message-ID: <1460499062.71.0.893435193838.issue25942@psf.upfronthosting.co.za>


Martin Panter added the comment:

I don?t know how it works on Windows, but on Unix in most cases the parent and child will share a controlling terminal. Pressing Ctrl+C in the terminal will broadcast SIGINT to all processes, parent and child. That is probably why os.system() ignores SIGINT.

I doubt the usefulness of building in extra timeouts to send SIGTERM and SIGKILL. If the user really cares that much, they can probably design their own timeout mechanism. That is why I suggested above to treat the non-timeout mode differently.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25942>
_______________________________________

From report at bugs.python.org  Tue Apr 12 18:21:38 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 12 Apr 2016 22:21:38 +0000
Subject: [issue26729] Incorrect __text_signature__ for sorted
In-Reply-To: <1460310880.55.0.462687598027.issue26729@psf.upfronthosting.co.za>
Message-ID: <1460499698.67.0.432940574345.issue26729@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch 3 looks okay to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26729>
_______________________________________

From report at bugs.python.org  Tue Apr 12 18:49:07 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2016 22:49:07 +0000
Subject: [issue26741] subprocess.Popen should emit a ResourceWarning in
 destructor if the process is still running
Message-ID: <1460501347.41.0.70782898945.issue26741@psf.upfronthosting.co.za>


New submission from STINNER Victor:

A subprocess.Popen object contains many resources: pipes, a child process (its pid, and an handle on Windows), etc.

IMHO it's not safe to rely on the destructor to release all resources. I would prefer to release resources explicitly. For example, use proc.wait() or "with proc:".

Attached patch emits a ResourceWarning in Popen destructor if the status of the child process was not read yet.

The patch changes also _execute_child() to set the returncode on error, if the child process raised a Python exception. It avoids to emit a ResourceWarning on this case.

The patch fixes also unit tests to release explicitly resources. self.addCleanup(p.stdout.close) is not enough: use "with proc:" instead.

TODO: fix also the Windows implementation of _execute_child().

----------
components: Library (Lib)
messages: 263281
nosy: haypo, martin.panter, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: subprocess.Popen should emit a ResourceWarning in destructor if the process is still running
type: resource usage
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26741>
_______________________________________

From report at bugs.python.org  Tue Apr 12 18:57:46 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2016 22:57:46 +0000
Subject: [issue26732] multiprocessing sentinel resource leak
In-Reply-To: <1460325501.58.0.225914662536.issue26732@psf.upfronthosting.co.za>
Message-ID: <1460501866.57.0.644466130481.issue26732@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I confirm the issue with Python 3.6 on Linux.

File descriptors of the parent process:

haypo at selma$ ls -l /proc/31564/fd/
lrwx------. 1 haypo haypo 64 13 avril 00:55 0 -> /dev/pts/0
lrwx------. 1 haypo haypo 64 13 avril 00:55 1 -> /dev/pts/0
lr-x------. 1 haypo haypo 64 13 avril 00:55 10 -> pipe:[697354]
lr-x------. 1 haypo haypo 64 13 avril 00:55 11 -> pipe:[697355]
lr-x------. 1 haypo haypo 64 13 avril 00:55 12 -> pipe:[697356]
lrwx------. 1 haypo haypo 64 13 avril 00:54 2 -> /dev/pts/0
lr-x------. 1 haypo haypo 64 13 avril 00:55 3 -> pipe:[697347]
lr-x------. 1 haypo haypo 64 13 avril 00:55 4 -> pipe:[697348]
lr-x------. 1 haypo haypo 64 13 avril 00:55 5 -> pipe:[697349]
lr-x------. 1 haypo haypo 64 13 avril 00:55 6 -> pipe:[697350]
lr-x------. 1 haypo haypo 64 13 avril 00:55 7 -> pipe:[697351]
lr-x------. 1 haypo haypo 64 13 avril 00:55 8 -> pipe:[697352]
lr-x------. 1 haypo haypo 64 13 avril 00:55 9 -> pipe:[697353]

File descriptors of the first child process:

haypo at selma$ ls -l /proc/31565/fd/
lrwx------. 1 haypo haypo 64 13 avril 00:54 0 -> /dev/pts/0
lrwx------. 1 haypo haypo 64 13 avril 00:54 1 -> /dev/pts/0
lrwx------. 1 haypo haypo 64 13 avril 00:54 2 -> /dev/pts/0
lr-x------. 1 haypo haypo 64 13 avril 00:54 3 -> /dev/null
l-wx------. 1 haypo haypo 64 13 avril 00:54 4 -> pipe:[697347]

File descriptors of the second child process:

haypo at selma$ ls -l /proc/31566/fd/
lrwx------. 1 haypo haypo 64 13 avril 00:54 0 -> /dev/pts/0
lrwx------. 1 haypo haypo 64 13 avril 00:54 1 -> /dev/pts/0
lrwx------. 1 haypo haypo 64 13 avril 00:54 2 -> /dev/pts/0
lr-x------. 1 haypo haypo 64 13 avril 00:54 3 -> pipe:[697347]
lr-x------. 1 haypo haypo 64 13 avril 00:54 4 -> /dev/null
l-wx------. 1 haypo haypo 64 13 avril 00:54 5 -> pipe:[697348]

(...)

File descriptors of the last child process:

haypo at selma$ ls -l /proc/31574/fd/
lrwx------. 1 haypo haypo 64 13 avril 00:57 0 -> /dev/pts/0
lrwx------. 1 haypo haypo 64 13 avril 00:57 1 -> /dev/pts/0
lr-x------. 1 haypo haypo 64 13 avril 00:57 10 -> pipe:[697354]
lr-x------. 1 haypo haypo 64 13 avril 00:57 11 -> pipe:[697355]
lr-x------. 1 haypo haypo 64 13 avril 00:57 12 -> /dev/null
l-wx------. 1 haypo haypo 64 13 avril 00:57 13 -> pipe:[697356]
lrwx------. 1 haypo haypo 64 13 avril 00:54 2 -> /dev/pts/0
lr-x------. 1 haypo haypo 64 13 avril 00:57 3 -> pipe:[697347]
lr-x------. 1 haypo haypo 64 13 avril 00:57 4 -> pipe:[697348]
lr-x------. 1 haypo haypo 64 13 avril 00:57 5 -> pipe:[697349]
lr-x------. 1 haypo haypo 64 13 avril 00:57 6 -> pipe:[697350]
lr-x------. 1 haypo haypo 64 13 avril 00:57 7 -> pipe:[697351]
lr-x------. 1 haypo haypo 64 13 avril 00:57 8 -> pipe:[697352]
lr-x------. 1 haypo haypo 64 13 avril 00:57 9 -> pipe:[697353]

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26732>
_______________________________________

From report at bugs.python.org  Tue Apr 12 19:02:28 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2016 23:02:28 +0000
Subject: [issue26731] subprocess on windows leaks stdout/stderr handle to
 child process when stdout/stderr overridden
In-Reply-To: <1460319713.01.0.037399080694.issue26731@psf.upfronthosting.co.za>
Message-ID: <1460502148.46.0.0651657382303.issue26731@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The PEP 446 fixes the issue on UNIX for file descriptors, but you are right, there is still an issue with inheritable Windows handles. By default, Windows handles are not inheritable, but subprocess requires to make stdout and stderr pipes inheritable.

See:
https://www.python.org/dev/peps/pep-0446/#only-inherit-some-handles-on-windows

See also the issue #19764: "subprocess: use PROC_THREAD_ATTRIBUTE_HANDLE_LIST with STARTUPINFOEX on Windows Vista".

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26731>
_______________________________________

From report at bugs.python.org  Tue Apr 12 19:02:40 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2016 23:02:40 +0000
Subject: [issue19764] subprocess: use PROC_THREAD_ATTRIBUTE_HANDLE_LIST with
 STARTUPINFOEX on Windows Vista
In-Reply-To: <1385370115.99.0.757096187315.issue19764@psf.upfronthosting.co.za>
Message-ID: <1460502160.67.0.276762592043.issue19764@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
type: enhancement -> resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19764>
_______________________________________

From report at bugs.python.org  Tue Apr 12 19:02:50 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2016 23:02:50 +0000
Subject: [issue26731] subprocess on windows leaks stdout/stderr handle to
 child process when stdout/stderr overridden
In-Reply-To: <1460319713.01.0.037399080694.issue26731@psf.upfronthosting.co.za>
Message-ID: <1460502170.02.0.394566368638.issue26731@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
type:  -> resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26731>
_______________________________________

From report at bugs.python.org  Tue Apr 12 19:08:02 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Apr 2016 23:08:02 +0000
Subject: [issue26491] Defer DECREFs until enum object is in a consistent state
 for re-entrancy
In-Reply-To: <1457264726.34.0.955181545994.issue26491@psf.upfronthosting.co.za>
Message-ID: <1460502482.7.0.51047168953.issue26491@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Raymond: Do you have an example to trigger the issue?

----------
nosy: +haypo
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26491>
_______________________________________

From report at bugs.python.org  Tue Apr 12 19:54:22 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 12 Apr 2016 23:54:22 +0000
Subject: [issue26741] subprocess.Popen should emit a ResourceWarning in
 destructor if the process is still running
In-Reply-To: <1460501347.41.0.70782898945.issue26741@psf.upfronthosting.co.za>
Message-ID: <1460505262.63.0.159010637986.issue26741@psf.upfronthosting.co.za>


Martin Panter added the comment:

Did you forget to send the patch?

One potential problem is how to provide for people who really want to let the child continue to run in the background or as a daemon without waiting for it, even if the parent exits. Perhaps a special method proc.detach() or whatever?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26741>
_______________________________________

From report at bugs.python.org  Tue Apr 12 19:57:02 2016
From: report at bugs.python.org (Jeremy Kloth)
Date: Tue, 12 Apr 2016 23:57:02 +0000
Subject: [issue26624] Windows hangs in call to CRT setlocale()
In-Reply-To: <1458747871.12.0.710719467032.issue26624@psf.upfronthosting.co.za>
Message-ID: <1460505422.01.0.892654976304.issue26624@psf.upfronthosting.co.za>


Jeremy Kloth added the comment:

It seems that the updated UCRT debug runtime has indeed solved the issue.

I suggest that this issue remains open pending an update to the devguide for required settings for installing VS2015 with the updated runtime (see msg262672).  I have no idea if the VC Build Tools 2015 installs the needed files, so that would need to be checked on a clean machine (all of mine have VS2015 installed).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26624>
_______________________________________

From report at bugs.python.org  Tue Apr 12 20:20:37 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Apr 2016 00:20:37 +0000
Subject: [issue26741] subprocess.Popen should emit a ResourceWarning in
 destructor if the process is still running
In-Reply-To: <1460501347.41.0.70782898945.issue26741@psf.upfronthosting.co.za>
Message-ID: <1460506837.23.0.803186471427.issue26741@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Did you forget to send the patch?

Right :-)

----------
keywords: +patch
Added file: http://bugs.python.org/file42448/subprocess_res_warn.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26741>
_______________________________________

From report at bugs.python.org  Tue Apr 12 20:29:44 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Apr 2016 00:29:44 +0000
Subject: [issue26741] subprocess.Popen should emit a ResourceWarning in
 destructor if the process is still running
In-Reply-To: <1460501347.41.0.70782898945.issue26741@psf.upfronthosting.co.za>
Message-ID: <1460507384.81.0.344155913686.issue26741@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> One potential problem is how to provide for people who really want to let the child continue to run in the background or as a daemon without waiting for it, even if the parent exits. Perhaps a special method proc.detach() or whatever?

Maybe my heuristic to decide if ResourceWarning must be emitted is wrong.

If stdout and/or stderr is redirected to a pipe and the process is still alive when the destructor is called, it sounds more likely like a bug, because it's better to explicitly close these pipes.

If no stream is redirected, yeah, it's ok to pass the pid to a different function which will handle the child process. The risk here is not never called waitpid() to read the child exit status and so create zombi processes.

For daemons, I disagree: the daemon must use double fork, so the parent will quickly see its direct child process to exit. Ignoring the status of the first child status is a bug (we must call waitpid().

I have to think about the detach() idea and check if some applications use it, or even some parts of the stdlib.

Note: The ResourceWarning idea comes from asyncio.subprocess transport which also raises a ResourceWarning. I also had the idea when I read the issue #25942 and the old issue #12494.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26741>
_______________________________________

From report at bugs.python.org  Tue Apr 12 20:34:20 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Apr 2016 00:34:20 +0000
Subject: [issue26491] Defer DECREFs until enum object is in a consistent state
 for re-entrancy
In-Reply-To: <1457264726.34.0.955181545994.issue26491@psf.upfronthosting.co.za>
Message-ID: <1460507660.88.0.656783297489.issue26491@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> status: pending -> open

Oh, this change was not intended. I don't know how it occurred.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26491>
_______________________________________

From report at bugs.python.org  Tue Apr 12 20:36:05 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Apr 2016 00:36:05 +0000
Subject: [issue26624] Windows hangs in call to CRT setlocale()
In-Reply-To: <1460505422.01.0.892654976304.issue26624@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYFD27792_pCxqo3+j-DGqH2foYmyxt6rrAoTnxoYB7kg@mail.gmail.com>


STINNER Victor added the comment:

Is it possible to log a compilation warning in Python if VS version
contains the bug? Or even make the compilation fails?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26624>
_______________________________________

From report at bugs.python.org  Tue Apr 12 20:51:35 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Apr 2016 00:51:35 +0000
Subject: [issue26742] imports in test_warnings changes warnings.filters
Message-ID: <1460508695.22.0.184623410488.issue26742@psf.upfronthosting.co.za>


New submission from STINNER Victor:

---
$ ./python -Wd -m test -j0 test_warnings
Run tests in parallel using 6 child processes
0:00:01 [1/1] test_warnings
(...)
Warning -- warnings.filters was modified by test_warnings
1 test altered the execution environment:
    test_warnings
Total duration: 0:00:02
---

The problem are these two lines in test_warnings/__init__.py:
---
py_warnings = support.import_fresh_module('warnings', blocked=['_warnings'])
c_warnings = support.import_fresh_module('warnings', fresh=['_warnings'])
---

Each fresh "import warnings" calls _processoptions(sys.warnoptions) which can change warning filters.

Attached patch saves/restores warnings.filter to fix the resource warning from the test suite.

Note: the warning is not emited if tests are run sequentially (without the -jN option).

----------
files: test_warnings.patch
keywords: patch
messages: 263291
nosy: haypo
priority: normal
severity: normal
status: open
title: imports in test_warnings changes warnings.filters
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42449/test_warnings.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26742>
_______________________________________

From report at bugs.python.org  Tue Apr 12 20:56:46 2016
From: report at bugs.python.org (Raghu)
Date: Wed, 13 Apr 2016 00:56:46 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
Message-ID: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>


New submission from Raghu:

Hi, I am trying to import random on a power pc based machine and I see this exception. Could you please help me?

root at host# python
Python 2.7.3 (default, Apr  3 2016, 22:31:30)
[GCC 4.8.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import random
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/random.py", line 58, in <module>
    NV_MAGICCONST = 4 * _exp(-0.5)/_sqrt(2.0)
ValueError: math domain error
>>>

----------
components: Library (Lib)
messages: 263292
nosy: ragreddy
priority: normal
severity: normal
status: open
title: Unable to import random with python2.7 on power pc based machine
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Tue Apr 12 21:38:31 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 13 Apr 2016 01:38:31 +0000
Subject: [issue26624] Windows hangs in call to CRT setlocale()
In-Reply-To: <1458747871.12.0.710719467032.issue26624@psf.upfronthosting.co.za>
Message-ID: <1460511511.73.0.0472916713849.issue26624@psf.upfronthosting.co.za>


Steve Dower added the comment:

That's a good idea. I don't know that it's trivial to do, but at build is going to be the easiest time. I'll take a look.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26624>
_______________________________________

From report at bugs.python.org  Tue Apr 12 21:51:37 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 13 Apr 2016 01:51:37 +0000
Subject: [issue26742] imports in test_warnings changes warnings.filters
In-Reply-To: <1460508695.22.0.184623410488.issue26742@psf.upfronthosting.co.za>
Message-ID: <1460512297.9.0.784399347497.issue26742@psf.upfronthosting.co.za>


Martin Panter added the comment:

Hmm your patch is a variation of the first patch in Issue 18383, and Serhiy?s comment about not fixing the underlying problem would apply: <https://bugs.python.org/issue18383#msg232451>.

I can?t remember all the details now, but it sounds like Alex?s later patch may be a slightly more desirable hack :)

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26742>
_______________________________________

From report at bugs.python.org  Tue Apr 12 21:57:50 2016
From: report at bugs.python.org (Ma Lin)
Date: Wed, 13 Apr 2016 01:57:50 +0000
Subject: [issue26744] print() function hangs on MS-Windows 10
Message-ID: <1460512669.99.0.0354506250162.issue26744@psf.upfronthosting.co.za>


New submission from Ma Lin:

My OS is MS-Windows 10 X86-64 (Home edition), with the lastest update (now it's 10586.164).

I have two programs, they occasionally infinite hang.
After a few months observation, I provide these infomation:

1, print() function cause the infinite hang.
2, If it hangs, simply press ENTER key, it goes on without any problem.
3, Both pure-console program and console in Tkinter program have this issue.
4, I tried offical Python 3.4.4 64bit and 3.5.1 64bit, they all have this issue. I didn't try other versions because my programs need Python 3.4+.
5, IIRC, the problem was since Windows 10 Threshold 2 (12/Nov/2015), but I'm not very sure about this.

----------
components: Windows
messages: 263295
nosy: Ma Lin, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: print() function hangs on MS-Windows 10
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26744>
_______________________________________

From report at bugs.python.org  Tue Apr 12 22:32:56 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 13 Apr 2016 02:32:56 +0000
Subject: [issue14784] Re-importing _warnings changes warnings.filters
In-Reply-To: <1336765216.03.0.0611996113989.issue14784@psf.upfronthosting.co.za>
Message-ID: <1460514776.2.0.739392506578.issue14784@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> test_warnings modifies warnings.filters when running with "-W default"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14784>
_______________________________________

From report at bugs.python.org  Tue Apr 12 22:36:09 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 13 Apr 2016 02:36:09 +0000
Subject: [issue26741] subprocess.Popen should emit a ResourceWarning in
 destructor if the process is still running
In-Reply-To: <1460501347.41.0.70782898945.issue26741@psf.upfronthosting.co.za>
Message-ID: <1460514969.8.0.805079080775.issue26741@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think the basic idea of adding the warning is good.

I think this might be a bit like open(closefd=True) and socket.detach(). Normally, it is a bug not to close a file or socket, but the API is flexible and has a way to bypass this.

Perhaps the term ?daemon? means something very specific that is not relevant. But as another example, how would you implement the ?bg? and ?fg? commands of a Unix shell with subprocess.Popen? The Python parent may need to exit cleanly if the child is still running in the background.

I am not really familiar with it, but perhaps the webbrowser.BackgroundBrowser may be a use case for detach().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26741>
_______________________________________

From report at bugs.python.org  Tue Apr 12 22:37:14 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 13 Apr 2016 02:37:14 +0000
Subject: [issue26745] Redundant code in _PyObject_GenericSetAttrWithDict
Message-ID: <1460515034.42.0.500786155919.issue26745@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

It seems some code in _PyObject_GenericSetAttrWithDict is not necessary. There is no need to check data descriptor again using PyDescr_IsData. And the second if (f != NULL) {} will never function.

----------
components: Interpreter Core
files: _PyObject_GenericSetAttrWithDict.patch
keywords: patch
messages: 263297
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title: Redundant code in _PyObject_GenericSetAttrWithDict
versions: Python 3.6
Added file: http://bugs.python.org/file42450/_PyObject_GenericSetAttrWithDict.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26745>
_______________________________________

From report at bugs.python.org  Tue Apr 12 22:41:30 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Apr 2016 02:41:30 +0000
Subject: [issue26404] socketserver context manager
In-Reply-To: <1456088110.26.0.0505883466277.issue26404@psf.upfronthosting.co.za>
Message-ID: <20160413024127.109933.6834.9B29AF89@psf.io>


Roundup Robot added the comment:

New changeset 5c4303c46a18 by Martin Panter in branch 'default':
Issue #26404: Add context manager to socketserver, by Aviv Palivoda
https://hg.python.org/cpython/rev/5c4303c46a18

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26404>
_______________________________________

From report at bugs.python.org  Tue Apr 12 23:12:48 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Apr 2016 03:12:48 +0000
Subject: [issue26624] Windows hangs in call to CRT setlocale()
In-Reply-To: <1458747871.12.0.710719467032.issue26624@psf.upfronthosting.co.za>
Message-ID: <20160413031245.41597.8429.CEE43C75@psf.io>


Roundup Robot added the comment:

New changeset 605fde022b15 by Steve Dower in branch '3.5':
Closes #26624: Adds validation of ucrtbase[d].dll version with warning for old versions.
https://hg.python.org/cpython/rev/605fde022b15

New changeset 6ff020df61b8 by Steve Dower in branch 'default':
Closes #26624: Adds validation of ucrtbase[d].dll version with warning for old versions.
https://hg.python.org/cpython/rev/6ff020df61b8

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26624>
_______________________________________

From report at bugs.python.org  Tue Apr 12 23:15:34 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Apr 2016 03:15:34 +0000
Subject: [issue26624] Windows hangs in call to CRT setlocale()
In-Reply-To: <1458747871.12.0.710719467032.issue26624@psf.upfronthosting.co.za>
Message-ID: <20160413031530.109907.28346.F69786ED@psf.io>


Roundup Robot added the comment:

New changeset a352f7e96f85 by Steve Dower in branch 'default':
Issue #26624: Adds recommendation to install updates of VS 2015.
https://hg.python.org/devguide/rev/a352f7e96f85

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26624>
_______________________________________

From report at bugs.python.org  Tue Apr 12 23:18:33 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 13 Apr 2016 03:18:33 +0000
Subject: [issue26491] Defer DECREFs until enum object is in a consistent state
 for re-entrancy
In-Reply-To: <1457264726.34.0.955181545994.issue26491@psf.upfronthosting.co.za>
Message-ID: <1460517513.93.0.268644379252.issue26491@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Deferring decrefs as late as possible is a good practice, reducing the risk of bugs being introduced later.  There have been other places where there were bugs that arose due to premature decreffing.

I wrote the original code for enumerate, am the primary maintainer, and can make improvements to code organization as needed.  Unless you think this change is broken, it should stay in.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26491>
_______________________________________

From report at bugs.python.org  Tue Apr 12 23:26:41 2016
From: report at bugs.python.org (Mike Pomraning)
Date: Wed, 13 Apr 2016 03:26:41 +0000
Subject: [issue25942] subprocess.call SIGKILLs too liberally
In-Reply-To: <1451006108.23.0.113868196098.issue25942@psf.upfronthosting.co.za>
Message-ID: <1460518001.88.0.119635374302.issue25942@psf.upfronthosting.co.za>


Mike Pomraning added the comment:

Yes, standard UNIX terminal behavior is to map Ctrl-C to a SIGINT sent to the foreground process group, so that every member of a pipeline (e.g.) or hidden helper children processes can be terminated by the interactive user and have the chance to clean up.

Handling a child process behind a convenience interface, like system() or subprocess.call(), is inherently a bit tricky when things go wrong.

My expectation for .call() would be that it behave something like os.system() (or the C library system() for that matter) and _not_ be interrupted by conventional signals.  That the EINTR be "swallowed" and the p.wait() resumed, as _try_wait() does already.  That way a user timeout= does what we want, but a Ctrl-C has familiar semantics.

Yes, it will be possible for a coder to contrive to throw some other exception during the wait() ... in that case we should close the pipes but _not_ kill and reap the child.  There will be zombies.  Zombies are better than SIGKILLing a 3rd-party process that perhaps needs a graceful shutdown.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25942>
_______________________________________

From report at bugs.python.org  Wed Apr 13 00:00:06 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 13 Apr 2016 04:00:06 +0000
Subject: [issue26404] socketserver context manager
In-Reply-To: <1456088110.26.0.0505883466277.issue26404@psf.upfronthosting.co.za>
Message-ID: <1460520006.27.0.340295888574.issue26404@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the patch Aviv. I made a few minor English grammar etc tweaks in the version I committed, as pointed out in the review comments.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26404>
_______________________________________

From report at bugs.python.org  Wed Apr 13 00:24:46 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 13 Apr 2016 04:24:46 +0000
Subject: [issue26720] memoryview from BufferedWriter becomes garbage
In-Reply-To: <1460203726.07.0.470306343445.issue26720@psf.upfronthosting.co.za>
Message-ID: <1460521486.18.0.156961089348.issue26720@psf.upfronthosting.co.za>


Martin Panter added the comment:

The trouble with my original idea is that it is complex to implement, and inconsistent. If you wrote small amounts to your BufferedWriter, you would get a memoryview of bytes that you save for later. If there was a write of a large bytes object, we could pass a memoryview of that bytes object (or the actual bytes object). But if there was a write of a large bytearray, we could end up locking that bytearray, preventing it from being resized, and there could be problems mutating the bytearray.

Because I can?t see how to eliminate all inconsistencies, I prefer to document against saving the memoryview for later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26720>
_______________________________________

From report at bugs.python.org  Wed Apr 13 00:32:33 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Apr 2016 04:32:33 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <20160413043229.41613.12349.79431341@psf.io>


Roundup Robot added the comment:

New changeset 4b65bee79dab by Georg Brandl in branch '2.7':
Update susp-ignore file (#25910).
https://hg.python.org/cpython/rev/4b65bee79dab

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25910>
_______________________________________

From report at bugs.python.org  Wed Apr 13 00:32:33 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Apr 2016 04:32:33 +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: <20160413043229.41613.99767.968E4554@psf.io>


Roundup Robot added the comment:

New changeset b1f3fe320adf by Martin Panter in branch '3.5':
Issue #25496: Document compresslevel defaults to 9, by Hamza T Khan
https://hg.python.org/cpython/rev/b1f3fe320adf

New changeset a04455866ec7 by Martin Panter in branch 'default':
Issue #25496: Merge tarfile doc from 3.5
https://hg.python.org/cpython/rev/a04455866ec7

New changeset 4b9d70d3ba1b by Martin Panter in branch '2.7':
Issue #25496: Document compresslevel defaults to 9, by Hamza T Khan
https://hg.python.org/cpython/rev/4b9d70d3ba1b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25496>
_______________________________________

From report at bugs.python.org  Wed Apr 13 01:08:09 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Apr 2016 05:08:09 +0000
Subject: [issue26491] Defer DECREFs until enum object is in a consistent state
 for re-entrancy
In-Reply-To: <1457264726.34.0.955181545994.issue26491@psf.upfronthosting.co.za>
Message-ID: <1460524089.27.0.0910656612074.issue26491@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This change is not broken. It is just redundant.

If you are still inclined to apply this changes, I would suggest to factor out common code in enum_next_long and enum_next.

> Oh, this change was not intended. I don't know how it occurred.

Any reply changes the status from pending to open.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26491>
_______________________________________

From report at bugs.python.org  Wed Apr 13 01:15:41 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Apr 2016 05:15:41 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460524541.62.0.580102127903.issue26743@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +mark.dickinson, rhettinger, serhiy.storchaka
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Wed Apr 13 01:18:22 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 13 Apr 2016 05:18:22 +0000
Subject: [issue26745] Redundant code in _PyObject_GenericSetAttrWithDict
In-Reply-To: <1460515034.42.0.500786155919.issue26745@psf.upfronthosting.co.za>
Message-ID: <1460524702.59.0.497870469074.issue26745@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
nosy: +benjamin.peterson, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26745>
_______________________________________

From report at bugs.python.org  Wed Apr 13 01:21:50 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Apr 2016 05:21:50 +0000
Subject: [issue26745] Redundant code in _PyObject_GenericSetAttrWithDict
In-Reply-To: <1460515034.42.0.500786155919.issue26745@psf.upfronthosting.co.za>
Message-ID: <1460524910.16.0.198850460003.issue26745@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/issue26745>
_______________________________________

From report at bugs.python.org  Wed Apr 13 01:51:07 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 13 Apr 2016 05:51:07 +0000
Subject: [issue25942] subprocess.call SIGKILLs too liberally
In-Reply-To: <1451006108.23.0.113868196098.issue25942@psf.upfronthosting.co.za>
Message-ID: <1460526667.21.0.129579155742.issue25942@psf.upfronthosting.co.za>


Martin Panter added the comment:

When no timeout is specified, these are the options as I see them:

1. SIGKILL child immediately on the first KeyboardInterrupt (Victor?s behaviour since 3.3)

2. Give up and leave a zombie after the first KeyboardInterrupt (pre-3.3 behaviour)

3. Wait again after first KeyboardInterrupt, and leave a zombie after the second one (Mike?s patch)

4. Ignore SIGINT so that by default no KeyboardInterrupt will happen, like C?s system()

5. Start a timeout after the first KeyboardInterrupt (Victor?s suggestion)

Here is my proposal, taking into account Victor?s desire to never leave a zombie, and Mike?s desire to let the child handle SIGINT in its own time: After the first KeyboardInterrupt or other exception, wait() a second time, and only use SIGKILL if the second wait() is interrupted. It?s a bit complicated, but I think this would solve everyone?s concerns raised so far:

def call(*popenargs, timeout=None, **kwargs):
    p = Popen(*popenargs, **kwargs)
    try:
        if timeout is None:
            try:
                return p.wait()
            except:
                p.wait()  # Let the child handle SIGINT
                raise
        else:
            return p.wait(timeout=timeout)
    except:
        p.kill()  # Last resort to avoid leaving a zombie
        p.wait()
        raise

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25942>
_______________________________________

From report at bugs.python.org  Wed Apr 13 01:54:13 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 13 Apr 2016 05:54:13 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460526853.89.0.651621761518.issue26743@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

That's odd.

Try:
   import math
   print math.sqrt(2.0)
   print math

Post what you see.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Wed Apr 13 02:05:50 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 13 Apr 2016 06:05:50 +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: <1460527549.99.0.430990315027.issue25496@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the patch Hamza

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25496>
_______________________________________

From report at bugs.python.org  Wed Apr 13 02:17:23 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 13 Apr 2016 06:17:23 +0000
Subject: [issue26699] locale.str docstring is incorrect: "Convert float to
 integer"
In-Reply-To: <1459927789.02.0.138982751213.issue26699@psf.upfronthosting.co.za>
Message-ID: <1460528243.2.0.715818176905.issue26699@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks. Fixed in

https://hg.python.org/cpython/rev/2b35ef6a9853
https://hg.python.org/cpython/rev/ad5b079565ad
https://hg.python.org/cpython/rev/125d27d9cf9b

----------
nosy: +orsenthil
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26699>
_______________________________________

From report at bugs.python.org  Wed Apr 13 03:35:51 2016
From: report at bugs.python.org (leycec)
Date: Wed, 13 Apr 2016 07:35:51 +0000
Subject: [issue1322] Deprecate platform.dist() and
 platform.linux_distribution() functions
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1460532951.71.0.823907126239.issue1322@psf.upfronthosting.co.za>


leycec added the comment:

Deprecating platform.linux_distribution() while retaining platform.win32_ver() and platform.mac_ver() is non-orthogonal, unjustifiable, and (arguably) discriminatory.

Platform version detection is no more a moving target under Linux than under Windows or OS X -- possibly less so, given the numerous significant revisions to platform.win32_ver() implementations over the dreary years. If Linux is arbitrarily unentitled to platform-specific lookup functions, then other platforms deserve the same.

Unlike both Windows and OS X, the overwhelming majority of Linux distributions provide a trivially parsable plaintext file publishing high-level platform metadata in "="-delimited shell variable assignment format: the systemd-mandated and freedesktop.org-maintained "/etc/os-release" file. Under edge-case Linux distributions ideologically rejecting this standard (e.g., Gentoo Linux), a subset of the named tuple returned by platform.uname() is trivially returnable.

Do not parse multiple possibly conflicting files, commands, or standards. Doing so is neither necessary nor desirable. If "/etc/os-release" exists, parse that; else, fallback to platform.uname(). Done. Fait accompli. Quite simple. No moving target exists.

A robust platform.linux_distribution() implementation adhering to this scheme is implementable in less than 50 lines of code -- possibly less than 20, assuming aggressive cleverness. How? If "/etc/os-release" exists, this file is guaranteed to be POSIX shell-compatible and hence Pythonically parsable via the stdlib shlex.shlex() function. (In brief: iteratively search for tokens containing "=", split these tokens on "=", ignore irrelevant variable names, and retain the remainder. That's it.) The fallback alternative is even briefer.

Removing core functionality invites third-party API explosion. This is the height of irresponsibility. Brace for heavyweight dependencies, end-user confusion, multiple competing non-standards, and poorly selected PyPi names conflicting with the long-standing GNU toolchain. (See nir0s' "ld", also referred to as "What was nir0s thinking?")

None of these are good things. Given the unremarkable simplicity of implementing this function correctly, this cul-de-sac of Cthulhian insanity needn't have happened in the first place.

It did. Now we languish.

----------
nosy: +leycec

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Wed Apr 13 03:51:07 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 13 Apr 2016 07:51:07 +0000
Subject: [issue1322] Deprecate platform.dist() and
 platform.linux_distribution() functions
In-Reply-To: <1460532951.71.0.823907126239.issue1322@psf.upfronthosting.co.za>
Message-ID: <570DFA65.6090606@egenix.com>


Marc-Andre Lemburg added the comment:

The idea is to have similar functionality implemented as a PyPI
package, which can be updated more often than the stdlib.

Unlike Windows and Mac OS X, the approach to finding out
the distribution version is changing too often on Linux (w/r to how
Python release cycles work). The problem is not complexity, it's
maintainability.

If you're confident that you can write the one and only implementation,
feel free to do so. Put it on PyPI and we can point people to it
once it has picked up a reasonable following we can point to it
in the documentation.

PS: I agree that the package name "ld" is not very intuitive. Perhaps
Nir could change it to something more easily recognizable, such as
"linux_distribution" :-)

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Wed Apr 13 04:38:49 2016
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 13 Apr 2016 08:38:49 +0000
Subject: [issue26746] struct.pack(): trailing padding bytes on x64
Message-ID: <1460536729.2.0.723853097724.issue26746@psf.upfronthosting.co.za>


New submission from Stefan Krah:

On the x64 architecture gcc adds trailing padding bytes after the last
struct member.  NumPy does the same:

>>> import numpy as np
>>> 
>>> t = np.dtype([('x', 'u1'), ('y', 'u8'), ('z', 'u1')], align=True)
>>> x = np.array([(1, 2, 3)], dtype=t)
>>> x.tostring()
b'\x01\xf7\xba\xab\x03\x7f\x00\x00\x02\x00\x00\x00\x00\x00\x00\x00\x03\x00\x00\x00\x00\x00\x00\x00'


The struct module in native mode does not:

>>> struct.pack("BQB", 1, 2, 3)
b'\x01\x00\x00\x00\x00\x00\x00\x00\x02\x00\x00\x00\x00\x00\x00\x00\x03'


I'm not sure if this is intended -- or if full compatibility to
native compilers is even achievable in the general case.

----------
components: Extension Modules
messages: 263315
nosy: mark.dickinson, skrah
priority: normal
severity: normal
status: open
title: struct.pack(): trailing padding bytes on x64
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26746>
_______________________________________

From report at bugs.python.org  Wed Apr 13 05:29:10 2016
From: report at bugs.python.org (Ma Lin)
Date: Wed, 13 Apr 2016 09:29:10 +0000
Subject: [issue26744] print() function hangs on MS-Windows 10
In-Reply-To: <1460512669.99.0.0354506250162.issue26744@psf.upfronthosting.co.za>
Message-ID: <1460539750.48.0.291955976625.issue26744@psf.upfronthosting.co.za>


Ma Lin added the comment:

After my MS-Windows 10 updated to 10586.218 this day, it occurs again.

It hung, the console cursor was flashing at the beginning of the current line.
I pressed ENTER key on the console window, then it printed the supposed content and went on.

I have read issue26624, if you encounter the issue again, try ENTER key, if it works maybe it's the same problem.

----------
components: +Interpreter Core
nosy: +eryksun, haypo, jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26744>
_______________________________________

From report at bugs.python.org  Wed Apr 13 05:32:13 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Apr 2016 09:32:13 +0000
Subject: [issue26744] print() function hangs on MS-Windows 10
In-Reply-To: <1460512669.99.0.0354506250162.issue26744@psf.upfronthosting.co.za>
Message-ID: <1460539933.85.0.222340419812.issue26744@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I have two programs, they occasionally infinite hang.

Can you please try the faulthandler module to try to get a traceback of all Python threads?

I suggest to use the watchdog with a short timeout (ex: 60 seconds):
https://docs.python.org/dev/library/faulthandler.html#faulthandler.dump_traceback_later

> 1, print() function cause the infinite hang.
> 2, If it hangs, simply press ENTER key, it goes on without any problem.

Are you running your program in the Windows console (cmd.exe)? In IDLE? In PowerShell?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26744>
_______________________________________

From report at bugs.python.org  Wed Apr 13 05:48:21 2016
From: report at bugs.python.org (Ma Lin)
Date: Wed, 13 Apr 2016 09:48:21 +0000
Subject: [issue26744] print() function hangs on MS-Windows 10
In-Reply-To: <1460512669.99.0.0354506250162.issue26744@psf.upfronthosting.co.za>
Message-ID: <1460540901.37.0.0564689253522.issue26744@psf.upfronthosting.co.za>


Ma Lin added the comment:

ok, I will try faulthandler module.

>> Are you running your program in the Windows console (cmd.exe)? In IDLE? In PowerShell?

One runs in pure command line mode, cmd.exe.
The other is a simple tkinter GUI with a console for output message.

To be honest, I'm a bit suprise that almost no one complain it, maybe it's my system's fault? I don't know.

Just want to remind you try ENTER key next time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26744>
_______________________________________

From report at bugs.python.org  Wed Apr 13 05:49:20 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Apr 2016 09:49:20 +0000
Subject: [issue26744] print() function hangs on MS-Windows 10
In-Reply-To: <1460512669.99.0.0354506250162.issue26744@psf.upfronthosting.co.za>
Message-ID: <1460540960.06.0.279238760187.issue26744@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> To be honest, I'm a bit suprise that almost no one complain it, maybe it's my system's fault? I don't know.

It looks like a bug in your application. Can you provide a short script to reproduce the bug?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26744>
_______________________________________

From report at bugs.python.org  Wed Apr 13 06:12:52 2016
From: report at bugs.python.org (Ma Lin)
Date: Wed, 13 Apr 2016 10:12:52 +0000
Subject: [issue26744] print() function hangs on MS-Windows 10
In-Reply-To: <1460512669.99.0.0354506250162.issue26744@psf.upfronthosting.co.za>
Message-ID: <1460542372.88.0.776040059513.issue26744@psf.upfronthosting.co.za>


Ma Lin added the comment:

>> It looks like a bug in your application. Can you provide a short script to reproduce the bug?

It's hard to believe it, the code has no way to behavior like that.
I think this is not reproducible, it's random hang.

As my subjective feelings, I suspect it's a Windows bug.

e.g., after an relative long time nooperation, I suddenly press a button in tkinter GUI, it simply delete a file like this:

        try:
            output = self.output.get().strip()
            os.remove(output)
        except:
            pass
        else:
            print('???????')
			
It usually hangs at the print() line.

Another scene is high IO, I download something at 8 MB/s, then I run my program, it should download a HTML page and then print() some information, some hangs happed in this scene.

In addition, the printed strings are Simplified Chinese, my system's language is it as well. Maybe it's a factor?

I'm inclined to guess is a Windows 10 (or only my system's) bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26744>
_______________________________________

From report at bugs.python.org  Wed Apr 13 06:20:08 2016
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 13 Apr 2016 10:20:08 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1460542808.12.0.590949018582.issue3132@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Here's a grammar that roughly describes the subset that NumPy supports.

As for implementing this in the struct module: There is a new data
description language on the horizon:

  http://datashape.readthedocs.org/en/latest/


It does not have all the low-level capabilities (e.g changing alignment
on the fly), but it is far more readable. Example:

PEP-3118:  "(2,3)10f0fZdT{10B:x:(2,3)d:y:Q:z:}B"
Datashape: "2 * 3 * (10 * float32, 0 * float32, complex128, {x: 10 * uint8, y: 2 * 3 * float64, z: int64}, uint8)"


There are a lot of open questions still. Should "10f" be viewed as an
array[10] of float, i.e. equivalent to (10)f?

In the context of PEP-3118, I think so.

----------
nosy: +skrah
Added file: http://bugs.python.org/file42451/grammar.y

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Wed Apr 13 06:20:21 2016
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 13 Apr 2016 10:20:21 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1460542821.21.0.929106582738.issue3132@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan at bytereef.org>:


----------
versions: +Python 3.6 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Wed Apr 13 06:21:19 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 13 Apr 2016 10:21:19 +0000
Subject: [issue26746] struct.pack(): trailing padding bytes on x64
In-Reply-To: <1460536729.2.0.723853097724.issue26746@psf.upfronthosting.co.za>
Message-ID: <1460542879.64.0.422969527412.issue26746@psf.upfronthosting.co.za>


Martin Panter added the comment:

This behaviour seems to be documented, although it is not very explicit, and a bit surprising to me. See the third note at the end of <https://docs.python.org/3/library/struct.html#byte-order-size-and-alignment>: ?align the end . . . with a repeat count of zero?, and the example

>>> pack('llh0l', 1, 2, 3)
b'\x00\x00\x00\x01\x00\x00\x00\x02\x00\x03\x00\x00'

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26746>
_______________________________________

From report at bugs.python.org  Wed Apr 13 07:04:36 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Apr 2016 11:04:36 +0000
Subject: [issue26744] print() function hangs on MS-Windows 10
In-Reply-To: <1460512669.99.0.0354506250162.issue26744@psf.upfronthosting.co.za>
Message-ID: <1460545476.71.0.0931022639971.issue26744@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> In addition, the printed strings are Simplified Chinese, my system's language is it as well. Maybe it's a factor?

Ooooooh yes. The Windows Console sucks to display Unicode: see the very old issue #1602 which is not fixed yet and is 9 years old...

Try to replace your chinese message with a simple ASCII text like print("test") to check if it works around your issue.

Maybe IDLE and/or PowerShell have a better Unicode support, I don't know for Chinese.

Sorry, I know better Linux, I know that Linux handles well Unicode in terminals.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26744>
_______________________________________

From report at bugs.python.org  Wed Apr 13 07:17:15 2016
From: report at bugs.python.org (Ma Lin)
Date: Wed, 13 Apr 2016 11:17:15 +0000
Subject: [issue26744] print() function hangs on MS-Windows 10
In-Reply-To: <1460512669.99.0.0354506250162.issue26744@psf.upfronthosting.co.za>
Message-ID: <1460546235.25.0.319780023734.issue26744@psf.upfronthosting.co.za>


Ma Lin added the comment:

I'm afraid not. If run it 1000 times, only about <5 times occurs, the others are quite fine.
I have installed faulthandler, let's wait the hunting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26744>
_______________________________________

From report at bugs.python.org  Wed Apr 13 07:18:43 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 13 Apr 2016 11:18:43 +0000
Subject: [issue15984] Wrong documentation for PyUnicode_FromObject() and
 PyUnicode_FromEncodedObject()
In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za>
Message-ID: <1460546323.09.0.804495807587.issue15984@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a new version where I use the phrase ?true Unicode object?.

----------
Added file: http://bugs.python.org/file42452/from_object_v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15984>
_______________________________________

From report at bugs.python.org  Wed Apr 13 07:33:50 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 13 Apr 2016 11:33:50 +0000
Subject: [issue26057] Avoid nonneeded use of PyUnicode_FromObject()
In-Reply-To: <1452328901.15.0.65828251852.issue26057@psf.upfronthosting.co.za>
Message-ID: <1460547230.14.0.915386902962.issue26057@psf.upfronthosting.co.za>


Martin Panter added the comment:

Apart from one redundancy (see review), this looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26057>
_______________________________________

From report at bugs.python.org  Wed Apr 13 07:35:46 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 13 Apr 2016 11:35:46 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460547346.23.0.384120386927.issue26743@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

The output of `struct.pack('<d', 2.0)` would also be worth knowing about. I'm wondering whether there's some kind of endianness issue going on in the float-to-string conversions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Wed Apr 13 07:37:19 2016
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 13 Apr 2016 11:37:19 +0000
Subject: [issue26746] struct.pack(): trailing padding bytes on x64
In-Reply-To: <1460536729.2.0.723853097724.issue26746@psf.upfronthosting.co.za>
Message-ID: <1460547439.69.0.973638174779.issue26746@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Thank you.  So technically, in the above NumPy example the format
string generated by NumPy would be considered incomplete if we assume
struct syntax:

>>> m = memoryview(x)
>>> m.format
'T{B:x:xxxxxxxL:y:B:z:}'


I find this "0L" thing a very odd notation. Taking care of this
manually requires a) knowledge of what the compiler does and b)
searching for the largest struct member.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26746>
_______________________________________

From report at bugs.python.org  Wed Apr 13 07:57:41 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Apr 2016 11:57:41 +0000
Subject: [issue15984] Wrong documentation for PyUnicode_FromObject() and
 PyUnicode_FromEncodedObject()
In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za>
Message-ID: <1460548661.57.0.185950145619.issue15984@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM. Thank you Martin for this improvement.

----------
assignee: docs at python -> martin.panter
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15984>
_______________________________________

From report at bugs.python.org  Wed Apr 13 08:24:03 2016
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 13 Apr 2016 12:24:03 +0000
Subject: [issue26673] Tkinter error when opening IDLE configuration menu
In-Reply-To: <1459351920.73.0.899924616631.issue26673@psf.upfronthosting.co.za>
Message-ID: <1460550243.54.0.336277364683.issue26673@psf.upfronthosting.co.za>


Petr Viktorin added the comment:

Indeed, the size is 0 there:

{'family': 'DejaVu Sans Mono', 'size': 0, 'slant': 'roman', 'weight': 'normal', 'overstrike': 0, 'underline': 0}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26673>
_______________________________________

From report at bugs.python.org  Wed Apr 13 08:30:01 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Apr 2016 12:30:01 +0000
Subject: [issue26718] super.__init__ leaks memory if called multiple times
In-Reply-To: <1460163723.35.0.208266777223.issue26718@psf.upfronthosting.co.za>
Message-ID: <20160413122931.23035.87754.9C87EF95@psf.io>


Roundup Robot added the comment:

New changeset 450f36750cb9 by Serhiy Storchaka in branch '3.5':
Issue #26718: super.__init__ no longer leaks memory if called multiple times.
https://hg.python.org/cpython/rev/450f36750cb9

New changeset 4680438f486f by Serhiy Storchaka in branch '2.7':
Issue #26718: super.__init__ no longer leaks memory if called multiple times.
https://hg.python.org/cpython/rev/4680438f486f

New changeset 55f4c1f8ca6a by Serhiy Storchaka in branch 'default':
Issue #26718: super.__init__ no longer leaks memory if called multiple times.
https://hg.python.org/cpython/rev/55f4c1f8ca6a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26718>
_______________________________________

From report at bugs.python.org  Wed Apr 13 08:38:38 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Apr 2016 12:38:38 +0000
Subject: [issue26718] super.__init__ leaks memory if called multiple times
In-Reply-To: <1460163723.35.0.208266777223.issue26718@psf.upfronthosting.co.za>
Message-ID: <1460551118.5.0.13706485209.issue26718@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/issue26718>
_______________________________________

From report at bugs.python.org  Wed Apr 13 08:44:38 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Apr 2016 12:44:38 +0000
Subject: [issue26057] Avoid nonneeded use of PyUnicode_FromObject()
In-Reply-To: <1452328901.15.0.65828251852.issue26057@psf.upfronthosting.co.za>
Message-ID: <20160413124435.3948.22484.203678BC@psf.io>


Roundup Robot added the comment:

New changeset 3f3b3d4881f6 by Serhiy Storchaka in branch 'default':
Issue #26057: Got rid of nonneeded use of PyUnicode_FromObject().
https://hg.python.org/cpython/rev/3f3b3d4881f6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26057>
_______________________________________

From report at bugs.python.org  Wed Apr 13 08:45:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Apr 2016 12:45:58 +0000
Subject: [issue26057] Avoid nonneeded use of PyUnicode_FromObject()
In-Reply-To: <1452328901.15.0.65828251852.issue26057@psf.upfronthosting.co.za>
Message-ID: <1460551558.84.0.0144832204893.issue26057@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your review Martin.

----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26057>
_______________________________________

From report at bugs.python.org  Wed Apr 13 09:03:05 2016
From: report at bugs.python.org (Demur Rumed)
Date: Wed, 13 Apr 2016 13:03:05 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1460552585.93.0.128699873513.issue26647@psf.upfronthosting.co.za>


Demur Rumed added the comment:

Made changes from code review, did a little extra on fixing up type consistency, not sure if this is exactly the patch format you wanted; I tried `git difftool --extcmd='diff -u' python/master` but it's listing the original files as being from /tmp

I've updated modulefinder with haypo's index patch except in the context of wordcode

----------
Added file: http://bugs.python.org/file42453/wpy5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Wed Apr 13 09:41:53 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Apr 2016 13:41:53 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1460554913.53.0.00147501390912.issue26647@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Updated wpy5.patch to use a more standard diff format (patch generated with Mercurial, hg diff > patch).

----------
Added file: http://bugs.python.org/file42454/wpy5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Wed Apr 13 10:28:22 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Apr 2016 14:28:22 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1460557702.24.0.625282158863.issue26647@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Removed file: http://bugs.python.org/file42454/wpy5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Wed Apr 13 10:29:09 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Apr 2016 14:29:09 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1460557749.83.0.34379286097.issue26647@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Updated wpy5.patch to use a more standard diff format (patch generated with Mercurial, hg diff > patch).

Crap, I forgot Python/wordcode_helpers.h.

I updated a fixed wpy6.patch.

----------
Added file: http://bugs.python.org/file42455/wpy6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Wed Apr 13 10:50:31 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Apr 2016 14:50:31 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1460559031.26.0.337573620284.issue26647@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Demur Rumed: Is the peephole optimizer able to emit *two* EXTENDED_ARG for jump larger than 16 bits? Currently, it only has to retry once to add EXTENDED_ARG if a jump is larger than 16 bits (to use 32-bit jump offset).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Wed Apr 13 11:29:00 2016
From: report at bugs.python.org (Nan Wu)
Date: Wed, 13 Apr 2016 15:29:00 +0000
Subject: [issue26747] types.InstanceType only for old style class only in 2.7
Message-ID: <1460561340.28.0.563389556375.issue26747@psf.upfronthosting.co.za>


New submission from Nan Wu:

>>> import types
>>> a = 1
>>> isinstance(a, types.InstanceType)
False
>>> class A:
...     pass
... 
>>> a = A()
>>> isinstance(a, types.InstanceType)
True
>>> class A(object):
...     pass
... 
>>> a = A()
>>> isinstance(a, types.InstanceType)
False

Looks like isinstance(instance, types.InstanceType) only return True for user-defined old-style class instance. If it's the case, I feel doc should clarify that like what types.ClassType did. If no, someone please close this request. Thanks.

----------
files: doc_InstanceType_is_for_old_style_cls.patch
keywords: patch
messages: 263338
nosy: Nan Wu
priority: normal
severity: normal
status: open
title: types.InstanceType only for old style class only in 2.7
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file42456/doc_InstanceType_is_for_old_style_cls.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26747>
_______________________________________

From report at bugs.python.org  Wed Apr 13 12:07:41 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 13 Apr 2016 16:07:41 +0000
Subject: [issue26747] types.InstanceType only for old style class only in 2.7
In-Reply-To: <1460561340.28.0.563389556375.issue26747@psf.upfronthosting.co.za>
Message-ID: <1460563661.74.0.773327588016.issue26747@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26747>
_______________________________________

From report at bugs.python.org  Wed Apr 13 12:23:46 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Apr 2016 16:23:46 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1460564626.0.0.816679496508.issue26647@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I ran the Python benchmark suite on wpy6.patch.

* My platform: Linux-4.4.4-301.fc23.x86_64-x86_64-with-fedora-23-Twenty_Three
* My PC: CPU Intel i7-2600 (~2.9 GHz) with 12 GB of RAM
* Benchmark ran on isolated CPU: http://haypo-notes.readthedocs.org/microbenchmark.html
* Command line: ~/bin/taskset_isolated.py time python3 -u perf.py --rigorous "$ORIG_PYTHON" "$PATCHED_PYTHON" -b all 2>&1

It looks like we get more faster benchmarks than slower benchamrks. Faster is up to 11% faster, whereas the worst slowdown is only 4%. The overall results look good to me.

Slower:

* fannkuch: 1.04x slower
* pickle_dict: 1.04x slower
* telco: 1.03x slower
* django_v3: 1.02x slower
* simple_logging: 1.02x slower
* meteor_contest: 1.02x slower

Faster:

* unpack_sequence: 1.11x faster
* etree_parse: 1.06x faster
* call_method_slots: 1.06x faster
* etree_iterparse: 1.05x faster
* call_simple: 1.04x faster
* nbody: 1.04x faster
* float: 1.04x faster
* call_method_unknown: 1.03x faster
* call_method: 1.03x faster
* chaos: 1.03x faster
* mako_v2: 1.03x faster
* richards: 1.02x faster
* silent_logging1: 1.02x faster


Full Output:

Original python: ../wordcode/python
3.6.0a0 (default:ad5b079565ad, Apr 13 2016, 16:30:36) 
[GCC 5.3.1 20151207 (Red Hat 5.3.1-2)]

Patched python: ../wordcode/python
3.6.0a0 (default:c050d203e82b, Apr 13 2016, 16:30:24) 
[GCC 5.3.1 20151207 (Red Hat 5.3.1-2)]

INFO:root:Automatically selected timer: perf_counter
INFO:root:Skipping benchmark slowpickle; not compatible with Python 3.6
INFO:root:Skipping benchmark pybench; not compatible with Python 3.6
INFO:root:Skipping benchmark hg_startup; not compatible with Python 3.6
INFO:root:Skipping benchmark rietveld; not compatible with Python 3.6
INFO:root:Skipping benchmark slowspitfire; not compatible with Python 3.6
INFO:root:Skipping benchmark bzr_startup; not compatible with Python 3.6
INFO:root:Skipping benchmark html5lib_warmup; not compatible with Python 3.6
INFO:root:Skipping benchmark slowunpickle; not compatible with Python 3.6
INFO:root:Skipping benchmark html5lib; not compatible with Python 3.6
INFO:root:Skipping benchmark spambayes; not compatible with Python 3.6
[ 1/43] 2to3...
INFO:root:Running `../wordcode/python lib3/2to3/2to3 -f all lib/2to3`
INFO:root:Running `../wordcode/python lib3/2to3/2to3 -f all lib/2to3` 5 times
INFO:root:Running `../default/python lib3/2to3/2to3 -f all lib/2to3`
INFO:root:Running `../default/python lib3/2to3/2to3 -f all lib/2to3` 5 times
[ 2/43] call_method...
INFO:root:Running `../wordcode/python performance/bm_call_method.py -n 300 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_call_method.py -n 300 --timer perf_counter`
mer. avril 13 16:36:47 CEST 2016
Original python: ../wordcode/python
3.6.0a0 (default:ad5b079565ad, Apr 13 2016, 16:30:36) 
[GCC 5.3.1 20151207 (Red Hat 5.3.1-2)]

Patched python: ../wordcode/python
3.6.0a0 (default:c050d203e82b, Apr 13 2016, 16:30:24) 
[GCC 5.3.1 20151207 (Red Hat 5.3.1-2)]

INFO:root:Automatically selected timer: perf_counter
INFO:root:Skipping benchmark html5lib; not compatible with Python 3.6
INFO:root:Skipping benchmark html5lib_warmup; not compatible with Python 3.6
INFO:root:Skipping benchmark slowpickle; not compatible with Python 3.6
INFO:root:Skipping benchmark slowunpickle; not compatible with Python 3.6
INFO:root:Skipping benchmark slowspitfire; not compatible with Python 3.6
INFO:root:Skipping benchmark rietveld; not compatible with Python 3.6
INFO:root:Skipping benchmark bzr_startup; not compatible with Python 3.6
INFO:root:Skipping benchmark spambayes; not compatible with Python 3.6
INFO:root:Skipping benchmark pybench; not compatible with Python 3.6
INFO:root:Skipping benchmark hg_startup; not compatible with Python 3.6
[ 1/43] 2to3...
INFO:root:Running `../wordcode/python lib3/2to3/2to3 -f all lib/2to3`
INFO:root:Running `../wordcode/python lib3/2to3/2to3 -f all lib/2to3` 5 times
INFO:root:Running `../default/python lib3/2to3/2to3 -f all lib/2to3`
INFO:root:Running `../default/python lib3/2to3/2to3 -f all lib/2to3` 5 times
[ 2/43] call_method...
INFO:root:Running `../wordcode/python performance/bm_call_method.py -n 300 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_call_method.py -n 300 --timer perf_counter`
[ 3/43] call_method_slots...
INFO:root:Running `../wordcode/python performance/bm_call_method_slots.py -n 300 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_call_method_slots.py -n 300 --timer perf_counter`
[ 4/43] call_method_unknown...
INFO:root:Running `../wordcode/python performance/bm_call_method_unknown.py -n 300 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_call_method_unknown.py -n 300 --timer perf_counter`
[ 5/43] call_simple...
INFO:root:Running `../wordcode/python performance/bm_call_simple.py -n 300 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_call_simple.py -n 300 --timer perf_counter`
[ 6/43] chameleon_v2...
INFO:root:Running `../wordcode/python performance/bm_chameleon_v2.py -n 100 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_chameleon_v2.py -n 100 --timer perf_counter`
[ 7/43] chaos...
INFO:root:Running `../wordcode/python performance/bm_chaos.py -n 100 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_chaos.py -n 100 --timer perf_counter`
[ 8/43] django_v3...
INFO:root:Running `../wordcode/python performance/bm_django_v3.py -n 100 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_django_v3.py -n 100 --timer perf_counter`
[ 9/43] etree_generate...
INFO:root:Running `../wordcode/python performance/bm_elementtree.py -n 100 --timer perf_counter generate`
INFO:root:Running `../default/python performance/bm_elementtree.py -n 100 --timer perf_counter generate`
[10/43] etree_iterparse...
INFO:root:Running `../wordcode/python performance/bm_elementtree.py -n 100 --timer perf_counter iterparse`
INFO:root:Running `../default/python performance/bm_elementtree.py -n 100 --timer perf_counter iterparse`
[11/43] etree_parse...
INFO:root:Running `../wordcode/python performance/bm_elementtree.py -n 100 --timer perf_counter parse`
INFO:root:Running `../default/python performance/bm_elementtree.py -n 100 --timer perf_counter parse`
[12/43] etree_process...
INFO:root:Running `../wordcode/python performance/bm_elementtree.py -n 100 --timer perf_counter process`
INFO:root:Running `../default/python performance/bm_elementtree.py -n 100 --timer perf_counter process`
[13/43] fannkuch...
INFO:root:Running `../wordcode/python performance/bm_fannkuch.py -n 100 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_fannkuch.py -n 100 --timer perf_counter`
[14/43] fastpickle...
INFO:root:Running `../wordcode/python performance/bm_pickle.py -n 100 --timer perf_counter --use_cpickle pickle`
INFO:root:Running `../default/python performance/bm_pickle.py -n 100 --timer perf_counter --use_cpickle pickle`
[15/43] fastunpickle...
INFO:root:Running `../wordcode/python performance/bm_pickle.py -n 100 --timer perf_counter --use_cpickle unpickle`
INFO:root:Running `../default/python performance/bm_pickle.py -n 100 --timer perf_counter --use_cpickle unpickle`
[16/43] float...
INFO:root:Running `../wordcode/python performance/bm_float.py -n 100 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_float.py -n 100 --timer perf_counter`
[17/43] formatted_logging...
INFO:root:Running `../wordcode/python performance/bm_logging.py -n 100 --timer perf_counter formatted_output`
INFO:root:Running `../default/python performance/bm_logging.py -n 100 --timer perf_counter formatted_output`
[18/43] go...
INFO:root:Running `../wordcode/python performance/bm_go.py -n 100 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_go.py -n 100 --timer perf_counter`
[19/43] hexiom2...
INFO:root:Running `../wordcode/python performance/bm_hexiom2.py -n 4 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_hexiom2.py -n 4 --timer perf_counter`
[20/43] json_dump_v2...
INFO:root:Running `../wordcode/python performance/bm_json_v2.py -n 100 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_json_v2.py -n 100 --timer perf_counter`
[21/43] json_load...
INFO:root:Running `../wordcode/python performance/bm_json.py -n 100 --timer perf_counter json_load`
INFO:root:Running `../default/python performance/bm_json.py -n 100 --timer perf_counter json_load`
[22/43] mako_v2...
INFO:root:Running `../wordcode/python performance/bm_mako_v2.py -n 1000 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_mako_v2.py -n 1000 --timer perf_counter`
[23/43] meteor_contest...
INFO:root:Running `../wordcode/python performance/bm_meteor_contest.py -n 100 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_meteor_contest.py -n 100 --timer perf_counter`
[24/43] nbody...
INFO:root:Running `../wordcode/python performance/bm_nbody.py -n 100 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_nbody.py -n 100 --timer perf_counter`
[25/43] normal_startup...
INFO:root:Running `../wordcode/python -c ` 2000 times
INFO:root:Running `../default/python -c ` 2000 times
[26/43] nqueens...
INFO:root:Running `../wordcode/python performance/bm_nqueens.py -n 100 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_nqueens.py -n 100 --timer perf_counter`
[27/43] pathlib...
INFO:root:Running `../wordcode/python performance/bm_pathlib.py -n 1000 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_pathlib.py -n 1000 --timer perf_counter`
[28/43] pickle_dict...
INFO:root:Running `../wordcode/python performance/bm_pickle.py -n 100 --timer perf_counter --use_cpickle pickle_dict`
INFO:root:Running `../default/python performance/bm_pickle.py -n 100 --timer perf_counter --use_cpickle pickle_dict`
[29/43] pickle_list...
INFO:root:Running `../wordcode/python performance/bm_pickle.py -n 100 --timer perf_counter --use_cpickle pickle_list`
INFO:root:Running `../default/python performance/bm_pickle.py -n 100 --timer perf_counter --use_cpickle pickle_list`
[30/43] pidigits...
INFO:root:Running `../wordcode/python performance/bm_pidigits.py -n 100 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_pidigits.py -n 100 --timer perf_counter`
[31/43] raytrace...
INFO:root:Running `../wordcode/python performance/bm_raytrace.py -n 100 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_raytrace.py -n 100 --timer perf_counter`
[32/43] regex_compile...
INFO:root:Running `../wordcode/python performance/bm_regex_compile.py -n 100 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_regex_compile.py -n 100 --timer perf_counter`
[33/43] regex_effbot...
INFO:root:Running `../wordcode/python performance/bm_regex_effbot.py -n 100 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_regex_effbot.py -n 100 --timer perf_counter`
[34/43] regex_v8...
INFO:root:Running `../wordcode/python performance/bm_regex_v8.py -n 100 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_regex_v8.py -n 100 --timer perf_counter`
[35/43] richards...
INFO:root:Running `../wordcode/python performance/bm_richards.py -n 100 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_richards.py -n 100 --timer perf_counter`
[36/43] silent_logging...
INFO:root:Running `../wordcode/python performance/bm_logging.py -n 100 --timer perf_counter no_output`
INFO:root:Running `../default/python performance/bm_logging.py -n 100 --timer perf_counter no_output`
[37/43] simple_logging...
INFO:root:Running `../wordcode/python performance/bm_logging.py -n 100 --timer perf_counter simple_output`
INFO:root:Running `../default/python performance/bm_logging.py -n 100 --timer perf_counter simple_output`
[38/43] spectral_norm...
INFO:root:Running `../wordcode/python performance/bm_spectral_norm.py -n 100 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_spectral_norm.py -n 100 --timer perf_counter`
[39/43] startup_nosite...
INFO:root:Running `../wordcode/python -S -c ` 4000 times
INFO:root:Running `../default/python -S -c ` 4000 times
[40/43] telco...
INFO:root:Running `../wordcode/python performance/bm_telco.py -n 100 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_telco.py -n 100 --timer perf_counter`
[41/43] tornado_http...
INFO:root:Running `../wordcode/python performance/bm_tornado_http.py -n 200 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_tornado_http.py -n 200 --timer perf_counter`
[42/43] unpack_sequence...
INFO:root:Running `../wordcode/python performance/bm_unpack_sequence.py -n 100000 --timer perf_counter`
INFO:root:Running `../default/python performance/bm_unpack_sequence.py -n 100000 --timer perf_counter`
[43/43] unpickle_list...
INFO:root:Running `../wordcode/python performance/bm_pickle.py -n 100 --timer perf_counter --use_cpickle unpickle_list`
INFO:root:Running `../default/python performance/bm_pickle.py -n 100 --timer perf_counter --use_cpickle unpickle_list`

Report on Linux smithers 4.4.4-301.fc23.x86_64 #1 SMP Fri Mar 4 17:42:42 UTC 2016 x86_64 x86_64
Total CPU cores: 8

### call_method ###
Min: 0.313558 -> 0.304460: 1.03x faster
Avg: 0.313797 -> 0.304661: 1.03x faster
Significant (t=773.69)
Stddev: 0.00015 -> 0.00014: 1.1084x smaller

### call_method_slots ###
Min: 0.317374 -> 0.300388: 1.06x faster
Avg: 0.317527 -> 0.300701: 1.06x faster
Significant (t=1971.52)
Stddev: 0.00011 -> 0.00010: 1.0595x smaller

### call_method_unknown ###
Min: 0.309548 -> 0.301112: 1.03x faster
Avg: 0.309619 -> 0.301828: 1.03x faster
Significant (t=636.50)
Stddev: 0.00008 -> 0.00020: 2.3452x larger

### call_simple ###
Min: 0.245480 -> 0.235982: 1.04x faster
Avg: 0.246004 -> 0.236310: 1.04x faster
Significant (t=492.66)
Stddev: 0.00023 -> 0.00025: 1.1069x larger

### chaos ###
Min: 0.271012 -> 0.264204: 1.03x faster
Avg: 0.271723 -> 0.264787: 1.03x faster
Significant (t=132.15)
Stddev: 0.00044 -> 0.00028: 1.5564x smaller

### django_v3 ###
Min: 0.544071 -> 0.555346: 1.02x slower
Avg: 0.544697 -> 0.556142: 1.02x slower
Significant (t=-210.46)
Stddev: 0.00036 -> 0.00041: 1.1510x larger

### etree_iterparse ###
Min: 0.215644 -> 0.205198: 1.05x faster
Avg: 0.219440 -> 0.208423: 1.05x faster
Significant (t=53.95)
Stddev: 0.00145 -> 0.00144: 1.0016x smaller

### etree_parse ###
Min: 0.287245 -> 0.271355: 1.06x faster
Avg: 0.288902 -> 0.273051: 1.06x faster
Significant (t=107.60)
Stddev: 0.00106 -> 0.00102: 1.0348x smaller

### fannkuch ###
Min: 0.957137 -> 0.993462: 1.04x slower
Avg: 0.965306 -> 0.995223: 1.03x slower
Significant (t=-42.85)
Stddev: 0.00665 -> 0.00214: 3.1094x smaller

### float ###
Min: 0.258390 -> 0.248217: 1.04x faster
Avg: 0.265902 -> 0.255380: 1.04x faster
Significant (t=17.29)
Stddev: 0.00441 -> 0.00419: 1.0510x smaller

### mako_v2 ###
Min: 0.040757 -> 0.039408: 1.03x faster
Avg: 0.041534 -> 0.040058: 1.04x faster
Significant (t=106.39)
Stddev: 0.00033 -> 0.00029: 1.1548x smaller

### meteor_contest ###
Min: 0.187423 -> 0.192079: 1.02x slower
Avg: 0.188739 -> 0.193440: 1.02x slower
Significant (t=-61.30)
Stddev: 0.00053 -> 0.00056: 1.0503x larger

### nbody ###
Min: 0.227627 -> 0.219617: 1.04x faster
Avg: 0.229736 -> 0.221310: 1.04x faster
Significant (t=23.23)
Stddev: 0.00276 -> 0.00235: 1.1745x smaller

### pickle_dict ###
Min: 0.491946 -> 0.513859: 1.04x slower
Avg: 0.492796 -> 0.515723: 1.05x slower
Significant (t=-158.63)
Stddev: 0.00063 -> 0.00130: 2.0672x larger

### richards ###
Min: 0.159527 -> 0.155970: 1.02x faster
Avg: 0.160603 -> 0.157190: 1.02x faster
Significant (t=36.37)
Stddev: 0.00067 -> 0.00066: 1.0168x smaller

### silent_logging ###
Min: 0.068349 -> 0.067301: 1.02x faster
Avg: 0.069759 -> 0.067481: 1.03x faster
Significant (t=56.73)
Stddev: 0.00038 -> 0.00013: 2.8514x smaller

### simple_logging ###
Min: 0.276149 -> 0.282515: 1.02x slower
Avg: 0.277709 -> 0.283773: 1.02x slower
Significant (t=-53.60)
Stddev: 0.00080 -> 0.00080: 1.0045x smaller

### telco ###
Min: 0.011922 -> 0.012221: 1.03x slower
Avg: 0.011985 -> 0.012283: 1.02x slower
Significant (t=-59.48)
Stddev: 0.00003 -> 0.00004: 1.0912x larger

### unpack_sequence ###
Min: 0.000047 -> 0.000042: 1.11x faster
Avg: 0.000047 -> 0.000042: 1.10x faster
Significant (t=2242.55)
Stddev: 0.00000 -> 0.00000: 1.2134x larger

The following not significant results are hidden, use -v to show them:
2to3, chameleon_v2, etree_generate, etree_process, fastpickle, fastunpickle, formatted_logging, go, hexiom2, json_dump_v2, json_load, normal_startup, nqueens, pathlib, pickle_list, pidigits, raytrace, regex_compile, regex_effbot, regex_v8, spectral_norm, startup_nosite, tornado_http, unpickle_list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Wed Apr 13 12:36:01 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Apr 2016 16:36:01 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1460565361.57.0.511015942146.issue26647@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I opened a thread on the python-dev mailing list to discuss wordcode:
https://mail.python.org/pipermail/python-dev/2016-April/144044.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Wed Apr 13 12:57:35 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 13 Apr 2016 16:57:35 +0000
Subject: [issue26745] Redundant code in _PyObject_GenericSetAttrWithDict
In-Reply-To: <1460515034.42.0.500786155919.issue26745@psf.upfronthosting.co.za>
Message-ID: <1460566655.43.0.548691471829.issue26745@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

LGTM. Had to check the definition of PyDescr_IsData to determine that checking the value from tp_descr_set for NULL was exactly what that macro does, but yeah, it looks like the first test was redundant, and f is never assigned outside that block, so the second block after the rest of the work is pointless; you'd never get there.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26745>
_______________________________________

From report at bugs.python.org  Wed Apr 13 13:22:01 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Apr 2016 17:22:01 +0000
Subject: [issue26748] enum.Enum is False-y
Message-ID: <1460568121.51.0.847598758945.issue26748@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

>>> import enum
>>> bool(enum.Enum)
False
>>> bool(enum.IntEnum)
False

This behaviour is relatively unexpected for classes, and can lead to subtle bugs such as the following:

https://bitbucket.org/ambv/singledispatch/issues/8/inconsistent-hierarchy-with-enum

----------
components: Library (Lib)
messages: 263342
nosy: barry, eli.bendersky, ethan.furman, gvanrossum, pitrou
priority: normal
severity: normal
status: open
title: enum.Enum is False-y
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26748>
_______________________________________

From report at bugs.python.org  Wed Apr 13 13:47:41 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 13 Apr 2016 17:47:41 +0000
Subject: [issue26748] enum.Enum is False-y
In-Reply-To: <1460568121.51.0.847598758945.issue26748@psf.upfronthosting.co.za>
Message-ID: <1460569661.49.0.134961827624.issue26748@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I guess it's marked 2.7 because of the enum34 backport? There's no enum in the 2.7 stdlib.

I believe this was brought up before on one of the lists but I don't recall the outcome of the discussion, except that for IntEnum the behavior is correct.  I tend to agree that for plain Enum it's a problem, the question is whether we can fix it without breaking code that accidentally relies on this behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26748>
_______________________________________

From report at bugs.python.org  Wed Apr 13 13:49:32 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 13 Apr 2016 17:49:32 +0000
Subject: [issue26748] enum.Enum is False-y
In-Reply-To: <1460568121.51.0.847598758945.issue26748@psf.upfronthosting.co.za>
Message-ID: <1460569771.99.0.49771236.issue26748@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Oh wait. The *class* is False-y? That's definitely a bug, just fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26748>
_______________________________________

From report at bugs.python.org  Wed Apr 13 13:50:51 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Apr 2016 17:50:51 +0000
Subject: [issue26748] enum.Enum is False-y
In-Reply-To: <1460568121.51.0.847598758945.issue26748@psf.upfronthosting.co.za>
Message-ID: <1460569851.49.0.260709218353.issue26748@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Yes, I didn't find a separate bug tracker for the enum34 backport, which is why I included that version here.

> for IntEnum the behavior is correct

Do you remember the argument? I agree that IntEnum *instances* may be falsy, but IntEnum classes I don't see why.

That said, if an IntEnum *class* has to be false-y, then there's no real point in fixing just Enum (you can pass an IntEnum instance to singledispatch() too).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26748>
_______________________________________

From report at bugs.python.org  Wed Apr 13 13:51:13 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Apr 2016 17:51:13 +0000
Subject: [issue26748] enum.Enum is False-y
In-Reply-To: <1460568121.51.0.847598758945.issue26748@psf.upfronthosting.co.za>
Message-ID: <1460569873.54.0.198090797895.issue26748@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, we posted at the same time :-) Yes, the class is false-y.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26748>
_______________________________________

From report at bugs.python.org  Wed Apr 13 13:53:55 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Apr 2016 17:53:55 +0000
Subject: [issue26748] enum.Enum is False-y
In-Reply-To: <1460568121.51.0.847598758945.issue26748@psf.upfronthosting.co.za>
Message-ID: <1460570035.67.0.523019957422.issue26748@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Just reading the code now, the reason is that EnumMeta pretends to be a collection (it defines a __len__ and an __iter__).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26748>
_______________________________________

From report at bugs.python.org  Wed Apr 13 14:06:42 2016
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 13 Apr 2016 18:06:42 +0000
Subject: [issue26748] enum.Enum is False-y
In-Reply-To: <1460568121.51.0.847598758945.issue26748@psf.upfronthosting.co.za>
Message-ID: <1460570802.79.0.82136569169.issue26748@psf.upfronthosting.co.za>


Ethan Furman added the comment:

EnumMeta /is/ a collection (at least in the same sense the dict class is a collection).  ;)

Fix is on it's way...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26748>
_______________________________________

From report at bugs.python.org  Wed Apr 13 14:46:40 2016
From: report at bugs.python.org (skydoom)
Date: Wed, 13 Apr 2016 18:46:40 +0000
Subject: [issue26693] Exception ignored in: <module 'threading' from
 ...threading.py> in _shutdown, assert tlock.locked()
In-Reply-To: <1459821105.82.0.884891417565.issue26693@psf.upfronthosting.co.za>
Message-ID: <1460573200.49.0.961730437852.issue26693@psf.upfronthosting.co.za>


skydoom added the comment:

seems we also need to check whether _main_thread is daemon thread or not, so the proposed patch would look like:

def _shutdown():
   # add these checking first
   if( _main_thread.isDaemon() is False or _main_thread.is_alive() is False ):
       return

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26693>
_______________________________________

From report at bugs.python.org  Wed Apr 13 14:49:03 2016
From: report at bugs.python.org (Luiz Poleto)
Date: Wed, 13 Apr 2016 18:49:03 +0000
Subject: [issue26749] Update devguide to include Fedora's DNF
Message-ID: <1460573343.29.0.391562448207.issue26749@psf.upfronthosting.co.za>


New submission from Luiz Poleto:

Starting with Fedora 22, yum is no longer the default packaging tool, being replaced by the new DNF (Dandified Yum).

Section 1.1.3.1 of the devguide, Build dependencies, has instructions to install system headers using popular Linux distributions, including Fedora, however, it only covers using yum to do it.

This section should be updated to include the usage of the new DNF packaging tool to perform that task.

----------
assignee: docs at python
components: Documentation
messages: 263350
nosy: docs at python, poleto
priority: normal
severity: normal
status: open
title: Update devguide to include Fedora's DNF
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26749>
_______________________________________

From report at bugs.python.org  Wed Apr 13 14:51:06 2016
From: report at bugs.python.org (Luiz Poleto)
Date: Wed, 13 Apr 2016 18:51:06 +0000
Subject: [issue26749] Update devguide to include Fedora's DNF
In-Reply-To: <1460573343.29.0.391562448207.issue26749@psf.upfronthosting.co.za>
Message-ID: <1460573466.7.0.705673261872.issue26749@psf.upfronthosting.co.za>


Luiz Poleto added the comment:

The attached patch contains the instructions on how to use DNF to install the system headers.

----------
keywords: +patch
Added file: http://bugs.python.org/file42457/issue26749.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26749>
_______________________________________

From report at bugs.python.org  Wed Apr 13 15:10:51 2016
From: report at bugs.python.org (Gabriel Devenyi)
Date: Wed, 13 Apr 2016 19:10:51 +0000
Subject: [issue16399] argparse: append action with default list adds to list
 instead of overriding
In-Reply-To: <1351992623.71.0.851432414607.issue16399@psf.upfronthosting.co.za>
Message-ID: <1460574651.38.0.566454239485.issue16399@psf.upfronthosting.co.za>


Gabriel Devenyi added the comment:

>From what I can tell a workaround for this still isn't documented.

----------
nosy: +Gabriel Devenyi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16399>
_______________________________________

From report at bugs.python.org  Wed Apr 13 15:23:04 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Apr 2016 19:23:04 +0000
Subject: [issue26359] CPython build options for out-of-the box performance
In-Reply-To: <1455445693.01.0.984013993837.issue26359@psf.upfronthosting.co.za>
Message-ID: <1460575384.32.0.651089289115.issue26359@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Sorry, I don't understand this issue. I don't think that we need 3 flavors: debug, devel and release. We already have debug (--with-pydebug) and release, and IMHO debug is what developers should use.

I like the idea of using the best optimizers options *by default* for the release mode. In practice, I suggest to enable PGO *by default*.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26359>
_______________________________________

From report at bugs.python.org  Wed Apr 13 15:24:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Apr 2016 19:24:24 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za>
Message-ID: <1460575464.69.0.769023210339.issue25702@psf.upfronthosting.co.za>


STINNER Victor added the comment:

+  --with-lto              Enable Link Time Optimization in PGO builds.
+                          Disabled by default.

I don't understand why it's disabled by default. IMHO we must enable all the best optimizers options *by default*.

But I expect all optimizations to be disabled by --with-debug.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25702>
_______________________________________

From report at bugs.python.org  Wed Apr 13 15:50:26 2016
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 13 Apr 2016 19:50:26 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za>
Message-ID: <1460577026.2.0.800170590262.issue25702@psf.upfronthosting.co.za>


Stefan Krah added the comment:

LTO is not stable on all platforms (according to doko), and people don't
want to wait for PGO to build when they just run ./configure && make.

--with-pgo and --with-lto is fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25702>
_______________________________________

From report at bugs.python.org  Wed Apr 13 15:53:38 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Apr 2016 19:53:38 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za>
Message-ID: <1460577218.36.0.407315097832.issue25702@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> LTO is not stable on all platforms (according to doko), and people don't want to wait for PGO to build when they just run ./configure && make.

Can we have a whitelist of arch known to support PGO and/or LTO? Or maybe a blacklist?

Ubuntu already has this knownledge in their package, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25702>
_______________________________________

From report at bugs.python.org  Wed Apr 13 15:55:45 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 13 Apr 2016 19:55:45 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1460577026.2.0.800170590262.issue25702@psf.upfronthosting.co.za>
Message-ID: <570EA43A.9090009@egenix.com>


Marc-Andre Lemburg added the comment:

On 13.04.2016 21:50, Stefan Krah wrote:
> 
> LTO is not stable on all platforms (according to doko), and people don't
> want to wait for PGO to build when they just run ./configure && make.
> 
> --with-pgo and --with-lto is fine.

Agreed. Let's not make compilation take longer than necessary.

When doing production builds, people can still enable these
optimizations as necessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25702>
_______________________________________

From report at bugs.python.org  Wed Apr 13 15:57:45 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Apr 2016 19:57:45 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <570EA43A.9090009@egenix.com>
Message-ID: <570EA4B7.3070103@free.fr>


Antoine Pitrou added the comment:

Le 13/04/2016 21:55, Marc-Andre Lemburg a ?crit :
>>
>> LTO is not stable on all platforms (according to doko), and people don't
>> want to wait for PGO to build when they just run ./configure && make.
>>
>> --with-pgo and --with-lto is fine.
> 
> Agreed. Let's not make compilation take longer than necessary.
> 
> When doing production builds, people can still enable these
> optimizations as necessary.

Agreed as well. It's enough to make these options sufficiently accessible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25702>
_______________________________________

From report at bugs.python.org  Wed Apr 13 16:04:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Apr 2016 20:04:46 +0000
Subject: [issue26748] enum.Enum is False-y
In-Reply-To: <1460568121.51.0.847598758945.issue26748@psf.upfronthosting.co.za>
Message-ID: <1460577886.14.0.502808882855.issue26748@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue23008.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26748>
_______________________________________

From report at bugs.python.org  Wed Apr 13 17:13:26 2016
From: report at bugs.python.org (Raghu)
Date: Wed, 13 Apr 2016 21:13:26 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460582006.37.0.931404363513.issue26743@psf.upfronthosting.co.za>


Raghu added the comment:

Hi, I apologize. I didn't expect a quick reply.
Here are the outputs you requested.

root at host:~# python
Python 2.7.3 (default, Apr  3 2016, 22:31:30)
[GCC 4.8.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> print math.sqrt(2.0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: math domain error
>>> print math
<module 'math' from '/usr/lib/python2.7/lib-dynload/math.so'>
>>> import struct
>>> struct.pack('<d', 2.0)
'\x00\x00\x00\x00\x00\x00\x00@'
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Wed Apr 13 18:13:06 2016
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 13 Apr 2016 22:13:06 +0000
Subject: [issue26750] Mock autospec does not work with subclasses of property()
Message-ID: <1460585586.67.0.646853664072.issue26750@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc:

When patching a class, mock.create_autospec() correctly detects properties and __slot__ attributes, but not subclasses of property() or other kinds of data descriptors.

The attached patch detects all data descriptors and patch them the way they should be.

----------
components: Tests
files: mock-descriptor.patch
keywords: patch
messages: 263361
nosy: amaury.forgeotdarc, michael.foord
priority: normal
severity: normal
status: open
title: Mock autospec does not work with subclasses of property()
type: enhancement
Added file: http://bugs.python.org/file42458/mock-descriptor.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26750>
_______________________________________

From report at bugs.python.org  Wed Apr 13 20:45:12 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Apr 2016 00:45:12 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460594712.22.0.819766654869.issue26743@psf.upfronthosting.co.za>


STINNER Victor added the comment:

>>> print math.sqrt(2.0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: math domain error

I'm surprised that such basic math function fails.

Can you please try to compile and run attached C program?

$ gcc sqrt.c -o sqrt -lm && ./sqrt
sqrt(2) = 1.41421

----------
nosy: +haypo
Added file: http://bugs.python.org/file42459/sqrt.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Wed Apr 13 20:48:53 2016
From: report at bugs.python.org (Raghu)
Date: Thu, 14 Apr 2016 00:48:53 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460594933.09.0.913682333193.issue26743@psf.upfronthosting.co.za>


Raghu added the comment:

stinner victor, my host doesn't have a gcc compiler. is there a way you can give me the binary?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Wed Apr 13 20:50:28 2016
From: report at bugs.python.org (Raghu)
Date: Thu, 14 Apr 2016 00:50:28 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460595028.43.0.937520537004.issue26743@psf.upfronthosting.co.za>


Raghu added the comment:

my host details:

Linux fpc0 3.10.62-ltsi-WR6.0.0.18_standard #1 SMP PREEMPT Sun Apr 3 23:17:02 PDT 2016 ppc64 ppc64 ppc64 GNU/Linux

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Wed Apr 13 20:58:12 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Apr 2016 00:58:12 +0000
Subject: [issue26693] Exception ignored in: <module 'threading' from
 ...threading.py> in _shutdown, assert tlock.locked()
In-Reply-To: <1459821105.82.0.884891417565.issue26693@psf.upfronthosting.co.za>
Message-ID: <1460595492.26.0.884972199104.issue26693@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/issue26693>
_______________________________________

From report at bugs.python.org  Wed Apr 13 21:04:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Apr 2016 01:04:03 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460595843.67.0.083709218155.issue26743@psf.upfronthosting.co.za>


STINNER Victor added the comment:

What is your Linux distribution and what is your CPU? (try to read /proc/cpuinfo)

You cannot install a C compiler?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Wed Apr 13 21:14:34 2016
From: report at bugs.python.org (Raghu)
Date: Thu, 14 Apr 2016 01:14:34 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460596474.34.0.893716501493.issue26743@psf.upfronthosting.co.za>


Raghu added the comment:

It's windriver linux. Processor is PPC64-E5500

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Wed Apr 13 21:14:51 2016
From: report at bugs.python.org (David Manowitz)
Date: Thu, 14 Apr 2016 01:14:51 +0000
Subject: [issue26751] Possible bug in sorting algorithm
Message-ID: <1460596491.57.0.479961799171.issue26751@psf.upfronthosting.co.za>


New submission from David Manowitz:

I'm trying to sort a list of tuples.  Most of the tuples are pairs of US state names.  However, some of the tuples have None instead of the 2nd name.  I want the items sorted first by the 1st element, and then by the 2nd element, BUT I want the None to count as LARGER than any name.  Thus, I want to see [('Alabama', 'Iowa'), ('Alabama', None)] rather than [('Alabama', None), ('Alabama', 'Iowa')].  I defined the following comparitor:

def cmp_keys (k1, k2):
    retval = cmp(k1[0], k2[0])
    if retval == 0:
        if k2[1] is None:
            retval = -1
        if k1[1] is None:
            retval = 1
        else:
            retval = cmp(k1[1], k2[1])
                
    return retval

However, once I sort using this, some of the elements are out of order.

----------
components: Interpreter Core
messages: 263367
nosy: David.Manowitz
priority: normal
severity: normal
status: open
title: Possible bug in sorting algorithm
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26751>
_______________________________________

From report at bugs.python.org  Wed Apr 13 21:21:33 2016
From: report at bugs.python.org (Tim Peters)
Date: Thu, 14 Apr 2016 01:21:33 +0000
Subject: [issue26751] Possible bug in sorting algorithm
In-Reply-To: <1460596491.57.0.479961799171.issue26751@psf.upfronthosting.co.za>
Message-ID: <1460596893.82.0.0639821241836.issue26751@psf.upfronthosting.co.za>


Tim Peters added the comment:

If that's the actual code you're using, it has a bug:  the "if k2[1] is None" test is useless, since regardless of whether it's true or false, the next `if` suite overwrites `retval`.  You probably meant

    elif k1[1] ...
    ^^

instead of

    if k1[1] ...

Does that fix your problem?

If not, please augment the bug report with the _complete_ code you're actually using, a sample problematic input, the exact output you're expecting, and the exact output you're seeing instead.  We're not telepathic ;-)

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26751>
_______________________________________

From report at bugs.python.org  Thu Apr 14 00:35:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Apr 2016 04:35:47 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460608547.32.0.560178924693.issue26743@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What is the output of `struct.pack('d', 2.0)` and `struct.pack('d', float(2))`?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Thu Apr 14 01:43:15 2016
From: report at bugs.python.org (Raghu)
Date: Thu, 14 Apr 2016 05:43:15 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460612595.59.0.787181229771.issue26743@psf.upfronthosting.co.za>


Raghu added the comment:

Serhiy,

root at host:~# python
Python 2.7.3 (default, Apr  3 2016, 22:31:30)
[GCC 4.8.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> struct.pack('d', 2.0)
'@\x00\x00\x00\x00\x00\x00\x00'
>>> struct.pack('d', float(2))
'@\x00\x00\x00\x00\x00\x00\x00'
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Thu Apr 14 03:04:14 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 Apr 2016 07:04:14 +0000
Subject: [issue26748] enum.Enum is False-y
In-Reply-To: <1460568121.51.0.847598758945.issue26748@psf.upfronthosting.co.za>
Message-ID: <20160414070411.26087.31648.13103AB2@psf.io>


Roundup Robot added the comment:

New changeset 772805538caf by Ethan Furman in branch '3.4':
Issue26748: Enum classes should evaluate as True
https://hg.python.org/cpython/rev/772805538caf

New changeset f840608f79da by Ethan Furman in branch '3.5':
Issue26748: Enum classes should evaluate as True
https://hg.python.org/cpython/rev/f840608f79da

New changeset 2fc61f8ee2d2 by Ethan Furman in branch 'default':
Issue26748: Enum classes should evaluate as True
https://hg.python.org/cpython/rev/2fc61f8ee2d2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26748>
_______________________________________

From report at bugs.python.org  Thu Apr 14 03:16:02 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Thu, 14 Apr 2016 07:16:02 +0000
Subject: [issue26359] CPython build options for out-of-the box performance
In-Reply-To: <1455445693.01.0.984013993837.issue26359@psf.upfronthosting.co.za>
Message-ID: <1460618162.08.0.365394888545.issue26359@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

Hello Victor, 

Indeed, the best outcome is to have PGO, LTO, etc enabled by default when running ./configure && make, for production level. I also feel that they should be on by default, if only developers would use the debug version.

Do you think that modifying the patches attached to this issue and enabling all optimizations by default could be considered acceptable by the Python community?

Thank you,
Alecsandru

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26359>
_______________________________________

From report at bugs.python.org  Thu Apr 14 03:35:16 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Apr 2016 07:35:16 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460619316.66.0.657076331151.issue26743@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What is the output of `python -m sysconfig`?

Python 2.7.3 is too old. May be this issue was already fixed in newer versions. Can you install 2.7.11?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Thu Apr 14 03:42:33 2016
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 14 Apr 2016 07:42:33 +0000
Subject: [issue26359] CPython build options for out-of-the box performance
In-Reply-To: <1455445693.01.0.984013993837.issue26359@psf.upfronthosting.co.za>
Message-ID: <1460619753.15.0.615068325156.issue26359@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Not acceptable, I'm afraid. See #25702.  I'm not sure why it is
considered so bothersome to type --with-pgo and --with-lto for
the rare case of a real production build.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26359>
_______________________________________

From report at bugs.python.org  Thu Apr 14 03:43:24 2016
From: report at bugs.python.org (James)
Date: Thu, 14 Apr 2016 07:43:24 +0000
Subject: [issue26752] Mock(2.0.0).assert_has_calls() raise AssertionError in
 two same calls
Message-ID: <1460619804.34.0.222553592589.issue26752@psf.upfronthosting.co.za>


New submission from James:

>>> import mock
>>> print mock.__version__
2.0.0
>>> 

=================
test.py
from mock import Mock,call

class BB(object):
    def __init__(self):pass
    def print_b(self):pass
    def print_bb(self,tsk_id):pass


bMock = Mock(return_value=Mock(spec=BB))
bMock().print_bb(20)
bMock().assert_has_calls([call.print_bb(20)])


===================
Traceback (most recent call last):
  File "test.py", line 11, in <module>
    bMock().assert_has_calls([call.print_bb(20)])
  File "/usr/lib/python2.7/site-packages/mock/mock.py", line 969, in assert_has_calls
    ), cause)
  File "/usr/lib/python2.7/site-packages/six.py", line 718, in raise_from
    raise value
AssertionError: Calls not found.
Expected: [call.print_bb(20)]
Actual: [call.print_bb(20)]

=======
print expected in mock.py assert_has_calls()

result is:
[TypeError('too many positional arguments',)]

----------
files: test.py
messages: 263375
nosy: jekin000, rbcollins
priority: normal
severity: normal
status: open
title: Mock(2.0.0).assert_has_calls() raise AssertionError in two same calls
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file42460/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26752>
_______________________________________

From report at bugs.python.org  Thu Apr 14 03:43:43 2016
From: report at bugs.python.org (Raghu)
Date: Thu, 14 Apr 2016 07:43:43 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460619823.29.0.956933723724.issue26743@psf.upfronthosting.co.za>


Raghu added the comment:

There is no output for `python -m sysconfig`

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Thu Apr 14 03:55:46 2016
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 14 Apr 2016 07:55:46 +0000
Subject: [issue26753] Obmalloc lock LOCK_INIT and LOCK_FINI are never used
Message-ID: <1460620546.75.0.247903713074.issue26753@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Obmalloc now has theoretical support for locking.  I say theoretical because I'm not convinced it's ever been used.

The interface is defined through five macros:
    SIMPLELOCK_DECL
    SIMPLELOCK_INIT
    SIMPLELOCK_FINI
    SIMPLELOCK_LOCK
    SIMPLELOCK_UNLOCK

Internally these are used to define an actual lock to be used in the module.  The lock, "_malloc_lock", is declared, then four defines are made building on top of the SIMPLELOCK macros, named:
    LOCK
    UNLOCK
    LOCK_INIT
    LOCK_FINI

LOCK_INIT and LOCK_FINI are never called.  So unless your lock doesn't happen to require initialization or shutdown, this API is misimplemented.

Victor: this was your work, right?  If not, sorry, please unassign/de-nosy yourself.

----------
assignee: haypo
components: Interpreter Core
messages: 263377
nosy: haypo, larry
priority: low
severity: normal
stage: needs patch
status: open
title: Obmalloc lock LOCK_INIT and LOCK_FINI are never used
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26753>
_______________________________________

From report at bugs.python.org  Thu Apr 14 04:06:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Apr 2016 08:06:10 +0000
Subject: [issue26754] PyUnicode_FSDecoder() accepts arbitrary iterable
Message-ID: <1460621170.51.0.766625206789.issue26754@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

PyUnicode_FSDecoder() accepts not only str and bytes or bytes-like object, but arbitrary iterable, e.g. list.

Example:

>>> compile('', [116, 101, 115, 116], 'exec')
<code object <module> at 0xb6fb1340, file "test", line 1>

I think accepting arbitrary iterables is unintentional and weird behavior.

----------
components: Interpreter Core
messages: 263378
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: PyUnicode_FSDecoder() accepts arbitrary iterable
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26754>
_______________________________________

From report at bugs.python.org  Thu Apr 14 04:09:52 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Apr 2016 08:09:52 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460621392.69.0.482347846964.issue26743@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What is the output of `import sysconfig; print sysconfig.get_config_vars()`?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Thu Apr 14 04:27:19 2016
From: report at bugs.python.org (Christian Tanzer)
Date: Thu, 14 Apr 2016 08:27:19 +0000
Subject: [issue22005] datetime.__setstate__ fails decoding python2 pickle
In-Reply-To: <1405687792.76.0.689943587668.issue22005@psf.upfronthosting.co.za>
Message-ID: <1460622439.26.0.125715372309.issue22005@psf.upfronthosting.co.za>


Christian Tanzer added the comment:

This issue is getting old. Is there any way to solve this for Python 3.6?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22005>
_______________________________________

From report at bugs.python.org  Thu Apr 14 04:34:13 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Apr 2016 08:34:13 +0000
Subject: [issue26753] Obmalloc lock LOCK_INIT and LOCK_FINI are never used
In-Reply-To: <1460620546.75.0.247903713074.issue26753@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbDVTdkLB08WhTaZMokvy+eJCjsFscccOYO8AwZzeSuiw@mail.gmail.com>


STINNER Victor added the comment:

These macros are very old, I didn't write them. They are not used since the
API rely on the GIL.

Do you want to remove them?

I think that it's ok to keep them, just in case, if tomorrow we want to
support multiple allocations in parallel. Maybe a comment should explain
that these macros are not used because of the GIL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26753>
_______________________________________

From report at bugs.python.org  Thu Apr 14 04:38:49 2016
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 14 Apr 2016 08:38:49 +0000
Subject: [issue26753] Obmalloc lock LOCK_INIT and LOCK_FINI are never used
In-Reply-To: <1460620546.75.0.247903713074.issue26753@psf.upfronthosting.co.za>
Message-ID: <1460623129.5.0.436848093215.issue26753@psf.upfronthosting.co.za>


Larry Hastings added the comment:

There's already a comment saying that the macros are empty because the GIL protects obmalloc from parallelization.

I'd be happy to improve the code and add calls for LOCK_INIT and LOCK_FINI in the proper places.  You don't have to do it.  Since this isn't your goof I'll go ahead and own it.

----------
assignee: haypo -> larry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26753>
_______________________________________

From report at bugs.python.org  Thu Apr 14 04:39:20 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Thu, 14 Apr 2016 08:39:20 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za>
Message-ID: <1460623160.19.0.635787464978.issue25702@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

@Stefan and @Marc, you say that people don't want to wait for PGO to build when running ./configure && make, but why? Even though many developers use it, this mode is not intended for development, it is production level and should be run once (or at leas a limited number or times), when the developers are sure that everything is fine in the debug mode. As Victor previously said, we should have all the *good* stuff (PGO, LTO, etc) enabled by default, regardless the time needed to do it.

@Victor, indeed, LTO is not yet good enough to use it stand-alone in CPython. That is the reason why it is enabled only with PGO, because applied over it, we obtain further speedups than PGO alone. Also Ubuntu uses PGO and LTO in their releases.

But in the end maybe `./configure --with-lto && make profile-opt` will have to do for everybody.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25702>
_______________________________________

From report at bugs.python.org  Thu Apr 14 04:41:22 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Thu, 14 Apr 2016 08:41:22 +0000
Subject: [issue26359] CPython build options for out-of-the box performance
In-Reply-To: <1455445693.01.0.984013993837.issue26359@psf.upfronthosting.co.za>
Message-ID: <1460623282.96.0.996942194566.issue26359@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

Maybe that end users are lazy and want to type just `make` and let things happen magically behind the scenes :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26359>
_______________________________________

From report at bugs.python.org  Thu Apr 14 04:55:25 2016
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 14 Apr 2016 08:55:25 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1460623160.19.0.635787464978.issue25702@psf.upfronthosting.co.za>
Message-ID: <20160414085513.GA4115@bytereef.org>


Stefan Krah added the comment:

On Thu, Apr 14, 2016 at 08:39:20AM +0000, Alecsandru Patrascu wrote:
> @Stefan and @Marc, you say that people don't want to wait for PGO to build when running ./configure && make, but why? Even though many developers use it, this mode is not intended for development, it is production level and should be run once (or at leas a limited number or times), when the developers are sure that everything is fine in the debug mode. As Victor previously said, we should have all the *good* stuff (PGO, LTO, etc) enabled by default, regardless the time needed to do it.

I use it all the time in development:

  - For running math tests that would be too slow otherwise.

  - To diagnose invalid accesses that only occur with -O2.

  - To speed up Valgrind runs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25702>
_______________________________________

From report at bugs.python.org  Thu Apr 14 05:07:32 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 14 Apr 2016 09:07:32 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1460623160.19.0.635787464978.issue25702@psf.upfronthosting.co.za>
Message-ID: <570F5DCC.4060301@egenix.com>


Marc-Andre Lemburg added the comment:

On 14.04.2016 10:39, Alecsandru Patrascu wrote:
> 
> @Stefan and @Marc, you say that people don't want to wait for PGO to build when running ./configure && make, but why? Even though many developers use it, this mode is not intended for development, it is production level and should be run once (or at leas a limited number or times), when the developers are sure that everything is fine in the debug mode. As Victor previously said, we should have all the *good* stuff (PGO, LTO, etc) enabled by default, regardless the time needed to do it.

You need to compile Python a lot during Python development and
here the compile speed matters, the performance of the resulting
binary is secondary (as long as it is consistent).

For production, it's easily possible to add those options to configure,
plus it's not 100% clear whether all optimizations really do create
correct code. We've had lots of issues with optimization errors in
compilers in the past and have generally been rather conservative with
the default optimization settings. It's better to have a stable running
Python, than a Python that is fast at failing or creating wrong
results ;-)

I think having these extra options readily accessible and
working is great, and people who know what they are doing can
then use them for the benefit of getting an even faster Python.

Distributors will know what they are doing, so many Python
users will still be able to benefit from them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25702>
_______________________________________

From report at bugs.python.org  Thu Apr 14 05:13:39 2016
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 14 Apr 2016 09:13:39 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <20160414085513.GA4115@bytereef.org>
Message-ID: <20160414091328.GA4259@bytereef.org>


Stefan Krah added the comment:

On Thu, Apr 14, 2016 at 08:55:25AM +0000, Stefan Krah wrote:
> I use it all the time in development:

... where "it" refers to "./configure && make", not to PGO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25702>
_______________________________________

From report at bugs.python.org  Thu Apr 14 05:16:05 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Apr 2016 09:16:05 +0000
Subject: [issue26754] PyUnicode_FSDecoder() accepts arbitrary iterable
In-Reply-To: <1460621170.51.0.766625206789.issue26754@psf.upfronthosting.co.za>
Message-ID: <1460625365.25.0.86948473691.issue26754@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I agree this doens't make sense.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26754>
_______________________________________

From report at bugs.python.org  Thu Apr 14 05:16:42 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 14 Apr 2016 09:16:42 +0000
Subject: [issue26749] Update devguide to include Fedora's DNF
In-Reply-To: <1460573343.29.0.391562448207.issue26749@psf.upfronthosting.co.za>
Message-ID: <1460625402.77.0.764520755327.issue26749@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Committed in 0ed2497e5aa4. Thanks for the patch, Luiz.

----------
components: +Devguide -Documentation
nosy: +berker.peksag, ezio.melotti, willingc
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26749>
_______________________________________

From report at bugs.python.org  Thu Apr 14 05:17:08 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 Apr 2016 09:17:08 +0000
Subject: [issue26749] Update devguide to include Fedora's DNF
In-Reply-To: <1460573343.29.0.391562448207.issue26749@psf.upfronthosting.co.za>
Message-ID: <20160414091457.19493.76264.A7269803@psf.io>


Roundup Robot added the comment:

New changeset 0ed2497e5aa4 by Berker Peksag in branch 'default':
Issue #26749: Update devguide to include DNF package manager
https://hg.python.org/devguide/rev/0ed2497e5aa4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26749>
_______________________________________

From report at bugs.python.org  Thu Apr 14 05:31:23 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 Apr 2016 09:31:23 +0000
Subject: [issue26057] Avoid nonneeded use of PyUnicode_FromObject()
In-Reply-To: <1452328901.15.0.65828251852.issue26057@psf.upfronthosting.co.za>
Message-ID: <20160414093119.12745.23599.4D15A562@psf.io>


Roundup Robot added the comment:

New changeset 19dec08e54a8 by Serhiy Storchaka in branch 'default':
Issues #26716, #26057: Regenerate Argument Clinic code.
https://hg.python.org/cpython/rev/19dec08e54a8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26057>
_______________________________________

From report at bugs.python.org  Thu Apr 14 05:31:23 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 Apr 2016 09:31:23 +0000
Subject: [issue26716] EINTR handling in fcntl
In-Reply-To: <1460145033.33.0.165294517839.issue26716@psf.upfronthosting.co.za>
Message-ID: <20160414093119.12745.3837.1B2708C5@psf.io>


Roundup Robot added the comment:

New changeset 9ffe055f2b0e by Serhiy Storchaka in branch '3.5':
Issue #26716: Regenerate Argument Clinic code.
https://hg.python.org/cpython/rev/9ffe055f2b0e

New changeset 19dec08e54a8 by Serhiy Storchaka in branch 'default':
Issues #26716, #26057: Regenerate Argument Clinic code.
https://hg.python.org/cpython/rev/19dec08e54a8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26716>
_______________________________________

From report at bugs.python.org  Thu Apr 14 05:38:45 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 14 Apr 2016 09:38:45 +0000
Subject: [issue26755] Update version{added,changed} docs in devguide
Message-ID: <1460626724.97.0.188358038821.issue26755@psf.upfronthosting.co.za>


New submission from Berker Peksag:

This is a follow-up from issue 26366:

    "the original intention was to use "versionadded" where the API item is completely new.  So "The parameter x was added" in a function is using "versionchanged" because only an aspect of the function's signature was changed."

See msg260314 and msg260509 for details.

----------
components: Devguide
files: versionchanged.diff
keywords: patch
messages: 263393
nosy: berker.peksag, ezio.melotti, georg.brandl, willingc
priority: normal
severity: normal
stage: patch review
status: open
title: Update version{added,changed} docs in devguide
type: behavior
Added file: http://bugs.python.org/file42461/versionchanged.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26755>
_______________________________________

From report at bugs.python.org  Thu Apr 14 05:59:54 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 14 Apr 2016 09:59:54 +0000
Subject: [issue26754] PyUnicode_FSDecoder() accepts arbitrary iterable
In-Reply-To: <1460621170.51.0.766625206789.issue26754@psf.upfronthosting.co.za>
Message-ID: <1460627994.56.0.847526661668.issue26754@psf.upfronthosting.co.za>


Martin Panter added the comment:

I agree it is a bit strange. It looks like it is a victim of PyBytes_FromObject() doing more than it says; its documentation only mentions the buffer protocol, not accepting iterables.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26754>
_______________________________________

From report at bugs.python.org  Thu Apr 14 06:17:43 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Thu, 14 Apr 2016 10:17:43 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za>
Message-ID: <1460629063.6.0.790380905874.issue25702@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

Maybe an workflow like the one proposed in issue #26359 can be helpful in these development phases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25702>
_______________________________________

From report at bugs.python.org  Thu Apr 14 06:51:13 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Apr 2016 10:51:13 +0000
Subject: [issue26754] PyUnicode_FSDecoder() accepts arbitrary iterable
In-Reply-To: <1460621170.51.0.766625206789.issue26754@psf.upfronthosting.co.za>
Message-ID: <1460631073.66.0.688013652141.issue26754@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

PyUnicode_FSDecoder() is used in following functions in the stdlib:

compile()
symtable.symtable()
parser.compile()
parser.compilest()
zipimporter.zipimporter()
_imp.load_dynamic() (before 3.5)

This is behavior of PyUnicode_FSDecoder() from the start (issue9542). All above functions accepted only str in 3.1, thus accepting bytes object and others was new feature.

None tests are failed if reject non-str and non-bytes argument in PyUnicode_FSDecoder(). But none tests are failed even if disable support of bytes argument (there is a lack of tests for bytes path).

What should we do?

1. Add a warning when the argument neither str nor supporting the buffer protocol.

2. Drop support of non-str and not supporting the buffer protocol arguments without a warning.

3. Drop support of non-str and not supporting the buffer protocol arguments without a warning, and add a warning when the argument neither str nor bytes.

4. Drop support of non-str and non-bytes arguments without a warning.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26754>
_______________________________________

From report at bugs.python.org  Thu Apr 14 07:32:42 2016
From: report at bugs.python.org (Alwin Kahlert)
Date: Thu, 14 Apr 2016 11:32:42 +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: <1460633562.64.0.907748294016.issue20607@psf.upfronthosting.co.za>


Alwin Kahlert added the comment:

I have also trouble with this bug. It wasn't fixed in Python 3.4 and Python 3.5. It should be reopened.

----------
nosy: +Alwin Kahlert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20607>
_______________________________________

From report at bugs.python.org  Thu Apr 14 07:46:05 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 14 Apr 2016 11:46:05 +0000
Subject: [issue26752] Mock(2.0.0).assert_has_calls() raise AssertionError in
 two same calls
In-Reply-To: <1460619804.34.0.222553592589.issue26752@psf.upfronthosting.co.za>
Message-ID: <1460634365.57.0.992135567627.issue26752@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26752>
_______________________________________

From report at bugs.python.org  Thu Apr 14 08:17:57 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 14 Apr 2016 12:17:57 +0000
Subject: [issue17339] bytes() TypeError message is misleadingly narrow
In-Reply-To: <1362254314.39.0.995387791388.issue17339@psf.upfronthosting.co.za>
Message-ID: <1460636277.73.0.243361364147.issue17339@psf.upfronthosting.co.za>


Martin Panter added the comment:

The int.from_bytes() behaviour seems to have been documented from the beginning, so maybe it was intended.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17339>
_______________________________________

From report at bugs.python.org  Thu Apr 14 08:25:57 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Apr 2016 12:25:57 +0000
Subject: [issue15984] Wrong documentation for PyUnicode_FromObject() and
 PyUnicode_FromEncodedObject()
In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za>
Message-ID: <1460636757.52.0.858669515529.issue15984@psf.upfronthosting.co.za>


STINNER Victor added the comment:

from_object_v4.patch LGTM, nice enhancement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15984>
_______________________________________

From report at bugs.python.org  Thu Apr 14 08:40:18 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Apr 2016 12:40:18 +0000
Subject: [issue26721] Avoid socketserver.StreamRequestHandler.wfile doing
 partial writes
In-Reply-To: <1460204395.72.0.250418211057.issue26721@psf.upfronthosting.co.za>
Message-ID: <1460637618.94.0.746653664005.issue26721@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hum, since long time ago, Python has issues with partial write. It's hard to guess if a write will always write all data, store the data on partial write, or simply ignore remaining data on partial write.

I recall a "write1" function which was well defined: limited to 1 syscall, don't try (or maybe only on the very specific case of EINTR). But I'm not sure that it still exists in the io module of Python 3.

asyncio has also issues with the definition of "partial write" in its API.

You propose to fix the issue in socketserver.

socket.makefile(bufsize=0).write() uses send() and so use partial write. Are you sure that users are prepared for that? Maybe SocketIO must be modified to use sendall() when bufsize=0?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26721>
_______________________________________

From report at bugs.python.org  Thu Apr 14 08:42:31 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Apr 2016 12:42:31 +0000
Subject: [issue26721] Avoid socketserver.StreamRequestHandler.wfile doing
 partial writes
In-Reply-To: <1460204395.72.0.250418211057.issue26721@psf.upfronthosting.co.za>
Message-ID: <1460637751.2.0.9933601594.issue26721@psf.upfronthosting.co.za>


STINNER Victor added the comment:

FYI I recently worked on a issue with partial write in eventlet on Python 3:
* https://github.com/eventlet/eventlet/issues/274
* https://github.com/eventlet/eventlet/issues/295

By the way, I opened #26292 "Raw I/O writelines() broken for non-blocking I/O" as a follow-up of the eventlet issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26721>
_______________________________________

From report at bugs.python.org  Thu Apr 14 08:45:58 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Apr 2016 12:45:58 +0000
Subject: [issue26721] Avoid socketserver.StreamRequestHandler.wfile doing
 partial writes
In-Reply-To: <1460204395.72.0.250418211057.issue26721@psf.upfronthosting.co.za>
Message-ID: <1460637958.44.0.378850303467.issue26721@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I recall a "write1" function which was well defined: limited to 1 syscall, don't try (or maybe only on the very specific case of EINTR). But I'm not sure that it still exists in the io module of Python 3.

Oops, in fact it is read1:
https://docs.python.org/dev/library/io.html#io.BufferedIOBase.read1
"Read and return up to size bytes, with at most one call to the underlying raw stream?s read()"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26721>
_______________________________________

From report at bugs.python.org  Thu Apr 14 08:50:42 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 Apr 2016 12:50:42 +0000
Subject: [issue26747] types.InstanceType only for old style class only in 2.7
In-Reply-To: <1460561340.28.0.563389556375.issue26747@psf.upfronthosting.co.za>
Message-ID: <20160414125032.8336.75848.B8B58E5D@psf.io>


Roundup Robot added the comment:

New changeset b684298671f9 by Berker Peksag in branch '2.7':
Issue #26747: Document that InstanceTypes only works for old-style classes
https://hg.python.org/cpython/rev/b684298671f9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26747>
_______________________________________

From report at bugs.python.org  Thu Apr 14 08:51:40 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 14 Apr 2016 12:51:40 +0000
Subject: [issue26747] types.InstanceType only for old style class only in 2.7
In-Reply-To: <1460561340.28.0.563389556375.issue26747@psf.upfronthosting.co.za>
Message-ID: <1460638300.48.0.110139940673.issue26747@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks!

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26747>
_______________________________________

From report at bugs.python.org  Thu Apr 14 08:52:19 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Apr 2016 12:52:19 +0000
Subject: [issue26638] Avoid warnings about missing CLI options when building
 documentation
In-Reply-To: <1458881380.09.0.599104229044.issue26638@psf.upfronthosting.co.za>
Message-ID: <1460638339.46.0.926901334261.issue26638@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> FTR the warnings that I am fixing were apparently enabled in Sphinx 1.3.4, reverted in 1.3.6, and added in 1.4.

Would it be possible to turn off the warning?

Doc/using/cmdline.py uses ".. cmdoption::". If we cannot turn off the warning on option, maybe we should use a new :cmdoption:`xxx` which wouldn't emit a warning?

I'm not strongly opposed to doc-warnings.patch.

I understand that Sphinx expects the exact option, for example -W, whereas the doc uses option with parameter like -Wd. Sphinx is unable to link to the option.

Maybe we need something like :cmdoption:`-Wd <-W>`: display -Wd but link to -W?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26638>
_______________________________________

From report at bugs.python.org  Thu Apr 14 08:54:16 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Apr 2016 12:54:16 +0000
Subject: [issue25654] test_multiprocessing_spawn ResourceWarning with -Werror
In-Reply-To: <1447830828.22.0.981390741581.issue25654@psf.upfronthosting.co.za>
Message-ID: <1460638456.38.0.617705290627.issue25654@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Since the initial issue is fixed (test failures when using -Werror), I suggest to close this issue.

> BTW the spurious background processes are still there (visible if you run ?ps? or ?pstree? immediately after the test finishes), but they no longer print errors.

Please open a new issue for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25654>
_______________________________________

From report at bugs.python.org  Thu Apr 14 08:55:26 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Apr 2016 12:55:26 +0000
Subject: [issue23214] BufferedReader.read1(size) signature incompatible with
 BufferedIOBase.read1(size=-1)
In-Reply-To: <1420854382.8.0.44417983014.issue23214@psf.upfronthosting.co.za>
Message-ID: <1460638526.51.0.0930449881319.issue23214@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/issue23214>
_______________________________________

From report at bugs.python.org  Thu Apr 14 09:23:32 2016
From: report at bugs.python.org (Luiz Poleto)
Date: Thu, 14 Apr 2016 13:23:32 +0000
Subject: [issue26749] Update devguide to include Fedora's DNF
In-Reply-To: <1460625402.77.0.764520755327.issue26749@psf.upfronthosting.co.za>
Message-ID: <CAHFUrkcPN4pxf0A0oB7O4q6V29QmWpS1jd2Gy4gq2aSYyXRnQg@mail.gmail.com>


Luiz Poleto added the comment:

Nice! Thanks!

On Thu, Apr 14, 2016, 5:16 AM Berker Peksag <report at bugs.python.org> wrote:

>
> Berker Peksag added the comment:
>
> Committed in 0ed2497e5aa4. Thanks for the patch, Luiz.
>
> ----------
> components: +Devguide -Documentation
> nosy: +berker.peksag, ezio.melotti, willingc
> resolution:  -> fixed
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue26749>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26749>
_______________________________________

From report at bugs.python.org  Thu Apr 14 09:46:45 2016
From: report at bugs.python.org (Steve Dower)
Date: Thu, 14 Apr 2016 13:46:45 +0000
Subject: [issue26359] CPython build options for out-of-the box performance
In-Reply-To: <1455445693.01.0.984013993837.issue26359@psf.upfronthosting.co.za>
Message-ID: <1460641605.81.0.606376048926.issue26359@psf.upfronthosting.co.za>


Steve Dower added the comment:

FWIW, I'm also against enabling it by default due to the extended build time. There are plenty of reasons to build Python with the non-debug ABI that don't require extended optimizations. Production builds are the exception I believe, not the rule.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26359>
_______________________________________

From report at bugs.python.org  Thu Apr 14 10:32:27 2016
From: report at bugs.python.org (Joel Barry)
Date: Thu, 14 Apr 2016 14:32:27 +0000
Subject: [issue26756] fileinput handling of unicode errors from standard input
Message-ID: <1460644347.16.0.552330506095.issue26756@psf.upfronthosting.co.za>


New submission from Joel Barry:

The openhook for fileinput currently will not be called when the input
is from sys.stdin.  However, if the input contains invalid UTF-8
sequences, a program with a hook that specifies errors='replace' will
not behave as expected:

  $ cat x.py
  import fileinput
  import sys
  
  def hook(filename, mode):
      print('hook called')
      return open(filename, mode, errors='replace')
  
  for line in fileinput.input(openhook=hook):
      sys.stdout.write(line)


  $ echo -e "foo\x80bar" >in.txt

  $ python3 x.py in.txt
  hook called
  foo?bar

Good.  Hook is called, and replacement character is observed.

  $ python3 x.py <in.txt
  Traceback (most recent call last):
    File "x.py", line 8, in <module>
      for line in fileinput.input(openhook=hook):
    File "/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/fileinput.py", line 263, in __next__
      line = self.readline()
    File "/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/fileinput.py", line 363, in readline
      self._buffer = self._file.readlines(self._bufsize)
    File "/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/codecs.py", line 319, in decode
      (result, consumed) = self._buffer_decode(data, self.errors, final)
  UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 3: invalid start byte

Hook was not called, and so we get the UnicodeDecodeError.

Should fileinput attempt to apply the hook code to stdin?

----------
messages: 263409
nosy: jmb236
priority: normal
severity: normal
status: open
title: fileinput handling of unicode errors from standard input
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26756>
_______________________________________

From report at bugs.python.org  Thu Apr 14 10:47:54 2016
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 14 Apr 2016 14:47:54 +0000
Subject: [issue24165] Free list for single-digits ints
In-Reply-To: <1431352769.3.0.375640200007.issue24165@psf.upfronthosting.co.za>
Message-ID: <1460645274.08.0.55901283439.issue24165@psf.upfronthosting.co.za>


Larry Hastings added the comment:

FWIW, the patch still cleanly applies, but now a couple tests in posix fail because the assertion text has changed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24165>
_______________________________________

From report at bugs.python.org  Thu Apr 14 10:53:12 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Apr 2016 14:53:12 +0000
Subject: [issue26757] test_urllib2net.test_http_basic() timeout after 15 min on
Message-ID: <1460645592.51.0.660228574975.issue26757@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Timeout seen on "x86-64 Ubuntu 15.10 Skylake CPU 3.5" buildbot:

http://buildbot.python.org/all/builders/x86-64%20Ubuntu%2015.10%20Skylake%20CPU%203.5/builds/357/steps/test/logs/stdio

[215/398] test_urllib2net
Timeout (0:15:00)!
Thread 0x00007f71354be700 (most recent call first):
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/socket.py", line 575 in readinto
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/http/client.py", line 258 in _read_status
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/http/client.py", line 297 in begin
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/http/client.py", line 1197 in getresponse
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/urllib/request.py", line 1246 in do_open
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/urllib/request.py", line 1271 in http_open
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/urllib/request.py", line 443 in _call_chain
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/urllib/request.py", line 483 in _open
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/urllib/request.py", line 465 in open
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/urllib/request.py", line 162 in urlopen
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/test/test_urllib2net.py", line 19 in _retry_thrice
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/test/test_urllib2net.py", line 27 in wrapped
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/test/test_urllib2net.py", line 255 in test_http_basic
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/unittest/case.py", line 600 in run
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/unittest/case.py", line 648 in __call__
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/unittest/runner.py", line 176 in run
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/test/support/__init__.py", line 1800 in _run_suite
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/test/support/__init__.py", line 1834 in run_unittest
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/test/regrtest.py", line 1305 in test_runner
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/test/regrtest.py", line 1306 in runtest_inner
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/test/regrtest.py", line 991 in runtest
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/test/regrtest.py", line 784 in main
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/test/regrtest.py", line 1592 in main_in_temp_cwd
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/test/__main__.py", line 3 in <module>
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/runpy.py", line 85 in _run_code
  File "/home/buildbot/buildarea/3.5.intel-ubuntu-skylake/build/Lib/runpy.py", line 184 in _run_module_as_main

----------
messages: 263411
nosy: haypo, martin.panter
priority: normal
severity: normal
status: open
title: test_urllib2net.test_http_basic() timeout after 15 min on

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26757>
_______________________________________

From report at bugs.python.org  Thu Apr 14 10:55:13 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Apr 2016 14:55:13 +0000
Subject: [issue26757] test_urllib2net.test_http_basic() timeout after 15 min on
In-Reply-To: <1460645592.51.0.660228574975.issue26757@psf.upfronthosting.co.za>
Message-ID: <1460645713.31.0.213796106249.issue26757@psf.upfronthosting.co.za>


STINNER Victor added the comment:

See also issue #21069 "test_fileno of test_urllibnet intermittently fails".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26757>
_______________________________________

From report at bugs.python.org  Thu Apr 14 10:57:01 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Apr 2016 14:57:01 +0000
Subject: [issue26757] test_urllib2net.test_http_basic() timeout after 15 min on
In-Reply-To: <1460645592.51.0.660228574975.issue26757@psf.upfronthosting.co.za>
Message-ID: <1460645821.85.0.313007784086.issue26757@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It looks deliberate to test the HTTP query with *no* timeout. Sadly, it looks like it's ok that an HTTP query takes longer than 15 minutes!

Can't we mock the query to only test that the socket timeout is None? Move the test from test_urllib2net to test_urllib2.

class TimeoutTest(unittest.TestCase):
    def test_http_basic(self):
        self.assertIsNone(socket.getdefaulttimeout())
        url = "http://www.example.com"
        with support.transient_internet(url, timeout=None):
            u = _urlopen_with_retry(url)
            self.addCleanup(u.close)
            self.assertIsNone(u.fp.raw._sock.gettimeout())

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26757>
_______________________________________

From report at bugs.python.org  Thu Apr 14 10:58:36 2016
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 14 Apr 2016 14:58:36 +0000
Subject: [issue26757] test_urllib2net.test_http_basic() timeout after 15 min on
In-Reply-To: <1460645592.51.0.660228574975.issue26757@psf.upfronthosting.co.za>
Message-ID: <1460645916.98.0.460970710939.issue26757@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: +florin.papa, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26757>
_______________________________________

From report at bugs.python.org  Thu Apr 14 11:20:31 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Apr 2016 15:20:31 +0000
Subject: [issue26058] PEP 509: Add ma_version to PyDictObject
In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za>
Message-ID: <1460647231.09.0.557942517057.issue26058@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The implementation is outdated: ma_version was renamed to ma_version_tag in the latest version of the PEP 509.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26058>
_______________________________________

From report at bugs.python.org  Thu Apr 14 11:25:06 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 14 Apr 2016 15:25:06 +0000
Subject: [issue26359] CPython build options for out-of-the box performance
In-Reply-To: <1455445693.01.0.984013993837.issue26359@psf.upfronthosting.co.za>
Message-ID: <1460647506.78.0.351896861445.issue26359@psf.upfronthosting.co.za>


Brett Cannon added the comment:

What if we added a --with-optimizations flag to build --with-pgo, --with-lto, and avoid having to run `make` twice thanks to `make`/`make profileopt`? That way the default build is still quick and reasonable but gain a simple way to use the right flags and avoid having to remember to run `make` twice?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26359>
_______________________________________

From report at bugs.python.org  Thu Apr 14 11:27:08 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 Apr 2016 15:27:08 +0000
Subject: [issue26706] Update OpenSSL version in readme
In-Reply-To: <1459974987.74.0.0926215654006.issue26706@psf.upfronthosting.co.za>
Message-ID: <20160414152335.8354.84653.0F5EC6F1@psf.io>


Roundup Robot added the comment:

New changeset 4936b2723471 by Zachary Ware in branch '3.5':
Issue #26706: Update OpenSSL version in PCbuild/readme.txt
https://hg.python.org/cpython/rev/4936b2723471

New changeset 430f5a23a853 by Zachary Ware in branch 'default':
Closes #26706: Merge with 3.5
https://hg.python.org/cpython/rev/430f5a23a853

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26706>
_______________________________________

From report at bugs.python.org  Thu Apr 14 11:27:08 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 Apr 2016 15:27:08 +0000
Subject: [issue26465] Upgrade OpenSSL shipped with python installers
In-Reply-To: <1456842373.05.0.727353806198.issue26465@psf.upfronthosting.co.za>
Message-ID: <20160414152335.8354.47346.861DFC27@psf.io>


Roundup Robot added the comment:

New changeset 3a3b30c310e5 by Zachary Ware in branch '2.7':
Issue #26465: Update VS9.0 build files for OpenSSL 1.0.2g
https://hg.python.org/cpython/rev/3a3b30c310e5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26465>
_______________________________________

From report at bugs.python.org  Thu Apr 14 11:28:46 2016
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 14 Apr 2016 15:28:46 +0000
Subject: [issue26706] Update OpenSSL version in readme
In-Reply-To: <1459974987.74.0.0926215654006.issue26706@psf.upfronthosting.co.za>
Message-ID: <1460647726.32.0.907706594384.issue26706@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thanks, Shaun!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26706>
_______________________________________

From report at bugs.python.org  Thu Apr 14 12:03:16 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 14 Apr 2016 16:03:16 +0000
Subject: [issue26758] Unnecessary format string handling for no argument slot
 wrappers in typeobject.c
Message-ID: <1460649796.07.0.143785441525.issue26758@psf.upfronthosting.co.za>


New submission from Josh Rosenberg:

Right now, in typeobject.c, the call_method and call_maybe utility functions have a fast path for no argument methods, where a NULL or "" format string just calls PyTuple_New(0) directly instead of wasting time parsing Py_VaBuildValue.

Problem is, nothing uses it. Every no arg user (the slot wrappers for __len__, __index__ and __next__ directly, and indirectly through the SLOT0 macro for __neg__, __pos__, __abs__, __invert__, __int__ and __float__) is passing along "()" as the format string, which fails the test for NULL/"", so it calls Py_VaBuildValue that goes to an awful lot of trouble to scan the string a few times and eventually spit out the empty tuple anyway.

Changing the three direct calls to call_method where it passes "()" as the format string, as well as the definition of SLOT0, to replace "()" with NULL as the format string argument should remove a non-trivial number of C varargs function calls and string processing, replacing it with a single, cheap PyTuple_New(0) call (which Py_VaBuildValue was already eventually performing anyway). If I understand the purpose of these slot wrapper functions, that should give a free speed up to all types implemented at the Python level, particularly numeric types (e.g. fractions.Fraction) and container/iterator types (speeding up __len__ and __next__ respectively).

I identified this while on a work machine which I can't use to check out the Python repository; I'll submit a patch later today if no one else gets to it, once I'm home and can use my own computer to make/test the fix.

----------
components: Interpreter Core
messages: 263419
nosy: josh.r
priority: normal
severity: normal
status: open
title: Unnecessary format string handling for no argument slot wrappers in typeobject.c
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26758>
_______________________________________

From report at bugs.python.org  Thu Apr 14 12:07:26 2016
From: report at bugs.python.org (Mike Pomraning)
Date: Thu, 14 Apr 2016 16:07:26 +0000
Subject: [issue25942] subprocess.call SIGKILLs too liberally
In-Reply-To: <1451006108.23.0.113868196098.issue25942@psf.upfronthosting.co.za>
Message-ID: <1460650046.04.0.301084293306.issue25942@psf.upfronthosting.co.za>


Mike Pomraning added the comment:

#2 and #4 are the only predictable and palatable options, I think.  Ignore the patch that started this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25942>
_______________________________________

From report at bugs.python.org  Thu Apr 14 12:20:47 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 14 Apr 2016 16:20:47 +0000
Subject: [issue26758] Unnecessary format string handling for no argument slot
 wrappers in typeobject.c
In-Reply-To: <1460649796.07.0.143785441525.issue26758@psf.upfronthosting.co.za>
Message-ID: <1460650847.94.0.206595136874.issue26758@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +serhiy.storchaka
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26758>
_______________________________________

From report at bugs.python.org  Thu Apr 14 12:30:54 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 14 Apr 2016 16:30:54 +0000
Subject: [issue26756] fileinput handling of unicode errors from standard input
In-Reply-To: <1460644347.16.0.552330506095.issue26756@psf.upfronthosting.co.za>
Message-ID: <1460651454.3.0.873279812536.issue26756@psf.upfronthosting.co.za>


SilentGhost added the comment:

While documentation seems not entirely clear, the openhook only applies to files.

I'm not sure what is the logic behind the suggested change, what would openhook do in your situation?

----------
components: +Library (Lib)
nosy: +SilentGhost, serhiy.storchaka
versions: +Python 3.5, Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26756>
_______________________________________

From report at bugs.python.org  Thu Apr 14 13:46:44 2016
From: report at bugs.python.org (Joel Barry)
Date: Thu, 14 Apr 2016 17:46:44 +0000
Subject: [issue26756] fileinput handling of unicode errors from standard input
In-Reply-To: <1460644347.16.0.552330506095.issue26756@psf.upfronthosting.co.za>
Message-ID: <1460656004.78.0.852919938376.issue26756@psf.upfronthosting.co.za>


Joel Barry added the comment:

I was suggesting that the openhook could somehow be applied to a
*reopening* of sys.stdin.  Something like this:

326c326,329
<                     self._file = sys.stdin
---
>                     if self._openhook:
>                         self._file = self._openhook(self._filename, self._mode)
>                     else:
>                         self._file = sys.stdin

But this won't work because self._filename here is '<stdin>' which
isn't a real filename.  In conjunction with a change to my hook:

   def hook(filename, mode):
       if filename == '<stdin>':
           return io.TextIOWrapper(sys.stdin.buffer, errors='replace')
       return open(filename, mode, errors='replace')

things would work, but this is a bit awkward.

This works for me without changing my hook:

326c326,329
<                     self._file = sys.stdin
---
>                     if self._openhook:
>                         self._file = self._openhook('/dev/stdin', self._mode)
>                     else:
>                         self._file = sys.stdin

but I realize that using /dev/stdin is not portable.

The desired outcome is really just to control Unicode behavior from
stdin, not necessary the ability to provide a generic hook.  Adding an
'errors' keyword to apply to stdin would solve my case, but if you
open up 'errors', someone may also want 'encoding', and the others,
which is why it would be nicer if this could somehow be solved with
the existing openhook interface.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26756>
_______________________________________

From report at bugs.python.org  Thu Apr 14 14:13:43 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Apr 2016 18:13:43 +0000
Subject: [issue26759] PyBytes_FromObject accepts arbitrary iterable
Message-ID: <1460657623.47.0.29764231335.issue26759@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

PyBytes_FromObject creates a bytes object from an object that implements the buffer or the iterable protocol. But only using the buffer protocol is documented.

We should either document the current behavior (the documentation of int.from_bytes() can be used as a sample), or change the behavior to match the documentation.

For now PyBytes_FromObject() is used in the stdlib only for converting FS paths to str (besides using internally in bytes). When called from PyUnicode_FSDecoder(), this leads to accepting arbitrary iterables as filenames, that looks at leas strange (issue26754). In the posix module it is called only for objects that support the buffer protocol.

Thus the support of the iterable protocol is not used or misused in the stdlib. I don't know if it is used correctly in third party code, I suspect that this is rather misused. Note that there is alternative API function PyObject_Bytes(), that accepts same arguments as the bytes() constructor, except an integer, and supports the buffer protocol, the iterable protocol, and in additional supports the __bytes__() special method.

----------
messages: 263423
nosy: haypo, martin.panter, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: PyBytes_FromObject accepts arbitrary iterable
type: behavior
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26759>
_______________________________________

From report at bugs.python.org  Thu Apr 14 14:26:28 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 14 Apr 2016 18:26:28 +0000
Subject: [issue26760] Document PyFrameObject
Message-ID: <1460658388.85.0.590056164506.issue26760@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Can be as simple as https://docs.python.org/3/c-api/code.html#c.PyCodeObject . Key point is to have it in the index so people don't wonder what the deal is with the type when noticing it as a parameter to a function.

----------
assignee: brett.cannon
components: Documentation
messages: 263424
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Document PyFrameObject
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26760>
_______________________________________

From report at bugs.python.org  Thu Apr 14 14:29:35 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Apr 2016 18:29:35 +0000
Subject: [issue26759] PyBytes_FromObject accepts arbitrary iterable
In-Reply-To: <1460657623.47.0.29764231335.issue26759@psf.upfronthosting.co.za>
Message-ID: <1460658575.52.0.327148701143.issue26759@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Note that there is alternative API function PyObject_Bytes(), that accepts same arguments as the bytes() constructor, except an integer, and supports the buffer protocol, the iterable protocol, and in additional supports the __bytes__() special method.

That's a good point. Then I think PyBytes_FromObject() should be restricted. Also the docs for these functions should probably mention each other.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26759>
_______________________________________

From report at bugs.python.org  Thu Apr 14 14:45:51 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Apr 2016 18:45:51 +0000
Subject: [issue26759] PyBytes_FromObject accepts arbitrary iterable
In-Reply-To: <1460657623.47.0.29764231335.issue26759@psf.upfronthosting.co.za>
Message-ID: <1460659551.12.0.555289176922.issue26759@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Other *_FromObject public API functions:

PyUnicode_FromObject() -- Very strict. Accepts only str subclasses.
PyByteArray_FromObject() -- Very lenient! Calls the bytearray() constructor, accepts even an integer!
PyMemoryView_FromObject() -- No surprises. Accepts only objects that support the buffer protocol.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26759>
_______________________________________

From report at bugs.python.org  Thu Apr 14 14:48:19 2016
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 14 Apr 2016 18:48:19 +0000
Subject: [issue26755] Update version{added,changed} docs in devguide
In-Reply-To: <1460626724.97.0.188358038821.issue26755@psf.upfronthosting.co.za>
Message-ID: <1460659699.4.0.144520322751.issue26755@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Now that "added" doesn't mention the second argument, the "This one *must* have the second argument (explanation of the change)." should be changed. Otherwise +1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26755>
_______________________________________

From report at bugs.python.org  Thu Apr 14 14:52:00 2016
From: report at bugs.python.org (Raghu)
Date: Thu, 14 Apr 2016 18:52:00 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460659920.79.0.118853094222.issue26743@psf.upfronthosting.co.za>


Raghu added the comment:

Hi, This is my work system and I don't know if I am allowed to send out the complete output of "print sysconfig.get_config_vars()". could you please let me know which fields you are looking for?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Thu Apr 14 15:13:56 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Apr 2016 19:13:56 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460661236.8.0.473228664514.issue26743@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Fields with ENDIAN or IEEE in key.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Thu Apr 14 17:00:43 2016
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 14 Apr 2016 21:00:43 +0000
Subject: [issue26748] enum.Enum is False-y
In-Reply-To: <1460568121.51.0.847598758945.issue26748@psf.upfronthosting.co.za>
Message-ID: <1460667643.09.0.740209731739.issue26748@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Enum classes are now Truth-y in 3.4, 3.5, enum34, and aenum.  :)

----------
assignee:  -> ethan.furman
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26748>
_______________________________________

From report at bugs.python.org  Thu Apr 14 18:18:56 2016
From: report at bugs.python.org (Raghu)
Date: Thu, 14 Apr 2016 22:18:56 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460672336.49.0.195696141068.issue26743@psf.upfronthosting.co.za>


Raghu added the comment:

The keys ENDIAN and IEEE are not available.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Thu Apr 14 18:26:41 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Apr 2016 22:26:41 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460672801.67.0.216580113793.issue26743@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I guess that Serhiy is looking for these variables defined in pyconfig.h:
---
/* Define if C doubles are 64-bit IEEE 754 binary format, stored in ARM
   mixed-endian order (byte order 45670123) */
#undef DOUBLE_IS_ARM_MIXED_ENDIAN_IEEE754

/* Define if C doubles are 64-bit IEEE 754 binary format, stored with the most
   significant byte first */
#undef DOUBLE_IS_BIG_ENDIAN_IEEE754

/* Define if C doubles are 64-bit IEEE 754 binary format, stored with the
   least significant byte first */
#undef DOUBLE_IS_LITTLE_ENDIAN_IEEE754
---

On Fedora, pyconfig.h is installed into /usr/include/python2.7/pyconfig.h. This file doesn't contain any sensitive information, it is the configuration used to build Python.

On Fedora, this file only dispatches between pyconfig-32.h and pyconfig-64.h:
---
$ cat /usr/include/python2.7/pyconfig.h 
#include <bits/wordsize.h>

#if __WORDSIZE == 32
#include "pyconfig-32.h"
#elif __WORDSIZE == 64
#include "pyconfig-64.h"
#else
#error "Unknown word size"
#endif
---

My system is 64-bit, so I can use pyconfig-64.h:
---
$ grep IEEE /usr/include/python2.7/pyconfig-64.h 
/* Define if C doubles are 64-bit IEEE 754 binary format, stored in ARM
/* #undef DOUBLE_IS_ARM_MIXED_ENDIAN_IEEE754 */
/* Define if C doubles are 64-bit IEEE 754 binary format, stored with the most
/* #undef DOUBLE_IS_BIG_ENDIAN_IEEE754 */
/* Define if C doubles are 64-bit IEEE 754 binary format, stored with the
#define DOUBLE_IS_LITTLE_ENDIAN_IEEE754 1
/* #undef HAVE_IEEEFP_H */
/* #undef HAVE_LIBIEEE */
/* Define to activate features from IEEE Stds 1003.1-2001 */
---

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Thu Apr 14 19:11:24 2016
From: report at bugs.python.org (Raghu)
Date: Thu, 14 Apr 2016 23:11:24 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460675484.57.0.691119507888.issue26743@psf.upfronthosting.co.za>


Raghu added the comment:

Here is one output:

root at fpc0:~# grep IEEE /usr/include/python2.7/pyconfig-32.h
/* Define if C doubles are 64-bit IEEE 754 binary format, stored in ARM
/* #undef DOUBLE_IS_ARM_MIXED_ENDIAN_IEEE754 */
/* Define if C doubles are 64-bit IEEE 754 binary format, stored with the most
/* #undef DOUBLE_IS_BIG_ENDIAN_IEEE754 */
/* Define if C doubles are 64-bit IEEE 754 binary format, stored with the
/* #undef DOUBLE_IS_LITTLE_ENDIAN_IEEE754 */
/* #undef HAVE_IEEEFP_H */
/* #undef HAVE_LIBIEEE */
/* Define to activate features from IEEE Stds 1003.1-2001 */
root at fpc0:~#

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Thu Apr 14 19:24:15 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 14 Apr 2016 23:24:15 +0000
Subject: [issue26638] Avoid warnings about missing CLI options when building
 documentation
In-Reply-To: <1458881380.09.0.599104229044.issue26638@psf.upfronthosting.co.za>
Message-ID: <1460676255.19.0.526689084285.issue26638@psf.upfronthosting.co.za>


Martin Panter added the comment:

I?m not an expert on Sphinx. Maybe <http://www.sphinx-doc.org/en/stable/config.html#confval-suppress_warnings> could help with disabling these warnings. Considering there are so many false positives, it might be best to disable the warning. Though my patch does have a few genuine improvements as well.

I already used the :option:`-Wd <-W>` syntax in some cases; see Doc/library/warnings.rst for example. The problem in unittest.rst is I think Sphinx is trying to find a -W option defined within unittest.rst (with the unittest --buffer etc options), rather than the main Python options from using/cmdline.rst.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26638>
_______________________________________

From report at bugs.python.org  Thu Apr 14 19:28:55 2016
From: report at bugs.python.org (Raghu)
Date: Thu, 14 Apr 2016 23:28:55 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460676535.4.0.73816514278.issue26743@psf.upfronthosting.co.za>


Raghu added the comment:

Couple more outputs:

----------------
/* Define WORDS_BIGENDIAN to 1 if your processor stores words with the most
   significant byte first (like Motorola and SPARC, unlike Intel). */
#if defined AC_APPLE_UNIVERSAL_BUILD
# if defined __BIG_ENDIAN__
#  define WORDS_BIGENDIAN 1
# endif
#else
# ifndef WORDS_BIGENDIAN
#  define WORDS_BIGENDIAN 1
# endif
#endif
----------------

Math works in some cases.
----------------
>>> import math
>>> math.sqrt(2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: math domain error
>>> math.floor(2.5)
2.0
>>>
----------------


Also, could you please let me know the train of thought and ask for all the outputs as much as possible in one go? because I feel like I am delaying your debugging.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Thu Apr 14 19:39:07 2016
From: report at bugs.python.org (Raghu)
Date: Thu, 14 Apr 2016 23:39:07 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460677147.02.0.313324127607.issue26743@psf.upfronthosting.co.za>


Raghu added the comment:

@stinner, my host doesn't have internet connection and it doesn't have gcc installed.

I don't know how to install gcc in windriverlinux.
In famous linux distributions like ubuntu and centos, i install gcc using 'yum install gcc' or 'apt-get install gcc' commands.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Thu Apr 14 19:43:40 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 14 Apr 2016 23:43:40 +0000
Subject: [issue19985] Not so correct error message when initializing Struct
 with ill argument
In-Reply-To: <1387099730.06.0.788825958744.issue19985@psf.upfronthosting.co.za>
Message-ID: <1460677420.52.0.832266307064.issue19985@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
dependencies: +Not so correct error message when initializing Struct with ill argument

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19985>
_______________________________________

From report at bugs.python.org  Thu Apr 14 20:51:00 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 15 Apr 2016 00:51:00 +0000
Subject: [issue26721] Avoid socketserver.StreamRequestHandler.wfile doing
 partial writes
In-Reply-To: <1460204395.72.0.250418211057.issue26721@psf.upfronthosting.co.za>
Message-ID: <1460681460.12.0.489036747738.issue26721@psf.upfronthosting.co.za>


Martin Panter added the comment:

If a user calls makefile(bufsize=0), they may have written that based on Python 2?s behaviour of always doing full writes. But in Python 3 this is indirectly documented as doing partial writes: makefile() args interpreted as for open, and open() buffering disabled returns a RawIOBase subclass.

People porting code from Python 2 may be unprepared for partial writes. Just another subtle Python 2 vs 3 incompatibility. People using only Python 3 might be unprepared if they are not familar with the intricacies of the Python API, but then why are they using bufsize=0? On the other hand, they might require partial writes if they are using select() or similar, so changing it would be a compatibility problem.

You could use the same arguments for socketserver. The difference is that wfile being in raw mode is not documented. Almost all of the relevant builtin library code that I reviewed expects full blocking writes, and I did not find any that requires partial writes. So I think making the change in socketserver is less likely to introduce compatibility problems, and is much more beneficial.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26721>
_______________________________________

From report at bugs.python.org  Thu Apr 14 23:29:55 2016
From: report at bugs.python.org (Ganning Liu)
Date: Fri, 15 Apr 2016 03:29:55 +0000
Subject: [issue26761] winsound module very unstable in Windows 10
Message-ID: <1460690995.69.0.897655850655.issue26761@psf.upfronthosting.co.za>


New submission from Ganning Liu:

Cannot using winsound.Beep?? in .py file (run as module), get error information like:

Traceback (most recent call last):
  File "C:\Users\liuga\Desktop\sound.py", line 2, in <module>
    winsound.Beep(230,200)
AttributeError: module 'winsound' has no attribute 'Beep'

And also failed in interactive shell occasionally.

----------
components: Extension Modules
messages: 263438
nosy: Ganning Liu
priority: normal
severity: normal
status: open
title: winsound module very unstable in Windows 10
type: compile error
versions: Python 2.7, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26761>
_______________________________________

From report at bugs.python.org  Thu Apr 14 23:35:29 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Apr 2016 03:35:29 +0000
Subject: [issue15984] Wrong documentation for PyUnicode_FromObject() and
 PyUnicode_FromEncodedObject()
In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za>
Message-ID: <20160415033526.19501.75844.A3387E72@psf.io>


Roundup Robot added the comment:

New changeset af655e73f7bd by Martin Panter in branch '3.5':
Issue #15984: Correct PyUnicode_FromObject() and _FromEncodedObject() docs
https://hg.python.org/cpython/rev/af655e73f7bd

New changeset 570ada02d0f0 by Martin Panter in branch 'default':
Issue #15984: Merge PyUnicode doc from 3.5
https://hg.python.org/cpython/rev/570ada02d0f0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15984>
_______________________________________

From report at bugs.python.org  Thu Apr 14 23:41:08 2016
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 15 Apr 2016 03:41:08 +0000
Subject: [issue26761] winsound module very unstable in Windows 10
In-Reply-To: <1460690995.69.0.897655850655.issue26761@psf.upfronthosting.co.za>
Message-ID: <1460691668.79.0.399482125319.issue26761@psf.upfronthosting.co.za>


Zachary Ware added the comment:

This looks very like a case of shadowing a standard library module.  Just before your call to Beep(), try "print(winsound.__file__)".  If it's not "C:\SomePathToPython\DLLs\winsound.pyd" (with an appropriate real path in place of "SomePathToPython"), it's the path of the file that you should rename to something other than "winsound.py".

----------
nosy: +zach.ware
resolution:  -> not a bug
status: open -> pending
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26761>
_______________________________________

From report at bugs.python.org  Fri Apr 15 00:00:33 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 15 Apr 2016 04:00:33 +0000
Subject: [issue19985] Not so correct error message when initializing Struct
 with ill argument
In-Reply-To: <1387099730.06.0.788825958744.issue19985@psf.upfronthosting.co.za>
Message-ID: <1460692833.6.0.0103186257796.issue19985@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
dependencies: +Document whether it's safe to use bytes for struct format string -Not so correct error message when initializing Struct with ill argument

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19985>
_______________________________________

From report at bugs.python.org  Fri Apr 15 00:01:20 2016
From: report at bugs.python.org (Tim Peters)
Date: Fri, 15 Apr 2016 04:01:20 +0000
Subject: [issue26753] Obmalloc lock LOCK_INIT and LOCK_FINI are never used
In-Reply-To: <1460620546.75.0.247903713074.issue26753@psf.upfronthosting.co.za>
Message-ID: <1460692880.0.0.494689151414.issue26753@psf.upfronthosting.co.za>


Tim Peters added the comment:

Right, these macros were in the original module (by Vladimir Marangozov).  They've never done anything - never been tested.  Over the years I removed other layers of macro indirection (while other people added more ;-) ), but left these alone because they point out at least some speed-crucial places where "removing the GIL" would add new costs.

That said, I wouldn't object if you removed all the lock-related macros in obmalloc.  The code is hairier now than it was at the start, so throwing out unused cruft is also more valuable now than it was at the start.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26753>
_______________________________________

From report at bugs.python.org  Fri Apr 15 00:04:25 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 15 Apr 2016 04:04:25 +0000
Subject: [issue26762] test_multiprocessing_spawn leaves processes running in
 background
Message-ID: <1460693065.24.0.946570360611.issue26762@psf.upfronthosting.co.za>


New submission from Martin Panter:

I noticed that this test leaves processes running in the background for a moment after the parent Python process exits. They disappear pretty quickly, but even so, it seems like a bad design. However I am not familiar with the multiprocessing module, so maybe this is unavoidable.

$ ps
  PID TTY          TIME CMD
  597 pts/2    00:00:01 bash
13423 pts/2    00:00:00 ps
$ python3.5 -m test test_multiprocessing_spawn; ps
[1/1] test_multiprocessing_spawn
1 test OK.
  PID TTY          TIME CMD
  597 pts/2    00:00:01 bash
13429 pts/2    00:00:00 python3.5
13475 pts/2    00:00:00 python3.5
15066 pts/2    00:00:00 ps

----------
components: Tests
messages: 263442
nosy: martin.panter
priority: normal
severity: normal
status: open
title: test_multiprocessing_spawn leaves processes running in background
type: behavior
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26762>
_______________________________________

From report at bugs.python.org  Fri Apr 15 00:06:05 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 15 Apr 2016 04:06:05 +0000
Subject: [issue26762] test_multiprocessing_spawn leaves processes running in
 background
In-Reply-To: <1460693065.24.0.946570360611.issue26762@psf.upfronthosting.co.za>
Message-ID: <1460693165.81.0.849172222316.issue26762@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +davin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26762>
_______________________________________

From report at bugs.python.org  Fri Apr 15 00:29:13 2016
From: report at bugs.python.org (Ganning Liu)
Date: Fri, 15 Apr 2016 04:29:13 +0000
Subject: [issue26761] winsound module very unstable in Windows 10
In-Reply-To: <1460690995.69.0.897655850655.issue26761@psf.upfronthosting.co.za>
Message-ID: <1460694553.44.0.0199007137014.issue26761@psf.upfronthosting.co.za>


Ganning Liu added the comment:

Thanks Zachary, it's not a bug!

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26761>
_______________________________________

From report at bugs.python.org  Fri Apr 15 00:36:06 2016
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 15 Apr 2016 04:36:06 +0000
Subject: [issue26761] winsound module very unstable in Windows 10
In-Reply-To: <1460690995.69.0.897655850655.issue26761@psf.upfronthosting.co.za>
Message-ID: <1460694966.71.0.603907670721.issue26761@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Glad I could guide you to a solution :)

----------
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26761>
_______________________________________

From report at bugs.python.org  Fri Apr 15 00:47:02 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 15 Apr 2016 04:47:02 +0000
Subject: [issue26535] Minor typo in the docs for struct.unpack
In-Reply-To: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za>
Message-ID: <1460695622.75.0.960628481469.issue26535@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a new patch:

* Use ?The buffer?s size in bytes? wording
* Avoid brackets inside brackets
* Fix the three unpack functions and corresponding methods
* Also fix doc strings

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26535>
_______________________________________

From report at bugs.python.org  Fri Apr 15 00:48:08 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 15 Apr 2016 04:48:08 +0000
Subject: [issue15984] Wrong documentation for PyUnicode_FromObject() and
 PyUnicode_FromEncodedObject()
In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za>
Message-ID: <1460695688.61.0.284052822161.issue15984@psf.upfronthosting.co.za>


Martin Panter added the comment:

I also tweaked the PyUnicode_FromEncodedObject() documentation to avoid the word ?coerce? and to fix up outdated stuff.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15984>
_______________________________________

From report at bugs.python.org  Fri Apr 15 00:50:25 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 15 Apr 2016 04:50:25 +0000
Subject: [issue25654] test_multiprocessing_spawn ResourceWarning with -Werror
In-Reply-To: <1447830828.22.0.981390741581.issue25654@psf.upfronthosting.co.za>
Message-ID: <1460695825.24.0.330214802509.issue25654@psf.upfronthosting.co.za>


Martin Panter added the comment:

Opened Issue 26762 about the leftover processes.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25654>
_______________________________________

From report at bugs.python.org  Fri Apr 15 01:06:02 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 15 Apr 2016 05:06:02 +0000
Subject: [issue26757] test_urllib2net.test_http_basic() timeout after 15 min on
In-Reply-To: <1460645592.51.0.660228574975.issue26757@psf.upfronthosting.co.za>
Message-ID: <1460696762.33.0.0906029314306.issue26757@psf.upfronthosting.co.za>


Martin Panter added the comment:

By ?mock the query?, do you mean swap out the socket for a pretend socket object? Another option would be to connect to a server on localhost running on the background, like I did for the fileno() problem.

Looks like this test_http_basic() was intended to verify that no timeout was being used by default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26757>
_______________________________________

From report at bugs.python.org  Fri Apr 15 01:30:19 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 15 Apr 2016 05:30:19 +0000
Subject: [issue26745] Redundant code in _PyObject_GenericSetAttrWithDict
In-Reply-To: <1460515034.42.0.500786155919.issue26745@psf.upfronthosting.co.za>
Message-ID: <1460698219.89.0.928645163546.issue26745@psf.upfronthosting.co.za>


Martin Panter added the comment:

This code mirrors code in the Get function, but that function inspects tp_descr_get (not set) instead. As I understand it, this is the difference between ?data? descriptors and ?non-data? descriptors. So I think the change is okay.

----------
nosy: +martin.panter
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26745>
_______________________________________

From report at bugs.python.org  Fri Apr 15 01:42:26 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Apr 2016 05:42:26 +0000
Subject: [issue26535] Minor typo in the docs for struct.unpack
In-Reply-To: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za>
Message-ID: <1460698946.43.0.543327208905.issue26535@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Seems you forgot to send a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26535>
_______________________________________

From report at bugs.python.org  Fri Apr 15 01:48:25 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Apr 2016 05:48:25 +0000
Subject: [issue26762] test_multiprocessing_spawn leaves processes running in
 background
In-Reply-To: <1460693065.24.0.946570360611.issue26762@psf.upfronthosting.co.za>
Message-ID: <1460699305.66.0.252382632299.issue26762@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +haypo, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26762>
_______________________________________

From report at bugs.python.org  Fri Apr 15 02:00:59 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 15 Apr 2016 06:00:59 +0000
Subject: [issue26535] Minor typo in the docs for struct.unpack
In-Reply-To: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za>
Message-ID: <1460700059.6.0.277401820251.issue26535@psf.upfronthosting.co.za>


Martin Panter added the comment:

Indeed, let me try again

----------
Added file: http://bugs.python.org/file42462/struct-size.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26535>
_______________________________________

From report at bugs.python.org  Fri Apr 15 02:47:27 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 15 Apr 2016 06:47:27 +0000
Subject: [issue26359] CPython build options for out-of-the box performance
In-Reply-To: <1455445693.01.0.984013993837.issue26359@psf.upfronthosting.co.za>
Message-ID: <1460702847.05.0.0863973389586.issue26359@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

--with-optimizations seems fine.

As does having the final thing the Makefile prints out when run from a configuration that did not specify any of --with-pgo, --with-lto, --with-pydebug, or --with-optimizations be to echo message reminding people to configure --with-optimizations when making a release build.

The default "./configure && make" target needs to remain optimized for CPython developer speed.  Not release builds.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26359>
_______________________________________

From report at bugs.python.org  Fri Apr 15 03:06:00 2016
From: report at bugs.python.org (Ian Lee)
Date: Fri, 15 Apr 2016 07:06:00 +0000
Subject: [issue26763] Update PEP-8 regarding binary operators
Message-ID: <1460703960.6.0.758787970043.issue26763@psf.upfronthosting.co.za>


New submission from Ian Lee:

Following up from discussion on python-ideas [1] about updating PEP-8 regarding wrapping lines before rather than after binary operators.

----------
files: wrap-before-binary-operator.patch
keywords: patch
messages: 263453
nosy: IanLee1521, gvanrossum
priority: normal
severity: normal
status: open
title: Update PEP-8 regarding binary operators
type: enhancement
Added file: http://bugs.python.org/file42463/wrap-before-binary-operator.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26763>
_______________________________________

From report at bugs.python.org  Fri Apr 15 03:09:45 2016
From: report at bugs.python.org (Ian Lee)
Date: Fri, 15 Apr 2016 07:09:45 +0000
Subject: [issue26763] Update PEP-8 regarding binary operators
In-Reply-To: <1460703960.6.0.758787970043.issue26763@psf.upfronthosting.co.za>
Message-ID: <1460704185.07.0.908339318845.issue26763@psf.upfronthosting.co.za>


Ian Lee added the comment:

Discussion link missing from msg263453: https://mail.python.org/pipermail/python-ideas/2016-April/039774.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26763>
_______________________________________

From report at bugs.python.org  Fri Apr 15 03:23:58 2016
From: report at bugs.python.org (Ian Lee)
Date: Fri, 15 Apr 2016 07:23:58 +0000
Subject: [issue26763] Update PEP-8 regarding binary operators
In-Reply-To: <1460703960.6.0.758787970043.issue26763@psf.upfronthosting.co.za>
Message-ID: <1460705038.75.0.23579452109.issue26763@psf.upfronthosting.co.za>


Ian Lee added the comment:

Link to GitHub branch with the patch as a commit [1].

[1] https://github.com/python/peps/compare/master...IanLee1521:issue26763

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26763>
_______________________________________

From report at bugs.python.org  Fri Apr 15 03:24:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Apr 2016 07:24:46 +0000
Subject: [issue26535] Minor typo in the docs for struct.unpack
In-Reply-To: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za>
Message-ID: <1460705086.43.0.894288003478.issue26535@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
assignee: docs at python -> martin.panter
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26535>
_______________________________________

From report at bugs.python.org  Fri Apr 15 03:28:02 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Apr 2016 07:28:02 +0000
Subject: [issue26764] SystemError in bytes.__rmod__
Message-ID: <1460705282.56.0.272877366519.issue26764@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

>>> [] % b''
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Objects/bytesobject.c:2975: bad argument to internal function

Proposed patch fixes bytes.__rmod__ and tests for bytes formatting.

----------
components: Interpreter Core
files: bytes_rmod.patch
keywords: patch
messages: 263457
nosy: ethan.furman, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: SystemError in bytes.__rmod__
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42464/bytes_rmod.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26764>
_______________________________________

From report at bugs.python.org  Fri Apr 15 03:35:44 2016
From: report at bugs.python.org (Chris Angelico)
Date: Fri, 15 Apr 2016 07:35:44 +0000
Subject: [issue26763] Update PEP-8 regarding binary operators
In-Reply-To: <1460703960.6.0.758787970043.issue26763@psf.upfronthosting.co.za>
Message-ID: <1460705744.35.0.336761775118.issue26763@psf.upfronthosting.co.za>


Changes by Chris Angelico <rosuav at gmail.com>:


----------
nosy: +Rosuav

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26763>
_______________________________________

From report at bugs.python.org  Fri Apr 15 04:05:59 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Apr 2016 08:05:59 +0000
Subject: [issue26765] Factor out common bytes and bytearray implementation
Message-ID: <1460707559.13.0.709090380773.issue26765@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch factors out the implementation of bytes and bytearray by moving common code in separate files. This is not new approach, the part of the code is already shared.

The patch decreases the size of the source code by 862 lines.

----------
components: Interpreter Core
files: bytes_methods.patch
keywords: patch
messages: 263458
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Factor out common bytes and bytearray implementation
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42465/bytes_methods.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26765>
_______________________________________

From report at bugs.python.org  Fri Apr 15 04:31:42 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Apr 2016 08:31:42 +0000
Subject: [issue25654] test_multiprocessing_spawn ResourceWarning with -Werror
In-Reply-To: <1460695825.24.0.330214802509.issue25654@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYQ0bzBZ4vSzG7Unb3bUdsYtupHpyXEpt6862-30jxhdg@mail.gmail.com>


STINNER Victor added the comment:

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25654>
_______________________________________

From report at bugs.python.org  Fri Apr 15 04:53:32 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Apr 2016 08:53:32 +0000
Subject: [issue26764] SystemError in bytes.__rmod__
In-Reply-To: <1460705282.56.0.272877366519.issue26764@psf.upfronthosting.co.za>
Message-ID: <1460710412.97.0.256184983501.issue26764@psf.upfronthosting.co.za>


STINNER Victor added the comment:

bytes_rmod.patch LGTM (maybe just a minor PEP 7 issue, see my review).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26764>
_______________________________________

From report at bugs.python.org  Fri Apr 15 05:06:37 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Apr 2016 09:06:37 +0000
Subject: [issue26762] test_multiprocessing_spawn leaves processes running in
 background
In-Reply-To: <1460693065.24.0.946570360611.issue26762@psf.upfronthosting.co.za>
Message-ID: <1460711197.72.0.0348456332697.issue26762@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Using this patch, I can see the list of "python" processes slowly growing:

diff -r ad5b079565ad Lib/unittest/case.py
--- a/Lib/unittest/case.py      Tue Apr 12 23:15:44 2016 -0700
+++ b/Lib/unittest/case.py      Fri Apr 15 11:06:07 2016 +0200
@@ -10,6 +10,7 @@ import warnings
 import collections
 import contextlib
 import traceback
+import os
 
 from . import result
 from .util import (strclass, safe_repr, _count_diff_all_purpose,
@@ -590,6 +591,7 @@ class TestCase(object):
         expecting_failure = expecting_failure_class or expecting_failure_method
         outcome = _Outcome(result)
         try:
+            os.system("ps")
             self._outcome = outcome
 
             with outcome.testPartExecutor(self):
@@ -614,6 +616,7 @@ class TestCase(object):
                         self._addUnexpectedSuccess(result)
                 else:
                     result.addSuccess(self)
+            os.system("ps")
             return result
         finally:
             result.stopTest(self)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26762>
_______________________________________

From report at bugs.python.org  Fri Apr 15 05:16:22 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 15 Apr 2016 09:16:22 +0000
Subject: [issue19444] mmap.mmap() allocates a file descriptor that isn't
 CLOEXEC
In-Reply-To: <1383110349.25.0.857290073089.issue19444@psf.upfronthosting.co.za>
Message-ID: <1460711782.69.0.0900196635336.issue19444@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
assignee: docs at python -> 
components:  -Documentation
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19444>
_______________________________________

From report at bugs.python.org  Fri Apr 15 05:43:21 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 15 Apr 2016 09:43:21 +0000
Subject: [issue26766] Redundant check in bytearray_mod
Message-ID: <1460713401.07.0.177357500269.issue26766@psf.upfronthosting.co.za>


New submission from Berker Peksag:

I noticed this while looking at issue 26764.

bytearray_mod() and bytearray_format() both have checks for PyByteArray_Check(v). The check in bytearray_format() looks redundant to me.

Here is a patch.

----------
components: Interpreter Core
files: bytearray_mod.diff
keywords: patch
messages: 263462
nosy: berker.peksag, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Redundant check in bytearray_mod
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42466/bytearray_mod.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26766>
_______________________________________

From report at bugs.python.org  Fri Apr 15 05:44:37 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Apr 2016 09:44:37 +0000
Subject: [issue26745] Redundant code in _PyObject_GenericSetAttrWithDict
In-Reply-To: <1460515034.42.0.500786155919.issue26745@psf.upfronthosting.co.za>
Message-ID: <1460713477.32.0.493835042052.issue26745@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM. But there are other redundant code in _PyObject_GenericSetAttrWithDict(). Here is a patch that makes larger refactoring.

----------
type:  -> enhancement
Added file: http://bugs.python.org/file42467/_PyObject_GenericSetAttrWithDict_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26745>
_______________________________________

From report at bugs.python.org  Fri Apr 15 06:10:32 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Apr 2016 10:10:32 +0000
Subject: [issue26767] Inconsistant error messages for failed attribute
 modification
Message-ID: <1460715032.51.0.36886496046.issue26767@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

>>> class I(int):
...     @property
...     def a(self): pass
...     @property
...     def b(self): pass
...     @b.setter
...     def b(self, value): pass
...     @property
...     def c(self): pass
...     @c.deleter
...     def c(self): pass
... 
>>> obj = I()
>>> del obj.numerator
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: attribute 'numerator' of 'int' objects is not writable
>>> del obj.to_bytes
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: to_bytes
>>> del obj.from_bytes
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: from_bytes
>>> del obj.a
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: can't delete attribute
>>> del obj.b
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: can't delete attribute
>>> del obj.y
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: y
>>> obj.numerator = 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: attribute 'numerator' of 'int' objects is not writable
>>> obj.a = 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: can't set attribute
>>> obj.c = 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: can't set attribute
>>> 
>>> obj = 1
>>> del obj.numerator
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: attribute 'numerator' of 'int' objects is not writable
>>> del obj.to_bytes
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'int' object attribute 'to_bytes' is read-only
>>> del obj.from_bytes
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'int' object attribute 'from_bytes' is read-only
>>> del obj.y
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'int' object has no attribute 'y'
>>> obj.numerator = 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: attribute 'numerator' of 'int' objects is not writable
>>> obj.to_bytes = 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'int' object attribute 'to_bytes' is read-only
>>> obj.from_bytes = 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'int' object attribute 'from_bytes' is read-only
>>> obj.y = 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'int' object has no attribute 'y'

Different error messages are used in errors when try to modify non-existing or read-only attribute. This depends on the existing __dict__ and the way how the attribute is resolved.

* just the attribute name
* "'%.50s' object has no attribute '%U'"
* "'%.50s' object attribute '%U' is read-only"
* "attribute '%V' of '%.100s' objects is not writable"

I think it would be nice to unify error messages and make them more specific.

----------
components: Interpreter Core
messages: 263464
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Inconsistant error messages for failed attribute modification
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26767>
_______________________________________

From report at bugs.python.org  Fri Apr 15 06:16:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Apr 2016 10:16:07 +0000
Subject: [issue26766] Redundant check in bytearray_mod
In-Reply-To: <1460713401.07.0.177357500269.issue26766@psf.upfronthosting.co.za>
Message-ID: <1460715367.16.0.778024350552.issue26766@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, I noticed this, but left for future (post-issue26765) refactoring.

The patch LGTM, but notice Victor's comment to issue26764.

----------
nosy: +ethan.furman, haypo
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26766>
_______________________________________

From report at bugs.python.org  Fri Apr 15 06:17:36 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Fri, 15 Apr 2016 10:17:36 +0000
Subject: [issue26359] CPython build options for out-of-the box performance
In-Reply-To: <1455445693.01.0.984013993837.issue26359@psf.upfronthosting.co.za>
Message-ID: <1460715456.31.0.0420878587124.issue26359@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

That sounds like a good idea and plan, to have everything enabled with just one dedicated configure flag.

I can work on this and post the patches as soon as they are done. 

Thank you

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26359>
_______________________________________

From report at bugs.python.org  Fri Apr 15 06:22:41 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 15 Apr 2016 10:22:41 +0000
Subject: [issue26745] Redundant code in _PyObject_GenericSetAttrWithDict
In-Reply-To: <1460515034.42.0.500786155919.issue26745@psf.upfronthosting.co.za>
Message-ID: <1460715761.85.0.0120245652386.issue26745@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

It's a better work. And the code looks simpler now. I test it with the test suite and none fails (though some tests are skipped due to platform).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26745>
_______________________________________

From report at bugs.python.org  Fri Apr 15 06:24:45 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Apr 2016 10:24:45 +0000
Subject: [issue26764] SystemError in bytes.__rmod__
In-Reply-To: <1460705282.56.0.272877366519.issue26764@psf.upfronthosting.co.za>
Message-ID: <1460715885.28.0.677081286676.issue26764@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Surprisingly the implementation in 3.5 is correct. But backporting tests exposed behavior change in bytearray formatting in 3.6. In 3.5 bytearray.__mod__ returns bytearray, in 3.6 it returns bytes. Is this intentional?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26764>
_______________________________________

From report at bugs.python.org  Fri Apr 15 06:36:14 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Apr 2016 10:36:14 +0000
Subject: [issue26766] Redundant check in bytearray_mod
In-Reply-To: <1460713401.07.0.177357500269.issue26766@psf.upfronthosting.co.za>
Message-ID: <1460716574.59.0.937040216005.issue26766@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

And may be bytearray_mod in 3.6 is not correct. In 3.5 it returns bytearray, in 3.6 it returns bytes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26766>
_______________________________________

From report at bugs.python.org  Fri Apr 15 06:37:05 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 15 Apr 2016 10:37:05 +0000
Subject: [issue26358] mmap.mmap.__iter__ is broken (yields bytes instead of
 ints)
In-Reply-To: <1455421066.19.0.307034706486.issue26358@psf.upfronthosting.co.za>
Message-ID: <1460716625.18.0.102124878111.issue26358@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I don't think we can change this in 3.5 since it would break backward compatibility.

> Similarly the `in` operator seems to be broken; one could search for space using `32 in bytesobj`, which would work for slices but not for the whole mmap object.

Seems a reasonable request to me. Could you please open a separate issue?

----------
components: +Extension Modules
nosy: +berker.peksag
priority: normal -> low
stage:  -> needs patch
type: behavior -> enhancement
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26358>
_______________________________________

From report at bugs.python.org  Fri Apr 15 06:47:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Apr 2016 10:47:22 +0000
Subject: [issue26358] mmap.mmap.__iter__ is broken (yields bytes instead of
 ints)
In-Reply-To: <1455421066.19.0.307034706486.issue26358@psf.upfronthosting.co.za>
Message-ID: <1460717242.01.0.91615310387.issue26358@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Iterating a slice produces ints too (a slice is just a bytes object).

>>> import mmap, sys
>>> with open(sys.executable, 'rb') as f:
...     mm = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
...     print(next(iter(mm)))
...     print(next(iter(mm[:10])))
... 
b'\x7f'
127

Seems this module taken little love when migrated to 3.0.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26358>
_______________________________________

From report at bugs.python.org  Fri Apr 15 07:14:44 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Apr 2016 11:14:44 +0000
Subject: [issue26764] SystemError in bytes.__rmod__
In-Reply-To: <1460705282.56.0.272877366519.issue26764@psf.upfronthosting.co.za>
Message-ID: <20160415111441.12745.41745.D7804336@psf.io>


Roundup Robot added the comment:

New changeset ebece99c0bb6 by Serhiy Storchaka in branch 'default':
Issue #26764: Fixed SystemError in bytes.__rmod__.
https://hg.python.org/cpython/rev/ebece99c0bb6

New changeset 8dee0c09b46e by Serhiy Storchaka in branch '3.5':
Issue #26764: Bacported tests for bytes formatting.
https://hg.python.org/cpython/rev/8dee0c09b46e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26764>
_______________________________________

From report at bugs.python.org  Fri Apr 15 07:19:01 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 15 Apr 2016 11:19:01 +0000
Subject: [issue26766] Redundant check in bytearray_mod
In-Reply-To: <1460713401.07.0.177357500269.issue26766@psf.upfronthosting.co.za>
Message-ID: <1460719141.15.0.796829070962.issue26766@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Do you have an example code? It returns bytearray for me in both 3.5 and 3.6. use_bytearray parameter of _PyBytes_FormatEx() is 1 in bytearray_mod().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26766>
_______________________________________

From report at bugs.python.org  Fri Apr 15 07:21:51 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Fri, 15 Apr 2016 11:21:51 +0000
Subject: [issue26768] Fix instructions at WindowsCompilers for MSVC/SDKs
Message-ID: <1460719311.17.0.00683602776456.issue26768@psf.upfronthosting.co.za>


New submission from Ivan Pozdeev:

Current instructions at https://wiki.python.org/moin/WindowsCompilers for a number of items are insufficient to make things work out of the box.
This has lead to widespread confusion and a lot of vastly different and invariably hacky/unreliable/unmaintainable "alternative" guides on the Net (see e.g. the sheer volume of crappy advice at http://stackoverflow.com/questions/2817869/error-unable-to-find-vcvarsall-bat and http://stackoverflow.com/questions/4676728/value-error-trying-to-install-python-for-windows-extensions).

The first patch fixes that for SDKs 6.1,7.0,7.1 (details are in the patch's Subject).
The second one mentions VS Express' limitation that leads to an obscure error in distutils which resulted in https://bugs.python.org/issue7511 .

Unlike other (all?) instructions circling around the Net, these are NOT hacks and are intended to be official recommendations.

I tested them to work with 2.7 and 3.2 on an x32 with no prior development tools installed. I also checked other instructions applicable to these versions to be okay.

I didn't touch the ''mingw'' section because, according to https://bugs.python.org/issue4709 , it can't really be officially supported as it is now.

----------
assignee: docs at python
components: Build, Documentation, Windows
files: 0001-fix-winsdk.patch
keywords: patch
messages: 263474
nosy: Ivan.Pozdeev, docs at python, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Fix instructions at WindowsCompilers for MSVC/SDKs
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file42468/0001-fix-winsdk.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26768>
_______________________________________

From report at bugs.python.org  Fri Apr 15 07:22:27 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Fri, 15 Apr 2016 11:22:27 +0000
Subject: [issue26768] Fix instructions at WindowsCompilers for MSVC/SDKs
In-Reply-To: <1460719311.17.0.00683602776456.issue26768@psf.upfronthosting.co.za>
Message-ID: <1460719347.53.0.494632829469.issue26768@psf.upfronthosting.co.za>


Changes by Ivan Pozdeev <ivan_pozdeev at mail.ru>:


Added file: http://bugs.python.org/file42469/0002-VS-Express.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26768>
_______________________________________

From report at bugs.python.org  Fri Apr 15 07:29:45 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Fri, 15 Apr 2016 11:29:45 +0000
Subject: [issue26768] Fix instructions at WindowsCompilers for MSVC/SDKs
In-Reply-To: <1460719311.17.0.00683602776456.issue26768@psf.upfronthosting.co.za>
Message-ID: <1460719785.89.0.268354949413.issue26768@psf.upfronthosting.co.za>


Ivan Pozdeev added the comment:

I preferred DISTUTILS_USE_SDK to MSSDK because the latter is a hack intended for private, advanced use rather than as the standard way: it makes distutils stop guessing and rely on the user to set the environment correctly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26768>
_______________________________________

From report at bugs.python.org  Fri Apr 15 07:33:44 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 15 Apr 2016 11:33:44 +0000
Subject: [issue26768] Fix instructions at WindowsCompilers for MSVC/SDKs
In-Reply-To: <1460719311.17.0.00683602776456.issue26768@psf.upfronthosting.co.za>
Message-ID: <1460720024.16.0.055491765901.issue26768@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the detailed report and for the patch, Ivan. But since https://wiki.python.org/moin/WindowsCompilers is a wiki document, you can edit it yourself. Please send an email to pydotorg-www at python.org with your account name. See https://wiki.python.org/moin/FrontPage#use for details.

----------
nosy: +berker.peksag
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26768>
_______________________________________

From report at bugs.python.org  Fri Apr 15 07:35:17 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Apr 2016 11:35:17 +0000
Subject: [issue26766] Redundant check in bytearray_mod
In-Reply-To: <1460713401.07.0.177357500269.issue26766@psf.upfronthosting.co.za>
Message-ID: <1460720117.44.0.80272395236.issue26766@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Python 3.5:

>>> bytearray(b'%d') % 42
bytearray(b'42')

Python 3.6:

>>> bytearray(b'%d') % 42
b'42'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26766>
_______________________________________

From report at bugs.python.org  Fri Apr 15 07:38:08 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 15 Apr 2016 11:38:08 +0000
Subject: [issue26745] Redundant code in _PyObject_GenericSetAttrWithDict
In-Reply-To: <1460515034.42.0.500786155919.issue26745@psf.upfronthosting.co.za>
Message-ID: <1460720288.15.0.299330738839.issue26745@psf.upfronthosting.co.za>


Martin Panter added the comment:

Serhiy?s version looks good to me

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26745>
_______________________________________

From report at bugs.python.org  Fri Apr 15 07:38:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Apr 2016 11:38:33 +0000
Subject: [issue26764] SystemError in bytes.__rmod__
In-Reply-To: <1460705282.56.0.272877366519.issue26764@psf.upfronthosting.co.za>
Message-ID: <1460720313.74.0.0580247744969.issue26764@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26764>
_______________________________________

From report at bugs.python.org  Fri Apr 15 07:44:59 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Apr 2016 11:44:59 +0000
Subject: [issue26745] Redundant code in _PyObject_GenericSetAttrWithDict
In-Reply-To: <1460515034.42.0.500786155919.issue26745@psf.upfronthosting.co.za>
Message-ID: <1460720699.25.0.843579195634.issue26745@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'll defer committing the patch until some progress in issue26767 will be reached. May be _PyObject_GenericSetAttrWithDict() will have to rewrite again.

----------
assignee:  -> serhiy.storchaka
priority: normal -> low
resolution:  -> remind
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26745>
_______________________________________

From report at bugs.python.org  Fri Apr 15 07:51:12 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Fri, 15 Apr 2016 11:51:12 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1460721072.89.0.951727923726.issue4709@psf.upfronthosting.co.za>


Ivan Pozdeev added the comment:

I know it's a wiki but I couldn't edit the page even after I registered, so I thought It's protected. I'll try the e-mail now.

----------
nosy: +Ivan.Pozdeev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4709>
_______________________________________

From report at bugs.python.org  Fri Apr 15 07:52:07 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Fri, 15 Apr 2016 11:52:07 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1460721127.71.0.444815676404.issue4709@psf.upfronthosting.co.za>


Ivan Pozdeev added the comment:

Whoops, wrong ticket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4709>
_______________________________________

From report at bugs.python.org  Fri Apr 15 07:53:42 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Fri, 15 Apr 2016 11:53:42 +0000
Subject: [issue26768] Fix instructions at WindowsCompilers for MSVC/SDKs
In-Reply-To: <1460719311.17.0.00683602776456.issue26768@psf.upfronthosting.co.za>
Message-ID: <1460721222.87.0.477775090445.issue26768@psf.upfronthosting.co.za>


Ivan Pozdeev added the comment:

I know it's a wiki. But this particular page is marked ImmutablePage and I couldn't edit it even after I registered, so I thought It's protected. I'll try the e-mail now.

----------
resolution: third party -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26768>
_______________________________________

From report at bugs.python.org  Fri Apr 15 07:54:20 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Fri, 15 Apr 2016 11:54:20 +0000
Subject: [issue26768] Fix instructions at WindowsCompilers for MSVC/SDKs
In-Reply-To: <1460719311.17.0.00683602776456.issue26768@psf.upfronthosting.co.za>
Message-ID: <1460721260.29.0.430419595087.issue26768@psf.upfronthosting.co.za>


Changes by Ivan Pozdeev <ivan_pozdeev at mail.ru>:


----------
resolution:  -> third party
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26768>
_______________________________________

From report at bugs.python.org  Fri Apr 15 07:55:44 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 15 Apr 2016 11:55:44 +0000
Subject: [issue20699] Document that binary IO classes work with bytes-likes
 objects
In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za>
Message-ID: <1460721344.46.0.383130391003.issue20699@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is an updated patch merged with recent changes. I also added a sentence to the RawIOBase.write() and BufferedIOBase.write() documentation about access to the buffer after the method returns. And I added tests for this.

----------
Added file: http://bugs.python.org/file42470/bytes-like-param.v5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20699>
_______________________________________

From report at bugs.python.org  Fri Apr 15 08:07:33 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Apr 2016 12:07:33 +0000
Subject: [issue26764] SystemError in bytes.__rmod__
In-Reply-To: <1460705282.56.0.272877366519.issue26764@psf.upfronthosting.co.za>
Message-ID: <1460722053.4.0.665582701671.issue26764@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Buildbots are unhappy.

http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.x/builds/3456/steps/test/logs/stdio

======================================================================
FAIL: test_imod (test.test_bytes.ByteArrayTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_bytes.py", line 507, in test_imod
    self.assertIs(type(b), bytes)
AssertionError: <class 'bytearray'> is not <class 'bytes'>

======================================================================
FAIL: test_mod (test.test_bytes.ByteArrayTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_bytes.py", line 495, in test_mod
    self.assertIs(type(a), bytes)
AssertionError: <class 'bytearray'> is not <class 'bytes'>

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26764>
_______________________________________

From report at bugs.python.org  Fri Apr 15 08:12:20 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 15 Apr 2016 12:12:20 +0000
Subject: [issue26766] Redundant check in bytearray_mod
In-Reply-To: <1460713401.07.0.177357500269.issue26766@psf.upfronthosting.co.za>
Message-ID: <1460722340.79.0.12958250349.issue26766@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks! More examples:

Python 3.6:

>>> bytearray(b'hello %b') % b"world"
bytearray(b'hello world')
>>> bytearray(b'hello %b') % b"wor"
b'hello wor'

Python 3.5:

>>> bytearray(b'hello %b') % b"world"
bytearray(b'hello world')
>>> bytearray(b'hello %b') % b"wor"
bytearray(b'hello wor')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26766>
_______________________________________

From report at bugs.python.org  Fri Apr 15 08:28:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Apr 2016 12:28:58 +0000
Subject: [issue26766] The result type of bytearray formatting is not stable
In-Reply-To: <1460713401.07.0.177357500269.issue26766@psf.upfronthosting.co.za>
Message-ID: <1460723338.61.0.914121845542.issue26766@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Hmm, looks the result type is very unstable.

On release build:

>>> bytearray(b'hello %b') % b"world"
b'hello world'
>>> bytearray(b'hello %b') % b"wor"
b'hello wor'

On debug build:

>>> bytearray(b'hello %b') % b"world"
bytearray(b'hello world')
>>> bytearray(b'hello %b') % b"wor"
b'hello wor'

And current test_bytes.py is passed on release build, but is failed on debug build.

----------
priority: normal -> high
stage: commit review -> 
title: Redundant check in bytearray_mod -> The result type of bytearray formatting is not stable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26766>
_______________________________________

From report at bugs.python.org  Fri Apr 15 08:29:15 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Apr 2016 12:29:15 +0000
Subject: [issue26766] The result type of bytearray formatting is not stable
In-Reply-To: <1460713401.07.0.177357500269.issue26766@psf.upfronthosting.co.za>
Message-ID: <1460723355.53.0.486700270939.issue26766@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
type: enhancement -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26766>
_______________________________________

From report at bugs.python.org  Fri Apr 15 08:30:01 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Apr 2016 12:30:01 +0000
Subject: [issue26764] SystemError in bytes.__rmod__
In-Reply-To: <1460705282.56.0.272877366519.issue26764@psf.upfronthosting.co.za>
Message-ID: <1460723401.28.0.956496934971.issue26764@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is a bug in bytearray formatting. See issue26766.

----------
dependencies: +The result type of bytearray formatting is not stable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26764>
_______________________________________

From report at bugs.python.org  Fri Apr 15 08:52:17 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 15 Apr 2016 12:52:17 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1460724737.78.0.287769076994.issue4709@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
Removed message: http://bugs.python.org/msg263480

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4709>
_______________________________________

From report at bugs.python.org  Fri Apr 15 08:52:23 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 15 Apr 2016 12:52:23 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1460724743.85.0.138005825395.issue4709@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
Removed message: http://bugs.python.org/msg263481

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4709>
_______________________________________

From report at bugs.python.org  Fri Apr 15 08:59:01 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Apr 2016 12:59:01 +0000
Subject: [issue26769] Python 2.7: make private file descriptors non inheritable
Message-ID: <1460725141.7.0.638632202912.issue26769@psf.upfronthosting.co.za>


New submission from STINNER Victor:

By default, subprocess.Popen doesn't close file descriptors (close_fds=False by default) and so a child process inherit all file descriptors open by the parent process. See the PEP 446 for the long rationale.

I propose to partially backport the PEP 446: only make *private* file descriptors non-inheritable. The private file descriptor of os.urandom() is already marked as non-inheritable.

To be clear: my patch doesn't affect applications using fork(). Only child processes created with fork+exec (ex: using subprocess) are impacted. Since modified file descriptors are private (not accessible from the Python scope), I don't think that the change can cause any backward compatibility issue.

I'm not 100% sure that it's worth to take the risk of introducing bugs (backward incompatible change?), since it looks like very few users complained of leaked file descriptors. I'm not sure that the modified functions contain sensitive file descriptors.

--

I chose to add Python/fileutils.c (and Include/fileutils.h) to add the new functions:

   /* Try to make the file descriptor non-inheritable. Ignore errors. */
   PyAPI_FUNC(void) _Py_try_set_non_inheritable(int fd);

   /* Wrapper to fopen() which tries to make the file non-inheritable on success.
      Ignore errors on trying to set the file descriptor non-inheritable. */
   PyAPI_FUNC(FILE*) _Py_fopen(const char *path, const char *mode);

I had to modify PCbuild/pythoncore.vcxproj and Makefile.pre.in to add fileutils.c/h. I chose to mimick Python 3 Python/fileutils.c. Tell me if you prefer to put the new functions in an existing file (I don't see where such function should be put).

File descriptors made non inheritable:

* linuxaudiodev.open()
* mmap.mmap(fd, 0): this function duplicates the file descriptor, the duplicated file descriptor is set to non-inheritable
* mmap.mmap(-1, ...): on platforms without MAP_ANONYMOUS, the function opens /dev/zero, its file descriptor is set to non-inheritable
* ossaudiodev.open()
* ossaudiodev.openmixer()
* select.epoll()
* select.kqueue()
* sunaudiodev.open()

Other functions using fopen() have been modified to use _Py_fopen(): the file is closed a few lines below and not returned to the Python scope.

The patch also reuses _Py_try_set_non_inheritable(fd) in Modules/posixmodule.c and Python/random.c.

Not modified:

* _hotshot: the file descriptor can get retrieved with _hotshot.ProfilerType.fileno().
* find_module() of Python/import.c: imp.find_module() uses the FILE* to create a Python file object which is returned

Note: I don't think that os.openpty() should be modified to limit the risk of breaking the backward compatibility.

This issue is a much more generic issue than the change #10897.

----------
files: set_inheritable.patch
keywords: patch
messages: 263488
nosy: benjamin.peterson, haypo, martin.panter, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Python 2.7: make private file descriptors non inheritable
type: resource usage
versions: Python 2.7
Added file: http://bugs.python.org/file42471/set_inheritable.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26769>
_______________________________________

From report at bugs.python.org  Fri Apr 15 09:05:07 2016
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 15 Apr 2016 13:05:07 +0000
Subject: [issue26763] Update PEP-8 regarding binary operators
In-Reply-To: <1460703960.6.0.758787970043.issue26763@psf.upfronthosting.co.za>
Message-ID: <1460725507.76.0.161428521106.issue26763@psf.upfronthosting.co.za>


INADA Naoki added the comment:

https://github.com/python/peps/compare/master...IanLee1521:issue26763

----------
nosy: +naoki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26763>
_______________________________________

From report at bugs.python.org  Fri Apr 15 09:07:54 2016
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 15 Apr 2016 13:07:54 +0000
Subject: [issue26763] Update PEP-8 regarding binary operators
In-Reply-To: <1460703960.6.0.758787970043.issue26763@psf.upfronthosting.co.za>
Message-ID: <1460725674.86.0.717556211715.issue26763@psf.upfronthosting.co.za>


INADA Naoki added the comment:

Roundup doesn't link to Github's branch comparing URL correctly.
How about just create pull request on Github?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26763>
_______________________________________

From report at bugs.python.org  Fri Apr 15 09:09:52 2016
From: report at bugs.python.org (Luiz Poleto)
Date: Fri, 15 Apr 2016 13:09:52 +0000
Subject: [issue20116] urlparse.parse_qs should take argument for query
 separator
In-Reply-To: <1388777959.1.0.144368039339.issue20116@psf.upfronthosting.co.za>
Message-ID: <1460725792.7.0.827381077499.issue20116@psf.upfronthosting.co.za>


Luiz Poleto added the comment:

If this bug is to be moved forward, we should consider this:

The RFC 3986 defines that a query can have any of these characters:
/?:@-._~!$&'()*+,;= ALPHA DIGIT %HH (encoded octet)

But does not define how the data should be interpreted, leaving that to the naming authority and the URI schema (although http/https doesn't specify it as well; see RFC 7230).

OTOH, parse_qs (both on 2.x and 3.x) is very specific that the query string is of type application/x-www-form-urlencoded; which defines that the name is separated from the value by '=' and name/value pairs are separated from each other by '&', although the use of ';' to separate the pairs is only suggested to be supported by HTTP server implementors.

It could be that adding support to the characters specified by RFC 3986 pose as a challenge since there is no fixed schema and they can be freely used by the naming authority so perhaps we could add a parameter to enable/disable ';' as a pair separator?

----------
nosy: +poleto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20116>
_______________________________________

From report at bugs.python.org  Fri Apr 15 09:10:43 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Apr 2016 13:10:43 +0000
Subject: [issue26766] The result type of bytearray formatting is not stable
In-Reply-To: <1460713401.07.0.177357500269.issue26766@psf.upfronthosting.co.za>
Message-ID: <1460725843.96.0.70297409499.issue26766@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It looks like a bug introduced by me in the issue #25399.

bytearray%args must return a bytearray object.

I understand that test_bytes lacks tests since it missed the bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26766>
_______________________________________

From report at bugs.python.org  Fri Apr 15 09:21:00 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Apr 2016 13:21:00 +0000
Subject: [issue26770] _Py_set_inheritable(): do nothing if the FD_CLOEXEC
 close is already set/cleared
Message-ID: <1460726460.32.0.344896145272.issue26770@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch is avoids a syscall in os.set_inheritable() if the FD_CLOEXEC flag is already set/cleared.

The change only impacts platforms using fcntl() in _Py_set_inheritable(). Windows has a different implementation, and Linux uses ioctl() for example.

The same "optimization" is used in socket.socket.setblocking(): see the issue #19827.

----------
files: set_inheritable_fcntl.patch
keywords: patch
messages: 263493
nosy: haypo
priority: normal
severity: normal
status: open
title: _Py_set_inheritable(): do nothing if the FD_CLOEXEC close is already set/cleared
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file42472/set_inheritable_fcntl.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26770>
_______________________________________

From report at bugs.python.org  Fri Apr 15 09:21:33 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Apr 2016 13:21:33 +0000
Subject: [issue26770] _Py_set_inheritable(): do nothing if the FD_CLOEXEC
 close is already set/cleared
In-Reply-To: <1460726460.32.0.344896145272.issue26770@psf.upfronthosting.co.za>
Message-ID: <1460726493.96.0.934348132969.issue26770@psf.upfronthosting.co.za>


STINNER Victor added the comment:

See also the issue #26769: "Python 2.7: make private file descriptors non inheritable".

----------
nosy: +martin.panter, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26770>
_______________________________________

From report at bugs.python.org  Fri Apr 15 09:24:07 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Apr 2016 13:24:07 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1460726647.92.0.950454751173.issue4709@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4709>
_______________________________________

From report at bugs.python.org  Fri Apr 15 09:33:00 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 15 Apr 2016 13:33:00 +0000
Subject: [issue26763] Update PEP-8 regarding binary operators
In-Reply-To: <1460703960.6.0.758787970043.issue26763@psf.upfronthosting.co.za>
Message-ID: <1460727180.43.0.454361020192.issue26763@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Please don't create a pull request on GitHub (python/peps is read-only). Attaching wrap-before-binary-operator.patch is enough.

----------
nosy: +berker.peksag
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26763>
_______________________________________

From report at bugs.python.org  Fri Apr 15 09:37:21 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Apr 2016 13:37:21 +0000
Subject: [issue26766] The result type of bytearray formatting is not stable
In-Reply-To: <1460713401.07.0.177357500269.issue26766@psf.upfronthosting.co.za>
Message-ID: <1460727441.49.0.938917910072.issue26766@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Here is a fix for bytearray%args. As expected, it was a bug in the new _PyBytesWriter API (introduced in Python 3.6 to implementation optimizations).

----------
Added file: http://bugs.python.org/file42473/writer_bytearray_mod.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26766>
_______________________________________

From report at bugs.python.org  Fri Apr 15 09:52:39 2016
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 15 Apr 2016 13:52:39 +0000
Subject: [issue26763] Update PEP-8 regarding binary operators
In-Reply-To: <1460703960.6.0.758787970043.issue26763@psf.upfronthosting.co.za>
Message-ID: <1460728359.57.0.0268087085261.issue26763@psf.upfronthosting.co.za>


INADA Naoki added the comment:

How about recommend using parentheses to avoid different level operators have same indent level?

ok:
            if (width == 0
                and height == 0
                and color == 'red'
                and emphasis == 'strong'
                or highlight > 100
            ):
                ...

better:
            if ((width == 0
                 and height == 0
                 and color == 'red'
                 and emphasis == 'strong')
                or highlight > 100
            ):

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26763>
_______________________________________

From report at bugs.python.org  Fri Apr 15 10:31:50 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 15 Apr 2016 14:31:50 +0000
Subject: [issue26763] Update PEP-8 regarding binary operators
In-Reply-To: <1460703960.6.0.758787970043.issue26763@psf.upfronthosting.co.za>
Message-ID: <1460730710.57.0.504506870228.issue26763@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I don't like the way "):" is indented in that example. I propose:

            if ((width == 0
                 and height == 0
                 and color == 'red'
                 and emphasis == 'strong')
                or highlight > 100):

Aren't there many other examples in the PEP that need to be adjusted, since we're changing the style not just for 'and' and 'or' but for all binary operators?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26763>
_______________________________________

From report at bugs.python.org  Fri Apr 15 10:33:11 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 15 Apr 2016 14:33:11 +0000
Subject: [issue26763] Update PEP-8 regarding binary operators
In-Reply-To: <1460703960.6.0.758787970043.issue26763@psf.upfronthosting.co.za>
Message-ID: <1460730791.89.0.0309214520705.issue26763@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I also think the PEP needs some language about the previous style being still acceptable as long as it's being used consistently (Knuth notwithstanding), and an acceptable compromise style where and/or go at the start of the line but other binary operators stay at the end.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26763>
_______________________________________

From report at bugs.python.org  Fri Apr 15 11:47:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Apr 2016 15:47:00 +0000
Subject: [issue26766] The result type of bytearray formatting is not stable
In-Reply-To: <1460713401.07.0.177357500269.issue26766@psf.upfronthosting.co.za>
Message-ID: <1460735220.86.0.508878566042.issue26766@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM, please commit. Why the behavior is vary in release and debug builds?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26766>
_______________________________________

From report at bugs.python.org  Fri Apr 15 11:50:34 2016
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 15 Apr 2016 15:50:34 +0000
Subject: [issue26763] Update PEP-8 regarding binary operators
In-Reply-To: <1460730710.57.0.504506870228.issue26763@psf.upfronthosting.co.za>
Message-ID: <CAEfz+TyKnh4jiai-MUKzuXfP=hQr6y2rUmaiXGYA+n4v5R0+hQ@mail.gmail.com>


INADA Naoki added the comment:

On Fri, Apr 15, 2016 at 11:31 PM, Guido van Rossum <report at bugs.python.org>
wrote:

>
> Guido van Rossum added the comment:
>
> I don't like the way "):" is indented in that example.

Me too.
I haven't know about this PEP8 update.
https://github.com/python/peps/commit/843b7d2cdb954dc0aa5ea70f140db2bd42943e1f

> I propose:
>
>             if ((width == 0
>                  and height == 0
>                  and color == 'red'
>                  and emphasis == 'strong')
>                 or highlight > 100):
>
>
Looks better to me.  But how about this?

if (width == 0
        and height == 0
        and color == 'red'
        and emphasis == 'strong'
    or highlight > 100):

Changing indentation level based on operator precedence is acceptable?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26763>
_______________________________________

From report at bugs.python.org  Fri Apr 15 11:52:49 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Apr 2016 15:52:49 +0000
Subject: [issue26766] The result type of bytearray formatting is not stable
In-Reply-To: <1460713401.07.0.177357500269.issue26766@psf.upfronthosting.co.za>
Message-ID: <20160415155245.26083.61618.52AD6A0E@psf.io>


Roundup Robot added the comment:

New changeset 1eb586d5b321 by Victor Stinner in branch 'default':
Issue #26766: Fix _PyBytesWriter_Finish()
https://hg.python.org/cpython/rev/1eb586d5b321

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26766>
_______________________________________

From report at bugs.python.org  Fri Apr 15 11:52:56 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Apr 2016 15:52:56 +0000
Subject: [issue26766] The result type of bytearray formatting is not stable
In-Reply-To: <1460713401.07.0.177357500269.issue26766@psf.upfronthosting.co.za>
Message-ID: <1460735576.96.0.119185371569.issue26766@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> LGTM, please commit.

Ok, done.

> Why the behavior is vary in release and debug builds?

See _PyBytesWriter_Alloc(): the code is designed to detect bugs earlier in debug mode, it only uses 10 bytes of the "small buffer" (buffer allocated on the stack) rather than the full size of the smaller buffer (512 bytes).

It looks like this hack helped to find a real bug :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26766>
_______________________________________

From report at bugs.python.org  Fri Apr 15 11:54:44 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Apr 2016 15:54:44 +0000
Subject: [issue26766] The result type of bytearray formatting is not stable
In-Reply-To: <1460713401.07.0.177357500269.issue26766@psf.upfronthosting.co.za>
Message-ID: <1460735684.79.0.215989455251.issue26766@psf.upfronthosting.co.za>


STINNER Victor added the comment:

@Berker: bytearray_mod.diff LGTM, you can push it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26766>
_______________________________________

From report at bugs.python.org  Fri Apr 15 12:00:47 2016
From: report at bugs.python.org (Benjamin Berg)
Date: Fri, 15 Apr 2016 16:00:47 +0000
Subject: [issue26771] python-config.sh.in INCDIR does not match python version
 if exec_prefix != prefix
Message-ID: <1460736047.35.0.090254006662.issue26771@psf.upfronthosting.co.za>


New submission from Benjamin Berg:

The script contains:

INCDIR="-I$includedir/python${VERSION}${ABIFLAGS}"
PLATINCDIR="-I$includedir/python${VERSION}${ABIFLAGS}"


But looking at the sysconfig module we have:
        'include':
            '{installed_base}/include/python{py_version_short}{abiflags}',
        'platinclude':
            '{installed_platbase}/include/python{py_version_short}{abiflags}',

which resolves from:
        _CONFIG_VARS['installed_base'] = _BASE_PREFIX
        _CONFIG_VARS['platbase'] = _EXEC_PREFIX

So one is based on prefix, and the other on exec_prefix. I am actually not sure right now how I could properly reconcile these in the shell script version, but if I simply patch the makefile to install the python version, then everything works fine.

----------
components: Cross-Build
messages: 263505
nosy: Alex.Willmer, benzea
priority: normal
severity: normal
status: open
title: python-config.sh.in INCDIR does not match python version if exec_prefix != prefix
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26771>
_______________________________________

From report at bugs.python.org  Fri Apr 15 12:13:26 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 15 Apr 2016 16:13:26 +0000
Subject: [issue26763] Update PEP-8 regarding binary operators
In-Reply-To: <1460703960.6.0.758787970043.issue26763@psf.upfronthosting.co.za>
Message-ID: <1460736806.84.0.421124415104.issue26763@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

> Changing indentation level based on operator precedence is acceptable?

I think that's a matter of personal taste and I don't think the PEP needs to have an opinion on it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26763>
_______________________________________

From report at bugs.python.org  Fri Apr 15 12:28:55 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Apr 2016 16:28:55 +0000
Subject: [issue26716] EINTR handling in fcntl
In-Reply-To: <1460145033.33.0.165294517839.issue26716@psf.upfronthosting.co.za>
Message-ID: <1460737735.69.0.412225651912.issue26716@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Patch version 2:

* add a comment to explain the C loop retrying on EINTR error
* add an unit test: I checked that the test fails with InterruptedError without the fix
* document the change in fcntl documentation

----------
Added file: http://bugs.python.org/file42474/fcntl_eintr-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26716>
_______________________________________

From report at bugs.python.org  Fri Apr 15 12:46:46 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 15 Apr 2016 16:46:46 +0000
Subject: [issue26763] Update PEP-8 regarding binary operators
In-Reply-To: <1460703960.6.0.758787970043.issue26763@psf.upfronthosting.co.za>
Message-ID: <1460738806.59.0.875969992593.issue26763@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I've updated the PEP with some more permissive language, mentioning Knuth's recommendation but allowing the old style because it's been recommended (and followed, and enforced) for decades. I've intentionally not updated other examples in the PEP to follow suit.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26763>
_______________________________________

From report at bugs.python.org  Fri Apr 15 13:07:06 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Fri, 15 Apr 2016 17:07:06 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1460740026.49.0.47734595814.issue4709@psf.upfronthosting.co.za>


Changes by Ivan Pozdeev <ivan_pozdeev at mail.ru>:


----------
nosy:  -Ivan.Pozdeev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4709>
_______________________________________

From report at bugs.python.org  Fri Apr 15 13:32:02 2016
From: report at bugs.python.org (Ian Lee)
Date: Fri, 15 Apr 2016 17:32:02 +0000
Subject: [issue26763] Update PEP-8 regarding binary operators
In-Reply-To: <1460703960.6.0.758787970043.issue26763@psf.upfronthosting.co.za>
Message-ID: <1460741522.82.0.186519054029.issue26763@psf.upfronthosting.co.za>


Ian Lee added the comment:

> Aren't there many other examples in the PEP that need to be adjusted, since we're changing the style not just for 'and' and 'or' but for all binary operators?

Admittedly I'd only looked in that one section last night, but I just went through the PEP and didn't see any other when I just went through the entire PEP now...

> I also think the PEP needs some language about the previous style being still acceptable as long as it's being used consistently (Knuth notwithstanding), and an acceptable compromise style where and/or go at the start of the line but other binary operators stay at the end.

I'd updated my branch on GitHub [1] but Guido, you beat me to the update while I was typing this message!

> I don't like the way "):" is indented in that example.

Honestly I don't either, I just like it more than artificially pushing the other lines forward a space. Personally, I'm not a fan of the current change either which puts the raise in line with the condition logic for the `if`::

        if (width == 0
            and height == 0
            and color == 'red'
            and emphasis == 'strong'
            or highlight > 100):
            raise ValueError("sorry, you lose")


My preference is to actually break that logic up and avoid the wrapping in the first place, as in [2]. Which in this particular class has the side benefit of that value being used again in the same function anyways.

I'm starting to realize that Brandon Rhodes really had a big impact on my ideas of styling as I've been learning Python these past few years, as this was another one style I'm stealing from that same talk [3].

> I've updated the PEP...

Great, thanks! I've created a ticket in pycodestyle [4] to update the style checker, which in turn will fix the flake8 error downstream once I get around (hopefully before PyCon) to releasing pycodestyle 1.8.0

[1] https://github.com/python/peps/compare/master...IanLee1521:issue26763
[2] https://github.com/python/peps/commit/0c790e7b721bd13ad12ab9e6f6206836f398f9c4
[3] http://rhodesmill.org/brandon/slides/2012-11-pyconca/#naming-intermediate-values
[4] https://github.com/PyCQA/pycodestyle/issues/498

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26763>
_______________________________________

From report at bugs.python.org  Fri Apr 15 13:43:11 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 15 Apr 2016 17:43:11 +0000
Subject: [issue26763] Update PEP-8 regarding binary operators
In-Reply-To: <1460741522.82.0.186519054029.issue26763@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJFuLmzECq90g17bbdoAdpOHL4Sijh-m9DgHeYGVhUoAw@mail.gmail.com>


Guido van Rossum added the comment:

I propose to keep the somewhat questionable examples in the PEP as an
illustration of the idea that style is debatable and cannot be reduced to
fixed rules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26763>
_______________________________________

From report at bugs.python.org  Fri Apr 15 13:51:51 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Apr 2016 17:51:51 +0000
Subject: [issue25609] Add a ContextManager ABC and type
In-Reply-To: <1447355679.68.0.225089426373.issue25609@psf.upfronthosting.co.za>
Message-ID: <20160415175148.421.74421.E77F7C24@psf.io>


Roundup Robot added the comment:

New changeset 257dd57dd732 by Brett Cannon in branch '3.5':
Issue #25609: Backport typing.ContextManager.
https://hg.python.org/cpython/rev/257dd57dd732

New changeset 14cf0011c5e9 by Brett Cannon in branch 'default':
Merge for issue #25609
https://hg.python.org/cpython/rev/14cf0011c5e9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25609>
_______________________________________

From report at bugs.python.org  Fri Apr 15 13:52:06 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Apr 2016 17:52:06 +0000
Subject: [issue25609] Add a ContextManager ABC and type
In-Reply-To: <1447355679.68.0.225089426373.issue25609@psf.upfronthosting.co.za>
Message-ID: <1460742726.02.0.0879319743254.issue25609@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/issue25609>
_______________________________________

From report at bugs.python.org  Fri Apr 15 14:01:03 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Apr 2016 18:01:03 +0000
Subject: [issue26716] EINTR handling in fcntl
In-Reply-To: <1460145033.33.0.165294517839.issue26716@psf.upfronthosting.co.za>
Message-ID: <1460743263.13.0.204627332278.issue26716@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Left nitpicks about tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26716>
_______________________________________

From report at bugs.python.org  Fri Apr 15 14:26:15 2016
From: report at bugs.python.org (Raghu)
Date: Fri, 15 Apr 2016 18:26:15 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460744775.74.0.596923754901.issue26743@psf.upfronthosting.co.za>


Raghu added the comment:

Hey Guys/Gals, are you still debugging the issue? Do you need more info?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Fri Apr 15 14:29:53 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 15 Apr 2016 18:29:53 +0000
Subject: [issue26763] Update PEP-8 regarding binary operators
In-Reply-To: <1460703960.6.0.758787970043.issue26763@psf.upfronthosting.co.za>
Message-ID: <1460744993.98.0.585704100811.issue26763@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/issue26763>
_______________________________________

From report at bugs.python.org  Fri Apr 15 14:40:08 2016
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 15 Apr 2016 18:40:08 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460745608.3.0.558401413725.issue26743@psf.upfronthosting.co.za>


Stefan Krah added the comment:

An option would be to use the support of the probably commercial

  http://www.windriver.com/products/linux/

and ask them why they're still on Python 2.7.3.  They'll also
have gcc installed and can run the test case proposed in this
issue.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Fri Apr 15 14:51:46 2016
From: report at bugs.python.org (Rex Dwyer)
Date: Fri, 15 Apr 2016 18:51:46 +0000
Subject: [issue26772] regex.ENHANCEMATCH crashes interpreter
Message-ID: <1460746306.07.0.135965165356.issue26772@psf.upfronthosting.co.za>


New submission from Rex Dwyer:

regex.findall(r'((brown)|(lazy)){1<=e<=3} ((dog)|(fox)){1<=e<=3}',
              'The quick borwn fax jumped over the lzy hog',
              regex.ENHANCEMATCH)

crashes interpreter.

regex.__version__ =>  2.4.85

python version
'3.4.2 (v3.4.2:ab2c023a9432, Oct  6 2014, 22:15:05) [MSC v.1600 32 bit (Intel)]'

----------
components: Regular Expressions
messages: 263515
nosy: Rex Dwyer, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: regex.ENHANCEMATCH crashes interpreter
type: crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26772>
_______________________________________

From report at bugs.python.org  Fri Apr 15 15:01:36 2016
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 15 Apr 2016 19:01:36 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460746896.24.0.338086827214.issue26743@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Also, I don't understand how the test suite could pass with
these kinds of errors. Are you sure this is the Wind-River
system Python?  Did they run the test suite?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Fri Apr 15 15:01:56 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 15 Apr 2016 19:01:56 +0000
Subject: [issue26772] regex.ENHANCEMATCH crashes interpreter
In-Reply-To: <1460746306.07.0.135965165356.issue26772@psf.upfronthosting.co.za>
Message-ID: <1460746916.09.0.995211422322.issue26772@psf.upfronthosting.co.za>


SilentGhost added the comment:

regex module is not part of the standard library and issues with it should be reported on its bug tracker https://bitbucket.org/mrabarnett/mrab-regex

----------
nosy: +SilentGhost
resolution:  -> third party
stage:  -> resolved
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26772>
_______________________________________

From report at bugs.python.org  Fri Apr 15 15:15:17 2016
From: report at bugs.python.org (=?utf-8?b?TWFydMOtbiBHYWl0w6Fu?=)
Date: Fri, 15 Apr 2016 19:15:17 +0000
Subject: [issue26763] Update PEP-8 regarding binary operators
In-Reply-To: <1460703960.6.0.758787970043.issue26763@psf.upfronthosting.co.za>
Message-ID: <1460747717.65.0.400105381483.issue26763@psf.upfronthosting.co.za>


Mart?n Gait?n added the comment:

There is a typo on "reseach" instead of "research"

----------
nosy: +Mart?n Gait?n

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26763>
_______________________________________

From report at bugs.python.org  Fri Apr 15 15:20:25 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 15 Apr 2016 19:20:25 +0000
Subject: [issue26763] Update PEP-8 regarding binary operators
In-Reply-To: <1460747717.65.0.400105381483.issue26763@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJQ8Za0OtrkF4+xDuHPiwza4EU0c=tX19PFe+9nTjeL1A@mail.gmail.com>


Guido van Rossum added the comment:

OK, maybe @chrisa can fix the typo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26763>
_______________________________________

From report at bugs.python.org  Fri Apr 15 15:24:01 2016
From: report at bugs.python.org (Chris Angelico)
Date: Fri, 15 Apr 2016 19:24:01 +0000
Subject: [issue26763] Update PEP-8 regarding binary operators
In-Reply-To: <1460703960.6.0.758787970043.issue26763@psf.upfronthosting.co.za>
Message-ID: <1460748241.6.0.979271391078.issue26763@psf.upfronthosting.co.za>


Chris Angelico added the comment:

Typo fixed in peps repo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26763>
_______________________________________

From report at bugs.python.org  Fri Apr 15 15:30:06 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 15 Apr 2016 19:30:06 +0000
Subject: [issue26769] Python 2.7: make private file descriptors non inheritable
In-Reply-To: <1460725141.7.0.638632202912.issue26769@psf.upfronthosting.co.za>
Message-ID: <1460748606.91.0.116109151573.issue26769@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26769>
_______________________________________

From report at bugs.python.org  Fri Apr 15 15:35:12 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Apr 2016 19:35:12 +0000
Subject: [issue26739] idle: Errno 10035 a non-blocking socket operation could
 not be completed immediately
In-Reply-To: <1460409859.89.0.789703447955.issue26739@psf.upfronthosting.co.za>
Message-ID: <1460748912.9.0.183099811947.issue26739@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Michael, when you open an issue, you need to stay nosy so we can ask questions.  This is especially true when the issue involved 3rd party modules, like pygame, and even more, when personal files, like the images, are required.  In this case:

0. Which patch release of 2.7 are you running?  If not 2.7.11, please upgrade and retry.  There was a patch for Error 10035 in March 19, 2013, which would be about the time of 2.7.6 or so.
https://hg.python.org/cpython/rev/8ec39bfd1f01 #9090

1.Does your program run correctly when you run it directly with python from the console, with "python pathto/Skier"?

2. Were you running it from the IDLE editor?  If so, does it fail immediately? or after the game runs a bit?  Does it seem to always fail in exactly the same way, at the same time?

[A 'socket' is a class abstraction used to communicate between different processes.  It is usually used for processes on different machines, as with the browser process on your machine and a server process on another machine, but can be used for two processes on the same machine.]

--
This appears to be a socket issue, not an IDLE issue as such, just as #25332 was not a urllib issue.  This is the 10th issue found searching the tracker for 'Error 10035', but the first, I think, involving IDLE.  I know essentially nothing about the subject.

----------
nosy: +MICHAEL JACOBSON, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26739>
_______________________________________

From report at bugs.python.org  Fri Apr 15 15:43:36 2016
From: report at bugs.python.org (Paul Ellenbogen)
Date: Fri, 15 Apr 2016 19:43:36 +0000
Subject: [issue26773] Shelve works inconsistently when carried over to child
 processes
Message-ID: <1460749416.45.0.0472811645443.issue26773@psf.upfronthosting.co.za>


New submission from Paul Ellenbogen:

If a shelve is opened, then the processed forked, sometime the shelve will appear to work in the child, and other times it will throw a KeyError. I suspect the order of element access may trigger the issue. I have included a python script that will exhibit the error. It may need to be run a few times.

If shelve is not meant to be inherited by the child process in this way, it should consistently throw an error (probably not a KeyError) on any use, including the first. This way it can be caught in the child, and the shelve can potentially be reopened in the child.

A current workaround is to find all places where a process may fork, and reopen any shelves in the child process after the fork. This may work for most smaller scripts. This could become tedious in more complex applications that fork in multiple places and open shelves in multiple places.

-------------------------------------------------------

Running

#!/usr/bin/env python3

import multiprocessing
import platform
import sys

print(sys.version)
print(multiprocessing.cpu_count())
print(platform.platform())


outputs:
3.4.3+ (default, Oct 14 2015, 16:03:50) 
[GCC 5.2.1 20151010]
8
Linux-4.2.0-34-generic-x86_64-with-Ubuntu-15.10-wily

----------
components: Interpreter Core
files: shelve_process.py
messages: 263522
nosy: Paul Ellenbogen
priority: normal
severity: normal
status: open
title: Shelve works inconsistently when carried over to child processes
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file42475/shelve_process.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26773>
_______________________________________

From report at bugs.python.org  Fri Apr 15 15:44:18 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Apr 2016 19:44:18 +0000
Subject: [issue26760] Document PyFrameObject
In-Reply-To: <1460658388.85.0.590056164506.issue26760@psf.upfronthosting.co.za>
Message-ID: <20160415194411.88648.72015.DE33B775@psf.io>


Roundup Robot added the comment:

New changeset ba6f4f0fe9ea by Brett Cannon in branch '3.5':
Issue #26760: Minimally document PyFrameObject
https://hg.python.org/cpython/rev/ba6f4f0fe9ea

New changeset 5c18598382e9 by Brett Cannon in branch 'default':
Merge for issue #26760
https://hg.python.org/cpython/rev/5c18598382e9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26760>
_______________________________________

From report at bugs.python.org  Fri Apr 15 15:45:07 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Apr 2016 19:45:07 +0000
Subject: [issue26760] Document PyFrameObject
In-Reply-To: <1460658388.85.0.590056164506.issue26760@psf.upfronthosting.co.za>
Message-ID: <1460749507.17.0.778951756281.issue26760@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/issue26760>
_______________________________________

From report at bugs.python.org  Fri Apr 15 15:46:05 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Apr 2016 19:46:05 +0000
Subject: [issue26744] print() function hangs on MS-Windows 10
In-Reply-To: <1460512669.99.0.0354506250162.issue26744@psf.upfronthosting.co.za>
Message-ID: <1460749565.8.0.132428898544.issue26744@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/issue26744>
_______________________________________

From report at bugs.python.org  Fri Apr 15 15:50:32 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 15 Apr 2016 19:50:32 +0000
Subject: [issue26773] Shelve works inconsistently when carried over to child
 processes
In-Reply-To: <1460749416.45.0.0472811645443.issue26773@psf.upfronthosting.co.za>
Message-ID: <1460749832.99.0.873453021931.issue26773@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Extension Modules
nosy: +jnoller, sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26773>
_______________________________________

From report at bugs.python.org  Fri Apr 15 16:09:11 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Apr 2016 20:09:11 +0000
Subject: [issue26186] LazyLoader rejecting use of SourceFileLoader
In-Reply-To: <1453577280.26.0.226746274701.issue26186@psf.upfronthosting.co.za>
Message-ID: <1460750951.59.0.0515580015364.issue26186@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I actually think this can be generalized thanks to some tweaks made in Python 3.6 which will lead to it working with extension modules.

I need to double-check, but I think I can:
- Eliminate the _Module class (and thus have _LazyModule inherit types.ModuleType directly)
- Call create_module() and see if it returns something
- Use spec.loader_state to store the original value of module.__class__ (probably be simply storing __class__ in the dict of values)
- Just blindly try to set module.__class__ to _LazyModule and let the exception propagate if it fails
- In _LazyModule.__getattribute__, temporarily assign the type to types.ModuleType to shut off __getattribute__() before assigning the proper value

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26186>
_______________________________________

From report at bugs.python.org  Fri Apr 15 16:49:10 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Apr 2016 20:49:10 +0000
Subject: [issue26058] PEP 509: Add ma_version to PyDictObject
In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za>
Message-ID: <1460753350.42.0.468132684166.issue26058@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The implementation is outdated: ma_version was renamed to ma_version_tag in the latest version of the PEP 509.

Patch version 7 is updated to the latest PEP (rebased and rename ma_version to ma_version_tag).

----------
Added file: http://bugs.python.org/file42476/dict_version-7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26058>
_______________________________________

From report at bugs.python.org  Fri Apr 15 17:04:26 2016
From: report at bugs.python.org (Raghu)
Date: Fri, 15 Apr 2016 21:04:26 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460754266.97.0.472232018202.issue26743@psf.upfronthosting.co.za>


Raghu added the comment:

Yes, it is a WindRiver linux. I will check if Commercial WindRiver team can help me.

Host details:
Linux fpc0 3.10.62-ltsi-WR6.0.0.18_standard #1 SMP PREEMPT Sun Apr 3 23:17:02 PDT 2016 ppc64 ppc64 ppc64 GNU/Linux



Also is there a protocol followed in this website? If I have done something wrong it's because I didn't know I was doing it incorrectly. I ask because, a new person replies everyday and they don't even completely tell me the solution or what conclusions they have made. I am lost.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Fri Apr 15 17:29:00 2016
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 15 Apr 2016 21:29:00 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460755740.35.0.576529305029.issue26743@psf.upfronthosting.co.za>


Stefan Krah added the comment:

My conclusion is:  The error in msg263292 should have been
caught by the test suite.

I'd ask the WindRiver support if they actually run the test suite
before shipping the binaries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Fri Apr 15 17:32:00 2016
From: report at bugs.python.org (Raghu)
Date: Fri, 15 Apr 2016 21:32:00 +0000
Subject: [issue26743] Unable to import random with python2.7 on power pc based
 machine
In-Reply-To: <1460509006.04.0.361461231746.issue26743@psf.upfronthosting.co.za>
Message-ID: <1460755920.37.0.234347506822.issue26743@psf.upfronthosting.co.za>


Raghu added the comment:

Thank you skrah. I raised a support request from WR. I will keep my fingers crossed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26743>
_______________________________________

From report at bugs.python.org  Fri Apr 15 18:20:00 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Apr 2016 22:20:00 +0000
Subject: [issue26766] The result type of bytearray formatting is not stable
In-Reply-To: <1460713401.07.0.177357500269.issue26766@psf.upfronthosting.co.za>
Message-ID: <20160415221940.88648.96701.FEFAB578@psf.io>


Roundup Robot added the comment:

New changeset b3e3efc5afa4 by Berker Peksag in branch 'default':
Issue #26766: Remove redundant bytearray_format() from bytearrayobject.c
https://hg.python.org/cpython/rev/b3e3efc5afa4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26766>
_______________________________________

From report at bugs.python.org  Fri Apr 15 18:20:34 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 15 Apr 2016 22:20:34 +0000
Subject: [issue26766] The result type of bytearray formatting is not stable
In-Reply-To: <1460713401.07.0.177357500269.issue26766@psf.upfronthosting.co.za>
Message-ID: <1460758834.44.0.599143733746.issue26766@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the reviews!

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26766>
_______________________________________

From report at bugs.python.org  Fri Apr 15 19:45:32 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Apr 2016 23:45:32 +0000
Subject: [issue26535] Minor typo in the docs for struct.unpack
In-Reply-To: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za>
Message-ID: <20160415234528.107504.61235.FA4C37C9@psf.io>


Roundup Robot added the comment:

New changeset 7889fcb0697b by Martin Panter in branch '3.5':
Issue #26535: Correct docs regarding the struct buffer size
https://hg.python.org/cpython/rev/7889fcb0697b

New changeset 39dc2f39373d by Martin Panter in branch 'default':
Issue #26535: Merge struct doc from 3.5
https://hg.python.org/cpython/rev/39dc2f39373d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26535>
_______________________________________

From report at bugs.python.org  Fri Apr 15 19:59:18 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Apr 2016 23:59:18 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za>
Message-ID: <20160415235912.12733.37463.0E484000@psf.io>


Roundup Robot added the comment:

New changeset f16ec63055ad by Gregory P. Smith in branch '3.5':
Issue #25702: A --with-lto configure option has been added that will
https://hg.python.org/cpython/rev/f16ec63055ad

New changeset 3103af76f4c4 by Gregory P. Smith in branch 'default':
Issue #25702: A --with-lto configure option has been added that will
https://hg.python.org/cpython/rev/3103af76f4c4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25702>
_______________________________________

From report at bugs.python.org  Fri Apr 15 20:01:09 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Apr 2016 00:01:09 +0000
Subject: [issue26657] Directory traversal with http.server and
 SimpleHTTPServer on windows
In-Reply-To: <1459179015.77.0.509336394494.issue26657@psf.upfronthosting.co.za>
Message-ID: <1460764869.49.0.321401046198.issue26657@psf.upfronthosting.co.za>


Martin Panter added the comment:

I will try to commit my patch in a couple days if there are no objections.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26657>
_______________________________________

From report at bugs.python.org  Fri Apr 15 20:16:25 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 16 Apr 2016 00:16:25 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za>
Message-ID: <1460765785.67.0.634793604926.issue25702@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

What i committed for 3.5 and 3.6 matches lto-cpython3-v04.patch which just adds --with-lto support.  2.7 still needs to be patched.

For reference: Using ubuntu's gcc 5.2.1 i was seeing a 2-3% performance increase in the resulting LTO binary vs a plain profile-opt PGO build.  That'll vary based on arch and compiler toolchain.

----------
assignee:  -> gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25702>
_______________________________________

From report at bugs.python.org  Fri Apr 15 20:22:07 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Apr 2016 00:22:07 +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: <20160416002157.12729.67722.949FA6B1@psf.io>


Roundup Robot added the comment:

New changeset c42a9233af04 by Martin Panter in branch '2.7':
Issue #25314: Remove confused statement about const argument
https://hg.python.org/cpython/rev/c42a9233af04

New changeset 59b8db278e3c by Martin Panter in branch '3.5':
Issue #25314: Remove confused statement about const argument
https://hg.python.org/cpython/rev/59b8db278e3c

New changeset 7d61a991f405 by Martin Panter in branch 'default':
Issue #25314: Merge argparse doc from 3.5
https://hg.python.org/cpython/rev/7d61a991f405

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25314>
_______________________________________

From report at bugs.python.org  Fri Apr 15 20:52:07 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Apr 2016 00:52:07 +0000
Subject: [issue26769] Python 2.7: make private file descriptors non inheritable
In-Reply-To: <1460725141.7.0.638632202912.issue26769@psf.upfronthosting.co.za>
Message-ID: <1460767927.47.0.625012726838.issue26769@psf.upfronthosting.co.za>


Martin Panter added the comment:

It looks like some of these do make the file descriptor accessible to the Python user. The following are from the RST documentation:

oss_audio_device.fileno()
oss_mixer_device.fileno()
epoll.fileno()
kqueue.fileno()
audio device.fileno()

I did not find any documentation for the ?linuxaudiodev? module, but it also seems to supply a public fileno() method:

$ sudo modprobe snd-pcm-oss
$ python2
Python 2.7.11 (default, Dec  6 2015, 15:43:46) 
[GCC 5.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import linuxaudiodev
>>> a = linuxaudiodev.open("w")
>>> a.fileno()
3

Unless there is demand for making these cases non-inheritable, it might be safest to leave them be. However it looks like the mmap file descriptor could be internal (though I?m not an expert on that module to be sure). So you might be okay with the mmap change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26769>
_______________________________________

From report at bugs.python.org  Fri Apr 15 22:33:17 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Apr 2016 02:33:17 +0000
Subject: [issue26535] Minor typo in the docs for struct.unpack
In-Reply-To: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za>
Message-ID: <1460773997.9.0.519553449453.issue26535@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/issue26535>
_______________________________________

From report at bugs.python.org  Fri Apr 15 23:29:24 2016
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 16 Apr 2016 03:29:24 +0000
Subject: [issue26774] Elide Py_atomic fences when WITH_THREAD is disabled?
Message-ID: <1460777364.25.0.14094466129.issue26774@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Right now the atomic access fence macros in pyatomic.h are unconditional.  This means that they're active even even when you "./configure --without-threads".  If Python thread support is disabled, surely we don't need to ensure atomic access to variables, because there aren't any other threads to compete with.

Shouldn't we add

#ifdef WITH_THREAD
/* current code goes here */
#else
#define _Py_atomic_load_relaxed(x) (x)
/* etc */
#endif

?

----------
messages: 263537
nosy: haypo, jyasskin, larry
priority: low
severity: normal
stage: test needed
status: open
title: Elide Py_atomic fences when WITH_THREAD is disabled?
type: performance
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26774>
_______________________________________

From report at bugs.python.org  Sat Apr 16 00:04:57 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Apr 2016 04:04:57 +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: <1460779497.37.0.483898304615.issue25314@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25314>
_______________________________________

From report at bugs.python.org  Sat Apr 16 02:54:29 2016
From: report at bugs.python.org (Luiz Poleto)
Date: Sat, 16 Apr 2016 06:54:29 +0000
Subject: [issue26775] Improve test coverage on urllib.parse
Message-ID: <1460789669.45.0.432751253755.issue26775@psf.upfronthosting.co.za>


New submission from Luiz Poleto:

urllib.parse has two methods, parse_qs and parse_qsl to parse a query string and return its parameters/values as a dictionary or a list, respectively. However, the unit tests only tests parse_qsl, which is also incomplete since both parse_qs and parse_qsl support & and ; as separators for key=value pairs and there are only test scenarios using &.

The attached patch add a new test for parse_qs as well as new scenarios including ; as separator.

----------
components: Tests
files: urllib.parse_test_coverage.patch
keywords: patch
messages: 263538
nosy: luiz.poleto
priority: normal
severity: normal
status: open
title: Improve test coverage on urllib.parse
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42477/urllib.parse_test_coverage.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26775>
_______________________________________

From report at bugs.python.org  Sat Apr 16 03:47:28 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Apr 2016 07:47:28 +0000
Subject: [issue26638] Avoid warnings about missing CLI options when building
 documentation
In-Reply-To: <1458881380.09.0.599104229044.issue26638@psf.upfronthosting.co.za>
Message-ID: <20160416074725.403.4946.97A3F1C4@psf.io>


Roundup Robot added the comment:

New changeset 23a884c32a39 by Martin Panter in branch '3.5':
Issue #26638: Fix links to some CLI options and section headings
https://hg.python.org/cpython/rev/23a884c32a39

New changeset 68b84643dffd by Martin Panter in branch 'default':
Issue #26638: Merge link fixes from 3.5
https://hg.python.org/cpython/rev/68b84643dffd

New changeset 3e0321584f23 by Martin Panter in branch '2.7':
Issue #26638: Fix links to some CLI options
https://hg.python.org/cpython/rev/3e0321584f23

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26638>
_______________________________________

From report at bugs.python.org  Sat Apr 16 04:02:38 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Apr 2016 08:02:38 +0000
Subject: [issue26776] Determining the failure of C API call is ambiguous
Message-ID: <1460793758.51.0.304392536592.issue26776@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

C API functions returns a special value unambiguously signaling about a raised exception (NULL or -1). But in some cases this is ambiguous, because the special value is a legitimate value (e.g. -1 for PyLong_AsLong() or NULL for PyDict_GetItem()). Needed to use PyErr_Occurred() to distinguish between successful and failed call.

The problem is that if PyLong_AsLong() is called when the exception is set, successful call returned -1 is interpreted as failed. Since it is happen in very rare case, this bug is usually unnoticed.

Attached experimental patch makes some functions like PyLong_AsLong() always failing if called with an exception set. Some tests are failed with it applied: test_compile test_datetime test_io test_os test_symtable test_syntax test_xml_etree_c.

----------
components: Interpreter Core
files: check_error_occurred.patch
keywords: patch
messages: 263540
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Determining the failure of C API call is ambiguous
Added file: http://bugs.python.org/file42478/check_error_occurred.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26776>
_______________________________________

From report at bugs.python.org  Sat Apr 16 04:22:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Apr 2016 08:22:33 +0000
Subject: [issue26764] SystemError in bytes.__rmod__
In-Reply-To: <1460705282.56.0.272877366519.issue26764@psf.upfronthosting.co.za>
Message-ID: <1460794953.7.0.498678763485.issue26764@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26764>
_______________________________________

From report at bugs.python.org  Sat Apr 16 04:43:10 2016
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 16 Apr 2016 08:43:10 +0000
Subject: [issue26753] Obmalloc lock LOCK_INIT and LOCK_FINI are never used
In-Reply-To: <1460620546.75.0.247903713074.issue26753@psf.upfronthosting.co.za>
Message-ID: <1460796190.74.0.153470488524.issue26753@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Patch attached.  The basics were okay; however, there was no locking around access to a static variable (_Py_AllocatedBlocks) so I added some.  The way the code managed _Py_AllocatedBlocks was a bit odd; this approach resulted in fewer lines, but it was hard to follow, and adding locking support would have muddied it even further, so I simplified it.  I also simplified the locking support a great deal ("SIMPLELOCK": YAGNI) and touched up the relevant comment.

Finally, I noticed a minor bug wrt added _Py_AllocatedBlocks: if you call PyMem_Realloc(NULL, 50000), that's really a new allocation, so _Py_AllocatedBlocks needs to be incremented, but it wasn't.  Since Antoine is the father of _Py_AllocatedBlocks I added him to the nosy list.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26753>
_______________________________________

From report at bugs.python.org  Sat Apr 16 04:43:49 2016
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 16 Apr 2016 08:43:49 +0000
Subject: [issue26753] Obmalloc lock LOCK_INIT and LOCK_FINI are never used
In-Reply-To: <1460620546.75.0.247903713074.issue26753@psf.upfronthosting.co.za>
Message-ID: <1460796229.25.0.921214627366.issue26753@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Oy veh, in editing the issue I dropped the attached file.  Here it is.

----------
keywords: +patch
Added file: http://bugs.python.org/file42479/larry.refresh.lock.macros.for.obmalloc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26753>
_______________________________________

From report at bugs.python.org  Sat Apr 16 05:17:43 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Apr 2016 09:17:43 +0000
Subject: [issue26774] Elide Py_atomic fences when WITH_THREAD is disabled?
In-Reply-To: <1460777364.25.0.14094466129.issue26774@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwac80E1YF+WmwQbZOGh5rJHGpmPsH+jubDsVaF7MEZb7w@mail.gmail.com>


STINNER Victor added the comment:

I never liked the option to disable thread support. I don't think that
anyone uses it but it requires many #ifdef in the code. I would prefer to
drop the option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26774>
_______________________________________

From report at bugs.python.org  Sat Apr 16 05:27:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Apr 2016 09:27:24 +0000
Subject: [issue26776] Determining the failure of C API call is ambiguous
In-Reply-To: <1460793758.51.0.304392536592.issue26776@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwazbDbJp3aiFce-ODpZG+i3mNXHRiPYfK07fmHcC6GK3w@mail.gmail.com>


STINNER Victor added the comment:

Ah yes. Some months (years?) ago, i started to add assertions to fail if
some functions are called with an exception set.

Checking if an exception is set at runtime adds a low overhead. Maybe it's
better to fail with a fatal error (like an assertion error) in debug mode
(and do nothing in release mode).

But I'm not sure that developers of C extensions are all able to get a
Python compiled in debug mode :-/ That's also why I added a check a
runtime: raise a SystemError if a function with an exception set. I also
added PYTHONMALLOC=debug to make some debug checks easily available on
release builds.

The bug also reminds me my PEP 490 to chain exceptions. It would be
yet another option...

So well, I don't know what is the best option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26776>
_______________________________________

From report at bugs.python.org  Sat Apr 16 05:37:35 2016
From: report at bugs.python.org (Bernard Spil)
Date: Sat, 16 Apr 2016 09:37:35 +0000
Subject: [issue26470] Make OpenSSL module compatible with OpenSSL 1.1.0
In-Reply-To: <1456920893.87.0.933592382559.issue26470@psf.upfronthosting.co.za>
Message-ID: <1460799455.01.0.975442565357.issue26470@psf.upfronthosting.co.za>


Bernard Spil added the comment:

Testing this patch on HardenedBSD/LibreSSL (base SSL libs replaced with LibreSSL)

----------
nosy: +spil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26470>
_______________________________________

From report at bugs.python.org  Sat Apr 16 06:39:35 2016
From: report at bugs.python.org (Bernard Spil)
Date: Sat, 16 Apr 2016 10:39:35 +0000
Subject: [issue26470] Make OpenSSL module compatible with OpenSSL 1.1.0
In-Reply-To: <1456920893.87.0.933592382559.issue26470@psf.upfronthosting.co.za>
Message-ID: <1460803175.06.0.589125601527.issue26470@psf.upfronthosting.co.za>


Bernard Spil added the comment:

Checking version numbers to see if a feature is available is a bad practice. How can features ever be removed this way! Would be better to check for the feature itself (using autoconf).

The patch was mostly OK but any check for OPENSSL_VERSION_NUMBER for now also requires a negative check for LIBRESSL_VERSION_NUMBER as LibreSSL froze features at 1.0.1g.

Next to that, anything requiring compression (CRIME attack) should be guarded using and #infdef OPENSSL_NO_COMP.

This patch allowed me to build Python 3.5 with LibreSSL 2.3 (i.e. without SSLv3, Compression, RC4, SHA-0, etc)

----------
Added file: http://bugs.python.org/file42480/patch-lang_python35-OpenSSL-1.1.0+LibreSSL

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26470>
_______________________________________

From report at bugs.python.org  Sat Apr 16 06:42:30 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Apr 2016 10:42:30 +0000
Subject: [issue26638] Avoid warnings about missing CLI options when building
 documentation
In-Reply-To: <1458881380.09.0.599104229044.issue26638@psf.upfronthosting.co.za>
Message-ID: <1460803350.4.0.895602152033.issue26638@psf.upfronthosting.co.za>


Martin Panter added the comment:

I committed the parts of my patch that improve real links in the end result.

doc-warnings.v2.patch has the remaining changes which add exclamation marks to mask undefined options.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26638>
_______________________________________

From report at bugs.python.org  Sat Apr 16 06:46:14 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Apr 2016 10:46:14 +0000
Subject: [issue26638] Avoid warnings about missing CLI options when building
 documentation
In-Reply-To: <1458881380.09.0.599104229044.issue26638@psf.upfronthosting.co.za>
Message-ID: <1460803574.14.0.749296739598.issue26638@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


Added file: http://bugs.python.org/file42481/doc-warnings.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26638>
_______________________________________

From report at bugs.python.org  Sat Apr 16 06:47:30 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Apr 2016 10:47:30 +0000
Subject: [issue26638] Avoid warnings about missing CLI options when building
 documentation
In-Reply-To: <1458881380.09.0.599104229044.issue26638@psf.upfronthosting.co.za>
Message-ID: <1460803650.4.0.2239081487.issue26638@psf.upfronthosting.co.za>


Martin Panter added the comment:

This patch disables the warning, but I tend to think it is not a good long-term solution.

----------
Added file: http://bugs.python.org/file42482/disable-warning.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26638>
_______________________________________

From report at bugs.python.org  Sat Apr 16 08:12:42 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Apr 2016 12:12:42 +0000
Subject: [issue10838] subprocess __all__ is incomplete
In-Reply-To: <1294260769.5.0.0970426129524.issue10838@psf.upfronthosting.co.za>
Message-ID: <20160416121239.70543.6351.9FB5FA39@psf.io>


Roundup Robot added the comment:

New changeset cb38866e4c13 by Martin Panter in branch '3.5':
Issue #10838: Run test__all__() everywhere, even if poll() is not available
https://hg.python.org/cpython/rev/cb38866e4c13

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10838>
_______________________________________

From report at bugs.python.org  Sat Apr 16 08:35:09 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Apr 2016 12:35:09 +0000
Subject: [issue26777] test_asyncio: test_timeout_disable() fails randomly
Message-ID: <1460810109.63.0.0563263496249.issue26777@psf.upfronthosting.co.za>


New submission from STINNER Victor:

On the "AMD64 FreeBSD 9.x 3.5" buildbot, test_timeout_disable() fails randomly.

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%203.5/builds/701/steps/test/logs/stdio

======================================================================
FAIL: test_timeout_disable (test.test_asyncio.test_tasks.TimeoutTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.5.koobs-freebsd9/build/Lib/test/test_asyncio/test_tasks.py", line 2399, in test_timeout_disable
    self.loop.run_until_complete(go())
  File "/usr/home/buildbot/python/3.5.koobs-freebsd9/build/Lib/asyncio/base_events.py", line 379, in run_until_complete
    return future.result()
  File "/usr/home/buildbot/python/3.5.koobs-freebsd9/build/Lib/asyncio/futures.py", line 274, in result
    raise self._exception
  File "/usr/home/buildbot/python/3.5.koobs-freebsd9/build/Lib/asyncio/tasks.py", line 240, in _step
    result = coro.send(None)
  File "/usr/home/buildbot/python/3.5.koobs-freebsd9/build/Lib/test/test_asyncio/test_tasks.py", line 2398, in go
    self.assertTrue(0.09 < dt < 0.11, dt)
AssertionError: False is not true : 0.11916078114882112

----------
components: Tests, asyncio
keywords: buildbot
messages: 263550
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncio: test_timeout_disable() fails randomly
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26777>
_______________________________________

From report at bugs.python.org  Sat Apr 16 08:48:57 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Apr 2016 12:48:57 +0000
Subject: [issue25942] subprocess.call SIGKILLs too liberally
In-Reply-To: <1451006108.23.0.113868196098.issue25942@psf.upfronthosting.co.za>
Message-ID: <1460810937.47.0.16872694169.issue25942@psf.upfronthosting.co.za>


Martin Panter added the comment:

I don?t think Victor likes #2 because of the zombie. I would be interested in #4 (one of the documented purposes of subprocess is to replace os.system), but it might need careful consideration and discussion. Ignoring signals is such a significant change I think it would have to be a new feature for 3.6+ only.

Mike/Victor, what do you think of my proposal (call it #6) about waiting a second time before resorting to SIGKILL? Posting a patch which implements this.

----------
Added file: http://bugs.python.org/file42483/second-wait.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25942>
_______________________________________

From report at bugs.python.org  Sat Apr 16 08:49:36 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Apr 2016 12:49:36 +0000
Subject: [issue26778] More typo fixes
Message-ID: <1460810974.92.0.431649847374.issue26778@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes a number of typos (mainly about misusing "a/an") in the docs, docstrings, comments and error messages.

----------
files: typos.patch
keywords: patch
messages: 263552
nosy: martin.panter, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: More typo fixes
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42484/typos.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26778>
_______________________________________

From report at bugs.python.org  Sat Apr 16 08:52:11 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Apr 2016 12:52:11 +0000
Subject: [issue26778] More typo fixes
In-Reply-To: <1460810974.92.0.431649847374.issue26778@psf.upfronthosting.co.za>
Message-ID: <1460811131.21.0.581494392872.issue26778@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file42484/typos.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26778>
_______________________________________

From report at bugs.python.org  Sat Apr 16 08:52:21 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Apr 2016 12:52:21 +0000
Subject: [issue26778] More typo fixes
In-Reply-To: <1460810974.92.0.431649847374.issue26778@psf.upfronthosting.co.za>
Message-ID: <1460811141.9.0.910278619994.issue26778@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file42485/typos.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26778>
_______________________________________

From report at bugs.python.org  Sat Apr 16 09:08:12 2016
From: report at bugs.python.org (Sriram Rajagopalan)
Date: Sat, 16 Apr 2016 13:08:12 +0000
Subject: [issue26779] pdb continue followed by an exception in the same frame
 shows incorrect frame linenumber
Message-ID: <1460812092.64.0.640871964672.issue26779@psf.upfronthosting.co.za>


New submission from Sriram Rajagopalan:

Consider this simple python program - 

  1 #!/usr/bin/python
  2
  3 import pdb
  4 import sys
  5 import traceback
  6
  7 def trace_exception( type, value, tb ):
  8     traceback.print_tb( tb )
  9     pdb.post_mortem( tb )
 10
 11 sys.excepthook = trace_exception
 12
 13 def func():
 14     print ( "Am here in func" )
 15     pdb.set_trace()
 16     print ( "Am here after pdb" )
 17     print ( "Am going to assert now" )
 18     assert False
 19     print ( "Am here after exception" )
 20
 21 def main():
 22     func()
 23
 24 if __name__ == "__main__":
 25     main()


On running this program - 

% ./python /tmp/test.py
Am here in func
> /tmp/test.py(16)func()
-> print ( "Am here after pdb" )
(Pdb) c
Am here after pdb
Am going to assert now
  File "/tmp/test.py", line 25, in <module>
    main()
  File "/tmp/test.py", line 22, in main
    func()
  File "/tmp/test.py", line 16, in func
    print ( "Am here after pdb" )
> /tmp/test.py(16)func()
-> print ( "Am here after pdb" ) >>>> This should have been at the line corresponding to "Am going to assert now"
(Pdb)


This seems to be an bug ( due to a performance consideration ) with the way python bdb's set_continue() has been implemented -

https://hg.python.org/cpython/file/2.7/Lib/bdb.py#l227

    def set_continue(self):
        # Don't stop except at breakpoints or when finished
        self._set_stopinfo(self.botframe, None, -1)
        if not self.breaks:
            # no breakpoints; run without debugger overhead
            sys.settrace(None)
            frame = sys._getframe().f_back
            while frame and frame is not self.botframe:
                del frame.f_trace
                frame = frame.f_back

Basically what happens after "c" in a "(Pdb)" prompt is that bdb optimizes for the case where there are no more break points found by cleaning up the trace callback from all the frames.

However, all of this happens in the context of tracing itself and hence the trace_dispatch function in https://hg.python.org/cpython/file/2.7/Lib/bdb.py#l45 still returns back the trace_dispatch as the new system trace function. For more details on sys.settrace(), check https://docs.python.org/2/library/sys.html#sys.settrace

Check, the function trace_trampoline at https://hg.python.org/cpython/file/2.7/Python/sysmodule.c#l353
which sets f->f_trace back to result at https://hg.python.org/cpython/file/2.7/Python/sysmodule.c#l377

This seems to be an bug ( due to a performance consideration ) with the way python bdb's set_continue() has been implemented -

https://hg.python.org/cpython/file/2.7/Lib/bdb.py#l227

    def set_continue(self):
        # Don't stop except at breakpoints or when finished
        self._set_stopinfo(self.botframe, None, -1)
        if not self.breaks:
            # no breakpoints; run without debugger overhead
            sys.settrace(None)
            frame = sys._getframe().f_back
            while frame and frame is not self.botframe:
                del frame.f_trace
                frame = frame.f_back

Basically what happens after "c" in a "(Pdb)" prompt is that bdb optimizes for the case where there are no more break points found by cleaning up the trace callback from all the frames.

However, all of this happens in the context of tracing itself and hence the trace_dispatch function in https://hg.python.org/cpython/file/2.7/Lib/bdb.py#l45 still returns back the trace_dispatch as the new system trace function. For more details on sys.settrace(), check https://docs.python.org/2/library/sys.html#sys.settrace

Check, the function trace_trampoline at https://hg.python.org/cpython/file/2.7/Python/sysmodule.c#l353
which sets f->f_trace back to result at https://hg.python.org/cpython/file/2.7/Python/sysmodule.c#l377

Now, check the function PyFrame_GetLineNumber() which is used by the traceback to get the frame line number https://hg.python.org/cpython/file/2.7/Objects/frameobject.c#l63

int
PyFrame_GetLineNumber(PyFrameObject *f)
{
    if (f->f_trace)
        return f->f_lineno;
    else
        return PyCode_Addr2Line(f->f_code, f->f_lasti);
}

Basically this function returns back the stored f->f_lineno in case the f->f_trace is enabled.

The fix is fortunately simple - 

Just set self.trace_dispatch to None if pdb set_continue decides to run without debugger overhead.

----------
components: Library (Lib)
files: bdbfix.patch
keywords: patch
messages: 263553
nosy: Sriram Rajagopalan
priority: normal
severity: normal
status: open
title: pdb continue followed by an exception in the same frame shows incorrect frame linenumber
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/file42486/bdbfix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26779>
_______________________________________

From report at bugs.python.org  Sat Apr 16 09:18:40 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 16 Apr 2016 13:18:40 +0000
Subject: [issue26779] pdb continue followed by an exception in the same frame
 shows incorrect frame linenumber
In-Reply-To: <1460812092.64.0.640871964672.issue26779@psf.upfronthosting.co.za>
Message-ID: <1460812720.74.0.268704534303.issue26779@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +georg.brandl
versions:  -Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26779>
_______________________________________

From report at bugs.python.org  Sat Apr 16 09:21:01 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 16 Apr 2016 13:21:01 +0000
Subject: [issue26779] pdb continue followed by an exception in the same frame
 shows incorrect frame linenumber
In-Reply-To: <1460812092.64.0.640871964672.issue26779@psf.upfronthosting.co.za>
Message-ID: <1460812861.62.0.861985836113.issue26779@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26779>
_______________________________________

From report at bugs.python.org  Sat Apr 16 10:06:45 2016
From: report at bugs.python.org (Brandon Rhodes)
Date: Sat, 16 Apr 2016 14:06:45 +0000
Subject: [issue26780] Illustrate both binary operator conventions in PEP-8
Message-ID: <1460815604.66.0.184242188494.issue26780@psf.upfronthosting.co.za>


New submission from Brandon Rhodes:

I am delighted to see that PEP-8 has pivoted to breaking long formulae before, rather than after, each binary operator! But I would like to pivot the PEP away from citing my own PyCon Canada talk as the authority on the matter, and toward citing Knuth himself. It would also be an enhancement for the PEP to show both options and make an argument for the practice, instead of simply asserting that one is better than the other. I therefore propose the attached patch.

----------
assignee: docs at python
components: Documentation
files: pep8-knuth.patch
keywords: patch
messages: 263554
nosy: barry, brandon-rhodes, docs at python, gvanrossum
priority: normal
severity: normal
status: open
title: Illustrate both binary operator conventions in PEP-8
Added file: http://bugs.python.org/file42487/pep8-knuth.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26780>
_______________________________________

From report at bugs.python.org  Sat Apr 16 10:07:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Apr 2016 14:07:35 +0000
Subject: [issue26778] More typo fixes
In-Reply-To: <1460810974.92.0.431649847374.issue26778@psf.upfronthosting.co.za>
Message-ID: <1460815655.13.0.831831535109.issue26778@psf.upfronthosting.co.za>


Martin Panter added the comment:

Should exception messages be corrected in old versions, or just 3.6?

Apart from the few changes with comments, the rest look good to me.

I found some more cases (my patch is independent of Serhiy?s).

----------
Added file: http://bugs.python.org/file42488/an-consonant.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26778>
_______________________________________

From report at bugs.python.org  Sat Apr 16 10:08:37 2016
From: report at bugs.python.org (Brandon Rhodes)
Date: Sat, 16 Apr 2016 14:08:37 +0000
Subject: [issue26780] Illustrate both binary operator conventions in PEP-8
In-Reply-To: <1460815604.66.0.184242188494.issue26780@psf.upfronthosting.co.za>
Message-ID: <1460815717.36.0.211476748804.issue26780@psf.upfronthosting.co.za>


Changes by Brandon Rhodes <brandon at rhodesmill.org>:


Removed file: http://bugs.python.org/file42487/pep8-knuth.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26780>
_______________________________________

From report at bugs.python.org  Sat Apr 16 10:09:11 2016
From: report at bugs.python.org (Brandon Rhodes)
Date: Sat, 16 Apr 2016 14:09:11 +0000
Subject: [issue26780] Illustrate both binary operator conventions in PEP-8
In-Reply-To: <1460815604.66.0.184242188494.issue26780@psf.upfronthosting.co.za>
Message-ID: <1460815751.35.0.272995762823.issue26780@psf.upfronthosting.co.za>


Changes by Brandon Rhodes <brandon at rhodesmill.org>:


Added file: http://bugs.python.org/file42489/pep8-knuth.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26780>
_______________________________________

From report at bugs.python.org  Sat Apr 16 10:11:11 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 16 Apr 2016 14:11:11 +0000
Subject: [issue26781] os.walk max_depth
Message-ID: <1460815870.93.0.432472188169.issue26781@psf.upfronthosting.co.za>


New submission from Aviv Palivoda:

I am suggesting to add max_depth argument to os.walk. I think this is very useful for two cases. The trivial one is when someone wants to walk on a directory tree up to specific depth. The second one is when you follow symlinks and wish to avoid infinite loop.

The patch add the max_depth both to os.walk and os.fwalk.

----------
components: Library (Lib)
files: os-walk-max-depth.patch
keywords: patch
messages: 263556
nosy: loewis, palaviv
priority: normal
severity: normal
status: open
title: os.walk max_depth
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42490/os-walk-max-depth.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26781>
_______________________________________

From report at bugs.python.org  Sat Apr 16 10:23:28 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Apr 2016 14:23:28 +0000
Subject: [issue26782] subprocess.__all__ incomplete on Windows
Message-ID: <1460816608.8.0.0902250991116.issue26782@psf.upfronthosting.co.za>


New submission from Martin Panter:

After enabling test__all__() in test_subprocess on Windows (see Issue 10838), I find that STARTUPINFO is missing from __all__, and there is a class Handle that is ambiguous. Handle doesn?t seem to be documented, so I propose to add it to the intentionally-excluded list.

In Python 3.5 I will fix the test to exclude STARTUPINFO from __all__.

----------
components: Windows
files: subprocess-all.patch
keywords: patch
messages: 263557
nosy: martin.panter, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: subprocess.__all__ incomplete on Windows
versions: Python 3.6
Added file: http://bugs.python.org/file42491/subprocess-all.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26782>
_______________________________________

From report at bugs.python.org  Sat Apr 16 10:24:27 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 16 Apr 2016 14:24:27 +0000
Subject: [issue26783] test_os.WalkTests.test_walk_topdown don't test fwalk and
 Bytes
Message-ID: <1460816667.71.0.632457277114.issue26783@psf.upfronthosting.co.za>


New submission from Aviv Palivoda:

test_walk_topdown call os.walk directly instead of using self.walk. This test currently run 3 time's while checking the same thing. The test should use self.walk to check fwalk and Bytes as well.

----------
components: Tests
files: os-test-walk-topdown-use-self-walk.patch
keywords: patch
messages: 263558
nosy: loewis, palaviv
priority: normal
severity: normal
status: open
title: test_os.WalkTests.test_walk_topdown don't test fwalk and Bytes
versions: Python 3.6
Added file: http://bugs.python.org/file42492/os-test-walk-topdown-use-self-walk.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26783>
_______________________________________

From report at bugs.python.org  Sat Apr 16 10:34:32 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Apr 2016 14:34:32 +0000
Subject: [issue26775] Improve test coverage on urllib.parse
In-Reply-To: <1460789669.45.0.432751253755.issue26775@psf.upfronthosting.co.za>
Message-ID: <20160416143429.8340.59658.BB381CDE@psf.io>


Roundup Robot added the comment:

New changeset 8f02747ff908 by Senthil Kumaran in branch '3.5':
issue26775 - Improve test coverage for urllib.parse
https://hg.python.org/cpython/rev/8f02747ff908

New changeset 401dca6ac084 by Senthil Kumaran in branch 'default':
merge 3.5
https://hg.python.org/cpython/rev/401dca6ac084

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26775>
_______________________________________

From report at bugs.python.org  Sat Apr 16 10:35:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Apr 2016 14:35:40 +0000
Subject: [issue26778] More typo fixes
In-Reply-To: <1460810974.92.0.431649847374.issue26778@psf.upfronthosting.co.za>
Message-ID: <1460817340.22.0.58156262828.issue26778@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you all for your reviews. Martin's patch LGTM.

I agree that it would be safer to not change error messages in bugfix releases. Here is consolidated patch with fixed errors.

----------
Added file: http://bugs.python.org/file42493/typos2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26778>
_______________________________________

From report at bugs.python.org  Sat Apr 16 10:36:15 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 16 Apr 2016 14:36:15 +0000
Subject: [issue26775] Improve test coverage on urllib.parse
In-Reply-To: <1460789669.45.0.432751253755.issue26775@psf.upfronthosting.co.za>
Message-ID: <1460817375.77.0.269393545104.issue26775@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for your contribution, Luiz. It's a useful improvement.
Committed to all active branches.

2.7 changeset: 101012:e3ed950ad728

----------
nosy: +orsenthil
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26775>
_______________________________________

From report at bugs.python.org  Sat Apr 16 10:36:43 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Apr 2016 14:36:43 +0000
Subject: [issue10838] subprocess __all__ is incomplete
In-Reply-To: <1294260769.5.0.0970426129524.issue10838@psf.upfronthosting.co.za>
Message-ID: <1460817403.86.0.98979947864.issue10838@psf.upfronthosting.co.za>


Martin Panter added the comment:

See Issue 26782 for a follow-up with Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10838>
_______________________________________

From report at bugs.python.org  Sat Apr 16 10:49:41 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Apr 2016 14:49:41 +0000
Subject: [issue26783] test_os.WalkTests.test_walk_topdown don't test fwalk and
 Bytes
In-Reply-To: <1460816667.71.0.632457277114.issue26783@psf.upfronthosting.co.za>
Message-ID: <1460818181.79.0.445088994874.issue26783@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch LGTM. Thank you Aviv.

----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka
stage:  -> commit review
type:  -> behavior
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26783>
_______________________________________

From report at bugs.python.org  Sat Apr 16 10:51:45 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Apr 2016 14:51:45 +0000
Subject: [issue26783] test_os.WalkTests.test_walk_topdown don't test fwalk and
 Bytes
In-Reply-To: <1460816667.71.0.632457277114.issue26783@psf.upfronthosting.co.za>
Message-ID: <20160416145138.70529.36770.FC06E10F@psf.io>


Roundup Robot added the comment:

New changeset e44a2dc62c11 by Serhiy Storchaka in branch '3.5':
Issue #26783: test_os.WalkTests.test_walk_topdown did't test fwalk and bytes.
https://hg.python.org/cpython/rev/e44a2dc62c11

New changeset be96434b8777 by Serhiy Storchaka in branch 'default':
Issue #26783: test_os.WalkTests.test_walk_topdown did't test fwalk and bytes.
https://hg.python.org/cpython/rev/be96434b8777

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26783>
_______________________________________

From report at bugs.python.org  Sat Apr 16 10:52:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Apr 2016 14:52:39 +0000
Subject: [issue26783] test_os.WalkTests.test_walk_topdown don't test fwalk and
 Bytes
In-Reply-To: <1460816667.71.0.632457277114.issue26783@psf.upfronthosting.co.za>
Message-ID: <1460818359.28.0.910354054101.issue26783@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26783>
_______________________________________

From report at bugs.python.org  Sat Apr 16 11:47:52 2016
From: report at bugs.python.org (random832)
Date: Sat, 16 Apr 2016 15:47:52 +0000
Subject: [issue26781] os.walk max_depth
In-Reply-To: <1460815870.93.0.432472188169.issue26781@psf.upfronthosting.co.za>
Message-ID: <1460821671.99.0.899027012004.issue26781@psf.upfronthosting.co.za>


random832 added the comment:

Wouldn't the "symlink infinite loop" case be better handled by making it track where it's already been? This can be done by inode and dev number on Unix; I'm not sure what equivalent exists on Windows (though symlinks are uncommon on Windows) but you could fall back on realpath.

----------
nosy: +random832

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26781>
_______________________________________

From report at bugs.python.org  Sat Apr 16 12:05:46 2016
From: report at bugs.python.org (random832)
Date: Sat, 16 Apr 2016 16:05:46 +0000
Subject: [issue17859] improve error message for saving ints to file
In-Reply-To: <1367134676.21.0.161863892006.issue17859@psf.upfronthosting.co.za>
Message-ID: <1460822746.53.0.100850885666.issue17859@psf.upfronthosting.co.za>


random832 added the comment:

This bug should be closed since #16518 was accepted and the error is now "TypeError: a bytes-like object is required, not 'int'"

----------
nosy: +random832

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17859>
_______________________________________

From report at bugs.python.org  Sat Apr 16 12:14:57 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Apr 2016 16:14:57 +0000
Subject: [issue17859] improve error message for saving ints to file
In-Reply-To: <1367134676.21.0.161863892006.issue17859@psf.upfronthosting.co.za>
Message-ID: <1460823297.89.0.532746411416.issue17859@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> add "buffer protocol" to glossary

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17859>
_______________________________________

From report at bugs.python.org  Sat Apr 16 12:41:35 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 16 Apr 2016 16:41:35 +0000
Subject: [issue24922] assertWarnsRegex doesn't allow multiple warning messages
In-Reply-To: <1440425748.63.0.780438690591.issue24922@psf.upfronthosting.co.za>
Message-ID: <1460824895.31.0.469507816257.issue24922@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
components: +Library (Lib) -Interpreter Core
type: behavior -> enhancement
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24922>
_______________________________________

From report at bugs.python.org  Sat Apr 16 12:48:11 2016
From: report at bugs.python.org (Marcus)
Date: Sat, 16 Apr 2016 16:48:11 +0000
Subject: [issue26784] regular expression problem at umlaut handling
Message-ID: <1460825291.89.0.971564767313.issue26784@psf.upfronthosting.co.za>


New submission from Marcus:

Working with this example string "E-112233-555-11 | Bl?h - Bl?h" with the following code leeds under python 2.7.10 (OSX) to an exception whereas the same code works under python 3.5.1 (OSX).

s = "E-112233-555-11 | Bl?h - Bl?h"

expr = re.compile(r"(?P<p>[A-Z]{1}-[0-9]{0,}(-[0-9]{0,}(-[0-9]{0,})?)?)?(( [|] )?(?P<a>[\s\w]*)?)? - (?P<j>[\s\w]*)?",re.UNICODE)
res = re.match(expr,s)
a = (res.group('p'), res.group('a'), res.group('j'))
print(a)


When I change the first umlaut in "Bl?h" from ? to ? it works as expected on python 2 and 3. A change from ? to ? however leeds to a crash again.

Ideas?

----------
messages: 263567
nosy: arbyter
priority: normal
severity: normal
status: open
title: regular expression problem at umlaut handling
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26784>
_______________________________________

From report at bugs.python.org  Sat Apr 16 13:11:18 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 16 Apr 2016 17:11:18 +0000
Subject: [issue26784] regular expression problem at umlaut handling
In-Reply-To: <1460825291.89.0.971564767313.issue26784@psf.upfronthosting.co.za>
Message-ID: <1460826678.04.0.27965798611.issue26784@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Regular Expressions
nosy: +ezio.melotti, mrabarnett, pitrou, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26784>
_______________________________________

From report at bugs.python.org  Sat Apr 16 13:13:17 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 16 Apr 2016 17:13:17 +0000
Subject: [issue20739] PEP 463 (except expression) implementation
In-Reply-To: <1393113417.21.0.308711390279.issue20739@psf.upfronthosting.co.za>
Message-ID: <1460826797.65.0.341278183137.issue20739@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20739>
_______________________________________

From report at bugs.python.org  Sat Apr 16 13:34:15 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 16 Apr 2016 17:34:15 +0000
Subject: [issue21274] define PATH_MAX for GNU/Hurd in Python/pythonrun.c
In-Reply-To: <1397687576.16.0.104530346632.issue21274@psf.upfronthosting.co.za>
Message-ID: <1460828055.83.0.258287829016.issue21274@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Python 3.4 is in security-fix-only mode so we can close this now.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21274>
_______________________________________

From report at bugs.python.org  Sat Apr 16 13:41:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Apr 2016 17:41:33 +0000
Subject: [issue26784] regular expression problem at umlaut handling
In-Reply-To: <1460825291.89.0.971564767313.issue26784@psf.upfronthosting.co.za>
Message-ID: <1460828493.99.0.935073707321.issue26784@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

First, in the context of Python a crash means a core dump or an analogue on Windows. In this case the code just works not as you expected.

The short answer: s should be a unicode.

In your code "?" is encoded as 8-bit string '\xc3\xa4'. When matched, every bytes is independently expanded to Unicode range. The first byte becomes u'\xc3' = u'?', the second byte becomes u'?', non-alphanumeric. '[\s\w]*' doesn't match u'??'.

"?" is encoded as 8-bit string '\xc3\xbc'. The second byte becomes u'?', numeric. '[\s\w]*' matches u'??'.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26784>
_______________________________________

From report at bugs.python.org  Sat Apr 16 13:54:11 2016
From: report at bugs.python.org (Marcus)
Date: Sat, 16 Apr 2016 17:54:11 +0000
Subject: [issue26784] regular expression problem at umlaut handling
In-Reply-To: <1460825291.89.0.971564767313.issue26784@psf.upfronthosting.co.za>
Message-ID: <1460829251.88.0.797134601026.issue26784@psf.upfronthosting.co.za>


Marcus added the comment:

Thx for your explanation. You explained why [\s\w] didn't match for "?". In my situation it didn't matches for the first "?" but the second time I used [\s\w] in the same regex it matched at the second "?". What's the explanation for this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26784>
_______________________________________

From report at bugs.python.org  Sat Apr 16 14:03:13 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Apr 2016 18:03:13 +0000
Subject: [issue24922] assertWarnsRegex doesn't allow multiple warning messages
In-Reply-To: <1440425748.63.0.780438690591.issue24922@psf.upfronthosting.co.za>
Message-ID: <1460829793.38.0.763243342503.issue24922@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think there is a little need for this feature. On other hand, its use looks complicated, and it will likely complicate the implementation.

If tested types are same, but messages differ, messages can be combined in on regex: 'msg1|msg2'.

If tested types differ, but messages are same, this case is already supported.

If tested types and messages differ, you can test with combined regex, and then check a context manager object that the message matches the type. But this is very rare case.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24922>
_______________________________________

From report at bugs.python.org  Sat Apr 16 14:10:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Apr 2016 18:10:10 +0000
Subject: [issue26784] regular expression problem at umlaut handling
In-Reply-To: <1460825291.89.0.971564767313.issue26784@psf.upfronthosting.co.za>
Message-ID: <1460830210.95.0.921581418304.issue26784@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Sorry, I don't understand you. If the regex failed to match the first "?", it can't match the second "?". Do you have an example?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26784>
_______________________________________

From report at bugs.python.org  Sat Apr 16 14:14:37 2016
From: report at bugs.python.org (Brandon Rhodes)
Date: Sat, 16 Apr 2016 18:14:37 +0000
Subject: [issue26780] Illustrate both binary operator conventions in PEP-8
In-Reply-To: <1460815604.66.0.184242188494.issue26780@psf.upfronthosting.co.za>
Message-ID: <1460830477.17.0.654752736917.issue26780@psf.upfronthosting.co.za>


Brandon Rhodes added the comment:

Another important objection against the current text is that it stacks a series of `and` and `or` operators at the same level of indentation, as though they naturally evaluate in the order the programmer writes them. In fact, they have different levels of precedence, and the code example violates the other sections of PEP-8 that ask for the creation of a visual distinction in code between different precedence levels.

The example needs to pivot towards a series of operators which belong at the same precedence level. I have used `+` and `-` because they seemed more natural to form an example from than something like division and multiplication.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26780>
_______________________________________

From report at bugs.python.org  Sat Apr 16 14:14:59 2016
From: report at bugs.python.org (Brandon Rhodes)
Date: Sat, 16 Apr 2016 18:14:59 +0000
Subject: [issue26780] Illustrate both binary operator conventions in PEP-8
In-Reply-To: <1460815604.66.0.184242188494.issue26780@psf.upfronthosting.co.za>
Message-ID: <1460830499.39.0.446563619869.issue26780@psf.upfronthosting.co.za>


Changes by Brandon Rhodes <brandon at rhodesmill.org>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26780>
_______________________________________

From report at bugs.python.org  Sat Apr 16 14:25:35 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 16 Apr 2016 18:25:35 +0000
Subject: [issue24922] assertWarnsRegex doesn't allow multiple warning messages
In-Reply-To: <1440425748.63.0.780438690591.issue24922@psf.upfronthosting.co.za>
Message-ID: <1460831135.47.0.0816882389215.issue24922@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Agreed. Let's close this then.

----------
nosy: +berker.peksag
resolution:  -> rejected
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24922>
_______________________________________

From report at bugs.python.org  Sat Apr 16 14:32:36 2016
From: report at bugs.python.org (Marcus)
Date: Sat, 16 Apr 2016 18:32:36 +0000
Subject: [issue26784] regular expression problem at umlaut handling
In-Reply-To: <1460825291.89.0.971564767313.issue26784@psf.upfronthosting.co.za>
Message-ID: <1460831556.01.0.910451768267.issue26784@psf.upfronthosting.co.za>


Marcus added the comment:

When I replace the first "?" with a random letter the untouched expression has not problems to match the second word which contains also an "?"

s = "E-112233-555-11 | Bl?h - Bl?h" #untuched string
s = "E-112233-555-11 | Bloh - Bl?h" #string where the first ? is replaced by an "o"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26784>
_______________________________________

From report at bugs.python.org  Sat Apr 16 14:32:48 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 16 Apr 2016 18:32:48 +0000
Subject: [issue26781] os.walk max_depth
In-Reply-To: <1460815870.93.0.432472188169.issue26781@psf.upfronthosting.co.za>
Message-ID: <1460831568.86.0.0535223525097.issue26781@psf.upfronthosting.co.za>


Changes by Aviv Palivoda <palaviv at gmail.com>:


Added file: http://bugs.python.org/file42494/os-walk-max-depth-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26781>
_______________________________________

From report at bugs.python.org  Sat Apr 16 14:44:53 2016
From: report at bugs.python.org (Hrvoje Abraham)
Date: Sat, 16 Apr 2016 18:44:53 +0000
Subject: [issue26785] repr of -nan value should contain the sign
Message-ID: <1460832293.23.0.989531230725.issue26785@psf.upfronthosting.co.za>


New submission from Hrvoje Abraham:

repr of -nan value should contain the sign so the round-trip could be assured. NaN value sign (bit) could be seen as not relevant or even uninterpretable information, but it is actually used in real-life situations, the fact substantiated by section 6.3 of IEEE-754 2008 standard.

>>> from math import copysign
>>> x = float("-nan")
>>> copysign(1.0, x)
-1.0

This is correct. Also proves the value contains the sign information.

>>> repr(x)
nan

Not correct. Should be '-nan'.

----------
components: Interpreter Core
messages: 263576
nosy: ahrvoje
priority: normal
severity: normal
status: open
title: repr of -nan value should contain the sign
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/issue26785>
_______________________________________

From report at bugs.python.org  Sat Apr 16 14:48:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Apr 2016 18:48:00 +0000
Subject: [issue26784] regular expression problem at umlaut handling
In-Reply-To: <1460825291.89.0.971564767313.issue26784@psf.upfronthosting.co.za>
Message-ID: <1460832480.42.0.854467678329.issue26784@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Because "[\s\w]*" matches only a part of "Bl?h": "Bl\xc3".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26784>
_______________________________________

From report at bugs.python.org  Sat Apr 16 14:50:50 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Apr 2016 18:50:50 +0000
Subject: [issue26785] repr of -nan value should contain the sign
In-Reply-To: <1460832293.23.0.989531230725.issue26785@psf.upfronthosting.co.za>
Message-ID: <1460832650.65.0.0613347701126.issue26785@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26785>
_______________________________________

From report at bugs.python.org  Sat Apr 16 15:14:55 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Apr 2016 19:14:55 +0000
Subject: [issue23029] test_warnings produces extra output in quiet mode
In-Reply-To: <1418249291.77.0.334327768838.issue23029@psf.upfronthosting.co.za>
Message-ID: <20160416191452.107524.94383.A1132411@psf.io>


Roundup Robot added the comment:

New changeset 009e36e6d16d by Berker Peksag in branch '2.7':
Issue #23029: Fix catch_warnings() in test_filename_none
https://hg.python.org/cpython/rev/009e36e6d16d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23029>
_______________________________________

From report at bugs.python.org  Sat Apr 16 15:15:31 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 16 Apr 2016 19:15:31 +0000
Subject: [issue23029] test_warnings produces extra output in quiet mode
In-Reply-To: <1418249291.77.0.334327768838.issue23029@psf.upfronthosting.co.za>
Message-ID: <1460834131.15.0.879920979632.issue23029@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23029>
_______________________________________

From report at bugs.python.org  Sat Apr 16 15:15:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Apr 2016 19:15:46 +0000
Subject: [issue26781] os.walk max_depth
In-Reply-To: <1460815870.93.0.432472188169.issue26781@psf.upfronthosting.co.za>
Message-ID: <1460834146.03.0.286779109111.issue26781@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

os.walk() allows more flexible control.

    for root, dirs, files in os.walk(top):
        if is_too_deep(root):
            dirs.clear()
            continue
        ...

You can even walk up to different depth on different parts of the tree. You can limit walking not by the directory depth, but by the length of the path, or the number of links in the path, or what-you-need. Adding separate parameters for all this particular cases is not practical.

I think there is a little need in this feature.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26781>
_______________________________________

From report at bugs.python.org  Sat Apr 16 15:17:39 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 Apr 2016 19:17:39 +0000
Subject: [issue25731] Assigning and deleting __new__ attr on the class does
 not allow to create instances of this class
In-Reply-To: <1448454590.41.0.350843358205.issue25731@psf.upfronthosting.co.za>
Message-ID: <1460834259.17.0.511393680512.issue25731@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I believe the correct behavior is actually

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "bar.py", line 7, in <module>
    C()
TypeError: foo.A.__new__(C) is not safe, use foo.B.__new__()

This is because A comes before B in the mro, and, indeed, constructing C with A.__new__ is unsafe. In fact, reordering A and B in the definition of C fixes everything.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25731>
_______________________________________

From report at bugs.python.org  Sat Apr 16 15:28:03 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 16 Apr 2016 19:28:03 +0000
Subject: [issue25989] documentation version switcher is broken fro 2.6, 3.2,
 3.3
In-Reply-To: <1451692017.71.0.123733949867.issue25989@psf.upfronthosting.co.za>
Message-ID: <1460834883.61.0.153165163675.issue25989@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report, but as I said in the GitHub issue, the version switcher works as expected (we don't build docs of security-only-fix branches).

----------
nosy: +berker.peksag
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25989>
_______________________________________

From report at bugs.python.org  Sat Apr 16 15:36:04 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 16 Apr 2016 19:36:04 +0000
Subject: [issue13340] list.index does not accept None as start or stop
In-Reply-To: <1320398584.03.0.145013152611.issue13340@psf.upfronthosting.co.za>
Message-ID: <1460835364.14.0.0895644527417.issue13340@psf.upfronthosting.co.za>


Berker Peksag added the comment:

See http://thread.gmane.org/gmane.comp.python.devel/127502 for the python-dev thread.

----------
nosy: +berker.peksag
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13340>
_______________________________________

From report at bugs.python.org  Sat Apr 16 15:45:06 2016
From: report at bugs.python.org (Hrvoje Abraham)
Date: Sat, 16 Apr 2016 19:45:06 +0000
Subject: [issue26785] repr of -nan value should contain the sign
In-Reply-To: <1460832293.23.0.989531230725.issue26785@psf.upfronthosting.co.za>
Message-ID: <1460835906.79.0.186650929685.issue26785@psf.upfronthosting.co.za>


Hrvoje Abraham added the comment:

Reported issue was created in 64-bit Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:54:25) [MSC v.1900 64 bit (AMD64)] on win32.

Now I noticed that in Py 2.7 even copysign part does not work as expected.

Python 2.7.11 (v2.7.11:6d1b6a68f775, Dec  5 2015, 20:40:30) [MSC v.1500 64 bit (AMD64)] on win32:

>>> from math import copysign
>>> x = float("-nan")
>>> copysign(1.0, x)
1.0

Not correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26785>
_______________________________________

From report at bugs.python.org  Sat Apr 16 15:51:58 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 16 Apr 2016 19:51:58 +0000
Subject: [issue15933] flaky test in test_datetime
In-Reply-To: <1347466816.36.0.945599436453.issue15933@psf.upfronthosting.co.za>
Message-ID: <1460836318.1.0.871128557489.issue15933@psf.upfronthosting.co.za>


Berker Peksag added the comment:

The assert was changed (somewhat similar to issue15933.diff) in bc67e8d39164. I've checked last 18 builds (from 800 to 818) on http://buildbot.python.org/all/builders/x86%20OpenIndiana%203.5 and test_today wasn't one of the failed tests. I'm closing this as outdated.

----------
nosy: +berker.peksag
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15933>
_______________________________________

From report at bugs.python.org  Sat Apr 16 16:14:28 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Apr 2016 20:14:28 +0000
Subject: [issue24173] curses HOWTO/implementation disagreement
In-Reply-To: <1431506529.99.0.82682445605.issue24173@psf.upfronthosting.co.za>
Message-ID: <20160416201425.70527.2271.16B6C4B9@psf.io>


Roundup Robot added the comment:

New changeset 5c9cda2bdfd2 by Berker Peksag in branch '2.7':
Issue #24173: Fix curses.wrapper link in curses HOWTO
https://hg.python.org/cpython/rev/5c9cda2bdfd2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24173>
_______________________________________

From report at bugs.python.org  Sat Apr 16 16:15:17 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 16 Apr 2016 20:15:17 +0000
Subject: [issue24173] curses HOWTO/implementation disagreement
In-Reply-To: <1431506529.99.0.82682445605.issue24173@psf.upfronthosting.co.za>
Message-ID: <1460837717.5.0.203374027496.issue24173@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report! 3.x docs have already been updated.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24173>
_______________________________________

From report at bugs.python.org  Sat Apr 16 16:24:00 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 16 Apr 2016 20:24:00 +0000
Subject: [issue7694] DeprecationWarnings in distutils are pointless
In-Reply-To: <1263401319.23.0.932890994142.issue7694@psf.upfronthosting.co.za>
Message-ID: <1460838240.73.0.814064580226.issue7694@psf.upfronthosting.co.za>


Berker Peksag added the comment:

> [...] I think the DeprecationWarnings in distutils should just be removed, as they serve no useful purpose.

There are no DeprecationWarning warnings (only four PendingDeprecationWarning warnings -- two of them are for 'check_metadata') in distutils codebase in both 2.7 and 3.x anymore.

Closing this as out of date.

----------
nosy: +berker.peksag
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7694>
_______________________________________

From report at bugs.python.org  Sat Apr 16 16:27:55 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 16 Apr 2016 20:27:55 +0000
Subject: [issue25642] Setting maxsize breaks asyncio.JoinableQueue/Queue
In-Reply-To: <1447720653.5.0.538430267197.issue25642@psf.upfronthosting.co.za>
Message-ID: <1460838475.42.0.19391196954.issue25642@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage:  -> resolved
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25642>
_______________________________________

From report at bugs.python.org  Sat Apr 16 16:37:09 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 16 Apr 2016 20:37:09 +0000
Subject: [issue19791] test_pathlib should use can_symlink or
 skip_unless_symlink from test.support
In-Reply-To: <1385449388.05.0.507393772442.issue19791@psf.upfronthosting.co.za>
Message-ID: <1460839029.91.0.274099733831.issue19791@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
stage:  -> patch review
type: behavior -> enhancement
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19791>
_______________________________________

From report at bugs.python.org  Sat Apr 16 17:12:32 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 16 Apr 2016 21:12:32 +0000
Subject: [issue26780] Illustrate both binary operator conventions in PEP-8
In-Reply-To: <1460815604.66.0.184242188494.issue26780@psf.upfronthosting.co.za>
Message-ID: <1460841152.81.0.460743121792.issue26780@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Patch LGTM.

Note that the and/or example was in the PEP before this discussion broke out.

The discussion also at some point (before your Knuth quote was discovered) veered in the direction of making and/or a special case, perhaps because it's more likely that a long expression must be broken around and/or operators. And there were already examples of breaking after binary arithmetic operators elsewhere in the PEP (I think).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26780>
_______________________________________

From report at bugs.python.org  Sat Apr 16 17:22:20 2016
From: report at bugs.python.org (Ellison Marks)
Date: Sat, 16 Apr 2016 21:22:20 +0000
Subject: [issue26571] turtle regression in 3.5
In-Reply-To: <1458104355.45.0.620158354917.issue26571@psf.upfronthosting.co.za>
Message-ID: <1460841740.89.0.0931493681872.issue26571@psf.upfronthosting.co.za>


Ellison Marks added the comment:

Just as an update, I've been working around this by manually setting TurtleScreen._RUNNING to True before calling Turtle() again, which produces the desired behaviour in both 3.4 and 3.5. Haven't noticed any bad effects so far.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26571>
_______________________________________

From report at bugs.python.org  Sat Apr 16 17:23:55 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 Apr 2016 21:23:55 +0000
Subject: [issue26751] Possible bug in sorting algorithm
In-Reply-To: <1460596491.57.0.479961799171.issue26751@psf.upfronthosting.co.za>
Message-ID: <1460841835.68.0.432394705835.issue26751@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/issue26751>
_______________________________________

From report at bugs.python.org  Sat Apr 16 17:54:40 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Apr 2016 21:54:40 +0000
Subject: [issue26659] slice() leaks memory when part of a cycle
In-Reply-To: <1459195650.62.0.697543008617.issue26659@psf.upfronthosting.co.za>
Message-ID: <20160416215437.26083.34084.3631F925@psf.io>


Roundup Robot added the comment:

New changeset 879da9400529 by Benjamin Peterson in branch '2.7':
add gc support to slice (closes #26659)
https://hg.python.org/cpython/rev/879da9400529

New changeset 9e2176d18965 by Benjamin Peterson in branch '3.5':
add gc support to slice (closes #26659)
https://hg.python.org/cpython/rev/9e2176d18965

New changeset 870fcc50f1bd by Benjamin Peterson in branch 'default':
merge 3.5 (#26659)
https://hg.python.org/cpython/rev/870fcc50f1bd

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26659>
_______________________________________

From report at bugs.python.org  Sat Apr 16 18:06:30 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Sat, 16 Apr 2016 22:06:30 +0000
Subject: [issue26786] bdist_msi duplicates directories with names in ALL CAPS
 to a bogus location
Message-ID: <1460844390.43.0.520967711704.issue26786@psf.upfronthosting.co.za>


New submission from Ivan Pozdeev:

If a package has directories with names in APP CAPS, distutils.commands.bdist_msi creates properties for them that are also in all caps.

Such properties are handled specially by MSI and are called "public properties (http://www.advancedinstaller.com/user-guide/properties.html).

Due to the way bdist_msi-produced .msi's work, this ultimately results in subtrees of these directories being duplicated to a bogus location (the root directory of the drive on which the .msi being installed is).

E.g. in the attached example, all <python>\Lib\mercurial\locale\<code>\LC_MESSAGES subtrees got duplicated to D:\Lib\<etc>.

See https://bz.mercurial-scm.org/show_bug.cgi?id=5192 for details (including a high-level description of how bdist_msi packages work).

----------
components: Distutils, Library (Lib), Windows
files: mercurial-3.3.2.log.gz
messages: 263591
nosy: Ivan.Pozdeev, dstufft, eric.araujo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: bdist_msi duplicates directories with names in ALL CAPS to a bogus location
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/file42495/mercurial-3.3.2.log.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26786>
_______________________________________

From report at bugs.python.org  Sat Apr 16 18:52:29 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Apr 2016 22:52:29 +0000
Subject: [issue26659] slice() leaks memory when part of a cycle
In-Reply-To: <1459195650.62.0.697543008617.issue26659@psf.upfronthosting.co.za>
Message-ID: <1460847149.79.0.545100008639.issue26659@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26659>
_______________________________________

From report at bugs.python.org  Sat Apr 16 19:51:54 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Apr 2016 23:51:54 +0000
Subject: [issue26782] subprocess.__all__ incomplete on Windows
In-Reply-To: <1460816608.8.0.0902250991116.issue26782@psf.upfronthosting.co.za>
Message-ID: <20160416235151.4321.24130.51BD460F@psf.io>


Roundup Robot added the comment:

New changeset 386712b16c74 by Martin Panter in branch '3.5':
Issue #26782: Acknowledge the incomplete status of __all__ in 3.5
https://hg.python.org/cpython/rev/386712b16c74

New changeset 728370e7a29d by Martin Panter in branch 'default':
Issue #26782: Merge test_subprocess from 3.5
https://hg.python.org/cpython/rev/728370e7a29d

New changeset 3e93ac5a7afa by Martin Panter in branch 'default':
Issue #26782: Add STARTUPINFO to subprocess.__all__ on Windows
https://hg.python.org/cpython/rev/3e93ac5a7afa

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26782>
_______________________________________

From report at bugs.python.org  Sat Apr 16 19:54:11 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 16 Apr 2016 23:54:11 +0000
Subject: [issue26785] repr of -nan value should contain the sign
In-Reply-To: <1460832293.23.0.989531230725.issue26785@psf.upfronthosting.co.za>
Message-ID: <1460850851.95.0.0589950008343.issue26785@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26785>
_______________________________________

From report at bugs.python.org  Sat Apr 16 19:55:29 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 16 Apr 2016 23:55:29 +0000
Subject: [issue26785] repr of -nan value should contain the sign
In-Reply-To: <1460832293.23.0.989531230725.issue26785@psf.upfronthosting.co.za>
Message-ID: <1460850929.53.0.358985140869.issue26785@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Changing versions.

I left in 2.7, but I doubt we'd make any changes to 2.7 with regards to this.

----------
versions:  -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26785>
_______________________________________

From report at bugs.python.org  Sat Apr 16 20:21:47 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 17 Apr 2016 00:21:47 +0000
Subject: [issue26778] More typo fixes
In-Reply-To: <1460810974.92.0.431649847374.issue26778@psf.upfronthosting.co.za>
Message-ID: <1460852507.67.0.994710598861.issue26778@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think there are two outstanding problems; see Lib/tkinter/tix.py and Misc/HISTORY.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26778>
_______________________________________

From report at bugs.python.org  Sat Apr 16 20:24:31 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 17 Apr 2016 00:24:31 +0000
Subject: [issue23883] __all__ lists are incomplete
In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za>
Message-ID: <1460852671.92.0.425019569861.issue23883@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
dependencies: +subprocess.__all__ incomplete on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23883>
_______________________________________

From report at bugs.python.org  Sat Apr 16 21:40:25 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 Apr 2016 01:40:25 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
 mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <20160417014021.12739.67558.B2D8D2CD@psf.io>


Roundup Robot added the comment:

New changeset eef8f72ddb00 by Martin Panter in branch '2.7':
Issue #4806: Avoid masking TypeError when *-unpacking a generator
https://hg.python.org/cpython/rev/eef8f72ddb00

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4806>
_______________________________________

From report at bugs.python.org  Sat Apr 16 23:04:43 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 Apr 2016 03:04:43 +0000
Subject: [issue26717] wsgiref.simple_server: mojibake with cp1252 bytes in
 PATH_INFO
In-Reply-To: <1460148485.6.0.00224363970956.issue26717@psf.upfronthosting.co.za>
Message-ID: <20160417030440.415.34377.F679171D@psf.io>


Roundup Robot added the comment:

New changeset 1f2cfcd5a83f by Martin Panter in branch '3.5':
Issue #26717: Stop encoding Latin-1-ized WSGI paths with UTF-8
https://hg.python.org/cpython/rev/1f2cfcd5a83f

New changeset 815a4ac67e68 by Martin Panter in branch 'default':
Issue #26717: Merge wsgiref fix from 3.5
https://hg.python.org/cpython/rev/815a4ac67e68

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26717>
_______________________________________

From report at bugs.python.org  Sat Apr 16 23:34:44 2016
From: report at bugs.python.org (Josh Snider)
Date: Sun, 17 Apr 2016 03:34:44 +0000
Subject: [issue26554] PC\bdist_wininst\install.c: Missing call to fclose()
In-Reply-To: <1457949701.38.0.834751371072.issue26554@psf.upfronthosting.co.za>
Message-ID: <1460864084.98.0.763258163318.issue26554@psf.upfronthosting.co.za>


Josh Snider added the comment:

I suggested some changes to your patch. Your patch should also add your name to the Misc/ACKS file as I don't currently see an Aatish listed there.

----------
nosy: +Josh Snider

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26554>
_______________________________________

From report at bugs.python.org  Sat Apr 16 23:54:19 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 17 Apr 2016 03:54:19 +0000
Subject: [issue26782] subprocess.__all__ incomplete on Windows
In-Reply-To: <1460816608.8.0.0902250991116.issue26782@psf.upfronthosting.co.za>
Message-ID: <1460865259.75.0.716639872083.issue26782@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26782>
_______________________________________

From report at bugs.python.org  Sun Apr 17 00:00:20 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 17 Apr 2016 04:00:20 +0000
Subject: [issue4806] Function calls taking a generator as star argument can
 mask TypeErrors in the generator
In-Reply-To: <1230900364.95.0.0532833034138.issue4806@psf.upfronthosting.co.za>
Message-ID: <1460865620.43.0.274617289609.issue4806@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4806>
_______________________________________

From report at bugs.python.org  Sun Apr 17 02:21:25 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 17 Apr 2016 06:21:25 +0000
Subject: [issue26787] test_distutils fails when configured --with-lto
Message-ID: <1460874085.6.0.334729464026.issue26787@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

When configured using './configure --with-lto' (added in issue25702) and doing a 'make profile-opt' build, test_distutils fails:

======================================================================
FAIL: test_sysconfig_compiler_vars (distutils.tests.test_sysconfig.SysconfigTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/greg/sandbox/python/cpython/3.5/Lib/distutils/tests/test_sysconfig.py", line 156, in test_sysconfig_compiler_vars
    sysconfig.get_config_var('LDSHARED'))
AssertionError: 'gcc -pthread -shared -flto -fuse-linker-plugin -ffat-lto-obje[20 chars]none' != 'gcc -pthread -shared'
- gcc -pthread -shared -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none
+ gcc -pthread -shared


======================================================================
FAIL: test_sysconfig_module (distutils.tests.test_sysconfig.SysconfigTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/greg/sandbox/python/cpython/3.5/Lib/distutils/tests/test_sysconfig.py", line 133, in test_sysconfig_module
    sysconfig.get_config_var('LDFLAGS'))
AssertionError: '-flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none' != ''
- -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none
+

----------
components: Build
messages: 263598
nosy: alecsandru.patrascu, gregory.p.smith
priority: normal
severity: normal
status: open
title: test_distutils fails when configured --with-lto
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26787>
_______________________________________

From report at bugs.python.org  Sun Apr 17 02:21:50 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 17 Apr 2016 06:21:50 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za>
Message-ID: <1460874110.12.0.924340184699.issue25702@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
dependencies: +test_distutils fails when configured --with-lto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25702>
_______________________________________

From report at bugs.python.org  Sun Apr 17 02:29:59 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 17 Apr 2016 06:29:59 +0000
Subject: [issue26788] test_gdb fails all tests on a profile-opt build
 configured --with-lto
Message-ID: <1460874599.33.0.6029536171.issue26788@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

cpython/build35.lto$ ./python ../3.5/Lib/test/test_gdb.py
GDB version 7.10:
    GNU gdb (Ubuntu 7.10-1ubuntu2) 7.10
...
======================================================================
FAIL: test_tuples (__main__.PrettyPrintTests)
Verify the pretty-printing of tuples
----------------------------------------------------------------------
Traceback (most recent call last):
  File "../3.5/Lib/test/test_gdb.py", line 359, in test_tuples
    self.assertGdbRepr(tuple(), '()')
  File "../3.5/Lib/test/test_gdb.py", line 279, in assertGdbRepr
    gdb_repr, gdb_output = self.get_gdb_repr('id(' + ascii(val) + ')')
  File "../3.5/Lib/test/test_gdb.py", line 255, in get_gdb_repr
    self.fail('Unexpected gdb output: %r\n%s' % (gdb_output, gdb_output))
AssertionError: Unexpected gdb output: 'Breakpoint 1 at 0x4cc310\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".\n\nBreakpoint 1, builtin_id ()\n#0  builtin_id ()\n'
Breakpoint 1 at 0x4cc310
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, builtin_id ()
#0  builtin_id ()

I don't know the right thing to do here.  This might depend on compiler, linker, arch and gdb version?  Are it's LTO executables debuggable?  It's not clear to me that we can do anything about this.  We may just want to skip the test when configured --with-lto.  Or perhaps this is an indication that this specific toolchain's LTO build (x86_64, ubuntu wily gcc 5.2.1 and gdb 7.1.0) has issues and shouldn't be used?

----------
components: Build
messages: 263599
nosy: alecsandru.patrascu, gregory.p.smith
priority: normal
severity: normal
status: open
title: test_gdb fails all tests on a profile-opt build configured --with-lto
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26788>
_______________________________________

From report at bugs.python.org  Sun Apr 17 02:30:12 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 17 Apr 2016 06:30:12 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za>
Message-ID: <1460874612.55.0.220927812691.issue25702@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
dependencies: +test_gdb fails all tests on a profile-opt build configured --with-lto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25702>
_______________________________________

From report at bugs.python.org  Sun Apr 17 02:40:17 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 Apr 2016 06:40:17 +0000
Subject: [issue26778] More typo fixes
In-Reply-To: <1460810974.92.0.431649847374.issue26778@psf.upfronthosting.co.za>
Message-ID: <20160417064014.19505.99985.4E85AD5F@psf.io>


Roundup Robot added the comment:

New changeset 395dd5630e6c by Serhiy Storchaka in branch '3.5':
Issue #26778: Fixed "a/an/and" typos in code comment and documentation.
https://hg.python.org/cpython/rev/395dd5630e6c

New changeset bbcde8db4dc4 by Serhiy Storchaka in branch '2.7':
Issue #26778: Fixed "a/an/and" typos in code comment and documentation.
https://hg.python.org/cpython/rev/bbcde8db4dc4

New changeset 932b330e22d8 by Serhiy Storchaka in branch 'default':
Issue #26778: Fixed "a/an/and" typos in code comment, documentation and error
https://hg.python.org/cpython/rev/932b330e22d8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26778>
_______________________________________

From report at bugs.python.org  Sun Apr 17 02:41:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Apr 2016 06:41:00 +0000
Subject: [issue26778] More typo fixes
In-Reply-To: <1460810974.92.0.431649847374.issue26778@psf.upfronthosting.co.za>
Message-ID: <1460875260.81.0.444321267025.issue26778@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/issue26778>
_______________________________________

From report at bugs.python.org  Sun Apr 17 04:23:34 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 17 Apr 2016 08:23:34 +0000
Subject: [issue26717] wsgiref.simple_server: mojibake with cp1252 bytes in
 PATH_INFO
In-Reply-To: <1460148485.6.0.00224363970956.issue26717@psf.upfronthosting.co.za>
Message-ID: <1460881414.12.0.652496257346.issue26717@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26717>
_______________________________________

From report at bugs.python.org  Sun Apr 17 04:28:19 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 17 Apr 2016 08:28:19 +0000
Subject: [issue26554] PC\bdist_wininst\install.c: Missing call to fclose()
In-Reply-To: <1457949701.38.0.834751371072.issue26554@psf.upfronthosting.co.za>
Message-ID: <1460881699.7.0.829166406526.issue26554@psf.upfronthosting.co.za>


Martin Panter added the comment:

Adding aatishnn to nosy in case they aren?t aware of your review.

----------
nosy: +aatishnn, martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26554>
_______________________________________

From report at bugs.python.org  Sun Apr 17 06:02:29 2016
From: report at bugs.python.org (Ma Lin)
Date: Sun, 17 Apr 2016 10:02:29 +0000
Subject: [issue26744] print() function hangs on MS-Windows 10
In-Reply-To: <1460512669.99.0.0354506250162.issue26744@psf.upfronthosting.co.za>
Message-ID: <1460887349.51.0.446938851705.issue26744@psf.upfronthosting.co.za>


Ma Lin added the comment:

faulthandler module caught a hang just now:

    Timeout (0:01:00)!
    Thread 0x00000eb0 (most recent call first):
      File "D:\git\tz2txt\tz2txt\gui.py", line 262 in delfile
      File "C:\Python35\lib\tkinter\__init__.py", line 1549 in __call__
      File "C:\Python35\lib\tkinter\__init__.py", line 1131 in mainloop
      File "D:\git\tz2txt\tz2txt\gui.py", line 328 in main
      File "D:\git\tz2txt\tz2txt\gui.py", line 331 in <module>
  
 Here is the full delfile function:
  
      def delfile(self):
        try:
            output = self.output.get().strip()
            os.remove(output)
        except:
            pass
        else:
            print('???????')    # <- line 262
        
        try:
            os.remove(discard_fn)
        except:
            pass
        else:
            print('???????')
        
        self.url.set(url_use)

~~~~~~~~~~~~~~~~~~~~~~~~~~
Some supplemental information:

There was a time point, *maybe* it's Windows10 Threshold2 (12/Nov/2015), before that time no hang at all.
After that time, the hangs were quite often.
Some months later, the frequency had declined a lot, but still hang occasionally.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26744>
_______________________________________

From report at bugs.python.org  Sun Apr 17 06:33:44 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Apr 2016 10:33:44 +0000
Subject: [issue26770] _Py_set_inheritable(): do nothing if the FD_CLOEXEC
 close is already set/cleared
In-Reply-To: <1460726460.32.0.344896145272.issue26770@psf.upfronthosting.co.za>
Message-ID: <1460889224.92.0.805881786162.issue26770@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Changes look pretty innocent. LGTM.

----------
assignee:  -> haypo
nosy: +steve.dower
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26770>
_______________________________________

From report at bugs.python.org  Sun Apr 17 06:39:06 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Apr 2016 10:39:06 +0000
Subject: [issue26770] _Py_set_inheritable(): do nothing if the FD_CLOEXEC
 close is already set/cleared
In-Reply-To: <1460726460.32.0.344896145272.issue26770@psf.upfronthosting.co.za>
Message-ID: <1460889546.08.0.149975953571.issue26770@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Another question: should we handle EINTR in ioctl() and fcntl()? But this is a different issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26770>
_______________________________________

From report at bugs.python.org  Sun Apr 17 06:55:15 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Apr 2016 10:55:15 +0000
Subject: [issue26756] fileinput handling of unicode errors from standard input
In-Reply-To: <1460644347.16.0.552330506095.issue26756@psf.upfronthosting.co.za>
Message-ID: <1460890515.84.0.445521285977.issue26756@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Calling the openhook for the stdin will break existing code. Third-party openhooks don't special case the '<stdin>' name, which is legitimate file name.

Instead I recommend to patch sys.stdin explicitly in your program.

    sys.stdin = io.TextIOWrapper(sys.stdin.buffer, errors='replace')
    for line in fileinput.input(openhook=hook):
        ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26756>
_______________________________________

From report at bugs.python.org  Sun Apr 17 07:02:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Apr 2016 11:02:47 +0000
Subject: [issue26758] Unnecessary format string handling for no argument slot
 wrappers in typeobject.c
In-Reply-To: <1460649796.07.0.143785441525.issue26758@psf.upfronthosting.co.za>
Message-ID: <1460890967.16.0.816921275238.issue26758@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If I correctly understood, there is no visible bug, but there is a suboptimal code. The patch is welcome.

----------
stage:  -> needs patch
type: behavior -> performance
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26758>
_______________________________________

From report at bugs.python.org  Sun Apr 17 09:13:36 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Sun, 17 Apr 2016 13:13:36 +0000
Subject: [issue26786] bdist_msi duplicates directories with names in ALL CAPS
 to a bogus location
In-Reply-To: <1460844390.43.0.520967711704.issue26786@psf.upfronthosting.co.za>
Message-ID: <1460898816.04.0.206074482538.issue26786@psf.upfronthosting.co.za>


Changes by Ivan Pozdeev <ivan_pozdeev at mail.ru>:


----------
keywords: +patch
Added file: http://bugs.python.org/file42496/bdist_msi.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26786>
_______________________________________

From report at bugs.python.org  Sun Apr 17 09:23:21 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Apr 2016 13:23:21 +0000
Subject: [issue26774] Elide Py_atomic fences when WITH_THREAD is disabled?
In-Reply-To: <1460777364.25.0.14094466129.issue26774@psf.upfronthosting.co.za>
Message-ID: <1460899401.16.0.1329648503.issue26774@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This sounds like additional hassle for not much gain. Agreed with Victor.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26774>
_______________________________________

From report at bugs.python.org  Sun Apr 17 10:43:43 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 17 Apr 2016 14:43:43 +0000
Subject: [issue26774] Elide Py_atomic fences when WITH_THREAD is disabled?
In-Reply-To: <1460777364.25.0.14094466129.issue26774@psf.upfronthosting.co.za>
Message-ID: <1460904223.25.0.485509341074.issue26774@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Discussion about --without-threads:

* May 2012
  https://mail.python.org/pipermail/python-dev/2012-May/119333.html
* Follow-up january 2013
  https://mail.python.org/pipermail/python-dev/2013-January/123505.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26774>
_______________________________________

From report at bugs.python.org  Sun Apr 17 10:50:19 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 17 Apr 2016 14:50:19 +0000
Subject: [issue26770] _Py_set_inheritable(): do nothing if the FD_CLOEXEC
 close is already set/cleared
In-Reply-To: <1460726460.32.0.344896145272.issue26770@psf.upfronthosting.co.za>
Message-ID: <1460904619.89.0.870616577106.issue26770@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Another question: should we handle EINTR in ioctl() and fcntl()? But this is a different issue.

See attached test stress.py. I tried it with ioctl() and fcntl() implementations of os.set_inheritable() and I got more than 10,000 signals: no syscalls failed with EINTR.

IMHO EINTR is only used when the syscall waits, for example wait for I/O. I don't think that setting FD_CLOEXEC requires any I/O.

Example:

$ ./python stress.py 
got 16871 signals

----------
Added file: http://bugs.python.org/file42497/stress.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26770>
_______________________________________

From report at bugs.python.org  Sun Apr 17 10:52:14 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 Apr 2016 14:52:14 +0000
Subject: [issue26770] _Py_set_inheritable(): do nothing if the FD_CLOEXEC
 close is already set/cleared
In-Reply-To: <1460726460.32.0.344896145272.issue26770@psf.upfronthosting.co.za>
Message-ID: <20160417145210.15346.50805.3F6FE5D7@psf.io>


Roundup Robot added the comment:

New changeset d268f108ba80 by Victor Stinner in branch 'default':
Avoid fcntl() if possible in set_inheritable()
https://hg.python.org/cpython/rev/d268f108ba80

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26770>
_______________________________________

From report at bugs.python.org  Sun Apr 17 10:52:33 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 17 Apr 2016 14:52:33 +0000
Subject: [issue26770] _Py_set_inheritable(): do nothing if the FD_CLOEXEC
 close is already set/cleared
In-Reply-To: <1460726460.32.0.344896145272.issue26770@psf.upfronthosting.co.za>
Message-ID: <1460904753.49.0.103709577601.issue26770@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Changes look pretty innocent. LGTM.

Thanks. I pushed my change.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26770>
_______________________________________

From report at bugs.python.org  Sun Apr 17 11:12:07 2016
From: report at bugs.python.org (Matthias Urlichs)
Date: Sun, 17 Apr 2016 15:12:07 +0000
Subject: [issue26789] Please do not log during shutdown
Message-ID: <1460905927.74.0.222378341822.issue26789@psf.upfronthosting.co.za>


New submission from Matthias Urlichs:

? or, if you do, ignore errors.

This is during program shutdown. Unfortunately, I am unable to create a trivial example which exhibits the order of destruction necessary to trigger this problem.

Traceback (most recent call last):
  File "/usr/lib/python3.5/asyncio/tasks.py", line 93, in __del__
  File "/usr/lib/python3.5/asyncio/base_events.py", line 1160, in call_exception_handler
  File "/usr/lib/python3.5/logging/__init__.py", line 1308, in error
  File "/usr/lib/python3.5/logging/__init__.py", line 1415, in _log
  File "/usr/lib/python3.5/logging/__init__.py", line 1425, in handle
  File "/usr/lib/python3.5/logging/__init__.py", line 1487, in callHandlers
  File "/usr/lib/python3.5/logging/__init__.py", line 855, in handle
  File "/usr/lib/python3.5/logging/__init__.py", line 1047, in emit
  File "/usr/lib/python3.5/logging/__init__.py", line 1037, in _open
NameError: name 'open' is not defined

----------
components: asyncio
messages: 263612
nosy: gvanrossum, haypo, smurfix, yselivanov
priority: normal
severity: normal
status: open
title: Please do not log during shutdown
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26789>
_______________________________________

From report at bugs.python.org  Sun Apr 17 11:15:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 17 Apr 2016 15:15:24 +0000
Subject: [issue26716] EINTR handling in fcntl
In-Reply-To: <1460145033.33.0.165294517839.issue26716@psf.upfronthosting.co.za>
Message-ID: <1460906124.83.0.644162549335.issue26716@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Added file: http://bugs.python.org/file42498/fcntl_eintr-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26716>
_______________________________________

From report at bugs.python.org  Sun Apr 17 11:16:04 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 17 Apr 2016 15:16:04 +0000
Subject: [issue26716] EINTR handling in fcntl
In-Reply-To: <1460145033.33.0.165294517839.issue26716@psf.upfronthosting.co.za>
Message-ID: <1460906164.13.0.208690810014.issue26716@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I updated the test, does it look better now?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26716>
_______________________________________

From report at bugs.python.org  Sun Apr 17 11:39:17 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 17 Apr 2016 15:39:17 +0000
Subject: [issue25987] collections.abc.Reversible
In-Reply-To: <1451685633.1.0.273350637631.issue25987@psf.upfronthosting.co.za>
Message-ID: <1460907557.3.0.347423566085.issue25987@psf.upfronthosting.co.za>


Ivan Levkivskyi added the comment:

I see that I forgot to include .. versionadded:: in the documentation.
Will this go into 3.5.2 or in 3.6?

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25987>
_______________________________________

From report at bugs.python.org  Sun Apr 17 12:12:00 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Sun, 17 Apr 2016 16:12:00 +0000
Subject: [issue26790] bdist_msi package duplicates everything to a bogus
 location when run with /passive or /q
Message-ID: <1460909520.55.0.0242536179929.issue26790@psf.upfronthosting.co.za>


New submission from Ivan Pozdeev:

First, the background information so you understand what I am talking about.

bdist_msi-produced packages work in the following way:

The files to install are presented as at least 3 equivalent sets (implemented as Features): "Python<version>" (for Python from registry), "PythonX" (for Python from a custom location) and a hidden but always selected "Python" - a "source" set.
Files in them are linked together with DuplicateFiles, with "real" files in the "Python" set.

"Python" has the installation target set to TARGETDIR that has the default value specified as "SourceDir" (practice shows it's initially set to the root of the drive where the .msi being installed is).
The other two have default locations set to subdirectories of TARGETDIR, but PYTHON<version> is changed to the root of the installed Python early on (at AppSearch stage and custom actions just after it in both InstallUISequence and InstallExecuteSequence) if an installtion is detected.

Now, at SelectFeaturesDlg in InstallUISequence, TARGETDIR is changed to a location for one of the features selected for install (initially, "Python<version>" is selected if an installation was found). Later, as a public property, it's passed to InstallExecuteSequence, acting as the new default value.

Finally, the files are installed to TARGETDIR and _duplicated_ to locations for all other features that have been selected. So, if only one feature was selected (the common scenario), TARGETDIR is equal to its location, so no duplication takes place. If nothing was selected, everything is unpacked to the directory where the .msi is, like `tar' does. (The latter is extremely weird for an .msi but is quite in line with the logic for other types of `bdist_' packages.)

----

Now, the problem is:
* the aforementioned TARGETDIR switch is implemented as an event handler in the SelectFeaturesDlg dialog.
* if I run with /passive or /q, InstallUISequence isn't done, the dialog isn't shown, and the event never happens.
* so TARGETDIR remains the default, and MSI installs everything to whatever that default happened to be, then duplicates to the correct location.

----

To fix this, we need to somehow duplicate the Python detection and TARGETDIR switch to InstallExecuteSequence, avoiding overwriting the results of earlier actions.

Current workaround is to pass "TARGETDIR=<python root>" to msiexec.

----------
components: Distutils, Library (Lib), Windows
files: mercurial-3.7.3.log.gz
messages: 263615
nosy: Ivan.Pozdeev, dstufft, eric.araujo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: bdist_msi package duplicates everything to a bogus location when run with /passive or /q
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/file42499/mercurial-3.7.3.log.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26790>
_______________________________________

From report at bugs.python.org  Sun Apr 17 12:53:37 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 17 Apr 2016 16:53:37 +0000
Subject: [issue26790] bdist_msi package duplicates everything to a bogus
 location when run with /passive or /q
In-Reply-To: <1460909520.55.0.0242536179929.issue26790@psf.upfronthosting.co.za>
Message-ID: <1460912017.98.0.265634399435.issue26790@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
versions:  -Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26790>
_______________________________________

From report at bugs.python.org  Sun Apr 17 12:58:17 2016
From: report at bugs.python.org (Renato Alves)
Date: Sun, 17 Apr 2016 16:58:17 +0000
Subject: [issue26791] shutil.move fails to move symlink (Invalid cross-device
 link)
Message-ID: <1460912297.17.0.227992133358.issue26791@psf.upfronthosting.co.za>


New submission from Renato Alves:

Hi everyone,

I'm not really sure if this is a new issue but digging through the bug reports from the past I couldn't find an answer.
There's http://bugs.python.org/issue1438480 but this seems to be a different issue.
I also found http://bugs.python.org/issue9993 that addressed problems with symlinks but didn't correct the behavior reported here.

The problem can be visualized with the following code.
Code fails on python 2.7 as well as python 3.4+. Not tested in python <2.7 and <3.4.


    import shutil
    import os
    
    TMPDIR = "/tmp/tmpdir"
    TESTLINK = "test_dir"
    
    if not os.path.isdir(TMPDIR):
        os.mkdir(TMPDIR)
    
    if not os.path.islink(TESTLINK):
        os.symlink(TMPDIR, TESTLINK)
    
    shutil.move(TESTLINK, TMPDIR)


When executed it gives me:

    % python3 test.py
    Traceback (most recent call last):
      File "test.py", line 14, in <module>
        shutil.move(TESTLINK, TMPDIR)
      File "/usr/lib64/python3.4/shutil.py", line 516, in move
        os.rename(src, dst)
    OSError: [Errno 18] Invalid cross-device link: 'test_dir' -> '/tmp/tmpdir'


This happens because /tmp is:

  tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime,nodiratime)


In the past the recommendation to handle this problem was to stop using os.rename and use shutil.move instead.
This was even discussed in a bug report - http://bugs.python.org/issue14848

If one searches for this exception there's plenty of advice [1][2][3][4] in the same direction.
However, given that shutil.move uses os.rename internally, the problem returns.

On the other end doing the equivalent action in the shell with 'mv' works fine.


[1] - http://stackoverflow.com/a/15300474
[2] - https://mail.python.org/pipermail/python-list/2005-February/342892.html
[3] - http://www.thecodingforums.com/threads/errno-18-invalid-cross-device-link-using-os-rename.341597/
[4] - https://github.com/pypa/pip/issues/103

----------
components: Library (Lib)
messages: 263616
nosy: Unode
priority: normal
severity: normal
status: open
title: shutil.move fails to move symlink (Invalid cross-device link)
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26791>
_______________________________________

From report at bugs.python.org  Sun Apr 17 12:59:06 2016
From: report at bugs.python.org (Renato Alves)
Date: Sun, 17 Apr 2016 16:59:06 +0000
Subject: [issue26791] shutil.move fails to move symlink (Invalid cross-device
 link)
In-Reply-To: <1460912297.17.0.227992133358.issue26791@psf.upfronthosting.co.za>
Message-ID: <1460912346.29.0.677707838911.issue26791@psf.upfronthosting.co.za>


Changes by Renato Alves <alves.rjc at gmail.com>:


----------
versions: +Python 2.7, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26791>
_______________________________________

From report at bugs.python.org  Sun Apr 17 13:00:27 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Apr 2016 17:00:27 +0000
Subject: [issue26789] Please do not log during shutdown
In-Reply-To: <1460905927.74.0.222378341822.issue26789@psf.upfronthosting.co.za>
Message-ID: <1460912427.15.0.517607000776.issue26789@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26789>
_______________________________________

From report at bugs.python.org  Sun Apr 17 13:01:21 2016
From: report at bugs.python.org (Renato Alves)
Date: Sun, 17 Apr 2016 17:01:21 +0000
Subject: [issue26791] shutil.move fails to move symlink (Invalid cross-device
 link)
In-Reply-To: <1460912297.17.0.227992133358.issue26791@psf.upfronthosting.co.za>
Message-ID: <1460912481.92.0.99665299234.issue26791@psf.upfronthosting.co.za>


Renato Alves added the comment:

Also related to http://bugs.python.org/issue212317

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26791>
_______________________________________

From report at bugs.python.org  Sun Apr 17 13:27:45 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Apr 2016 17:27:45 +0000
Subject: [issue26767] Inconsistant error messages for failed attribute
 modification
In-Reply-To: <1460715032.51.0.36886496046.issue26767@psf.upfronthosting.co.za>
Message-ID: <1460914065.07.0.569891222549.issue26767@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26767>
_______________________________________

From report at bugs.python.org  Sun Apr 17 13:28:16 2016
From: report at bugs.python.org (Paul Ellenbogen)
Date: Sun, 17 Apr 2016 17:28:16 +0000
Subject: [issue26773] Shelve works inconsistently when carried over to child
 processes
In-Reply-To: <1460749416.45.0.0472811645443.issue26773@psf.upfronthosting.co.za>
Message-ID: <1460914096.07.0.170314253319.issue26773@psf.upfronthosting.co.za>


Paul Ellenbogen added the comment:

I think this behavior is due to the underlying behavior of the dbm. The same code using dbm, rather than shelve, also throws KeyErrors:

from multiprocessing import Process
import dbm

db = dbm.open("example.dbm", "c")
for i in range(100):
    db[str(i)] = str(i ** 2)


def parallel():
    for i in range(100):
        print(db[str(i)])

a = Process(target = parallel)
b = Process(target = parallel)
a.start()
b.start()
a.join()
b.join()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26773>
_______________________________________

From report at bugs.python.org  Sun Apr 17 13:32:15 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 Apr 2016 17:32:15 +0000
Subject: [issue26745] Redundant code in _PyObject_GenericSetAttrWithDict
In-Reply-To: <1460515034.42.0.500786155919.issue26745@psf.upfronthosting.co.za>
Message-ID: <20160417173213.12733.22307.729A602A@psf.io>


Roundup Robot added the comment:

New changeset e5149789e4ea by Serhiy Storchaka in branch 'default':
Issue #26745: Removed redundant code in _PyObject_GenericSetAttrWithDict.
https://hg.python.org/cpython/rev/e5149789e4ea

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26745>
_______________________________________

From report at bugs.python.org  Sun Apr 17 13:33:08 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Apr 2016 17:33:08 +0000
Subject: [issue26745] Redundant code in _PyObject_GenericSetAttrWithDict
In-Reply-To: <1460515034.42.0.500786155919.issue26745@psf.upfronthosting.co.za>
Message-ID: <1460914388.27.0.418744196004.issue26745@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Issue26767 looks too complex and resolving it needs much more rewriting.

----------
resolution: remind -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26745>
_______________________________________

From report at bugs.python.org  Sun Apr 17 14:01:38 2016
From: report at bugs.python.org (Matthias Bussonnier)
Date: Sun, 17 Apr 2016 18:01:38 +0000
Subject: [issue24294] DeprecationWarnings should be visible by default in the
 interactive REPL
In-Reply-To: <1432713990.67.0.935342603332.issue24294@psf.upfronthosting.co.za>
Message-ID: <1460916098.62.0.426144364585.issue24294@psf.upfronthosting.co.za>


Matthias Bussonnier added the comment:

> @mbussonn - I don't see an updated non-tty-checking patch from you?

Sorry for the delay, trying to get back on this. 

Please find attached a new patch that does not check whether is is a tty.
Still struggling a bit with HG (looking fwd to migration to GH)

----------
Added file: http://bugs.python.org/file42500/enable_deprecation_warnings_in_repl_no_check_tty.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24294>
_______________________________________

From report at bugs.python.org  Sun Apr 17 14:29:27 2016
From: report at bugs.python.org (ppperry)
Date: Sun, 17 Apr 2016 18:29:27 +0000
Subject: [issue26627] IDLE incorrectly labeling error as internal
In-Reply-To: <1458756045.86.0.656079576242.issue26627@psf.upfronthosting.co.za>
Message-ID: <1460917767.31.0.217523260726.issue26627@psf.upfronthosting.co.za>


ppperry added the comment:

Duplicate issue24252, although the consequences are slightly different.

----------
nosy: +ppperry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26627>
_______________________________________

From report at bugs.python.org  Sun Apr 17 15:19:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Apr 2016 19:19:30 +0000
Subject: [issue26720] memoryview from BufferedWriter becomes garbage
In-Reply-To: <1460203726.07.0.470306343445.issue26720@psf.upfronthosting.co.za>
Message-ID: <1460920770.15.0.973267485762.issue26720@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Python implementation passes bytearray to underlying write and delete it's content just after that. Thus saving written data was never worked, and making it working don't worth efforts. I agree with you, we should add a warning against saving. This might be a part of issue20699.

As for original issue, this is potential crash, and we should fix this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26720>
_______________________________________

From report at bugs.python.org  Sun Apr 17 15:52:48 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sun, 17 Apr 2016 19:52:48 +0000
Subject: [issue26787] test_distutils fails when configured --with-lto
In-Reply-To: <1460874085.6.0.334729464026.issue26787@psf.upfronthosting.co.za>
Message-ID: <1460922768.13.0.626021759093.issue26787@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

I will investigate this and submit a fix. At a first glance, it seems the test is failing because it does not have the knowledge of the LTO flags.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26787>
_______________________________________

From report at bugs.python.org  Sun Apr 17 15:56:14 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sun, 17 Apr 2016 19:56:14 +0000
Subject: [issue26788] test_gdb fails all tests on a profile-opt build
 configured --with-lto
In-Reply-To: <1460874599.33.0.6029536171.issue26788@psf.upfronthosting.co.za>
Message-ID: <1460922974.04.0.477397121552.issue26788@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

I will investigate this issue to understand what is happening there and submit a fix. Thank you for pointing out the exact OS and toolchain used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26788>
_______________________________________

From report at bugs.python.org  Sun Apr 17 16:30:05 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Apr 2016 20:30:05 +0000
Subject: [issue26642] Replace stdout and stderr with simple standard printers
 at Python exit
In-Reply-To: <1458911597.09.0.705997743741.issue26642@psf.upfronthosting.co.za>
Message-ID: <1460925005.51.0.939974944798.issue26642@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I meant that C files stderr and stdout can be closed. Or it's file descriptors can be closed. I think in these cases fileno() or PyFile_NewStdPrinter() will fail.

I'm trying to consider all possible cases. Standard streams can be:

* Left original.
* Set to None.
* Reopened with different encoding/errors/etc.
* Redirected to a file (/dev/null).
* Redirected to a socket.
* Redirected to inherited file descriptor (pipe) in a subprocess.
* Be a high level wrapper around RPC (IDLE subprocess).

If the stream was reopened with the same file descriptor and closefd=True, closing it invalidates just opened "standard printer".

I would replace stdout and stderr after PyImport_Cleanup(). But PyImport_Cleanup() cleans up the sys module! Thus we should do this inside PyImport_Cleanup().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26642>
_______________________________________

From report at bugs.python.org  Sun Apr 17 16:36:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Apr 2016 20:36:33 +0000
Subject: [issue26733] staticmethod and classmethod are ignored when
 disassemble class
In-Reply-To: <1460369974.2.0.716803365246.issue26733@psf.upfronthosting.co.za>
Message-ID: <1460925393.47.0.0562122272694.issue26733@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

Nick, do you consider this as a new feature, or as a fix?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26733>
_______________________________________

From report at bugs.python.org  Sun Apr 17 17:03:04 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 17 Apr 2016 21:03:04 +0000
Subject: [issue26785] repr of -nan value should contain the sign
In-Reply-To: <1460832293.23.0.989531230725.issue26785@psf.upfronthosting.co.za>
Message-ID: <1460926984.85.0.289649754973.issue26785@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

The current behaviour is deliberate, so any change would be an enhancement rather than a bugfix. I'm modifying the versions accordingly.

Unlike the sign of a zero, the sign of a NaN has no useful meaning: IEEE 754 explicitly says "this standard does not interpret the sign of a NaN". Yes, that sign is copied by copysign, but I don't think that in itself means that the sign should be included in the repr, and I'm not aware of any applications where the sign matters in that context.

A NaN also has 51 payload bits (or 52 if you're not distinguishing between quiet and signalling NaNs), but like the sign, those bits are rarely important in applications.

I'm not really seeing a case for representing either the sign or the payload bits in the repr. Do you know of any applications that make use of the sign of a NaN?

----------
versions:  -Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26785>
_______________________________________

From report at bugs.python.org  Sun Apr 17 17:06:04 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 17 Apr 2016 21:06:04 +0000
Subject: [issue26785] repr of -nan value should contain the sign
In-Reply-To: <1460832293.23.0.989531230725.issue26785@psf.upfronthosting.co.za>
Message-ID: <1460927164.37.0.306917579916.issue26785@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> it is actually used in real-life situations

Do you have any examples available?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26785>
_______________________________________

From report at bugs.python.org  Sun Apr 17 17:13:45 2016
From: report at bugs.python.org (Meador Inge)
Date: Sun, 17 Apr 2016 21:13:45 +0000
Subject: [issue26765] Factor out common bytes and bytearray implementation
In-Reply-To: <1460707559.13.0.709090380773.issue26765@psf.upfronthosting.co.za>
Message-ID: <1460927625.56.0.659976797932.issue26765@psf.upfronthosting.co.za>


Meador Inge added the comment:

If I follow this correctly, then it seems like there are two
main pieces to this patch:

  1. Consolidating the following methods into `bytes_methods.c`:

     a. {bytes, bytearray}_find_internal

     b. {bytes, bytearray}_find

     c. {bytes, bytearray}_count

     d. {bytes, bytearray}_index

     e. {bytes, bytearray}_rfind

     f. {bytes, bytearray}_rindex

     g. {bytes, bytearray}_contains

     h. (_bytes, _bytearray}_tailmatch

     i. {bytes, bytearray}_startswith

     j. {bytes, bytearray}_endswith

  2. Consolidating the redundant implementations of the following functions
     into the stringlib:

     a. return_self

     b. countchar

     c. replace_interleave

     d. replace_delete_single_character

     e. replace_delete_substring

     f. replace_single_character_in_place

     g. replace_substring_in_place

     h. replace_single_character

     i. replace_substring

     j. replace

If so, then that seems reasonable to me and a nice cleanup.

A few comments:

  1. The diffs are fairly large.  It might be easier to follow if you stage
     the two steps above as separate commits (if possible).

  2. Why are some of the namings in stringlib inconsistent?  For example,
     `stringlib_method_find` and `stringlib_index`.  In other words, why
     do some names have the *_method_* part?

----------
nosy: +meador.inge
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26765>
_______________________________________

From report at bugs.python.org  Sun Apr 17 17:25:49 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 17 Apr 2016 21:25:49 +0000
Subject: [issue26785] repr of -nan value should contain the sign
In-Reply-To: <1460832293.23.0.989531230725.issue26785@psf.upfronthosting.co.za>
Message-ID: <1460928349.55.0.295695042001.issue26785@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

About the Python 2.7 behaviour:

>>> from math import copysign
>>> x = float("-nan")
>>> copysign(1.0, x)
1.0

I'd be interested to know what `struct.pack('<d', x)` shows in this case. I'd expect it to be '\x00\x00\x00\x00\x00\x00\xf8\xff', meaning that the `float` conversion has produced a value with its sign bit set, as expected, but `copysign` has failed to transfer that sign bit. That failure is somewhat expected: older versions of MSVC don't provide copysign, so it has to be emulated, and the emulation doesn't take the sign of NaNs into account. (Getting the sign of a NaN is awkward to do without a native copysign function.) It works as expected on OS X and Linux.

So that's a separate issue: copysign on Windows / Python 2.7 doesn't correctly handle the sign bit of a NaN. I agree that that's less than ideal, but I'm not sure whether it's worth fixing for Python 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26785>
_______________________________________

From report at bugs.python.org  Sun Apr 17 17:31:09 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 17 Apr 2016 21:31:09 +0000
Subject: [issue26785] repr of -nan value should contain the sign
In-Reply-To: <1460832293.23.0.989531230725.issue26785@psf.upfronthosting.co.za>
Message-ID: <1460928669.68.0.67429714302.issue26785@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Gah, sorry. I misdiagnosed the Python 2.7 issue (I was looking at the code for the wrong branch). See issue 22590 for the correct diagnosis.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26785>
_______________________________________

From report at bugs.python.org  Sun Apr 17 17:31:26 2016
From: report at bugs.python.org (Hrvoje Abraham)
Date: Sun, 17 Apr 2016 21:31:26 +0000
Subject: [issue26785] repr of -nan value should contain the sign
In-Reply-To: <1460832293.23.0.989531230725.issue26785@psf.upfronthosting.co.za>
Message-ID: <1460928686.67.0.0333172814743.issue26785@psf.upfronthosting.co.za>


Hrvoje Abraham added the comment:

Python 2.7.11 (v2.7.11:6d1b6a68f775, Dec  5 2015, 20:40:30) [MSC v.1500 64 bit (AMD64)] on win32:

>>> import struct
>>> x=float("-nan")
>>> struct.pack('<d', x)
'\x00\x00\x00\x00\x00\x00\xf8\x7f'

Looks like the sign bit is off (0) in 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26785>
_______________________________________

From report at bugs.python.org  Sun Apr 17 18:11:34 2016
From: report at bugs.python.org (Josh Snider)
Date: Sun, 17 Apr 2016 22:11:34 +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: <1460931094.83.0.130475075998.issue25386@psf.upfronthosting.co.za>


Josh Snider added the comment:

Here's a patch that raises an exception when _put[w]ch and _get[w]ch[e] are run without a console. Like Eryk Sun says, the get's work fine if you do unget before hand.

----------
keywords: +patch
nosy: +Josh Snider
Added file: http://bugs.python.org/file42501/issue25386.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25386>
_______________________________________

From report at bugs.python.org  Sun Apr 17 18:27:49 2016
From: report at bugs.python.org (Hrvoje Abraham)
Date: Sun, 17 Apr 2016 22:27:49 +0000
Subject: [issue26785] repr of -nan value should contain the sign
In-Reply-To: <1460832293.23.0.989531230725.issue26785@psf.upfronthosting.co.za>
Message-ID: <1460932069.08.0.253722234387.issue26785@psf.upfronthosting.co.za>


Hrvoje Abraham added the comment:

Regarding NaN sign bit, IEEE-754 states:

"Note, however, that operations on bit strings?copy, negate, abs, copySign?specify the sign bit of a NaN result, sometimes based upon the sign bit of a NaN operand. The logical predicate totalOrder is also affected by the sign bit of a NaN operand."

So NaN sign bit information is used in the standard itself (section 5.10.d):

1) totalOrder(?NaN, y) is true where ?NaN represents a NaN with negative sign bit and y is a
   floating-point number.
2) totalOrder(x, +NaN) is true where +NaN represents a NaN with positive sign bit and x is a
   floating-point number.

This fact alone implies the importance of its round-trip safety. I believe the quote you picked states this information doesn't have universal (standardized) meaning, not it is not important or used at all. It is reasonable to assume some will need to preserve it.

There are also some real-life usages, similar as signed zero, in determining the correct complex plane branch cut:
http://stackoverflow.com/questions/8781072/sign-check-for-nan-value
http://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/catan.3M.html
catan(inf + iNAN) => ?/2 + i0; catan(inf - iNAN) => ?/2 - i0;

MSVC 2015 and MinGW-W64 v4.9.2 output (source below) for '-nan' values are:

MSVC:      -nan(ind)
MinGW-W64: -1.#IND00


#include <stdio.h>

int main()
{
    double x = 0.0;
    x = - x / x;
    printf("%lf\n", x);

    return 0;
}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26785>
_______________________________________

From report at bugs.python.org  Sun Apr 17 19:02:32 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 17 Apr 2016 23:02:32 +0000
Subject: [issue25987] collections.abc.Reversible
In-Reply-To: <1451685633.1.0.273350637631.issue25987@psf.upfronthosting.co.za>
Message-ID: <1460934152.68.0.894570522342.issue25987@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Because it's a change to collections.abc, it goes in 3.6 only.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25987>
_______________________________________

From report at bugs.python.org  Sun Apr 17 19:10:30 2016
From: report at bugs.python.org (Hrvoje Abraham)
Date: Sun, 17 Apr 2016 23:10:30 +0000
Subject: [issue26785] repr of -nan value should contain the sign
In-Reply-To: <1460832293.23.0.989531230725.issue26785@psf.upfronthosting.co.za>
Message-ID: <1460934630.34.0.118635800389.issue26785@psf.upfronthosting.co.za>


Hrvoje Abraham added the comment:

Sage:
http://doc.sagemath.org/html/en/reference/rings_numerical/sage/rings/complex_number.html

>>> log(ComplexNumber(NaN,1))
NaN - NaN*I

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26785>
_______________________________________

From report at bugs.python.org  Sun Apr 17 21:55:02 2016
From: report at bugs.python.org (Antony Lee)
Date: Mon, 18 Apr 2016 01:55:02 +0000
Subject: [issue26792] docstrings of runpy.run_{module,path} are rather sparse
Message-ID: <1460944502.67.0.955110104065.issue26792@psf.upfronthosting.co.za>


New submission from Antony Lee:

$ pydoc runpy

    run_module(mod_name, init_globals=None, run_name=None, alter_sys=False)
        Execute a module's code without importing it
        
        Returns the resulting top level namespace dictionary
    
    run_path(path_name, init_globals=None, run_name=None)
        Execute code located at the specified filesystem location
        
        Returns the resulting top level namespace dictionary
        
        The file path may refer directly to a Python script (i.e.
        one that could be directly executed with execfile) or else
        it may refer to a zipfile or directory containing a top
        level __main__.py script.

The meaning of the arguments should be documented (e.g. by copy-pasting the html docs).  (And some sentences are missing final dots.)

----------
assignee: docs at python
components: Documentation
messages: 263638
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: docstrings of runpy.run_{module,path} are rather sparse
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26792>
_______________________________________

From report at bugs.python.org  Mon Apr 18 00:27:39 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 18 Apr 2016 04:27:39 +0000
Subject: [issue25243] decouple string-to-boolean logic from
 ConfigParser.getboolean and offer as separate function
In-Reply-To: <1443307220.16.0.776749230814.issue25243@psf.upfronthosting.co.za>
Message-ID: <1460953659.98.0.575481122666.issue25243@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I'm not sure I see the point in moving this out to a separate method (i.e. I wouldn't want to see people importing configparser just to use this particular group of boolean word aliases).  In general, users would be better served by a simple dictionary that gives them the ability to say exactly which variants they want to allow ('y', 'n', 'enabled', 'disabled', etc).

Also, the preposition "from" in a method name usually indicates a classmethod that creates instances of the class where it is defined.

----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25243>
_______________________________________

From report at bugs.python.org  Mon Apr 18 00:51:59 2016
From: report at bugs.python.org (Steven Adams)
Date: Mon, 18 Apr 2016 04:51:59 +0000
Subject: [issue26793] uuid causing thread issues when forking using os.fork
 py3.4+
Message-ID: <1460955119.44.0.370193254434.issue26793@psf.upfronthosting.co.za>


New submission from Steven Adams:

I've ran into a strange issue after trying to port a project to support py 3.x

The app uses a double os.fork to run in the background. On py 3.4+ it seems that when you have an import uuid statement it causes threading.threads to always return false on is_alive()..

Here is an example of the issue. You can see i've imported uuid. This script should fork into the background and stay alive for at least 3 loops (3 seconds) but it dies after 1 loop as self._thread.is_alive() return False??

http://paste.pound-python.org/show/WbDkqPqu94zEstHG6Xl1/

This does NOT happen in py 2.7 or py3.3. Only occurs py3.4+

----------
components: Interpreter Core
messages: 263640
nosy: Steven Adams
priority: normal
severity: normal
status: open
title: uuid causing thread issues when forking using os.fork py3.4+
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26793>
_______________________________________

From report at bugs.python.org  Mon Apr 18 00:54:07 2016
From: report at bugs.python.org (Steven Adams)
Date: Mon, 18 Apr 2016 04:54:07 +0000
Subject: [issue26793] uuid causing thread issues when forking using os.fork
 py3.4+
In-Reply-To: <1460955119.44.0.370193254434.issue26793@psf.upfronthosting.co.za>
Message-ID: <1460955247.76.0.3804823187.issue26793@psf.upfronthosting.co.za>


Steven Adams added the comment:

I forgot to mention if i remove import uuid all works as expected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26793>
_______________________________________

From report at bugs.python.org  Mon Apr 18 01:26:11 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Apr 2016 05:26:11 +0000
Subject: [issue25987] collections.abc.Reversible
In-Reply-To: <1451685633.1.0.273350637631.issue25987@psf.upfronthosting.co.za>
Message-ID: <20160418052602.88648.87702.884C3893@psf.io>


Roundup Robot added the comment:

New changeset 7d9f7d7a21ae by Georg Brandl in branch 'default':
#25987: add versionadded to Reversible.
https://hg.python.org/cpython/rev/7d9f7d7a21ae

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25987>
_______________________________________

From report at bugs.python.org  Mon Apr 18 01:29:28 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 18 Apr 2016 05:29:28 +0000
Subject: [issue26733] staticmethod and classmethod are ignored when
 disassemble class
In-Reply-To: <1460369974.2.0.716803365246.issue26733@psf.upfronthosting.co.za>
Message-ID: <1460957368.32.0.656300363132.issue26733@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Looking at the history of the dis module, I'd now class this as a bug fix for 3.5+ - it looks like dis.dis gained the ability to disassemble static and class methods as a side-effect of the removal of bound methods in Python 3 (see https://hg.python.org/cpython/rev/48af6375207e ) but because it was a side effect, the additional changes needed to also handle them when disassembling a class were missed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26733>
_______________________________________

From report at bugs.python.org  Mon Apr 18 01:31:18 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 18 Apr 2016 05:31:18 +0000
Subject: [issue26793] uuid causing thread issues when forking using os.fork
 py3.4+
In-Reply-To: <1460955119.44.0.370193254434.issue26793@psf.upfronthosting.co.za>
Message-ID: <1460957478.9.0.815042609569.issue26793@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
nosy: +pitrou, xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26793>
_______________________________________

From report at bugs.python.org  Mon Apr 18 01:48:43 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 18 Apr 2016 05:48:43 +0000
Subject: [issue26793] uuid causing thread issues when forking using os.fork
 py3.4+
In-Reply-To: <1460955119.44.0.370193254434.issue26793@psf.upfronthosting.co.za>
Message-ID: <1460958523.86.0.236338418108.issue26793@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

It seems a matter of lib uuid. The comments in uuid.py tells that the module is not thread-safe. I try to comment out the code using ctypes and rerun your sample, it works well. 

In uuid's documentation it does not mention the non-thread-safe characteristic. Maybe we should add it.

----------
nosy:  -pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26793>
_______________________________________

From report at bugs.python.org  Mon Apr 18 01:53:47 2016
From: report at bugs.python.org (Steven Adams)
Date: Mon, 18 Apr 2016 05:53:47 +0000
Subject: [issue26793] uuid causing thread issues when forking using os.fork
 py3.4+
In-Reply-To: <1460955119.44.0.370193254434.issue26793@psf.upfronthosting.co.za>
Message-ID: <1460958827.54.0.0367733309484.issue26793@psf.upfronthosting.co.za>


Steven Adams added the comment:

Shouldn't that mean it also breaks on py3.3?

As a workaround i just import uuid later within the thread method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26793>
_______________________________________

From report at bugs.python.org  Mon Apr 18 02:14:17 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 18 Apr 2016 06:14:17 +0000
Subject: [issue26793] uuid causing thread issues when forking using os.fork
 py3.4+
In-Reply-To: <1460955119.44.0.370193254434.issue26793@psf.upfronthosting.co.za>
Message-ID: <1460960057.71.0.0936016034573.issue26793@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Sorry. I forgot to take that into consideration. I think now the problem appears because of ctypes. Simply import ctypes instead of uuid can also lead to your problem.

----------
nosy: +amaury.forgeotdarc, belopolsky, meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26793>
_______________________________________

From report at bugs.python.org  Mon Apr 18 02:52:32 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Apr 2016 06:52:32 +0000
Subject: [issue26765] Factor out common bytes and bytearray implementation
In-Reply-To: <1460707559.13.0.709090380773.issue26765@psf.upfronthosting.co.za>
Message-ID: <1460962352.27.0.486163640714.issue26765@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

>   1. The diffs are fairly large.  It might be easier to follow if you stage
>      the two steps above as separate commits (if possible).

OK. Here is the first part of the patch. It moves common code and docstrings in bytes_methods.c.

>   2. Why are some of the namings in stringlib inconsistent?  For example,
>      `stringlib_method_find` and `stringlib_index`.  In other words, why
>      do some names have the *_method_* part?

There were conflicts with existing names stringlib_find and stringlib_rfind.

----------
Added file: http://bugs.python.org/file42502/bytes_methods_stage1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26765>
_______________________________________

From report at bugs.python.org  Mon Apr 18 03:03:52 2016
From: report at bugs.python.org (Steven Adams)
Date: Mon, 18 Apr 2016 07:03:52 +0000
Subject: [issue26793] uuid causing thread issues when forking using os.fork
 py3.4+
In-Reply-To: <1460955119.44.0.370193254434.issue26793@psf.upfronthosting.co.za>
Message-ID: <1460963032.78.0.598060715237.issue26793@psf.upfronthosting.co.za>


Steven Adams added the comment:

My workaround didn't work either.. We are a number of third party libs including flask. As soon as i import flask the issues remains.. Maybe something with flask is importing ctypes?

Something aint right..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26793>
_______________________________________

From report at bugs.python.org  Mon Apr 18 03:08:23 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 18 Apr 2016 07:08:23 +0000
Subject: [issue26793] uuid causing thread issues when forking using os.fork
 py3.4+
In-Reply-To: <1460955119.44.0.370193254434.issue26793@psf.upfronthosting.co.za>
Message-ID: <1460963303.18.0.737423858904.issue26793@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I am not sure what the real problem is. What I can see now it that it seems ctypes affects process fork. If you create the thread after fork, for example, in wait, your example works well. But if the thread participates in process fork, it fails.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26793>
_______________________________________

From report at bugs.python.org  Mon Apr 18 03:20:05 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Apr 2016 07:20:05 +0000
Subject: [issue26793] uuid causing thread issues when forking using os.fork
 py3.4+
In-Reply-To: <1460955119.44.0.370193254434.issue26793@psf.upfronthosting.co.za>
Message-ID: <1460964005.83.0.517122663459.issue26793@psf.upfronthosting.co.za>


STINNER Victor added the comment:

IMHO it's a bad idea to create a thread before forking. I suggest you to not create any kind of resource before calling daemonize().

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26793>
_______________________________________

From report at bugs.python.org  Mon Apr 18 03:29:36 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 18 Apr 2016 07:29:36 +0000
Subject: [issue26793] uuid causing thread issues when forking using os.fork
 py3.4+
In-Reply-To: <1460955119.44.0.370193254434.issue26793@psf.upfronthosting.co.za>
Message-ID: <1460964576.45.0.25867766325.issue26793@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I write a simple example which behaviour is like Steven's example.

import os
import sys
import threading
import ctypes
import time

def test():
    while True:
        print(time.time())

_thread = threading.Thread(target=test)

pid = os.fork()
if pid > 0:
    sys.exit(0)

_thread.start()

Run this with py3.4 emits one print and then comes fatal error:

[code]$ python3 ctypes_test.py 
1460964519.9721818
[code]$ Fatal Python error: could not acquire lock for <_io.BufferedWriter name='<stdout>'> at interpreter shutdown, possibly due to daemon threads

Thread 0x00007f41fdadf700 (most recent call first):
  File "ctypes_test.py", line 9 in test
  File "/usr/lib/python3.4/threading.py", line 868 in run
  File "/usr/lib/python3.4/threading.py", line 920 in _bootstrap_inner
  File "/usr/lib/python3.4/threading.py", line 888 in _bootstrap

Current thread 0x00007f41ff9a9700 (most recent call first):
^C

Without import ctypes, it's OK.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26793>
_______________________________________

From report at bugs.python.org  Mon Apr 18 03:47:44 2016
From: report at bugs.python.org (Jacek Pliszka)
Date: Mon, 18 Apr 2016 07:47:44 +0000
Subject: [issue26794] curframe can be None in pdb.py
Message-ID: <1460965664.24.0.92280915097.issue26794@psf.upfronthosting.co.za>


New submission from Jacek Pliszka:

In /usr/lib64/python2.7/pdb.py in
Pdb.default there is line:

globals = self.curframe.f_globals

curframe can be None so the line should be replaced by:

globals = getattr(self.curframe, "f_globals", None) if hasattr(self, 'curframe') else None

or something should be done in different way in setup

----------
components: Library (Lib)
messages: 263652
nosy: Jacek.Pliszka
priority: normal
severity: normal
status: open
title: curframe can be None in pdb.py
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26794>
_______________________________________

From report at bugs.python.org  Mon Apr 18 04:02:49 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Apr 2016 08:02:49 +0000
Subject: [issue26657] Directory traversal with http.server and
 SimpleHTTPServer on windows
In-Reply-To: <1459179015.77.0.509336394494.issue26657@psf.upfronthosting.co.za>
Message-ID: <20160418080242.89045.10263.643C0AC2@psf.io>


Roundup Robot added the comment:

New changeset 8054a68dfce2 by Martin Panter in branch '3.5':
Issue #26657: Fix Windows directory traversal vulnerability with http.server
https://hg.python.org/cpython/rev/8054a68dfce2

New changeset 5d8042ab3361 by Martin Panter in branch 'default':
Issue #26657: Merge http.server fix from 3.5
https://hg.python.org/cpython/rev/5d8042ab3361

New changeset 8aa032b26552 by Martin Panter in branch '2.7':
Issue #26657: Fix SimpleHTTPServer Windows directory traversal vulnerability
https://hg.python.org/cpython/rev/8aa032b26552

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26657>
_______________________________________

From report at bugs.python.org  Mon Apr 18 04:09:08 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 18 Apr 2016 08:09:08 +0000
Subject: [issue26791] shutil.move fails to move symlink (Invalid cross-device
 link)
In-Reply-To: <1460912297.17.0.227992133358.issue26791@psf.upfronthosting.co.za>
Message-ID: <1460966948.79.0.73143682258.issue26791@psf.upfronthosting.co.za>


SilentGhost added the comment:

This seems to be only triggered when moving a symlink into its destination. Assumption in the code is that when _samefile returns True, it must be due to case-insensitive filesystem, rather than this edge case.

----------
nosy: +SilentGhost, tarek
type:  -> behavior
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26791>
_______________________________________

From report at bugs.python.org  Mon Apr 18 04:10:37 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Apr 2016 08:10:37 +0000
Subject: [issue26793] uuid causing thread issues when forking using os.fork
 py3.4+
In-Reply-To: <1460955119.44.0.370193254434.issue26793@psf.upfronthosting.co.za>
Message-ID: <1460967037.99.0.52143660746.issue26793@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/issue26793>
_______________________________________

From report at bugs.python.org  Mon Apr 18 04:10:56 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 18 Apr 2016 08:10:56 +0000
Subject: [issue26794] curframe can be None in pdb.py
In-Reply-To: <1460965664.24.0.92280915097.issue26794@psf.upfronthosting.co.za>
Message-ID: <1460967056.12.0.222230219788.issue26794@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26794>
_______________________________________

From report at bugs.python.org  Mon Apr 18 04:21:14 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Apr 2016 08:21:14 +0000
Subject: [issue26793] uuid causing thread issues when forking using os.fork
 py3.4+
In-Reply-To: <1460955119.44.0.370193254434.issue26793@psf.upfronthosting.co.za>
Message-ID: <1460967674.98.0.066369575698.issue26793@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hum, I should elaborate my explanation :-) os.fork() removes all threads except of the current thread. It's clearly stated in the fork manual page, but the Python os.fork() doesn't say anything about threads.
https://docs.python.org/dev/library/os.html#os.fork

Short example:
---
import os, threading, time

t = threading.Thread(target=time.sleep, args=(3.0,))
t.start()

print("First process", threading.enumerate())

pid = os.fork()
if pid != 0:
    os.waitpid(pid, 0)
else:
    print("Child process", threading.enumerate())
---

Output:
---
First process [<_MainThread(MainThread, started 140737353955072)>, <Thread(Thread-1, started 140737216849664)>]
Child process [<_MainThread(MainThread, started 140737353955072)>]
---

The thread is removed in the child process.

Again, *don't create threads before fork*. More generally, don't create any resource before fork: don't open files, don't create locks, don't open a connection to a database, don't start an event loop, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26793>
_______________________________________

From report at bugs.python.org  Mon Apr 18 04:30:13 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 18 Apr 2016 08:30:13 +0000
Subject: [issue26793] uuid causing thread issues when forking using os.fork
 py3.4+
In-Reply-To: <1460955119.44.0.370193254434.issue26793@psf.upfronthosting.co.za>
Message-ID: <1460968213.03.0.0153863537913.issue26793@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I should not make more noise after realizing it's matter of thread and process. Sorry. :-( Except this one. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26793>
_______________________________________

From report at bugs.python.org  Mon Apr 18 04:30:40 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Apr 2016 08:30:40 +0000
Subject: [issue26777] test_asyncio: test_timeout_disable() fails randomly
In-Reply-To: <1460810109.63.0.0563263496249.issue26777@psf.upfronthosting.co.za>
Message-ID: <20160418083037.26077.48279.6B82ED69@psf.io>


Roundup Robot added the comment:

New changeset 730a95c2d38f by Victor Stinner in branch '3.5':
Fix test_asyncio.test_timeout_disable()
https://hg.python.org/cpython/rev/730a95c2d38f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26777>
_______________________________________

From report at bugs.python.org  Mon Apr 18 04:32:31 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Apr 2016 08:32:31 +0000
Subject: [issue26777] test_asyncio: test_timeout_disable() fails randomly
In-Reply-To: <1460810109.63.0.0563263496249.issue26777@psf.upfronthosting.co.za>
Message-ID: <1460968351.52.0.278237952967.issue26777@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The same test failed one more time, I pushed a fix.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26777>
_______________________________________

From report at bugs.python.org  Mon Apr 18 04:56:42 2016
From: report at bugs.python.org (Wolfgang Maier)
Date: Mon, 18 Apr 2016 08:56:42 +0000
Subject: [issue18378] locale.getdefaultlocale() fails on Mac OS X with default
 language set to English
In-Reply-To: <1373113143.69.0.513997485887.issue18378@psf.upfronthosting.co.za>
Message-ID: <1460969802.49.0.317557445096.issue18378@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

ping?

Just ran into this issue on OS X El Capitan with Region set to Germany and Language to English. Just as Ned pointed out 2 years ago, this results in LC_CTYPE set to 'UTF-8' in the terminal and docutils still can't cope with it.

----------
nosy: +wolma

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18378>
_______________________________________

From report at bugs.python.org  Mon Apr 18 05:20:57 2016
From: report at bugs.python.org (Steven Adams)
Date: Mon, 18 Apr 2016 09:20:57 +0000
Subject: [issue26793] uuid causing thread issues when forking using os.fork
 py3.4+
In-Reply-To: <1460955119.44.0.370193254434.issue26793@psf.upfronthosting.co.za>
Message-ID: <1460971257.24.0.095522605338.issue26793@psf.upfronthosting.co.za>


Steven Adams added the comment:

Ok but the question still remains, why does it only happen on py3.4+??

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26793>
_______________________________________

From report at bugs.python.org  Mon Apr 18 05:41:33 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 18 Apr 2016 09:41:33 +0000
Subject: [issue26657] Directory traversal with http.server and
 SimpleHTTPServer on windows
In-Reply-To: <1459179015.77.0.509336394494.issue26657@psf.upfronthosting.co.za>
Message-ID: <1460972493.35.0.764341805144.issue26657@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the report and the patch.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26657>
_______________________________________

From report at bugs.python.org  Mon Apr 18 08:25:18 2016
From: report at bugs.python.org (MICHAEL JACOBSON)
Date: Mon, 18 Apr 2016 12:25:18 +0000
Subject: [issue26739] idle: Errno 10035 a non-blocking socket operation could
 not be completed immediately
In-Reply-To: <1460409859.89.0.789703447955.issue26739@psf.upfronthosting.co.za>
Message-ID: <1460982318.15.0.817978120534.issue26739@psf.upfronthosting.co.za>


MICHAEL JACOBSON added the comment:

0. I have Python 2.7.5
1. I don't know what you mean.
2. It fails right when I run it.
IDLE stands for Python's Integrated DeveLopment Environment
I am running IDLE / Python on a Windows Vista, Service pack 2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26739>
_______________________________________

From report at bugs.python.org  Mon Apr 18 08:40:37 2016
From: report at bugs.python.org (Erik Bray)
Date: Mon, 18 Apr 2016 12:40:37 +0000
Subject: [issue8027] distutils fail to determine c++ linker with unixcompiler
 if using ccache
In-Reply-To: <1267284243.46.0.756608052144.issue8027@psf.upfronthosting.co.za>
Message-ID: <1460983237.66.0.934317777155.issue8027@psf.upfronthosting.co.za>


Changes by Erik Bray <erik.m.bray at gmail.com>:


----------
nosy: +erik.bray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8027>
_______________________________________

From report at bugs.python.org  Mon Apr 18 09:08:00 2016
From: report at bugs.python.org (Erik Bray)
Date: Mon, 18 Apr 2016 13:08:00 +0000
Subject: [issue8027] distutils fail to determine c++ linker with unixcompiler
 if using ccache
In-Reply-To: <1267284243.46.0.756608052144.issue8027@psf.upfronthosting.co.za>
Message-ID: <1460984880.34.0.852469109196.issue8027@psf.upfronthosting.co.za>


Erik Bray added the comment:

I'm also inclined to agree that the buggy code (and it *is* buggy even if it was meant to fix something originally) should be removed outright.  Nobody can point to a real world issue that it fixes anymore, yet we can point to real world consequences caused by this bug still.

However, I could also agree that this should come with better support for CXXFLAGS and CXXLINK.  It's no wonder these variables are ignored by CPython--it doesn't use any c++.  That said, extension module compilation is tied, through distutils, to CPython. And there are plenty of c++ extension modules in the wild that are affected.  So it's worth addressing how these variables are used--or rather not used properly--by distutils.

I'd be happy to take a look at that if that sounds like a good approach?  Otherwise I'd push for accepting some versions of the existing patches by Joshua.J.Cogliati that remove the buggy code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8027>
_______________________________________

From report at bugs.python.org  Mon Apr 18 09:40:10 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 18 Apr 2016 13:40:10 +0000
Subject: [issue15994] memoryview to freed memory can cause segfault
In-Reply-To: <1348173441.91.0.841080415833.issue15994@psf.upfronthosting.co.za>
Message-ID: <1460986810.65.0.0942259810746.issue15994@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think idea 2 (error if memoryview not released) would not work. It would rely on garbage collection, which is not always immediate. E.g. if the memoryview were kept alive by a reference cycle, it may not immediately be released. I don?t think idea 3 is worthwhile, because the memoryview API does not seem designed for this use case, and it would not be 100% consistent anyway.

So that leaves my first idea, to call view.release() when readinto(), etc, return. This should avoid the crash and data loss problems in some common cases. It is implemented in release-view.patch, along with some notes.

----------
components: +Unicode
keywords: +patch
nosy: +ezio.melotti, haypo
stage:  -> patch review
Added file: http://bugs.python.org/file42503/release-view.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15994>
_______________________________________

From report at bugs.python.org  Mon Apr 18 09:43:40 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 18 Apr 2016 13:43:40 +0000
Subject: [issue26720] memoryview from BufferedWriter becomes garbage
In-Reply-To: <1460203726.07.0.470306343445.issue26720@psf.upfronthosting.co.za>
Message-ID: <1460987020.76.0.313169945284.issue26720@psf.upfronthosting.co.za>


Martin Panter added the comment:

Closing this as a duplicate of Issue 15994, where I have proposed a patch to add a note for RawIOBase.write(), and call memoryview.release() when the method returns.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> memoryview to freed memory can cause segfault

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26720>
_______________________________________

From report at bugs.python.org  Mon Apr 18 09:46:45 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Mon, 18 Apr 2016 13:46:45 +0000
Subject: [issue26787] test_distutils fails when configured --with-lto
In-Reply-To: <1460874085.6.0.334729464026.issue26787@psf.upfronthosting.co.za>
Message-ID: <1460987205.93.0.663782491395.issue26787@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

Hello,

You can find a patch for this issue attached. Basically, since LTO needs LD flags when used, I modified the makefile template file and the test to push the flags up to the sysconfig module.

----------
keywords: +patch
Added file: http://bugs.python.org/file42504/issue26787.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26787>
_______________________________________

From report at bugs.python.org  Mon Apr 18 09:48:11 2016
From: report at bugs.python.org (Marat Sharafutdinov)
Date: Mon, 18 Apr 2016 13:48:11 +0000
Subject: [issue26795] Fix PEP 344 Python version
Message-ID: <1460987291.12.0.969662098571.issue26795@psf.upfronthosting.co.za>


New submission from Marat Sharafutdinov:

Should be 3.0 instead of 2.5

----------
assignee: docs at python
components: Documentation
files: pep-0344-version.patch
keywords: patch
messages: 263667
nosy: decaz, docs at python
priority: normal
severity: normal
status: open
title: Fix PEP 344 Python version
type: enhancement
Added file: http://bugs.python.org/file42505/pep-0344-version.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26795>
_______________________________________

From report at bugs.python.org  Mon Apr 18 09:56:17 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 18 Apr 2016 13:56:17 +0000
Subject: [issue26795] Fix PEP 344 Python version
In-Reply-To: <1460987291.12.0.969662098571.issue26795@psf.upfronthosting.co.za>
Message-ID: <1460987777.56.0.539564115077.issue26795@psf.upfronthosting.co.za>


SilentGhost added the comment:

I think the note at the top makes it perfectly clear that PEP 344 is superseded by PEP 3134 which has correct Python version.

----------
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26795>
_______________________________________

From report at bugs.python.org  Mon Apr 18 10:43:59 2016
From: report at bugs.python.org (Hans Lawrenz)
Date: Mon, 18 Apr 2016 14:43:59 +0000
Subject: [issue26796] BaseEventLoop.run_in_executor shouldn't specify
 max_workers for default Executor
Message-ID: <1460990639.79.0.271352232569.issue26796@psf.upfronthosting.co.za>


New submission from Hans Lawrenz:

In issue 21527 <http://bugs.python.org/issue21527> the concurrent.futures.ThreadPoolExecutor was changed to have a default value for max_workers. When asyncio.base_events.BaseEventLoop.run_in_executor creates a default ThreadPoolExecutor it specifies a value of 5 for max_workers, presumably because at the time it was written ThreadPoolExecutor didn't have a default for max_workers. This is confusing because on reading the documentation for ThreadPoolExecutor one might assume that the default specified there is what will be used if a default executor isn't supplied via BaseEventLoop.set_default_executor.

I propose that BaseEventLoop.run_in_executor be changed to not supply a default for max_workers. If this isn't acceptable, a note ought to be put in the run_in_executor documentation.

----------
components: asyncio
files: run_in_executor_max_workers.patch
keywords: patch
messages: 263669
nosy: Hans Lawrenz, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: BaseEventLoop.run_in_executor shouldn't specify max_workers for default Executor
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file42506/run_in_executor_max_workers.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26796>
_______________________________________

From report at bugs.python.org  Mon Apr 18 11:19:00 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 18 Apr 2016 15:19:00 +0000
Subject: [issue26796] BaseEventLoop.run_in_executor shouldn't specify
 max_workers for default Executor
In-Reply-To: <1460990639.79.0.271352232569.issue26796@psf.upfronthosting.co.za>
Message-ID: <1460992740.88.0.610142784946.issue26796@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I like this idea for 3.5 and later. I know this is a pain, but I would like the code to have a version check so that the identical code can still be used in Python 3.3 and 3.4. We go through great lengths to keep the asyncio package compatible with those versions so that we can occasionally push a version out to PyPI for 3.3 and 3.4 users. If the versions diverge we would be unable to keep track of other bug fixes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26796>
_______________________________________

From report at bugs.python.org  Mon Apr 18 11:43:32 2016
From: report at bugs.python.org (Hans Lawrenz)
Date: Mon, 18 Apr 2016 15:43:32 +0000
Subject: [issue26796] BaseEventLoop.run_in_executor shouldn't specify
 max_workers for default Executor
In-Reply-To: <1460990639.79.0.271352232569.issue26796@psf.upfronthosting.co.za>
Message-ID: <1460994212.14.0.663807893417.issue26796@psf.upfronthosting.co.za>


Hans Lawrenz added the comment:

Thanks, that makes sense. I've attached a patch with a version check.

----------
Added file: http://bugs.python.org/file42507/run_in_executor_max_workers_vcheck.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26796>
_______________________________________

From report at bugs.python.org  Mon Apr 18 12:38:50 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 18 Apr 2016 16:38:50 +0000
Subject: [issue26796] BaseEventLoop.run_in_executor shouldn't specify
 max_workers for default Executor
In-Reply-To: <1460990639.79.0.271352232569.issue26796@psf.upfronthosting.co.za>
Message-ID: <1460997530.83.0.164608774384.issue26796@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

There should at least be a comment at the definition of _MAX_WORKERS that it's only used on Python 3.4 and before.

Maybe a note in the docs about the default executor would also be useful.

Otherwise this is exactly what I had in mind -- thanks!

PS. Could you sign a contributor form online
https://www.python.org/psf/contrib/contrib-form/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26796>
_______________________________________

From report at bugs.python.org  Mon Apr 18 12:55:22 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Mon, 18 Apr 2016 16:55:22 +0000
Subject: [issue26787] test_distutils fails when configured --with-lto
In-Reply-To: <1460874085.6.0.334729464026.issue26787@psf.upfronthosting.co.za>
Message-ID: <1460998522.51.0.428311934485.issue26787@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

This patch is for CPython 3, and if it looks good I will post also the CPython 2 version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26787>
_______________________________________

From report at bugs.python.org  Mon Apr 18 13:40:06 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 18 Apr 2016 17:40:06 +0000
Subject: [issue22873] Re: SSLsocket.getpeercert - return ALL the fields of the
 certificate.
In-Reply-To: <1415988206.94.0.332443874226.issue22873@psf.upfronthosting.co.za>
Message-ID: <1461001206.93.0.477817549571.issue22873@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> ssl.getpeercert() should include extensions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22873>
_______________________________________

From report at bugs.python.org  Mon Apr 18 14:19:51 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Apr 2016 18:19:51 +0000
Subject: [issue26615] Missing entry in WRAPPER_ASSIGNMENTS in update_wrapper's
 doc
In-Reply-To: <1458704141.94.0.68234227835.issue26615@psf.upfronthosting.co.za>
Message-ID: <20160418181948.7131.91870.FC6AD19F@psf.io>


Roundup Robot added the comment:

New changeset 11d8f5d1968d by Berker Peksag in branch '3.5':
Issue #26615: Add missing __qualname__ entry to functools.update_wrapper() docs
https://hg.python.org/cpython/rev/11d8f5d1968d

New changeset ee9921b29fd8 by Berker Peksag in branch 'default':
Issue #26615: Add missing __qualname__ entry to functools.update_wrapper() docs
https://hg.python.org/cpython/rev/ee9921b29fd8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26615>
_______________________________________

From report at bugs.python.org  Mon Apr 18 14:21:42 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 18 Apr 2016 18:21:42 +0000
Subject: [issue26615] Missing entry in WRAPPER_ASSIGNMENTS in update_wrapper's
 doc
In-Reply-To: <1458704141.94.0.68234227835.issue26615@psf.upfronthosting.co.za>
Message-ID: <1461003702.67.0.948680020395.issue26615@psf.upfronthosting.co.za>


Berker Peksag added the comment:

__qualname__ was added to WRAPPER_ASSIGNMENTS in 963e98f5ad31 (issue 13544).

Thanks for the patch!

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26615>
_______________________________________

From report at bugs.python.org  Mon Apr 18 14:23:10 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 18 Apr 2016 18:23:10 +0000
Subject: [issue26739] idle: Errno 10035 a non-blocking socket operation could
 not be completed immediately
In-Reply-To: <1460409859.89.0.789703447955.issue26739@psf.upfronthosting.co.za>
Message-ID: <1461003790.73.0.254122725986.issue26739@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

0. OK, 2.7.5 came out in 2013 May, after the 2.7 backport.  Kristj?n, you did the backport.  Do you have any idea about this?

1. Open a Command Prompt window, the command line console.  For Win 7, it can be found find it on the Start menu under Admin or something or started on the run line with 'cmd.exe'.  You should learn how to get the console.

On the command line, after the ...> prompt, enter "python patth/to/Skier.py".

Or, maybe, find Skier.py in Windows Explorer, and either double click or right-click and select "Run".  (I am not sure if this works with 2.7.5 on Vista.)

----------
keywords: +3.4regression
nosy: +kristjan.jonsson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26739>
_______________________________________

From report at bugs.python.org  Mon Apr 18 14:33:10 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 18 Apr 2016 18:33:10 +0000
Subject: [issue26785] repr of -nan value should contain the sign
In-Reply-To: <1460832293.23.0.989531230725.issue26785@psf.upfronthosting.co.za>
Message-ID: <1461004390.47.0.729784211263.issue26785@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> Looks like the sign bit is off (0) in 2.7.

Yep, that looks like issue 22590. It's "fixed" in Python 3, and I don't think it's worth changing in Python 2.

About this issue (sign in repr of NaN): sorry, but I'm unconvinced. :-)

>From the standpoint of IEEE 754, the only part that's really relevant is section 5.12 ("Details of conversion between floating-point data and external character sequences"), and there's nothing in that section indicating that a sign is either recommended or required. The most relevant part is this one:

"""
Conversion of a quiet NaN in a supported format to an external character sequence shall produce a language-defined one of ?nan? or a sequence that is equivalent except for case (e.g., ?NaN?), with an optional preceding sign. (This standard does not interpret the sign of a NaN.)
"""

Yes, it's true that copysign copies the sign bit, but I don't see the leap from there to saying that the *repr* of a NaN should include it. total_order doesn't really seem relevant here, since Python doesn't implement it, and if it were implemented that implementation would almost certainly not be via the repr.

To your catan example: Python follows Annex G of the C99 specification for its cmath functions. catan is specified in terms of catanh, and the relevant line there is:
"""
catanh(NaN + i?) returns ?0 + i? /2 (where the sign of the real part of the result is unspecified).
"""
Note that the sign of the zero is unspecified here. There's no part of Annex G that introduces any dependence on the sign of a NaN. So no, unlike the sign of a zero, the sign of a NaN does *not* play a role in selecting which side of a branch cut an input to a complex function lies on. (The branch cuts for cmath.atan are both on the imaginary axis, with real part 0; while it's not really clear what kind of topology applies to a C99-style extended complex plane, it would be a stretch to regard inf +/- iNaN as being anywhere on or near that branch cut.)

The roundtrip argument doesn't really hold water either: a quiet NaN has 52 extra bits of information - a sign bit and a 51-bit payload; if we were attempting to roundtrip the bits, we'd need to include the payload information too. I don't see that it's any more important to distinguish NaNs with different signs than to distinguish NaNs with different payloads.

> MSVC 2015 and MinGW-W64 v4.9.2 output (source below) for '-nan' values are:
> MSVC:      -nan(ind)
> MinGW-W64: -1.#IND00

Sure, and clang on OS X produces "nan" for the same source.

> It is reasonable to assume some will need to preserve it.

Maybe, but I've read and worked with a lot of numerical code over the last two and a half decades, and I have yet to see any whose correctness depends on interpreting the sign of a NaN. Access to the sign bit of a NaN is a rare need, and not something that needs be included in the repr. For those who really do need it for some kind of custom use-case, it's not hard to use copysign to extract it.

In sum, I don't see any benefit to adding the sign, and there's an obvious drawback in the form of code breakage (in doctests, for example).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26785>
_______________________________________

From report at bugs.python.org  Mon Apr 18 14:35:08 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 18 Apr 2016 18:35:08 +0000
Subject: [issue26785] repr of -nan value should contain the sign
In-Reply-To: <1460832293.23.0.989531230725.issue26785@psf.upfronthosting.co.za>
Message-ID: <1461004508.89.0.903138036817.issue26785@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26785>
_______________________________________

From report at bugs.python.org  Mon Apr 18 14:35:54 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 18 Apr 2016 18:35:54 +0000
Subject: [issue26797] Segafault in _PyObject_Alloc
Message-ID: <1461004554.65.0.108278995171.issue26797@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

I'm working on an implementation of asyncio event loop on top of libuv [1].  One of my tests crashes on Mac OS X with a segfault [2].  The problem is that it's not consistent -- looks like it depends on size of uvloop so binary, or/and amount of objects allocated in program.

I can't reproduce the problem on a debug build, or write a test for it, it is really a weird edge-case.  But I'm certain that we have a bug in our memory allocator.

Here's a screenshot of crash log [3], and here's an lldb disassembly of crash location [4].

Now, what's going on in [2] is:
1. uvloop sets a sigint signal handler the moment it starts the loop
2. uvloop start to execute a coroutine, which blocks on a long "time.sleep(..)" call
3. sigint handler receives a SIGINT and calls PyErr_SetInterrupt
4. CPython interrupts the code, KeyboardInterrupt is instantiated and raised
5. CPython starts to render the traceback to print it to stderr, and this is where it tries to allocate some object, and this is where we hit a bad-access in _PyObject_Alloc.

I'd really appreciate any ideas on what's going on here and how we can fix this.


[1] https://github.com/magicstack/uvloop
[2] https://github.com/MagicStack/uvloop/blob/v0.4.6/tests/test_signals.py#L14
[3] http://imgur.com/6GcE92X
[4] https://gist.github.com/1st1/b46f3702aeb1b57fe4ad32b19ed63c3f

----------
messages: 263678
nosy: haypo, ned.deily, serhiy.storchaka, yselivanov
priority: normal
severity: normal
stage: test needed
status: open
title: Segafault in _PyObject_Alloc
type: crash
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26797>
_______________________________________

From report at bugs.python.org  Mon Apr 18 14:40:12 2016
From: report at bugs.python.org (Zooko Wilcox-O'Hearn)
Date: Mon, 18 Apr 2016 18:40:12 +0000
Subject: [issue26798] add BLAKE2 to hashlib
Message-ID: <1461004812.44.0.872226457841.issue26798@psf.upfronthosting.co.za>


New submission from Zooko Wilcox-O'Hearn:

(Disclosure: I'm one of the authors of BLAKE2.)

Please include BLAKE2 in hashlib. It well-suited for hashing long inputs (e.g. files), because it is substantially faster than SHA-3, SHA-2, SHA-1, or MD5 while also being safer than SHA-2, SHA-1, or MD5.

BLAKE2 and/or its relatives, BLAKE, ChaCha20, and Salsa20, have gotten extensive cryptographic peer review.

It is widely used in modern applications and widely supported in modern crypto libraries (https://en.wikipedia.org/wiki/BLAKE_%28hash_function%29#BLAKE2_uses).

Here is the official reference implementation: https://github.com/BLAKE2

Here are some Python modules (wrappers or implementations):
 * https://github.com/buggywhip/blake2_py
 * https://github.com/dchest/pyblake2
 * https://github.com/darjeeling/python-blake2

----------
components: Library (Lib)
messages: 263679
nosy: Zooko.Wilcox-O'Hearn, dstufft
priority: normal
severity: normal
status: open
title: add BLAKE2 to hashlib

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26798>
_______________________________________

From report at bugs.python.org  Mon Apr 18 14:41:15 2016
From: report at bugs.python.org (Zooko Wilcox-O'Hearn)
Date: Mon, 18 Apr 2016 18:41:15 +0000
Subject: [issue26798] add BLAKE2 to hashlib
In-Reply-To: <1461004812.44.0.872226457841.issue26798@psf.upfronthosting.co.za>
Message-ID: <1461004875.7.0.995120221983.issue26798@psf.upfronthosting.co.za>


Zooko Wilcox-O'Hearn added the comment:

Oh, just to be clear, I didn't mean to imply that BLAKE2 is _less_ safe than SHA-3. My best estimate is that BLAKE2 and SHA-3 are equivalently safe, and that either of them is safer than SHA-2, SHA-1, or MD5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26798>
_______________________________________

From report at bugs.python.org  Mon Apr 18 14:41:29 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Apr 2016 18:41:29 +0000
Subject: [issue26755] Update version{added,changed} docs in devguide
In-Reply-To: <1460626724.97.0.188358038821.issue26755@psf.upfronthosting.co.za>
Message-ID: <20160418184123.107518.68091.954E671E@psf.io>


Roundup Robot added the comment:

New changeset 6ef3d77b3c27 by Berker Peksag in branch 'default':
Issue #26755: Clarify when version{added,changed} directives should be used in docs
https://hg.python.org/devguide/rev/6ef3d77b3c27

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26755>
_______________________________________

From report at bugs.python.org  Mon Apr 18 14:41:43 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 18 Apr 2016 18:41:43 +0000
Subject: [issue26755] Update version{added,changed} docs in devguide
In-Reply-To: <1460626724.97.0.188358038821.issue26755@psf.upfronthosting.co.za>
Message-ID: <1461004903.22.0.271817190664.issue26755@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26755>
_______________________________________

From report at bugs.python.org  Mon Apr 18 14:44:21 2016
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 18 Apr 2016 18:44:21 +0000
Subject: [issue26798] add BLAKE2 to hashlib
In-Reply-To: <1461004812.44.0.872226457841.issue26798@psf.upfronthosting.co.za>
Message-ID: <1461005061.65.0.434016951267.issue26798@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

Right now all the hashlib algorithms are backed by OpenSSL. OpenSSL 1.1.0 will have blake2, so perhaps the right move is just to wait for that to drop in a few weeks?

Sadly many users with old OpenSSL's still won't have blake2, but pretty quickly Windows and OS X users will get blake2!

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26798>
_______________________________________

From report at bugs.python.org  Mon Apr 18 14:48:40 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Apr 2016 18:48:40 +0000
Subject: [issue26797] Segafault in _PyObject_Alloc
In-Reply-To: <1461004554.65.0.108278995171.issue26797@psf.upfronthosting.co.za>
Message-ID: <1461005320.4.0.46536768234.issue26797@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26797>
_______________________________________

From report at bugs.python.org  Mon Apr 18 14:49:21 2016
From: report at bugs.python.org (Donald Stufft)
Date: Mon, 18 Apr 2016 18:49:21 +0000
Subject: [issue26798] add BLAKE2 to hashlib
In-Reply-To: <1461004812.44.0.872226457841.issue26798@psf.upfronthosting.co.za>
Message-ID: <1461005361.49.0.0882661043783.issue26798@psf.upfronthosting.co.za>


Donald Stufft added the comment:

> Right now all the hashlib algorithms are backed by OpenSSL.

As far as I know, hashlib ships it's own implementations of anything that is a guaranteed algorithms (currently md5, sha1, and sha2, presumably sha3 too once that gets added).

So I guess one question is whether we want to guarantee the existence of blake2 or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26798>
_______________________________________

From report at bugs.python.org  Mon Apr 18 14:53:34 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Apr 2016 18:53:34 +0000
Subject: [issue26798] add BLAKE2 to hashlib
In-Reply-To: <1461004812.44.0.872226457841.issue26798@psf.upfronthosting.co.za>
Message-ID: <1461005614.44.0.785219086757.issue26798@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +christian.heimes, gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26798>
_______________________________________

From report at bugs.python.org  Mon Apr 18 15:00:28 2016
From: report at bugs.python.org (Sriram Rajagopalan)
Date: Mon, 18 Apr 2016 19:00:28 +0000
Subject: [issue26779] pdb continue followed by an exception in the same frame
 shows incorrect frame linenumber
In-Reply-To: <1460812092.64.0.640871964672.issue26779@psf.upfronthosting.co.za>
Message-ID: <1461006028.51.0.563174183891.issue26779@psf.upfronthosting.co.za>


Changes by Sriram Rajagopalan <bglsriram at gmail.com>:


Added file: http://bugs.python.org/file42508/bdbfix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26779>
_______________________________________

From report at bugs.python.org  Mon Apr 18 15:01:38 2016
From: report at bugs.python.org (Sriram Rajagopalan)
Date: Mon, 18 Apr 2016 19:01:38 +0000
Subject: [issue26779] pdb continue followed by an exception in the same frame
 shows incorrect frame linenumber
In-Reply-To: <1460812092.64.0.640871964672.issue26779@psf.upfronthosting.co.za>
Message-ID: <1461006098.69.0.613513020371.issue26779@psf.upfronthosting.co.za>


Changes by Sriram Rajagopalan <bglsriram at gmail.com>:


Removed file: http://bugs.python.org/file42486/bdbfix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26779>
_______________________________________

From report at bugs.python.org  Mon Apr 18 15:01:52 2016
From: report at bugs.python.org (Hans Lawrenz)
Date: Mon, 18 Apr 2016 19:01:52 +0000
Subject: [issue26796] BaseEventLoop.run_in_executor shouldn't specify
 max_workers for default Executor
In-Reply-To: <1460990639.79.0.271352232569.issue26796@psf.upfronthosting.co.za>
Message-ID: <1461006112.23.0.327792145486.issue26796@psf.upfronthosting.co.za>


Hans Lawrenz added the comment:

New patch attached. Includes comments and a note in the documentation.

The documentation note is inside a versionchanged:: 3.5 block. Should this be more specific about the version it changed in? It could be confusing for someone using a version of 3.5 that doesn't have the change.

Contributor form is signed.

Thanks!

----------
Added file: http://bugs.python.org/file42509/run_in_executor_max_workers_with_docs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26796>
_______________________________________

From report at bugs.python.org  Mon Apr 18 15:03:41 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 18 Apr 2016 19:03:41 +0000
Subject: [issue26796] BaseEventLoop.run_in_executor shouldn't specify
 max_workers for default Executor
In-Reply-To: <1460990639.79.0.271352232569.issue26796@psf.upfronthosting.co.za>
Message-ID: <1461006221.88.0.199738811451.issue26796@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

LGTM!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26796>
_______________________________________

From report at bugs.python.org  Mon Apr 18 15:22:43 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 18 Apr 2016 19:22:43 +0000
Subject: [issue26785] repr of -nan value should contain the sign
In-Reply-To: <1460832293.23.0.989531230725.issue26785@psf.upfronthosting.co.za>
Message-ID: <1461007363.13.0.484130743194.issue26785@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

This StackOverflow answer from one of the IEEE 754 committee members is highly relevant here:

http://stackoverflow.com/a/21350299/270986

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26785>
_______________________________________

From report at bugs.python.org  Mon Apr 18 15:26:55 2016
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 18 Apr 2016 19:26:55 +0000
Subject: [issue26798] add BLAKE2 to hashlib
In-Reply-To: <1461004812.44.0.872226457841.issue26798@psf.upfronthosting.co.za>
Message-ID: <1461007615.32.0.57627331289.issue26798@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I have SHA-3, SHAKE and BLAKE2s / BLAKE2b on my radar.

PEP 247 and the current API definition of the hashlib module is too limited for the new hashing algorithms. It lacks variable output for SHAKE as well as salt and personalization for BLAKE. I started to work on PEP 452 while I was working on SHA-3 support for Python 3. The PEP is still work-in-progress. I can address the needs of BLAKE and submit the PEP to a formal review.

I'm already working on OpenSSL 1.1.0 support for Python. blake will be automatically supported with OpenSSL builds. See for yourself:

$ ./python 
Python 3.6.0a0 (default, Apr 18 2016, 21:16:54) 
[GCC 5.3.1 20160406 (Red Hat 5.3.1-6)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib
>>> import ssl
>>> ssl.OPENSSL_VERSION
'OpenSSL 1.1.0-pre5-dev  xx XXX xxxx'
>>> hashlib.new('BLAKE2s256').hexdigest()
'69217a3079908094e11121d042354a7c1f55b6482ca1a51e1b250dfd1ed0eef9'


Donald:
I love to add SHA-3 support to Python. After all I had a working patch for SHA-3 before NIST changed the padding. Now my old patch is worthless. The new reference implementations are either too complicated (spread across like twenty files for various optimizations) or are one-shot implementations. I'm still looking for a good implementation that supports incremental updates, copy and SHAKE at the same time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26798>
_______________________________________

From report at bugs.python.org  Mon Apr 18 17:08:27 2016
From: report at bugs.python.org (Hrvoje Abraham)
Date: Mon, 18 Apr 2016 21:08:27 +0000
Subject: [issue26785] repr of -nan value should contain the sign
In-Reply-To: <1460832293.23.0.989531230725.issue26785@psf.upfronthosting.co.za>
Message-ID: <1461013707.4.0.501825516664.issue26785@psf.upfronthosting.co.za>


Hrvoje Abraham added the comment:

IEEE & C/C++ standards allow and explicitly mention it, some people and projects are using it, many compilers preserve it...

I believe it's reasonable to support it despite the fact it does not have standardized semantic meaning. Maybe one day...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26785>
_______________________________________

From report at bugs.python.org  Mon Apr 18 17:10:02 2016
From: report at bugs.python.org (MICHAEL JACOBSON)
Date: Mon, 18 Apr 2016 21:10:02 +0000
Subject: [issue26739] idle: Errno 10035 a non-blocking socket operation could
 not be completed immediately
In-Reply-To: <1460409859.89.0.789703447955.issue26739@psf.upfronthosting.co.za>
Message-ID: <1461013802.89.0.2988203617.issue26739@psf.upfronthosting.co.za>


MICHAEL JACOBSON added the comment:

Is the command prompt itself admin?
I don't have access to the admin command prompt.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26739>
_______________________________________

From report at bugs.python.org  Mon Apr 18 17:10:40 2016
From: report at bugs.python.org (Thomas)
Date: Mon, 18 Apr 2016 21:10:40 +0000
Subject: [issue26799] gdb support fails with "Invalid cast."
Message-ID: <1461013840.26.0.744881925452.issue26799@psf.upfronthosting.co.za>


New submission from Thomas:

Trying to use any kind of python gdb integration results in the following error:

(gdb) py-bt
Traceback (most recent call first):
Python Exception <class 'gdb.error'> Invalid cast.: 
Error occurred in Python command: Invalid cast.

I have tracked it down to the _type_... globals, and I am able to fix it with the following commands:

(gdb) pi
>>> # Look up the gdb.Type for some standard types:
... _type_char_ptr = gdb.lookup_type('char').pointer() # char*
>>> _type_unsigned_char_ptr = gdb.lookup_type('unsigned char').pointer() # unsigned char*
>>> _type_void_ptr = gdb.lookup_type('void').pointer() # void*
>>> _type_unsigned_short_ptr = gdb.lookup_type('unsigned short').pointer()
>>> _type_unsigned_int_ptr = gdb.lookup_type('unsigned int').pointer()

After this, it works correctly. I was able to workaround it by making a fix_globals that resets the globals on each gdb.Command. I do not understand why the originally initialized types are not working properly. It feels like gdb-inception trying to debug python within a gdb that debugs cpython while executing python code.

I have tried this using hg/default cpython (--with-pydebug --without-pymalloc --with-valgrind --enable-shared) 
1) System install of gdb 7.11, linked against system libpython 3.5.1.
2) Custom install of gdb 7.11.50.20160411-git, the debug cpython I am trying to debug

----------
components: Demos and Tools
messages: 263690
nosy: tilsche
priority: normal
severity: normal
status: open
title: gdb support fails with "Invalid cast."
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26799>
_______________________________________

From report at bugs.python.org  Mon Apr 18 17:16:35 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Apr 2016 21:16:35 +0000
Subject: [issue26797] Segafault in _PyObject_Alloc
In-Reply-To: <1461004554.65.0.108278995171.issue26797@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwa3cuw8SrkFUEdvTX-NRdzgtftz1Eu3hFbEz3SS38jQ3g@mail.gmail.com>


STINNER Victor added the comment:

Usually a "bug in the memory allocator" means a buffer overflow in your
code. Did you check your code using a debug build, PYTHONDEBUG=debug (if
CPython is compiled in release mode), or PYTHONMALLOC=malloc + valgrind?
(The env var requires CPython 3.6)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26797>
_______________________________________

From report at bugs.python.org  Mon Apr 18 17:26:38 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 18 Apr 2016 21:26:38 +0000
Subject: [issue26797] Segafault in _PyObject_Alloc
In-Reply-To: <1461004554.65.0.108278995171.issue26797@psf.upfronthosting.co.za>
Message-ID: <1461014798.4.0.82979129972.issue26797@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Did you check your code using a debug build, PYTHONDEBUG=debug (if
CPython is compiled in release mode), or PYTHONMALLOC=malloc + valgrind?
(The env var requires CPython 3.6)

Can't reproduce it in the debug build :(

Since I'm not writing C by hand (I use Cython), and libuv is quite stable, I quite doubt that I have a buffer overflow anywhere in my code, but I'll double check.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26797>
_______________________________________

From report at bugs.python.org  Mon Apr 18 17:27:30 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 18 Apr 2016 21:27:30 +0000
Subject: [issue26798] add BLAKE2 to hashlib
In-Reply-To: <1461004812.44.0.872226457841.issue26798@psf.upfronthosting.co.za>
Message-ID: <1461014850.46.0.587174474556.issue26798@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

CPython should not attempt make a judgement about the safety of a particular function.  We can only document if something has known issues.

We should only include things in the stdlib which are either (a) standard or (b) widely used regardless of being standard.  Given that librsync and RAR both support BLAKE2 and that it is defined by an RFC, I'd say it should go in.

The reference implementation appears to have Apache 2.0 licensed C code would can fall back to when the OpenSSL in use does not include it.

PEP-452 seems to address the necessary API changes.

----------
assignee:  -> christian.heimes
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26798>
_______________________________________

From report at bugs.python.org  Mon Apr 18 17:34:55 2016
From: report at bugs.python.org (Philip Jenvey)
Date: Mon, 18 Apr 2016 21:34:55 +0000
Subject: [issue26800] Don't accept bytearray as filenames part 2
Message-ID: <1461015295.39.0.246147143774.issue26800@psf.upfronthosting.co.za>


New submission from Philip Jenvey:

Basically a reopen of the older issue8485 with the same name. It was decided there to drop support for bytearray filenames -- partly because of the complexity of handling buffers but it was also deemed to just not make much sense.

This regressed or crept back into the posix module with the big path_converter changes for 3.3:

https://hg.python.org/cpython/file/ee9921b29fd8/Lib/test/test_posix.py#l411

IMHO this functionality should be deprecated/removed per the original discussion, or does someone want to reopen the debate?

The os module docs (and path_converter's own docs) explicitly advertise handling of str or bytes, not bytearrays or buffers. Even os.fsencode rejects bytearrays/buffers.

Related to issue26754 -- further inconsistencies around filename handling

----------
assignee: larry
components: Interpreter Core
keywords: 3.3regression
messages: 263694
nosy: Ronan.Lamy, haypo, larry, pitrou, pjenvey, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Don't accept bytearray as filenames part 2
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26800>
_______________________________________

From report at bugs.python.org  Mon Apr 18 17:36:11 2016
From: report at bugs.python.org (Philip Jenvey)
Date: Mon, 18 Apr 2016 21:36:11 +0000
Subject: [issue26754] PyUnicode_FSDecoder() accepts arbitrary iterable
In-Reply-To: <1460621170.51.0.766625206789.issue26754@psf.upfronthosting.co.za>
Message-ID: <1461015371.77.0.426554662823.issue26754@psf.upfronthosting.co.za>


Philip Jenvey added the comment:

See issue26800 for reasoning to go with #4

----------
nosy: +pjenvey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26754>
_______________________________________

From report at bugs.python.org  Mon Apr 18 17:51:09 2016
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 18 Apr 2016 21:51:09 +0000
Subject: [issue26798] add BLAKE2 to hashlib
In-Reply-To: <1461004812.44.0.872226457841.issue26798@psf.upfronthosting.co.za>
Message-ID: <1461016269.92.0.0625937101201.issue26798@psf.upfronthosting.co.za>


Christian Heimes added the comment:

BLAKE2 is under CC0 1.0 Universal, https://github.com/BLAKE2/libb2

OpenSSL 1.1.0 has no API to set salt, personal, digest length and key length (for keyed BLAKE2). I have asked Richard Salz and MJC if they'd accept a patch.

Or I could ask Dmitry Chestnykh if he is interested to submit his pyblake2 module to the stdlib. It's under CC0. It looks pretty good except for his macro tricks. I can cope. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26798>
_______________________________________

From report at bugs.python.org  Mon Apr 18 18:13:01 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 18 Apr 2016 22:13:01 +0000
Subject: [issue26739] idle: Errno 10035 a non-blocking socket operation could
 not be completed immediately
In-Reply-To: <1460409859.89.0.789703447955.issue26739@psf.upfronthosting.co.za>
Message-ID: <1461017581.1.0.905746904408.issue26739@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

No, admin privileges should not be needed to run Command Prompt.  Ditto for python if you did not already need same to run IDLE.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26739>
_______________________________________

From report at bugs.python.org  Mon Apr 18 18:29:20 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 18 Apr 2016 22:29:20 +0000
Subject: [issue26730] SpooledTemporaryFile doesn't correctly preserve data for
 text (non-binary) SpooledTemporaryFile objects when Unicode
 characters are written
In-Reply-To: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>
Message-ID: <1461018560.1.0.306698521512.issue26730@psf.upfronthosting.co.za>


Martin Panter added the comment:

I noticed another possible problem with using TextIOWrapper. We call tell() to see if a rollover is needed. But I think TextIOWrapper streams can return complicated values from tell(), encoding stuff like codec state and buffered data in an integer. At the minimum, I think the meaning of max_size has changed (code points vs bytes). And perhaps it won?t work very well with some codecs that record state in the tell() value.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26730>
_______________________________________

From report at bugs.python.org  Mon Apr 18 18:42:57 2016
From: report at bugs.python.org (Frew Schmidt)
Date: Mon, 18 Apr 2016 22:42:57 +0000
Subject: [issue11416] netrc module does not handle multiple entries for a
 single host
In-Reply-To: <1299446047.69.0.767438398088.issue11416@psf.upfronthosting.co.za>
Message-ID: <1461019377.94.0.923172927771.issue11416@psf.upfronthosting.co.za>


Frew Schmidt added the comment:

This issue is causing a problem in OfflineIMAP.  I wrote a patch that I think is a little simpler than the existing one, including tests and docs, though honestly I don't care one way or another.  See attached.  Note that the patch is for Python 2.7 but it mostly applies to 3.5 just fine.  Any chance we could get mine or the other one applied?

Thanks

----------
nosy: +Frew Schmidt
versions: +Python 2.7
Added file: http://bugs.python.org/file42510/netrc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11416>
_______________________________________

From report at bugs.python.org  Mon Apr 18 19:23:49 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 18 Apr 2016 23:23:49 +0000
Subject: [issue18591] threading.Thread.run returning a result
In-Reply-To: <1375130050.37.0.102071487502.issue18591@psf.upfronthosting.co.za>
Message-ID: <1461021829.08.0.493109534917.issue18591@psf.upfronthosting.co.za>


Berker Peksag added the comment:

What is your use case? I think this can easily be implemented by subclassing the threading.Thread class:

    class MyThread(threading.Thread):

        def run(self):
            # skip try...finally to make the example shorter
            result = None
            if self._target:
                result = self._target(*self._args, **self._kwargs)
            return result

We can reopen this if you can share a valid use case. Thanks for the report!

----------
nosy: +berker.peksag
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18591>
_______________________________________

From report at bugs.python.org  Mon Apr 18 19:43:57 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Mon, 18 Apr 2016 23:43:57 +0000
Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError
Message-ID: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za>


New submission from Emanuel Barry:

`shutil.get_terminal_size()` will sometimes propagate `AttributeError: module <os> has not attribute 'get_terminal_size'` to the caller. The call checks for NameError, which makes no sense, so I guess it must be an oversight. Attached patch fixes it.

(diff was generated with git, I don't know if it works with Mercurial, but it's a trivial change anyway)

----------
components: Library (Lib)
files: get_terminal_size.diff
keywords: patch
messages: 263701
nosy: ebarry
priority: normal
severity: normal
stage: patch review
status: open
title: Fix shutil.get_terminal_size() to catch AttributeError
type: behavior
Added file: http://bugs.python.org/file42511/get_terminal_size.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26801>
_______________________________________

From report at bugs.python.org  Mon Apr 18 19:51:21 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 18 Apr 2016 23:51:21 +0000
Subject: [issue17233] http.client header debug output format
In-Reply-To: <1361256774.67.0.162902666936.issue17233@psf.upfronthosting.co.za>
Message-ID: <1461023481.18.0.695260918015.issue17233@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +easy
nosy: +berker.peksag
stage:  -> needs patch
versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17233>
_______________________________________

From report at bugs.python.org  Mon Apr 18 20:01:54 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 19 Apr 2016 00:01:54 +0000
Subject: [issue23251] mention in time.sleep() docs that it does not block
 other Python threads
In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za>
Message-ID: <1461024114.4.0.593130857546.issue23251@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23251>
_______________________________________

From report at bugs.python.org  Mon Apr 18 20:07:35 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 19 Apr 2016 00:07:35 +0000
Subject: [issue13826] Having a shlex example in the subprocess.Popen docs is
 confusing
In-Reply-To: <1326983115.48.0.551767400168.issue13826@psf.upfronthosting.co.za>
Message-ID: <1461024455.31.0.195080633884.issue13826@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch
versions: +Python 3.5, Python 3.6 -Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13826>
_______________________________________

From report at bugs.python.org  Mon Apr 18 21:10:12 2016
From: report at bugs.python.org (Joe Jevnik)
Date: Tue, 19 Apr 2016 01:10:12 +0000
Subject: [issue26802] Avoid copy in call_function_var when no extra stack args
 are passed
Message-ID: <1461028212.35.0.591299573852.issue26802@psf.upfronthosting.co.za>


New submission from Joe Jevnik:

When star unpacking positions into a function we can avoid a copy iff there are no extra arguments coming from the stack. Syntactically this looks like: `f(*args)`

This reduces the overhead of the call by about 25% (~30ns on my machine) based on some light profiling of just * unpacking. I can imagine this having a slight impact on code that uses this feature in a loop.

The cost is minimal when we need to make the copy because the int != 0 check is dwarfed by the allocation. I did not notice a significant change between the slow path and the original code.

The macro benchmark suite did not show a difference on my machine but this is not much more complex code.

----------
components: Interpreter Core
files: call-function-var.patch
keywords: patch
messages: 263702
nosy: llllllllll
priority: normal
severity: normal
status: open
title: Avoid copy in call_function_var when no extra stack args are passed
versions: Python 3.6
Added file: http://bugs.python.org/file42512/call-function-var.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26802>
_______________________________________

From report at bugs.python.org  Mon Apr 18 22:15:06 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 19 Apr 2016 02:15:06 +0000
Subject: [issue26798] add BLAKE2 to hashlib
In-Reply-To: <1461016269.92.0.0625937101201.issue26798@psf.upfronthosting.co.za>
Message-ID: <CAGE7PNJQ95QHy6ZypT5o0_J0Sa-0TtOqPRL2hwxaJsZ37n8+Bw@mail.gmail.com>


Gregory P. Smith added the comment:

Confirm that the CC license is valid/acceptable with Van L. first. That's
why I pointed at the Apache 2 code, already a known good license. :)

On Mon, Apr 18, 2016, 2:51 PM Christian Heimes <report at bugs.python.org>
wrote:

>
> Christian Heimes added the comment:
>
> BLAKE2 is under CC0 1.0 Universal, https://github.com/BLAKE2/libb2
>
> OpenSSL 1.1.0 has no API to set salt, personal, digest length and key
> length (for keyed BLAKE2). I have asked Richard Salz and MJC if they'd
> accept a patch.
>
> Or I could ask Dmitry Chestnykh if he is interested to submit his pyblake2
> module to the stdlib. It's under CC0. It looks pretty good except for his
> macro tricks. I can cope. :)
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue26798>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26798>
_______________________________________

From report at bugs.python.org  Mon Apr 18 22:29:32 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 19 Apr 2016 02:29:32 +0000
Subject: [issue26016] io.TextIOWrapper.tell() report 65bit number when mix
 readline() + tell()
In-Reply-To: <1452006336.5.0.310653434385.issue26016@psf.upfronthosting.co.za>
Message-ID: <1461032972.92.0.217259623487.issue26016@psf.upfronthosting.co.za>


Martin Panter added the comment:

EcmaXp: Do you think there is anything we can do for this? I think the cases discussed here are working as intended.

----------
resolution:  -> not a bug
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26016>
_______________________________________

From report at bugs.python.org  Mon Apr 18 22:44:58 2016
From: report at bugs.python.org (Luiz Poleto)
Date: Tue, 19 Apr 2016 02:44:58 +0000
Subject: [issue17233] http.client header debug output format
In-Reply-To: <1361256774.67.0.162902666936.issue17233@psf.upfronthosting.co.za>
Message-ID: <1461033898.61.0.661080064114.issue17233@psf.upfronthosting.co.za>


Changes by Luiz Poleto <luiz.poleto at gmail.com>:


----------
nosy: +luiz.poleto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17233>
_______________________________________

From report at bugs.python.org  Mon Apr 18 22:53:43 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 19 Apr 2016 02:53:43 +0000
Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError
In-Reply-To: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za>
Message-ID: <1461034423.47.0.159561437247.issue26801@psf.upfronthosting.co.za>


Martin Panter added the comment:

The patch looks good to me. The function was originally written to be included in the ?os? module, hence the NameError. The patch should probably be fine with Mercurial, but it looks like the Reitveld review system doesn?t like it :)

What platform do you get the AttributeError with? Perhaps the function is not well covered in the test suite.

----------
nosy: +martin.panter
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26801>
_______________________________________

From report at bugs.python.org  Mon Apr 18 23:00:57 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Tue, 19 Apr 2016 03:00:57 +0000
Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError
In-Reply-To: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za>
Message-ID: <1461034857.48.0.0658258576179.issue26801@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

I think Rietveld doesn't like me because I made it a .diff file, and not a .patch file, but who knows.

It's a bit of a shot in the dark though, because I can't reproduce an environment where `os.get_terminal_size()` doesn't exist. I'm on Windows and sometimes compile the latest trunk to play around and find bugs, so it could be in one of those times (even though I just tried and it didn't fail).

I think that if `NameError` was to be caught before, it means the function was to be "maybe there, maybe not", which could very well still be the case, so it makes sense to use the proper exception in that case. I don't see any significant drawback to catching AttributeError, anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26801>
_______________________________________

From report at bugs.python.org  Mon Apr 18 23:54:12 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 19 Apr 2016 03:54:12 +0000
Subject: [issue26730] SpooledTemporaryFile doesn't correctly preserve data for
 text (non-binary) SpooledTemporaryFile objects when Unicode
 characters are written
In-Reply-To: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>
Message-ID: <1461038052.98.0.975308894485.issue26730@psf.upfronthosting.co.za>


Martin Panter added the comment:

According to Issue 12215, the TextIOWrapper.tell() position only includes decoder state, not encoder state. So we may be lucky that tell() is proportional to the file size. If so my concern about max_size isn?t so important. But it still feels like a bad hack.

Maybe another quick fix for this would be to do two writes of the StringIO data, and then seek back to the end of the first write:

pos = file.tell()  # StringIO position is in code points
file.seek(0)
newfile.write(file.read(pos))
pos = newfile.tell()  # TextIOWrapper position is opaque
newfile.write(file.read())
newfile.seek(pos, 0)

This still depends on StringIO.tell() corresponding to the number of code points, which is undocumented (we already disable newline translation in the StringIO). See also Issue 25190.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26730>
_______________________________________

From report at bugs.python.org  Tue Apr 19 01:05:44 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Apr 2016 05:05:44 +0000
Subject: [issue26730] SpooledTemporaryFile doesn't correctly preserve data for
 text (non-binary) SpooledTemporaryFile objects when Unicode
 characters are written
In-Reply-To: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>
Message-ID: <1461042344.71.0.577714890919.issue26730@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> This still depends on StringIO.tell() corresponding to the number of code points, which is undocumented (we already disable newline translation in the StringIO). See also Issue 25190.

And doesn't work with Python implementation of StringIO. More general solution needs the code like:

pos = file.tell()
tail = file.read()
file.seek(0)
head = file.read()
if tail:
    head = head[:-len(tail)]
newfile.write(head)
pos = newfile.tell()  # TextIOWrapper position is opaque
newfile.write(tail)
newfile.seek(pos, 0)

Yet one bad thing with using independent StringIO instead of TextIOWrapper, is that saved tell() position becomes not valid after rollover(). I'm going to write few tests for cases when file position points not at the end of the stream.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26730>
_______________________________________

From report at bugs.python.org  Tue Apr 19 01:20:46 2016
From: report at bugs.python.org (Joe Jevnik)
Date: Tue, 19 Apr 2016 05:20:46 +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: <1461043246.53.0.391646879193.issue23926@psf.upfronthosting.co.za>


Joe Jevnik added the comment:

bump

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23926>
_______________________________________

From report at bugs.python.org  Tue Apr 19 01:45:45 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Apr 2016 05:45:45 +0000
Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError
In-Reply-To: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za>
Message-ID: <1461044745.2.0.763604576321.issue26801@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> What platform do you get the AttributeError with? Perhaps the function is not well covered in the test suite.

I guess `os.get_terminal_size()` didn't exist on ancient OSes like DOS, OS/2, ancient UNIXes. On all supported platforms (including such exotic as old AIX, QNX or Minix) it should be defined.

Tests should fail if `os.get_terminal_size()` doesn't exist.

> I think Rietveld doesn't like me because I made it a .diff file, and not a .patch file, but who knows.

I think this is because the patch doesn't contain a revision number.

On Windows `os.get_terminal_size()` can raise ValueError if `sys.__stdout__.fileno()` is not one of 0, 1 or 2. It is worth to catch it too. An AttributeError is also raised if sys.__stdout__ has no the "fileno" attribute (StringIO or None).

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26801>
_______________________________________

From report at bugs.python.org  Tue Apr 19 01:54:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Apr 2016 05:54:10 +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: <1461045250.55.0.915689656957.issue23926@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23926>
_______________________________________

From report at bugs.python.org  Tue Apr 19 02:19:49 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 19 Apr 2016 06:19:49 +0000
Subject: [issue26802] Avoid copy in call_function_var when no extra stack args
 are passed
In-Reply-To: <1461028212.35.0.591299573852.issue26802@psf.upfronthosting.co.za>
Message-ID: <1461046789.28.0.854035874484.issue26802@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +haypo, martin.panter, yselivanov
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26802>
_______________________________________

From report at bugs.python.org  Tue Apr 19 02:20:12 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 19 Apr 2016 06:20:12 +0000
Subject: [issue26785] repr of -nan value should contain the sign
In-Reply-To: <1460832293.23.0.989531230725.issue26785@psf.upfronthosting.co.za>
Message-ID: <1461046812.58.0.216068172964.issue26785@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

The sign of a NaN *is* fully supported, and easily accessible to those who need it. It just isn't part of the repr. Given that the sign is meaningless in the vast majority of applications, I think Python does the right thing here by leaving it out of the repr, rather than cluttering up the repr with meaningless and potentially confusing information.

I'll leave the last word to Stephen Canon, from the SO answer I linked to above:

" it is almost always a bug to attach meaning to the "sign bit" of a NaN datum."

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26785>
_______________________________________

From report at bugs.python.org  Tue Apr 19 02:25:39 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 19 Apr 2016 06:25:39 +0000
Subject: [issue26799] gdb support fails with "Invalid cast."
In-Reply-To: <1461013840.26.0.744881925452.issue26799@psf.upfronthosting.co.za>
Message-ID: <1461047139.29.0.862564199422.issue26799@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26799>
_______________________________________

From report at bugs.python.org  Tue Apr 19 02:42:21 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Apr 2016 06:42:21 +0000
Subject: [issue26802] Avoid copy in call_function_var when no extra stack args
 are passed
In-Reply-To: <1461028212.35.0.591299573852.issue26802@psf.upfronthosting.co.za>
Message-ID: <1461048141.33.0.0918318438955.issue26802@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

stararg can be not exact tuple, but an instance of tuple subclass.

Could you provide a microbenchmark that shows the effect of the optimization?

----------
nosy: +serhiy.storchaka
type: behavior -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26802>
_______________________________________

From report at bugs.python.org  Tue Apr 19 02:54:49 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Apr 2016 06:54:49 +0000
Subject: [issue24838] tarfile.py: fix GNU and USTAR formats to properly handle
 paths with special characters that are encoded with more than one
 byte each
In-Reply-To: <1439229863.39.0.118048991617.issue24838@psf.upfronthosting.co.za>
Message-ID: <20160419065445.88648.40371.31556B90@psf.io>


Roundup Robot added the comment:

New changeset d08d6b776694 by Lars Gust?bel in branch '3.5':
Issue #24838: tarfile's ustar and gnu formats now correctly calculate name and
https://hg.python.org/cpython/rev/d08d6b776694

New changeset e281a57d5b29 by Lars Gust?bel in branch 'default':
Issue #24838: Merge tarfile fix from 3.5.
https://hg.python.org/cpython/rev/e281a57d5b29

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24838>
_______________________________________

From report at bugs.python.org  Tue Apr 19 02:56:12 2016
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Tue, 19 Apr 2016 06:56:12 +0000
Subject: [issue24838] tarfile.py: fix GNU and USTAR formats to properly handle
 paths with special characters that are encoded with more than one
 byte each
In-Reply-To: <1439229863.39.0.118048991617.issue24838@psf.upfronthosting.co.za>
Message-ID: <1461048972.96.0.947290159187.issue24838@psf.upfronthosting.co.za>


Changes by Lars Gust?bel <lars at gustaebel.de>:


----------
resolution:  -> fixed
stage: test needed -> resolved
status: open -> closed
versions:  -Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24838>
_______________________________________

From report at bugs.python.org  Tue Apr 19 03:18:38 2016
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Tue, 19 Apr 2016 07:18:38 +0000
Subject: [issue10261] tarfile iterator without members caching
In-Reply-To: <1288523998.25.0.554801648749.issue10261@psf.upfronthosting.co.za>
Message-ID: <1461050318.38.0.461694785418.issue10261@psf.upfronthosting.co.za>


Lars Gust?bel added the comment:

Closing after six years of inactivity.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10261>
_______________________________________

From report at bugs.python.org  Tue Apr 19 03:35:16 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 19 Apr 2016 07:35:16 +0000
Subject: [issue26803] syslog logging handler fails with address in unix
 abstract namespace
Message-ID: <1461051316.11.0.100147214694.issue26803@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

The traceback:

    Traceback (most recent call last):
      File "Lib/logging/handlers.py", line 917, in emit
        self.socket.sendto(msg, self.address)
    TypeError: getsockaddrarg: AF_INET address must be tuple, not bytes

The attached patch reproduces the issue with a test case and fixes it.

----------
components: Library (Lib)
files: unix_abstract_namespace.patch
keywords: patch
messages: 263715
nosy: vinay.sajip, xdegaye
priority: normal
severity: normal
status: open
title: syslog logging handler fails with address in unix abstract namespace
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file42513/unix_abstract_namespace.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26803>
_______________________________________

From report at bugs.python.org  Tue Apr 19 03:54:18 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 19 Apr 2016 07:54:18 +0000
Subject: [issue21668] The select and time modules uses libm functions without
 linking against it
In-Reply-To: <1401972993.52.0.304727515537.issue21668@psf.upfronthosting.co.za>
Message-ID: <1461052458.41.0.042425033754.issue21668@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The _datetime module also calls functions in libm: delta_new() uses
round() and accum() uses modf().

The attached patch updates setup.py for all the modules that use libm.

----------
nosy: +xdegaye
Added file: http://bugs.python.org/file42514/ext_modules_libm.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21668>
_______________________________________

From report at bugs.python.org  Tue Apr 19 04:00:58 2016
From: report at bugs.python.org (Joe Jevnik)
Date: Tue, 19 Apr 2016 08:00:58 +0000
Subject: [issue26802] Avoid copy in call_function_var when no extra stack args
 are passed
In-Reply-To: <1461028212.35.0.591299573852.issue26802@psf.upfronthosting.co.za>
Message-ID: <1461052858.18.0.698633254256.issue26802@psf.upfronthosting.co.za>


Joe Jevnik added the comment:

in _PyEval_EvalCodeWithName we will have already pulled the underlying array out of the tuple subclass and the then we will reconstruct the vararg value in the locals from this array. This means that with this patch we can get:

>>> class C(tuple): pass
... 
>>> def f(*args): print(type(args))
... 
>>> f(*C([1, 2, 3]))
<class 'tuple'>

The only case where we get potentially strange behavior is if we have a type whose tp_call did not forward to PyArg_Parse* or the PyTupleObject api and went though the abstract object interface. I ran the tests and the benchmark suite and did not run into any issues here but I can see how this would be potentially problematic behavior.

I have updated the code to also do a PyTuple_CheckExact against `stararg`. The tests I ran are:

timeit("h(*(a, b, c, d, e, f, g))", 'def h(a, b, c, d, e, f, g): pass\na, b, c, d, e, f, g = range(7)', number=int(10e7))

default: 17.191688070015516
patch: 14.060781285981648

There is also a really great case where you star unpack a tuple of literals which gets pushed into the co_consts:

timeit("f(*('a', 'b', 'c', 'd', 'e', 'f', 'g'))", 'def f(a, b, c, d, e, f, g): pass', number=int(10e7))

default: 13.842308042978402
patch: 9.696972723002546

This case seems far less common, but maybe someone has something like:

a = 1, 2, 3
...
f(*a)

----------
type: performance -> 
Added file: http://bugs.python.org/file42515/call-function-var.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26802>
_______________________________________

From report at bugs.python.org  Tue Apr 19 04:02:33 2016
From: report at bugs.python.org (Joe Jevnik)
Date: Tue, 19 Apr 2016 08:02:33 +0000
Subject: [issue26802] Avoid copy in call_function_var when no extra stack args
 are passed
In-Reply-To: <1461028212.35.0.591299573852.issue26802@psf.upfronthosting.co.za>
Message-ID: <1461052953.88.0.271272156261.issue26802@psf.upfronthosting.co.za>


Changes by Joe Jevnik <joe at quantopian.com>:


----------
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26802>
_______________________________________

From report at bugs.python.org  Tue Apr 19 04:03:57 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Tue, 19 Apr 2016 08:03:57 +0000
Subject: [issue21668] The select and time modules uses libm functions without
 linking against it
In-Reply-To: <1401972993.52.0.304727515537.issue21668@psf.upfronthosting.co.za>
Message-ID: <1461053037.64.0.596174351955.issue21668@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

The approach with a helper function is better. See https://github.com/yan12125/python3-android/blob/038271d/mk/python/modules-link-libm.patch.

By the way, I have verified there are no libraries referencing libm functions with https://github.com/yan12125/python3-android/blob/cpython-hg/devscripts/import_all.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21668>
_______________________________________

From report at bugs.python.org  Tue Apr 19 04:04:49 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 08:04:49 +0000
Subject: [issue24838] tarfile.py: fix GNU and USTAR formats to properly handle
 paths with special characters that are encoded with more than one
 byte each
In-Reply-To: <1439229863.39.0.118048991617.issue24838@psf.upfronthosting.co.za>
Message-ID: <1461053089.08.0.864753958638.issue24838@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Tests fail on FreeBSD:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%203.5/builds/713/steps/test/logs/stdio

Example:



======================================================================
FAIL: test_unicode_link1 (test.test_tarfile.UstarUnicodeTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.5.koobs-freebsd9/build/Lib/test/test_tarfile.py", line 1807, in test_unicode_link1
    self._test_ustar_link("0123456789" * 9 + "01234567\xff")
  File "/usr/home/buildbot/python/3.5.koobs-freebsd9/build/Lib/test/test_tarfile.py", line 1826, in _test_ustar_link
    self.assertEqual(name, t.linkname)
AssertionError: '0123[44 chars]89012345678901234567890123456789012345678901234567\xff' != '0123[44 chars]89012345678901234567890123456789012345678901234567\udcc3\udcbf'
- 01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567\xff
?                                                                                                   ^
+ 01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567\udcc3\udcbf
?                                                                                                   ^^

----------
nosy: +haypo
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24838>
_______________________________________

From report at bugs.python.org  Tue Apr 19 04:18:29 2016
From: report at bugs.python.org (Hans-Peter Jansen)
Date: Tue, 19 Apr 2016 08:18:29 +0000
Subject: [issue26804] Prioritize lowercase proxy variables in urllib.request
Message-ID: <1461053909.86.0.0123928931795.issue26804@psf.upfronthosting.co.za>


New submission from Hans-Peter Jansen:

During programming a function, that replaces a wget call, I noticed, that something is wrong with urllibs proxy handling. 

I usually use the scheme "http_proxy= wget -N -nd URL" when I need to bypass the proxy. Hence I was pretty confused, that this doesn't work with python(3). Creating an empty ProxyHandler isn't the real Mc Coy either. Diving into the issue, I found getproxies_environment, but couldn't make much sense out of its behavior, up until I noticed, that
my OS (openSUSE ) creates both variants of environment variables behind the scenes: uppercase and lowercase. 

Consequence: python3 needs the scheme "http_proxy= HTTP_PROXY= python3 ..."

Since I, like everyone else, prefer gentle tones over the loud, and want to spare this surprise for others in the future, I propose the attached patch.

Process environment variables in two passes, first uppercase, then lowercase, allowing an empty lowercase value to overrule any uppercase value.

Please consider applying this.

----------
components: Extension Modules
files: prioritize_lowercase_proxy_vars_in_urllib_request.diff
keywords: patch
messages: 263720
nosy: frispete
priority: normal
severity: normal
status: open
title: Prioritize lowercase proxy variables in urllib.request
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file42516/prioritize_lowercase_proxy_vars_in_urllib_request.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26804>
_______________________________________

From report at bugs.python.org  Tue Apr 19 04:24:09 2016
From: report at bugs.python.org (Hans-Peter Jansen)
Date: Tue, 19 Apr 2016 08:24:09 +0000
Subject: [issue26804] Prioritize lowercase proxy variables in urllib.request
In-Reply-To: <1461053909.86.0.0123928931795.issue26804@psf.upfronthosting.co.za>
Message-ID: <1461054249.28.0.0839857159946.issue26804@psf.upfronthosting.co.za>


Changes by Hans-Peter Jansen <hpj at urpla.net>:


----------
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26804>
_______________________________________

From report at bugs.python.org  Tue Apr 19 04:28:29 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 19 Apr 2016 08:28:29 +0000
Subject: [issue22359] Remove incorrect uses of recursive make
In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za>
Message-ID: <1461054509.58.0.74154607396.issue22359@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Here is a patch that does not use GNU make conditionals.
Patch tested by running the test suite both natively and after a
cross-compilation.

----------
Added file: http://bugs.python.org/file42517/cross-chgeset-c2a53aa27cad_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22359>
_______________________________________

From report at bugs.python.org  Tue Apr 19 04:37:46 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 19 Apr 2016 08:37:46 +0000
Subject: [issue26804] Prioritize lowercase proxy variables in urllib.request
In-Reply-To: <1461053909.86.0.0123928931795.issue26804@psf.upfronthosting.co.za>
Message-ID: <1461055066.69.0.413189783367.issue26804@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Library (Lib) -Extension Modules
nosy: +orsenthil
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26804>
_______________________________________

From report at bugs.python.org  Tue Apr 19 06:01:21 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Apr 2016 10:01:21 +0000
Subject: [issue24838] tarfile.py: fix GNU and USTAR formats to properly handle
 paths with special characters that are encoded with more than one
 byte each
In-Reply-To: <1439229863.39.0.118048991617.issue24838@psf.upfronthosting.co.za>
Message-ID: <1461060081.7.0.489840864021.issue24838@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/issue24838>
_______________________________________

From report at bugs.python.org  Tue Apr 19 06:01:33 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Apr 2016 10:01:33 +0000
Subject: [issue24838] tarfile.py: fix GNU and USTAR formats to properly handle
 paths with special characters that are encoded with more than one
 byte each
In-Reply-To: <1439229863.39.0.118048991617.issue24838@psf.upfronthosting.co.za>
Message-ID: <20160419100121.119498.27939.69766BA0@psf.io>


Roundup Robot added the comment:

New changeset 78ede2baa146 by Lars Gust?bel in branch '3.5':
Issue #24838: Fix test_tarfile.py for non-utf8 filesystem encodings.
https://hg.python.org/cpython/rev/78ede2baa146

New changeset 08835d1e7a50 by Lars Gust?bel in branch 'default':
Issue #24838: Merge test_tarfile.py fix from 3.5.
https://hg.python.org/cpython/rev/08835d1e7a50

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24838>
_______________________________________

From report at bugs.python.org  Tue Apr 19 06:02:47 2016
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Tue, 19 Apr 2016 10:02:47 +0000
Subject: [issue24838] tarfile.py: fix GNU and USTAR formats to properly handle
 paths with special characters that are encoded with more than one
 byte each
In-Reply-To: <1439229863.39.0.118048991617.issue24838@psf.upfronthosting.co.za>
Message-ID: <1461060167.5.0.140984501835.issue24838@psf.upfronthosting.co.za>


Lars Gust?bel added the comment:

Sorry for the glitch, I suppose everything works fine now.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24838>
_______________________________________

From report at bugs.python.org  Tue Apr 19 06:07:04 2016
From: report at bugs.python.org (Andy Maier)
Date: Tue, 19 Apr 2016 10:07:04 +0000
Subject: [issue1322] Deprecate platform.dist() and
 platform.linux_distribution() functions
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1461060424.56.0.826646931211.issue1322@psf.upfronthosting.co.za>


Andy Maier added the comment:

Nir currently proposes to change the package name from "ld" to "dist". See https://github.com/nir0s/ld/issues/103
Comments on this name change proposal are welcome (over there).

On "Given the unremarkable simplicity of implementing this function correctly ...":

It seems to me that this is over-simplifying the task somewhat. Nir's "ld" package needs to understand all of the (currently) three different formats on Linux, and goes for a precedence-based approach to consolidate the information. Also, determining supposedly simple things like a reliable distro ID, or a precise distro version is not trivial, given that some Linux distros provide their data quite inconsistently between the different data sources and sometimes change things like distro ID incompatibly in a new minor release.

Overall, I can only encourage people to try out the "ld" package (v0.5.0 is currently on PyPI) and give feedback (on its GitHub project).

Does the deprecation and removal of these functions discriminate Linux compared to Windows and OS-X? Maybe, but I'm pragmatic here, and for me the important criteria is the one that was stated from the beginning in this discussion: The higher change rate in Linux fits quite well with the approach of having a separate package that is not part of the standard Python.

Does that mean that less batteries are now included in Python out of the box: Yes, a very small part of the batteries is now no longer included. But maybe one day when the "ld" package is perfect and does not require a high change rate anymore, it gets added to standard Python.

Also, there are many packages the average Python project needs these days that are no longer coming with standard Python (six, setuptools, pbr, better unit testers, lxml, M2Crypto, Sphinx, lxml, ........). If you look at the long backlog of pull requests and open issues in standard Python, it is a good thing actually, not to overload the community maintaining the standard Python even further. But that is a bit off-topic for this issue, I am just mentioning it in order to beg for acceptance for the approach taken for linux distro information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Tue Apr 19 06:15:02 2016
From: report at bugs.python.org (Andy Maier)
Date: Tue, 19 Apr 2016 10:15:02 +0000
Subject: [issue1322] Deprecate platform.dist() and
 platform.linux_distribution() functions
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1461060902.63.0.956186938617.issue1322@psf.upfronthosting.co.za>


Andy Maier added the comment:

@leycec: By the way, the "ld" package *does* use shlex.shlex() to parse the os-release file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Tue Apr 19 06:24:07 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 10:24:07 +0000
Subject: [issue26058] PEP 509: Add ma_version to PyDictObject
In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za>
Message-ID: <1461061447.2.0.107235245717.issue26058@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Patch version 8:

* Update to the latest PEP: remove micro-optimization in dictobject.c if the new value is identical to the current value, dict.__setitem__() now always changes the version
* Refactor test_pep509 to address Brett's comments
* Add new unit tests on identical values
* Add new unit tests on equal values (with special __eq__ method)

----------
Added file: http://bugs.python.org/file42518/dict_version-8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26058>
_______________________________________

From report at bugs.python.org  Tue Apr 19 06:38:56 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 10:38:56 +0000
Subject: [issue26058] PEP 509: Add ma_version to PyDictObject
In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za>
Message-ID: <1461062336.26.0.364679429804.issue26058@psf.upfronthosting.co.za>


STINNER Victor added the comment:

timeit microbenchmarks on dict_version-8.patch, minimum of 10 runs.

$ ./python.orig -m timeit 'd={1: 0}; d[2]=0; d[3]=0; d[4]=0; del d[1]; del d[2]; d.clear()'
1000000 loops, best of 3: 0.292 usec per loop
$ ./python.version -m timeit 'd={1: 0}; d[2]=0; d[3]=0; d[4]=0; del d[1]; del d[2]; d.clear()'
1000000 loops, best of 3: 0.293 usec per loop

=> 1 nanosecond (0.3%) slower

$ ./python.orig -m timeit 'd={i:i for i in range(2**16)}' 'for i in range(2**16): d[i]=i-1' 'for i in range(2**16): d[i]=i+1' 'for i in range(2**15): del d[i]' 'd.clear()'
10 loops, best of 3: 21.2 msec per loop
$ ./python.version -m timeit 'd={i:i for i in range(2**16)}' 'for i in range(2**16): d[i]=i-1' 'for i in range(2**16): d[i]=i+1' 'for i in range(2**15): del d[i]' 'd.clear()'
10 loops, best of 3: 21.3 msec per loop

=> 0.1 ms (0.5%) slower

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26058>
_______________________________________

From report at bugs.python.org  Tue Apr 19 06:47:41 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 10:47:41 +0000
Subject: [issue26058] PEP 509: Add ma_version to PyDictObject
In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za>
Message-ID: <1461062861.14.0.853132768728.issue26058@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I ran again timeit microbenchmarks with CPU isolation on dict_version-8.patch, minimum of 10 runs.

-m timeit 'd={1: 0}; d[2]=0; d[3]=0; d[4]=0; del d[1]; del d[2]; d.clear()'

* Original: 287 ns
* Version: 289 ns (+2 ns, +0.7%)

-m timeit 'd={i:i for i in range(2**16)}' 'for i in range(2**16): d[i]=i-1' 'for i in range(2**16): d[i]=i+1' 'for i in range(2**15): del d[i]' 'd.clear()'

* Original: 21.2 msec
* Version: 21.4 msec (+0.2 ms, +0.9%)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26058>
_______________________________________

From report at bugs.python.org  Tue Apr 19 06:52:21 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 10:52:21 +0000
Subject: [issue26058] PEP 509: Add ma_version to PyDictObject
In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za>
Message-ID: <1461063141.34.0.82021694339.issue26058@psf.upfronthosting.co.za>


STINNER Victor added the comment:

pybench results on dict_version-8.patch with CPU isolation: http://haypo-notes.readthedocs.org/microbenchmark.html

As usual, I'm very skeptical on the pybench results which almost look like noise. I don't understand how my change can make any operation *faster*, whereas some benchmarks are faster with the patch...

Dict microbenchmarks:

           DictCreation:    38ms    36ms   +4.8%    39ms    37ms   +3.9%
      DictWithFloatKeys:    40ms    40ms   -0.8%    40ms    40ms   -0.4%
    DictWithIntegerKeys:    33ms    31ms   +7.2%    33ms    31ms   +7.6%
     DictWithStringKeys:    29ms    28ms   +0.4%    29ms    29ms   +0.7%
 SimpleDictManipulation:    59ms    59ms   -0.4%    59ms    59ms   -0.4%

Full output:

$ ./python.version Tools/pybench/pybench.py -f pybench.version
$ ./python.orig Tools/pybench/pybench.py -f pybench.orig
$ ./python.orig Tools/pybench/pybench.py -s pybench.version -c pybench.orig 

-------------------------------------------------------------------------------
PYBENCH 2.1
-------------------------------------------------------------------------------
* using CPython 3.6.0a0 (default:e281a57d5b29, Apr 19 2016, 12:30:36) [GCC 5.3.1 20151207 (Red Hat 5.3.1-2)]
* disabled garbage collection
* system check interval set to maximum: 2147483647
* using timer: time.perf_counter
* timer: resolution=1e-09, implementation=clock_gettime(CLOCK_MONOTONIC)

-------------------------------------------------------------------------------
Benchmark: pybench.version
-------------------------------------------------------------------------------

    Rounds: 10
    Warp:   10
    Timer:  time.perf_counter

    Machine Details:
       Platform ID:    Linux-4.4.4-301.fc23.x86_64-x86_64-with-fedora-23-Twenty_Three
       Processor:      x86_64
    
    Python:
       Implementation: CPython
       Executable:     /home/haypo/prog/python/default/python.version
       Version:        3.6.0a0
       Compiler:       GCC 5.3.1 20151207 (Red Hat 5.3.1-2)
       Bits:           64bit
       Build:          Apr 19 2016 12:29:16 (#default:e281a57d5b29+)
       Unicode:        UCS4


-------------------------------------------------------------------------------
Comparing with: pybench.orig
-------------------------------------------------------------------------------

    Rounds: 10
    Warp:   10
    Timer:  time.perf_counter

    Machine Details:
       Platform ID:    Linux-4.4.4-301.fc23.x86_64-x86_64-with-fedora-23-Twenty_Three
       Processor:      x86_64
    
    Python:
       Implementation: CPython
       Executable:     /home/haypo/prog/python/default/python.orig
       Version:        3.6.0a0
       Compiler:       GCC 5.3.1 20151207 (Red Hat 5.3.1-2)
       Bits:           64bit
       Build:          Apr 19 2016 12:30:36 (#default:e281a57d5b29)
       Unicode:        UCS4


Test                             minimum run-time        average  run-time
                                 this    other   diff    this    other   diff
-------------------------------------------------------------------------------
          BuiltinFunctionCalls:    49ms    50ms   -1.3%    49ms    50ms   -1.2%
           BuiltinMethodLookup:    26ms    26ms   -0.8%    26ms    27ms   -1.2%
                 CompareFloats:    29ms    30ms   -2.0%    29ms    30ms   -1.9%
         CompareFloatsIntegers:    39ms    39ms   +1.4%    39ms    39ms   +1.5%
               CompareIntegers:    43ms    43ms   -1.1%    43ms    43ms   -1.1%
        CompareInternedStrings:    28ms    28ms   -0.2%    28ms    28ms   -0.3%
                  CompareLongs:    25ms    25ms   +2.8%    25ms    25ms   +2.9%
                CompareStrings:    26ms    27ms   -0.8%    26ms    27ms   -1.6%
    ComplexPythonFunctionCalls:    44ms    44ms   -1.6%    44ms    45ms   -1.6%
                 ConcatStrings:    35ms    33ms   +6.4%    35ms    33ms   +6.1%
               CreateInstances:    49ms    48ms   +2.6%    50ms    49ms   +1.8%
            CreateNewInstances:    37ms    36ms   +2.5%    37ms    36ms   +2.2%
       CreateStringsWithConcat:    65ms    63ms   +3.3%    66ms    64ms   +2.9%
                  DictCreation:    38ms    36ms   +4.8%    39ms    37ms   +3.9%
             DictWithFloatKeys:    40ms    40ms   -0.8%    40ms    40ms   -0.4%
           DictWithIntegerKeys:    33ms    31ms   +7.2%    33ms    31ms   +7.6%
            DictWithStringKeys:    29ms    28ms   +0.4%    29ms    29ms   +0.7%
                      ForLoops:    25ms    25ms   -0.4%    26ms    26ms   -0.3%
                    IfThenElse:    37ms    35ms   +3.3%    37ms    36ms   +3.0%
                   ListSlicing:    39ms    38ms   +0.3%    39ms    39ms   +0.0%
                NestedForLoops:    40ms    40ms   +0.1%    40ms    40ms   -0.0%
      NestedListComprehensions:    41ms    42ms   -0.2%    42ms    42ms   -0.9%
          NormalClassAttribute:    82ms    78ms   +4.0%    82ms    79ms   +3.8%
       NormalInstanceAttribute:    43ms    42ms   +1.9%    44ms    43ms   +1.8%
           PythonFunctionCalls:    40ms    42ms   -5.0%    41ms    43ms   -4.8%
             PythonMethodCalls:    51ms    52ms   -1.1%    51ms    52ms   -0.8%
                     Recursion:    69ms    72ms   -4.8%    69ms    73ms   -4.7%
                  SecondImport:    37ms    38ms   -0.1%    37ms    38ms   -0.1%
           SecondPackageImport:    40ms    39ms   +1.9%    40ms    39ms   +1.6%
         SecondSubmoduleImport:    96ms    97ms   -1.0%    96ms    97ms   -1.1%
       SimpleComplexArithmetic:    28ms    27ms   +1.7%    29ms    28ms   +1.9%
        SimpleDictManipulation:    59ms    59ms   -0.4%    59ms    59ms   -0.4%
         SimpleFloatArithmetic:    27ms    27ms   +2.2%    27ms    27ms   +2.3%
      SimpleIntFloatArithmetic:    31ms    31ms   +1.6%    31ms    31ms   +1.7%
       SimpleIntegerArithmetic:    31ms    31ms   +0.8%    31ms    31ms   +0.5%
      SimpleListComprehensions:    33ms    33ms   +0.2%    33ms    33ms   +0.4%
        SimpleListManipulation:    31ms    31ms   -0.0%    32ms    32ms   -1.5%
          SimpleLongArithmetic:    21ms    22ms   -2.5%    22ms    22ms   -1.8%
                    SmallLists:    43ms    44ms   -3.3%    43ms    44ms   -3.5%
                   SmallTuples:    51ms    53ms   -2.9%    52ms    54ms   -3.6%
         SpecialClassAttribute:    80ms    81ms   -1.0%    80ms    81ms   -1.1%
      SpecialInstanceAttribute:    42ms    42ms   -0.5%    42ms    42ms   -0.7%
                StringMappings:    87ms    86ms   +0.8%    87ms    86ms   +0.9%
              StringPredicates:    53ms    53ms   +0.3%    53ms    53ms   +0.2%
                 StringSlicing:    48ms    49ms   -1.3%    48ms    49ms   -0.8%
                     TryExcept:    25ms    25ms   +0.6%    25ms    25ms   +0.7%
                    TryFinally:    35ms    35ms   +1.1%    36ms    35ms   +0.7%
                TryRaiseExcept:    13ms    13ms   -0.5%    13ms    13ms   -0.6%
                  TupleSlicing:    46ms    46ms   +0.2%    48ms    50ms   -3.2%
                   WithFinally:    54ms    53ms   +0.8%    54ms    54ms   +0.7%
               WithRaiseExcept:    44ms    43ms   +2.8%    44ms    43ms   +2.7%
-------------------------------------------------------------------------------
Totals:                          2156ms  2150ms   +0.3%  2171ms  2169ms   +0.1%

(this=pybench.version, other=pybench.orig)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26058>
_______________________________________

From report at bugs.python.org  Tue Apr 19 06:55:31 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 19 Apr 2016 10:55:31 +0000
Subject: [issue24838] tarfile.py: fix GNU and USTAR formats to properly handle
 paths with special characters that are encoded with more than one
 byte each
In-Reply-To: <1439229863.39.0.118048991617.issue24838@psf.upfronthosting.co.za>
Message-ID: <1461063331.52.0.392237049311.issue24838@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24838>
_______________________________________

From report at bugs.python.org  Tue Apr 19 07:01:23 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 19 Apr 2016 11:01:23 +0000
Subject: [issue26058] PEP 509: Add ma_version to PyDictObject
In-Reply-To: <1461063141.34.0.82021694339.issue26058@psf.upfronthosting.co.za>
Message-ID: <57160FF3.8090203@egenix.com>


Marc-Andre Lemburg added the comment:

On 19.04.2016 12:52, STINNER Victor wrote:
> 
> As usual, I'm very skeptical on the pybench results which almost look like noise. I don't understand how my change can make any operation *faster*, whereas some benchmarks are faster with the patch...

This can easily happen as a result of different memory layout, but is
very much dependent on the machine architecture, CPU, memory type, etc.

> Dict microbenchmarks:
> 
>            DictCreation:    38ms    36ms   +4.8%    39ms    37ms   +3.9%
>       DictWithFloatKeys:    40ms    40ms   -0.8%    40ms    40ms   -0.4%
>     DictWithIntegerKeys:    33ms    31ms   +7.2%    33ms    31ms   +7.6%
>      DictWithStringKeys:    29ms    28ms   +0.4%    29ms    29ms   +0.7%
>  SimpleDictManipulation:    59ms    59ms   -0.4%    59ms    59ms   -0.4%

Only dict creation and the integer keys benchmark results are relevant.

Could you perhaps check what's causing these slowdowns ?

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26058>
_______________________________________

From report at bugs.python.org  Tue Apr 19 07:11:55 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 11:11:55 +0000
Subject: [issue26058] PEP 509: Add ma_version to PyDictObject
In-Reply-To: <57160FF3.8090203@egenix.com>
Message-ID: <CAMpsgwb7MMr=P0+fUCt9yhKF4SgGLjZXJhW_O-Sa19KZ4nsmCg@mail.gmail.com>


STINNER Victor added the comment:

> Could you perhaps check what's causing these slowdowns ?

It's obvious, no? My patch causes the slowdown.

On a timeit microbenchmark, I don't see such slowdown. That's also why
I suspect that pybench is unstable.

python3.6 -m timeit '{}' says 105 ns with and without the patch.

python3.6 -m timeit 'd={}; d[1]=1; d[2]=2; d[3]=3; d[4]=4; d[5]=5;
d[6]=6; d[7]=7; d[8]=8; d[9]=9; d[10]=10' says 838 ns with and without
the patch.

I have to "cheat": I run timeit enough times until I see the "minimum".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26058>
_______________________________________

From report at bugs.python.org  Tue Apr 19 07:25:31 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 19 Apr 2016 11:25:31 +0000
Subject: [issue26058] PEP 509: Add ma_version to PyDictObject
In-Reply-To: <CAMpsgwb7MMr=P0+fUCt9yhKF4SgGLjZXJhW_O-Sa19KZ4nsmCg@mail.gmail.com>
Message-ID: <5716159C.2010100@egenix.com>


Marc-Andre Lemburg added the comment:

On 19.04.2016 13:11, STINNER Victor wrote:
> 
> STINNER Victor added the comment:
> 
>> Could you perhaps check what's causing these slowdowns ?
> 
> It's obvious, no? My patch causes the slowdown.

Well, yes, of course :-) I meant whether there's anything you
can do about those slowdowns.

> On a timeit microbenchmark, I don't see such slowdown. That's also why
> I suspect that pybench is unstable.
> 
> python3.6 -m timeit '{}' says 105 ns with and without the patch.
> 
> python3.6 -m timeit 'd={}; d[1]=1; d[2]=2; d[3]=3; d[4]=4; d[5]=5;
> d[6]=6; d[7]=7; d[8]=8; d[9]=9; d[10]=10' says 838 ns with and without
> the patch.
> 
> I have to "cheat": I run timeit enough times until I see the "minimum".

Those operations are too fast for timeit. The overhead associated
with looping is much larger than the time it takes to run the
operation itself. That's why in pybench I put the operations into
blocks of repeated statements. The interpreter then doesn't spend
time on branching when going from one statement execution to the
next (inside those blocks) and you get closer to the real runtime
of the operation you're trying to measure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26058>
_______________________________________

From report at bugs.python.org  Tue Apr 19 08:25:44 2016
From: report at bugs.python.org (Paul Moore)
Date: Tue, 19 Apr 2016 12:25:44 +0000
Subject: [issue26805] Refer to types.SimpleNamespace in namedtuple
 documentation
Message-ID: <1461068744.46.0.957777609901.issue26805@psf.upfronthosting.co.za>


New submission from Paul Moore:

People often look towards collections.namedtuple when all they actually want is "named attribute" access to a collection of values, without needing a tuple subclass, or positional access. In these cases, types.SimpleNamespace may be a better fit.

I suggest adding the following pointer to the top of the namedtuple documentation:

"""
For simple uses, where the only requirement is to be able to refer to a set of values by name using attribute-style access, the :ref:`types.SimpleNamespace` type may be a suitable alternative to using a namedtuple.
"""

----------
assignee: docs at python
components: Documentation
messages: 263733
nosy: docs at python, paul.moore
priority: normal
severity: normal
status: open
title: Refer to types.SimpleNamespace in namedtuple documentation
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26805>
_______________________________________

From report at bugs.python.org  Tue Apr 19 08:29:00 2016
From: report at bugs.python.org (Chris Angelico)
Date: Tue, 19 Apr 2016 12:29:00 +0000
Subject: [issue26805] Refer to types.SimpleNamespace in namedtuple
 documentation
In-Reply-To: <1461068744.46.0.957777609901.issue26805@psf.upfronthosting.co.za>
Message-ID: <1461068940.38.0.670291197057.issue26805@psf.upfronthosting.co.za>


Changes by Chris Angelico <rosuav at gmail.com>:


----------
nosy: +Rosuav

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26805>
_______________________________________

From report at bugs.python.org  Tue Apr 19 08:33:19 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 12:33:19 +0000
Subject: [issue26769] Python 2.7: make private file descriptors non inheritable
In-Reply-To: <1460725141.7.0.638632202912.issue26769@psf.upfronthosting.co.za>
Message-ID: <1461069199.01.0.734696331182.issue26769@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> It looks like some of these do make the file descriptor accessible to the Python user. (...)

Oh right, I reverted changes on these modules.

What do you think of the patch version 2?

Changes since patch version 1:

* Revert changes in linuxaudio, oss, select, etc. modules
* Fix _Py_try_set_non_inheritable(): *set* the FD_CLOEXEC flag, don't clear it!
* Optimize _Py_try_set_non_inheritable(): avoid fcntl() if possible (backport issue #26770)

----------
Added file: http://bugs.python.org/file42519/set_inheritable-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26769>
_______________________________________

From report at bugs.python.org  Tue Apr 19 08:36:38 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 19 Apr 2016 12:36:38 +0000
Subject: [issue26805] Refer to types.SimpleNamespace in namedtuple
 documentation
In-Reply-To: <1461068744.46.0.957777609901.issue26805@psf.upfronthosting.co.za>
Message-ID: <1461069398.6.0.553199628695.issue26805@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26805>
_______________________________________

From report at bugs.python.org  Tue Apr 19 09:09:54 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 19 Apr 2016 13:09:54 +0000
Subject: [issue23710] C API doc for PyObject_HEAD is outdated
In-Reply-To: <1426776099.01.0.644113037586.issue23710@psf.upfronthosting.co.za>
Message-ID: <1461071394.91.0.617805222538.issue23710@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Docs of PyObject_HEAD and friends have already been fixed in 760c5cfacbaa.

https://docs.python.org/3/extending/newtypes.html still needs to be updated to mention ob_base:

    This is what a Noddy object will contain?in this case, nothing more than what every Python object contains?a refcount and a pointer to a type object. These are the fields the PyObject_HEAD macro brings in.

----------
keywords: +easy
nosy: +berker.peksag
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23710>
_______________________________________

From report at bugs.python.org  Tue Apr 19 09:10:40 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 19 Apr 2016 13:10:40 +0000
Subject: [issue9014] Incorrect documentation of the PyObject_HEAD macro
In-Reply-To: <1276718330.85.0.16685449654.issue9014@psf.upfronthosting.co.za>
Message-ID: <1461071440.97.0.0608233641883.issue9014@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage: commit review -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9014>
_______________________________________

From report at bugs.python.org  Tue Apr 19 09:11:29 2016
From: report at bugs.python.org (Tommy Sparber)
Date: Tue, 19 Apr 2016 13:11:29 +0000
Subject: [issue18378] locale.getdefaultlocale() fails on Mac OS X with default
 language set to English
In-Reply-To: <1373113143.69.0.513997485887.issue18378@psf.upfronthosting.co.za>
Message-ID: <1461071489.91.0.859839128055.issue18378@psf.upfronthosting.co.za>


Changes by Tommy Sparber <tommy.sparber at gmail.com>:


----------
nosy: +tsparber

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18378>
_______________________________________

From report at bugs.python.org  Tue Apr 19 09:13:16 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 19 Apr 2016 13:13:16 +0000
Subject: [issue11233] clarifying Availability: Unix
In-Reply-To: <1297969399.53.0.187875867799.issue11233@psf.upfronthosting.co.za>
Message-ID: <1461071596.93.0.289229673708.issue11233@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
stage: needs patch -> patch review
type:  -> enhancement
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11233>
_______________________________________

From report at bugs.python.org  Tue Apr 19 09:41:05 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 19 Apr 2016 13:41:05 +0000
Subject: [issue22297] 2.7 json encoding broken for enums
In-Reply-To: <1409310034.91.0.63329091583.issue22297@psf.upfronthosting.co.za>
Message-ID: <1461073265.98.0.573334771669.issue22297@psf.upfronthosting.co.za>


Berker Peksag added the comment:

-1 from me, too.

----------
nosy: +berker.peksag
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22297>
_______________________________________

From report at bugs.python.org  Tue Apr 19 09:44:09 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 13:44:09 +0000
Subject: [issue26805] Refer to types.SimpleNamespace in namedtuple
 documentation
In-Reply-To: <1461068744.46.0.957777609901.issue26805@psf.upfronthosting.co.za>
Message-ID: <1461073449.32.0.349983675487.issue26805@psf.upfronthosting.co.za>


STINNER Victor added the comment:

LGTM. I was going to push your sugestion when I saw that you are allowed to push yourself. See my attached patch:

* I fixed :ref:`types.SimpleNamespace` => you have to use :class:`...`
* I replaced "may be" with "can be" (I'm not confortable with "may", but it's up to you)

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file42520/collections.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26805>
_______________________________________

From report at bugs.python.org  Tue Apr 19 09:56:33 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 19 Apr 2016 13:56:33 +0000
Subject: [issue13876] Sporadic failure in test_socket: testRecvmsgEOF
In-Reply-To: <1327588563.2.0.447366914719.issue13876@psf.upfronthosting.co.za>
Message-ID: <1461074193.0.0.441155944762.issue13876@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13876>
_______________________________________

From report at bugs.python.org  Tue Apr 19 09:58:47 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Apr 2016 13:58:47 +0000
Subject: [issue21668] The select and time modules uses libm functions without
 linking against it
In-Reply-To: <1401972993.52.0.304727515537.issue21668@psf.upfronthosting.co.za>
Message-ID: <20160419135843.27120.55482.8BDD7AFE@psf.io>


Roundup Robot added the comment:

New changeset f92fea23161d by Victor Stinner in branch '3.5':
setup.py: add missing libm dependency
https://hg.python.org/cpython/rev/f92fea23161d

New changeset 3a9b47b062b9 by Victor Stinner in branch 'default':
Merge 3.5: Issue #21668
https://hg.python.org/cpython/rev/3a9b47b062b9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21668>
_______________________________________

From report at bugs.python.org  Tue Apr 19 10:00:07 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 14:00:07 +0000
Subject: [issue21668] The select and time modules uses libm functions without
 linking against it
In-Reply-To: <1401972993.52.0.304727515537.issue21668@psf.upfronthosting.co.za>
Message-ID: <1461074407.32.0.704539022429.issue21668@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I pushed ext_modules_libm.patch with the helper function proposed by Chi Hsuan Yen in https://github.com/yan12125/python3-android/blob/038271d/mk/python/modules-link-libm.patch.

Tell me if it's not enough. I hope that it will make CPython a little bit more portable ;-)

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21668>
_______________________________________

From report at bugs.python.org  Tue Apr 19 10:02:06 2016
From: report at bugs.python.org (Paul Moore)
Date: Tue, 19 Apr 2016 14:02:06 +0000
Subject: [issue26805] Refer to types.SimpleNamespace in namedtuple
 documentation
In-Reply-To: <1461068744.46.0.957777609901.issue26805@psf.upfronthosting.co.za>
Message-ID: <1461074526.82.0.728625121386.issue26805@psf.upfronthosting.co.za>


Paul Moore added the comment:

Thanks Victor. I'll sort this out this evening when I get to my PC with access to the CPython repo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26805>
_______________________________________

From report at bugs.python.org  Tue Apr 19 10:25:13 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 14:25:13 +0000
Subject: [issue26802] Avoid copy in call_function_var when no extra stack args
 are passed
In-Reply-To: <1461028212.35.0.591299573852.issue26802@psf.upfronthosting.co.za>
Message-ID: <1461075913.22.0.354060602162.issue26802@psf.upfronthosting.co.za>


STINNER Victor added the comment:

+        if (!nstar) {
+            /* There are no positional arguments on the stack or in in a
+               sequence that was unpacked. */
+            return PyTuple_New(0);
+        }

It's possible that stararg is already an empty tuple. Is it worth to use it?

+        if (!nstar) {
+            if (stararg != NULL && PyTuple_CheckExact(stararg)) {
+                Py_INCREF(stararg);
+                return stararg;
+            }
+            else {
+                /* There are no positional arguments on the stack or in in a
+                   sequence that was unpacked. */
+                return PyTuple_New(0);
+            }
+        }

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26802>
_______________________________________

From report at bugs.python.org  Tue Apr 19 10:25:23 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 14:25:23 +0000
Subject: [issue26802] Avoid copy in call_function_var when no extra stack args
 are passed
In-Reply-To: <1461028212.35.0.591299573852.issue26802@psf.upfronthosting.co.za>
Message-ID: <1461075923.21.0.165236334087.issue26802@psf.upfronthosting.co.za>


STINNER Victor added the comment:

call-function-var.patch LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26802>
_______________________________________

From report at bugs.python.org  Tue Apr 19 10:53:21 2016
From: report at bugs.python.org (Mike Pomraning)
Date: Tue, 19 Apr 2016 14:53:21 +0000
Subject: [issue25942] subprocess.call SIGKILLs too liberally
In-Reply-To: <1451006108.23.0.113868196098.issue25942@psf.upfronthosting.co.za>
Message-ID: <1461077601.13.0.668329882182.issue25942@psf.upfronthosting.co.za>


Mike Pomraning added the comment:

Re: #2, I'd rather have a zombie than a hard kill on a child whose code I perhaps don't control.  Zombies are a fact of life (er, a fact of undeath?) in UNIX process management, and are the historical and IMHO expected behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25942>
_______________________________________

From report at bugs.python.org  Tue Apr 19 10:53:32 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 14:53:32 +0000
Subject: [issue11233] clarifying Availability: Unix
In-Reply-To: <1297969399.53.0.187875867799.issue11233@psf.upfronthosting.co.za>
Message-ID: <1461077612.74.0.240613605755.issue11233@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I like the idea of a single place where the Availability is described, and adding a link to this place.  availability-directive.patch LGTM.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11233>
_______________________________________

From report at bugs.python.org  Tue Apr 19 10:58:33 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 14:58:33 +0000
Subject: [issue26803] syslog logging handler fails with address in unix
 abstract namespace
In-Reply-To: <1461051316.11.0.100147214694.issue26803@psf.upfronthosting.co.za>
Message-ID: <1461077913.89.0.397831262372.issue26803@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The following change looks good to me:

-        if isinstance(address, str):
+        if isinstance(address, (str, bytes)):
             self.unixsocket = True
             self._connect_unixsocket(address)

But I don't understand the testcase. Is an address starting with a NULL character a special address? How does it the bytes address case?

+        # override the definition in the base class
+        self.address = '\x00python_logging_test'

"syslog logging handler fails with address in unix abstract namespace"

What is the unix abstract namespace?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26803>
_______________________________________

From report at bugs.python.org  Tue Apr 19 11:03:12 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Apr 2016 15:03:12 +0000
Subject: [issue26516] Add PYTHONMALLOC env var and add support for malloc
 debug hooks in release mode
In-Reply-To: <1457522115.12.0.78692190259.issue26516@psf.upfronthosting.co.za>
Message-ID: <20160419150309.19323.91277.326B7C51@psf.io>


Roundup Robot added the comment:

New changeset c4c14e34e528 by Victor Stinner in branch 'default':
Don't define _PyMem_PymallocEnabled() if pymalloc is disabled
https://hg.python.org/cpython/rev/c4c14e34e528

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26516>
_______________________________________

From report at bugs.python.org  Tue Apr 19 11:05:50 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 15:05:50 +0000
Subject: [issue26799] gdb support fails with "Invalid cast."
In-Reply-To: <1461013840.26.0.744881925452.issue26799@psf.upfronthosting.co.za>
Message-ID: <1461078350.8.0.646153141318.issue26799@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I tried Python 3.6 with "./configure --with-pydebug --without-pymalloc --with-valgrind". The py-bt commands works as expect in gdb.

Can you try to modify python-gdb.py to get a traceback of your Invalid cast error?

> I am able to fix it with the following commands:
> (...) _type_char_ptr = gdb.lookup_type('char').pointer() # char*

These defines are already in Tools/gdb/libpython.py (python-gdb.py is just a copy). I don't understand why you have to redeclare these variables again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26799>
_______________________________________

From report at bugs.python.org  Tue Apr 19 11:09:27 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 15:09:27 +0000
Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError
In-Reply-To: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za>
Message-ID: <1461078567.31.0.0955892365156.issue26801@psf.upfronthosting.co.za>


STINNER Victor added the comment:

get_terminal_size.diff LGTM.

Would you like to try to write an unit test? Maybe using unittest.mock.patch?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26801>
_______________________________________

From report at bugs.python.org  Tue Apr 19 11:11:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 15:11:03 +0000
Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError
In-Reply-To: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za>
Message-ID: <1461078663.98.0.969311355132.issue26801@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> On all supported platforms (including such exotic as old AIX, QNX or Minix) it should be defined.

test_shutil always call shutil.get_terminal_size() and I didn't see any failure on the unit suite on our buildbots, even less common platforms like OpenBSD, AIX, OpenIndiana, etc.

So yes, os.get_terminal_size() looks to be available on all supported platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26801>
_______________________________________

From report at bugs.python.org  Tue Apr 19 11:13:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 15:13:24 +0000
Subject: [issue26802] Avoid copy in call_function_var when no extra stack args
 are passed
In-Reply-To: <1461028212.35.0.591299573852.issue26802@psf.upfronthosting.co.za>
Message-ID: <1461078804.04.0.249143726988.issue26802@psf.upfronthosting.co.za>


STINNER Victor added the comment:

FYI I ran the full test suite with the second attached patch and all tests pass.

By the way, please add a suffix like -2, -3, etc. to your patches next time. It's easier to identify them if they have a different name ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26802>
_______________________________________

From report at bugs.python.org  Tue Apr 19 11:33:42 2016
From: report at bugs.python.org (Yoni Lavi)
Date: Tue, 19 Apr 2016 15:33:42 +0000
Subject: [issue22558] Missing doc links to source code
In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za>
Message-ID: <1461080022.54.0.880245774685.issue22558@psf.upfronthosting.co.za>


Changes by Yoni Lavi <yoni at lavi.fm>:


----------
nosy: +Yoni Lavi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22558>
_______________________________________

From report at bugs.python.org  Tue Apr 19 12:15:28 2016
From: report at bugs.python.org (Joe Jevnik)
Date: Tue, 19 Apr 2016 16:15:28 +0000
Subject: [issue26802] Avoid copy in call_function_var when no extra stack args
 are passed
In-Reply-To: <1461028212.35.0.591299573852.issue26802@psf.upfronthosting.co.za>
Message-ID: <1461082528.24.0.536721239091.issue26802@psf.upfronthosting.co.za>


Joe Jevnik added the comment:

> It's possible that stararg is already an empty tuple. Is it worth to use it?

PyTuple_New(0) should return the unit tuple in most cases:

#if PyTuple_MAXSAVESIZE > 0
    if (size == 0 && free_list[0]) {
        op = free_list[0];
        Py_INCREF(op);
#ifdef COUNT_ALLOCS
        tuple_zero_allocs++;
#endif
        return (PyObject *) op;
    }


Looking at this again I think that checking if stararg is nonnull is more clear, I will update the patch (as call-function-var-3.patch). I cannot exactly rewrite the if to use the control flow you show because that would cause non-tuple subclasses to forward a stararg of () instead of copying it into a normal tuple when no arguments are passed ont the stack.

----------
Added file: http://bugs.python.org/file42521/call-function-var-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26802>
_______________________________________

From report at bugs.python.org  Tue Apr 19 12:42:28 2016
From: report at bugs.python.org (Thomas)
Date: Tue, 19 Apr 2016 16:42:28 +0000
Subject: [issue26799] gdb support fails with "Invalid cast."
In-Reply-To: <1461013840.26.0.744881925452.issue26799@psf.upfronthosting.co.za>
Message-ID: <1461084148.41.0.385612092492.issue26799@psf.upfronthosting.co.za>


Thomas added the comment:

I have done a bit more digging, turns out it is actually no problem at all to debug python in gdb with gdb with python support (at least using a fixed python-gdb-py).

Turns out the type->length of the the globally initialized ptr types is wrong: It is 4 instead of 8, causing the cast to fail. I suspect the initialization is done before the executable is loaded and gdb is using some default. To verify, I have put two prints in the global initialization and in a command invocation:

GOBAL INITIALIZATION: gdb.lookup_type('char').pointer().sizeof == 4
COMMAND INVOKE: gdb.lookup_type('char').pointer().sizeof == 8

I guess to be fully portable those types need to be looked up at least whenever gdb changes it's binary, but I have no idea if there is a hook for that. But it seems reasonable to just replace those globals with on-demand lookup functions or properties.

If you are interested in the actual python/c stack traces for the error:

Thread 1 "gdb" hit Breakpoint 1, value_cast (type=type at entry=0x2ef91e0, arg2=arg2 at entry=0x32b13f0) at ../../gdb/valops.c:571
571	      error (_("Invalid cast."));
(gdb) py-bt
Traceback (most recent call first):
  <built-in method cast of gdb.Value object at remote 0x3260de0>
  File "[...]/python-gdb.py", line 1151, in proxyval
    field_str = field_str.cast(_type_unsigned_char_ptr)
  File "[...]/python-gdb.py", line 945, in print_traceback
    % (self.co_filename.proxyval(visited),
  File "[...]/python-gdb.py", line 1578, in print_traceback
    pyop.print_traceback()
  File "[...]/python-gdb.py", line 1761, in invoke
    frame.print_traceback()
(gdb) bt
#0  value_cast (type=type at entry=0x2ef91e0, arg2=arg2 at entry=0x32b13f0) at ../../gdb/valops.c:571
#1  0x000000000052261f in valpy_do_cast (self=<gdb.Value at remote 0x3260de0>, args=<optimized out>, op=UNOP_CAST) at ../../gdb/python/py-value.c:525
#2  0x00007fc7ce2141de in PyCFunction_Call (func=func at entry=<built-in method cast of gdb.Value object at remote 0x3260de0>, args=args at entry=(<gdb.Type at remote 0x2ed0fb0>,), kwds=kwds at entry=0x0)
    at ../../Python-3.5.1/Objects/methodobject.c:109
#3  0x00007fc7ce2c8887 in call_function (pp_stack=pp_stack at entry=0x7ffffc81cec8, oparg=oparg at entry=1) at ../../Python-3.5.1/Python/ceval.c:4655
#4  0x00007fc7ce2c57ac in PyEval_EvalFrameEx (

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26799>
_______________________________________

From report at bugs.python.org  Tue Apr 19 12:54:02 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 19 Apr 2016 16:54:02 +0000
Subject: [issue4260] ctypes.xFUNCTYPE are decorators.
In-Reply-To: <1225864263.85.0.365773038706.issue4260@psf.upfronthosting.co.za>
Message-ID: <1461084842.9.0.249627474201.issue4260@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +easy
nosy: +berker.peksag
stage:  -> needs patch
versions: +Python 3.5, Python 3.6 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4260>
_______________________________________

From report at bugs.python.org  Tue Apr 19 13:09:24 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 19 Apr 2016 17:09:24 +0000
Subject: [issue1612012] builtin compile() doc needs PyCF_DONT_IMPLY_DEDENT
Message-ID: <1461085764.26.0.343806399829.issue1612012@psf.upfronthosting.co.za>


Berker Peksag added the comment:

A similar request (issue 12207 - "Document ast.PyCF_ONLY_AST") was rejected in 2012.

----------
nosy: +berker.peksag
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1612012>
_______________________________________

From report at bugs.python.org  Tue Apr 19 13:24:44 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 19 Apr 2016 17:24:44 +0000
Subject: [issue26802] Avoid copy in call_function_var when no extra stack args
 are passed
In-Reply-To: <1461028212.35.0.591299573852.issue26802@psf.upfronthosting.co.za>
Message-ID: <1461086684.64.0.417911088134.issue26802@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

BTW, for a realistic use case that would be sped up by this patch (possibly a lot), consider a recursive function that is continually doing a "virtual" pop of the first argument, and receiving the rest as varargs, which are then unpacked for the recursive call, e.g., a function to make a multidimensional list populated with zeroes:

    def nestedzeroes(firstdim, *dims):
        '''Make multidimensional list populated with 0s'''
        if not dims:
            return [0] * firstdim
        return [nestedzeroes(*dims) for _ in range(firstdim)]

It's somewhat less artificial in that it multiplies the effect of the optimization in a way that would actually exercise a microbenchmark-like scenario, where the amount of work involved in the star-args-only function calls is an appreciable percentage of the work. Running nestedzeroes(5, 5, 5) to create a 5x5x5 structure would involve 30 recursive calls; for nestedzeroes(10, 10, 10), 110 recursive calls.

I've actually used code like this (admittedly rarely) to avoid the hassle of inlining a many times nested set of list comprehensions to initialize a multidimensional list.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26802>
_______________________________________

From report at bugs.python.org  Tue Apr 19 13:35:33 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Tue, 19 Apr 2016 17:35:33 +0000
Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError
In-Reply-To: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za>
Message-ID: <1461087333.02.0.000688457710524.issue26801@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

On posix-based OSes, `os.get_terminal_size` might not exist ( https://hg.python.org/cpython/file/default/Modules/posixmodule.c#l12462 ), so this is needed.

New patch file with tests included.

----------
Added file: http://bugs.python.org/file42522/get_term_size_with_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26801>
_______________________________________

From report at bugs.python.org  Tue Apr 19 14:07:28 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Tue, 19 Apr 2016 18:07:28 +0000
Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError
In-Reply-To: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za>
Message-ID: <1461089248.31.0.193422926075.issue26801@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Hmm, if `sys.__stdout__` was deleted (or set to `None`), this would also raise an `AttributeError` when calling `shutil.get_terminal_size`, so I think that even if `os.get_terminal_size` is guaranteed to be always present (which it's not, IIUC), catching `AttributeError` would prevent that bug, too.

Should I write a unit test for that too? Even though this one theorically covers it as well, I wouldn't want people in the future to think they can safely remove `except AttributeError` from the code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26801>
_______________________________________

From report at bugs.python.org  Tue Apr 19 14:20:11 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Apr 2016 18:20:11 +0000
Subject: [issue26805] Refer to types.SimpleNamespace in namedtuple
 documentation
In-Reply-To: <1461068744.46.0.957777609901.issue26805@psf.upfronthosting.co.za>
Message-ID: <20160419181913.107502.94499.D543EDB6@psf.io>


Roundup Robot added the comment:

New changeset c3232d1d8ca0 by Paul Moore in branch 'default':
Mention types.SimpleNamespace in collections.namedtuple doc
https://hg.python.org/cpython/rev/c3232d1d8ca0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26805>
_______________________________________

From report at bugs.python.org  Tue Apr 19 14:22:02 2016
From: report at bugs.python.org (Paul Moore)
Date: Tue, 19 Apr 2016 18:22:02 +0000
Subject: [issue26805] Refer to types.SimpleNamespace in namedtuple
 documentation
In-Reply-To: <1461068744.46.0.957777609901.issue26805@psf.upfronthosting.co.za>
Message-ID: <1461090122.14.0.231647269794.issue26805@psf.upfronthosting.co.za>


Changes by Paul Moore <p.f.moore at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26805>
_______________________________________

From report at bugs.python.org  Tue Apr 19 14:24:28 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Tue, 19 Apr 2016 18:24:28 +0000
Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError
In-Reply-To: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za>
Message-ID: <1461090268.45.0.818169788072.issue26801@psf.upfronthosting.co.za>


Changes by Emanuel Barry <barry at dadadata.net>:


Added file: http://bugs.python.org/file42523/get_term_size_with_test2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26801>
_______________________________________

From report at bugs.python.org  Tue Apr 19 15:19:12 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 19:19:12 +0000
Subject: [issue26799] gdb support fails with "Invalid cast."
In-Reply-To: <1461013840.26.0.744881925452.issue26799@psf.upfronthosting.co.za>
Message-ID: <1461093552.09.0.752196911771.issue26799@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Turns out the type->length of the the globally initialized ptr types is wrong: It is 4 instead of 8, causing the cast to fail. I suspect the initialization is done before the executable is loaded and gdb is using some default.

Hum. I see two options:

* try late initialization: initialize types at the first usage
* remove variables: always lookup types at runtime

Would you like to try to implement these options?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26799>
_______________________________________

From report at bugs.python.org  Tue Apr 19 15:22:09 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 19:22:09 +0000
Subject: [issue26805] Refer to types.SimpleNamespace in namedtuple
 documentation
In-Reply-To: <1461068744.46.0.957777609901.issue26805@psf.upfronthosting.co.za>
Message-ID: <1461093729.1.0.535784457933.issue26805@psf.upfronthosting.co.za>


STINNER Victor added the comment:

types.SimpleNamespace is also available on Python 3.5, you may also modify Python 3.5 doc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26805>
_______________________________________

From report at bugs.python.org  Tue Apr 19 15:27:52 2016
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Tue, 19 Apr 2016 19:27:52 +0000
Subject: [issue14102] argparse: add ability to create a man page
In-Reply-To: <1330031760.56.0.8938390885.issue14102@psf.upfronthosting.co.za>
Message-ID: <1461094072.6.0.0211823568357.issue14102@psf.upfronthosting.co.za>


Changes by Zbyszek J?drzejewski-Szmek <zbyszek at in.waw.pl>:


----------
nosy: +zbysz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14102>
_______________________________________

From report at bugs.python.org  Tue Apr 19 15:39:08 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 19:39:08 +0000
Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError
In-Reply-To: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za>
Message-ID: <1461094748.33.0.716684245783.issue26801@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Hmm, if `sys.__stdout__` was deleted (or set to `None`), this would also raise an `AttributeError` when calling `shutil.get_terminal_size`, so I think that even if `os.get_terminal_size` is guaranteed to be always present (which it's not, IIUC), catching `AttributeError` would prevent that bug, too.

It would be nice to have an unit test too for this case. You can use something like:

with unittest.mock.patch('shutil.sys') as mock_sys:
    del mock_sys.__stdout__
    print(shutil.get_terminal_size((3, 3)))

(and mock also os.envion, as shown in the review.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26801>
_______________________________________

From report at bugs.python.org  Tue Apr 19 15:54:44 2016
From: report at bugs.python.org (Paul Moore)
Date: Tue, 19 Apr 2016 19:54:44 +0000
Subject: [issue26805] Refer to types.SimpleNamespace in namedtuple
 documentation
In-Reply-To: <1461068744.46.0.957777609901.issue26805@psf.upfronthosting.co.za>
Message-ID: <1461095684.35.0.687168977893.issue26805@psf.upfronthosting.co.za>


Paul Moore added the comment:

Ah, thanks. I probably did the commit the wrong way round in that case, as I committed to tip. How should I do the commit into 3.5? (I'm also somewhat confused by the fact that hg describes the 3.5 branch as "inactive"...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26805>
_______________________________________

From report at bugs.python.org  Tue Apr 19 16:12:24 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Apr 2016 20:12:24 +0000
Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError
In-Reply-To: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za>
Message-ID: <1461096744.3.0.37837436865.issue26801@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Honest, I don't think that we need such complex test for the case that isn't occurred in wild. If delete os.get_terminal_size, all TermsizeTests tests fail, so we will know if encounter a platform without os.get_terminal_size.

Instead I suggest to add ValueError in exceptions list and add tests for changed sys.__stdout__: None, StringIO(), open(TESTFN, "w"). Some of these tests fail without AttributeError in the exceptions list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26801>
_______________________________________

From report at bugs.python.org  Tue Apr 19 16:14:07 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 20:14:07 +0000
Subject: [issue26805] Refer to types.SimpleNamespace in namedtuple
 documentation
In-Reply-To: <1461095684.35.0.687168977893.issue26805@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZ3rnEN6N+CWXB8jAuB6bmJim+qBro2-6jbbHxKY5kf6g@mail.gmail.com>


STINNER Victor added the comment:

I don't know what "inactive" means in Mercurial. Python 3.5 is
actively developed (maintained):
https://docs.python.org/devguide/#status-of-python-branches

> How should I do the commit into 3.5?

Update to 3.5 (hg up 3.5), transplant your change (hg transplant
c3232d1d8ca0). Fix if needed. I don't recall if you need to commit or
not (commit if you get the patch as local changes). Then update to
default (hg update default), and merge 3.5 (hg merge 3.5). Commit.

https://docs.python.org/devguide/devcycle.html#branches

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26805>
_______________________________________

From report at bugs.python.org  Tue Apr 19 16:16:23 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 20:16:23 +0000
Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError
In-Reply-To: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za>
Message-ID: <1461096983.43.0.208237196303.issue26801@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Honest, I don't think that we need such complex test for the case that isn't occurred in wild.

Right. I'm also fine if you test manually this corner case.

The Lib/shutil.py change LGTM in get_term_size_with_test2.patch (I ignored the unit test).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26801>
_______________________________________

From report at bugs.python.org  Tue Apr 19 16:16:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Apr 2016 20:16:40 +0000
Subject: [issue26802] Avoid copy in call_function_var when no extra stack args
 are passed
In-Reply-To: <1461028212.35.0.591299573852.issue26802@psf.upfronthosting.co.za>
Message-ID: <1461097000.13.0.592656285023.issue26802@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

call-function-var-3.patch LGTM. Thank you for your contribution Joe.

----------
assignee:  -> serhiy.storchaka
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26802>
_______________________________________

From report at bugs.python.org  Tue Apr 19 16:20:17 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Tue, 19 Apr 2016 20:20:17 +0000
Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError
In-Reply-To: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za>
Message-ID: <1461097217.81.0.829251753654.issue26801@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

To be fair, I don't think we actually need a unit test to check if `os.get_terminal_size` exists, as we catch any `AttributeError` at all. I'd want to keep the except clause there to properly handle `sys.__stdout__` being `None` (or simply absent). I also don't consider that I'm fixing a bug here, but more like an oversight. The except clause with `NameError` is obviously an oversight from when the function was ported from `os` to `shutil`, so I'd rather fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26801>
_______________________________________

From report at bugs.python.org  Tue Apr 19 16:29:30 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Apr 2016 20:29:30 +0000
Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError
In-Reply-To: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za>
Message-ID: <20160419202925.19521.17538.1675F79B@psf.io>


Roundup Robot added the comment:

New changeset e3763b5964b6 by Victor Stinner in branch '3.5':
Fix shutil.get_terminal_size() error handling
https://hg.python.org/cpython/rev/e3763b5964b6

New changeset 75f40345d784 by Victor Stinner in branch 'default':
Merge 3.5: issue #26801
https://hg.python.org/cpython/rev/75f40345d784

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26801>
_______________________________________

From report at bugs.python.org  Tue Apr 19 16:30:23 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 20:30:23 +0000
Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError
In-Reply-To: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za>
Message-ID: <1461097823.08.0.229711202133.issue26801@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Well, since Serhiy, Emmanuel and me agree that unit tests are overkill, I pushed the obivous and trivial fix. Thank you Emmanual for your contribution! I added your name to Misc/ACKS ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26801>
_______________________________________

From report at bugs.python.org  Tue Apr 19 16:31:31 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 20:31:31 +0000
Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError
In-Reply-To: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za>
Message-ID: <1461097891.14.0.920088281773.issue26801@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/issue26801>
_______________________________________

From report at bugs.python.org  Tue Apr 19 16:36:16 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 19 Apr 2016 20:36:16 +0000
Subject: [issue26805] Refer to types.SimpleNamespace in namedtuple
 documentation
In-Reply-To: <1461068744.46.0.957777609901.issue26805@psf.upfronthosting.co.za>
Message-ID: <1461098176.76.0.600273809947.issue26805@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Or if you don't want to use any hg extension:

hg update 3.5
hg import --no-c http://bugs.python.org/file42520/collections.patch
hg commit
hg update default
hg merge 3.5
hg revert -ar default
hg resolve -am
hg commit

(Null merge (hg merge 3.5 and later) is step documented at https://docs.python.org/devguide/faq.html?#how-do-i-make-a-null-merge)

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26805>
_______________________________________

From report at bugs.python.org  Tue Apr 19 16:38:02 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Apr 2016 20:38:02 +0000
Subject: [issue26802] Avoid copy in call_function_var when no extra stack args
 are passed
In-Reply-To: <1461028212.35.0.591299573852.issue26802@psf.upfronthosting.co.za>
Message-ID: <20160419203734.25320.65655.E379AAEB@psf.io>


Roundup Robot added the comment:

New changeset 15b20201cfa5 by Serhiy Storchaka in branch 'default':
Issue #26802: Optimized calling a function with *args only positional arguments.
https://hg.python.org/cpython/rev/15b20201cfa5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26802>
_______________________________________

From report at bugs.python.org  Tue Apr 19 16:47:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Apr 2016 20:47:10 +0000
Subject: [issue26802] Avoid copy in call_function_var when no extra stack args
 are passed
In-Reply-To: <1461028212.35.0.591299573852.issue26802@psf.upfronthosting.co.za>
Message-ID: <1461098830.68.0.947750676618.issue26802@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

FYI, there is a proposition about constructing arguments tuple and dict in bytecode instead of ceval.c. This will significantly simplify CALL_FUNCTION (which will get just one optional tuple and one optional dict). Likely this idea will be implemented after changing to wordcode.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26802>
_______________________________________

From report at bugs.python.org  Tue Apr 19 17:14:43 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 21:14:43 +0000
Subject: [issue26802] Avoid copy in call_function_var when no extra stack args
 are passed
In-Reply-To: <1461028212.35.0.591299573852.issue26802@psf.upfronthosting.co.za>
Message-ID: <1461100483.71.0.154244272017.issue26802@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Good news. On a microbenchmark, the patch makes func(*tuple) between 14% and 18% faster. See attached bench.py. I ran the benchmark on Linux with isolated CPUs to get reliable results.
https://haypo-notes.readthedocs.org/microbenchmark.html

$ ./python-orig ~/prog/HG/misc/python/benchmark.py script bench.py --file=orig
$ ./python-patched ~/prog/HG/misc/python/benchmark.py script bench.py --file=patch
$ ./python-orig ~/prog/HG/misc/python/benchmark.py compare_to orig patch

Common platform:
CPU model: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
SCM: hg revision=75f40345d784 branch=default date="2016-04-19 22:29 +0200"
Timer info: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09)
Timer: time.perf_counter
Bits: int=32, long=64, long long=64, size_t=64, void*=64
Python unicode implementation: PEP 393
CFLAGS: -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
Platform: Linux-4.4.4-301.fc23.x86_64-x86_64-with-fedora-23-Twenty_Three

Platform of campaign orig:
Timer precision: 62 ns
Python version: 3.6.0a0 (default:75f40345d784, Apr 19 2016, 23:07:49) [GCC 5.3.1 20151207 (Red Hat 5.3.1-2)]
Date: 2016-04-19 23:08:21

Platform of campaign patch:
Timer precision: 61 ns
Python version: 3.6.0a0 (default:084d5315dd50, Apr 19 2016, 23:06:38) [GCC 5.3.1 20151207 (Red Hat 5.3.1-2)]
Date: 2016-04-19 23:08:39

-----------------------------------------------------+------------+--------------
Tests                                                |       orig |         patch
-----------------------------------------------------+------------+--------------
def func(a, b, c): pass args=(1, 2, 3); func(*args)  | 127 ns (*) | 104 ns (-18%)
def func(*args): pass args=(1, 2, 3); func(*args)    | 147 ns (*) | 126 ns (-14%)
def func(*args): pass args=(2, 3, 4); func(1, *args) | 154 ns (*) |        154 ns
-----------------------------------------------------+------------+--------------
Total                                                | 429 ns (*) | 384 ns (-10%)
-----------------------------------------------------+------------+--------------

----------
Added file: http://bugs.python.org/file42524/bench.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26802>
_______________________________________

From report at bugs.python.org  Tue Apr 19 17:15:55 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Apr 2016 21:15:55 +0000
Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError
In-Reply-To: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za>
Message-ID: <1461100555.87.0.0966319604718.issue26801@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch that adds ValueError in the exceptions list and adds tests.

----------
resolution: fixed -> 
status: closed -> open
Added file: http://bugs.python.org/file42525/get_terminal_size_valueerror.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26801>
_______________________________________

From report at bugs.python.org  Tue Apr 19 17:16:42 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 21:16:42 +0000
Subject: [issue26802] Avoid copy in call_function_var when no extra stack args
 are passed
In-Reply-To: <1461028212.35.0.591299573852.issue26802@psf.upfronthosting.co.za>
Message-ID: <1461100602.13.0.0501912803175.issue26802@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> New changeset 15b20201cfa5 by Serhiy Storchaka in branch 'default':

Oh. I was cooking a commit, you was faster than me :-)

IMHO it's worth to make the optimization in Misc/NEWS, or maybe even in Whats new in Python 3.6.

I prepared the text:

Issue #26802: Optimize function calls only using unpacking like ``func(*tuple)`` (no other positional argument, no keyword): avoid copying the tuple. Such function calls are up to 15% faster. Patch written by Joe Jevnik.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26802>
_______________________________________

From report at bugs.python.org  Tue Apr 19 17:28:36 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 21:28:36 +0000
Subject: [issue26802] Avoid copy in call_function_var when no extra stack args
 are passed
In-Reply-To: <1461028212.35.0.591299573852.issue26802@psf.upfronthosting.co.za>
Message-ID: <1461101316.66.0.532562367455.issue26802@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> FYI, there is a proposition about constructing arguments tuple and dict in bytecode instead of ceval.c. This will significantly simplify CALL_FUNCTION (which will get just one optional tuple and one optional dict). Likely this idea will be implemented after changing to wordcode.

Wordcode is the issue #26647.

Do you have a reference to the more efficient implementation of CALL_FUNCTION? I recall vaguely this idea.

--

It was also proposed to pass keyword arguments as positional arguments: replace func(a=1, b=2) with func(1, 2) with "def func(a, b): ...". But this optimization requires something like FAT Python to disable the optimization if the function is replaced at runtime.

This optimization is more complex, maybe it's not worth.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26802>
_______________________________________

From report at bugs.python.org  Tue Apr 19 17:36:52 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 21:36:52 +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: <1461101812.9.0.158916920328.issue23926@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I reviewed skipitems.patch.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23926>
_______________________________________

From report at bugs.python.org  Tue Apr 19 17:44:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Apr 2016 21:44:58 +0000
Subject: [issue26802] Avoid copy in call_function_var when no extra stack args
 are passed
In-Reply-To: <1461028212.35.0.591299573852.issue26802@psf.upfronthosting.co.za>
Message-ID: <1461102298.51.0.445115249625.issue26802@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Do you have a reference to the more efficient implementation of CALL_FUNCTION?

Actually it was about MAKE_FUNCTION. But I think the same is applicable to CALL_FUNCTION.

http://comments.gmane.org/gmane.comp.python.devel/157321

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26802>
_______________________________________

From report at bugs.python.org  Tue Apr 19 17:52:30 2016
From: report at bugs.python.org (Joe Jevnik)
Date: Tue, 19 Apr 2016 21:52:30 +0000
Subject: [issue26802] Avoid copy in call_function_var when no extra stack args
 are passed
In-Reply-To: <1461028212.35.0.591299573852.issue26802@psf.upfronthosting.co.za>
Message-ID: <1461102750.44.0.306650761644.issue26802@psf.upfronthosting.co.za>


Joe Jevnik added the comment:

CALL_FUNCTION doesn't use extended arg; I don't see what we get by adding some opcode to convert the sequence into a tuple. We also don't want to box up the stack arguments into a tuple because when we do a CALL_FUNCTION to a python function we just copy the stack[-n:] elements into the locals of the next frame. Emitting a build_tuple here would be an unneeded allocation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26802>
_______________________________________

From report at bugs.python.org  Tue Apr 19 18:00:01 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Apr 2016 22:00:01 +0000
Subject: [issue26805] Refer to types.SimpleNamespace in namedtuple
 documentation
In-Reply-To: <1461068744.46.0.957777609901.issue26805@psf.upfronthosting.co.za>
Message-ID: <20160419215957.88648.75456.2E053A59@psf.io>


Roundup Robot added the comment:

New changeset 3115b6ce1006 by Paul Moore in branch '3.5':
Mention types.SimpleNamespace in collections.namedtuple doc
https://hg.python.org/cpython/rev/3115b6ce1006

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26805>
_______________________________________

From report at bugs.python.org  Tue Apr 19 18:21:22 2016
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 19 Apr 2016 22:21:22 +0000
Subject: [issue26470] Make OpenSSL module compatible with OpenSSL 1.1.0
In-Reply-To: <1456920893.87.0.933592382559.issue26470@psf.upfronthosting.co.za>
Message-ID: <1461104482.09.0.412039012314.issue26470@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


Removed file: http://bugs.python.org/file42184/0001-Port-Python-s-SSL-module-to-OpenSSL-1.1.0-WIP.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26470>
_______________________________________

From report at bugs.python.org  Tue Apr 19 18:21:53 2016
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 19 Apr 2016 22:21:53 +0000
Subject: [issue26470] Make OpenSSL module compatible with OpenSSL 1.1.0
In-Reply-To: <1456920893.87.0.933592382559.issue26470@psf.upfronthosting.co.za>
Message-ID: <1461104513.72.0.121404292681.issue26470@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The patch makes Python compatible with OpenSSL 1.1.0-pre6-dev from
git. The ssl and hashlib module are also compatible with OpenSSL 0.9.8zh,
1.0.1s, 1.0.2g as well as LibreSSL 2.3.3.

----------
Added file: http://bugs.python.org/file42526/0001-Port-Python-s-SSL-module-to-OpenSSL-1.1.0-WIP.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26470>
_______________________________________

From report at bugs.python.org  Tue Apr 19 18:23:17 2016
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 19 Apr 2016 22:23:17 +0000
Subject: [issue26470] Make OpenSSL module compatible with OpenSSL 1.1.0
In-Reply-To: <1456920893.87.0.933592382559.issue26470@psf.upfronthosting.co.za>
Message-ID: <1461104597.23.0.915123110987.issue26470@psf.upfronthosting.co.za>


Christian Heimes added the comment:

PS: The patch depends on https://github.com/openssl/openssl/pull/979

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26470>
_______________________________________

From report at bugs.python.org  Tue Apr 19 18:31:55 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Apr 2016 22:31:55 +0000
Subject: [issue26802] Avoid copy in call_function_var when no extra stack args
 are passed
In-Reply-To: <1461028212.35.0.591299573852.issue26802@psf.upfronthosting.co.za>
Message-ID: <20160419223152.26089.50227.96D43D54@psf.io>


Roundup Robot added the comment:

New changeset 6535481d610e by Victor Stinner in branch 'default':
Optimize func(*tuple) function call
https://hg.python.org/cpython/rev/6535481d610e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26802>
_______________________________________

From report at bugs.python.org  Tue Apr 19 18:33:07 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 19 Apr 2016 22:33:07 +0000
Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError
In-Reply-To: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za>
Message-ID: <1461105187.49.0.0470516557845.issue26801@psf.upfronthosting.co.za>


Martin Panter added the comment:

I doubt it is worth spending much effort supporting sys.__stdout__ being overwritten with StringIO or deleted. That seems an abuse of the ?sys? module. Idle doesn?t even seem to alter this attribute.

But if you call stdout.close() or detach(), I think that is a more valid way to trigger ValueError, so Serhiy?s patch is worthwhile for that case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26801>
_______________________________________

From report at bugs.python.org  Tue Apr 19 18:34:44 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 22:34:44 +0000
Subject: [issue26802] Avoid copy in call_function_var when no extra stack args
 are passed
In-Reply-To: <1461028212.35.0.591299573852.issue26802@psf.upfronthosting.co.za>
Message-ID: <1461105284.5.0.265322889779.issue26802@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> New changeset 6535481d610e by Victor Stinner in branch 'default':
> Optimize func(*tuple) function call
> https://hg.python.org/cpython/rev/6535481d610e

Oops. Mercurial is too hard for me /o\ I didn't want to push this change, since Serhiy already pushed the change itself. I asked Serhiy what he thinks about documenting the optimization. Well, now at least it's documented in NEWS. But I'm still interested to know if it's worth to mention the change in What's New in Python 3.6?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26802>
_______________________________________

From report at bugs.python.org  Tue Apr 19 18:39:04 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 19 Apr 2016 22:39:04 +0000
Subject: [issue26806] IDLE not displaying RecursionError tracebacks
Message-ID: <1461105544.08.0.0145590373976.issue26806@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Test program:

import sys
sys.setrecursionlimit(20)
def f(): return f()
f()

F:\Python\mypy>python tem.py
Traceback (most recent call last):
  File "tem.py", line 4, in <module>
    f()
  File "tem.py", line 3, in f
    def f(): return f()
...
RecursionError: maximum recursion depth exceeded

In 2.7.11, the error is caught and the user process restarted.

======================= RESTART: F:\Python\mypy\tem.py =======================

=============================== RESTART: Shell ===============================
>>> 

In 3.5.1, the user process hangs, ^C does not work, and a restart explicitly requested either with Shell => Restart or running another program.

This behavior is either peculiar to this test case, or a regression, as I remember getting proper RecursionError tracebacks in the past.

----------
assignee: terry.reedy
messages: 263785
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE not displaying RecursionError tracebacks
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26806>
_______________________________________

From report at bugs.python.org  Tue Apr 19 18:57:58 2016
From: report at bugs.python.org (Chase Sterling)
Date: Tue, 19 Apr 2016 22:57:58 +0000
Subject: [issue26793] uuid causing thread issues when forking using os.fork
 py3.4+
In-Reply-To: <1460955119.44.0.370193254434.issue26793@psf.upfronthosting.co.za>
Message-ID: <1461106678.29.0.54767561872.issue26793@psf.upfronthosting.co.za>


Chase Sterling added the comment:

@STINNER Victor Your example is starting a thread before calling fork, the other examples just init a threading.Thread class before the fork (I imagine the OS thread is not created at that point.) Are you saying that just instantiating a threading.Thread class before forking (without actually starting the thread) is bad?

----------
nosy: +Chase Sterling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26793>
_______________________________________

From report at bugs.python.org  Tue Apr 19 19:21:52 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Apr 2016 23:21:52 +0000
Subject: [issue26058] PEP 509: Add ma_version to PyDictObject
In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za>
Message-ID: <1461108112.39.0.453827217424.issue26058@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Results of the CPython benchmark suite on dict_version-8.patch.

IMHO regex_v8 can be ignored, this benchmark is unstable (issue #26275).

Original python: ../pep509/python
3.6.0a0 (default:3a9b47b062b9, Apr 19 2016, 16:23:15) 
[GCC 5.3.1 20151207 (Red Hat 5.3.1-2)]

Patched python: ../pep509/python
3.6.0a0 (default:96f61aab2c6e, Apr 19 2016, 15:21:15) 
[GCC 5.3.1 20151207 (Red Hat 5.3.1-2)]

$ python3 -u perf.py --rigorous -b all ../default.copy/python ../pep509/python

INFO:root:Automatically selected timer: perf_counter
(...)
Report on Linux smithers 4.4.4-301.fc23.x86_64 #1 SMP Fri Mar 4 17:42:42 UTC 2016 x86_64 x86_64
Total CPU cores: 8

### 2to3 ###
Min: 6.714927 -> 6.856992: 1.02x slower
Avg: 6.726773 -> 6.984359: 1.04x slower
Significant (t=-5.16)
Stddev: 0.01160 -> 0.11111: 9.5816x larger

### call_method ###
Min: 0.312567 -> 0.323260: 1.03x slower
Avg: 0.313399 -> 0.323821: 1.03x slower
Significant (t=-284.62)
Stddev: 0.00042 -> 0.00048: 1.1430x larger

### call_simple ###
Min: 0.242091 -> 0.228922: 1.06x faster
Avg: 0.243613 -> 0.229294: 1.06x faster
Significant (t=2134.23)
Stddev: 0.00010 -> 0.00005: 1.9124x smaller

### etree_generate ###
Min: 0.255097 -> 0.265558: 1.04x slower
Avg: 0.256947 -> 0.267478: 1.04x slower
Significant (t=-67.89)
Stddev: 0.00111 -> 0.00108: 1.0250x smaller

### etree_parse ###
Min: 0.281726 -> 0.290976: 1.03x slower
Avg: 0.283626 -> 0.292642: 1.03x slower
Significant (t=-62.59)
Stddev: 0.00109 -> 0.00094: 1.1540x smaller

### etree_process ###
Min: 0.217164 -> 0.229552: 1.06x slower
Avg: 0.219401 -> 0.231242: 1.05x slower
Significant (t=-75.05)
Stddev: 0.00112 -> 0.00111: 1.0053x smaller

### fannkuch ###
Min: 1.012875 -> 0.985196: 1.03x faster
Avg: 1.014760 -> 0.992104: 1.02x faster
Significant (t=46.44)
Stddev: 0.00287 -> 0.00395: 1.3778x larger

### float ###
Min: 0.259226 -> 0.251918: 1.03x faster
Avg: 0.266530 -> 0.260176: 1.02x faster
Significant (t=10.69)
Stddev: 0.00403 -> 0.00437: 1.0836x larger

### json_load ###
Min: 0.430602 -> 0.433593: 1.01x slower
Avg: 0.431278 -> 0.486924: 1.13x slower
Significant (t=-24.86)
Stddev: 0.00045 -> 0.02238: 49.8974x larger

### normal_startup ###
Min: 0.319092 -> 0.326082: 1.02x slower
Avg: 0.320093 -> 0.326842: 1.02x slower
Significant (t=-70.52)
Stddev: 0.00067 -> 0.00069: 1.0283x larger

### regex_effbot ###
Min: 0.048969 -> 0.048313: 1.01x faster
Avg: 0.050019 -> 0.048415: 1.03x faster
Significant (t=31.41)
Stddev: 0.00051 -> 0.00006: 8.8152x smaller

### regex_v8 ###
Min: 0.051040 -> 0.043412: 1.18x faster
Avg: 0.051325 -> 0.043577: 1.18x faster
Significant (t=45.60)
Stddev: 0.00120 -> 0.00120: 1.0013x larger

### richards ###
Min: 0.157625 -> 0.161126: 1.02x slower
Avg: 0.158952 -> 0.162519: 1.02x slower
Significant (t=-34.92)
Stddev: 0.00073 -> 0.00071: 1.0351x smaller

### silent_logging ###
Min: 0.070547 -> 0.069902: 1.01x faster
Avg: 0.072246 -> 0.069934: 1.03x faster
Significant (t=65.51)
Stddev: 0.00035 -> 0.00003: 11.9828x smaller

The following not significant results are hidden, use -v to show them:
call_method_slots, call_method_unknown, chameleon_v2, chaos, django_v3, etree_iterparse, fastpickle, fastunpickle, formatted_logging, go, hexiom2, json_dump_v2, mako_v2, meteor_contest, nbody, nqueens, pathlib, pickle_dict, pickle_list, pidigits, raytrace, regex_compile, simple_logging, spectral_norm, startup_nosite, telco, tornado_http, unpack_sequence, unpickle_list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26058>
_______________________________________

From report at bugs.python.org  Tue Apr 19 22:12:02 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 20 Apr 2016 02:12:02 +0000
Subject: [issue26769] Python 2.7: make private file descriptors non inheritable
In-Reply-To: <1460725141.7.0.638632202912.issue26769@psf.upfronthosting.co.za>
Message-ID: <1461118322.33.0.868237378303.issue26769@psf.upfronthosting.co.za>


Martin Panter added the comment:

The patch looks reasonable as far as I understand it. I don?t know what the consequences of adding new PyAPI_FUNC() symbols to 2.7 is, or changing the Windows build files, so can?t really comment on those aspects though.

I left some questions about porting _Py_open() and _Py_dup().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26769>
_______________________________________

From report at bugs.python.org  Tue Apr 19 22:22:56 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 20 Apr 2016 02:22:56 +0000
Subject: [issue24291] Many servers (wsgiref, http.server,
 etc) can truncate large output blobs
In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za>
Message-ID: <1461118976.86.0.091176630829.issue24291@psf.upfronthosting.co.za>


Martin Panter added the comment:

Widening the scope of the title to attract reviewers :)

----------
title: wsgiref.handlers.SimpleHandler truncates large output blobs -> Many servers (wsgiref, http.server, etc) can truncate large output blobs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24291>
_______________________________________

From report at bugs.python.org  Tue Apr 19 22:28:29 2016
From: report at bugs.python.org (Yoni Lavi)
Date: Wed, 20 Apr 2016 02:28:29 +0000
Subject: [issue22558] Missing doc links to source code
In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za>
Message-ID: <1461119309.01.0.971873164456.issue22558@psf.upfronthosting.co.za>


Yoni Lavi added the comment:

I went over all the library rst files and added a link to the source for each of the modules.

Also, I standardized the structure of the headers in all of the files to be in the following order: """
.. module

.. moduleauthor
.. sectionauthor

.. versionadded

**Source code:**

.. testsetup

.. index

--------------
"""

This'll be my first Python patch. Please let me know if I chose to go into too large of a scope and should split this, or if there's anything else I can improve. Also, since I'm modifying most of these files anyway, this might be a good opportunity to modify the header structure I mentioned above.

Thanks

----------
keywords: +patch
Added file: http://bugs.python.org/file42527/mywork.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22558>
_______________________________________

From report at bugs.python.org  Tue Apr 19 22:46:10 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 20 Apr 2016 02:46:10 +0000
Subject: [issue26804] Prioritize lowercase proxy variables in urllib.request
In-Reply-To: <1461053909.86.0.0123928931795.issue26804@psf.upfronthosting.co.za>
Message-ID: <1461120370.1.0.440768716505.issue26804@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think this should be applied as a bug fix to 2.7 and 3.5 as well. What do you think? Lowercase is the normal way to use these variables.

I left some comments on the code review.

A similar bug seems to exist for the ?no_proxy? variable. Also, it would be nice to add a test case for this.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26804>
_______________________________________

From report at bugs.python.org  Wed Apr 20 00:51:46 2016
From: report at bugs.python.org (Luiz Poleto)
Date: Wed, 20 Apr 2016 04:51:46 +0000
Subject: [issue17233] http.client header debug output format
In-Reply-To: <1361256774.67.0.162902666936.issue17233@psf.upfronthosting.co.za>
Message-ID: <1461127906.26.0.3163262435.issue17233@psf.upfronthosting.co.za>


Luiz Poleto added the comment:

The attached patch fixes 2 of the main issues reported:

- Missing header values
- Missing newline at the end of the header line

I thought about the suggestion to include the response headers with the reply but considering that they are two different elements in an HTTP response message, I think it makes more sense to keep them on separate lines. The names, however, could be changed; perhaps from reply to response-body and headers to response-headers but maybe it could affect other users already expecting these values?

----------
keywords: +patch
Added file: http://bugs.python.org/file42528/issue17233.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17233>
_______________________________________

From report at bugs.python.org  Wed Apr 20 01:06:37 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 20 Apr 2016 05:06:37 +0000
Subject: [issue22359] Remove incorrect uses of recursive make
In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za>
Message-ID: <1461128797.4.0.453610075159.issue22359@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think this may be a viable solution Xavier. See review suggestion about building from read-only source though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22359>
_______________________________________

From report at bugs.python.org  Wed Apr 20 01:07:32 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 20 Apr 2016 05:07:32 +0000
Subject: [issue22359] Remove incorrect uses of recursive make
In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za>
Message-ID: <1461128852.76.0.362955685184.issue22359@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
dependencies:  -When cross-compiling, don?t try to execute binaries
status: languishing -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22359>
_______________________________________

From report at bugs.python.org  Wed Apr 20 01:10:22 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 20 Apr 2016 05:10:22 +0000
Subject: =?utf-8?q?=5Bissue22625=5D_When_cross-compiling=2C_don=E2=80=99t_try_to_e?=
 =?utf-8?q?xecute_binaries?=
In-Reply-To: <1413226219.68.0.732560661241.issue22625@psf.upfronthosting.co.za>
Message-ID: <1461129022.22.0.395231188303.issue22625@psf.upfronthosting.co.za>


Martin Panter added the comment:

In Issue 22359, Xavier has posted a patch that looks like a reasonable solution to both cross compiling and allowing parallel make.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Remove incorrect uses of recursive make

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22625>
_______________________________________

From report at bugs.python.org  Wed Apr 20 01:18:02 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Apr 2016 05:18:02 +0000
Subject: [issue26806] IDLE not displaying RecursionError tracebacks
In-Reply-To: <1461105544.08.0.0145590373976.issue26806@psf.upfronthosting.co.za>
Message-ID: <1461129482.97.0.942504671692.issue26806@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In 3.6 just setting the recursion level to 20 produces following output on terminal:

----------------------------------------
Unhandled server exception!
Thread: SockThread
Client Address:  ('127.0.0.1', 41515)
Unhandled exception in thread started by 

and a hang.

In 2.7 it produces:

----------------------------------------
Unhandled server exception!
Thread: SockThread
Client Address:  ('127.0.0.1', 35043)
Request:  <socket._socketobject object at 0xb70e4a84>
Traceback (most recent call last):
  File "/home/serhiy/py/cpython-2.7-debug/Lib/SocketServer.py", line 290, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/home/serhiy/py/cpython-2.7-debug/Lib/SocketServer.py", line 318, in process_request
    self.finish_request(request, client_address)
  File "/home/serhiy/py/cpython-2.7-debug/Lib/SocketServer.py", line 331, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/home/serhiy/py/cpython-2.7-debug/Lib/idlelib/rpc.py", line 500, in __init__
    SocketServer.BaseRequestHandler.__init__(self, sock, addr, svr)
  File "/home/serhiy/py/cpython-2.7-debug/Lib/SocketServer.py", line 652, in __init__
    self.handle()
  File "/home/serhiy/py/cpython-2.7-debug/Lib/idlelib/run.py", line 292, in handle
    rpc.RPCHandler.getresponse(self, myseq=None, wait=0.05)
  File "/home/serhiy/py/cpython-2.7-debug/Lib/idlelib/rpc.py", line 280, in getresponse
    response = self._getresponse(myseq, wait)
  File "/home/serhiy/py/cpython-2.7-debug/Lib/idlelib/rpc.py", line 300, in _getresponse
    response = self.pollresponse(myseq, wait)
RuntimeError: maximum recursion depth exceeded

*** Unrecoverable, server exiting!
----------------------------------------

and restarts the shell.

Definitely the 20 limit is too low for IDLE.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26806>
_______________________________________

From report at bugs.python.org  Wed Apr 20 01:34:11 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 20 Apr 2016 05:34:11 +0000
Subject: [issue26804] Prioritize lowercase proxy variables in urllib.request
In-Reply-To: <1461053909.86.0.0123928931795.issue26804@psf.upfronthosting.co.za>
Message-ID: <1461130451.35.0.160315005412.issue26804@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Hi Hans-Peter,

I agree with Martin's comments and suggestion.

If I understand the suggestion correctly, the only change will be a documentation change. Isn't it? 

Because getproxies_environment() in it's current form already fetches the lower_case proxy which you want to highlight that is a winner in case there are two environment variables with different cases.

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26804>
_______________________________________

From report at bugs.python.org  Wed Apr 20 01:50:01 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Apr 2016 05:50:01 +0000
Subject: [issue26806] IDLE not displaying RecursionError tracebacks
In-Reply-To: <1461105544.08.0.0145590373976.issue26806@psf.upfronthosting.co.za>
Message-ID: <1461131401.7.0.705865771962.issue26806@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Experimentally found that minimal recursion level for 2.7 is 29, for 3.2-3.3 is 24, and for 3.4-3.6 is 25.

3.2 produces following output and restart the shell:

----------------------------------------
Unhandled server exception!
Thread: SockThread
Client Address:  ('127.0.0.1', 37227)
Request:  <socket.socket object, fd=3, family=2, type=1, proto=0>
Traceback (most recent call last):
  File "/home/serhiy/py/cpython-3.2/Lib/socketserver.py", line 295, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/home/serhiy/py/cpython-3.2/Lib/socketserver.py", line 321, in process_request
    self.finish_request(request, client_address)
  File "/home/serhiy/py/cpython-3.2/Lib/socketserver.py", line 334, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/home/serhiy/py/cpython-3.2/Lib/idlelib/rpc.py", line 503, in __init__
    socketserver.BaseRequestHandler.__init__(self, sock, addr, svr)
  File "/home/serhiy/py/cpython-3.2/Lib/socketserver.py", line 648, in __init__
    self.handle()
  File "/home/serhiy/py/cpython-3.2/Lib/idlelib/run.py", line 285, in handle
    rpc.RPCHandler.getresponse(self, myseq=None, wait=0.05)
  File "/home/serhiy/py/cpython-3.2/Lib/idlelib/rpc.py", line 280, in getresponse
    response = self._getresponse(myseq, wait)
  File "/home/serhiy/py/cpython-3.2/Lib/idlelib/rpc.py", line 300, in _getresponse
    response = self.pollresponse(myseq, wait)
  File "/home/serhiy/py/cpython-3.2/Lib/idlelib/rpc.py", line 421, in pollresponse
    self.putmessage(message)
  File "/home/serhiy/py/cpython-3.2/Lib/idlelib/rpc.py", line 324, in putmessage
    s = pickle.dumps(message)
RuntimeError: maximum recursion depth exceeded while pickling an object

*** Unrecoverable, server exiting!
----------------------------------------

3.3 hangs without any terminal output.

3.4 produces the most detailed output and hangs:

----------------------------------------
Unhandled server exception!
Thread: SockThread
Client Address:  ('127.0.0.1', 46394)
Request:  <socket.socket fd=6, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 48776), raddr=('127.0.0.1', 46394)>
Traceback (most recent call last):
Exception in thread SockThread:
Traceback (most recent call last):
  File "/home/serhiy/py/cpython-3.4/Lib/socketserver.py", line 305, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/home/serhiy/py/cpython-3.4/Lib/socketserver.py", line 331, in process_request
    self.finish_request(request, client_address)
  File "/home/serhiy/py/cpython-3.4/Lib/socketserver.py", line 344, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/home/serhiy/py/cpython-3.4/Lib/idlelib/rpc.py", line 508, in __init__
    socketserver.BaseRequestHandler.__init__(self, sock, addr, svr)
  File "/home/serhiy/py/cpython-3.4/Lib/socketserver.py", line 673, in __init__
    self.handle()
  File "/home/serhiy/py/cpython-3.4/Lib/idlelib/run.py", line 318, in handle
    rpc.RPCHandler.getresponse(self, myseq=None, wait=0.05)
  File "/home/serhiy/py/cpython-3.4/Lib/idlelib/rpc.py", line 288, in getresponse
    response = self._getresponse(myseq, wait)
  File "/home/serhiy/py/cpython-3.4/Lib/idlelib/rpc.py", line 308, in _getresponse
    response = self.pollresponse(myseq, wait)
  File "/home/serhiy/py/cpython-3.4/Lib/idlelib/rpc.py", line 426, in pollresponse
    self.putmessage(message)
  File "/home/serhiy/py/cpython-3.4/Lib/idlelib/rpc.py", line 332, in putmessage
    s = dumps(message)
  File "/home/serhiy/py/cpython-3.4/Lib/idlelib/rpc.py", line 60, in dumps
    p.dump(obj)
RuntimeError: maximum recursion depth exceeded while pickling an object

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/serhiy/py/cpython-3.4/Lib/threading.py", line 911, in _bootstrap_inner
    self.run()
  File "/home/serhiy/py/cpython-3.4/Lib/threading.py", line 859, in run
    self._target(*self._args, **self._kwargs)
  File "/home/serhiy/py/cpython-3.4/Lib/idlelib/run.py", line 162, in manage_socket
    server.handle_request() # A single request only
  File "/home/serhiy/py/cpython-3.4/Lib/socketserver.py", line 290, in handle_request
    self._handle_request_noblock()
  File "/home/serhiy/py/cpython-3.4/Lib/socketserver.py", line 307, in _handle_request_noblock
    self.handle_error(request, client_address)
  File "/home/serhiy/py/cpython-3.4/Lib/idlelib/run.py", line 288, in handle_error
    traceback.print_exc(file=erf)
  File "/home/serhiy/py/cpython-3.4/Lib/traceback.py", line 252, in print_exc
    print_exception(*sys.exc_info(), limit=limit, file=file, chain=chain)
  File "/home/serhiy/py/cpython-3.4/Lib/traceback.py", line 169, in print_exception
    for line in _format_exception_iter(etype, value, tb, limit, chain):
  File "/home/serhiy/py/cpython-3.4/Lib/traceback.py", line 153, in _format_exception_iter
    yield from _format_list_iter(_extract_tb_iter(tb, limit=limit))
  File "/home/serhiy/py/cpython-3.4/Lib/traceback.py", line 18, in _format_list_iter
    for filename, lineno, name, line in extracted_list:
  File "/home/serhiy/py/cpython-3.4/Lib/traceback.py", line 65, in _extract_tb_or_stack_iter
    line = linecache.getline(filename, lineno, f.f_globals)
  File "/home/serhiy/py/cpython-3.4/Lib/linecache.py", line 15, in getline
    lines = getlines(filename, module_globals)
  File "/home/serhiy/py/cpython-3.4/Lib/linecache.py", line 42, in getlines
    return updatecache(filename, module_globals)
  File "/home/serhiy/py/cpython-3.4/Lib/linecache.py", line 130, in updatecache
    with tokenize.open(fullname) as fp:
  File "/home/serhiy/py/cpython-3.4/Lib/tokenize.py", line 458, in open
    text = TextIOWrapper(buffer, encoding, line_buffering=True)
RuntimeError: maximum recursion depth exceeded

3.5 and 3.6 behaves as was described in msg263795.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26806>
_______________________________________

From report at bugs.python.org  Wed Apr 20 01:52:22 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 20 Apr 2016 05:52:22 +0000
Subject: [issue20116] urlparse.parse_qs should take argument for query
 separator
In-Reply-To: <1388777959.1.0.144368039339.issue20116@psf.upfronthosting.co.za>
Message-ID: <1461131542.9.0.938099488845.issue20116@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Luiz,

The original question was about introducing a parameter to override query string separate ';'.

If we do with enable or disable, then we should provide another option for query string separator.

The OP provided one example of query string which had & as a separator along with ';'. I wonder how the parsing of that should be.

The pointer to the RFC makes me think that is alright to provide an option to 'override' the default separator instead of providing an enable/disable.  

I would like to hear opposite thoughts on this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20116>
_______________________________________

From report at bugs.python.org  Wed Apr 20 02:15:35 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Apr 2016 06:15:35 +0000
Subject: [issue26780] Illustrate both binary operator conventions in PEP-8
In-Reply-To: <1460815604.66.0.184242188494.issue26780@psf.upfronthosting.co.za>
Message-ID: <20160420061532.26075.85780.3AC3293F@psf.io>


Roundup Robot added the comment:

New changeset 9afe77ad549b by Senthil Kumaran in branch 'default':
PEP-8 Update on Knuth style breaking of a long formula. #issue26780
https://hg.python.org/peps/rev/9afe77ad549b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26780>
_______________________________________

From report at bugs.python.org  Wed Apr 20 02:17:58 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 20 Apr 2016 06:17:58 +0000
Subject: [issue26780] Illustrate both binary operator conventions in PEP-8
In-Reply-To: <1460815604.66.0.184242188494.issue26780@psf.upfronthosting.co.za>
Message-ID: <1461133078.89.0.293396595427.issue26780@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

The patch is committed in changeset 9afe77ad549b.

Thanks for update Brandon. Citing the original source and stating the rationale for this suggestion was a great addition.

----------
nosy: +orsenthil
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26780>
_______________________________________

From report at bugs.python.org  Wed Apr 20 02:26:16 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 20 Apr 2016 06:26:16 +0000
Subject: [issue26804] Prioritize lowercase proxy variables in urllib.request
In-Reply-To: <1461053909.86.0.0123928931795.issue26804@psf.upfronthosting.co.za>
Message-ID: <1461133576.46.0.718174003287.issue26804@psf.upfronthosting.co.za>


Martin Panter added the comment:

It?s not just documentation, it is a real bug. If you run

http_proxy="" HTTP_PROXY=http://bad-proxy python . . .

the empty value of lowercase ?http_proxy? should have priority over the other one. At the moment it depends on the order of os.environ.items(), which I understand is random.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26804>
_______________________________________

From report at bugs.python.org  Wed Apr 20 03:06:58 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 20 Apr 2016 07:06:58 +0000
Subject: [issue26803] syslog logging handler fails with address in unix
 abstract namespace
In-Reply-To: <1461051316.11.0.100147214694.issue26803@psf.upfronthosting.co.za>
Message-ID: <1461136018.87.0.415916433082.issue26803@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

A unix abstract socket address is defined here:
    http://man7.org/linux/man-pages/man7/unix.7.html
as:

"Traditionally, UNIX domain sockets can be either unnamed, or bound to
a filesystem pathname (marked as being of type socket).  Linux also
supports an abstract namespace which is independent of the
filesystem."

and:

"abstract: an abstract socket address is distinguished (from a
pathname socket) by the fact that sun_path[0] is a null byte ('\0').
..."

It is also documented in the Python socket module documentation at
    https://docs.python.org/3/library/socket.html
and tested in the TestLinuxAbstractNamespace test of
Lib/test/test_socket.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26803>
_______________________________________

From report at bugs.python.org  Wed Apr 20 03:14:16 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 20 Apr 2016 07:14:16 +0000
Subject: [issue21668] The select and time modules uses libm functions without
 linking against it
In-Reply-To: <1401972993.52.0.304727515537.issue21668@psf.upfronthosting.co.za>
Message-ID: <1461136456.52.0.924635552986.issue21668@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The patch should be acknowledged in Misc/NEWS to Chi Hsuan Yen and not to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21668>
_______________________________________

From report at bugs.python.org  Wed Apr 20 03:17:06 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Apr 2016 07:17:06 +0000
Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError
In-Reply-To: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za>
Message-ID: <1461136626.96.0.52137153545.issue26801@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Left testing only the most common cases: sys.__stdout__ is None or is non a terminal.

----------
Added file: http://bugs.python.org/file42529/get_terminal_size_valueerror2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26801>
_______________________________________

From report at bugs.python.org  Wed Apr 20 03:33:28 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Apr 2016 07:33:28 +0000
Subject: [issue26800] Don't accept bytearray as filenames part 2
In-Reply-To: <1461015295.39.0.246147143774.issue26800@psf.upfronthosting.co.za>
Message-ID: <1461137608.5.0.876267858307.issue26800@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In the light of issue8485 this looks as a bug. Thank you for investigating this Philip.

I already raised this issue on Python-Dev less than a week ago [1], and only Victor had answered, thus we can assume that the consensus about bytes-like paths is not changed.

The only question is whether we need the deprecation period before removing the support of non-bytes bytes-like paths. Since they are supported during two major releases, and there are even tests for this support, I think that the deprecation period is needed. Third-party code written in last 3.5 years can use this feature.

[1] http://comments.gmane.org/gmane.comp.python.devel/157296

----------
nosy: +gvanrossum
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26800>
_______________________________________

From report at bugs.python.org  Wed Apr 20 03:38:51 2016
From: report at bugs.python.org (Hans-Peter Jansen)
Date: Wed, 20 Apr 2016 07:38:51 +0000
Subject: [issue26804] Prioritize lowercase proxy variables in urllib.request
In-Reply-To: <1461053909.86.0.0123928931795.issue26804@psf.upfronthosting.co.za>
Message-ID: <1461137931.81.0.46358314354.issue26804@psf.upfronthosting.co.za>


Hans-Peter Jansen added the comment:

Hi Martin, hi Senthil,

thanks for the valuable comments. 

Will incorporate your suggestions later today.

Yes, Martin, it's a bug, and should be fixed for 2.7 and 3.5 as well, but I was unsure, if I get some feedback at all... Hence, this is a very nice experience for me. 

I'm out for jogging now,
Pete

----------
versions: +Python 2.7, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26804>
_______________________________________

From report at bugs.python.org  Wed Apr 20 03:41:09 2016
From: report at bugs.python.org (Philip Jenvey)
Date: Wed, 20 Apr 2016 07:41:09 +0000
Subject: [issue26800] Don't accept bytearray as filenames part 2
In-Reply-To: <1461015295.39.0.246147143774.issue26800@psf.upfronthosting.co.za>
Message-ID: <1461138069.34.0.970180613012.issue26800@psf.upfronthosting.co.za>


Philip Jenvey added the comment:

Thanks Serhiy, I did not see the python-dev thread. This coincidentally came up recently in pypy3.

+1 for some kind of deprecation period needed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26800>
_______________________________________

From report at bugs.python.org  Wed Apr 20 03:48:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Apr 2016 07:48:40 +0000
Subject: [issue26802] Avoid copy in call_function_var when no extra stack args
 are passed
In-Reply-To: <1461028212.35.0.591299573852.issue26802@psf.upfronthosting.co.za>
Message-ID: <1461138520.66.0.914026125413.issue26802@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I was not sure about documenting this change in Misc/NEWS, but I think that it is not worth to mention it in What's New. This is very minor change. It's effect on any real code is negligible. I have pushed it only because it is trivial, unlikely has a negative effect, and there is a hope that the accumulated effect of several similar minor optimizations can be noticeable.

Simple refactoring or bug fix can have comparable performance effect on large program, but we don't mention this regression in What's New.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26802>
_______________________________________

From report at bugs.python.org  Wed Apr 20 03:55:49 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2016 07:55:49 +0000
Subject: [issue26802] Avoid copy in call_function_var when no extra stack args
 are passed
In-Reply-To: <1461028212.35.0.591299573852.issue26802@psf.upfronthosting.co.za>
Message-ID: <1461138949.86.0.68843593497.issue26802@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Serhiy: "I was not sure about documenting this change in Misc/NEWS, but I think that it is not worth to mention it in What's New. This is very minor change. It's effect on any real code is negligible. I have pushed it only because it is trivial, unlikely has a negative effect, and there is a hope that the accumulated effect of several similar minor optimizations can be noticeable."

I documented other similar optimizations which probably have a negligible effect. I also expect a visible effect when other optimizations are accumulated.

https://docs.python.org/dev/whatsnew/3.6.html#optimizations

It also a deliberate choice to document optimization. It's to communicate on the fact that we *are working* on performance. It looks like users are happy to see work done on this area:
https://twitter.com/TalkPython/status/720704770198126594/photo/1

The drawback is maybe that users may have too high expectations on these optimizations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26802>
_______________________________________

From report at bugs.python.org  Wed Apr 20 03:56:53 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2016 07:56:53 +0000
Subject: [issue26803] syslog logging handler fails with address in unix
 abstract namespace
In-Reply-To: <1461051316.11.0.100147214694.issue26803@psf.upfronthosting.co.za>
Message-ID: <1461139013.34.0.884610679377.issue26803@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ok. And what is the link between abstract namespace and the fact that the syslog handler gets bytes? Is it tested by your change?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26803>
_______________________________________

From report at bugs.python.org  Wed Apr 20 03:58:21 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Apr 2016 07:58:21 +0000
Subject: [issue21668] The select and time modules uses libm functions without
 linking against it
In-Reply-To: <1401972993.52.0.304727515537.issue21668@psf.upfronthosting.co.za>
Message-ID: <20160420075817.8324.35188.5D4BE3C2@psf.io>


Roundup Robot added the comment:

New changeset f76753f26982 by Victor Stinner in branch 'default':
Issue #21668: Fix author of the patch.
https://hg.python.org/cpython/rev/f76753f26982

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21668>
_______________________________________

From report at bugs.python.org  Wed Apr 20 04:02:13 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Apr 2016 08:02:13 +0000
Subject: [issue21668] The select and time modules uses libm functions without
 linking against it
In-Reply-To: <1401972993.52.0.304727515537.issue21668@psf.upfronthosting.co.za>
Message-ID: <20160420080209.401.65347.E445BFB9@psf.io>


Roundup Robot added the comment:

New changeset 7530caa5ed1a by Victor Stinner in branch 'default':
Issue #21668: Add also Chi Hsuan Yen to Misc/ACKS
https://hg.python.org/cpython/rev/7530caa5ed1a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21668>
_______________________________________

From report at bugs.python.org  Wed Apr 20 04:02:15 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2016 08:02:15 +0000
Subject: [issue21668] The select and time modules uses libm functions without
 linking against it
In-Reply-To: <1401972993.52.0.304727515537.issue21668@psf.upfronthosting.co.za>
Message-ID: <1461139335.66.0.598921542252.issue21668@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Xavier de Gaye: "The patch should be acknowledged in Misc/NEWS to Chi Hsuan Yen and not to me."

Oh sorry. I see 4 authors in attached patches, I picked the latest. Thank you to all authors for your contribution on this issue ;-) I fixed the author in Misc/NEWS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21668>
_______________________________________

From report at bugs.python.org  Wed Apr 20 04:18:03 2016
From: report at bugs.python.org (Robert Collins)
Date: Wed, 20 Apr 2016 08:18:03 +0000
Subject: [issue26807] mock_open()().readline() fails at EOF
Message-ID: <1461140283.7.0.219960203136.issue26807@psf.upfronthosting.co.za>


New submission from Robert Collins:

>>> import unittest.mock
>>> o = unittest.mock.mock_open(read_data="fred")
>>> f = o()
>>> f.read()
'fred'
>>> f.read()
''
>>> f.readlines()
[]
>>> f.readline()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/robertc/work/cpython/Lib/unittest/mock.py", line 935, in __call__
    return _mock_self._mock_call(*args, **kwargs)
  File "/home/robertc/work/cpython/Lib/unittest/mock.py", line 994, in _mock_call
    result = next(effect)
StopIteration

----------
components: Library (Lib)
messages: 263814
nosy: rbcollins
priority: normal
severity: normal
stage: test needed
status: open
title: mock_open()().readline() fails at EOF
type: behavior
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26807>
_______________________________________

From report at bugs.python.org  Wed Apr 20 05:59:54 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 20 Apr 2016 09:59:54 +0000
Subject: [issue22359] Remove incorrect uses of recursive make
In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za>
Message-ID: <1461146394.59.0.901814444659.issue22359@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Martin, thanks for the review and the suggestions.

The attached patch makes the following changes:
* do not modify the source files so as not to break builds made from
  read-only build sources (as per issue 15819)
* the cross-build copies the graminit.[ch] files to the build directory
* fix tab indentation

Patch tested by checking that the graminit.[ch] time stamps do not
change in the source directory afer a build and after a cross-build,
and by running the test suite both natively and on android emulator.

----------
Added file: http://bugs.python.org/file42530/crossbuild-sources-readonly.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22359>
_______________________________________

From report at bugs.python.org  Wed Apr 20 06:01:48 2016
From: report at bugs.python.org (jcristau)
Date: Wed, 20 Apr 2016 10:01:48 +0000
Subject: [issue25731] Assigning and deleting __new__ attr on the class does
 not allow to create instances of this class
In-Reply-To: <1448454590.41.0.350843358205.issue25731@psf.upfronthosting.co.za>
Message-ID: <1461146508.77.0.432086916143.issue25731@psf.upfronthosting.co.za>


jcristau added the comment:

Well yes, but as far as I can tell that's why python used B.__new__ for C before your change, as that has a compatible layout.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25731>
_______________________________________

From report at bugs.python.org  Wed Apr 20 06:28:42 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 20 Apr 2016 10:28:42 +0000
Subject: [issue26803] syslog logging handler fails with address in unix
 abstract namespace
In-Reply-To: <1461051316.11.0.100147214694.issue26803@psf.upfronthosting.co.za>
Message-ID: <1461148122.22.0.754712328998.issue26803@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The SysLogHandlerTest class instantiates a 'server_class' that eventually calls the
server_bind() method of the TCPServer class of the socketserver module.

This server_bind() method executes the statements:

    self.socket.bind(self.server_address)
    self.server_address = self.socket.getsockname()

and when self.server_address is a string and contains a null byte, then
getsockname() returns a bytes object.

So finally, self.server in SysLogHandlerTest is a bytes object in this case,
hence the needed to fix Lib/logging/handlers.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26803>
_______________________________________

From report at bugs.python.org  Wed Apr 20 06:46:18 2016
From: report at bugs.python.org (=?utf-8?b?0JDQu9C10LrRgdCw0L3QtNGAINCt0YDQuA==?=)
Date: Wed, 20 Apr 2016 10:46:18 +0000
Subject: [issue26717] wsgiref.simple_server: mojibake with cp1252 bytes in
 PATH_INFO
In-Reply-To: <1460148485.6.0.00224363970956.issue26717@psf.upfronthosting.co.za>
Message-ID: <1461149178.91.0.579920262353.issue26717@psf.upfronthosting.co.za>


????????? ??? added the comment:

Why wsgiref uses latin1? It must use utf-8.

----------
keywords: +patch
nosy: +????????? ???
Added file: http://bugs.python.org/file42531/simple_server.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26717>
_______________________________________

From report at bugs.python.org  Wed Apr 20 07:07:30 2016
From: report at bugs.python.org (Alexey Gorshkov)
Date: Wed, 20 Apr 2016 11:07:30 +0000
Subject: [issue26808] wsgiref.simple_server breaks unicode in URIs
Message-ID: <1461150450.27.0.360588809006.issue26808@psf.upfronthosting.co.za>


New submission from Alexey Gorshkov:

example code is in attachment

example URI is (for example): http://127.0.0.1:8005/????

----------
components: Extension Modules
files: t.py
messages: 263819
nosy: animus
priority: normal
severity: normal
status: open
title: wsgiref.simple_server breaks unicode in URIs
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file42532/t.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26808>
_______________________________________

From report at bugs.python.org  Wed Apr 20 07:10:30 2016
From: report at bugs.python.org (Alexey Gorshkov)
Date: Wed, 20 Apr 2016 11:10:30 +0000
Subject: [issue26808] wsgiref.simple_server breaks unicode in URIs
In-Reply-To: <1461150450.27.0.360588809006.issue26808@psf.upfronthosting.co.za>
Message-ID: <1461150630.97.0.887202254115.issue26808@psf.upfronthosting.co.za>


Changes by Alexey Gorshkov <animus at wayround.org>:


Added file: http://bugs.python.org/file42533/t.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26808>
_______________________________________

From report at bugs.python.org  Wed Apr 20 07:10:40 2016
From: report at bugs.python.org (Alexey Gorshkov)
Date: Wed, 20 Apr 2016 11:10:40 +0000
Subject: [issue26808] wsgiref.simple_server breaks unicode in URIs
In-Reply-To: <1461150450.27.0.360588809006.issue26808@psf.upfronthosting.co.za>
Message-ID: <1461150640.81.0.454525741143.issue26808@psf.upfronthosting.co.za>


Changes by Alexey Gorshkov <animus at wayround.org>:


Removed file: http://bugs.python.org/file42532/t.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26808>
_______________________________________

From report at bugs.python.org  Wed Apr 20 07:17:43 2016
From: report at bugs.python.org (=?utf-8?b?0JDQu9C10LrRgdCw0L3QtNGAINCt0YDQuA==?=)
Date: Wed, 20 Apr 2016 11:17:43 +0000
Subject: [issue26808] wsgiref.simple_server breaks unicode in URIs
In-Reply-To: <1461150450.27.0.360588809006.issue26808@psf.upfronthosting.co.za>
Message-ID: <1461151063.49.0.568804086216.issue26808@psf.upfronthosting.co.za>


????????? ??? added the comment:

look also #issue26717

----------
nosy: +????????? ???

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26808>
_______________________________________

From report at bugs.python.org  Wed Apr 20 07:21:53 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 20 Apr 2016 11:21:53 +0000
Subject: [issue26808] wsgiref.simple_server breaks unicode in URIs
In-Reply-To: <1461150450.27.0.360588809006.issue26808@psf.upfronthosting.co.za>
Message-ID: <1461151313.74.0.876826900594.issue26808@psf.upfronthosting.co.za>


SilentGhost added the comment:

What do you mean by "breaks"? Also, why do you encode your string as utf-8?

----------
components: +Library (Lib) -Extension Modules
nosy: +SilentGhost, orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26808>
_______________________________________

From report at bugs.python.org  Wed Apr 20 07:27:29 2016
From: report at bugs.python.org (Alexey Gorshkov)
Date: Wed, 20 Apr 2016 11:27:29 +0000
Subject: [issue26808] wsgiref.simple_server breaks unicode in URIs
In-Reply-To: <1461150450.27.0.360588809006.issue26808@psf.upfronthosting.co.za>
Message-ID: <1461151649.59.0.427332376928.issue26808@psf.upfronthosting.co.za>


Alexey Gorshkov added the comment:

take a look at 'pi:' result, please. - attaching screenshot

----------
Added file: http://bugs.python.org/file42534/Screenshot from 2016-04-20 14-26-03.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26808>
_______________________________________

From report at bugs.python.org  Wed Apr 20 07:28:31 2016
From: report at bugs.python.org (Alexey Gorshkov)
Date: Wed, 20 Apr 2016 11:28:31 +0000
Subject: [issue26808] wsgiref.simple_server breaks unicode in URIs
In-Reply-To: <1461150450.27.0.360588809006.issue26808@psf.upfronthosting.co.za>
Message-ID: <1461151711.71.0.355857156366.issue26808@psf.upfronthosting.co.za>


Alexey Gorshkov added the comment:

also attaching same print output in console

----------
Added file: http://bugs.python.org/file42535/Screenshot from 2016-04-20 14-28-03.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26808>
_______________________________________

From report at bugs.python.org  Wed Apr 20 07:36:22 2016
From: report at bugs.python.org (leewz)
Date: Wed, 20 Apr 2016 11:36:22 +0000
Subject: [issue26809] `string` exposes ChainMap from `collections`
Message-ID: <1461152182.96.0.373784885739.issue26809@psf.upfronthosting.co.za>


New submission from leewz:

I don't know if this kind of thing matters, but `from string import ChainMap` works (imports from `collections). It's used internally by `string`. This was done when ChainMap was made official:
https://github.com/python/cpython/commit/2886808d3809d69a6e9b360380080140b95df0b6#diff-4db7f78c8ac9907c7ad6231730d7900c

You can see in the above commit that `configparser` had `_ChainMap` changed to `ChainMap as _ChainMap`, but this was not done in `string`.

----------
components: Library (Lib)
messages: 263824
nosy: leewz
priority: normal
severity: normal
status: open
title: `string` exposes ChainMap from `collections`
type: behavior
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26809>
_______________________________________

From report at bugs.python.org  Wed Apr 20 07:48:58 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 20 Apr 2016 11:48:58 +0000
Subject: [issue26809] `string` exposes ChainMap from `collections`
In-Reply-To: <1461152182.96.0.373784885739.issue26809@psf.upfronthosting.co.za>
Message-ID: <1461152938.89.0.283182437057.issue26809@psf.upfronthosting.co.za>


SilentGhost added the comment:

I wouldn't say it matter, "from configparser import _ChainMap" works too, but that's just how imports work in Python. There is not reason to do what you've done on purpose - ChainMap is undocumented and is clearly just a detail of implementation.

The fact that ChainMap pollutes namespace when doing star import ("from string import *"), however, is unfortunate. I believe there was an issue around that was supposed to add missing __all__, but I'm not able to find that issue atm.

----------
nosy: +SilentGhost, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26809>
_______________________________________

From report at bugs.python.org  Wed Apr 20 08:24:40 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 20 Apr 2016 12:24:40 +0000
Subject: [issue20001] pathlib inheritance diagram too large
In-Reply-To: <1387221538.52.0.488414928183.issue20001@psf.upfronthosting.co.za>
Message-ID: <1461155080.64.0.12895080335.issue20001@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.5, Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20001>
_______________________________________

From report at bugs.python.org  Wed Apr 20 08:40:44 2016
From: report at bugs.python.org (Yolanda)
Date: Wed, 20 Apr 2016 12:40:44 +0000
Subject: [issue26807] mock_open()().readline() fails at EOF
In-Reply-To: <1461140283.7.0.219960203136.issue26807@psf.upfronthosting.co.za>
Message-ID: <1461156044.78.0.880052687968.issue26807@psf.upfronthosting.co.za>


Yolanda added the comment:

diff --git a/Lib/unittest/mock.py b/Lib/unittest/mock.py
index 7400fb7..9e47cd2 100644
--- a/Lib/unittest/mock.py
+++ b/Lib/unittest/mock.py
@@ -991,7 +991,10 @@ class CallableMixin(Base):
                 raise effect
 
             if not _callable(effect):
-                result = next(effect)
+                try:
+                    result = next(effect)
+                except StopIteration:
+                    result = None
                 if _is_exception(result):
                     raise result
                 if result is DEFAULT:

----------
nosy: +yolanda.robla

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26807>
_______________________________________

From report at bugs.python.org  Wed Apr 20 08:44:42 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 20 Apr 2016 12:44:42 +0000
Subject: [issue26808] wsgiref.simple_server breaks unicode in URIs
In-Reply-To: <1461150450.27.0.360588809006.issue26808@psf.upfronthosting.co.za>
Message-ID: <1461156282.16.0.563352132669.issue26808@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think this is already covered in Issue 16679. PEP 3333 says it?s meant to work this way.

I admit it is very quirky. See also Issue 22264 discussing future enhancements.

----------
nosy: +martin.panter
resolution:  -> duplicate
status: open -> closed
superseder:  -> Add advice about non-ASCII wsgiref PATH_INFO

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26808>
_______________________________________

From report at bugs.python.org  Wed Apr 20 09:01:58 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2016 13:01:58 +0000
Subject: [issue26803] syslog logging handler fails with address in unix
 abstract namespace
In-Reply-To: <1461148122.22.0.754712328998.issue26803@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwa+Bu2JOOsWHUYiocGYpnQVzSdyN2ttz5_Mjjn91aYg4w@mail.gmail.com>


STINNER Victor added the comment:

Xavier de Gaye added the comment:
> when self.server_address is a string and contains a null byte, then
> getsockname() returns a bytes object.

Ah? It sounds strange to me that the type of getsockname() depends on
the NULL byte. I would also expect a Unicode name for the abstract
namespace. What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26803>
_______________________________________

From report at bugs.python.org  Wed Apr 20 09:02:34 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 20 Apr 2016 13:02:34 +0000
Subject: [issue26809] `string` exposes ChainMap from `collections`
In-Reply-To: <1461152182.96.0.373784885739.issue26809@psf.upfronthosting.co.za>
Message-ID: <1461157354.85.0.901935526952.issue26809@psf.upfronthosting.co.za>


Martin Panter added the comment:

I agree that the namespace pollution is a valid bug. It affects ?from string import *? and dir(string). Normally, modules either define __all__ listing their exported names, or they are really careful to define non-exported names beginning with underscores (_). Judging by the line ?import re as _re?, somebody once tried to use the second technique for the ?string? module.

Silent Ghost: perhaps you were thinking of Issue 23883 (adding to __all__ in various modules). This case is the opposite: we want to limit the exported names.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26809>
_______________________________________

From report at bugs.python.org  Wed Apr 20 09:07:12 2016
From: report at bugs.python.org (=?utf-8?b?0JDQu9C10LrRgdCw0L3QtNGAINCt0YDQuA==?=)
Date: Wed, 20 Apr 2016 13:07:12 +0000
Subject: [issue26808] wsgiref.simple_server breaks unicode in URIs
In-Reply-To: <1461150450.27.0.360588809006.issue26808@psf.upfronthosting.co.za>
Message-ID: <1461157632.39.0.966763171667.issue26808@psf.upfronthosting.co.za>


????????? ??? added the comment:

My browser encodes url in utf-8. To resolve this bug we need to look in web standards, not in pep.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26808>
_______________________________________

From report at bugs.python.org  Wed Apr 20 09:07:53 2016
From: report at bugs.python.org (leewz)
Date: Wed, 20 Apr 2016 13:07:53 +0000
Subject: [issue26809] `string` exposes ChainMap from `collections`
In-Reply-To: <1461152182.96.0.373784885739.issue26809@psf.upfronthosting.co.za>
Message-ID: <1461157673.27.0.0775942749809.issue26809@psf.upfronthosting.co.za>


leewz added the comment:

> The fact that ChainMap pollutes namespace when doing star import ("from string import *"), however, is unfortunate.

This is what I meant by "this kind of thing". (IPython also ignores underscored names for autocomplete suggestions, unless you start with an underscore. IPython doesn't respect `__all__` by default, but that's a report for IPython's tracker.)


> This case is the opposite: we want to limit the exported names.

(Well, not exactly the opposite. Same purpose.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26809>
_______________________________________

From report at bugs.python.org  Wed Apr 20 09:10:46 2016
From: report at bugs.python.org (leewz)
Date: Wed, 20 Apr 2016 13:10:46 +0000
Subject: [issue26809] `string` exposes ChainMap from `collections`
In-Reply-To: <1461152182.96.0.373784885739.issue26809@psf.upfronthosting.co.za>
Message-ID: <1461157846.86.0.184578371493.issue26809@psf.upfronthosting.co.za>


leewz added the comment:

(Never mind that last bit. I see it now.)

> I agree that the namespace pollution is a valid bug. It affects ?from string import *? and dir(string).

How do I get this behavior for `dir`? I get '_re' in `dir(string)`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26809>
_______________________________________

From report at bugs.python.org  Wed Apr 20 09:14:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 20 Apr 2016 13:14:35 +0000
Subject: [issue26809] `string` exposes ChainMap from `collections`
In-Reply-To: <1461152182.96.0.373784885739.issue26809@psf.upfronthosting.co.za>
Message-ID: <1461158075.01.0.741620604767.issue26809@psf.upfronthosting.co.za>


Martin Panter added the comment:

Okay looks like I was mistaken about dir(). It ignores __all__, and just gives you everything. But the star-import point is still valid :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26809>
_______________________________________

From report at bugs.python.org  Wed Apr 20 09:22:52 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Wed, 20 Apr 2016 13:22:52 +0000
Subject: [issue26809] `string` exposes ChainMap from `collections`
In-Reply-To: <1461152182.96.0.373784885739.issue26809@psf.upfronthosting.co.za>
Message-ID: <1461158572.39.0.508185203932.issue26809@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Patch fixes this the proper way by defining __all__ in the string module.

----------
keywords: +patch
nosy: +ebarry
Added file: http://bugs.python.org/file42536/string___all__.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26809>
_______________________________________

From report at bugs.python.org  Wed Apr 20 09:26:22 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 20 Apr 2016 13:26:22 +0000
Subject: [issue26809] `string` exposes ChainMap from `collections`
In-Reply-To: <1461152182.96.0.373784885739.issue26809@psf.upfronthosting.co.za>
Message-ID: <1461158782.34.0.768420989424.issue26809@psf.upfronthosting.co.za>


SilentGhost added the comment:

> Silent Ghost: perhaps you were thinking of Issue 23883 (adding to __all__ in various modules). This case is the opposite: we want to limit the exported names.

It was one of mine, issue 10895. Been dead for a while now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26809>
_______________________________________

From report at bugs.python.org  Wed Apr 20 09:33:42 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Wed, 20 Apr 2016 13:33:42 +0000
Subject: [issue26809] `string` exposes ChainMap from `collections`
In-Reply-To: <1461152182.96.0.373784885739.issue26809@psf.upfronthosting.co.za>
Message-ID: <1461159222.33.0.311346141625.issue26809@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Thanks SilentGhost, seems my brain decided not to see uppercase names :) Attached patch adds Formatter and Template as well.

----------
Added file: http://bugs.python.org/file42537/string___all___2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26809>
_______________________________________

From report at bugs.python.org  Wed Apr 20 09:45:49 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 20 Apr 2016 13:45:49 +0000
Subject: [issue26803] syslog logging handler fails with address in unix
 abstract namespace
In-Reply-To: <1461051316.11.0.100147214694.issue26803@psf.upfronthosting.co.za>
Message-ID: <1461159949.57.0.242141909274.issue26803@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

makesockaddr() in socketmodule.c calls PyBytes_FromStringAndSize() when the
first byte is a null byte.

My opinion is not worth much in this matter :). The socket documentation does
say that AF_UNIX addresses are "represented as a string, using the file system
encoding", so the implementation looks wrong. However it is possible that
PyUnicode_DecodeFSDefault() fails for some file system encodings when the
encoded address contains null bytes ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26803>
_______________________________________

From report at bugs.python.org  Wed Apr 20 09:49:01 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2016 13:49:01 +0000
Subject: [issue26803] syslog logging handler fails with address in unix
 abstract namespace
In-Reply-To: <1461051316.11.0.100147214694.issue26803@psf.upfronthosting.co.za>
Message-ID: <1461160141.91.0.971562977542.issue26803@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> However it is possible that
PyUnicode_DecodeFSDefault() fails for some file system encodings when the
encoded address contains null bytes ?

No, it's not possible. Undecode bytes are escaped as surrogate characters using the surrogateescape error handler. See the PEP 393.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26803>
_______________________________________

From report at bugs.python.org  Wed Apr 20 09:56:01 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 20 Apr 2016 13:56:01 +0000
Subject: [issue26803] syslog logging handler fails with address in unix
 abstract namespace
In-Reply-To: <1461051316.11.0.100147214694.issue26803@psf.upfronthosting.co.za>
Message-ID: <1461160561.4.0.256255488008.issue26803@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Then it seems that makesockaddr() should be fixed instead of the logging
handler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26803>
_______________________________________

From report at bugs.python.org  Wed Apr 20 09:57:23 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2016 13:57:23 +0000
Subject: [issue26803] syslog logging handler fails with address in unix
 abstract namespace
In-Reply-To: <1461051316.11.0.100147214694.issue26803@psf.upfronthosting.co.za>
Message-ID: <1461160643.11.0.250806807045.issue26803@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Then it seems that makesockaddr() should be fixed instead of the logging handler.

Yes. That's why I didn't understand the issue at the beginning :-) Would you like to work on fixing the _socket module?

It may be worth to keep your syslog unit test. It's up to you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26803>
_______________________________________

From report at bugs.python.org  Wed Apr 20 10:03:58 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 20 Apr 2016 14:03:58 +0000
Subject: [issue26803] syslog logging handler fails with address in unix
 abstract namespace
In-Reply-To: <1461051316.11.0.100147214694.issue26803@psf.upfronthosting.co.za>
Message-ID: <1461161038.91.0.249412677473.issue26803@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

I will give it a try.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26803>
_______________________________________

From report at bugs.python.org  Wed Apr 20 10:08:42 2016
From: report at bugs.python.org (Luiz Poleto)
Date: Wed, 20 Apr 2016 14:08:42 +0000
Subject: [issue20116] urlparse.parse_qs should take argument for query
 separator
In-Reply-To: <1461131542.9.0.938099488845.issue20116@psf.upfronthosting.co.za>
Message-ID: <CAHFUrke1dFKBco3hxNDxNUUYgZob89dG15TtTdREKMwTXVE1GQ@mail.gmail.com>


Luiz Poleto added the comment:

Based on the example provided by the OP, it appears that he would expect
the output to be:
{'family': ['citrus'], 'fruits': ['lemon;lime']}

Since the W3C recommendation for the application/x-www-form-urlencoded type
specify using '&' to separate the parameters in the query string (';' is
not mentioned there), I recommended a parameter for disabling the use of
';' as a separator (but '&' will still be the separator to be used).

The only thing I see against using the RFC is that although it specifies
which characters are valid in a query string, it does not define how they
should be used; that is done by W3C's application/x-www-form-urlencoded and
it is very specific about using '&' as a separator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20116>
_______________________________________

From report at bugs.python.org  Wed Apr 20 10:16:35 2016
From: report at bugs.python.org (Ruben D. Orduz)
Date: Wed, 20 Apr 2016 14:16:35 +0000
Subject: [issue20116] urlparse.parse_qs should take argument for query
 separator
In-Reply-To: <1388777959.1.0.144368039339.issue20116@psf.upfronthosting.co.za>
Message-ID: <1461161795.05.0.0898422911738.issue20116@psf.upfronthosting.co.za>


Ruben D. Orduz added the comment:

Hi all,

OP here. My intent was to optionally pass a separator parameter, _not_ enable/disable toggle.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20116>
_______________________________________

From report at bugs.python.org  Wed Apr 20 10:24:22 2016
From: report at bugs.python.org (Roman Evstifeev)
Date: Wed, 20 Apr 2016 14:24:22 +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: <1461162262.88.0.756861772012.issue23496@psf.upfronthosting.co.za>


Changes by Roman Evstifeev <someuniquename at gmail.com>:


----------
nosy: +Roman.Evstifeev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Wed Apr 20 10:34:55 2016
From: report at bugs.python.org (Anthony Sottile)
Date: Wed, 20 Apr 2016 14:34:55 +0000
Subject: [issue26717] wsgiref.simple_server: mojibake with cp1252 bytes in
 PATH_INFO
In-Reply-To: <1461149178.91.0.579920262353.issue26717@psf.upfronthosting.co.za>
Message-ID: <CA+dzEB=neMXB8LWcNum+MOAQ+UcQFzVQ9uE3C35J4XG27b=2tA@mail.gmail.com>


Anthony Sottile added the comment:

PEP3333 states that environ variables are str variables decoded using
latin1:
https://www.python.org/dev/peps/pep-3333/#id19

Therefore, to get the original bytes, one must encode using latin1
On Apr 20, 2016 3:46 AM, "????????? ???" <report at bugs.python.org> wrote:

>
> ????????? ??? added the comment:
>
> Why wsgiref uses latin1? It must use utf-8.
>
> ----------
> keywords: +patch
> nosy: +????????? ???
> Added file: http://bugs.python.org/file42531/simple_server.py.diff
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue26717>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26717>
_______________________________________

From report at bugs.python.org  Wed Apr 20 11:50:47 2016
From: report at bugs.python.org (Thomas)
Date: Wed, 20 Apr 2016 15:50:47 +0000
Subject: [issue26799] gdb support fails with "Invalid cast."
In-Reply-To: <1461013840.26.0.744881925452.issue26799@psf.upfronthosting.co.za>
Message-ID: <1461167447.57.0.943813383738.issue26799@psf.upfronthosting.co.za>


Thomas added the comment:

The second option seems like the safest choice, attached is a patch that addresses just that.

----------
keywords: +patch
Added file: http://bugs.python.org/file42538/gdb-python-invalid-cast.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26799>
_______________________________________

From report at bugs.python.org  Wed Apr 20 12:04:28 2016
From: report at bugs.python.org (unsec treedee)
Date: Wed, 20 Apr 2016 16:04:28 +0000
Subject: [issue26810] inconsistent garbage collector behavior across platforms
 when using ctypes data-structures
Message-ID: <1461168268.36.0.0880478693475.issue26810@psf.upfronthosting.co.za>


New submission from unsec treedee:

The garbage collector is not behaving consistently across platforms for python 2.7.11.

I realize that the example code and style is not proper :-)

On the Mac OSX platform this code runs without the garbage collector "cleaning house" and there is no resulting crash from a NULL pointer.  On the Linux platform the garbage collector decides to "clean house" (deallocates the object) resulting in a NULL pointer which is not handled correctly by the c-function code (some legacy stuff) and causes a segmentation fault.

Temporarily disabling the garbage collector and enabling it later on allows a workaround (valid or not) that is consistent on all platforms.

Improper coding and style aside... the issue I am reporting is the inconsistent behaviour of the garbage collector.  I am looking for consistency across platforms (same result on all platforms).  :-)

----------
components: ctypes
files: gc_snippet_report_pybug.py
messages: 263846
nosy: unsec treedee
priority: normal
severity: normal
status: open
title: inconsistent garbage collector behavior across platforms when using ctypes data-structures
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file42539/gc_snippet_report_pybug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26810>
_______________________________________

From report at bugs.python.org  Wed Apr 20 12:05:32 2016
From: report at bugs.python.org (Roman Evstifeev)
Date: Wed, 20 Apr 2016 16:05:32 +0000
Subject: [issue2636] Adding a new regex module (compatible with re)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1461168332.58.0.14105195124.issue2636@psf.upfronthosting.co.za>


Changes by Roman Evstifeev <someuniquename at gmail.com>:


----------
nosy: +Roman.Evstifeev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Wed Apr 20 12:13:38 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 20 Apr 2016 16:13:38 +0000
Subject: [issue26810] inconsistent garbage collector behavior across platforms
 when using ctypes data-structures
In-Reply-To: <1461168268.36.0.0880478693475.issue26810@psf.upfronthosting.co.za>
Message-ID: <1461168818.97.0.806532479612.issue26810@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +amaury.forgeotdarc, belopolsky, meador.inge, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26810>
_______________________________________

From report at bugs.python.org  Wed Apr 20 12:15:15 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Apr 2016 16:15:15 +0000
Subject: [issue26799] gdb support fails with "Invalid cast."
In-Reply-To: <1461013840.26.0.744881925452.issue26799@psf.upfronthosting.co.za>
Message-ID: <20160420161500.48684.52345.ADA9247B@psf.io>


Roundup Robot added the comment:

New changeset e1c6f8895fd8 by Victor Stinner in branch '3.5':
python-gdb.py: get C types at runtime
https://hg.python.org/cpython/rev/e1c6f8895fd8

New changeset 6425728d8dc6 by Victor Stinner in branch 'default':
Merge 3.5: Issue #26799
https://hg.python.org/cpython/rev/6425728d8dc6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26799>
_______________________________________

From report at bugs.python.org  Wed Apr 20 12:24:10 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Apr 2016 16:24:10 +0000
Subject: [issue26799] gdb support fails with "Invalid cast."
In-Reply-To: <1461013840.26.0.744881925452.issue26799@psf.upfronthosting.co.za>
Message-ID: <20160420162407.12753.10648.346034A1@psf.io>


Roundup Robot added the comment:

New changeset e4561aad29e6 by Victor Stinner in branch '2.7':
Fix python-gdb.py: get C types on demand
https://hg.python.org/cpython/rev/e4561aad29e6

New changeset 952c89a10be6 by Victor Stinner in branch '3.5':
Issue #26799: Fix typo in Misc/NEWS
https://hg.python.org/cpython/rev/952c89a10be6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26799>
_______________________________________

From report at bugs.python.org  Wed Apr 20 12:28:59 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Apr 2016 16:28:59 +0000
Subject: [issue26799] gdb support fails with "Invalid cast."
In-Reply-To: <1461013840.26.0.744881925452.issue26799@psf.upfronthosting.co.za>
Message-ID: <1461169739.56.0.275313412404.issue26799@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The second option seems like the safest choice, attached is a patch that addresses just that.

Thanks, I applied your patch (your a bugfix, you forgot one "return" ;-)).

I also inlined _type_void_ptr() into _sizeof_void_p(), since it was only called there.

Thanks for your bug report and your patch.

Can you please sign the PSF Contributor Agreement? https://www.python.org/psf/contrib/contrib-form/

It's required when you contribute to Python. In short, it warns you that Python is free software ;-)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26799>
_______________________________________

From report at bugs.python.org  Wed Apr 20 12:37:43 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Apr 2016 16:37:43 +0000
Subject: [issue26809] `string` exposes ChainMap from `collections`
In-Reply-To: <1461152182.96.0.373784885739.issue26809@psf.upfronthosting.co.za>
Message-ID: <1461170263.18.0.115019930213.issue26809@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Judging by the line ?import re as _re?, somebody once tried to use the second technique for the ?string? module.

So I think it is preferable to use this technique for ChainMap.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26809>
_______________________________________

From report at bugs.python.org  Wed Apr 20 12:46:44 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Wed, 20 Apr 2016 16:46:44 +0000
Subject: [issue26809] `string` exposes ChainMap from `collections`
In-Reply-To: <1461152182.96.0.373784885739.issue26809@psf.upfronthosting.co.za>
Message-ID: <1461170804.24.0.287854490262.issue26809@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

I added an underscore in front of ChainMap, but I kept the __all__ definition because I think it should be there regardless (like every module, basically).

----------
Added file: http://bugs.python.org/file42540/ChainMap___all__.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26809>
_______________________________________

From report at bugs.python.org  Wed Apr 20 12:46:58 2016
From: report at bugs.python.org (leewz)
Date: Wed, 20 Apr 2016 16:46:58 +0000
Subject: [issue26809] `string` exposes ChainMap from `collections`
In-Reply-To: <1461152182.96.0.373784885739.issue26809@psf.upfronthosting.co.za>
Message-ID: <1461170818.93.0.257326593657.issue26809@psf.upfronthosting.co.za>


leewz added the comment:

Why not both?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26809>
_______________________________________

From report at bugs.python.org  Wed Apr 20 12:49:11 2016
From: report at bugs.python.org (Roman Evstifeev)
Date: Wed, 20 Apr 2016 16:49:11 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1461170951.16.0.544430187508.issue15873@psf.upfronthosting.co.za>


Changes by Roman Evstifeev <someuniquename at gmail.com>:


----------
nosy: +Roman.Evstifeev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Wed Apr 20 12:54:38 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Wed, 20 Apr 2016 16:54:38 +0000
Subject: [issue26809] `string` exposes ChainMap from `collections`
In-Reply-To: <1461152182.96.0.373784885739.issue26809@psf.upfronthosting.co.za>
Message-ID: <1461171278.62.0.32787270434.issue26809@psf.upfronthosting.co.za>


Changes by Emanuel Barry <barry at dadadata.net>:


Added file: http://bugs.python.org/file42541/ChainMap___all___2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26809>
_______________________________________

From report at bugs.python.org  Wed Apr 20 13:24:32 2016
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 20 Apr 2016 17:24:32 +0000
Subject: [issue26798] add BLAKE2 to hashlib
In-Reply-To: <1461004812.44.0.872226457841.issue26798@psf.upfronthosting.co.za>
Message-ID: <1461173072.2.0.856049583165.issue26798@psf.upfronthosting.co.za>


Christian Heimes added the comment:

First experimental version of blake2b and blake2s for Python 3.6:
https://github.com/tiran/cpython/commits/feature/blake2

The code is based on Dmitry Chestnykh's pyblake2 but modified to support argument clinic. I had to replace the macro magic with plain C code. The clinic is not able to deal with the macros. blake2s.c is auto-generated from blake2b.c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26798>
_______________________________________

From report at bugs.python.org  Wed Apr 20 14:17:42 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Apr 2016 18:17:42 +0000
Subject: [issue26806] IDLE not displaying RecursionError tracebacks
In-Reply-To: <1461105544.08.0.0145590373976.issue26806@psf.upfronthosting.co.za>
Message-ID: <1461176262.33.0.85724936658.issue26806@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Thanks for the investigation.  I copied the limit from a python-ideas example and did not realize that IDLE adds so much to the call stack.  I should add a bit on the subject to the IDLE doc in "3.2. IDLE-console differences".  (It can also impact tracebacks -- as reported on a couple of tracker issues.)

"IDLE adds it own calls to the call stack before (and possibly after) running user code.  Tracebacks are filtered to remove these, but the filtering may not be perfect.  Setting a recursion limit that is too low, such as with sys.setrecursionlimit(20), will result in mysterious malfunctions."

----------
components: +Documentation, IDLE
stage: test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26806>
_______________________________________

From report at bugs.python.org  Wed Apr 20 14:35:46 2016
From: report at bugs.python.org (Alessandro Cucci)
Date: Wed, 20 Apr 2016 18:35:46 +0000
Subject: [issue14102] argparse: add ability to create a man page
In-Reply-To: <1330031760.56.0.8938390885.issue14102@psf.upfronthosting.co.za>
Message-ID: <1461177346.09.0.550273205883.issue14102@psf.upfronthosting.co.za>


Alessandro Cucci added the comment:

I would like to work on a patch if nobody currently are working on it. I'll keep you updated

----------
nosy: +acucci

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14102>
_______________________________________

From report at bugs.python.org  Wed Apr 20 14:47:26 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Apr 2016 18:47:26 +0000
Subject: [issue26806] IDLE not displaying RecursionError tracebacks
In-Reply-To: <1461105544.08.0.0145590373976.issue26806@psf.upfronthosting.co.za>
Message-ID: <1461178046.79.0.860560273192.issue26806@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

We can monkeypatch sys.setrecursionlimit() to set recursion limit to at least say 50.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26806>
_______________________________________

From report at bugs.python.org  Wed Apr 20 15:00:33 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 20 Apr 2016 19:00:33 +0000
Subject: [issue26803] syslog logging handler fails with address in unix
 abstract namespace
In-Reply-To: <1461051316.11.0.100147214694.issue26803@psf.upfronthosting.co.za>
Message-ID: <1461178833.11.0.891459958587.issue26803@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Here is the patch.

As a  reference, issue #8373 with changeset 1f23bb74f4bc changed the AF_UNIX
socket addresses encoding from UTF-8 to the file system encoding and the
'surrogateescape' error handler (PEP 383).

----------
Added file: http://bugs.python.org/file42542/unix_abstract_namespace_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26803>
_______________________________________

From report at bugs.python.org  Wed Apr 20 15:12:19 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 20 Apr 2016 19:12:19 +0000
Subject: [issue26803] syslog logging handler fails with address in unix
 abstract namespace
In-Reply-To: <1461051316.11.0.100147214694.issue26803@psf.upfronthosting.co.za>
Message-ID: <1461179539.26.0.374926832453.issue26803@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

This patch corrects the non-ascii quote character in the Misc/NEWS diff.

----------
Added file: http://bugs.python.org/file42543/unix_abstract_namespace_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26803>
_______________________________________

From report at bugs.python.org  Wed Apr 20 15:13:46 2016
From: report at bugs.python.org (Hans-Peter Jansen)
Date: Wed, 20 Apr 2016 19:13:46 +0000
Subject: [issue26804] Prioritize lowercase proxy variables in urllib.request
In-Reply-To: <1461053909.86.0.0123928931795.issue26804@psf.upfronthosting.co.za>
Message-ID: <1461179626.31.0.459225987864.issue26804@psf.upfronthosting.co.za>


Hans-Peter Jansen added the comment:

Hi Martin, hi Senthil,

please find a new patch attached, that incorporates your suggestions.

 * added a comment to get_proxies doc in urllib.rst
 * documented and fixed the mixed case scheme 
 * added a note to proxy_bypass_environment, that behaves slightly 
   different in this respect

Yes, mixed case situations are not handled in proxy_bypass_environment,
just lowercase and uppercase, while lowercase is preferred correctly.
I think, that the mixed case situation is pathologic enough and deserves to be ignored here. 

BTW, while looking at the code, I noticed, that most docstrings of the callers of proxy_bypass_environment are wrong: they say, that the proxies dict is returned, but they return the value of proxy_bypass_environment(), not get_proxies().

A follow up patch could do this in order to clean up this mess:
since there's always a call to get_proxies preceding the call to proxy_bypass_environment, we could add a second argument to the latter, passing in the proxy dict, that is thrown away at the moment. Since that carries a 'no' key already, if it exists, using it here would fix this ambiguity. While at it, fix up the affected docstrings.

What do you think about the attached patch and the last paragraph?

----------
Added file: http://bugs.python.org/file42544/python-urllib-prefer-lowercase-proxies.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26804>
_______________________________________

From report at bugs.python.org  Wed Apr 20 16:20:09 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Apr 2016 20:20:09 +0000
Subject: [issue26806] IDLE not displaying RecursionError tracebacks
In-Reply-To: <1461105544.08.0.0145590373976.issue26806@psf.upfronthosting.co.za>
Message-ID: <1461183609.61.0.881469081182.issue26806@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Interesting idea.  We avoid the problem by adding something like the following to run.py

_setrecursionlimit = sys.setrecursionlimit
def setrecursionlimit(n):
    _setrecursionlimit(max(n, 50))
sys.setrecursionlimit = setrecursionlimit

This works when entered interactively, and I presume it would within run.py.  For _setrecursionlimit to be accessible from user code (to reverse the monkey patching), it would have to be attached to the function as an attribute.

setrecursionlimit.original = _setrecursionlimit

Though user-friendly for most users, this would make IDLE execute code differently from raw Python.  The builtin has a lower limit, based on the current stack depth, but it raises instead of setting a higher limit.  I presume we could use len(inspect.stack()) to get the current 'recursion depth', and add, say, 30 rather than 3. (The current error message could be more helpful.)

>>> sys.setrecursionlimit(3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RecursionError: cannot set the recursion limit to 3 at the recursion depth 1: the limit is too low
>>> sys.setrecursionlimit(4)
>>> f()
>>>
>>> def f():
...   print('f')
...   f()
...
>>> f()
>>>

The call to f seems to be silently ignored.  This does not seem helpful.

Whatever we do, I would mention it in a revision of the proposed paragraph above.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26806>
_______________________________________

From report at bugs.python.org  Wed Apr 20 16:35:03 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Wed, 20 Apr 2016 20:35:03 +0000
Subject: [issue26781] os.walk max_depth
In-Reply-To: <1460815870.93.0.432472188169.issue26781@psf.upfronthosting.co.za>
Message-ID: <1461184503.26.0.00172424656857.issue26781@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

I am not sure about the wide use of this feature but I do think this is a nice feature to add to os.walk. I can see how you can implement is_too_deep by counting the number of separators in the path. However I don't think it is trivial to do that. In addition doing the same when topdown is False will not work.
As for the other limitations you suggested I think they are less trivial then limiting the recursion depth.

As for the "symlink infinite loop" I agree that it will be better to do that by tracking the paths we have already visited but avoiding infinite loop is just a bonus that you get from this feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26781>
_______________________________________

From report at bugs.python.org  Wed Apr 20 17:17:37 2016
From: report at bugs.python.org (Alexey Gorshkov)
Date: Wed, 20 Apr 2016 21:17:37 +0000
Subject: [issue16679] Add advice about non-ASCII wsgiref PATH_INFO
In-Reply-To: <1355473710.36.0.278942451351.issue16679@psf.upfronthosting.co.za>
Message-ID: <1461187057.44.0.372042694904.issue16679@psf.upfronthosting.co.za>


Alexey Gorshkov added the comment:

I'm from Issue 26808. I'd like to see some explanation on: how about QUERY_STRING value? Why only PATH_INFO is encoded in such a manner, but QUERY_STRING is passed without any changes and does not requires any latin-1 to utf-8 recodings?

----------
nosy: +animus

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16679>
_______________________________________

From report at bugs.python.org  Wed Apr 20 19:27:40 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 20 Apr 2016 23:27:40 +0000
Subject: [issue26810] inconsistent garbage collector behavior across platforms
 when using ctypes data-structures
In-Reply-To: <1461168268.36.0.0880478693475.issue26810@psf.upfronthosting.co.za>
Message-ID: <1461194860.42.0.236964291369.issue26810@psf.upfronthosting.co.za>


Martin Panter added the comment:

You should write your program so that it does not release objects until they are no longer needed, then it can handle the garbage collector running at any time. But it is not clear to me what your offending null pointer is. Your code has lots of pointers that could be null.

Can you provide a complete demonstration, perhaps using a standard function such as libc.printf, rather than your arbitrary function?

----------
nosy: +martin.panter
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26810>
_______________________________________

From report at bugs.python.org  Wed Apr 20 19:45:50 2016
From: report at bugs.python.org (Alexander Mohr)
Date: Wed, 20 Apr 2016 23:45:50 +0000
Subject: [issue23236] asyncio: add timeout to StreamReader read methods
In-Reply-To: <1421196508.1.0.44699876054.issue23236@psf.upfronthosting.co.za>
Message-ID: <1461195950.85.0.385843846186.issue23236@psf.upfronthosting.co.za>


Alexander Mohr added the comment:

any updates on this?  I think this would be perfect for https://github.com/aio-libs/aiobotocore/issues/31

----------
nosy: +thehesiod

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23236>
_______________________________________

From report at bugs.python.org  Wed Apr 20 20:09:08 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Apr 2016 00:09:08 +0000
Subject: [issue26530] tracemalloc: add C API to manually track/untrack memory
 allocations
In-Reply-To: <1457619430.68.0.0968942184372.issue26530@psf.upfronthosting.co.za>
Message-ID: <1461197348.24.0.851642329149.issue26530@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Nathaniel, Antoine: ping?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26530>
_______________________________________

From report at bugs.python.org  Wed Apr 20 20:20:16 2016
From: report at bugs.python.org (random832)
Date: Thu, 21 Apr 2016 00:20:16 +0000
Subject: [issue26811] segfault due to null pointer in tuple
Message-ID: <1461198016.05.0.40690695807.issue26811@psf.upfronthosting.co.za>


New submission from random832:

I was writing something that iterates over all objects in gc.get_objects(). I don't know precisely where the offending tuple is coming from, but nearby objects in gc.get_objects() appear to be related to frozen_importlib.

A tuple exists somewhere with a null pointer in it. Attempting to iterate over it or access its item results in a segmentation fault.

I confirmed this on both Linux and OSX.

Python 3.6.0a0 (default:778ccbe3cf74, Apr 20 2016, 20:17:38)

----------
components: Interpreter Core
files: fnt.py
messages: 263866
nosy: random832
priority: normal
severity: normal
status: open
title: segfault due to null pointer in tuple
versions: Python 3.6
Added file: http://bugs.python.org/file42545/fnt.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26811>
_______________________________________

From report at bugs.python.org  Wed Apr 20 21:08:37 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 21 Apr 2016 01:08:37 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1461200917.08.0.232124616519.issue15873@psf.upfronthosting.co.za>


Martin Panter added the comment:

If you decide to only do a Python implementation, the main reason to write a wrapper in C would be because the datetime class is defined in C. Similar to how the datetime_strptime() function in Modules/_datetimemodule.c imports and calls _strptime._strptime_datetime().

An alternative might be to subclass the C classes _datetime.datetime, etc, and define the methods directly in those subclasses. Similar to how the C-defined class _socket.socket is subclassed in Lib/socket.py and more methods are added.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Wed Apr 20 22:02:08 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 21 Apr 2016 02:02:08 +0000
Subject: [issue26804] Prioritize lowercase proxy variables in urllib.request
In-Reply-To: <1461053909.86.0.0123928931795.issue26804@psf.upfronthosting.co.za>
Message-ID: <1461204128.31.0.296883785765.issue26804@psf.upfronthosting.co.za>


Martin Panter added the comment:

The second patch looks reasonable (I left one minor grammar comment).

About getproxies_environment(), I meant that if you set no_proxy="", it may be ignored if NO_PROXY=. . . is also set. E.g. if you already have these set:

http_proxy=http://proxy
no_proxy=example.net
NO_PROXY=example.net

you should be able to override no_proxy="" to cancel bypassing for example.net.

I agree the proxy_bypass() docstring looks wrong. If you want to write a patch to fix that, or to make the code more efficient or easier to understand, that would be good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26804>
_______________________________________

From report at bugs.python.org  Wed Apr 20 22:50:13 2016
From: report at bugs.python.org (Luiz Poleto)
Date: Thu, 21 Apr 2016 02:50:13 +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: <1461207013.51.0.169377950887.issue25461@psf.upfronthosting.co.za>


Luiz Poleto added the comment:

The Doc/library/os.rst bit in the current patch fails to apply in all versions specified in this bug report (it seems that it was generated before the commit that included an earlier version of it).

----------
nosy: +luiz.poleto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25461>
_______________________________________

From report at bugs.python.org  Wed Apr 20 23:15:44 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 21 Apr 2016 03:15:44 +0000
Subject: [issue16577] Suspect
 test.test_codeccallbacks.test_mutatingdecodehandler
In-Reply-To: <1354193508.42.0.911887136635.issue16577@psf.upfronthosting.co.za>
Message-ID: <1461208544.9.0.203388373862.issue16577@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16577>
_______________________________________

From report at bugs.python.org  Wed Apr 20 23:39:39 2016
From: report at bugs.python.org (Graham Dumpleton)
Date: Thu, 21 Apr 2016 03:39:39 +0000
Subject: [issue26808] wsgiref.simple_server breaks unicode in URIs
In-Reply-To: <1461150450.27.0.360588809006.issue26808@psf.upfronthosting.co.za>
Message-ID: <1461209979.29.0.437771900174.issue26808@psf.upfronthosting.co.za>


Graham Dumpleton added the comment:

Your code should be written as:

    res = """\
e:
{}
pi:
{}
qs:
{}
""".format(
        pprint.pformat(e),
        urllib.parse.unquote(e['PATH_INFO'].encode('Latin-1').decode('UTF-8')),
        urllib.parse.parse_qs(urllib.parse.unquote(e['QUERY_STRING'].encode('Latin-1').decode('UTF-8')))
        )

----------
nosy: +grahamd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26808>
_______________________________________

From report at bugs.python.org  Wed Apr 20 23:48:05 2016
From: report at bugs.python.org (Graham Dumpleton)
Date: Thu, 21 Apr 2016 03:48:05 +0000
Subject: [issue26808] wsgiref.simple_server breaks unicode in URIs
In-Reply-To: <1461150450.27.0.360588809006.issue26808@psf.upfronthosting.co.za>
Message-ID: <1461210485.93.0.876290363523.issue26808@psf.upfronthosting.co.za>


Graham Dumpleton added the comment:

There does appear to be something wrong with wsgiref, because with that rewritten code you should for:

curl http://127.0.0.1:8000/????

get:

pi:
/????
qs:
{}

and for:

curl http://127.0.0.1:8000/?a=????

get:

pi:
/
qs:
{'a': ['????']}

The PATH_INFO case appears to fail though and outputs:

pi:
/????????
qs:
{}

Don't think I have missed anything.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26808>
_______________________________________

From report at bugs.python.org  Wed Apr 20 23:53:25 2016
From: report at bugs.python.org (Graham Dumpleton)
Date: Thu, 21 Apr 2016 03:53:25 +0000
Subject: [issue16679] Add advice about non-ASCII wsgiref PATH_INFO
In-Reply-To: <1355473710.36.0.278942451351.issue16679@psf.upfronthosting.co.za>
Message-ID: <1461210805.59.0.721587110347.issue16679@psf.upfronthosting.co.za>


Graham Dumpleton added the comment:

As I commented on Issue 26808, it actually looks to me like the QUERY_STRING is processed fine and it is actually PATH_INFO that is not. I am confused at this point. I hate dealing with these WSGI level details now. :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16679>
_______________________________________

From report at bugs.python.org  Thu Apr 21 00:09:13 2016
From: report at bugs.python.org (Graham Dumpleton)
Date: Thu, 21 Apr 2016 04:09:13 +0000
Subject: [issue26808] wsgiref.simple_server breaks unicode in URIs
In-Reply-To: <1461150450.27.0.360588809006.issue26808@psf.upfronthosting.co.za>
Message-ID: <1461211753.65.0.90027682326.issue26808@psf.upfronthosting.co.za>


Graham Dumpleton added the comment:

This gets even weirder.

Gunicorn behaves same as wsgiref.

However, it turns out they both only show the unexpected result if using curl. If you use safari they are both fine.

Waitress blows up altogether on it with an exception when you use curl as client, but is okay with Safari and gives what I expect.

My mod_wsgi package gives what I expect whether you use curl or Safari. So Apache may be doing some magic in there to allow it to always work. No idea. But obviously mod_wsgi rules as it works regardless. :-)

uWSGI doesn't want to compile on MacOS X for me at the moment.

That Apache works properly whether use curl or Safari and other WSGI servers don't suggests something is amiss.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26808>
_______________________________________

From report at bugs.python.org  Thu Apr 21 00:19:59 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 21 Apr 2016 04:19:59 +0000
Subject: [issue26809] `string` exposes ChainMap from `collections`
In-Reply-To: <1461152182.96.0.373784885739.issue26809@psf.upfronthosting.co.za>
Message-ID: <1461212398.99.0.240831740557.issue26809@psf.upfronthosting.co.za>


Martin Panter added the comment:

No strong opinion on changing the name to _ChainMap, as long as it only goes into 3.6.

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26809>
_______________________________________

From report at bugs.python.org  Thu Apr 21 00:26:26 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 21 Apr 2016 04:26:26 +0000
Subject: [issue22359] Remove incorrect uses of recursive make
In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za>
Message-ID: <1461212786.64.0.622972938844.issue22359@psf.upfronthosting.co.za>


Martin Panter added the comment:

Looks pretty good. One more question: Why do you make the linking of _freeze_importlib conditional, but always build $(PGEN)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22359>
_______________________________________

From report at bugs.python.org  Thu Apr 21 00:27:19 2016
From: report at bugs.python.org (Yih-En Andrew Ban)
Date: Thu, 21 Apr 2016 04:27:19 +0000
Subject: [issue26812] ExtendedInterpolation drops user-defined 'vars' during
 _interpolate_some() recursion
Message-ID: <1461212839.44.0.193061483216.issue26812@psf.upfronthosting.co.za>


New submission from Yih-En Andrew Ban:

In Python 3.5.1, configparser.ExtendedInterpolation will drop the user-defined 'vars' passed in via ConfigParser.get(vars=...) due to a bug when recursing beyond depth 1 in ExtendedInterpolation._interpolate_some(). Line 509 of configparser.py currently reads: 'dict(parser.items(sect, raw=True))' This appears to be a mistake and should instead be: 'map', which includes the user-defined vars.

The following code will trigger an InterpolationMissingOptionError without the fix, and runs as expected with the fix:

from configparser import *
parser = ConfigParser( interpolation=ExtendedInterpolation() )
parser.add_section( 'Section' )
parser.set( 'Section', 'first', '${userdef}' )
parser.set( 'Section', 'second', '${first}' )
parser[ 'Section' ].get( 'second', vars={'userdef': 'userval'} )

----------
components: Library (Lib)
messages: 263876
nosy: lukasz.langa, yab-arz
priority: normal
severity: normal
status: open
title: ExtendedInterpolation drops user-defined 'vars' during _interpolate_some() recursion
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26812>
_______________________________________

From report at bugs.python.org  Thu Apr 21 00:42:43 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 21 Apr 2016 04:42:43 +0000
Subject: [issue26808] wsgiref.simple_server breaks unicode in URIs
In-Reply-To: <1461150450.27.0.360588809006.issue26808@psf.upfronthosting.co.za>
Message-ID: <1461213763.16.0.673659019953.issue26808@psf.upfronthosting.co.za>


Martin Panter added the comment:

Graham: On my Linux computer, Curl seems to treat the test ?URL? as a string of bytes and doesn?t percent encode it. Therefore you may be affected by Issue 26717 which I fixed the other day. But in real life, URLs are meant to only have literal ASCII characters (even if they encode other characters), so this shouldn?t be a big problem. Compare IRI vs URI. Browsers tend to percent-encode using UTF-8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26808>
_______________________________________

From report at bugs.python.org  Thu Apr 21 00:58:10 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 21 Apr 2016 04:58:10 +0000
Subject: [issue16679] Add advice about non-ASCII wsgiref PATH_INFO
In-Reply-To: <1355473710.36.0.278942451351.issue16679@psf.upfronthosting.co.za>
Message-ID: <1461214690.42.0.395585643105.issue16679@psf.upfronthosting.co.za>


Martin Panter added the comment:

PEP 3333 defers to a draft CGI specification for PATH_INFO and QUERY_STRING: <https://tools.ietf.org/html/draft-coar-cgi-v11-03>. (Dunno why it didn?t reference the final RFC 3875 instead, published 2004.) Anyway, both draft and final RFCs say ?PATH_INFO is not URL-encoded?, but ?the QUERY_STRING variable contains a URL-encoded search or parameter string?.

Graham, maybe you are seeing Latin-1 code points in PATH_INFO that have been translated from the %XX URL syntax, and QUERY_STRING retaining the original %XX syntax.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16679>
_______________________________________

From report at bugs.python.org  Thu Apr 21 01:16:09 2016
From: report at bugs.python.org (Graham Dumpleton)
Date: Thu, 21 Apr 2016 05:16:09 +0000
Subject: [issue16679] Add advice about non-ASCII wsgiref PATH_INFO
In-Reply-To: <1355473710.36.0.278942451351.issue16679@psf.upfronthosting.co.za>
Message-ID: <1461215769.25.0.114013932381.issue16679@psf.upfronthosting.co.za>


Graham Dumpleton added the comment:

What I get in Apache for:

http://127.0.0.1:8000/a=????

in Safari browser is:

'REQUEST_URI': '/a=%D1%82%D0%B5%D1%81%D1%82',
'PATH_INFO': '/a=\xc3\x91\\x82\xc3\x90\xc2\xb5\xc3\x91\\x81\xc3\x91\\x82',

Where as for curl see:

'REQUEST_URI': '/a=\xc3\x91\\x82\xc3\x90\xc2\xb5\xc3\x91\\x81\xc3\x91\\x82',
'PATH_INFO': '/a=\xc3\x91\\x82\xc3\x90\xc2\xb5\xc3\x91\\x81\xc3\x91\\x82',

For:

http://127.0.0.1:8000/?a=????

in Safari get:

'REQUEST_URI': '/?a=%D1%82%D0%B5%D1%81%D1%82',
'PATH_INFO': '/'
'QUERY_STRING': 'a=%D1%82%D0%B5%D1%81%D1%82',

and curl:

'REQUEST_URI': '/?a=\xc3\x91\\x82\xc3\x90\xc2\xb5\xc3\x91\\x81\xc3\x91\\x82',
'PATH_INFO': '/',
'QUERY_STRING': 'a=\xc3\x91\\x82\xc3\x90\xc2\xb5\xc3\x91\\x81\xc3\x91\\x82',

So yes curl sends as bytes rather than encoded, expected that.

Gunicorn on:

http://127.0.0.1:8000/a=????

sees for Safari:

 'PATH_INFO': '/a=?\x82???\x81?\x82',
 'QUERY_STRING': '',
 'RAW_URI': '/a=%D1%82%D0%B5%D1%81%D1%82',

and curl:

 'PATH_INFO': '/a=?\x91?\x82?\x90???\x91?\x81?\x91?\x82',
 'QUERY_STRING': '',
 'RAW_URI': '/a=?\x82???\x81?\x82',

Gunicorn on:

http://127.0.0.1:8000/?a=????

sees for Safari:

 'PATH_INFO': '/',
 'QUERY_STRING': 'a=%D1%82%D0%B5%D1%81%D1%82',
 'RAW_URI': '/?a=%D1%82%D0%B5%D1%81%D1%82',

and curl:

 'PATH_INFO': '/',
 'QUERY_STRING': 'a=?\x82???\x81?\x82',
 'RAW_URI': '/?a=?\x82???\x81?\x82',

So in Apache I get through UTF-8 byte string as Latin-1. So can see multi byte characters. Gunicorn is doing something different when gets raw bytes from curl. As does wsgiref. Showed Gunicorn as it has RAW_URI which is supposed to be the same as REQUEST_URI in Apache, but actually isn't showing the same there either.

Whatever is happening, mod_wsgi still gives a good outcome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16679>
_______________________________________

From report at bugs.python.org  Thu Apr 21 01:24:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Apr 2016 05:24:46 +0000
Subject: [issue26811] segfault due to null pointer in tuple
In-Reply-To: <1461198016.05.0.40690695807.issue26811@psf.upfronthosting.co.za>
Message-ID: <1461216286.22.0.223429510724.issue26811@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +brett.cannon, eric.snow, ncoghlan, serhiy.storchaka
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26811>
_______________________________________

From report at bugs.python.org  Thu Apr 21 01:25:39 2016
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Thu, 21 Apr 2016 05:25:39 +0000
Subject: [issue8978] "tarfile.ReadError: file could not be opened
 successfully" if compiled without zlib
In-Reply-To: <1276292933.37.0.137444086026.issue8978@psf.upfronthosting.co.za>
Message-ID: <1461216339.48.0.899075396654.issue8978@psf.upfronthosting.co.za>


Lars Gust?bel added the comment:

Closed after years of inactivity.

----------
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8978>
_______________________________________

From report at bugs.python.org  Thu Apr 21 01:33:22 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 21 Apr 2016 05:33:22 +0000
Subject: [issue2636] Adding a new regex module (compatible with re)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1461216802.82.0.0988246646506.issue2636@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Apr 21 01:51:03 2016
From: report at bugs.python.org (Ken Miura)
Date: Thu, 21 Apr 2016 05:51:03 +0000
Subject: [issue26813] Wrong Japanese translation of "Adverb" on Documentation
Message-ID: <1461217863.36.0.239729021285.issue26813@psf.upfronthosting.co.za>


New submission from Ken Miura:

In Japanese Python document, English word "Adverb" is translated to "????", but it's "??" actually.

http://docs.python.jp/2/library/re.html#finding-all-adverbs
http://docs.python.jp/2/library/re.html#finding-all-adverbs-and-their-positions

----------
assignee: docs at python
components: Documentation
messages: 263881
nosy: Ken Miura, docs at python
priority: normal
severity: normal
status: open
title: Wrong Japanese translation of "Adverb" on Documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26813>
_______________________________________

From report at bugs.python.org  Thu Apr 21 01:51:55 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 21 Apr 2016 05:51:55 +0000
Subject: [issue26811] segfault due to null pointer in tuple
In-Reply-To: <1461198016.05.0.40690695807.issue26811@psf.upfronthosting.co.za>
Message-ID: <1461217915.04.0.571073236753.issue26811@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

hg bisect tells me changeset 95830:661cdbd617b8 introduces this behaviour.

----------
nosy: +xiang.zhang
type: crash -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26811>
_______________________________________

From report at bugs.python.org  Thu Apr 21 02:04:00 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 21 Apr 2016 06:04:00 +0000
Subject: [issue26811] segfault due to null pointer in tuple
In-Reply-To: <1461198016.05.0.40690695807.issue26811@psf.upfronthosting.co.za>
Message-ID: <1461218640.62.0.982615121065.issue26811@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26811>
_______________________________________

From report at bugs.python.org  Thu Apr 21 02:10:34 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 21 Apr 2016 06:10:34 +0000
Subject: [issue26809] `string` exposes ChainMap from `collections`
In-Reply-To: <1461152182.96.0.373784885739.issue26809@psf.upfronthosting.co.za>
Message-ID: <1461219034.09.0.737119556791.issue26809@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26809>
_______________________________________

From report at bugs.python.org  Thu Apr 21 02:16:40 2016
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 21 Apr 2016 06:16:40 +0000
Subject: [issue26813] Wrong Japanese translation of "Adverb" on Documentation
In-Reply-To: <1461217863.36.0.239729021285.issue26813@psf.upfronthosting.co.za>
Message-ID: <1461219400.71.0.0104497487312.issue26813@psf.upfronthosting.co.za>


INADA Naoki added the comment:

Thank you for reporting.
Japanese translation team has own issue tracker in Github.
I copied this issue to https://github.com/python-doc-ja/python-doc-ja/issues/733

----------
nosy: +naoki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26813>
_______________________________________

From report at bugs.python.org  Thu Apr 21 02:17:49 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 21 Apr 2016 06:17:49 +0000
Subject: [issue26809] `string` exposes ChainMap from `collections`
In-Reply-To: <1461152182.96.0.373784885739.issue26809@psf.upfronthosting.co.za>
Message-ID: <1461219469.72.0.0228320497416.issue26809@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

ChainMap___all___2.patch looks good.  I would be fine with this going into 3.5 as well (ChainMap is not part of the documented API for the string module).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26809>
_______________________________________

From report at bugs.python.org  Thu Apr 21 02:26:04 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Apr 2016 06:26:04 +0000
Subject: [issue26813] Wrong Japanese translation of "Adverb" on Documentation
In-Reply-To: <1461217863.36.0.239729021285.issue26813@psf.upfronthosting.co.za>
Message-ID: <1461219964.29.0.00779524341917.issue26813@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> third party
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26813>
_______________________________________

From report at bugs.python.org  Thu Apr 21 02:27:14 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 21 Apr 2016 06:27:14 +0000
Subject: [issue26811] segfault due to null pointer in tuple
In-Reply-To: <1461198016.05.0.40690695807.issue26811@psf.upfronthosting.co.za>
Message-ID: <1461220034.01.0.843981868722.issue26811@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Also, see https://hg.python.org/cpython/rev/5dbf3d932a59

Serhiy, I'll thinking the whole optimization ought to be reverted as being too tricky and error-prone for the small benefit.  A less aggressive approach would be to have the tuple save a valid object (such as None) instead of NULL.  What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26811>
_______________________________________

From report at bugs.python.org  Thu Apr 21 02:27:45 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Apr 2016 06:27:45 +0000
Subject: [issue26811] segfault due to null pointer in tuple
In-Reply-To: <1461198016.05.0.40690695807.issue26811@psf.upfronthosting.co.za>
Message-ID: <1461220065.64.0.645295149471.issue26811@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

661cdbd617b8 can cause problems with recursion and with cached getters. I suggest to revert it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26811>
_______________________________________

From report at bugs.python.org  Thu Apr 21 02:32:14 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 21 Apr 2016 06:32:14 +0000
Subject: [issue26811] segfault due to null pointer in tuple
In-Reply-To: <1461198016.05.0.40690695807.issue26811@psf.upfronthosting.co.za>
Message-ID: <1461220334.69.0.329103992509.issue26811@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I concur.  Please do the honors and revert it from 3.5 and 3.6.

----------
assignee: rhettinger -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26811>
_______________________________________

From report at bugs.python.org  Thu Apr 21 02:32:25 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 21 Apr 2016 06:32:25 +0000
Subject: [issue26811] segfault due to null pointer in tuple
In-Reply-To: <1461198016.05.0.40690695807.issue26811@psf.upfronthosting.co.za>
Message-ID: <1461220345.93.0.807892994452.issue26811@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/issue26811>
_______________________________________

From report at bugs.python.org  Thu Apr 21 02:40:24 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Apr 2016 06:40:24 +0000
Subject: [issue26811] segfault due to null pointer in tuple
In-Reply-To: <1461198016.05.0.40690695807.issue26811@psf.upfronthosting.co.za>
Message-ID: <1461220824.57.0.867319760136.issue26811@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ah, yes, 5dbf3d932a59 partially fixed this optimization. Saving None in a tuple (as I believe done in itertools/zip/enumerate optimization) should fix this issue. I agree that the code is too tricky (as well as the code in itertools/zip/enumerate). It would be better to make tuple creation faster instead of adding special caches in separate functions (see also issue23507). But for now this optimization makes attribute access in named tuples 30% faster, and this is good argument for keeping it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26811>
_______________________________________

From report at bugs.python.org  Thu Apr 21 02:44:02 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Apr 2016 06:44:02 +0000
Subject: [issue26811] segfault due to null pointer in tuple
In-Reply-To: <1461198016.05.0.40690695807.issue26811@psf.upfronthosting.co.za>
Message-ID: <1461221042.91.0.894208151125.issue26811@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Sorry, I'm late with my comments. All my posts are written without seeing your previous message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26811>
_______________________________________

From report at bugs.python.org  Thu Apr 21 03:19:56 2016
From: report at bugs.python.org (Thomas)
Date: Thu, 21 Apr 2016 07:19:56 +0000
Subject: [issue26799] gdb support fails with "Invalid cast."
In-Reply-To: <1461013840.26.0.744881925452.issue26799@psf.upfronthosting.co.za>
Message-ID: <1461223196.56.0.781593773452.issue26799@psf.upfronthosting.co.za>


Thomas added the comment:

Thank you for the quick integration and fixing the return. I have signed the electronic form yesterday.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26799>
_______________________________________

From report at bugs.python.org  Thu Apr 21 03:40:46 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 21 Apr 2016 07:40:46 +0000
Subject: [issue22359] Remove incorrect uses of recursive make
In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za>
Message-ID: <1461224446.29.0.788608587954.issue22359@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> Why do you make the linking of _freeze_importlib conditional, but always build $(PGEN)?

Yes, this is not consistent. The cross-build is correct when both are linked or when both are not linked. And $(PGENOBJS) are cross-compiled in both cases.

Should both programs not be created ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22359>
_______________________________________

From report at bugs.python.org  Thu Apr 21 03:51:36 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Apr 2016 07:51:36 +0000
Subject: [issue26811] segfault due to null pointer in tuple
In-Reply-To: <1461198016.05.0.40690695807.issue26811@psf.upfronthosting.co.za>
Message-ID: <1461225096.88.0.6388438598.issue26811@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Serhiy: "Ah, yes, 5dbf3d932a59 partially fixed this optimization."

Since we already talking about hacks, another hack is to hide this private tuple from the GC using _PyObject_GC_UNTRACK(): see attached property_descr_get_gc_untrack.patch.

Note: I dislike my own patch :-D


Serhiy: "661cdbd617b8 can cause problems with recursion and with cached getters. I suggest to revert it."

Even if I don't understand the issue, I concur that the micro-optimization must be reverted. A micro-optimization must not introduce any behaviour change nor segfault :-)


Raymond Hettinger: "Serhiy, I'll thinking the whole optimization ought to be reverted as being too tricky and error-prone for the small benefit.  A less aggressive approach would be to have the tuple save a valid object (such as None) instead of NULL.  What do you think?"

PyEval_EvalCodeEx() accepts a C array of PyObject* for function arguments, it's used by fast_function() in Pythn/ceval.c. Maybe a new C function can be designed to call a function: it would uses PyEval_EvalCodeEx() to call functions implemented in Python, or create the tuple for functions implemented in C.

It looks like the issue #23910 which introduced the optimization was created for functions implemented in C. So I don't know it's acceptable. But it would be safer and more generic, no?

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file42546/property_descr_get_gc_untrack.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26811>
_______________________________________

From report at bugs.python.org  Thu Apr 21 03:59:08 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Apr 2016 07:59:08 +0000
Subject: [issue26811] segfault due to null pointer in tuple
In-Reply-To: <1461198016.05.0.40690695807.issue26811@psf.upfronthosting.co.za>
Message-ID: <1461225548.05.0.718938181579.issue26811@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Maybe a new C function can be designed to call a function: it would uses PyEval_EvalCodeEx() to call functions implemented in Python, or create the tuple for functions implemented in C.

I would expect C code to be more optimized that Python functions, but for the specific case of function calls: Python are more optimized with the fast-path fast_function()!

I recall vaguely that Larry Hasting shared me his idea of passing the Python stack to C functions to avoid the creation of a tuple.

Maybe we can add a new API for C functions accepted a C array of PyObject*, a number of positional arguments and a number of (key, value) pairs for keyword arguments. Something similar to PyEval_EvalCodeEx() but for C functions. It means that we should add a new flavor of PyArg_ParseTuple/PyArg_ParseTupleAndKeywords to accepts this format.

Larry's idea was to use the argument clinic to handle that for us.

----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26811>
_______________________________________

From report at bugs.python.org  Thu Apr 21 04:00:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Apr 2016 08:00:22 +0000
Subject: [issue26811] segfault due to null pointer in tuple
In-Reply-To: <1461198016.05.0.40690695807.issue26811@psf.upfronthosting.co.za>
Message-ID: <1461225622.57.0.507039436152.issue26811@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

References:

Issue23910 -- added original optimization (661cdbd617b8).
Issue24276 -- it was significant rewritten (5dbf3d932a59).

My suggestion in msg263886 to revert the optimization was related to the original code. Now, after reminding the background, I think it is worth to keep the optimization and try to fix the code.

Making the cached tuple to save None adds additional complexity and overhead (about 5%). Here is a patch that uses different trick. The size of saved tuple is set to 0.

----------
stage:  -> patch review
type:  -> crash
Added file: http://bugs.python.org/file42547/property_cached_args_set_size_0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26811>
_______________________________________

From report at bugs.python.org  Thu Apr 21 04:06:22 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Apr 2016 08:06:22 +0000
Subject: [issue26811] segfault due to null pointer in tuple
In-Reply-To: <1461198016.05.0.40690695807.issue26811@psf.upfronthosting.co.za>
Message-ID: <1461225982.36.0.541231496411.issue26811@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I suggest to remove the micro-optimization from Python 3.5 for safety.

I'm ok to experiment a new safer implementation on Python 3.6 ;-) We have more time to fix the code in Python 3.6 if new issues are found. Setting the tuple size to zero looks simple and safe, but the overall hack deserves a comment to explain:

* why you use a cached tuple
* why the reference count can be different than 2: recursive calls
* why do you change the tuple size

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26811>
_______________________________________

From report at bugs.python.org  Thu Apr 21 04:35:51 2016
From: report at bugs.python.org (Andy Maier)
Date: Thu, 21 Apr 2016 08:35:51 +0000
Subject: [issue1322] Deprecate platform.dist() and
 platform.linux_distribution() functions
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1461227751.69.0.73248400276.issue1322@psf.upfronthosting.co.za>


Andy Maier added the comment:

Just for completeness:

The "ld" package is now called "distro" and its v0.6.0 is on PyPI: https://pypi.python.org/pypi/distro

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Thu Apr 21 04:53:19 2016
From: report at bugs.python.org (Hans-Peter Jansen)
Date: Thu, 21 Apr 2016 08:53:19 +0000
Subject: [issue26804] Prioritize lowercase proxy variables in urllib.request
In-Reply-To: <1461053909.86.0.0123928931795.issue26804@psf.upfronthosting.co.za>
Message-ID: <1461228799.64.0.706379224348.issue26804@psf.upfronthosting.co.za>


Hans-Peter Jansen added the comment:

Here we go:

v3 fixes following issues:
 * prefer lowercase proxy environment settings, if multiple (disagreeing) settings are specified with differing case schemes (e.g. HTTP_PROXY vs. http_proxy)
 * an empty proxy variable value resets the related setting correctly 
 * apply this logic to no_proxy, too
 * document this behaviour 
 * fix misleading docstrings related to proxy_bypass

----------
Added file: http://bugs.python.org/file42548/python-urllib-prefer-lowercase-proxies-v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26804>
_______________________________________

From report at bugs.python.org  Thu Apr 21 04:56:50 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 21 Apr 2016 08:56:50 +0000
Subject: [issue22359] Remove incorrect uses of recursive make
In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za>
Message-ID: <1461229010.54.0.106151296209.issue22359@psf.upfronthosting.co.za>


Martin Panter added the comment:

I see. I guess it would keep the makefile simpler if we cross-compiled both programs, and never used them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22359>
_______________________________________

From report at bugs.python.org  Thu Apr 21 04:57:21 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Apr 2016 08:57:21 +0000
Subject: [issue26814] Add a new _PyObject_CallStack() function which avoids
 the creation of a tuple or dict for arguments
Message-ID: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch adds the following new function:

   PyObject* _PyObject_CallStack(PyObject *func,
                                 PyObject **stack, 
                                 int na, int nk);

where na is the number of positional arguments and nk is the number of (key, pair) arguments stored in the stack.

Example of C code to call a function with one positional argument:

    PyObject *stack[1];
    stack[0] = arg;
    return _PyObject_CallStack(func, stack, 1, 0);

Simple, isn't it?

The difference with PyObject_Call() is that its API avoids the creation of a tuple and a dictionary to pass parameters to functions when possible. Currently, the temporary tuple and dict can be avoided to call Python functions (nice, isn't it?) and C function declared with METH_O (not the most common API, but many functions are declared like that).

The patch only modifies property_descr_set() to test the feature, but I'm sure that *a lot* of C code can be modified to use this new function to beneift from its optimization.

Should we make this new _PyObject_CallStack() function official: call it PyObject_CallStack() (without the understand prefix) or experiment it in CPython 3.6 and decide later to make it public? If it's made private, it will require a large replacement patch later to replace all calls to _PyObject_CallStack() with PyObject_CallStack() (strip the underscore prefix).

The next step is to add a new METH_STACK flag to pass parameters to C functions using a similar API (PyObject **stack, int na, int nk) and modify the argument clinic to use this new API.

Thanks to Larry Hasting who gave me the idea in a previous edition of Pycon US ;-)

This issue was created after the discussion on issue #26811 which is an issue in a micro-optimization in property_descr_set() to avoid the creation of a tuple: it caches a private tuple inside property_descr_set().

----------
files: call_stack.patch
keywords: patch
messages: 263899
nosy: haypo, larry, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add a new _PyObject_CallStack() function which avoids the creation of a tuple or dict for arguments
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file42549/call_stack.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Thu Apr 21 04:57:45 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Apr 2016 08:57:45 +0000
Subject: [issue26811] segfault due to null pointer in tuple
In-Reply-To: <1461198016.05.0.40690695807.issue26811@psf.upfronthosting.co.za>
Message-ID: <1461229065.72.0.736819753841.issue26811@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I created the issue #26814: "Add a new _PyObject_CallStack() function which avoids the creation of a tuple or dict for arguments".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26811>
_______________________________________

From report at bugs.python.org  Thu Apr 21 04:58:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Apr 2016 08:58:03 +0000
Subject: [issue26814] Add a new _PyObject_CallStack() function which avoids
 the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461229083.0.0.135001406046.issue26814@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Thu Apr 21 05:00:28 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Apr 2016 09:00:28 +0000
Subject: [issue26799] gdb support fails with "Invalid cast."
In-Reply-To: <1461013840.26.0.744881925452.issue26799@psf.upfronthosting.co.za>
Message-ID: <1461229228.26.0.185887122097.issue26799@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Great!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26799>
_______________________________________

From report at bugs.python.org  Thu Apr 21 05:06:36 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 21 Apr 2016 09:06:36 +0000
Subject: [issue22359] Remove incorrect uses of recursive make
In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za>
Message-ID: <1461229596.49.0.140890069906.issue22359@psf.upfronthosting.co.za>


Martin Panter added the comment:

For the record, to fix this in 2.7 will involve backporting revision c2a53aa27cad, plus Xavier?s patch (except the freeze_importlib parts which is not relevant to 2.7).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22359>
_______________________________________

From report at bugs.python.org  Thu Apr 21 05:28:28 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Apr 2016 09:28:28 +0000
Subject: [issue26811] segfault due to null pointer in tuple
In-Reply-To: <1461198016.05.0.40690695807.issue26811@psf.upfronthosting.co.za>
Message-ID: <1461230907.99.0.397877017338.issue26811@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> I suggest to remove the micro-optimization from Python 3.5 for safety.

Then we should remove the promise from What's New In Python 3.5. That will cause a regression in namedtuple attributes access about 30%.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26811>
_______________________________________

From report at bugs.python.org  Thu Apr 21 05:41:19 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Apr 2016 09:41:19 +0000
Subject: [issue26811] segfault due to null pointer in tuple
In-Reply-To: <1461230907.99.0.397877017338.issue26811@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwb9DURkzzSYj6m9kCBSZ54SHvOBFuSfixegv7pa5azHvw@mail.gmail.com>


STINNER Victor added the comment:

Oh, I see "The property() getter calls are up to 25% faster.
(Contributed by Joe Jevnik in issue 23910.)" in
https://docs.python.org/dev/whatsnew/3.5.html#optimizations

Hum... This is embarrassing :-/ Ok, let's keep it, but we must fix it ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26811>
_______________________________________

From report at bugs.python.org  Thu Apr 21 05:49:15 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Apr 2016 09:49:15 +0000
Subject: [issue26815] SIGBUS in test_ssl.test_dealloc_warn() on "AMD64 FreeBSD
 10.0 3.x" buildbot
Message-ID: <1461232155.49.0.392894323476.issue26815@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Oh oh, that's not good. test_ssl crashed in test_dealloc_warn() on the "AMD64 FreeBSD 10.0 3.x" buildbot.

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x/builds/4348/steps/test/logs/stdio

[ 39/400] test_ssl
Fatal Python error: Bus error

Current thread 0x0000000802006400 (most recent call first):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/support/__init__.py", line 1444 in gc_collect
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_ssl.py", line 599 in test_dealloc_warn
  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 1802 in _run_suite
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/support/__init__.py", line 1836 in run_unittest
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_ssl.py", line 3364 in test_main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/runtest.py", line 162 in runtest_inner
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/runtest.py", line 115 in runtest
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/runtest_mp.py", line 69 in run_tests_slave
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py", line 379 in main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py", line 433 in main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py", line 455 in main_in_temp_cwd
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 39 in <module>
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/runpy.py", line 85 in _run_code
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/runpy.py", line 184 in _run_module_as_main
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/runpy.py", line 184, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/__main__.py", line 3, in <module>
    regrtest.main_in_temp_cwd()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py", line 455, in main_in_temp_cwd
    main()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py", line 433, in main
    Regrtest().main(tests=tests, **kwargs)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py", line 392, in main
    self.run_tests()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py", line 354, in run_tests
    run_tests_multiprocess(self)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/runtest_mp.py", line 212, in run_tests_multiprocess
    raise Exception(msg)
Exception: Child error on test_ssl: Exit code -10
*** Error code 1

----------
messages: 263905
nosy: haypo
priority: normal
severity: normal
status: open
title: SIGBUS in test_ssl.test_dealloc_warn() on "AMD64 FreeBSD 10.0 3.x" buildbot
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26815>
_______________________________________

From report at bugs.python.org  Thu Apr 21 05:51:35 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Apr 2016 09:51:35 +0000
Subject: [issue26815] SIGBUS in test_ssl.test_dealloc_warn() on "AMD64 FreeBSD
 10.0 3.x" buildbot
In-Reply-To: <1461232155.49.0.392894323476.issue26815@psf.upfronthosting.co.za>
Message-ID: <1461232295.86.0.490339355622.issue26815@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The test:

    def test_dealloc_warn(self):
        ss = ssl.wrap_socket(socket.socket(socket.AF_INET))
        r = repr(ss)
        with self.assertWarns(ResourceWarning) as cm:
            ss = None
            support.gc_collect()   <~~~~~ SIGBUG occurred here
        self.assertIn(r, str(cm.warning.args[0]))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26815>
_______________________________________

From report at bugs.python.org  Thu Apr 21 05:53:53 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Apr 2016 09:53:53 +0000
Subject: [issue26814] Add a new _PyObject_CallStack() function which avoids
 the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461232433.75.0.114908610649.issue26814@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

"Stack" in the function name looks a little confusing. I understand that this is related to the stack of bytecode interpreter, but this looks as raising pretty deep implementation detail. The way of packing positional and keyword arguments in the continuous array is not clear. Wouldn't be better to provide separate arguments for positional and keyword arguments?

What is the performance effect of using this function? For example compare the performance of namedtuple's attribute access of current code, the code with with this patch, and unoptimized code in 3.4:

    ./python -m timeit -r 11 -s "from collections import namedtuple as n; a = n('n', 'a b c')(1, 2, 3)" -- "a.a"

Is there any use of this function with keyword arguments?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Thu Apr 21 06:20:50 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Apr 2016 10:20:50 +0000
Subject: [issue26814] Add a new _PyObject_CallStack() function which avoids
 the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461234050.77.0.00621555347861.issue26814@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Microbenchmark on Python 3.6, best of 3 runs:

./python -m timeit -r 11 -s "from collections import namedtuple as n; a = n('n', 'a b c')(1, 2, 3)" -- "a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a"

* Python 3.6 unpatched: 0.968 usec
* call_stack.patch: 1.27 usec
* Python 3.6 with property_descr_get() of Python 3.4: 1.32 usec

"Python 3.6 with property_descr_get() of Python 3.4": replace the current optimization with "return PyObject_CallFunctionObjArgs(gs->prop_get, obj, NULL);".

Oh, in fact the tested code calls a property where the final function is operator.itemgetter(0). _PyObject_CallStack() creates a temporary tuple to call PyObject_Call() which calls func->ob_type->tp_call, itemgetter_call().

Problem: tp_call API uses (PyObject *args, PyObject *kwargs). It doesn't accept directly a stack (a C array of PyObject*). And it may be more difficult to modify tp_call.

In short, my patch disables the optimization on property with my current incomplete implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Thu Apr 21 06:28:27 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Apr 2016 10:28:27 +0000
Subject: [issue26814] Add a new _PyObject_CallStack() function which avoids
 the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461234507.66.0.61273418178.issue26814@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue23507. May be your function help to optimize filter(), map(), sorted()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Thu Apr 21 06:42:27 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Apr 2016 10:42:27 +0000
Subject: [issue26814] Add a new _PyObject_CallStack() function which avoids
 the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461235347.88.0.471114029992.issue26814@psf.upfronthosting.co.za>


STINNER Victor added the comment:

call_stack-2.patch: A little bit more complete patch, it adds a tp_call_stack field to PyTypeObject an use it in _PyObject_CallStack().

Updated microbenchmark on Python 3.6, best of 3 runs:

./python -m timeit -r 11 -s "from collections import namedtuple as n; a = n('n', 'a b c')(1, 2, 3)" -- "a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a"

* Python 3.6 unpatched: 0.968 usec
* call_stack.patch: 1.27 usec
* Python 3.6 with property_descr_get() of Python 3.4: 1.32 usec
* call_stack-2.patch: 0.664 usec

call_stack-2.patch makes this micro-benchmark 31% faster, not bad! It also makes calls to C functions almost 2x as fast if you replace current unoptimized calls with _PyObject_CallStack()!!

IHMO we should continue to experiment, making function calls 2x faster is worth it ;-)


Serhiy: "See also issue23507. May be your function help to optimize filter(), map(), sorted()?"

IMHO the API is generic enough to be usable in a lot of cases.


Serhiy: "Is there any use of this function with keyword arguments?"

Calling functions with keywords is probably the least common case for function calls in C code. But I would like to provide a fast function to call with keywords. Maybe we need two functions just to make the API cleaner? The difference would just be that "int k" would be omitted?

I proposed an API (PyObject **stack, int na, int nk) based on the current code in Python/ceval.c. I'm not sure that it's the best API ever :-)

In fact, there is already PyObject_CallFunctionObjArgs() which can be modified to reuse internally _PyObject_CallStack(), and its API is maybe more convenient than my proposed API.

----------
Added file: http://bugs.python.org/file42550/call_stack-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Thu Apr 21 07:01:52 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 21 Apr 2016 11:01:52 +0000
Subject: [issue26816] Make concurrent.futures.Executor an abc
Message-ID: <1461236512.66.0.771218032413.issue26816@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

The documentation tells that concurrent.futures.Executor is an abstract class. Also PEP3148 tells so and says concurrent.futures.Executor.submit is an abstract method and must be implemented by Executor subclasses. I think using abc.ABCMeta here is a good choice.

I propose a patch. The patch also remove some unnecessary object base class.

----------
files: make_concurrent_futures_Executor_an_abc.patch
keywords: patch
messages: 263911
nosy: bquinlan, xiang.zhang
priority: normal
severity: normal
status: open
title: Make concurrent.futures.Executor an abc
Added file: http://bugs.python.org/file42551/make_concurrent_futures_Executor_an_abc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26816>
_______________________________________

From report at bugs.python.org  Thu Apr 21 07:28:32 2016
From: report at bugs.python.org (Hans-Peter Jansen)
Date: Thu, 21 Apr 2016 11:28:32 +0000
Subject: [issue26804] Prioritize lowercase proxy variables in urllib.request
In-Reply-To: <1461053909.86.0.0123928931795.issue26804@psf.upfronthosting.co.za>
Message-ID: <1461238112.67.0.93282419088.issue26804@psf.upfronthosting.co.za>


Hans-Peter Jansen added the comment:

Here's the finalized version of this patch, including unit tests.

----------
Added file: http://bugs.python.org/file42552/python-urllib-prefer-lowercase-proxies-v4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26804>
_______________________________________

From report at bugs.python.org  Thu Apr 21 07:42:16 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 21 Apr 2016 11:42:16 +0000
Subject: [issue26803] syslog logging handler fails with address in unix
 abstract namespace
In-Reply-To: <1461051316.11.0.100147214694.issue26803@psf.upfronthosting.co.za>
Message-ID: <1461238936.39.0.372927002652.issue26803@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

In makesockaddr(), the current implementation does not do any decoding of AF_UNIX addresses in the abstract namespace in the struct sockaddr_un to bytes direction, i.e. system to python direction, but does encode a string or bytes object to struct sockaddr_un in the reverse direction, in getsockaddrarg(). This is not correct.

So the patch does more than fixing the type of the addresses as it also fixes this in a non backward compatible way. Maybe this should be indicated in Misc/NEWS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26803>
_______________________________________

From report at bugs.python.org  Thu Apr 21 07:51:38 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 21 Apr 2016 11:51:38 +0000
Subject: [issue26750] Mock autospec does not work with subclasses of property()
In-Reply-To: <1460585586.67.0.646853664072.issue26750@psf.upfronthosting.co.za>
Message-ID: <1461239498.14.0.213813046644.issue26750@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
components: +Library (Lib) -Tests
nosy: +berker.peksag
stage:  -> patch review
type: enhancement -> behavior
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26750>
_______________________________________

From report at bugs.python.org  Thu Apr 21 07:58:56 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 21 Apr 2016 11:58:56 +0000
Subject: [issue26816] Make concurrent.futures.Executor an abc
In-Reply-To: <1461236512.66.0.771218032413.issue26816@psf.upfronthosting.co.za>
Message-ID: <1461239936.79.0.897712552702.issue26816@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Update the patch to remove more unnecessary base object.

----------
Added file: http://bugs.python.org/file42553/make_concurrent_futures_Executor_an_abc_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26816>
_______________________________________

From report at bugs.python.org  Thu Apr 21 08:11:22 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 21 Apr 2016 12:11:22 +0000
Subject: [issue22359] Remove incorrect uses of recursive make
In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za>
Message-ID: <1461240682.09.0.0485937933876.issue22359@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

_freeze_importlib and pgen are cross-built in this patch. Patch tested with a run of the testsuite after a cross-build.

----------
Added file: http://bugs.python.org/file42554/crossbuild-sources-readonly_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22359>
_______________________________________

From report at bugs.python.org  Thu Apr 21 08:14:44 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 21 Apr 2016 12:14:44 +0000
Subject: [issue26816] Make concurrent.futures.Executor an abc
In-Reply-To: <1461236512.66.0.771218032413.issue26816@psf.upfronthosting.co.za>
Message-ID: <1461240884.94.0.0657261814567.issue26816@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
type:  -> enhancement
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26816>
_______________________________________

From report at bugs.python.org  Thu Apr 21 09:30:12 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Apr 2016 13:30:12 +0000
Subject: [issue26815] SIGBUS in test_ssl.test_dealloc_warn() on "AMD64 FreeBSD
 10.0 3.x" buildbot
In-Reply-To: <1461232155.49.0.392894323476.issue26815@psf.upfronthosting.co.za>
Message-ID: <1461245412.62.0.54677590645.issue26815@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Another different failure.

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x/builds/4362/steps/test/logs/stdio

======================================================================
FAIL: test_refcycle (test.test_ssl.BasicSocketTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_ssl.py", line 331, in test_refcycle
    self.assertEqual(wr(), None)
AssertionError: <ssl.SSLSocket fd=-1, family=AddressFamil[43 chars]to=0> != None

----------------------------------------------------------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26815>
_______________________________________

From report at bugs.python.org  Thu Apr 21 09:31:25 2016
From: report at bugs.python.org (Thomas Guettler)
Date: Thu, 21 Apr 2016 13:31:25 +0000
Subject: [issue26817] Docs for StringIO should link to io.BytesIO
Message-ID: <1461245485.84.0.279459146406.issue26817@psf.upfronthosting.co.za>


New submission from Thomas Guettler:

I think a warning at the top of StringIO docs is needed.

And it should link to io.BytesIO.

Maybe even deprecate StringIO and cStringIO in Python2?

StringIO docs: https://docs.python.org/2/library/stringio.html

io.BytesIO docs: https://docs.python.org/2/library/io.html#io.BytesIO

I would like to see this at the top of StringIO:

{{{
Please use io.BytesIO and io.StringIO since this module is not supported in Python3
}}

----------
assignee: docs at python
components: Documentation
messages: 263917
nosy: docs at python, guettli
priority: normal
severity: normal
status: open
title: Docs for StringIO should link to io.BytesIO
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26817>
_______________________________________

From report at bugs.python.org  Thu Apr 21 09:45:49 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Apr 2016 13:45:49 +0000
Subject: [issue26814] Add a new _PyObject_CallStack() function which avoids
 the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461246349.44.0.343678673.issue26814@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

With call_stack-2.patch attribute access in namedtuple is only 25% slower than attribute access in ordinary Python object! Definitely this this worth to continue to experiment!

But adding new slot to PyTypeObject sets the bar too high. Try to use your function to speed up all cases mentioned in issue23507: sorted()/list.sort(), min() and max() with the key argument, filter(), map(), some iterators from itertools (groupby(), dropwhile(), takewhile(), accumulate(), filterfalse()), thin wrappers around special method (round(), math.floor(), etc). Use it in wrappers around PyObject_Call() like PyObject_CallFunctionObjArgs(). May be this will cause an effect even on some macrobenchmarks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Thu Apr 21 09:49:25 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 21 Apr 2016 13:49:25 +0000
Subject: [issue12743] C API marshalling doc contains XXX
In-Reply-To: <1313160183.82.0.137409262179.issue12743@psf.upfronthosting.co.za>
Message-ID: <1461246565.27.0.301924248731.issue12743@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Since 4059e871e74e, PyMarshal_ReadLongFromFile and PyMarshal_ReadShortFromFile can return -1 on error. Return values of those functions were already documented in acb4d43955f6. Some of the usages also check return value of PyErr_Occurred(): https://hg.python.org/cpython/rev/11958c69a4b2#l2.7

I removed the outdated paragraph and add a sentence about using PyErr_Occurred().

----------
keywords: +patch
nosy: +berker.peksag, haypo
stage: needs patch -> patch review
versions: +Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42555/issue12743.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12743>
_______________________________________

From report at bugs.python.org  Thu Apr 21 10:24:16 2016
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 21 Apr 2016 14:24:16 +0000
Subject: [issue26814] Add a new _PyObject_CallStack() function which avoids
 the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461248656.45.0.312771436929.issue26814@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Yes, I've been working on a patch to do this as well.  I called the calling convention METH_RAW, to go alongside METH_ZERO METH_O etc.  My calling convention was exactly the same as yours: PyObject *(PyObject *o, PyObject **stack, int na, int nk).  I only had to modify two functions in ceval.c to support it: ext_do_call() and call_function().

And yes, the overarching goal was to have Argument Clinic generate custom argument parsing code for every function.  Supporting the calling convention was the easy part; generating code was quite complicated.  I believe I got a very simple version of it working at one point, supporting positional parameters only, with some optional arguments.  Parsing arguments by hand gets very complicated indeed when you introduce keyword arguments.

I haven't touched this patch in most of a year.  I hope to return to it someday.  In the meantime it's fine by me if you add support for this and rewrite some functions by hand to use it.

p.s. My last name has two S's.  If you continue to leave off one of them, I shall remove one from yours, Mr. TINNER.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Thu Apr 21 10:28:39 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 21 Apr 2016 14:28:39 +0000
Subject: [issue26818] trace CLI doesn't respect -s option
Message-ID: <1461248919.65.0.631004346458.issue26818@psf.upfronthosting.co.za>


New submission from Berker Peksag:

I noticed this while triaging issue 9317. Using traceme.py from that issue,

    $ ./python -m trace -c -s traceme.py

returns nothing. It seems like it's a regression caused by https://github.com/python/cpython/commit/17e5da46a733a1a05072a277bc81ffa885f0c204

With trace_cli_summary.diff applied:

    $ ./python -m trace -c -s traceme.py
    lines   cov%   module   (path)
        1   100%   trace   (/home/berker/projects/cpython/default/Lib/trace.py)
        6   100%   traceme   (traceme.py)

trace_cli_summary.diff also fixes issue 10541.

----------
components: Library (Lib)
files: trace_cli_cummary.diff
keywords: patch
messages: 263921
nosy: belopolsky, berker.peksag
priority: normal
severity: normal
stage: patch review
status: open
title: trace CLI doesn't respect -s option
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42556/trace_cli_cummary.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26818>
_______________________________________

From report at bugs.python.org  Thu Apr 21 10:31:42 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 21 Apr 2016 14:31:42 +0000
Subject: [issue9317] Incorrect coverage file from trace test_pickle.py
In-Reply-To: <1279677265.36.0.322549269298.issue9317@psf.upfronthosting.co.za>
Message-ID: <1461249102.51.0.899665672386.issue9317@psf.upfronthosting.co.za>


Berker Peksag added the comment:

A patch similar to issue9317.2.patch has been applied in 0aa46b9ffba3. However, I noticed a regression and created issue 26818. I can confirm that this issue is fixed with the patch from issue 26818 applied.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9317>
_______________________________________

From report at bugs.python.org  Thu Apr 21 11:03:09 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Apr 2016 15:03:09 +0000
Subject: [issue26814] Add a new _PyObject_FastCall() function which avoids the
 creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461250989.34.0.323446607853.issue26814@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Since early microbenchmarks are promising, I wrote a more complete implementations which tries to use the fast-path (avoid temporary tuple/dict) in all PyObject_Call*() functions.

The next step would be to add a METH_FASTCALL flag. IMHO adding such new flag requires to enhance Argument Clinic to be able to use it, at least when a function doesn't accept keyword parameters.

PyObject_CallFunction() & friends have a weird API: if call with the format string "O", the behaviour depends if the object parameter is a tuple or not. If it's a tuple, the tuple is unpacked. It's a little bit weird. I recall that it led to a bug in the implementation in generators in Python: issue #21209! Moreover, if the format string is "(...)", parenthesis are ignored. If you want to call a function with one argument which is a tuple, you have to write "((...))". It's a little bit weird, but we cannot change that without breaking the (Python) world :-)

call_stack-3.patch:

* I renamed the main function to _PyObject_FastCall()
* I added PyObject_CallNoArg(): call a function with no parameter
* I added Py_VaBuildStack() and _Py_VaBuildStack_SizeT() helpers for PyObject_Call*() functions using a format string
* I renamed the new slot to tp_fastcall

Nice change in the WITH_CLEANUP_START opcode (ceval.c):

-            /* XXX Not the fastest way to call it... */
-            res = PyObject_CallFunctionObjArgs(exit_func, exc, val, tb, NULL);

+            arg_stack[0] = exc;
+            arg_stack[1] = val;
+            arg_stack[2] = tb;
+            res = _PyObject_FastCall(exit_func, arg_stack, 3, 0);

I don't know if it's a common byetcode, nor if the change is really faster.

----------
title: Add a new _PyObject_CallStack() function which avoids the creation of a tuple or dict for arguments -> Add a new _PyObject_FastCall() function which avoids the creation of a tuple or dict for arguments
Added file: http://bugs.python.org/file42557/call_stack-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Thu Apr 21 11:05:13 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Apr 2016 15:05:13 +0000
Subject: [issue26814] Add a new _PyObject_FastCall() function which avoids the
 creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461251113.84.0.459335134548.issue26814@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I believe I got a very simple version of it working at one point, supporting positional parameters only, with some optional arguments.

Yeah, that would be a nice first step.

> p.s. My last name has two S's.  If you continue to leave off one of them, I shall remove one from yours, Mr. TINNER.

Ooops, I'm sorry Guido Hastings :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Thu Apr 21 11:56:10 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 21 Apr 2016 15:56:10 +0000
Subject: [issue7275] CoverageResult fails to merge input file with non-empty
 callers in trace.py
In-Reply-To: <1257531121.53.0.200338110704.issue7275@psf.upfronthosting.co.za>
Message-ID: <1461254170.3.0.877970075335.issue7275@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report and for the patch, Christian. Here is a patch with a test.

----------
nosy: +berker.peksag
title: CoverageResult fails to merge input file with non-empty callers in trace.py (patch) -> CoverageResult fails to merge input file with non-empty callers in trace.py
versions: +Python 3.5, Python 3.6 -Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file42558/issue7275.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7275>
_______________________________________

From report at bugs.python.org  Thu Apr 21 13:04:54 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Apr 2016 17:04:54 +0000
Subject: [issue26814] Add a new _PyObject_FastCall() function which avoids the
 creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461258294.02.0.780013432841.issue26814@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

PyObject_Call*() implementations with _PyObject_FastCall() look much more complex than with PyObject_Call() (even not counting additional complex functions in modsupport.c). And I'm not sure there is a benefit. May be for first stage we can do without this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Thu Apr 21 13:34:01 2016
From: report at bugs.python.org (Fulvio Esposito)
Date: Thu, 21 Apr 2016 17:34:01 +0000
Subject: [issue26819] _ProactorReadPipeTransport
 pause_reading()/resume_reading() broken if called before any read is perfored
Message-ID: <1461260041.01.0.731551553745.issue26819@psf.upfronthosting.co.za>


New submission from Fulvio Esposito:

Calling pause_reading()/resume_reading() on a _ProactorReadPipeTransport will result in an InvalidStateError('Result is not ready.') from a future if no read has been issued yet. The reason is that resume_reading() will schedule _loop_reading() a second time on the event loop. For example, currently aiomysql always fails to connect using a ProactorEventLoop on Windows because it calls pause_reading()/resume_reading() to set TCP_NODELAY on the socket just after connecting and before any read is performed.

----------
components: asyncio
files: pause_resume_test.py
messages: 263927
nosy: Fulvio Esposito, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: _ProactorReadPipeTransport pause_reading()/resume_reading() broken if called before any read is perfored
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file42559/pause_resume_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26819>
_______________________________________

From report at bugs.python.org  Thu Apr 21 13:55:05 2016
From: report at bugs.python.org (Andrew Clover)
Date: Thu, 21 Apr 2016 17:55:05 +0000
Subject: [issue16679] Add advice about non-ASCII wsgiref PATH_INFO
In-Reply-To: <1355473710.36.0.278942451351.issue16679@psf.upfronthosting.co.za>
Message-ID: <1461261305.6.0.692296553328.issue16679@psf.upfronthosting.co.za>


Andrew Clover added the comment:

> Why only PATH_INFO is encoded in such a manner, but QUERY_STRING is passed without any changes and does not requires any latin-1 to utf-8 recodings?

Laziness: QUERY_STRING should be pure-ASCII, making any such transcoding a no-op.

In principle a user agent *can* submit non-ASCII characters in a query string without %-encoding them, but it's not standards-conformant and most browsers don't usually do it (exception: apparently curl as above), so it's not worth adding a layer of hopefully-fixing-but-potentially-mangling to this variable to support a situation that shouldn't arise for normal requests.

PATH_INFO only requires special handling because of the sad, sad historical artefact of the CGI spec requiring it to have URL-decoding applied to it at the gateway, thus making the non-ASCII characters pop out of the percentage woodwork.

@Graham can you share more about how those test results were generated and displayed? The Gunicorn results are about what I would expect - the double-decoding of PATH_INFO is arguably undesirable when curl submits raw bytes, but ultimately that's an unspecified situation so I don't really case.

The output from Apache, on the other hand, is odd - something appears to have mangled the results at the reporting stage as not only is there double-decoding but also some double-backslashes. It looks like the strings have been put through ascii(repr()) or something?

----------
nosy: +Andrew Clover

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16679>
_______________________________________

From report at bugs.python.org  Thu Apr 21 14:36:47 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 21 Apr 2016 18:36:47 +0000
Subject: [issue26820] Prevent uses of format string based PyObject_Call* that
 do not produce tuple required by docs
Message-ID: <1461263807.63.0.49330886523.issue26820@psf.upfronthosting.co.za>


New submission from Josh Rosenberg:

PyObject_CallMethod explicitly documents that "The C arguments are described by a Py_BuildValue() format string that should produce a tuple." While PyObject_CallFunction doesn't document this requirement, it has the same behavior, and the same failures, as does the undocumented _PyObject_CallMethodId.

The issue is that, should someone pass a format string of "O", then the type of the subsequent argument determines the effect in a non-obvious way; when the argument comes from a caller, and the intent was to pass a single argument, this means that if the caller passes a non-tuple sequence, everything works, while passing a tuple tries to pass the contents of the tuple as sequential arguments. This inconsistency was the cause of both #26478 and #21209 (maybe others).

Assuming the API can't/shouldn't be changed, it should still be an error when a format string of "O" is passed and the argument is a non-tuple (because you've violated the spec; the result of BuildValue was not a tuple). Instead call_function_tail is silently rewrapping non-tuple args in a single element tuple.

I'm proposing that, in debug builds (and ideally release builds too), abstract.c's call_function_tail treat the "non-tuple" case as an error, rather than rewrapping in a single element tuple. This still allows the use case where the function is used inefficiently, but correctly (where the format string is "O" and the value is *always* a tuple that's supposed to be varargs; it should really just use PyObject_CallFunctionObjArgs/PyObject_CallMethodObjArgs/PyObject_CallObject or Id based optimized versions, but it's legal). But it will make the majority of cases where a user provided argument could be tuple or not fail fast, rather than silently behave themselves *until* they receive a tuple and misbehave.

Downside: It will require code changes for cases like PyObject_CallFunction(foo, "k", myunsigned);, where there was no risk of misbehavior, but those cases were also violating the spec, and should be fixable by changing the format string to wrap the single value in parens, e.g. "(k)".

----------
components: Interpreter Core
messages: 263929
nosy: haypo, josh.r
priority: normal
severity: normal
status: open
title: Prevent uses of format string based PyObject_Call* that do not produce tuple required by docs
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26820>
_______________________________________

From report at bugs.python.org  Thu Apr 21 14:42:08 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 21 Apr 2016 18:42:08 +0000
Subject: [issue26820] Prevent uses of format string based PyObject_Call* that
 do not produce tuple required by docs
In-Reply-To: <1461263807.63.0.49330886523.issue26820@psf.upfronthosting.co.za>
Message-ID: <1461264128.08.0.750983302622.issue26820@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

The motivation for this change was Mr. STINNER's comment on #26814 ( https://bugs.python.org/issue26814#msg263923 ), where he mentioned the weirdness of PyObject_CallFunction and friends, which complicates the implementation of PyObject_FastCall and alerted me to a second case ( #21209 ) in which this silent fix up has caused confusing issues in CPython (I filed #26478 so I recognized the issue).

If this fix could be made, it might be possible to eventually make the check for non-tuple arguments a debug build only check (or a check only on public APIs), allowing the implementation in release mode and/or internal APIs to avoid the work involved in constantly checking for and performing this workaround to fix doc violating code, and possible simplify PyObject_FastCall by removing the corner case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26820>
_______________________________________

From report at bugs.python.org  Thu Apr 21 15:07:41 2016
From: report at bugs.python.org (Jonathan Booth)
Date: Thu, 21 Apr 2016 19:07:41 +0000
Subject: [issue26821] array module "minimum size in bytes" table is wrong for
 int/long
Message-ID: <1461265661.42.0.761639464385.issue26821@psf.upfronthosting.co.za>


New submission from Jonathan Booth:

https://docs.python.org/3.5/library/array.html describes the 'I' and 'i' typecodes as being minimum-size in bytes of 2. The interpreter disagrees:

>>> import array
>>> a = array.array('i')
>>> a.itemsize
4

There is also a bug with the 'L' and 'l' long typecodes, which document as min-size of 4 bytes but are 8 bytes in the interpreter. That could be a bug in cPython itself though, as if 'L' should be 8 bytes, that disagrees with the type code sizing from the struct module, where it is 4 bytes, just like integers.

I checked documentation for all versions of python and it matches -- I did not check all python interpreters to see they match, but 2.7 and 3.5 did.

----------
assignee: docs at python
components: Documentation
messages: 263931
nosy: Jonathan Booth, docs at python
priority: normal
severity: normal
status: open
title: array module "minimum size in bytes" table is wrong for int/long
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/issue26821>
_______________________________________

From report at bugs.python.org  Thu Apr 21 15:17:04 2016
From: report at bugs.python.org (Sylvain Corlay)
Date: Thu, 21 Apr 2016 19:17:04 +0000
Subject: [issue26689] Add `has_flag` method to `distutils.CCompiler`
In-Reply-To: <1459643481.74.0.720699620632.issue26689@psf.upfronthosting.co.za>
Message-ID: <1461266224.19.0.477394093444.issue26689@psf.upfronthosting.co.za>


Sylvain Corlay added the comment:

Hey, any blocker to getting this in?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26689>
_______________________________________

From report at bugs.python.org  Thu Apr 21 15:23:41 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Apr 2016 19:23:41 +0000
Subject: [issue26822] itemgetter/attrgetter/methodcaller objects ignore
 keyword arguments
Message-ID: <1461266621.67.0.0664681491354.issue26822@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

itemgetter(), attrgetter() and methodcaller() objects require one argument. They raise TypeError if less or more than one positional argument is provided. But they totally ignore any keyword arguments.

>>> import operator
>>> f = operator.itemgetter(1)
>>> f('abc', spam=3)
'b'
>>> f = operator.attrgetter('index')
>>> f('abc', spam=3)
<built-in method index of str object at 0xb7172b20>
>>> f = operator.methodcaller('upper')
>>> f('abc', spam=3)
'ABC'

Proposed patch makes these objects raise TypeError if keyword arguments are provided.

----------
components: Extension Modules
files: operator_getters_kwargs.patch
keywords: patch
messages: 263933
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: itemgetter/attrgetter/methodcaller objects ignore keyword arguments
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42560/operator_getters_kwargs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26822>
_______________________________________

From report at bugs.python.org  Thu Apr 21 15:54:39 2016
From: report at bugs.python.org (Graham Dumpleton)
Date: Thu, 21 Apr 2016 19:54:39 +0000
Subject: [issue16679] Add advice about non-ASCII wsgiref PATH_INFO
In-Reply-To: <1355473710.36.0.278942451351.issue16679@psf.upfronthosting.co.za>
Message-ID: <1461268479.21.0.0628001576877.issue16679@psf.upfronthosting.co.za>


Graham Dumpleton added the comment:

Double back slashes would possibly be an artefact of the some mess that happens when logging out through the Apache error log.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16679>
_______________________________________

From report at bugs.python.org  Thu Apr 21 16:36:08 2016
From: report at bugs.python.org (random832)
Date: Thu, 21 Apr 2016 20:36:08 +0000
Subject: [issue26821] array module "minimum size in bytes" table is wrong for
 int/long
In-Reply-To: <1461265661.42.0.761639464385.issue26821@psf.upfronthosting.co.za>
Message-ID: <1461270968.04.0.0972980027032.issue26821@psf.upfronthosting.co.za>


random832 added the comment:

It says *minimum* size for a reason. The *actual* sizes of the types used in array are platform-dependent. 2 is the smallest that an int can be (it is probably not that size on any currently supported platforms, but would have been in DOS), and 4 is the smallest size a long can be (any 32-bit python build, and I think also any build on Windows, will have it be this size).

----------
nosy: +random832

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26821>
_______________________________________

From report at bugs.python.org  Thu Apr 21 18:15:03 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 21 Apr 2016 22:15:03 +0000
Subject: [issue26822] itemgetter/attrgetter/methodcaller objects ignore
 keyword arguments
In-Reply-To: <1461266621.67.0.0664681491354.issue26822@psf.upfronthosting.co.za>
Message-ID: <1461276903.6.0.819553999336.issue26822@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Seems sensible for itemgetter and attrgetter, where all but the first argument is nonsensical anyway.

It really seems like methodcaller should allow additional arguments (positional and keyword though), a la functools.partial (the difference being the support for duck-typed methods, where functools.partial only supports unbound methods for a specific type). I suppose #25454 disagrees, but it seems very strange how `methodcaller` is like `functools.partial`, but without call time argument binding, only definition time.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26822>
_______________________________________

From report at bugs.python.org  Thu Apr 21 18:21:31 2016
From: report at bugs.python.org (Julian Taylor)
Date: Thu, 21 Apr 2016 22:21:31 +0000
Subject: [issue26601] Use new madvise()'s MADV_FREE on the private heap
In-Reply-To: <1458557514.95.0.774301964914.issue26601@psf.upfronthosting.co.za>
Message-ID: <1461277291.73.0.399884519648.issue26601@psf.upfronthosting.co.za>


Julian Taylor added the comment:

simplest way to fix this would be to not use malloc instead of mmap in the allocator, then you also get MADV_FREE for free when malloc uses it.
The rational for using mmap is kind of weak, the source just says "heap fragmentation". The usual argument for using mmap is not that but the instant return of memory to the system, quite the opposite of what the python memory pool does.

----------
nosy: +jtaylor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26601>
_______________________________________

From report at bugs.python.org  Thu Apr 21 18:25:03 2016
From: report at bugs.python.org (Jonathan Booth)
Date: Thu, 21 Apr 2016 22:25:03 +0000
Subject: [issue26821] array module "minimum size in bytes" table is wrong for
 int/long
In-Reply-To: <1461265661.42.0.761639464385.issue26821@psf.upfronthosting.co.za>
Message-ID: <1461277503.01.0.139322535648.issue26821@psf.upfronthosting.co.za>


Jonathan Booth added the comment:

Ugly -- if I know I'm dealing with 4-byte data, I can't just specify 'I' or 'L' because it'll be wrong on some platform? Maybe the bug is really the module's design. Seems I need to look elsewhere for other reasons (array seems to want to copy memory, rather than sharing it, so I can't get two arrays one int, one byte with the same backing memory where changes to one effect the other), but that's all the more argument for me to switch off array anyway.

In any case, take it as the documentation wasn't particularly clear.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26821>
_______________________________________

From report at bugs.python.org  Thu Apr 21 18:39:22 2016
From: report at bugs.python.org (David Wilson)
Date: Thu, 21 Apr 2016 22:39:22 +0000
Subject: [issue26601] Use new madvise()'s MADV_FREE on the private heap
In-Reply-To: <1458557514.95.0.774301964914.issue26601@psf.upfronthosting.co.za>
Message-ID: <1461278362.09.0.911733427253.issue26601@psf.upfronthosting.co.za>


David Wilson added the comment:

@Julian note that ARENA_SIZE is double the threshold after which at least glibc resorts to calling mmap directly, so using malloc in place of mmap on at least Linux would have zero effect

----------
nosy: +dw

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26601>
_______________________________________

From report at bugs.python.org  Thu Apr 21 19:11:12 2016
From: report at bugs.python.org (Julian Taylor)
Date: Thu, 21 Apr 2016 23:11:12 +0000
Subject: [issue26601] Use new madvise()'s MADV_FREE on the private heap
In-Reply-To: <1458557514.95.0.774301964914.issue26601@psf.upfronthosting.co.za>
Message-ID: <1461280272.21.0.714082796183.issue26601@psf.upfronthosting.co.za>


Julian Taylor added the comment:

ARENA_SIZE is 256kb, the threshold in glibc is up to 32 MB

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26601>
_______________________________________

From report at bugs.python.org  Thu Apr 21 19:16:07 2016
From: report at bugs.python.org (David Wilson)
Date: Thu, 21 Apr 2016 23:16:07 +0000
Subject: [issue26601] Use new madvise()'s MADV_FREE on the private heap
In-Reply-To: <1458557514.95.0.774301964914.issue26601@psf.upfronthosting.co.za>
Message-ID: <1461280567.0.0.86895061108.issue26601@psf.upfronthosting.co.za>


David Wilson added the comment:

It defaults to 128kb, and messing with global state like the system allocator is a fine way to tempt regressions in third party code

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26601>
_______________________________________

From report at bugs.python.org  Thu Apr 21 19:18:34 2016
From: report at bugs.python.org (Julian Taylor)
Date: Thu, 21 Apr 2016 23:18:34 +0000
Subject: [issue26601] Use new madvise()'s MADV_FREE on the private heap
In-Reply-To: <1458557514.95.0.774301964914.issue26601@psf.upfronthosting.co.za>
Message-ID: <1461280714.05.0.405590153762.issue26601@psf.upfronthosting.co.za>


Julian Taylor added the comment:

it defaulted to 128kb ten years ago, its a dynamic threshold since ages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26601>
_______________________________________

From report at bugs.python.org  Thu Apr 21 20:06:00 2016
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 22 Apr 2016 00:06:00 +0000
Subject: [issue26800] Don't accept bytearray as filenames part 2
In-Reply-To: <1461015295.39.0.246147143774.issue26800@psf.upfronthosting.co.za>
Message-ID: <1461283560.66.0.616591479603.issue26800@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I did the path_converter change.  IIRC some functions supported bytearray, some did not, and in my quest for consistency I took the superset of functionality and supported bytearray for everything.

Sounds to me like bytearray support should be dropped, but ultimately I don't have a strong opinion.  I'm happy to sit back and let the more opinionated decide the matter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26800>
_______________________________________

From report at bugs.python.org  Thu Apr 21 20:19:46 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Apr 2016 00:19:46 +0000
Subject: [issue26800] Don't accept bytearray as filenames part 2
In-Reply-To: <1461283560.66.0.616591479603.issue26800@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYf1ZzGXSyrYFKjTi3=0cpQ7qCgaBgTVjeEcE63TrZRGg@mail.gmail.com>


STINNER Victor added the comment:

bytearray is designed for performance. I don't think that the code
creating a filename can be a bottleneck in an application.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26800>
_______________________________________

From report at bugs.python.org  Thu Apr 21 20:26:44 2016
From: report at bugs.python.org (Jeremy Kloth)
Date: Fri, 22 Apr 2016 00:26:44 +0000
Subject: [issue26820] Prevent uses of format string based PyObject_Call* that
 do not produce tuple required by docs
In-Reply-To: <1461263807.63.0.49330886523.issue26820@psf.upfronthosting.co.za>
Message-ID: <1461284804.98.0.248527775323.issue26820@psf.upfronthosting.co.za>


Jeremy Kloth added the comment:

IMHO, this is a documentation bug with PyObject_CallMethod.  The change to its documentation to differ from PyObject_CallFunction was changed back in 2004.  It should have been updated then to reflect the already well-entrenched behavior of those 2 (at the time) functions, but that ship has sailed.

It would be a huge mistake to change how they handle the format strings now as they have operated they way they have since at least Python 1.5.2 (when I learned Python's C API).  There is just too much C code that would potentially break (third-party C extensions).

I think that a good change for the docs would be to separate the specification of the "building format string" away from the Py_BuildValue function so as to allow for differences in how the resulting object is created in those C functions that use that specification.  Similar, I suppose, to how the "parsing format string" is defined independently from PyArg_ParseTuple.

Now to the "attractive nuisance" that the single argument passed as varargs is handled.  I believe it may be best to introduce a new format character just for this purpose.  Possibly "T" (for tuple) or "V" (for varargs) using uppercase as that seems to be the practice for referencing objects.  And at the same time, add a check in the "call" functions (those that *use* Py_VaBuildValue to create a argument tuple, of which there are also internal ones).  The check could be as simple as:

  if (format[0] == 'O' && format[1] == '\0') {
    va_start(va, format);
    PyObject *ob = (PyObject *)va_arg(va, PyObject *);
    if (ob != NULL) {
      if (PyTuple_Check(ob)) {
        if (PyErr_WarnFormat(PyExc_DeprecationWarning, 1,
                "use 'V' format code to support varargs")) {
          args = NULL;
        }
        else {
          args = ob;
        }
      }
      else {
        args = PyTuple_Pack(1, ob);
      }
    }
    else if (!PyErr_Occurred()) {
      PyErr_SetString(PyExc_SystemError, "argument is NULL");
      args = NULL;
    }
    va_end(va);
  }
  else {
    args = //...whatever happens now...
  }

----------
nosy: +jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26820>
_______________________________________

From report at bugs.python.org  Thu Apr 21 20:34:02 2016
From: report at bugs.python.org (Luiz Poleto)
Date: Fri, 22 Apr 2016 00:34:02 +0000
Subject: [issue26041] Update deprecation messages of platform.dist() and
 platform.linux_distribution()
In-Reply-To: <1452187100.03.0.384540652472.issue26041@psf.upfronthosting.co.za>
Message-ID: <1461285242.35.0.968771571873.issue26041@psf.upfronthosting.co.za>


Changes by Luiz Poleto <luiz.poleto at gmail.com>:


----------
nosy: +luiz.poleto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26041>
_______________________________________

From report at bugs.python.org  Thu Apr 21 20:41:28 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Apr 2016 00:41:28 +0000
Subject: [issue26814] Add a new _PyObject_FastCall() function which avoids the
 creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461285688.99.0.224565628771.issue26814@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
hgrepos: +342

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Thu Apr 21 20:44:11 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Apr 2016 00:44:11 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461285851.17.0.00196294212081.issue26814@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I created a repository. I will work there and make some experiment. It would help to have a better idea of the concrete performance. When I will have a better view of all requires changes to get best performances everywhere, I will start a discussion to see which parts are worth it or not. In my latest microbenchmarks, functions calls (C/Python, mixed) are between 8% and 40% faster. I'm now running the CPython benchmark suite.

----------
title: Add a new _PyObject_FastCall() function which avoids the creation of a tuple or dict for arguments -> [WIP] Add a new _PyObject_FastCall() function which avoids the creation of a tuple or dict for arguments

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Thu Apr 21 22:27:43 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 22 Apr 2016 02:27:43 +0000
Subject: [issue26822] itemgetter/attrgetter/methodcaller objects ignore
 keyword arguments
In-Reply-To: <1461266621.67.0.0664681491354.issue26822@psf.upfronthosting.co.za>
Message-ID: <1461292063.05.0.435880073742.issue26822@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

This makes sense. It makes the C version and Python version consistent.

----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26822>
_______________________________________

From report at bugs.python.org  Thu Apr 21 22:36:25 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Fri, 22 Apr 2016 02:36:25 +0000
Subject: [issue26823] Shrink recursive tracebacks
Message-ID: <1461292585.22.0.159887337407.issue26823@psf.upfronthosting.co.za>


New submission from Emanuel Barry:

I recently suggested on Python-ideas ( https://mail.python.org/pipermail/python-ideas/2016-April/039899.html ) to shrink long tracebacks if they were all the same noise (recursive calls). Seeing as the idea had a good reception, I went ahead and implemented a small patch for this.

It doesn't keep track of call chains, and I'm not sure if we want to implement that, as the performance decrease needed to store all of that might not be worth it. But then again, if an error happened performance is probably not a concern in this case.

I've never really coded in C before, so feedback is very much welcome.

----------
components: Interpreter Core
files: short_tracebacks.patch
keywords: patch
messages: 263948
nosy: ebarry
priority: normal
severity: normal
stage: patch review
status: open
title: Shrink recursive tracebacks
versions: Python 3.6
Added file: http://bugs.python.org/file42561/short_tracebacks.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26823>
_______________________________________

From report at bugs.python.org  Thu Apr 21 22:39:36 2016
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 22 Apr 2016 02:39:36 +0000
Subject: [issue26823] Shrink recursive tracebacks
In-Reply-To: <1461292585.22.0.159887337407.issue26823@psf.upfronthosting.co.za>
Message-ID: <1461292776.59.0.486497831431.issue26823@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/issue26823>
_______________________________________

From report at bugs.python.org  Thu Apr 21 22:44:41 2016
From: report at bugs.python.org (Chris Angelico)
Date: Fri, 22 Apr 2016 02:44:41 +0000
Subject: [issue26823] Shrink recursive tracebacks
In-Reply-To: <1461292585.22.0.159887337407.issue26823@psf.upfronthosting.co.za>
Message-ID: <1461293081.44.0.326015086406.issue26823@psf.upfronthosting.co.za>


Chris Angelico added the comment:

By "doesn't keep track of call chains", you mean that it can't handle mutually-recursive functions, right?

Still useful.

----------
nosy: +Rosuav

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26823>
_______________________________________

From report at bugs.python.org  Thu Apr 21 22:47:18 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Fri, 22 Apr 2016 02:47:18 +0000
Subject: [issue26823] Shrink recursive tracebacks
In-Reply-To: <1461292585.22.0.159887337407.issue26823@psf.upfronthosting.co.za>
Message-ID: <1461293238.58.0.642205422047.issue26823@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Yes, can't handle mutually recursive functions. I could maybe check for the last two or three functions, but that seems like unnecessary work for something that might not happen as often (I can see it being the case with e.g. __getattr__ though).

If enough people think it should keep track of all or most functions being called, I can do it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26823>
_______________________________________

From report at bugs.python.org  Thu Apr 21 22:48:54 2016
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 22 Apr 2016 02:48:54 +0000
Subject: [issue26823] Shrink recursive tracebacks
In-Reply-To: <1461292585.22.0.159887337407.issue26823@psf.upfronthosting.co.za>
Message-ID: <1461293334.26.0.881506957737.issue26823@psf.upfronthosting.co.za>


Ethan Furman added the comment:

If you can, give it a go.  Make it a new patch, though -- don't delete the existing one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26823>
_______________________________________

From report at bugs.python.org  Thu Apr 21 22:49:09 2016
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 22 Apr 2016 02:49:09 +0000
Subject: [issue26823] Shrink recursive tracebacks
In-Reply-To: <1461292585.22.0.159887337407.issue26823@psf.upfronthosting.co.za>
Message-ID: <1461293349.02.0.849789160913.issue26823@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26823>
_______________________________________

From report at bugs.python.org  Thu Apr 21 22:49:28 2016
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 22 Apr 2016 02:49:28 +0000
Subject: [issue26823] Shrink recursive tracebacks
In-Reply-To: <1461292585.22.0.159887337407.issue26823@psf.upfronthosting.co.za>
Message-ID: <1461293368.75.0.562225364321.issue26823@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26823>
_______________________________________

From report at bugs.python.org  Thu Apr 21 22:59:12 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 22 Apr 2016 02:59:12 +0000
Subject: [issue26823] Shrink recursive tracebacks
In-Reply-To: <1461292585.22.0.159887337407.issue26823@psf.upfronthosting.co.za>
Message-ID: <1461293952.74.0.535140664308.issue26823@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

With the current patch, a simple test gives the traceback:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in test
  File "<stdin>", line 2, in test
  File "<stdin>", line 2, in test
  [Previous message repeated 995 more times]
RecursionError: maximum recursion depth exceeded

I think the message [Previous message repeated 995 more times] is vague. Does it refer to the previous line or the whole previous messages? Hmm, at least it is vague for me, a non-native English speaker.

----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26823>
_______________________________________

From report at bugs.python.org  Thu Apr 21 23:02:43 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Fri, 22 Apr 2016 03:02:43 +0000
Subject: [issue26823] Shrink recursive tracebacks
In-Reply-To: <1461292585.22.0.159887337407.issue26823@psf.upfronthosting.co.za>
Message-ID: <1461294163.18.0.489944345121.issue26823@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

The message is mostly a placeholder, but "message" is singular so I figured it would be obvious. But alas, if you are confused, others might be too. Propositions for a better message are welcome :)

I'll attempt to make it track chained calls (or mutually recursive functions) tomorrow, my sleep-deprived brain is unable to find a clean way to do this right now :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26823>
_______________________________________

From report at bugs.python.org  Thu Apr 21 23:29:52 2016
From: report at bugs.python.org (Luiz Poleto)
Date: Fri, 22 Apr 2016 03:29:52 +0000
Subject: [issue22234] urllib.parse.urlparse accepts any falsy value as an url
In-Reply-To: <1408538391.97.0.53072227801.issue22234@psf.upfronthosting.co.za>
Message-ID: <1461295792.62.0.81481068309.issue22234@psf.upfronthosting.co.za>


Changes by Luiz Poleto <luiz.poleto at gmail.com>:


----------
nosy: +luiz.poleto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22234>
_______________________________________

From report at bugs.python.org  Thu Apr 21 23:46:02 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 22 Apr 2016 03:46:02 +0000
Subject: [issue26823] Shrink recursive tracebacks
In-Reply-To: <1461292585.22.0.159887337407.issue26823@psf.upfronthosting.co.za>
Message-ID: <1461296762.91.0.470605737646.issue26823@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

+1 for the simple approach, and deferring the mutual recursion support - it's desirable to keep traceback printing simple in order to minimise the chance for failures during the display process.

In addition to the C implementation of traceback printing, the standard library's traceback module would also need updating.

Regarding the ambiguity of "Previous message", I'd suggest using "Previous line" instead - that way it's accurate regardless of whether people read it as "previous line of the traceback" or "previous line of quoted source code".

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26823>
_______________________________________

From report at bugs.python.org  Fri Apr 22 00:25:51 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Fri, 22 Apr 2016 04:25:51 +0000
Subject: [issue26823] Shrink recursive tracebacks
In-Reply-To: <1461292585.22.0.159887337407.issue26823@psf.upfronthosting.co.za>
Message-ID: <1461299151.4.0.958645267908.issue26823@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Attached patch also modifies Lib/traceback.py to present identical behaviour, and changes "Previous message" to "Previous line". I'll postpone the more complex implementation of that, and might just not do it as it's indeed better to avoid bugs where we're meant to handle bugs =)

Should there be unit tests for that? I'm really not sure how to write tests for that particular case...

----------
Added file: http://bugs.python.org/file42562/short_tracebacks_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26823>
_______________________________________

From report at bugs.python.org  Fri Apr 22 00:54:50 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 22 Apr 2016 04:54:50 +0000
Subject: [issue26824] Make some macros use Py_TYPE
Message-ID: <1461300890.73.0.522492647874.issue26824@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

According to PEP3123, all accesses to ob_refcnt and ob_type MUST cast the object pointer to PyObject* (unless the pointer is already known to have that type), and SHOULD use the respective accessor macros.

I find that there are still some macros in Python use (obj)->ob_type. Though right now they may not impose any error, but as macros, they may be used with arguments not of type PyObject* later and introduce errors. So I think change them to use Py_TYPE is not a bad idea.

----------
files: change_some_macros_using_Py_TYPE.patch
keywords: patch
messages: 263956
nosy: serhiy.storchaka, xiang.zhang
priority: normal
severity: normal
status: open
title: Make some macros use Py_TYPE
Added file: http://bugs.python.org/file42563/change_some_macros_using_Py_TYPE.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26824>
_______________________________________

From report at bugs.python.org  Fri Apr 22 00:58:11 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 22 Apr 2016 04:58:11 +0000
Subject: [issue26824] Make some macros use Py_TYPE
In-Reply-To: <1461300890.73.0.522492647874.issue26824@psf.upfronthosting.co.za>
Message-ID: <1461301091.86.0.977160342909.issue26824@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
type:  -> enhancement
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26824>
_______________________________________

From report at bugs.python.org  Fri Apr 22 01:08:56 2016
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 22 Apr 2016 05:08:56 +0000
Subject: [issue26821] array module "minimum size in bytes" table is wrong for
 int/long
In-Reply-To: <1461265661.42.0.761639464385.issue26821@psf.upfronthosting.co.za>
Message-ID: <1461301736.42.0.0901839317311.issue26821@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Indeed, I don't think the `array` module is much used anymore.

If you're looking to serialize or deserialize fixed-size formats, you'll probably want the `struct` module.  It has both native and fixed-size modes.

For anything else involving arrays (mostly, but not exclusively, of numbers), just use numpy.  It has a much more developed system of data types for its arrays, and supports views.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26821>
_______________________________________

From report at bugs.python.org  Fri Apr 22 01:22:21 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Apr 2016 05:22:21 +0000
Subject: [issue26821] array module "minimum size in bytes" table is wrong for
 int/long
In-Reply-To: <1461265661.42.0.761639464385.issue26821@psf.upfronthosting.co.za>
Message-ID: <1461302541.68.0.643379416425.issue26821@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> I can't get two arrays one int, one byte with the same backing memory where changes to one effect the other

For this case you can use an array or bytearray + memoryview.

I think this issue can be closed.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26821>
_______________________________________

From report at bugs.python.org  Fri Apr 22 01:23:55 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 22 Apr 2016 05:23:55 +0000
Subject: [issue26823] Shrink recursive tracebacks
In-Reply-To: <1461292585.22.0.159887337407.issue26823@psf.upfronthosting.co.za>
Message-ID: <1461302635.09.0.0412746766523.issue26823@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

For testing, you can create a recursive scenario that terminates with an exception after a defined number of iterations:

>>> def f(counter):
...     if counter:
...         f(counter-1)
...     else:
...         raise RuntimeError
... 
>>> f(3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in f
  File "<stdin>", line 3, in f
  File "<stdin>", line 3, in f
  File "<stdin>", line 5, in f
RuntimeError

It's probably also worth checking the handling of two distinct frame repetitions by having another recursion counter that terminates itself by calling the one that terminates by raising an exception

Beyond that, https://hg.python.org/cpython/file/tip/Lib/test/test_traceback.py covers both traceback formatting implementations, so a new test case in TracebackFormatTests seems appropriate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26823>
_______________________________________

From report at bugs.python.org  Fri Apr 22 01:27:21 2016
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 22 Apr 2016 05:27:21 +0000
Subject: [issue26821] array module "minimum size in bytes" table is wrong for
 int/long
In-Reply-To: <1461265661.42.0.761639464385.issue26821@psf.upfronthosting.co.za>
Message-ID: <1461302841.61.0.65663521978.issue26821@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Agreed.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26821>
_______________________________________

From report at bugs.python.org  Fri Apr 22 02:03:49 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Apr 2016 06:03:49 +0000
Subject: [issue26824] Make some macros use Py_TYPE
In-Reply-To: <1461300890.73.0.522492647874.issue26824@psf.upfronthosting.co.za>
Message-ID: <1461305029.09.0.639964917048.issue26824@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In Python 2.6 PyObject_HEAD was defined as

#define PyObject_HEAD                   \
    _PyObject_HEAD_EXTRA                \
    Py_ssize_t ob_refcnt;               \
    struct _typeobject *ob_type;

Every extension type structure contained fields ob_refcnt and ob_type. For the pointer of type (FooObject *) you used foo->ob_refcnt and foo->ob_type. You could also use ob = (PyObject *)foo; ob->ob_type, but this is undefined behavior, as estimated in PEP3123.

Now PyObject_HEAD is defined as

#define PyObject_HEAD                   PyObject ob_base;

Every extension type structure no longer contain fields ob_refcnt and ob_type, and you can't access them directly. For convenience and compatibility with 2.6 there were added macros Py_TYPE() and Py_REFCNT(). Direct access to ob_refcnt and ob_type is legal, just your can't use it with arbitrary pointer type without casting it to PyObject*. That just can't be compiled. If you have a pointer of type PyObject*, you can use direct access to ob_refcnt and ob_type.

Direct access to ob_type is used about 300 times in the source code. Changing all this case to use the Py_TYPE() macro causes code churn.

There is different situation with ob_refcnt. It is less used, and changing the code to use Py_REFCNT() causes less code churn. But this can make the code looks more pretty. Here is a patch (written a day ago) that makes the code to use Py_REFCNT(). I was not sure about the code that directly modifies the reference count and left it unchanged. I'm not sure that it is worth to apply this patch, may be it still makes too much code churn.

----------
components: +Extension Modules, Interpreter Core
nosy: +loewis, ned.deily, rhettinger
stage:  -> patch review
Added file: http://bugs.python.org/file42564/py_refcnt.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26824>
_______________________________________

From report at bugs.python.org  Fri Apr 22 02:09:13 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Apr 2016 06:09:13 +0000
Subject: [issue26822] itemgetter/attrgetter/methodcaller objects ignore
 keyword arguments
In-Reply-To: <1461266621.67.0.0664681491354.issue26822@psf.upfronthosting.co.za>
Message-ID: <1461305353.82.0.626297955048.issue26822@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> It really seems like methodcaller should allow additional arguments (positional and keyword though)

This is good argument for raising an exception. Wrong expectations can lead to incorrect code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26822>
_______________________________________

From report at bugs.python.org  Fri Apr 22 02:10:19 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 22 Apr 2016 06:10:19 +0000
Subject: [issue26824] Make some macros use Py_TYPE
In-Reply-To: <1461300890.73.0.522492647874.issue26824@psf.upfronthosting.co.za>
Message-ID: <1461305419.03.0.877388394672.issue26824@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

No, actually I don't mean to change all the (obj)->ob_type in Python repo. I know there are more (obj)->ob_type in it, but they are compliant with PEP3123 since obj is of type PyObject*. You don't have the need to change them. What I propose is only to change the macros that not use Py_TYPE since the macros may be used later with arguments not of type PyObject*.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26824>
_______________________________________

From report at bugs.python.org  Fri Apr 22 02:15:15 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 22 Apr 2016 06:15:15 +0000
Subject: [issue26824] Make some macros use Py_TYPE
In-Reply-To: <1461300890.73.0.522492647874.issue26824@psf.upfronthosting.co.za>
Message-ID: <1461305715.58.0.524576457516.issue26824@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I also inspect Py_REFCNT and Py_SIZE. I don't think there is need to replace (obj)->ob_refcnt since they are legal. 

So my intention is only several macros need to be altered and won't make too much code churn.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26824>
_______________________________________

From report at bugs.python.org  Fri Apr 22 02:34:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Apr 2016 06:34:40 +0000
Subject: [issue26824] Make some macros use Py_TYPE
In-Reply-To: <1461300890.73.0.522492647874.issue26824@psf.upfronthosting.co.za>
Message-ID: <1461306880.12.0.788614846073.issue26824@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ah, sorry. This makes sense.

But there is one catch. If allow a macro to be used with an argument not of type PyObject*, this will make harder to change the implementation and convert the macro to a function.

And this may increase the probability to make an error with calling macros with wrong argument.

I have no strong opinion about this patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26824>
_______________________________________

From report at bugs.python.org  Fri Apr 22 02:48:49 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 22 Apr 2016 06:48:49 +0000
Subject: [issue26824] Make some macros use Py_TYPE
In-Reply-To: <1461300890.73.0.522492647874.issue26824@psf.upfronthosting.co.za>
Message-ID: <1461307729.01.0.189719995481.issue26824@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Good point. I don't think about that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26824>
_______________________________________

From report at bugs.python.org  Fri Apr 22 02:54:50 2016
From: report at bugs.python.org (ganix)
Date: Fri, 22 Apr 2016 06:54:50 +0000
Subject: [issue26825] Variable defined in exec(code) unreachable inside
 function call with visible name in dir() results
Message-ID: <1461308090.16.0.606527103016.issue26825@psf.upfronthosting.co.za>


New submission from ganix:

here is a code show what happend:
>>> def func():
	exec('ans=1')
	print(dir())
	return ans

>>> func()
['ans']
Traceback (most recent call last):
  File "<pyshell#5>", line 1, in <module>
    func()
  File "<pyshell#4>", line 4, in func
    return ans
NameError: name 'ans' is not defined

i tried this code in version 2.7,it is ok

----------
components: Argument Clinic
messages: 263967
nosy: 324857679, larry
priority: normal
severity: normal
status: open
title: Variable defined in exec(code) unreachable inside function call with visible name in dir() results
type: crash
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26825>
_______________________________________

From report at bugs.python.org  Fri Apr 22 02:56:08 2016
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 22 Apr 2016 06:56:08 +0000
Subject: [issue26601] Use new madvise()'s MADV_FREE on the private heap
In-Reply-To: <1461280714.05.0.405590153762.issue26601@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1isJQLB_qMh=49mfaq1LpuzWDXfH9fQ5kFhvvVCP5+dQ@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Julian Taylor added the comment:
>
> it defaulted to 128kb ten years ago, its a dynamic threshold since ages.

Indeed, and that's what encouraged switching the allocator to use mmap.
The problem with dynamic mmap threshold is that since the Python
allocator uses fixed-size arenas, basically malloc always ends up
allocating from the heap (brk).
Which means that given that we don't use a - compacting - garbage
collector, after a while the heap would end up quite fragmented, or
never shrink: for example let's say you allocate 1GB - on the heap -
and then you free them, but  a single object is allocated at the top
of the heap, you heap never shrinks back.
This has bitten people (and myself a couple times at work).

Now, I see several options:
- revert to using malloc, but this will re-introduce the original problem
- build some form of hysteresis in the arena allocation
- somewhat orthogonally, I'd be interested to see if we couldn't
increase the arena size

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26601>
_______________________________________

From report at bugs.python.org  Fri Apr 22 03:00:28 2016
From: report at bugs.python.org (Hans-Peter Jansen)
Date: Fri, 22 Apr 2016 07:00:28 +0000
Subject: [issue26804] Prioritize lowercase proxy variables in urllib.request
In-Reply-To: <1461053909.86.0.0123928931795.issue26804@psf.upfronthosting.co.za>
Message-ID: <1461308428.41.0.0436521608129.issue26804@psf.upfronthosting.co.za>


Hans-Peter Jansen added the comment:

v5: don't require the proxies argument in proxy_bypass_environment()

----------
Added file: http://bugs.python.org/file42565/python-urllib-prefer-lowercase-proxies-v5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26804>
_______________________________________

From report at bugs.python.org  Fri Apr 22 03:16:13 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Apr 2016 07:16:13 +0000
Subject: [issue26824] Make some macros use Py_TYPE
In-Reply-To: <1461300890.73.0.522492647874.issue26824@psf.upfronthosting.co.za>
Message-ID: <1461309373.54.0.903615166204.issue26824@psf.upfronthosting.co.za>


STINNER Victor added the comment:

change_some_macros_using_Py_TYPE.patch LGTM.

> Direct access to ob_type is used about 300 times in the source code. Changing all this case to use the Py_TYPE() macro causes code churn.

IHMO change_some_macros_using_Py_TYPE.patch makes the code more readable since it's harder and easier to read.

Note: Such refactoring patch must only be applied to the development branch (default).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26824>
_______________________________________

From report at bugs.python.org  Fri Apr 22 03:18:10 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Apr 2016 07:18:10 +0000
Subject: [issue26824] Make some macros use Py_TYPE
In-Reply-To: <1461300890.73.0.522492647874.issue26824@psf.upfronthosting.co.za>
Message-ID: <1461309490.46.0.20201701993.issue26824@psf.upfronthosting.co.za>


STINNER Victor added the comment:

py_refcnt.diff also LGTM, go ahead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26824>
_______________________________________

From report at bugs.python.org  Fri Apr 22 03:21:03 2016
From: report at bugs.python.org (lissacoffey)
Date: Fri, 22 Apr 2016 07:21:03 +0000
Subject: [issue20962] Rather modest chunk size in gzip.GzipFile
In-Reply-To: <1395082726.87.0.730756156096.issue20962@psf.upfronthosting.co.za>
Message-ID: <1461309663.5.0.961385061307.issue20962@psf.upfronthosting.co.za>


lissacoffey added the comment:

I measured both the total time of the run, the time to process each input records, and time to execute just the seek() call for each record. The bulk of the per-record time was in the call to seek(), so by reducing that time, I sped up my run-times significantly.
Thanks
http://qwikfix.co.uk/barclays/

----------
nosy: +editor-buzzfeed
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20962>
_______________________________________

From report at bugs.python.org  Fri Apr 22 03:27:32 2016
From: report at bugs.python.org (lissacoffey)
Date: Fri, 22 Apr 2016 07:27:32 +0000
Subject: [issue6792] Distutils-based installer does not detect 64bit versions
 of Python
In-Reply-To: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za>
Message-ID: <1461310052.72.0.277235697851.issue6792@psf.upfronthosting.co.za>


lissacoffey added the comment:

This bug is a really annoying one, any chance it will be fixed in 2.7? It's really a matter when you want to deploy a program using distutils (my case), because you cannot really require your clients to edit the registry themselves :/
Thanks
http://www.fixithere.net/sky-contact-number/

----------
nosy: +editor-buzzfeed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6792>
_______________________________________

From report at bugs.python.org  Fri Apr 22 03:40:49 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 22 Apr 2016 07:40:49 +0000
Subject: [issue26822] itemgetter/attrgetter/methodcaller objects ignore
 keyword arguments
In-Reply-To: <1461266621.67.0.0664681491354.issue26822@psf.upfronthosting.co.za>
Message-ID: <1461310849.44.0.752290833717.issue26822@psf.upfronthosting.co.za>


Martin Panter added the comment:

This seems like a good change, and the patch looks correct.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26822>
_______________________________________

From report at bugs.python.org  Fri Apr 22 03:44:31 2016
From: report at bugs.python.org (lissacoffey)
Date: Fri, 22 Apr 2016 07:44:31 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1461311071.05.0.397567875695.issue19846@psf.upfronthosting.co.za>


lissacoffey added the comment:

Using an environment variable is not the holy grail for this. On writing a non-single-user application you can't expect the user to set extra environment variables.

If compatibility is the only reason in my opinion it would be much better to include something like sys.use_strict_encoding() which decides if print()/write() will use sys.getfilesystemencoding() or sys.getdefaultencoding().
thanks
Lisa
mysite: http://www.fixithere.net/sky-contact-number/

----------
nosy: +editor-buzzfeed -Sworddragon, a.badger, bkabrda, haypo, jwilk, larry, lemburg, loewis, ncoghlan, pitrou, r.david.murray, serhiy.storchaka, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Fri Apr 22 03:45:36 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 22 Apr 2016 07:45:36 +0000
Subject: [issue26824] Make some macros use Py_TYPE
In-Reply-To: <1461300890.73.0.522492647874.issue26824@psf.upfronthosting.co.za>
Message-ID: <1461311136.19.0.487553427712.issue26824@psf.upfronthosting.co.za>


Martin Panter added the comment:

Most of Xiang?s changes are to Py<class>_Check() macros. I would expect them to be called with a generic PyObject pointer, and they do seem to be documented as accepting a PyObject pointer. Py_TYPE() is a macro that uses an unconditional cast. In general, these kinds of macros can hide errors that the compiler may otherwise pick up. E.g. if you accidentally pass an integer, or pointer to a pointer, etc, to Py_TYPE(), I think you will only get a warning or run-time crash, rather than a compile-time error. So while I am not that experienced with the C API, I suspect the change could have negative consequences.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26824>
_______________________________________

From report at bugs.python.org  Fri Apr 22 03:46:46 2016
From: report at bugs.python.org (lissacoffey)
Date: Fri, 22 Apr 2016 07:46:46 +0000
Subject: [issue7980] time.strptime not thread safe
In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za>
Message-ID: <1461311206.59.0.419272680369.issue7980@psf.upfronthosting.co.za>


lissacoffey added the comment:

On the other hand, the way imports are handled in 3.3 and later is a bit different, and if I run the unit test (which does still fail for me on 2.7 tip) on 3.3 and 3.4 tip it passes.

Thanks
Lisa - python expert
mysite: http://www.followthesteps.net/sky-contact-phone-number/

----------
nosy: +editor-buzzfeed -Romuald, William.McBrine, amaury.forgeotdarc, belopolsky, brett.cannon, ccorbacho, ced, cptnwillard, davidfraser, dpalms2011, epu, eric.smith, flox, fredwheeler, kzsolt, mark.dickinson, matrixise, pitrou, r.david.murray, ruseel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7980>
_______________________________________

From report at bugs.python.org  Fri Apr 22 03:48:56 2016
From: report at bugs.python.org (lissacoffey)
Date: Fri, 22 Apr 2016 07:48:56 +0000
Subject: [issue14621] Hash function is not randomized properly
In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za>
Message-ID: <1461311336.15.0.484636552452.issue14621@psf.upfronthosting.co.za>


lissacoffey added the comment:

How about Python grows a additional btree implementation in its collections module? I know that it's not going to fix existing code. However in the long run it's the best safeguard against hash collision attacks. I'm thinking about a simple, self balancing btree like red-black-tree. A quick search on Wikipedia also revealed Scapegoat and Splay tree with interesting properties.

Thanks
Lisa - python expert
mysite: http://www.fixithere.net/asos

----------
nosy: +editor-buzzfeed -Arfrever, Bob.Ziuchkovski, Giovanni.Bajo, PaulMcMillan, ReneSac, Vlado.Boza, alex, arigo, benjamin.peterson, bkabrda, camara, christian.heimes, cvrebert, dmalcolm, dstufft, gregory.p.smith, haypo, iElectric, isoschiz, koniiiik, lemburg, mark.dickinson, ncoghlan, pconnell, sbermeister, serhiy.storchaka, ?ukasz.Rekucki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14621>
_______________________________________

From report at bugs.python.org  Fri Apr 22 03:52:18 2016
From: report at bugs.python.org (Julian Taylor)
Date: Fri, 22 Apr 2016 07:52:18 +0000
Subject: [issue26601] Use new madvise()'s MADV_FREE on the private heap
In-Reply-To: <1458557514.95.0.774301964914.issue26601@psf.upfronthosting.co.za>
Message-ID: <1461311538.73.0.482636637014.issue26601@psf.upfronthosting.co.za>


Julian Taylor added the comment:

glibcs malloc is not obstack, its not a simple linear heap where one object on top means everything below is not freeable. It also uses MADV_DONTNEED give sbrk'd memory back to the system. This is the place where MADV_FREE can now be used now as the latter does not guarantee a page fault.
But that said of course you can construct workloads which lead to increased memory usage also with malloc and maybe python triggers them more often than other applications. Is there an existing issues showing the problem? It would be a good form of documentation in the source.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26601>
_______________________________________

From report at bugs.python.org  Fri Apr 22 04:06:30 2016
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 22 Apr 2016 08:06:30 +0000
Subject: [issue26601] Use new madvise()'s MADV_FREE on the private heap
In-Reply-To: <1461311538.73.0.482636637014.issue26601@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3erLPp6BiKRy2yBEPD05+AmW-BsAoDfPee4d0miR7OrQ@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

The heap on Linux is still a linear contiguous *address space*. I
agree that MADV_DONTNEED allow's returning committed memory back to
the VM subsystem, but it is still using a large virtual memory area.
Not everyone runs on 64-bit, or can waste address space.
Also, not every Unix is Linux.

But it might make sense to use malloc on Linux, maybe only on 64-bit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26601>
_______________________________________

From report at bugs.python.org  Fri Apr 22 04:07:17 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 22 Apr 2016 08:07:17 +0000
Subject: [issue26824] Make some macros use Py_TYPE
In-Reply-To: <1461300890.73.0.522492647874.issue26824@psf.upfronthosting.co.za>
Message-ID: <1461312437.95.0.022373837521.issue26824@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

My intention of the patch is that it helps reduce the possible errors described in PEP3123. I agree with Serhiy and Martin's opinion but I think the error passing a weird type argument to the macro is easier to find and debug than the undefined behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26824>
_______________________________________

From report at bugs.python.org  Fri Apr 22 04:17:45 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Apr 2016 08:17:45 +0000
Subject: [issue26824] Make some macros use Py_TYPE
In-Reply-To: <1461300890.73.0.522492647874.issue26824@psf.upfronthosting.co.za>
Message-ID: <1461313065.01.0.548513976392.issue26824@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It is possible to implement type checking in C macros.

Example found on the Internet:

/* inline type checking - can mix in with other macros more easily using the comma operator,
 * C11 gives best results here */
#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 201112L)
#  define CHECK_TYPE_INLINE(val, type) \
    (void)((void)(((type)0) != (0 ? (val) : ((type)0))), \
           _Generic((val), type: 0, const type: 0))
#else
#  define CHECK_TYPE_INLINE(val, type) \
    ((void)(((type)0) != (0 ? (val) : ((type)0))))
#endif

http://stackoverflow.com/questions/11449632/checking-types-of-macro-parameters-at-compile-time

See also Include/pymacro.h which contains some macros implementing checks tested at the compilation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26824>
_______________________________________

From report at bugs.python.org  Fri Apr 22 04:20:15 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Apr 2016 08:20:15 +0000
Subject: [issue26601] Use new madvise()'s MADV_FREE on the private heap
In-Reply-To: <1458557514.95.0.774301964914.issue26601@psf.upfronthosting.co.za>
Message-ID: <1461313215.98.0.249254535904.issue26601@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm not sure that I understood correctly, but if you are proposing to use malloc()/free() instead of mmap()/munmap() to allocate arenas in pymalloc, you have to know that we already different allocators depending on the platform:
https://docs.python.org/dev/c-api/memory.html#the-pymalloc-allocator

By the way, it is possible to modify the arena allocator at runtime:
https://docs.python.org/dev/c-api/memory.html#customize-pymalloc-arena-allocator

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26601>
_______________________________________

From report at bugs.python.org  Fri Apr 22 04:43:12 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 22 Apr 2016 08:43:12 +0000
Subject: [issue26825] Variable defined in exec(code) unreachable inside
 function call with visible name in dir() results
In-Reply-To: <1461308090.16.0.606527103016.issue26825@psf.upfronthosting.co.za>
Message-ID: <1461314592.35.0.0784234136535.issue26825@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

This seems to a behaviour change. In 2.7, return ans compiles to LOAD_NAME so it can find ans. But in 3.x, it compiles to LOAD_GLOBAL which searches ans from global scope. I don't know when this change is introduced.

----------
components: +Interpreter Core -Argument Clinic
nosy: +xiang.zhang -324857679
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26825>
_______________________________________

From report at bugs.python.org  Fri Apr 22 04:44:52 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 22 Apr 2016 08:44:52 +0000
Subject: [issue7980] time.strptime not thread safe
In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za>
Message-ID: <1461314692.7.0.615729856281.issue7980@psf.upfronthosting.co.za>


SilentGhost added the comment:

Lisa, please be careful with nosy list.

----------
nosy: +Romuald, SilentGhost, William.McBrine, amaury.forgeotdarc, belopolsky, brett.cannon, ccorbacho, ced, cptnwillard, davidfraser, dpalms2011, epu, eric.smith, flox, fredwheeler, kzsolt, mark.dickinson, matrixise, pitrou, r.david.murray, ruseel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7980>
_______________________________________

From report at bugs.python.org  Fri Apr 22 04:47:35 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 22 Apr 2016 08:47:35 +0000
Subject: [issue14621] Hash function is not randomized properly
In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za>
Message-ID: <1461314855.63.0.455738022764.issue14621@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +Arfrever, Bob.Ziuchkovski, Giovanni.Bajo, PaulMcMillan, ReneSac, Vlado.Boza, alex, arigo, benjamin.peterson, bkabrda, camara, christian.heimes, cvrebert, dmalcolm, dstufft, gregory.p.smith, haypo, iElectric, isoschiz, koniiiik, lemburg, mark.dickinson, ncoghlan, pconnell, sbermeister, serhiy.storchaka, ?ukasz.Rekucki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14621>
_______________________________________

From report at bugs.python.org  Fri Apr 22 04:48:15 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 22 Apr 2016 08:48:15 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1461314895.22.0.956289874395.issue19846@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +Sworddragon, a.badger, bkabrda, haypo, jwilk, larry, lemburg, loewis, ncoghlan, pitrou, r.david.murray, serhiy.storchaka, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Fri Apr 22 04:50:10 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 22 Apr 2016 08:50:10 +0000
Subject: [issue6792] Distutils-based installer does not detect 64bit versions
 of Python
In-Reply-To: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za>
Message-ID: <1461315010.32.0.0346260301863.issue6792@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
versions:  -Python 3.1, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6792>
_______________________________________

From report at bugs.python.org  Fri Apr 22 04:55:46 2016
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 22 Apr 2016 08:55:46 +0000
Subject: [issue26825] Variable defined in exec(code) unreachable inside
 function call with visible name in dir() results
In-Reply-To: <1461308090.16.0.606527103016.issue26825@psf.upfronthosting.co.za>
Message-ID: <1461315346.5.0.311688159032.issue26825@psf.upfronthosting.co.za>


Changes by Larry Hastings <larry at hastings.org>:


----------
nosy:  -larry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26825>
_______________________________________

From report at bugs.python.org  Fri Apr 22 05:01:55 2016
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 22 Apr 2016 09:01:55 +0000
Subject: [issue26825] Variable defined in exec(code) unreachable inside
 function call with visible name in dir() results
In-Reply-To: <1461308090.16.0.606527103016.issue26825@psf.upfronthosting.co.za>
Message-ID: <1461315715.38.0.256230430357.issue26825@psf.upfronthosting.co.za>


Eryk Sun added the comment:

In Python 2, using the exec statement makes the compiler disable fast locals: 

    >>> def foo(): pass
    ... 
    >>> def bar(): exec ''
    ... 
    >>> foo.__code__.co_flags & inspect.CO_OPTIMIZED
    1
    >>> bar.__code__.co_flags & inspect.CO_OPTIMIZED
    0

This has never been the case in Python 3, in which exec() is a function instead of a statement. The exec function can be shadowed by a global named "exec", so the hack to disable fast locals was removed.

----------
nosy: +eryksun
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26825>
_______________________________________

From report at bugs.python.org  Fri Apr 22 05:06:52 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Apr 2016 09:06:52 +0000
Subject: [issue26824] Make some macros use Py_TYPE
In-Reply-To: <1461300890.73.0.522492647874.issue26824@psf.upfronthosting.co.za>
Message-ID: <1461316012.33.0.0163161147652.issue26824@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

How this can help reduce the possible errors? I afraid that it rather can increase the possibility of error.

There is no undefined behaviour in current code. It was in old code (in the casting a pointer to PyObject*), but this was fixed with new PyObject_HEAD in 3.0+. 2.7 still has this undefined behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26824>
_______________________________________

From report at bugs.python.org  Fri Apr 22 05:07:16 2016
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 22 Apr 2016 09:07:16 +0000
Subject: [issue7980] time.strptime not thread safe
In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za>
Message-ID: <1461316036.2.0.707125717839.issue7980@psf.upfronthosting.co.za>


Eryk Sun added the comment:

SilentGhost, msg263977 is spam copied from msg206393 to try to fool people into clicking on the link. I've marked all of these messages from editor-buzzfeed as spam.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7980>
_______________________________________

From report at bugs.python.org  Fri Apr 22 05:11:53 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 22 Apr 2016 09:11:53 +0000
Subject: [issue20962] Rather modest chunk size in gzip.GzipFile
In-Reply-To: <1395082726.87.0.730756156096.issue20962@psf.upfronthosting.co.za>
Message-ID: <1461316313.95.0.073576871942.issue20962@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
Removed message: http://bugs.python.org/msg263972

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20962>
_______________________________________

From report at bugs.python.org  Fri Apr 22 05:13:29 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 22 Apr 2016 09:13:29 +0000
Subject: [issue7980] time.strptime not thread safe
In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za>
Message-ID: <1461316409.55.0.385764454356.issue7980@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
Removed message: http://bugs.python.org/msg263977

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7980>
_______________________________________

From report at bugs.python.org  Fri Apr 22 05:16:15 2016
From: report at bugs.python.org (Robin Roth)
Date: Fri, 22 Apr 2016 09:16:15 +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: <1461316575.58.0.80940855938.issue2466@psf.upfronthosting.co.za>


Robin Roth added the comment:

Any progress on merging this?
The fix is simple, there is a test; anything else I can do to help?

Ansible integrated the patch posted here as a workaround of an issue this caused. So there was some external review of the fix. See
https://github.com/ansible/ansible-modules-core/pull/2737

----------
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2466>
_______________________________________

From report at bugs.python.org  Fri Apr 22 05:23:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Apr 2016 09:23:46 +0000
Subject: [issue14621] Hash function is not randomized properly
In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za>
Message-ID: <1461317026.8.0.813694714933.issue14621@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
Removed message: http://bugs.python.org/msg263978

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14621>
_______________________________________

From report at bugs.python.org  Fri Apr 22 05:24:02 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Apr 2016 09:24:02 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1461317042.26.0.0668323742319.issue19846@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
Removed message: http://bugs.python.org/msg263975

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Fri Apr 22 05:24:27 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Apr 2016 09:24:27 +0000
Subject: [issue6792] Distutils-based installer does not detect 64bit versions
 of Python
In-Reply-To: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za>
Message-ID: <1461317067.16.0.819535601609.issue6792@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
Removed message: http://bugs.python.org/msg263973

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6792>
_______________________________________

From report at bugs.python.org  Fri Apr 22 05:29:19 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 22 Apr 2016 09:29:19 +0000
Subject: [issue26824] Make some macros use Py_TYPE
In-Reply-To: <1461300890.73.0.522492647874.issue26824@psf.upfronthosting.co.za>
Message-ID: <1461317359.76.0.126419309052.issue26824@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

The current code is OK. But if the macro are used with arguments not of PyObject* in the future, the bugs described in PEP3123 can possibly be introduced.

The new PyObject_HEAD alone can not fix the problem. It just makes the exception happen:

Standard C has one specific exception to its aliasing rules precisely designed to support the case of Python: a value of a struct type may also be accessed through a pointer to the first field. E.g. if a struct starts with an int , the struct * may also be cast to an int * , allowing to write int values into the first field. 

You still have to make sure accessing ob_type is via a PyObject* pointer. So the PEP also says:

However, all accesses to ob_refcnt and ob_type MUST cast the object pointer to PyObject* (unless the pointer is already known to have that type), and SHOULD use the respective accessor macros.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26824>
_______________________________________

From report at bugs.python.org  Fri Apr 22 05:38:05 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Apr 2016 09:38:05 +0000
Subject: [issue23507] Tuple creation is too slow
In-Reply-To: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za>
Message-ID: <1461317885.82.0.627770302773.issue23507@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hi, I started to work on a new top-down approach avoiding completly temporary tuple/dict: "FASTCALL", issue #26814. As you may expect, the patch is much larger that Serhiy's patches attached to his issue, but IMHO the final code is much simpler: it doesn't have to use complex tricks on the reference count or setting tuple items to NULL (which lead to segfaults like the issue #26811).


Antoine Pitrou: "Maybe we want a facility to create on-stack static-size tuples?"

My current implementation of FASTCALL uses a buffer allocated on the stack to handle calls with up to 10 parameters (10 positional parameters or 5 keyword parameters, since a keyword uses 2 PyObject*).


Antoine Pitrou: "How many functions can benefit from this approach, though?"

In my experimental FASTCALL branch, slot wrappers, PyObject_Call*() functions (except of PyObject_Call()!), ceval.c, etc. benefit from FASTCALL. The question is not really how much benefit from FASTCALL, but more how much changes are worth to avoid temporary tuple/dict. For example, right now I decided to not add a FASTCALL flavor of tp_new and tp_init (instanciate a class or create a new type) because it becomes much more complex when you have to handle inheritance.

Maybe my FASTCALL requires too many changes and is overkill. Maybe we need to find a compromise between FASTCALL (issue #26814) and Serhiy's changes which are limited to a few functions.

Today, it's too early to decide, but I have fun with my FASTCALL experiment ;-) Slot wrappers are 40% faster, getting a namedtuple attribute is 25% faster (whereas Serhiy already optimized this specific case!), etc.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23507>
_______________________________________

From report at bugs.python.org  Fri Apr 22 05:52:08 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Apr 2016 09:52:08 +0000
Subject: [issue26824] Make some macros use Py_TYPE
In-Reply-To: <1461300890.73.0.522492647874.issue26824@psf.upfronthosting.co.za>
Message-ID: <1461318728.77.0.406522675202.issue26824@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Seems you misunderstood PEP3123. The bugs described in the PEP are gone and can't be reappear. The new PyObject_HEAD fixes the problem, it makes casting to PyObject* be defined behaviour. The accessor macros are needed only to write the code compatible with 3.x and 2.x. Without Py_TYPE() you would need to use `foo->ob_base->ob_type` or `foo->ob_type` in 3.x depending on the type of foo, and always use `foo->ob_type` in 2.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26824>
_______________________________________

From report at bugs.python.org  Fri Apr 22 06:02:03 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 22 Apr 2016 10:02:03 +0000
Subject: [issue26824] Make some macros use Py_TYPE
In-Reply-To: <1461300890.73.0.522492647874.issue26824@psf.upfronthosting.co.za>
Message-ID: <1461319323.29.0.907301048762.issue26824@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Noooooooooooooo!!!!!! What I am afraid most seems to happen, a lot of noice due to misunderstanding! If that is true I am quite sorry. :-( But before I admit I have to figure it out myself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26824>
_______________________________________

From report at bugs.python.org  Fri Apr 22 06:21:04 2016
From: report at bugs.python.org (Robert Collins)
Date: Fri, 22 Apr 2016 10:21:04 +0000
Subject: [issue26807] mock_open()().readline() fails at EOF
In-Reply-To: <1461140283.7.0.219960203136.issue26807@psf.upfronthosting.co.za>
Message-ID: <1461320464.14.0.830216732782.issue26807@psf.upfronthosting.co.za>


Robert Collins added the comment:

Thanks Yolanda, that looks sane - could you perhaps add a test for this in Lib/unittest/tests/test_mock/ ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26807>
_______________________________________

From report at bugs.python.org  Fri Apr 22 06:41:53 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Apr 2016 10:41:53 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461321713.0.0.175178832595.issue26814@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Added file: http://bugs.python.org/file42566/ad4a53ed1fbf.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Fri Apr 22 07:10:16 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Apr 2016 11:10:16 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461323416.21.0.672697562575.issue26814@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Changes of my current implementation, ad4a53ed1fbf.diff.

The good thing is that all changes are internals (really?). Even if you don't modify your C extensions (nor your Python code), you should benefit of the new fast call is *a lot* of cases.

IMHO the best tricky part are changes on the PyTypeObject. Is it ok to add a new tp_fastcall slot? Should we add even more slots using the fast call convention like tp_fastnew and tp_fastinit? How should we handle the inheritance of types with that?


(*) Add 2 new public functions:

PyObject* PyObject_CallNoArg(PyObject *func);
PyObject* PyObject_CallArg1(PyObject *func, PyObject *arg);


(*) Add 1 new private function:

PyObject* _PyObject_FastCall(PyObject *func, PyObject **stack, int na, int nk);

_PyObject_FastCall() is the root of the new feature.


(*) type: add a new "tp_fastcall" field to the PyTypeObject structure.

It's unclear to me how inheritance is handled here. Maybe it's simply broken, but it's strange because it looks like it works :-) Maybe it's very rare that tp_call is overidden in a child class?

TODO: maybe reuse the "tp_call" field? (risk of major backward incompatibility...)


(*) slots: add a new "fastwrapper" field to the wrappercase structure. Add a fast wrapper to all slots (really all? i should check).

I don't think that consumers of the C API are of this change, or maybe only a few projects.

TODO: maybe remove "fastwrapper" and reuse the "wrapper" field? (low risk of backward compatibility?)


(*) Implement fast call for Python function (_PyFunction_FastCall) and C functions (PyCFunction_FastCall)


(*) Add a new METH_FASTCALL calling convention for C functions. Right now, it is used for 4 builtin functions: sorted(), getattr(), iter(), next().

Argument Clinic should be modified to emit C code using this new fast calling convention.


(*) Implement fast call in the following functions (types):

- method()
- method_descriptor()
- wrapper_descriptor()
- method_wrapper()
- operator.itemgetter => used by collections.namedtuple to get an item by its name


(*) Modify PyObject_Call*() functins to reuse internally the fast call. "tp_fastcall" is preferred over "tp_call" (FIXME: is it really useful to do that?).

The following functions are able to avoid temporary tuple/dict without having to modify the code calling them:

- PyObject_CallFunction()
- PyObject_CallMethod(), _PyObject_CallMethodId()
- PyObject_CallFunctionObjArgs(), PyObject_CallMethodObjArgs()

It's not required to modify code using these functions to use the 3 new shiny functions (PyObject_CallNoArg, PyObject_CallArg1, _PyObject_FastCall). For example, replacing PyObject_CallFunctionObjArgs(func, NULL) with PyObject_CallNoArg(func) is just a micro-optimization, the tuple is already avoided. But PyObject_CallNoArg() should use less memory of the C stack and be a "little bit" faster.


(*) Add new helpers: new Include/pystack.h file, Py_VaBuildStack(), etc.


Please ignore unrelated changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Fri Apr 22 07:12:30 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Apr 2016 11:12:30 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461323550.3.0.564888545784.issue26814@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Related issue: issue #23507, "Tuple creation is too slow".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Fri Apr 22 07:24:02 2016
From: report at bugs.python.org (Julian Taylor)
Date: Fri, 22 Apr 2016 11:24:02 +0000
Subject: [issue26601] Use new madvise()'s MADV_FREE on the private heap
In-Reply-To: <1458557514.95.0.774301964914.issue26601@psf.upfronthosting.co.za>
Message-ID: <1461324242.98.0.116944646741.issue26601@psf.upfronthosting.co.za>


Julian Taylor added the comment:

I know one can change the allocator, but the default is mmap which I don't think is a very good choice for the current arena size.
All the arguments about fragmentation and memory space also apply to pythons arena allocator itself and I am not convinced that fragmentation of the libc allocator is a real problem for python as pythons allocation pattern is very well behaved _due_ to its own arena allocator. I don't doubt it but I think it would be very valuable to document the actual real world use case that triggered this change, just to avoid people stumbling over this again and again.

But then I also don't think that anything needs to be necessarily be changed either, I have not seen the mmaps being a problem in any profiles of applications I work with.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26601>
_______________________________________

From report at bugs.python.org  Fri Apr 22 07:35:10 2016
From: report at bugs.python.org (Antti Haapala)
Date: Fri, 22 Apr 2016 11:35:10 +0000
Subject: [issue26601] Use new madvise()'s MADV_FREE on the private heap
In-Reply-To: <1458557514.95.0.774301964914.issue26601@psf.upfronthosting.co.za>
Message-ID: <1461324910.26.0.673523767.issue26601@psf.upfronthosting.co.za>


Antti Haapala added the comment:

mmap is not the problem, the eagerness of munmap is a source of possible problem. 

The munmap eagerness does not show problems in all programs because the arena allocation heuristics do not work as intended. A proper solution in Linux and other operating systems where it is supported, is to put the freed arenas in a list, then mark freed with MADV_FREE. Now if the memory pressure grows, only *then* will the OS reclaim these. At any time the application can start reusing these arenas/pages; if they're not reclaimed, the old contents will be still present there; if operating system reclaimed them, they'd be remapped with zeroes.

Really the only downside of all this that I can foresee is that `ps/top/whatever` output would see Python using way more memory in its RSS/virt/whatever than it is actually using.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26601>
_______________________________________

From report at bugs.python.org  Fri Apr 22 07:40:11 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Apr 2016 11:40:11 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461325211.5.0.76633358144.issue26814@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Some microbenchmarks: bench_fast.py.

== Python 3.6 / Python 3.6 FASTCALL ==

----------------------------------+--------------+---------------
Tests                             | /tmp/default |  /tmp/fastcall
----------------------------------+--------------+---------------
filter                            |   241 us (*) |  166 us (-31%)
map                               |   205 us (*) |  168 us (-18%)
sorted(list, key=lambda x: x)     |   242 us (*) |  162 us (-33%)
sorted(list)                      |  27.7 us (*) |        27.8 us
b=MyBytes(); bytes(b)             |   549 ns (*) |         533 ns
namedtuple.attr                   |  2.03 us (*) | 1.56 us (-23%)
object.__setattr__(obj, "x", 1)   |   347 ns (*) |  218 ns (-37%)
object.__getattribute__(obj, "x") |   331 ns (*) |  200 ns (-40%)
getattr(1, "real")                |   267 ns (*) |  150 ns (-44%)
bounded_pymethod(1, 2)            |   193 ns (*) |         190 ns
unbound_pymethod(obj, 1, 2        |   195 ns (*) |         192 ns
----------------------------------+--------------+---------------
Total                             |   719 us (*) |  526 us (-27%)
----------------------------------+--------------+---------------


== Compare Python 3.4 / Python 3.6 / Python 3.6 FASTCALL ==

Common platform:
Timer: time.perf_counter
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
Platform: Linux-4.4.4-301.fc23.x86_64-x86_64-with-fedora-23-Twenty_Three
SCM: hg revision=abort: repository . not found! tag=abort: repository . not found! branch=abort: repository . not found! date=abort: no repository found in '/home/haypo/prog/python' (.hg not found)!
Bits: int=32, long=64, long long=64, size_t=64, void*=64

Platform of campaign /tmp/py34:
Python version: 3.4.3 (default, Jun 29 2015, 12:16:01) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)]
CFLAGS: -Wno-unused-result -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv
Timer precision: 78 ns
Date: 2016-04-22 13:37:52

Platform of campaign /tmp/default:
Python version: 3.6.0a0 (default:496e094f4734, Apr 22 2016, 02:18:13) [GCC 5.3.1 20151207 (Red Hat 5.3.1-2)]
CFLAGS: -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
Timer precision: 103 ns
Date: 2016-04-22 13:38:07

Platform of campaign /tmp/fastcall:
Python version: 3.6.0a0 (default:ad4a53ed1fbf, Apr 22 2016, 12:42:15) [GCC 5.3.1 20151207 (Red Hat 5.3.1-2)]
Timer precision: 99 ns
CFLAGS: -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
Date: 2016-04-22 13:38:21

----------------------------------+-------------+----------------+---------------
Tests                             |   /tmp/py34 |   /tmp/default |  /tmp/fastcall
----------------------------------+-------------+----------------+---------------
filter                            |  325 us (*) |  241 us (-26%) |  166 us (-49%)
map                               |  260 us (*) |  205 us (-21%) |  168 us (-35%)
sorted(list, key=lambda x: x)     |  354 us (*) |  242 us (-32%) |  162 us (-54%)
sorted(list)                      | 46.9 us (*) | 27.7 us (-41%) | 27.8 us (-41%)
b=MyBytes(); bytes(b)             |  839 ns (*) |  549 ns (-35%) |  533 ns (-36%)
namedtuple.attr                   | 4.51 us (*) | 2.03 us (-55%) | 1.56 us (-65%)
object.__setattr__(obj, "x", 1)   |  447 ns (*) |  347 ns (-22%) |  218 ns (-51%)
object.__getattribute__(obj, "x") |  401 ns (*) |  331 ns (-17%) |  200 ns (-50%)
getattr(1, "real")                |  236 ns (*) |  267 ns (+13%) |  150 ns (-36%)
bounded_pymethod(1, 2)            |  249 ns (*) |  193 ns (-22%) |  190 ns (-24%)
unbound_pymethod(obj, 1, 2        |  251 ns (*) |  195 ns (-22%) |  192 ns (-23%)
----------------------------------+-------------+----------------+---------------
Total                             |  993 us (*) |  719 us (-28%) |  526 us (-47%)
----------------------------------+-------------+----------------+---------------

----------
Added file: http://bugs.python.org/file42567/bench_fast.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Fri Apr 22 07:40:39 2016
From: report at bugs.python.org (Marcos Dione)
Date: Fri, 22 Apr 2016 11:40:39 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module and use
 it to improve shutils.copy()
Message-ID: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>


New submission from Marcos Dione:

copy_file_range() has been introduced in the Linux kernel since version 4.5 (mid march 2016). This new syscall allows to copy data from one fd to another without passing by user space, improving speed in most cases. You can read more about it here:

https://lwn.net/Articles/659523/

I intend to start working on adding a binding for it in the os module and then, if it's available, use it in shutils.copy() to improve its efficiency. I have a couple of questions: If the syscall is not available, should I implement a user space alternative or should the method not exist at all?

----------
components: Library (Lib)
messages: 264000
nosy: StyXman
priority: normal
severity: normal
status: open
title: Expose new copy_file_range() syscal in os module and use it to improve shutils.copy()
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Fri Apr 22 07:41:52 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Apr 2016 11:41:52 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module and use
 it to improve shutils.copy()
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1461325312.03.0.118110321617.issue26826@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo, neologix, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Fri Apr 22 07:44:57 2016
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 22 Apr 2016 11:44:57 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module and use
 it to improve shutils.copy()
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1461325497.62.0.230683859343.issue26826@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thanks, looks interesting.

We usually wait until syscalls are generally available in common distros and have bindings in glibc. It makes it easier to test the feature.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Fri Apr 22 07:45:14 2016
From: report at bugs.python.org (Julian Taylor)
Date: Fri, 22 Apr 2016 11:45:14 +0000
Subject: [issue26601] Use new madvise()'s MADV_FREE on the private heap
In-Reply-To: <1458557514.95.0.774301964914.issue26601@psf.upfronthosting.co.za>
Message-ID: <1461325514.04.0.88896197292.issue26601@psf.upfronthosting.co.za>


Julian Taylor added the comment:

which is exactly what malloc is already doing for, thus my point is by using malloc we would fullfill your request.

But do you have an actual real work application where this would help?
it is pretty easy to figure out, just run the application under perf and see if there is a relevant amount of time spent in page_fault/clear_pages.

And as mentioned you can already change the allocator for arenas at runtime, so you could also try changing it to malloc and see if your application gets any faster.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26601>
_______________________________________

From report at bugs.python.org  Fri Apr 22 07:52:19 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Apr 2016 11:52:19 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461325939.83.0.91424093163.issue26814@psf.upfronthosting.co.za>


STINNER Victor added the comment:

For more fun, comparison between Python 2.7 / 3.4 / 3.6 / 3.6 FASTCALL.

----------------------------------+-------------+----------------+----------------+---------------
Tests                             |        py27 |           py34 |           py36 |           fast
----------------------------------+-------------+----------------+----------------+---------------
filter                            |  165 us (*) |  318 us (+93%) |  237 us (+43%) |         165 us
map                               |  209 us (*) |  258 us (+24%) |         202 us |  171 us (-18%)
sorted(list, key=lambda x: x)     |  272 us (*) |  348 us (+28%) |  237 us (-13%) |  163 us (-40%)
sorted(list)                      | 33.7 us (*) | 47.8 us (+42%) | 27.3 us (-19%) | 27.7 us (-18%)
b=MyBytes(); bytes(b)             | 3.31 us (*) |  835 ns (-75%) |  510 ns (-85%) |  561 ns (-83%)
namedtuple.attr                   | 4.63 us (*) |        4.51 us | 1.98 us (-57%) | 1.57 us (-66%)
object.__setattr__(obj, "x", 1)   |  463 ns (*) |         440 ns |  343 ns (-26%) |  222 ns (-52%)
object.__getattribute__(obj, "x") |  323 ns (*) |  396 ns (+23%) |         316 ns |  196 ns (-39%)
getattr(1, "real")                |  218 ns (*) |   237 ns (+8%) |  264 ns (+21%) |  147 ns (-33%)
bounded_pymethod(1, 2)            |  213 ns (*) |  244 ns (+14%) |   194 ns (-9%) |  188 ns (-12%)
unbound_pymethod(obj, 1, 2)       |  345 ns (*) |  247 ns (-29%) |  196 ns (-43%) |  191 ns (-45%)
func()                            |  161 ns (*) |  211 ns (+31%) |         161 ns |         157 ns
func(1, 2, 3)                     |  219 ns (*) |  247 ns (+13%) |  196 ns (-10%) |  190 ns (-13%)
----------------------------------+-------------+----------------+----------------+---------------
Total                             |  689 us (*) |  980 us (+42%) |         707 us |  531 us (-23%)
----------------------------------+-------------+----------------+----------------+---------------


I didn't know that Python 3.4 was so much slower than Python 2.7 on function calls!?

Note: Python 2.7 and Python 3.4 are system binaries (Fedora 22), wheras Python 3.6 and Python 3.6 FASTCALL are compiled manually.

Ignore "b=MyBytes(); bytes(b)", this benchmark is written for Python 3.

--

details:

Common platform:
Bits: int=32, long=64, long long=64, size_t=64, void*=64
Platform: Linux-4.4.4-301.fc23.x86_64-x86_64-with-fedora-23-Twenty_Three
CPU model: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz

Platform of campaign py27:
CFLAGS: -fno-strict-aliasing -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv
Python unicode implementation: UCS-4
Timer precision: 954 ns
Python version: 2.7.10 (default, Sep 8 2015, 17:20:17) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)]
Timer: time.time

Platform of campaign py34:
Timer info: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09)
CFLAGS: -Wno-unused-result -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv
Timer precision: 84 ns
Python unicode implementation: PEP 393
Python version: 3.4.3 (default, Jun 29 2015, 12:16:01) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)]
Timer: time.perf_counter

Platform of campaign py36:
Timer info: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09)
Python version: 3.6.0a0 (default:496e094f4734, Apr 22 2016, 02:18:13) [GCC 5.3.1 20151207 (Red Hat 5.3.1-2)]
CFLAGS: -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
Python unicode implementation: PEP 393
Timer: time.perf_counter

Platform of campaign fast:
Timer info: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09)
CFLAGS: -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
Python unicode implementation: PEP 393
Python version: 3.6.0a0 (default:ad4a53ed1fbf, Apr 22 2016, 12:42:15) [GCC 5.3.1 20151207 (Red Hat 5.3.1-2)]

----------
Added file: http://bugs.python.org/file42568/bench_fast-2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Fri Apr 22 07:58:16 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Apr 2016 11:58:16 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module and use
 it to improve shutils.copy()
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1461326296.43.0.130225474161.issue26826@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> We usually wait until syscalls are generally available in common distros and have bindings in glibc. It makes it easier to test the feature.

Usually, yeah. os.urandom() uses syscall() to use the new getrandom() of Linux since it's still not exposed in the GNU libc...
https://sourceware.org/bugzilla/show_bug.cgi?id=17252
Status: NEW

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Fri Apr 22 08:08:15 2016
From: report at bugs.python.org (Herbert)
Date: Fri, 22 Apr 2016 12:08:15 +0000
Subject: [issue26827] PyObject *PyInit_myextention -> PyMODINIT_FUNC
 PyInit_myextention
Message-ID: <1461326895.36.0.898462963597.issue26827@psf.upfronthosting.co.za>


New submission from Herbert:

I think 

PyObject *PyInit_myextention(void)

should be

PyMODINIT_FUNC PyInit_myextention(void)

on https://docs.python.org/3/howto/cporting.html#module-initialization-and-state

It didn't work for me until I replaced this with a message in the about 'undefined PyInit_myextention'. However, when I used nm to inspect the .so object file, I fond the PyInit_myextention (but probably with the wrong return type). Moreover, whenever I would remove the same .so importing resulted in a different error complaining that the module does not exist (strongly suggesting that I did not mix up .so files).

Good luck!

----------
assignee: docs at python
components: Documentation
messages: 264005
nosy: docs at python, prinsherbert
priority: normal
severity: normal
status: open
title: PyObject *PyInit_myextention -> PyMODINIT_FUNC PyInit_myextention
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26827>
_______________________________________

From report at bugs.python.org  Fri Apr 22 08:09:57 2016
From: report at bugs.python.org (Herbert)
Date: Fri, 22 Apr 2016 12:09:57 +0000
Subject: [issue26827] PyObject *PyInit_myextention -> PyMODINIT_FUNC
 PyInit_myextention
In-Reply-To: <1461326895.36.0.898462963597.issue26827@psf.upfronthosting.co.za>
Message-ID: <1461326997.03.0.74413294796.issue26827@psf.upfronthosting.co.za>


Herbert added the comment:

The exact error was:

ImportError: dynamic module does not define init function (PyInit_myextension)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26827>
_______________________________________

From report at bugs.python.org  Fri Apr 22 08:12:40 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Apr 2016 12:12:40 +0000
Subject: [issue26828] Implement __length_hint__() on map() and filter() to
 optimize list(map) and list(filter)
Message-ID: <1461327160.24.0.621419084727.issue26828@psf.upfronthosting.co.za>


New submission from STINNER Victor:

When I compared the performance of filter() and map() between Python 2.7 and 3.4, I noticed a huge performance drop in Python 3!
http://bugs.python.org/issue26814#msg264003

I didn't analyze yet exactly why Python 3 is so much slower (almost 100% slower for the case of fitler!). Maybe it's because filter() returns a list on Python 2, whereas filter() returns an iterator on Python 3.

In Python 2, filter() and map() use _PyObject_LengthHint(seq, 8) to create the result list. Why don't we do the same in Python 3?

filter.__length_hint__() and map.__length_hint__() would return seq.__length_hint__() of the input sequence, or return 8. It's a weak estimation, but it can help a lot of reduce the number of realloc() when the list is slowly growing.

See also the PEP 424 -- A method for exposing a length hint.

Note: the issue #26814 (fastcall) does make filter() and map() faster on Python 3.6 compared to Python 2.7, but it's not directly related to this issue. IMHO using length hint would make list(filter) and list(map) even faster.

----------
messages: 264007
nosy: alex, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Implement __length_hint__() on map() and filter() to optimize list(map) and list(filter)
type: performance
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26828>
_______________________________________

From report at bugs.python.org  Fri Apr 22 08:49:57 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Apr 2016 12:49:57 +0000
Subject: [issue26828] Implement __length_hint__() on map() and filter() to
 optimize list(map) and list(filter)
In-Reply-To: <1461327160.24.0.621419084727.issue26828@psf.upfronthosting.co.za>
Message-ID: <1461329397.87.0.908726925926.issue26828@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue14126.

It makes sense to implement map.__length_hint__() and  zip.__length_hint__(). But note that map() and zip() take several iterables, and we should call __length_hint__() for every of them (unless found a one with not implemented __length_hint__()). This can slow down the execution for short sequences.

It is impossible to implement reasonable filter.__length_hint__(), because the length of resulting sequence can be from 0 to the length of the input sequence, and returning the maximal value would be not correct.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26828>
_______________________________________

From report at bugs.python.org  Fri Apr 22 08:52:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Apr 2016 12:52:39 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461329559.86.0.0827239196342.issue26814@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you compare filter(), map() and sorted() performance with your patch and with issue23507 patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Fri Apr 22 08:57:55 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Apr 2016 12:57:55 +0000
Subject: [issue26828] Implement __length_hint__() on map() and filter() to
 optimize list(map) and list(filter)
In-Reply-To: <1461327160.24.0.621419084727.issue26828@psf.upfronthosting.co.za>
Message-ID: <1461329875.78.0.520347342807.issue26828@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> But note that map() and zip() take several iterables, and we should call __length_hint__() for every of them (unless found a one with not implemented __length_hint__()). This can slow down the execution for short sequences.

Oh, there is no slot for __length_hint__(). Maybe we should also try to add a new slot for it?

Maybe we can use a fast-path for the most common cases like list(map(func, list))?


> It is impossible to implement reasonable filter.__length_hint__(), because the length of resulting sequence can be from 0 to the length of the input sequence, and returning the maximal value would be not correct.

What I see is that Python 2 is much faster and Python 2 reallocates N items if the input sequence contains N items. But yeah, we have to benchmark such change on Python 3 ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26828>
_______________________________________

From report at bugs.python.org  Fri Apr 22 09:33:34 2016
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 22 Apr 2016 13:33:34 +0000
Subject: [issue6792] Distutils-based installer does not detect 64bit versions
 of Python
In-Reply-To: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za>
Message-ID: <1461332014.05.0.924619946484.issue6792@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
nosy:  -brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6792>
_______________________________________

From report at bugs.python.org  Fri Apr 22 09:43:52 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 22 Apr 2016 13:43:52 +0000
Subject: [issue26804] Prioritize lowercase proxy variables in urllib.request
In-Reply-To: <1461053909.86.0.0123928931795.issue26804@psf.upfronthosting.co.za>
Message-ID: <1461332632.97.0.0328210213748.issue26804@psf.upfronthosting.co.za>


Martin Panter added the comment:

I found two bugs; see the comments.

In Python 2, it looks like the proxy_bypass_etc() functions are defined in urllib and imported into urllib2, so it makes sense to include the tests in test_urllib rather than test_urllib2.

Technically I think proxy_bypass_environment() is meant to be an internal function, but it is safer to keep the changes to in minimal for bug fixes. So I think the optional proxies parameter should be okay.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26804>
_______________________________________

From report at bugs.python.org  Fri Apr 22 09:54:27 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Apr 2016 13:54:27 +0000
Subject: [issue23507] Tuple creation is too slow
In-Reply-To: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za>
Message-ID: <1461333267.43.0.831513138751.issue23507@psf.upfronthosting.co.za>


STINNER Victor added the comment:

msg264009: Serhiy Storchaka "Could you compare filter(), map() and sorted() performance with your patch and with issue23507 patch?"

Here you have the result of bench_builtins.py. The performance look to be the same, even if I expect better performance with less trivial callbacks (where fastcall would avoid the creation of other temporary tuples).

------------------------------------------------+-------------+--------------
Tests                                           |   argtuples |      fastcall
------------------------------------------------+-------------+--------------
filter(lambda x: x, range(1000))                | 80.2 us (*) | 72.7 us (-9%)
map(lambda x: x, range(1000))                   | 79.5 us (*) |       79.9 us
map(lambda x, y: x+y, range(1000), range(1000)) |  111 us (*) |        109 us
sorted(list, key=lambda x: x)                   | 82.6 us (*) | 75.7 us (-8%)
sorted(list)                                    | 15.7 us (*) |       15.6 us
------------------------------------------------+-------------+--------------
Total                                           |  369 us (*) |        353 us
------------------------------------------------+-------------+--------------

Comparison to the original Python 3.6:

------------------------------------------------+-------------+----------------+---------------
Tests                                           |    original |      argtuples |       fastcall
------------------------------------------------+-------------+----------------+---------------
filter(lambda x: x, range(1000))                |  109 us (*) | 80.2 us (-27%) | 72.7 us (-33%)
map(lambda x: x, range(1000))                   | 96.9 us (*) | 79.5 us (-18%) | 79.9 us (-18%)
map(lambda x, y: x+y, range(1000), range(1000)) |  126 us (*) |  111 us (-12%) |  109 us (-13%)
sorted(list, key=lambda x: x)                   |  114 us (*) | 82.6 us (-28%) | 75.7 us (-34%)
sorted(list)                                    | 16.1 us (*) |        15.7 us |        15.6 us
------------------------------------------------+-------------+----------------+---------------
Total                                           |  463 us (*) |  369 us (-20%) |  353 us (-24%)
------------------------------------------------+-------------+----------------+---------------


The difference is more on the changes in bltinmodule.c. Example with filter_next():

Using fastcall:

-            good = PyObject_CallFunctionObjArgs(lz->func, item, NULL);
+            good = PyObject_CallArg1(lz->func, item);

reuse_argtuples_2.patch:

-            good = PyObject_CallFunctionObjArgs(lz->func,
-                                                item, NULL);
+            PyObject *argtuple = lz->argtuple;
+            lz->argtuple = NULL;
+            if (argtuple == NULL) {
+                argtuple = PyTuple_New(1);
+                if (argtuple == NULL) {
+                    Py_DECREF(item);
+                    return NULL;
+                }
+                Py_INCREF(argtuple);
+            }
+            assert(Py_REFCNT(argtuple) == 2);
+            assert(Py_SIZE(argtuple) == 1);
+            assert(PyTuple_GET_ITEM(argtuple, 0) == NULL);
+            PyTuple_SET_ITEM(argtuple, 0, item);
+            good = PyObject_Call(lz->func, argtuple, NULL);
+            if (Py_REFCNT(argtuple) == 2) {
+                PyTuple_SET_ITEM(argtuple, 0, NULL);
+                if (lz->argtuple == NULL)
+                    lz->argtuple = argtuple;
+                else {
+                    Py_DECREF(argtuple);
+                    Py_DECREF(argtuple);
+                }
+            }
+            else {
+                Py_INCREF(item);
+                Py_DECREF(argtuple);
+                Py_DECREF(argtuple);
+            }

(reuse_argtuples_2.patch requires a few other changes related to filter_next().)

----------
Added file: http://bugs.python.org/file42569/bench_builtins.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23507>
_______________________________________

From report at bugs.python.org  Fri Apr 22 09:54:45 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 22 Apr 2016 13:54:45 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module and use
 it to improve shutils.copy()
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1461333285.83.0.992675768858.issue26826@psf.upfronthosting.co.za>


Martin Panter added the comment:

Tangentially related: Issue 25156, about using sendfile() to copy files in shutil.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Fri Apr 22 09:57:16 2016
From: report at bugs.python.org (sorin)
Date: Fri, 22 Apr 2016 13:57:16 +0000
Subject: [issue6792] Distutils-based installer does not detect 64bit versions
 of Python
In-Reply-To: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za>
Message-ID: <1461333436.22.0.66152232314.issue6792@psf.upfronthosting.co.za>


Changes by sorin <sorin.sbarnea at gmail.com>:


----------
nosy:  -sorin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6792>
_______________________________________

From report at bugs.python.org  Fri Apr 22 09:59:44 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Apr 2016 13:59:44 +0000
Subject: [issue26601] Use new madvise()'s MADV_FREE on the private heap
In-Reply-To: <1458557514.95.0.774301964914.issue26601@psf.upfronthosting.co.za>
Message-ID: <1461333584.96.0.0553926183603.issue26601@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

All this discussion is in the context of the GNU libc allocator, but please remember that Python works on many platforms, including OS X, Windows, the *BSDs...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26601>
_______________________________________

From report at bugs.python.org  Fri Apr 22 10:03:14 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 22 Apr 2016 14:03:14 +0000
Subject: [issue26809] `string` exposes ChainMap from `collections`
In-Reply-To: <1461152182.96.0.373784885739.issue26809@psf.upfronthosting.co.za>
Message-ID: <1461333794.24.0.0107158486604.issue26809@psf.upfronthosting.co.za>


Martin Panter added the comment:

I?m not that fussed if the _ChainMap name is backported. I just thought it is safer to not do it; similar reasoning to why I only committed Issue 23883 patches to 3.6. I certainly think backporting __all__ is reasonable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26809>
_______________________________________

From report at bugs.python.org  Fri Apr 22 10:03:54 2016
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 22 Apr 2016 14:03:54 +0000
Subject: [issue26829] update docs: when creating classes a new dict is created
 for the final class object
Message-ID: <1461333834.83.0.0321229546915.issue26829@psf.upfronthosting.co.za>


New submission from Ethan Furman:

https://docs.python.org/3/reference/datamodel.html#creating-the-class-object

This section should mention that the final class is created with a new dict(), and all key/value pairs from the dict used during creation are copied over.

----------
assignee: docs at python
components: Documentation
messages: 264016
nosy: docs at python, ethan.furman
priority: normal
severity: normal
status: open
title: update docs: when creating classes a new dict is created for the final class object
versions: Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26829>
_______________________________________

From report at bugs.python.org  Fri Apr 22 10:05:10 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 22 Apr 2016 14:05:10 +0000
Subject: [issue26824] Make some macros use Py_TYPE
In-Reply-To: <1461300890.73.0.522492647874.issue26824@psf.upfronthosting.co.za>
Message-ID: <1461333910.13.0.141152544231.issue26824@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

With a careful rereading of PEP3123, I think you are right. Actually the title of the PEP tells what you mean. I do misunderstand. I am quite sorry and feel shamed of making noice here and wasting time of the participants. I will think more seriously from now on. :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26824>
_______________________________________

From report at bugs.python.org  Fri Apr 22 10:05:45 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Apr 2016 14:05:45 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1461333945.44.0.88161417026.issue21955@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Maybe we should adopt a difference approach.

There is something called "inline caching": put the cache between instructions, in the same memory block. Example of paper on CPython:

"Efficient Inline Caching without Dynamic Translation" by Stefan Brunthaler (2009)
https://www.sba-research.org/wp-content/uploads/publications/sac10.pdf

Maybe we can build something on top of the issue #26219 "implement per-opcode cache in ceval"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21955>
_______________________________________

From report at bugs.python.org  Fri Apr 22 10:24:45 2016
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 22 Apr 2016 14:24:45 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1461335085.91.0.386305194278.issue21955@psf.upfronthosting.co.za>


Stefan Krah added the comment:

#14757 has an implementation of inline caching, which at least seemed to slow down some use cases. Then again, whenever someone posts a new speedup suggestion, it seems to slow down things I'm working on. At least Case van Horsen independently verified the phenomenon in this issue. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21955>
_______________________________________

From report at bugs.python.org  Fri Apr 22 10:38:51 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Apr 2016 14:38:51 +0000
Subject: [issue26249] Change PyMem_Malloc to use pymalloc allocator
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <20160422143842.90477.13678.EAB27CAD@psf.io>


Roundup Robot added the comment:

New changeset 68b2a43d8653 by Victor Stinner in branch 'default':
PyMem_Malloc() now uses the fast pymalloc allocator
https://hg.python.org/cpython/rev/68b2a43d8653

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26249>
_______________________________________

From report at bugs.python.org  Fri Apr 22 10:56:58 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Apr 2016 14:56:58 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461337018.0.0.521048848125.issue26814@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Results of the CPython benchmark suite on the revision 6c376e866330 of  https://hg.python.org/sandbox/fastcall compared to CPython 3.6 at the revision 496e094f4734.

It's surprising than call_simple is 1.08x slower in fastcall. This slowdown is not acceptable and should be fixed. It probable explains why many other benchmarks are slower.

Hopefully, some benchmarks are faster, between 1.02x and 1.09x faster.

IMHO there are still performance issues in my current implementation that can and must be fixed. At least, we have a starting point to compare performances.


$ python3 -u perf.py ../default/python ../fastcall/python -b all
(...)
Report on Linux smithers 4.4.4-301.fc23.x86_64 #1 SMP Fri Mar 4 17:42:42 UTC 2016 x86_64 x86_64
Total CPU cores: 8

[ slower ]

### 2to3 ###
6.859604 -> 6.985351: 1.02x slower

### call_method_slots ###
Min: 0.308846 -> 0.317780: 1.03x slower
Avg: 0.308902 -> 0.318667: 1.03x slower
Significant (t=-464.83)
Stddev: 0.00003 -> 0.00026: 9.8974x larger

### call_simple ###
Min: 0.232594 -> 0.251789: 1.08x slower
Avg: 0.232816 -> 0.252443: 1.08x slower
Significant (t=-911.97)
Stddev: 0.00024 -> 0.00011: 2.2373x smaller

### chaos ###
Min: 0.273084 -> 0.284790: 1.04x slower
Avg: 0.273951 -> 0.293177: 1.07x slower
Significant (t=-7.57)
Stddev: 0.00036 -> 0.01796: 49.9421x larger

### django_v3 ###
Min: 0.549604 -> 0.569982: 1.04x slower
Avg: 0.550557 -> 0.571038: 1.04x slower
Significant (t=-204.09)
Stddev: 0.00046 -> 0.00054: 1.1747x larger

### float ###
Min: 0.261939 -> 0.269224: 1.03x slower
Avg: 0.268475 -> 0.276515: 1.03x slower
Significant (t=-12.22)
Stddev: 0.00301 -> 0.00354: 1.1757x larger

### formatted_logging ###
Min: 0.325786 -> 0.334440: 1.03x slower
Avg: 0.326827 -> 0.335968: 1.03x slower
Significant (t=-34.44)
Stddev: 0.00129 -> 0.00136: 1.0503x larger

### mako_v2 ###
Min: 0.039642 -> 0.044765: 1.13x slower
Avg: 0.040251 -> 0.045562: 1.13x slower
Significant (t=-323.73)
Stddev: 0.00028 -> 0.00024: 1.1558x smaller

### meteor_contest ###
Min: 0.196589 -> 0.203667: 1.04x slower
Avg: 0.197497 -> 0.204782: 1.04x slower
Significant (t=-76.06)
Stddev: 0.00050 -> 0.00045: 1.1111x smaller

### nqueens ###
Min: 0.274664 -> 0.285866: 1.04x slower
Avg: 0.275285 -> 0.286774: 1.04x slower
Significant (t=-68.34)
Stddev: 0.00091 -> 0.00076: 1.2036x smaller

### pickle_list ###
Min: 0.262687 -> 0.269629: 1.03x slower
Avg: 0.263804 -> 0.270789: 1.03x slower
Significant (t=-50.14)
Stddev: 0.00070 -> 0.00070: 1.0004x larger

### raytrace ###
Min: 1.272960 -> 1.284516: 1.01x slower
Avg: 1.276398 -> 1.368574: 1.07x slower
Significant (t=-3.41)
Stddev: 0.00157 -> 0.19115: 122.0022x larger

### regex_compile ###
Min: 0.335753 -> 0.343820: 1.02x slower
Avg: 0.336273 -> 0.344894: 1.03x slower
Significant (t=-127.84)
Stddev: 0.00026 -> 0.00040: 1.5701x larger

### regex_effbot ###
Min: 0.048656 -> 0.050810: 1.04x slower
Avg: 0.048692 -> 0.051619: 1.06x slower
Significant (t=-69.92)
Stddev: 0.00002 -> 0.00030: 16.7793x larger

### silent_logging ###
Min: 0.069539 -> 0.071172: 1.02x slower
Avg: 0.069679 -> 0.071230: 1.02x slower
Significant (t=-124.08)
Stddev: 0.00009 -> 0.00002: 3.7073x smaller

### simple_logging ###
Min: 0.278439 -> 0.287736: 1.03x slower
Avg: 0.279504 -> 0.288811: 1.03x slower
Significant (t=-52.46)
Stddev: 0.00084 -> 0.00093: 1.1074x larger

### telco ###
Min: 0.012480 -> 0.013104: 1.05x slower
Avg: 0.012561 -> 0.013157: 1.05x slower
Significant (t=-100.42)
Stddev: 0.00004 -> 0.00002: 1.5881x smaller

### unpack_sequence ###
Min: 0.000047 -> 0.000048: 1.03x slower
Avg: 0.000047 -> 0.000048: 1.03x slower
Significant (t=-1170.16)
Stddev: 0.00000 -> 0.00000: 1.0749x larger

### unpickle_list ###
Min: 0.325310 -> 0.330080: 1.01x slower
Avg: 0.326484 -> 0.333974: 1.02x slower
Significant (t=-24.19)
Stddev: 0.00100 -> 0.00195: 1.9392x larger

[ faster ]

### chameleon_v2 ###
Min: 5.525575 -> 5.263668: 1.05x faster
Avg: 5.541444 -> 5.281893: 1.05x faster
Significant (t=85.79)
Stddev: 0.01107 -> 0.01831: 1.6539x larger

### etree_iterparse ###
Min: 0.212073 -> 0.197146: 1.08x faster
Avg: 0.215504 -> 0.200254: 1.08x faster
Significant (t=61.07)
Stddev: 0.00119 -> 0.00130: 1.0893x larger

### etree_parse ###
Min: 0.282983 -> 0.260390: 1.09x faster
Avg: 0.284333 -> 0.262758: 1.08x faster
Significant (t=77.34)
Stddev: 0.00102 -> 0.00169: 1.6628x larger

### etree_process ###
Min: 0.218953 -> 0.213683: 1.02x faster
Avg: 0.221036 -> 0.215280: 1.03x faster
Significant (t=25.98)
Stddev: 0.00114 -> 0.00108: 1.0580x smaller

### hexiom2 ###
Min: 122.001408 -> 118.967112: 1.03x faster
Avg: 122.108010 -> 119.110115: 1.03x faster
Significant (t=16.81)
Stddev: 0.15076 -> 0.20224: 1.3415x larger

### pathlib ###
Min: 0.088533 -> 0.084888: 1.04x faster
Avg: 0.088916 -> 0.085280: 1.04x faster
Significant (t=257.68)
Stddev: 0.00014 -> 0.00017: 1.1725x larger


The following not significant results are hidden, use -v to show them:
call_method, call_method_unknown, etree_generate, fannkuch, fastpickle, fastunpickle, go, json_dump_v2, json_load, nbody, normal_startup, pickle_dict, pidigits, regex_v8, richards, spectral_norm, startup_nosite, tornado_http.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Fri Apr 22 11:11:57 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Fri, 22 Apr 2016 15:11:57 +0000
Subject: [issue26823] Shrink recursive tracebacks
In-Reply-To: <1461292585.22.0.159887337407.issue26823@psf.upfronthosting.co.za>
Message-ID: <1461337917.43.0.19078158276.issue26823@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

New version with tests now, I test both the C and Python implementations.

----------
assignee:  -> ebarry
Added file: http://bugs.python.org/file42570/short_tracebacks_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26823>
_______________________________________

From report at bugs.python.org  Fri Apr 22 11:43:50 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 22 Apr 2016 15:43:50 +0000
Subject: [issue22234] urllib.parse.urlparse accepts any falsy value as an url
In-Reply-To: <1408538391.97.0.53072227801.issue22234@psf.upfronthosting.co.za>
Message-ID: <1461339830.57.0.30914294753.issue22234@psf.upfronthosting.co.za>


R. David Murray added the comment:

I just posted about this on the mentors list, where someone brought this issue up with a question about our policy on type checking.  The short version is the better (preserves duck-typing) and more backward compatibile fix is to change the test to be

   x != ''

That will result in an attribute error on 'decode' for values of the incorrect type.

But even that should go through a deperecation cycle, since there may be working programs depending on the current behavior.  It's worth fixing, though, because of the error propogation you report.  I also suggested a rewrite of _check_args to get a better error message that would indeed be a type error, and I'm anticipating someone from the mentors list will turn that into a patch here.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22234>
_______________________________________

From report at bugs.python.org  Fri Apr 22 11:48:34 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Apr 2016 15:48:34 +0000
Subject: [issue26827] PyObject *PyInit_myextention -> PyMODINIT_FUNC
 PyInit_myextention
In-Reply-To: <1461326895.36.0.898462963597.issue26827@psf.upfronthosting.co.za>
Message-ID: <1461340114.34.0.228244617883.issue26827@psf.upfronthosting.co.za>


Brett Cannon added the comment:

https://docs.python.org/3/extending/extending.html#the-module-s-method-table-and-initialization-function documents what Herbert discovered wrong in the porting docs.

----------
keywords: +easy
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26827>
_______________________________________

From report at bugs.python.org  Fri Apr 22 11:49:11 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Apr 2016 15:49:11 +0000
Subject: [issue26827] PyObject *PyInit_myextention -> PyMODINIT_FUNC
 PyInit_myextention
In-Reply-To: <1461326895.36.0.898462963597.issue26827@psf.upfronthosting.co.za>
Message-ID: <1461340151.7.0.190878129079.issue26827@psf.upfronthosting.co.za>


Brett Cannon added the comment:

And in case my comment wasn't obvious, Herbert is right about the error in the docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26827>
_______________________________________

From report at bugs.python.org  Fri Apr 22 12:22:13 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Apr 2016 16:22:13 +0000
Subject: [issue23507] Tuple creation is too slow
In-Reply-To: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za>
Message-ID: <1461342133.6.0.630043635878.issue23507@psf.upfronthosting.co.za>


STINNER Victor added the comment:

reuse_argtuples_3.patch: rebased reuse_argtuples_2.patch.

----------
Added file: http://bugs.python.org/file42571/reuse_argtuples_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23507>
_______________________________________

From report at bugs.python.org  Fri Apr 22 12:59:17 2016
From: report at bugs.python.org (Francisco Couzo)
Date: Fri, 22 Apr 2016 16:59:17 +0000
Subject: [issue26830] Refactor Tools/scripts/google.py
Message-ID: <1461344357.96.0.182735682536.issue26830@psf.upfronthosting.co.za>


Changes by Francisco Couzo <franciscouzo at gmail.com>:


----------
files: scripts_google.patch
keywords: patch
nosy: franciscouzo
priority: normal
severity: normal
status: open
title: Refactor Tools/scripts/google.py
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42572/scripts_google.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26830>
_______________________________________

From report at bugs.python.org  Fri Apr 22 13:11:48 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Apr 2016 17:11:48 +0000
Subject: [issue26249] Change PyMem_Malloc to use pymalloc allocator
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <20160422171119.53846.12124.6E54B82B@psf.io>


Roundup Robot added the comment:

New changeset 104ed24ebbd0 by Victor Stinner in branch 'default':
Issue #26249: Try test_capi on Windows
https://hg.python.org/cpython/rev/104ed24ebbd0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26249>
_______________________________________

From report at bugs.python.org  Fri Apr 22 13:37:34 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 22 Apr 2016 17:37:34 +0000
Subject: [issue26830] Refactor Tools/scripts/google.py
Message-ID: <1461346654.96.0.919095766119.issue26830@psf.upfronthosting.co.za>


New submission from Berker Peksag:

I don't think google.py is useful anymore. I'd prefer to just remove it from the cpython repository.

----------
components: +Demos and Tools
nosy: +berker.peksag
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26830>
_______________________________________

From report at bugs.python.org  Fri Apr 22 14:58:35 2016
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 22 Apr 2016 18:58:35 +0000
Subject: [issue4821] Patches for thread-support in built-in SHA modules
In-Reply-To: <1231002504.32.0.171592356443.issue4821@psf.upfronthosting.co.za>
Message-ID: <1461351515.07.0.440727175434.issue4821@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4821>
_______________________________________

From report at bugs.python.org  Fri Apr 22 15:00:52 2016
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 22 Apr 2016 19:00:52 +0000
Subject: [issue16113] Add SHA-3 and SHAKE (Keccak) support
In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za>
Message-ID: <1461351652.09.0.784552990501.issue16113@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The authors of Keccak have released a new version of the Keccak Code Package, http://keccak.noekeon.org/reorganized_code.html . The new package makes it much easier to integrate Keccak in Python. I'm working on a new patch with SHA3 and SHAKE support.

----------
stage:  -> needs patch
title: Add SHA-3 (Keccak) support -> Add SHA-3 and SHAKE (Keccak) support

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16113>
_______________________________________

From report at bugs.python.org  Fri Apr 22 16:41:19 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 22 Apr 2016 20:41:19 +0000
Subject: [issue23507] Tuple creation is too slow
In-Reply-To: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za>
Message-ID: <1461357679.4.0.0159479650627.issue23507@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/issue23507>
_______________________________________

From report at bugs.python.org  Fri Apr 22 17:56:34 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 22 Apr 2016 21:56:34 +0000
Subject: [issue26830] Refactor Tools/scripts/google.py
In-Reply-To: <1461346654.96.0.919095766119.issue26830@psf.upfronthosting.co.za>
Message-ID: <1461362194.5.0.176937295576.issue26830@psf.upfronthosting.co.za>


Ned Deily added the comment:

FWIW, I'm -0 on removing google.py and +0.5 on the refactoring.  It seems like it could still be useful as either an example or a tool.  Georg did a cleanup of the Tools directory several years ago (in Issue7962).  Rather than removing one script, it might be more useful to review them all for relevance.  In any case, thanks for the contribution, Francisco.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26830>
_______________________________________

From report at bugs.python.org  Fri Apr 22 18:37:38 2016
From: report at bugs.python.org (Hans-Peter Jansen)
Date: Fri, 22 Apr 2016 22:37:38 +0000
Subject: [issue26831] ConfigParser parsing failures with default_section and
 ExtendedInterpolation options
Message-ID: <1461364657.99.0.761573071574.issue26831@psf.upfronthosting.co.za>


New submission from Hans-Peter Jansen:

ConfigParser fails in interesting ways, when using default_section and ExtendedInterpolation options. Running the attached script results in: 

ConfigParser() with expected result:
global: [('loglevel', 'WARNING'), ('logfile', '-')]
section1: [('key_a', 'value'), ('key_b', 'morevalue')]
section2: [('key_c', 'othervalue'), ('key_d', 'differentvalue')]

ConfigParser(default_section='global') mangles section separation:
section1: [('loglevel', 'WARNING'), ('logfile', '-'), ('key_a', 'value'), ('key_b', 'morevalue')]
section2: [('loglevel', 'WARNING'), ('logfile', '-'), ('key_c', 'othervalue'), ('key_d', 'differentvalue')]

ConfigParser(interpolation=ExtendedInterpolation) fails with strange error:
Traceback (most recent call last):
  File "configparser-test.py", line 36, in <module>
    print_sections(cp)
  File "configparser-test.py", line 21, in print_sections
    cp.read_string(__doc__)
  File "/usr/lib64/python3.4/configparser.py", line 696, in read_string
    self.read_file(sfile, source)
  File "/usr/lib64/python3.4/configparser.py", line 691, in read_file
    self._read(f, source)
  File "/usr/lib64/python3.4/configparser.py", line 1089, in _read
    self._join_multiline_values()
  File "/usr/lib64/python3.4/configparser.py", line 1101, in _join_multiline_values
    name, val)
TypeError: before_read() missing 1 required positional argument: 'value'

while it is expected to behave identical.

----------
components: Library (Lib)
files: configparser-test.py
messages: 264031
nosy: frispete
priority: normal
severity: normal
status: open
title: ConfigParser parsing failures with default_section and ExtendedInterpolation options
versions: Python 3.4
Added file: http://bugs.python.org/file42573/configparser-test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26831>
_______________________________________

From report at bugs.python.org  Fri Apr 22 19:28:05 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Apr 2016 23:28:05 +0000
Subject: [issue26446] Mention in the devguide that core dev stuff falls under
 the PSF CoC
In-Reply-To: <1456514667.83.0.674412678031.issue26446@psf.upfronthosting.co.za>
Message-ID: <1461367685.16.0.487787342377.issue26446@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/issue26446>
_______________________________________

From report at bugs.python.org  Fri Apr 22 19:29:12 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Apr 2016 23:29:12 +0000
Subject: [issue26446] Mention in the devguide that core dev stuff falls under
 the PSF CoC
In-Reply-To: <1456514667.83.0.674412678031.issue26446@psf.upfronthosting.co.za>
Message-ID: <1461367752.14.0.534838676977.issue26446@psf.upfronthosting.co.za>


Brett Cannon added the comment:

The python-dev thread more-or-less petered out w/ the basic agreement that adding a short mention in the devguide would be tolerable. When I have a chance I will add a very short mention at the end of the opening page.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26446>
_______________________________________

From report at bugs.python.org  Fri Apr 22 19:31:18 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Apr 2016 23:31:18 +0000
Subject: [issue24016] Add a Sprints organization/preparation section to
 devguide
In-Reply-To: <1429545736.46.0.134603387564.issue24016@psf.upfronthosting.co.za>
Message-ID: <1461367878.27.0.513591513044.issue24016@psf.upfronthosting.co.za>


Brett Cannon added the comment:

This should also include a mention of devinabox.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24016>
_______________________________________

From report at bugs.python.org  Fri Apr 22 20:33:55 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 23 Apr 2016 00:33:55 +0000
Subject: [issue20962] Rather modest chunk size in gzip.GzipFile
In-Reply-To: <1395082726.87.0.730756156096.issue20962@psf.upfronthosting.co.za>
Message-ID: <1461371635.23.0.582247646158.issue20962@psf.upfronthosting.co.za>


Martin Panter added the comment:

Since there doesn?t seem to be much interest here any more, and the current code has changed and now uses 8 KiB buffering, I am closing this. Although in theory a buffer or chunk size paramter could still be added to the new code if there was a need.

----------
resolution:  -> out of date
status: open -> closed
superseder:  -> Limit decompressed data when reading from LZMAFile and BZ2File
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20962>
_______________________________________

From report at bugs.python.org  Fri Apr 22 20:47:43 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 23 Apr 2016 00:47:43 +0000
Subject: [issue16679] Add advice about non-ASCII wsgiref PATH_INFO
In-Reply-To: <1355473710.36.0.278942451351.issue16679@psf.upfronthosting.co.za>
Message-ID: <1461372463.43.0.610790400891.issue16679@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16679>
_______________________________________

From report at bugs.python.org  Fri Apr 22 21:46:30 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 23 Apr 2016 01:46:30 +0000
Subject: [issue7567] Messed up terminal after calling curses.initscr() twice.
In-Reply-To: <1261532778.06.0.257601342471.issue7567@psf.upfronthosting.co.za>
Message-ID: <1461375990.68.0.33437432146.issue7567@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7567>
_______________________________________

From report at bugs.python.org  Fri Apr 22 21:51:34 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Apr 2016 01:51:34 +0000
Subject: [issue22359] Remove incorrect uses of recursive make
In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za>
Message-ID: <20160423015131.21458.27499.6ACE8F50@psf.io>


Roundup Robot added the comment:

New changeset 66e40df31fac by Martin Panter in branch '3.5':
Issue #22359: Disable running cross-compiled _freeze_importlib and pgen
https://hg.python.org/cpython/rev/66e40df31fac

New changeset c36b9ef8ff39 by Martin Panter in branch 'default':
Issue #22359: Merge cross-compilation fix from 3.5
https://hg.python.org/cpython/rev/c36b9ef8ff39

New changeset 0f7a299c6d50 by Martin Panter in branch '2.7':
Issue #22359: Avoid recursive $(MAKE); disable running cross-compiled pgen
https://hg.python.org/cpython/rev/0f7a299c6d50

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22359>
_______________________________________

From report at bugs.python.org  Fri Apr 22 21:52:40 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 23 Apr 2016 01:52:40 +0000
Subject: [issue20077] Format of TypeError differs between comparison and
 arithmetic operators
In-Reply-To: <1388106970.8.0.6745803605.issue20077@psf.upfronthosting.co.za>
Message-ID: <1461376360.32.0.910456845304.issue20077@psf.upfronthosting.co.za>


Berker Peksag added the comment:

The exception message has been updated to "TypeError: '<' not supported between instances of 'Color' and 'Color'" in 0238eafb68da. Closing this as 'out of date'.

----------
nosy: +berker.peksag
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20077>
_______________________________________

From report at bugs.python.org  Fri Apr 22 21:52:46 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 23 Apr 2016 01:52:46 +0000
Subject: [issue26721] Avoid socketserver.StreamRequestHandler.wfile doing
 partial writes
In-Reply-To: <1460204395.72.0.250418211057.issue26721@psf.upfronthosting.co.za>
Message-ID: <1461376366.01.0.424478397273.issue26721@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26721>
_______________________________________

From report at bugs.python.org  Fri Apr 22 21:54:17 2016
From: report at bugs.python.org (Mark Kellogg)
Date: Sat, 23 Apr 2016 01:54:17 +0000
Subject: [issue26773] Shelve works inconsistently when carried over to child
 processes
In-Reply-To: <1460749416.45.0.0472811645443.issue26773@psf.upfronthosting.co.za>
Message-ID: <1461376457.69.0.0757652653663.issue26773@psf.upfronthosting.co.za>


Mark Kellogg added the comment:

I have also been running into this issue. 

I am using Debian GNU/Linux 8, it was also reproduced on ubuntu by a coworker. 

It however was not reproducible on Gentoo in our testing.

----------
nosy: +mkellogg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26773>
_______________________________________

From report at bugs.python.org  Fri Apr 22 22:01:24 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 23 Apr 2016 02:01:24 +0000
Subject: [issue12640] test_ctypes seg fault (test_callback_register_double);
 armv7; gcc 4.5.1
In-Reply-To: <1311637071.74.0.758300374846.issue12640@psf.upfronthosting.co.za>
Message-ID: <1461376884.47.0.692315333447.issue12640@psf.upfronthosting.co.za>


Berker Peksag added the comment:

2.7 now uses libffi 3.1 and our ARM buildbots are quite healthy so I think we can now close this 'out of date'.

----------
nosy: +berker.peksag
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12640>
_______________________________________

From report at bugs.python.org  Fri Apr 22 22:03:04 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 23 Apr 2016 02:03:04 +0000
Subject: [issue23806] documentation for no_proxy is missing from the python3
 urllib documentation
In-Reply-To: <1427640986.55.0.996928918568.issue23806@psf.upfronthosting.co.za>
Message-ID: <1461376984.67.0.522041779375.issue23806@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +easy
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23806>
_______________________________________

From report at bugs.python.org  Fri Apr 22 22:19:06 2016
From: report at bugs.python.org (Mark Kellogg)
Date: Sat, 23 Apr 2016 02:19:06 +0000
Subject: [issue26773] Shelve works inconsistently when carried over to child
 processes
In-Reply-To: <1460749416.45.0.0472811645443.issue26773@psf.upfronthosting.co.za>
Message-ID: <1461377946.01.0.248593132607.issue26773@psf.upfronthosting.co.za>


Mark Kellogg added the comment:

The gentoo user's version of gdbm is: gdbm-1.11

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26773>
_______________________________________

From report at bugs.python.org  Fri Apr 22 22:54:24 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Apr 2016 02:54:24 +0000
Subject: [issue26828] Implement __length_hint__() on map() and filter() to
 optimize list(map) and list(filter)
In-Reply-To: <1461327160.24.0.621419084727.issue26828@psf.upfronthosting.co.za>
Message-ID: <1461380064.44.0.864175493257.issue26828@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Victor, are you suggesting the following?  "If map has a single iterable, call and return as hint, otherwise give up."  Or something else?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26828>
_______________________________________

From report at bugs.python.org  Fri Apr 22 23:35:49 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Apr 2016 03:35:49 +0000
Subject: [issue23806] documentation for no_proxy is missing from the python3
 urllib documentation
In-Reply-To: <1427640986.55.0.996928918568.issue23806@psf.upfronthosting.co.za>
Message-ID: <20160423033546.381.15342.E377F2F1@psf.io>


Roundup Robot added the comment:

New changeset 5424a559ddea by Senthil Kumaran in branch '3.5':
Issue23806 - Document the no_proxy environment variable in Python 3 docs.
https://hg.python.org/cpython/rev/5424a559ddea

New changeset 103fb8be940b by Senthil Kumaran in branch 'default':
merge 3.5
https://hg.python.org/cpython/rev/103fb8be940b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23806>
_______________________________________

From report at bugs.python.org  Fri Apr 22 23:37:59 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 23 Apr 2016 03:37:59 +0000
Subject: [issue23806] documentation for no_proxy is missing from the python3
 urllib documentation
In-Reply-To: <1427640986.55.0.996928918568.issue23806@psf.upfronthosting.co.za>
Message-ID: <1461382679.55.0.186323689816.issue23806@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

no_proxy is applicable to ProxyHandler of the python 3. I've documented this in the corresponding section.

----------
nosy: +orsenthil
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23806>
_______________________________________

From report at bugs.python.org  Fri Apr 22 23:45:50 2016
From: report at bugs.python.org (Gabriel Mesquita Cangussu)
Date: Sat, 23 Apr 2016 03:45:50 +0000
Subject: [issue26832] ProactorEventLoop doesn't support stdin/stdout nor files
 with connect_read_pipe/connect_write_pipe
Message-ID: <1461383150.45.0.258316694453.issue26832@psf.upfronthosting.co.za>


New submission from Gabriel Mesquita Cangussu:

The documentation of asyncio specifies that the methods connect_read_pipe and connect_write_pipe are available on Windows with the ProactorEventLoop. The documentation then says that those methods accept file-like objects on the pipe parameter. However, the methods doesn't seem to work with stdio or any disk file under Windows. The following example catches this problem:

import asyncio
import sys

class MyProtocol(asyncio.Protocol):
    def connection_made(self, transport):
        print('connection established')
        
    def data_received(self, data):
        print('received: {!r}'.format(data.decode()))
        
    def connection_lost(self, exc):
        print('lost connection')

if sys.platform.startswith('win32'):
    loop = asyncio.ProactorEventLoop()
else:
    loop = asyncio.SelectorEventLoop()
coro = loop.connect_read_pipe(MyProtocol, sys.stdin)
loop.run_until_complete(coro)
loop.run_forever()
loop.close()


This code when executed on Ubuntu have the desired behavior, but under Windows 10 it gives OSError: [WinError 6] The handle is invalid. The complete output is this:

c:\Users\Gabriel\Documents\Python Scripts>python async_pipe.py
connection established
Fatal read error on pipe transport
protocol: <__main__.MyProtocol object at 0x000001970EB2FAC8>
transport: <_ProactorReadPipeTransport fd=0>
Traceback (most recent call last):
  File "C:\Program Files\Python35\lib\asyncio\proactor_events.py", line 195, in _loop_reading
    self._read_fut = self._loop._proactor.recv(self._sock, 4096)
  File "C:\Program Files\Python35\lib\asyncio\windows_events.py", line 425, in recv
    self._register_with_iocp(conn)
  File "C:\Program Files\Python35\lib\asyncio\windows_events.py", line 606, in _register_with_iocp
    _overlapped.CreateIoCompletionPort(obj.fileno(), self._iocp, 0, 0)
OSError: [WinError 6] Identificador inv?lido
lost connection


I think that the documentation should state that there is no support for disk files and stdio with the methods in question and also state what exactly they support (an example would be nice). And, of course, better support for watching file descriptors on Windows on future Python releases would be nice.

Thank you,
Gabriel

----------
components: Windows, asyncio
messages: 264043
nosy: Gabriel Mesquita Cangussu, gvanrossum, haypo, paul.moore, steve.dower, tim.golden, yselivanov, zach.ware
priority: normal
severity: normal
status: open
title: ProactorEventLoop doesn't support stdin/stdout nor files with connect_read_pipe/connect_write_pipe
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26832>
_______________________________________

From report at bugs.python.org  Sat Apr 23 00:57:25 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 23 Apr 2016 04:57:25 +0000
Subject: [issue26832] ProactorEventLoop doesn't support stdin/stdout nor files
 with connect_read_pipe/connect_write_pipe
In-Reply-To: <1461383150.45.0.258316694453.issue26832@psf.upfronthosting.co.za>
Message-ID: <1461387445.01.0.213431846128.issue26832@psf.upfronthosting.co.za>


Steve Dower added the comment:

> File "C:\Program Files\Python35\lib\asyncio\windows_events.py", line 606, in _register_with_iocp
>   _overlapped.CreateIoCompletionPort(obj.fileno(), self._iocp, 0, 0)

I don't think there's any case where this is going to work on an actual file - CreateIoCompletionPort needs a handle and not a file descriptor.

Presumably this line of code normally gets used with something else that defines fileno()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26832>
_______________________________________

From report at bugs.python.org  Sat Apr 23 02:14:54 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 23 Apr 2016 06:14:54 +0000
Subject: [issue26824] Make some macros use Py_TYPE
In-Reply-To: <1461300890.73.0.522492647874.issue26824@psf.upfronthosting.co.za>
Message-ID: <1461392094.46.0.0395143569632.issue26824@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

No problems! You are welcome.

I never read PEP3123 and it was a good opportunity to read this part of Python history.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26824>
_______________________________________

From report at bugs.python.org  Sat Apr 23 02:15:57 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 23 Apr 2016 06:15:57 +0000
Subject: [issue26733] staticmethod and classmethod are ignored when
 disassemble class
In-Reply-To: <1460369974.2.0.716803365246.issue26733@psf.upfronthosting.co.za>
Message-ID: <1461392157.25.0.571756107685.issue26733@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
stage: patch review -> commit review
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26733>
_______________________________________

From report at bugs.python.org  Sat Apr 23 02:24:55 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Apr 2016 06:24:55 +0000
Subject: [issue26733] staticmethod and classmethod are ignored when
 disassemble class
In-Reply-To: <1460369974.2.0.716803365246.issue26733@psf.upfronthosting.co.za>
Message-ID: <20160423062449.124498.23184.1743BE36@psf.io>


Roundup Robot added the comment:

New changeset d14ea3964590 by Serhiy Storchaka in branch '3.5':
Issue #26733: Disassembling a class now disassembles class and static methods.
https://hg.python.org/cpython/rev/d14ea3964590

New changeset f96fec10cf25 by Serhiy Storchaka in branch 'default':
Issue #26733: Disassembling a class now disassembles class and static methods.
https://hg.python.org/cpython/rev/f96fec10cf25

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26733>
_______________________________________

From report at bugs.python.org  Sat Apr 23 02:25:52 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 23 Apr 2016 06:25:52 +0000
Subject: [issue26733] staticmethod and classmethod are ignored when
 disassemble class
In-Reply-To: <1460369974.2.0.716803365246.issue26733@psf.upfronthosting.co.za>
Message-ID: <1461392752.47.0.567669407906.issue26733@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your contribution Xiang Zhang.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26733>
_______________________________________

From report at bugs.python.org  Sat Apr 23 02:30:14 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 23 Apr 2016 06:30:14 +0000
Subject: [issue26634] recursive_repr forgets to override __qualname__ of
 wrapper
In-Reply-To: <1458792576.69.0.965727650976.issue26634@psf.upfronthosting.co.za>
Message-ID: <1461393014.38.0.243306797492.issue26634@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM. I would commit the patch to 3.5 too.

----------
nosy: +serhiy.storchaka
stage:  -> commit review
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26634>
_______________________________________

From report at bugs.python.org  Sat Apr 23 02:43:32 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Apr 2016 06:43:32 +0000
Subject: [issue26827] PyObject *PyInit_myextention -> PyMODINIT_FUNC
 PyInit_myextention
In-Reply-To: <1461326895.36.0.898462963597.issue26827@psf.upfronthosting.co.za>
Message-ID: <20160423064328.26189.27314.94AAC9F0@psf.io>


Roundup Robot added the comment:

New changeset 188af2b4945a by Benjamin Peterson in branch '3.5':
fix python 3 mod init function declaration (closes #26827)
https://hg.python.org/cpython/rev/188af2b4945a

New changeset df0e900b8860 by Benjamin Peterson in branch 'default':
merge 3.5 (#26827)
https://hg.python.org/cpython/rev/df0e900b8860

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26827>
_______________________________________

From report at bugs.python.org  Sat Apr 23 02:49:21 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Apr 2016 06:49:21 +0000
Subject: [issue26827] PyObject *PyInit_myextention -> PyMODINIT_FUNC
 PyInit_myextention
In-Reply-To: <1461326895.36.0.898462963597.issue26827@psf.upfronthosting.co.za>
Message-ID: <20160423064919.15818.18212.55BF5C6F@psf.io>


Roundup Robot added the comment:

New changeset 8d6bd32a56a8 by Benjamin Peterson in branch '2.7':
fix python 3 mod init function declaration (closes #26827)
https://hg.python.org/cpython/rev/8d6bd32a56a8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26827>
_______________________________________

From report at bugs.python.org  Sat Apr 23 03:08:56 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 23 Apr 2016 07:08:56 +0000
Subject: [issue25341] File mode wb+ appears as rb+
In-Reply-To: <1444290178.48.0.0607111061258.issue25341@psf.upfronthosting.co.za>
Message-ID: <1461395336.17.0.543809205004.issue25341@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> But this behaviour treating wb+ and rb+ as the same is well tested and
seems to intended to do so.

I think this is not intended behavior. Tests just test that the current behavior is not changed accidentally. If I'm right, the patch LGTM. But since third-party code can depend on this behavior, I would fix it only in 3.6.

Tests were added in issue4362 and Barry asked the same question about "w+" (msg76134).

Barry, Benjamin, what are you think about this now?

----------
nosy: +barry, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25341>
_______________________________________

From report at bugs.python.org  Sat Apr 23 03:18:30 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Apr 2016 07:18:30 +0000
Subject: [issue26828] Implement __length_hint__() on map() and filter() to
 optimize list(map) and list(filter)
In-Reply-To: <1461380064.44.0.864175493257.issue26828@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYstctYHyqRJU0-Ng9joiUXbAJd5w=jsKWtyEeKE+=aCg@mail.gmail.com>


STINNER Victor added the comment:

I checked Python 2 for map(): it gets the length hint of all iterables and
use the maximum, with a default of 8. I'm not sure of what you mean by
errors, the function to get the length hint already catchs and ignores
errors no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26828>
_______________________________________

From report at bugs.python.org  Sat Apr 23 03:40:43 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 23 Apr 2016 07:40:43 +0000
Subject: [issue26828] Implement __length_hint__() on map() and filter() to
 optimize list(map) and list(filter)
In-Reply-To: <1461327160.24.0.621419084727.issue26828@psf.upfronthosting.co.za>
Message-ID: <1461397243.74.0.936444577851.issue26828@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

map and zip should use the minimum, zip_longest should use the maximum, and filter shouldn't have __length_hint__().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26828>
_______________________________________

From report at bugs.python.org  Sat Apr 23 03:54:07 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Apr 2016 07:54:07 +0000
Subject: [issue26822] itemgetter/attrgetter/methodcaller objects ignore
 keyword arguments
In-Reply-To: <1461266621.67.0.0664681491354.issue26822@psf.upfronthosting.co.za>
Message-ID: <20160423075404.21466.29053.FF74F062@psf.io>


Roundup Robot added the comment:

New changeset 16461a0016bf by Serhiy Storchaka in branch '3.5':
Issue #26822: itemgetter, attrgetter and methodcaller objects no longer
https://hg.python.org/cpython/rev/16461a0016bf

New changeset 9b565815079a by Serhiy Storchaka in branch '2.7':
Issue #26822: itemgetter, attrgetter and methodcaller objects no longer
https://hg.python.org/cpython/rev/9b565815079a

New changeset 5faccb403ad8 by Serhiy Storchaka in branch 'default':
Issue #26822: itemgetter, attrgetter and methodcaller objects no longer
https://hg.python.org/cpython/rev/5faccb403ad8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26822>
_______________________________________

From report at bugs.python.org  Sat Apr 23 03:55:01 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 23 Apr 2016 07:55:01 +0000
Subject: [issue26822] itemgetter/attrgetter/methodcaller objects ignore
 keyword arguments
In-Reply-To: <1461266621.67.0.0664681491354.issue26822@psf.upfronthosting.co.za>
Message-ID: <1461398101.01.0.158329286972.issue26822@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/issue26822>
_______________________________________

From report at bugs.python.org  Sat Apr 23 03:58:14 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sat, 23 Apr 2016 07:58:14 +0000
Subject: [issue26788] test_gdb fails all tests on a profile-opt build
 configured --with-lto
In-Reply-To: <1460874599.33.0.6029536171.issue26788@psf.upfronthosting.co.za>
Message-ID: <1461398294.25.0.102658753545.issue26788@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

I uploaded a patch that skips these tests if optimizations are available.

----------
keywords: +patch
Added file: http://bugs.python.org/file42574/issue26788.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26788>
_______________________________________

From report at bugs.python.org  Sat Apr 23 04:32:05 2016
From: report at bugs.python.org (Thomas)
Date: Sat, 23 Apr 2016 08:32:05 +0000
Subject: [issue26833] returning ctypes._SimpleCData objects from callbacks
Message-ID: <1461400325.28.0.01385438687.issue26833@psf.upfronthosting.co.za>


New submission from Thomas:

If a callback function returns a ctypes._SimpleCData object, it will fail with a type error and complain that it expects a basic type.

Using the qsort example:

def py_cmp_func(a, b):
    print(a.contents, b.contents)
    return c_int(0)

> TypeError: an integer is required (got type c_int)
> Exception ignored in: <function py_cmp_func at 0x2439648>

This is somewhat surprising as it is totally fine to pass a c_int (or an int) as an c_int argument. But this is really an issue for subclasses of fundamental data types:

(sticking with qsort for simplicity, full example attached)

class CmpRet(c_int):
    pass

cmp_ctype = CFUNCTYPE(CmpRet, POINTER(c_int), POINTER(c_int))

def py_cmp_func(a, b):
    print(a.contents, b.contents)
    return CmpRet(0)

> TypeError: an integer is required (got type CmpRet)
> Exception ignored in: <function py_cmp_func at 0x1049cf8>

This is inconsistent with the no transparent argument/return type conversion rule for subclasses.

Consider for instance an enum with a specific underlying type. A subclass (with __eq__ on value) from the corresponding ctype can be useful to provide a typesafe way to pass / receive those from C. Due to the described behavior, this doesn't work for callbacks.

This is related to #5710, that discusses composite types.

----------
files: callback_ret_sub.py
messages: 264056
nosy: tilsche
priority: normal
severity: normal
status: open
title: returning ctypes._SimpleCData objects from callbacks
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file42575/callback_ret_sub.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26833>
_______________________________________

From report at bugs.python.org  Sat Apr 23 04:46:27 2016
From: report at bugs.python.org (=?utf-8?q?Kim_Gr=C3=A4sman?=)
Date: Sat, 23 Apr 2016 08:46:27 +0000
Subject: [issue17233] http.client header debug output format
In-Reply-To: <1361256774.67.0.162902666936.issue17233@psf.upfronthosting.co.za>
Message-ID: <1461401186.99.0.23595803948.issue17233@psf.upfronthosting.co.za>


Kim Gr?sman added the comment:

Thanks! I filed this so long ago that I'd forgotten about it.

I ran the code in question with your patch manually hacked into my Python installation (3.4.1) and output is much easier to digest now.

I don't have a strong opinion on key names -- I haven't needed this code path since I filed the bug :) -- it's probably fine as-is if nobody wants to take a stab at it.

Anyway, thanks for this, I can confirm that it solves my problem, and it would be nice if it went into trunk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17233>
_______________________________________

From report at bugs.python.org  Sat Apr 23 04:52:42 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sat, 23 Apr 2016 08:52:42 +0000
Subject: [issue26359] CPython build options for out-of-the box performance
In-Reply-To: <1455445693.01.0.984013993837.issue26359@psf.upfronthosting.co.za>
Message-ID: <1461401562.64.0.989581326067.issue26359@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

I've added the --with-optimizations option to configure, for CPython3 only at this point. If it looks good I'll create a version also for CPython2.

----------
Added file: http://bugs.python.org/file42576/cpython3_with_optimizations_v01.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26359>
_______________________________________

From report at bugs.python.org  Sat Apr 23 04:53:44 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 23 Apr 2016 08:53:44 +0000
Subject: [issue26831] ConfigParser parsing failures with default_section and
 ExtendedInterpolation options
In-Reply-To: <1461364657.99.0.761573071574.issue26831@psf.upfronthosting.co.za>
Message-ID: <1461401624.09.0.0610146813101.issue26831@psf.upfronthosting.co.za>


SilentGhost added the comment:

I think there is some misunderstanding of what default_section is supposed to do, in fact in provides default values for *other* section, as the documentation says, it doesn't mangle section separation.

In case of ExtendedInterpolation, the interpolation argument needs to be instantiated, i.e. the call should be:
ConfigParser(interpolation=ExtendedInterpolation())

----------
nosy: +SilentGhost, lukasz.langa
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26831>
_______________________________________

From report at bugs.python.org  Sat Apr 23 05:35:28 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 23 Apr 2016 09:35:28 +0000
Subject: [issue26811] segfault due to null pointer in tuple
In-Reply-To: <1461198016.05.0.40690695807.issue26811@psf.upfronthosting.co.za>
Message-ID: <1461404128.8.0.230324966785.issue26811@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

May be using _PyObject_GC_UNTRACK() is more correct than setting the size to 0 or setting the item to None. But property_descr_get_gc_untrack.patch makes the code a little slower. Here is optimized version of Victor's patch.

----------
Added file: http://bugs.python.org/file42577/property_descr_get_gc_untrack_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26811>
_______________________________________

From report at bugs.python.org  Sat Apr 23 08:11:11 2016
From: report at bugs.python.org (Demur Rumed)
Date: Sat, 23 Apr 2016 12:11:11 +0000
Subject: [issue23507] Tuple creation is too slow
In-Reply-To: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za>
Message-ID: <1461413471.65.0.243486948892.issue23507@psf.upfronthosting.co.za>


Demur Rumed added the comment:

This code could be made to look a lot less hackish if the potential tuple reuse was abstracted by a PyTuple_UniqueOrNew(PyTuple) which returns its argument if REFCNT==1 otherwise allocates a tuple of the same size & returns that. It decrefs PyTuple if REFCNT != 1

----------
nosy: +Demur Rumed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23507>
_______________________________________

From report at bugs.python.org  Sat Apr 23 12:10:08 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Sat, 23 Apr 2016 16:10:08 +0000
Subject: [issue26039] More flexibility in zipfile write interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1461427808.02.0.10554801408.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Martin, Serhiy: Am I right that it would be unacceptable to change the test, and I therefore need to find a way to allow writestr while a reading-mode handle is open?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Sat Apr 23 13:21:33 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 23 Apr 2016 17:21:33 +0000
Subject: [issue26800] Don't accept bytearray as filenames part 2
In-Reply-To: <1461015295.39.0.246147143774.issue26800@psf.upfronthosting.co.za>
Message-ID: <1461432093.57.0.15333711464.issue26800@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I'm a little bit worried about removing support for bytearray in these cases. It used to be quite easy to support bytes and bytearray (just say you support the buffer API), and I even added language to PEP 484 suggesting that type checkers should consider bytearray (and memoryview) as valid arguments to anything that's declared as taking bytes. I know this is not universally true (a trivial example is a dict with bytes keys) but the existence of the buffer API makes it easy to do in most cases. Why are we moving away from this? If we do, we should probably remove that language from PEP 484 (and the code from mypy, but that's a separate thing).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26800>
_______________________________________

From report at bugs.python.org  Sat Apr 23 13:27:32 2016
From: report at bugs.python.org (Francisco Couzo)
Date: Sat, 23 Apr 2016 17:27:32 +0000
Subject: [issue26830] Refactor Tools/scripts/google.py
In-Reply-To: <1461346654.96.0.919095766119.issue26830@psf.upfronthosting.co.za>
Message-ID: <1461432452.33.0.678358093026.issue26830@psf.upfronthosting.co.za>


Francisco Couzo added the comment:

I was also going to refactor the other demo scripts, but first I wanted to make sure there was at least some kind of interest in it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26830>
_______________________________________

From report at bugs.python.org  Sat Apr 23 14:15:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 23 Apr 2016 18:15:33 +0000
Subject: [issue26800] Don't accept bytearray as filenames part 2
In-Reply-To: <1461015295.39.0.246147143774.issue26800@psf.upfronthosting.co.za>
Message-ID: <1461435333.18.0.124129358247.issue26800@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Side comment about "bytes-like" and "byte string". As for language from PEP 484, I think it is too permissive. bytes and bytearray have are "bytes strings" because they are not only sequences of bytes, but have a lot of str-like methods: lower(), split(), startswith(), strip(), etc. Many Python functions that work with "bytes strings" expect the support some of these methods. memoryview() has no these methods, it is even not always the sequence of bytes. Other objects that support the buffer protocol can even be not sequences. This is a problem when we want to support all objects with the buffer protocol in functions written in Python. We need to wrap them in memoryview and cast to the 'B' format. But in many cases the term "byte-like" means that bytes and bytearray are accepted. There are different levels of "byte-likelity", and unfortunately there is no good terminology.

As for moving away from accepting non-bytes paths, I think the arguments are similar to arguments about why Path is not str subclass. Or why we don't convert any path argument to string by calling str(). Because it can hide errors and cause unexpected behavior instead of exception. For example on Windows array('u', '???') represents not Unicode name '???', but bytes name b'abcdef'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26800>
_______________________________________

From report at bugs.python.org  Sat Apr 23 14:23:43 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 23 Apr 2016 18:23:43 +0000
Subject: [issue23516] pip: urllib3 does not encode userinfo section of URL
 with authentication credentials
In-Reply-To: <1424815080.16.0.743473330916.issue23516@psf.upfronthosting.co.za>
Message-ID: <1461435823.72.0.914671554806.issue23516@psf.upfronthosting.co.za>


Berker Peksag added the comment:

This was reported on urllib3 issue tracker: https://github.com/shazow/urllib3/issues/814

----------
nosy: +berker.peksag
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23516>
_______________________________________

From report at bugs.python.org  Sat Apr 23 15:24:24 2016
From: report at bugs.python.org (Marcos Dione)
Date: Sat, 23 Apr 2016 19:24:24 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module and use
 it to improve shutils.copy()
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1461439464.32.0.546175420918.issue26826@psf.upfronthosting.co.za>


Marcos Dione added the comment:

Debian Sid, arch Linux and Fedora FC24 (alpha) already have linux-4.5, others would certainly follow soon. Meanwhile, I could start developing the patch and we could review it when you think it's appropriate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Sat Apr 23 15:27:42 2016
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 23 Apr 2016 19:27:42 +0000
Subject: [issue26834] Add truncated SHA512/224 and SHA512/256
Message-ID: <1461439661.19.0.970129415182.issue26834@psf.upfronthosting.co.za>


New submission from Christian Heimes:

SHA512/224 and SHA512/256 are truncated versions of SHA512. Just like SHA384 they use the same algorithm but different initial values and a smaller digest. I took the start vectors and test values from libtomcrypt.

Like in my blake2 branch I have add tp_new to the types and removed the old factory methods. Now it is possible to instantiate the types.

The code is also in my github fork https://github.com/tiran/cpython/tree/feature/sha512truncated

----------
components: Extension Modules
files: cpython-cheimes-0001-Add-truncate-SHA512-224-and-SHA512-256-hash-algorith.patch
keywords: patch
messages: 264068
nosy: christian.heimes, gregory.p.smith
priority: normal
severity: normal
stage: patch review
status: open
title: Add truncated SHA512/224 and SHA512/256
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42578/cpython-cheimes-0001-Add-truncate-SHA512-224-and-SHA512-256-hash-algorith.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26834>
_______________________________________

From report at bugs.python.org  Sat Apr 23 16:00:26 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 23 Apr 2016 20:00:26 +0000
Subject: [issue1283110] Give __len__() advice for "don't know"
Message-ID: <1461441625.99.0.185874526233.issue1283110@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/issue1283110>
_______________________________________

From report at bugs.python.org  Sat Apr 23 16:47:04 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 23 Apr 2016 20:47:04 +0000
Subject: [issue14713] PEP 414 installation hook fails with an AssertionError
In-Reply-To: <1336059741.48.0.751323304263.issue14713@psf.upfronthosting.co.za>
Message-ID: <1461444424.67.0.350799164176.issue14713@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14713>
_______________________________________

From report at bugs.python.org  Sat Apr 23 16:54:44 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 23 Apr 2016 20:54:44 +0000
Subject: [issue11645] "Expand 10 after" on rietveld shows a duplicate line
In-Reply-To: <1300839541.37.0.373352205502.issue11645@psf.upfronthosting.co.za>
Message-ID: <1461444884.09.0.450848315221.issue11645@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I can't reproduce this with Chrome 49.0.2623.112 (64-bit). I guess this has already been fixed since 2011 (our fork's commit logs can be found at https://hg.python.org/tracker/rietveld/shortlog/bugs.python.org)

----------
nosy: +berker.peksag
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11645>
_______________________________________

From report at bugs.python.org  Sat Apr 23 16:59:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 23 Apr 2016 20:59:39 +0000
Subject: [issue26039] More flexibility in zipfile write interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1461445179.22.0.223233119015.issue26039@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

test_write_after_read was added in issue14099. It doesn't test intended behavior, it tests existing behavior just in case to not change it unintentionally. It is desirable to preserve it, but if there is no simple way, may be we can change it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Sat Apr 23 18:35:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Apr 2016 22:35:24 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module and use
 it to improve shutils.copy()
In-Reply-To: <1461439464.32.0.546175420918.issue26826@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwb22g5qHegumFwtZbYb=GMm0BQ3y+S+79ZbP4bDBnCeTQ@mail.gmail.com>


STINNER Victor added the comment:

Kerbel support ok, but what about the libc support? Do you know if it is
planned? Or do you want to use the syscall() low-level API. If we take the
syscall() path, I suggest to make the function private in the os module.
Wait until the API is standardized in the libc. Sometimes the libc changes
minor things, ir's not always a thin wrapper to the syscall.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Sat Apr 23 18:50:11 2016
From: report at bugs.python.org (Marcos Dione)
Date: Sat, 23 Apr 2016 22:50:11 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module and use
 it to improve shutils.copy()
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1461451811.81.0.544090330933.issue26826@psf.upfronthosting.co.za>


Marcos Dione added the comment:

Already there:

http://man7.org/linux/man-pages/man2/copy_file_range.2.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Sat Apr 23 18:51:22 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Apr 2016 22:51:22 +0000
Subject: [issue20112] The documentation for http.server error_message_format
 is inadequate.
In-Reply-To: <1388701952.2.0.132957137739.issue20112@psf.upfronthosting.co.za>
Message-ID: <20160423225118.119498.33367.6CDE8E43@psf.io>


Roundup Robot added the comment:

New changeset a912ca4f507b by Berker Peksag in branch '3.5':
Issue #20112: Improve BaseHTTPRequestHandler.error_message_format documentation
https://hg.python.org/cpython/rev/a912ca4f507b

New changeset baed33df1aed by Berker Peksag in branch 'default':
Issue #20112: Improve BaseHTTPRequestHandler.error_message_format documentation
https://hg.python.org/cpython/rev/baed33df1aed

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20112>
_______________________________________

From report at bugs.python.org  Sat Apr 23 18:52:23 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 23 Apr 2016 22:52:23 +0000
Subject: [issue20112] The documentation for http.server error_message_format
 is inadequate.
In-Reply-To: <1388701952.2.0.132957137739.issue20112@psf.upfronthosting.co.za>
Message-ID: <1461451943.65.0.154672113328.issue20112@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Anastasia.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20112>
_______________________________________

From report at bugs.python.org  Sat Apr 23 18:54:55 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Apr 2016 22:54:55 +0000
Subject: [issue26089] Duplicated keyword in distutils metadata
In-Reply-To: <1452591890.07.0.0660802423296.issue26089@psf.upfronthosting.co.za>
Message-ID: <20160423225451.112732.83032.2E95579D@psf.io>


Roundup Robot added the comment:

New changeset 21e522177ca0 by Berker Peksag in branch 'default':
Issue #26089: Remove duplicate field 'license' from DistributionMetadata
https://hg.python.org/cpython/rev/21e522177ca0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26089>
_______________________________________

From report at bugs.python.org  Sat Apr 23 18:59:29 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 23 Apr 2016 22:59:29 +0000
Subject: [issue26089] Duplicated keyword in distutils metadata
In-Reply-To: <1452591890.07.0.0660802423296.issue26089@psf.upfronthosting.co.za>
Message-ID: <1461452369.88.0.973512687319.issue26089@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I just committed Ezio's patch. Thanks!

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26089>
_______________________________________

From report at bugs.python.org  Sat Apr 23 19:59:31 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Apr 2016 23:59:31 +0000
Subject: [issue21382] Signal module doesnt raises ValueError Exception
In-Reply-To: <1398759436.39.0.420418396293.issue21382@psf.upfronthosting.co.za>
Message-ID: <20160423235926.31833.28776.27076379@psf.io>


Roundup Robot added the comment:

New changeset 1fcf68e6f4c7 by Berker Peksag in branch '3.5':
Issue #21382: Clarify signal.signal() documentation on Windows
https://hg.python.org/cpython/rev/1fcf68e6f4c7

New changeset 3e27b21e3a7d by Berker Peksag in branch 'default':
Issue #21382: Clarify signal.signal() documentation on Windows
https://hg.python.org/cpython/rev/3e27b21e3a7d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21382>
_______________________________________

From report at bugs.python.org  Sat Apr 23 19:59:58 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 23 Apr 2016 23:59:58 +0000
Subject: [issue21382] Signal module doesnt raises ValueError Exception
In-Reply-To: <1398759436.39.0.420418396293.issue21382@psf.upfronthosting.co.za>
Message-ID: <1461455998.68.0.845625813255.issue21382@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21382>
_______________________________________

From report at bugs.python.org  Sat Apr 23 20:06:49 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 24 Apr 2016 00:06:49 +0000
Subject: [issue18353] PyUnicode_WRITE_CHAR macro definition missing
In-Reply-To: <1372873387.67.0.379053408423.issue18353@psf.upfronthosting.co.za>
Message-ID: <20160424000646.21466.95581.314E4708@psf.io>


Roundup Robot added the comment:

New changeset 29e555e5956b by Berker Peksag in branch '3.5':
Issue #18353: Remove PyUnicode_WRITE_CHAR macro link from c-api/unicode.rst
https://hg.python.org/cpython/rev/29e555e5956b

New changeset 8c53fdc011a3 by Berker Peksag in branch 'default':
Issue #18353: Remove PyUnicode_WRITE_CHAR macro link from c-api/unicode.rst
https://hg.python.org/cpython/rev/8c53fdc011a3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18353>
_______________________________________

From report at bugs.python.org  Sat Apr 23 20:07:37 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 24 Apr 2016 00:07:37 +0000
Subject: [issue18353] PyUnicode_WRITE_CHAR macro definition missing
In-Reply-To: <1372873387.67.0.379053408423.issue18353@psf.upfronthosting.co.za>
Message-ID: <1461456457.35.0.929531898984.issue18353@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report Wolf and thanks for the patch Corey.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type: compile error -> behavior
versions: +Python 3.5, Python 3.6 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18353>
_______________________________________

From report at bugs.python.org  Sat Apr 23 20:13:50 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 24 Apr 2016 00:13:50 +0000
Subject: [issue18572] Remove redundant note about surrogates in string escape
 doc
In-Reply-To: <1374941533.84.0.352957238503.issue18572@psf.upfronthosting.co.za>
Message-ID: <20160424001346.90477.26763.86932010@psf.io>


Roundup Robot added the comment:

New changeset 79e7808c3941 by Berker Peksag in branch '3.5':
Issue #18572: Remove redundant note about surrogates in string escape doc
https://hg.python.org/cpython/rev/79e7808c3941

New changeset ee815d3535f5 by Berker Peksag in branch 'default':
Issue #18572: Remove redundant note about surrogates in string escape doc
https://hg.python.org/cpython/rev/ee815d3535f5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18572>
_______________________________________

From report at bugs.python.org  Sat Apr 23 20:14:43 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 24 Apr 2016 00:14:43 +0000
Subject: [issue18572] Remove redundant note about surrogates in string escape
 doc
In-Reply-To: <1374941533.84.0.352957238503.issue18572@psf.upfronthosting.co.za>
Message-ID: <1461456883.52.0.0192925852969.issue18572@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I removed the sentence in 3.5 and default branches.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18572>
_______________________________________

From report at bugs.python.org  Sat Apr 23 20:17:31 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 24 Apr 2016 00:17:31 +0000
Subject: [issue20572] subprocess.Popen.wait() undocumented "endtime" parameter
In-Reply-To: <1391941400.18.0.703922206544.issue20572@psf.upfronthosting.co.za>
Message-ID: <1461457051.05.0.0264577472692.issue20572@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Do we still want to remove the endtime parameter?

----------
nosy: +berker.peksag
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20572>
_______________________________________

From report at bugs.python.org  Sat Apr 23 20:20:57 2016
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 24 Apr 2016 00:20:57 +0000
Subject: [issue25599] asyncio.iscoroutinefunction returns unexpected results
 when presented with unittest.mock.Mock
In-Reply-To: <1447176382.09.0.498269327302.issue25599@psf.upfronthosting.co.za>
Message-ID: <1461457257.89.0.000999446266463.issue25599@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25599>
_______________________________________

From report at bugs.python.org  Sat Apr 23 20:21:24 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 24 Apr 2016 00:21:24 +0000
Subject: [issue19731] Fix copyright footer
In-Reply-To: <1385173768.12.0.946242825352.issue19731@psf.upfronthosting.co.za>
Message-ID: <20160424002115.391.68696.7D7B76D3@psf.io>


Roundup Robot added the comment:

New changeset 7cb3364952d5 by Berker Peksag in branch '3.5':
Issue #19731: Update copyright year in docs.p.o footer
https://hg.python.org/cpython/rev/7cb3364952d5

New changeset fa0a941728a8 by Berker Peksag in branch 'default':
Issue #19731: Update copyright year in docs.p.o footer
https://hg.python.org/cpython/rev/fa0a941728a8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19731>
_______________________________________

From report at bugs.python.org  Sat Apr 23 20:25:11 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 24 Apr 2016 00:25:11 +0000
Subject: [issue19731] Fix copyright footer
In-Reply-To: <1385173768.12.0.946242825352.issue19731@psf.upfronthosting.co.za>
Message-ID: <1461457511.88.0.574869873827.issue19731@psf.upfronthosting.co.za>


Berker Peksag added the comment:

2001 is also appears in python.org footer.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior
versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19731>
_______________________________________

From report at bugs.python.org  Sat Apr 23 20:32:38 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 24 Apr 2016 00:32:38 +0000
Subject: [issue26041] Update deprecation messages of platform.dist() and
 platform.linux_distribution()
In-Reply-To: <1452187100.03.0.384540652472.issue26041@psf.upfronthosting.co.za>
Message-ID: <20160424003233.30496.14309.777CCEFD@psf.io>


Roundup Robot added the comment:

New changeset 8f7b317124d6 by Berker Peksag in branch '3.5':
Issue #26041: Remove "will be removed in Python 3.7" from description messages
https://hg.python.org/cpython/rev/8f7b317124d6

New changeset 5d9f961edc30 by Berker Peksag in branch 'default':
Issue #26041: Remove "will be removed in Python 3.7" from description messages
https://hg.python.org/cpython/rev/5d9f961edc30

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26041>
_______________________________________

From report at bugs.python.org  Sat Apr 23 20:33:04 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 24 Apr 2016 00:33:04 +0000
Subject: [issue26041] Update deprecation messages of platform.dist() and
 platform.linux_distribution()
In-Reply-To: <1452187100.03.0.384540652472.issue26041@psf.upfronthosting.co.za>
Message-ID: <1461457984.09.0.323851960409.issue26041@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26041>
_______________________________________

From report at bugs.python.org  Sat Apr 23 20:45:53 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 24 Apr 2016 00:45:53 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module and use
 it to improve shutils.copy()
In-Reply-To: <1461451811.81.0.544090330933.issue26826@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwb-EjQpSY2iGDokKLLTQypH9TdAna2QSGuGv9nFHiP63g@mail.gmail.com>


STINNER Victor added the comment:

That's the manual page of the Linux kernel, not the glibc. It doesn't
mean that the glibc implemented it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Sat Apr 23 21:34:40 2016
From: report at bugs.python.org (Jelle Zijlstra)
Date: Sun, 24 Apr 2016 01:34:40 +0000
Subject: [issue26549] co_stacksize is calculated from unoptimized code
In-Reply-To: <1457822745.22.0.972836245522.issue26549@psf.upfronthosting.co.za>
Message-ID: <1461461680.84.0.628482973836.issue26549@psf.upfronthosting.co.za>


Jelle Zijlstra added the comment:

This also affects co_consts, which includes constants that are no longer used by the optimized code:

In [8]: def f():
    return (1, 2, 3, 4, 5)
   ...: 

In [9]: f.func_code.co_consts
Out[9]: (None, 1, 2, 3, 4, 5, (1, 2, 3, 4, 5))

In [12]: dis.dis(f)
  2           0 LOAD_CONST               6 ((1, 2, 3, 4, 5))
              3 RETURN_VALUE

----------
nosy: +Jelle Zijlstra

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26549>
_______________________________________

From report at bugs.python.org  Sat Apr 23 23:41:09 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 24 Apr 2016 03:41:09 +0000
Subject: [issue22359] Remove incorrect uses of recursive make
In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za>
Message-ID: <1461469269.15.0.348494634781.issue22359@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for your help with this Xavier.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22359>
_______________________________________

From report at bugs.python.org  Sun Apr 24 00:16:35 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 24 Apr 2016 04:16:35 +0000
Subject: [issue23806] documentation for no_proxy is missing from the python3
 urllib documentation
In-Reply-To: <1427640986.55.0.996928918568.issue23806@psf.upfronthosting.co.za>
Message-ID: <20160424041632.26362.43985.0986F1D1@psf.io>


Roundup Robot added the comment:

New changeset 5ad93528c39c by Martin Panter in branch '3.5':
Issue #23806: Update susp-ignored.csv
https://hg.python.org/cpython/rev/5ad93528c39c

New changeset cb38785acc8d by Martin Panter in branch 'default':
Issue #23806: Merge susp-ignored.csv from 3.5
https://hg.python.org/cpython/rev/cb38785acc8d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23806>
_______________________________________

From report at bugs.python.org  Sun Apr 24 00:31:30 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 24 Apr 2016 04:31:30 +0000
Subject: [issue23277] Cleanup unused and duplicate imports in tests
In-Reply-To: <1421716663.28.0.404138725628.issue23277@psf.upfronthosting.co.za>
Message-ID: <20160424043127.111048.68699.7E2188A6@psf.io>


Roundup Robot added the comment:

New changeset 6958bbf7f0ec by Berker Peksag in branch 'default':
Issue #23277: Remove unused sys and os imports
https://hg.python.org/cpython/rev/6958bbf7f0ec

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23277>
_______________________________________

From report at bugs.python.org  Sun Apr 24 00:36:38 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 24 Apr 2016 04:36:38 +0000
Subject: [issue23277] Cleanup unused and duplicate imports in tests
In-Reply-To: <1421716663.28.0.404138725628.issue23277@psf.upfronthosting.co.za>
Message-ID: <1461472598.89.0.361196157368.issue23277@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Jon.

I only removed sys and os since they were the most unused modules.

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 3.6 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23277>
_______________________________________

From report at bugs.python.org  Sun Apr 24 00:40:42 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 24 Apr 2016 04:40:42 +0000
Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError
In-Reply-To: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za>
Message-ID: <1461472842.48.0.0312958262946.issue26801@psf.upfronthosting.co.za>


Martin Panter added the comment:

Serhiy?s patch looks worthwhile to me, though I still think a comment would help. There are lots of different cases being handled by those few lines:

try:
   size = os.get_terminal_size(sys.__stdout__.fileno())
except (AttributeError, ValueError, OSError)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26801>
_______________________________________

From report at bugs.python.org  Sun Apr 24 00:55:45 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 24 Apr 2016 04:55:45 +0000
Subject: [issue24911] Context manager of socket.socket is not documented
In-Reply-To: <1440189246.69.0.0632097129757.issue24911@psf.upfronthosting.co.za>
Message-ID: <20160424045542.21466.22673.E8C9FA45@psf.io>


Roundup Robot added the comment:

New changeset d5f7980dd654 by Martin Panter in branch '3.5':
Issue #24911: All socket objects are context managers; update examples
https://hg.python.org/cpython/rev/d5f7980dd654

New changeset 711201953505 by Martin Panter in branch 'default':
Issue #24911: Merge socket context manager doc from 3.5
https://hg.python.org/cpython/rev/711201953505

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24911>
_______________________________________

From report at bugs.python.org  Sun Apr 24 01:09:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 24 Apr 2016 05:09:19 +0000
Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError
In-Reply-To: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za>
Message-ID: <1461474559.87.0.322340780158.issue26801@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you suggest concrete wording?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26801>
_______________________________________

From report at bugs.python.org  Sun Apr 24 02:22:13 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 24 Apr 2016 06:22:13 +0000
Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError
In-Reply-To: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za>
Message-ID: <1461478933.6.0.447080142935.issue26801@psf.upfronthosting.co.za>


Martin Panter added the comment:

How about:

try:
    size = os.get_terminal_size(sys.__stdout__.fileno())
except (AttributeError, ValueError, OSError):
    # stdout is None, closed, detached, or not a terminal, or
    # os.get_terminal_size() is unsupported
    size = os.terminal_size(fallback)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26801>
_______________________________________

From report at bugs.python.org  Sun Apr 24 02:23:24 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 24 Apr 2016 06:23:24 +0000
Subject: [issue24911] Context manager of socket.socket is not documented
In-Reply-To: <1440189246.69.0.0632097129757.issue24911@psf.upfronthosting.co.za>
Message-ID: <1461479004.92.0.311932922973.issue24911@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/issue24911>
_______________________________________

From report at bugs.python.org  Sun Apr 24 02:34:07 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 24 Apr 2016 06:34:07 +0000
Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError
In-Reply-To: <1461478933.6.0.447080142935.issue26801@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZ45b58CEQiy5oo7R4SOeOmfEwuj=3Bw76n12hixE3tRg@mail.gmail.com>


STINNER Victor added the comment:

Martin's comment is helpful and LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26801>
_______________________________________

From report at bugs.python.org  Sun Apr 24 02:37:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 24 Apr 2016 06:37:35 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461479855.7.0.319818750067.issue26814@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I have collected statistics about using CALL_FUNCTION* opcodes in compliled code during running CPython testsuite. According to it, 99.4% emitted opcodes is the CALL_FUNCTION opcode, and 89% of emitted CALL_FUNCTION opcodes have only positional arguments, and 98% of them have not more than 3 arguments.

That was about calls from Python code. All convenient C API functions (like PyObject_CallFunction and PyObject_CallFunctionObjArgs) used for direct calling in C code use only positional arguments.

Thus I think we need to optimize only cases of calling with small number (0-3) of positional arguments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Sun Apr 24 02:59:42 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 24 Apr 2016 06:59:42 +0000
Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError
In-Reply-To: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za>
Message-ID: <20160424065939.26171.71622.2B91CDB3@psf.io>


Roundup Robot added the comment:

New changeset df8652452d25 by Serhiy Storchaka in branch '3.5':
Issue #26801: shutil.get_terminal_size() now handles the case of stdout is
https://hg.python.org/cpython/rev/df8652452d25

New changeset d6e6dcef674f by Serhiy Storchaka in branch 'default':
Issue #26801: shutil.get_terminal_size() now handles the case of stdout is
https://hg.python.org/cpython/rev/d6e6dcef674f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26801>
_______________________________________

From report at bugs.python.org  Sun Apr 24 03:00:54 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 24 Apr 2016 07:00:54 +0000
Subject: [issue26801] Fix shutil.get_terminal_size() to catch AttributeError
In-Reply-To: <1461023037.12.0.975016313479.issue26801@psf.upfronthosting.co.za>
Message-ID: <1461481254.04.0.381146352128.issue26801@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Martin, your comment is helpful.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26801>
_______________________________________

From report at bugs.python.org  Sun Apr 24 03:15:35 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 24 Apr 2016 07:15:35 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461482135.77.0.174227934474.issue26814@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Thus I think we need to optimize only cases of calling with small number (0-3) of positional arguments.

My code is optimized to up to 10 positional arguments: with 0..10 arguments, the C stack is used to hold the array of PyObject*. For more arguments, an array is allocated in the heap memory.

+   /* 10 positional parameters or 5 (key, value) pairs for keyword parameters.
+      40 bytes on 32-bit or 80 bytes on 64-bit. */
+#  define _PyStack_SIZE 10

For keyword parameters, I don't know yet what is the best API (fatest API). Right now, I'm also using the same PyObject** array for positional and keyword arguments using "int nk", but maybe a dictionary is faster to combinary keyword arguments and to parse keyword arguments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Sun Apr 24 03:37:59 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 24 Apr 2016 07:37:59 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461483479.0.0.963624327333.issue26814@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think you can simplify the patch by dropping keyword arguments support from fastcall. Then you can decrease _PyStack_SIZE to 4 (larger size will serve only 1.7% of calls), and may be refactor a code since an array of 4 pointers consumes less C stack than an array of 10 pointers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Sun Apr 24 05:21:29 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 24 Apr 2016 09:21:29 +0000
Subject: [issue23277] Cleanup unused and duplicate imports in tests
In-Reply-To: <1421716663.28.0.404138725628.issue23277@psf.upfronthosting.co.za>
Message-ID: <1461489689.78.0.498753020515.issue23277@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Note that setUpModule is correctly imported in Lib/tkinter/test/test_tkinter/test_widgets.py.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23277>
_______________________________________

From report at bugs.python.org  Sun Apr 24 05:44:45 2016
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 24 Apr 2016 09:44:45 +0000
Subject: [issue26739] idle: Errno 10035 a non-blocking socket operation could
 not be completed immediately
In-Reply-To: <1460409859.89.0.789703447955.issue26739@psf.upfronthosting.co.za>
Message-ID: <1461491085.95.0.651101446731.issue26739@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

Hi there.
I don't think this is in relation to issue #9090.
That one had to do with the internal mechanisms of doing blocking IO with timeout.  this is done internally by using non-blocking sockets and select(), and the backport dealt with some edge cases on windows where select() could falsely indicate that data were ready.

>From what I can see in this error description, we are dealing with real non-blocking IO, i.e. an application is using select and non-blocking sockets.

It is possible that this windows edge case is now being elevated into the application code and whatever select() logic being used in rpc.py needs to be aware of it, or that for some reason this socket is supposed to be blocking, but isn't.

I'll have a quick look at idlelib and see if I can see anything.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26739>
_______________________________________

From report at bugs.python.org  Sun Apr 24 06:12:43 2016
From: report at bugs.python.org (Daryl Luna)
Date: Sun, 24 Apr 2016 10:12:43 +0000
Subject: [issue20572] subprocess.Popen.wait() undocumented "endtime" parameter
In-Reply-To: <1391941400.18.0.703922206544.issue20572@psf.upfronthosting.co.za>
Message-ID: <1461492763.02.0.246882039675.issue20572@psf.upfronthosting.co.za>


Changes by Daryl Luna <darylluna27 at gmail.com>:


----------
nosy: +Daryl Luna
status: pending -> open
Added file: http://bugs.python.org/file42579/downloadfile.htm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20572>
_______________________________________

From report at bugs.python.org  Sun Apr 24 06:30:23 2016
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 24 Apr 2016 10:30:23 +0000
Subject: [issue26739] idle: Errno 10035 a non-blocking socket operation could
 not be completed immediately
In-Reply-To: <1460409859.89.0.789703447955.issue26739@psf.upfronthosting.co.za>
Message-ID: <1461493823.75.0.389273719522.issue26739@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

Caveat emptor:  I know nothing of IDLE, and I even suspect it to be dead or dying code.  Non the less, it could be patched.

I found this in the code:
def putmessage(self, message):
        self.debug("putmessage:%d:" % message[0])
        try:
            s = pickle.dumps(message)
        except pickle.PicklingError:
            print >>sys.__stderr__, "Cannot pickle:", repr(message)
            raise
        s = struct.pack("<i", len(s)) + s
        while len(s) > 0:
            try:
                r, w, x = select.select([], [self.sock], [])
                n = self.sock.send(s[:BUFSIZE])
            except (AttributeError, TypeError):
                raise IOError, "socket no longer exists"
            except socket.error:
                raise
            else:
                s = s[n:]


If the socket were non-blocking, this would be the place to add a handler to catch socket.error with errno=errno.EWOULDBLOCK

However, I can't see that this socket is non-blocking.  Perhaps I have some blindness, but the select calls seem to be redundant to me, I can't see any sock.setblocking(False) or sock.settimeout(0.0) being done anywhere.


Having said that, the following change can be made (which is the prudent way to use select/send anyway)
while len(s) > 0:
            try:
                while True:
                r, w, x = select.select([], [self.sock], [])
                try:
                    n = self.sock.send(s[:BUFSIZE])
                    break
                except socket.error as e:
                    import errno # should be done at the top
                    if e.errno != errno.EWOULDBLOCK:
                        raise
            except (AttributeError, TypeError):
                raise IOError, "socket no longer exists"
            except socket.error:
                raise
            else:
                s = s[n:]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26739>
_______________________________________

From report at bugs.python.org  Sun Apr 24 06:54:52 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 24 Apr 2016 10:54:52 +0000
Subject: [issue23277] Cleanup unused and duplicate imports in tests
In-Reply-To: <1421716663.28.0.404138725628.issue23277@psf.upfronthosting.co.za>
Message-ID: <20160424105448.30111.89459.05DF15BC@psf.io>


Roundup Robot added the comment:

New changeset 9d7f2615f7b3 by Serhiy Storchaka in branch 'default':
Issue #23277: Remove more unused sys and os imports.
https://hg.python.org/cpython/rev/9d7f2615f7b3

New changeset abf3f0dcf2fd by Serhiy Storchaka in branch 'default':
Issue #23277: Remove unused support.run_unittest import.
https://hg.python.org/cpython/rev/abf3f0dcf2fd

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23277>
_______________________________________

From report at bugs.python.org  Sun Apr 24 07:45:54 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 24 Apr 2016 11:45:54 +0000
Subject: [issue23277] Cleanup unused and duplicate imports in tests
In-Reply-To: <1421716663.28.0.404138725628.issue23277@psf.upfronthosting.co.za>
Message-ID: <1461498354.04.0.630244910417.issue23277@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is the patch that contains the rest of changes, after resolving conflicts and fixing some errors. I have reviewed and tested these changes and they LGTM. I think it is worth to push them.

----------
resolution: fixed -> 
status: closed -> open
Added file: http://bugs.python.org/file42580/cleanup-unused-imports_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23277>
_______________________________________

From report at bugs.python.org  Sun Apr 24 09:53:19 2016
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Apr 2016 13:53:19 +0000
Subject: [issue26835] Add file-sealing ops to fcntl
Message-ID: <1461505999.3.0.387096384665.issue26835@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The file-sealing ops are useful for memfd_create(). The new syscall and ops are only available on Linux with a recent kernel.

http://man7.org/linux/man-pages/man2/fcntl.2.html
http://man7.org/linux/man-pages/man2/memfd_create.2.html

Code:

#include <linux/fcntl.h>

#ifndef F_ADD_SEALS

/*
 * Set/Get seals
 */
#define F_ADD_SEALS     (F_LINUX_SPECIFIC_BASE + 9)
#define F_GET_SEALS     (F_LINUX_SPECIFIC_BASE + 10)

/*
 * Types of seals
 */
#define F_SEAL_SEAL     0x0001  /* prevent further seals from being set */
#define F_SEAL_SHRINK   0x0002  /* prevent file from shrinking */
#define F_SEAL_GROW     0x0004  /* prevent file from growing */
#define F_SEAL_WRITE    0x0008  /* prevent writes */
/* (1U << 31) is reserved for signed error codes */

#endif /* F_ADD_SEALS */

----------
assignee: christian.heimes
components: Extension Modules
messages: 264108
nosy: christian.heimes
priority: normal
severity: normal
stage: needs patch
status: open
title: Add file-sealing ops to fcntl
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26835>
_______________________________________

From report at bugs.python.org  Sun Apr 24 09:56:03 2016
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Apr 2016 13:56:03 +0000
Subject: [issue26836] Add memfd_create to os module
Message-ID: <1461506163.13.0.0180353008827.issue26836@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Add memfd_create() and constants MFD_ALLOW_SEALING, MFD_CLOEXEC to the os module. A glibc wrapper for memfd_create() is not available yet but the interface has been standardized.

http://man7.org/linux/man-pages/man2/memfd_create.2.html
https://dvdhrm.wordpress.com/tag/memfd/

----------
assignee: christian.heimes
components: Extension Modules
messages: 264109
nosy: christian.heimes
priority: normal
severity: normal
stage: needs patch
status: open
title: Add memfd_create to os module
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26836>
_______________________________________

From report at bugs.python.org  Sun Apr 24 11:32:26 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 24 Apr 2016 15:32:26 +0000
Subject: [issue26837] assertSequenceEqual() raises BytesWarning when format
 message
Message-ID: <1461511946.3.0.425674817359.issue26837@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

assertSequenceEqual() raises BytesWarning when format failure report. See for example http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/10575/steps/test/logs/stdio :

======================================================================
ERROR: test_close_fds_0_1 (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_subprocess.py", line 1741, in test_close_fds_0_1
    self.check_close_std_fds([0, 1])
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_subprocess.py", line 1727, in check_close_std_fds
    self.assertEqual((out, err), (b'apple', b'orange'))
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/unittest/case.py", line 820, in assertEqual
    assertion_func(first, second, msg=msg)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/unittest/case.py", line 1029, in assertTupleEqual
    self.assertSequenceEqual(tuple1, tuple2, msg, seq_type=tuple)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/unittest/case.py", line 967, in assertSequenceEqual
    (i, item1, item2))
BytesWarning: str() on a bytes instance

======================================================================

Proposed patch fixes message formatting and adds tests for assertions that can emit BytesWarning.

----------
components: Library (Lib), Tests
files: unittest_assert_bytes_warning.patch
keywords: patch
messages: 264110
nosy: ezio.melotti, michael.foord, rbcollins, serhiy.storchaka
priority: normal
severity: normal
status: open
title: assertSequenceEqual() raises BytesWarning when format message
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42581/unittest_assert_bytes_warning.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26837>
_______________________________________

From report at bugs.python.org  Sun Apr 24 11:58:51 2016
From: report at bugs.python.org (Alan Jenkins)
Date: Sun, 24 Apr 2016 15:58:51 +0000
Subject: [issue26838] sax.xmlreader.InputSource.setCharacterStream() does not
 work?
Message-ID: <1461513531.9.0.223983001389.issue26838@psf.upfronthosting.co.za>


New submission from Alan Jenkins:

python3-3.4.3-5.fc23-x86_64

So far I spelunked here.  Starting from <https://github.com/kurtmckee/feedparser/issues/30>.  I experimented with using setCharacterStream() instead of setByteStream()

setCharacterStream() is shown in documentation but exercising it fails

>>> help(InputSource)
 |  setCharacterStream(self, charfile)
 |      Set the character stream for this input source. (The stream
 |      must be a Python 2.0 Unicode-wrapped file-like that performs
 |      conversion to Unicode strings.)
 |      
 |      If there is a character stream specified, the SAX parser will
 |      ignore any byte stream and will not attempt to open a URI
 |      connection to the system identifier.

Actually using an InputSource set up this way errors out as follows:

  File "/home/alan/.local/lib/python3.4/site-packages/feedparser-5.2.1-py3.4.egg/feedparser/api.py", line 236, in parse
  File "/usr/lib64/python3.4/site-packages/drv_libxml2.py", line 146, in parse
    source = saxutils.prepare_input_source(source)
  File "/usr/lib64/python3.4/xml/sax/saxutils.py", line 355, in prepare_input_source
    sysidfilename = os.path.join(basehead, sysid)
  File "/usr/lib64/python3.4/posixpath.py", line 79, in join
    if b.startswith(sep):
AttributeError: 'NoneType' object has no attribute 'startswith'

because the character stream is not actually used:

def prepare_input_source(source, base=""):
    """This function takes an InputSource and an optional base URL and
    returns a fully resolved InputSource object ready for reading."""

    if isinstance(source, str):
        source = xmlreader.InputSource(source)
    elif hasattr(source, "read"):
        f = source
        source = xmlreader.InputSource()
        source.setByteStream(f)
        if hasattr(f, "name") and isinstance(f.name, str):
            source.setSystemId(f.name)

    if source.getByteStream() is None:
        sysid = source.getSystemId()
        basehead = os.path.dirname(os.path.normpath(base))
        sysidfilename = os.path.join(basehead, sysid)

----------
components: XML
messages: 264111
nosy: sourcejedi
priority: normal
severity: normal
status: open
title: sax.xmlreader.InputSource.setCharacterStream() does not work?
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26838>
_______________________________________

From report at bugs.python.org  Sun Apr 24 12:02:41 2016
From: report at bugs.python.org (Alan Jenkins)
Date: Sun, 24 Apr 2016 16:02:41 +0000
Subject: [issue26838] sax.xmlreader.InputSource.setCharacterStream() does not
 work?
In-Reply-To: <1461513531.9.0.223983001389.issue26838@psf.upfronthosting.co.za>
Message-ID: <1461513761.24.0.158777291728.issue26838@psf.upfronthosting.co.za>


Alan Jenkins added the comment:

Looks like this is documented elsewhere and fixed in 3.5.

https://fossies.org/diffs/Python/3.4.3_vs_3.5.0/Doc/library/xml.sax.reader.rst-diff.html

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26838>
_______________________________________

From report at bugs.python.org  Sun Apr 24 12:05:35 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 24 Apr 2016 16:05:35 +0000
Subject: [issue26800] Don't accept bytearray as filenames part 2
In-Reply-To: <1461015295.39.0.246147143774.issue26800@psf.upfronthosting.co.za>
Message-ID: <1461513935.28.0.952913246784.issue26800@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

OK, I actually agree with you on memoryview and and other types that support the buffer view. I will update PEP 484 to exclude memoryview. But I think bytearray has a special role and purose, and as much as possible it needs to be accepted in places that support bytes. So IMO as long as the os module supports bytes at all, I see no reason not to support bytearray. (It even has the extra trailing \0 needed to pass it to a typical C function.)

So as long as we support bytes (and on Linux, and probably some other Unixoid systems, bytes are the *correct* type for paths) we should also support bytearray.

The issue that Path doesn't support bytes is separate. I think it's the right choice. But that doesn't mean e.g. os.listdir() shouldn't support bytes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26800>
_______________________________________

From report at bugs.python.org  Sun Apr 24 12:40:16 2016
From: report at bugs.python.org (Hans-Peter Jansen)
Date: Sun, 24 Apr 2016 16:40:16 +0000
Subject: [issue26804] Prioritize lowercase proxy variables in urllib.request
In-Reply-To: <1461053909.86.0.0123928931795.issue26804@psf.upfronthosting.co.za>
Message-ID: <1461516016.3.0.0138247725048.issue26804@psf.upfronthosting.co.za>


Hans-Peter Jansen added the comment:

* blatant error fixed
* one test case added

----------
Added file: http://bugs.python.org/file42582/python-urllib-prefer-lowercase-proxies-v6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26804>
_______________________________________

From report at bugs.python.org  Sun Apr 24 12:43:31 2016
From: report at bugs.python.org (Hans-Peter Jansen)
Date: Sun, 24 Apr 2016 16:43:31 +0000
Subject: [issue26804] Prioritize lowercase proxy variables in urllib.request
In-Reply-To: <1461053909.86.0.0123928931795.issue26804@psf.upfronthosting.co.za>
Message-ID: <1461516211.58.0.515334951892.issue26804@psf.upfronthosting.co.za>


Hans-Peter Jansen added the comment:

> In Python 2, it looks like the proxy_bypass_etc() functions are defined
> in urllib and imported into urllib2, so it makes sense to include the
> tests in test_urllib rather than test_urllib2.

The tests are in test_urllib. test_urllib2 is testing proxy behaviour on a higher level, so I think, they're in the correct module, aren't they?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26804>
_______________________________________

From report at bugs.python.org  Sun Apr 24 13:36:03 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 24 Apr 2016 17:36:03 +0000
Subject: [issue23277] Cleanup unused and duplicate imports in tests
In-Reply-To: <1421716663.28.0.404138725628.issue23277@psf.upfronthosting.co.za>
Message-ID: <1461519363.69.0.5948544484.issue23277@psf.upfronthosting.co.za>


Berker Peksag added the comment:

LGTM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23277>
_______________________________________

From report at bugs.python.org  Sun Apr 24 14:22:01 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 24 Apr 2016 18:22:01 +0000
Subject: [issue26739] idle: Errno 10035 a non-blocking socket operation could
 not be completed immediately
In-Reply-To: <1460409859.89.0.789703447955.issue26739@psf.upfronthosting.co.za>
Message-ID: <1461522121.35.0.107444082915.issue26739@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Kristj?n, thank you for the response.  The socket communication part of IDLE is pretty much a black box to me.  Just to clarify, you are saying that select polling is only needed for non-blocking sockets; sockets are blocking by default; and you see no override of the default.  Me neither.  It would be nice to know.  Idlelib.PyShell has the following lines: 
<445>        self.rpcclt.listening_sock.settimeout(10)
<561>            response = clt.pollresponse(self.active_seq, wait=0.05)
The wait is ultimately passed to rpc.py, line 353:
            r, w, x = select.select([self.sock.fileno()], [], [], wait)

(IDLE is very much in use, and I hope to modernize the 3.x version, and perhaps replace the sockets with non-blocking use of pipes.)

Michael: I cannot change 2.7.5 and I am not inclined to change 2.7.12+ until I know there is a problem with the current 2.7 release.  Numerous people are using IDLE with 2.7.11 (and 3.x) on Windows without problems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26739>
_______________________________________

From report at bugs.python.org  Sun Apr 24 14:22:24 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 24 Apr 2016 18:22:24 +0000
Subject: [issue26800] Don't accept bytearray as filenames part 2
In-Reply-To: <1461015295.39.0.246147143774.issue26800@psf.upfronthosting.co.za>
Message-ID: <1461522144.94.0.321342089829.issue26800@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The os.path module and os.fsdecode() don't support bytearray paths. Should we add bytearray support? This will complicate and slowdown os.path functions which often are used multiple times in tight loops.

Correspondingly, many Python implemented functions in the os module, such as makedirs() or walk(), doesn't support bytearray paths.

In 3.2 almost all functions used PyUnicode_FSConverter() and supported only str and bytes paths. Few functions accidentally supported other types (on Windows only!): chdir(), rmdir() and unlink() supported read-only buffers (i.e. bytearray was not supported), and rename() and symplink() supported any buffers, including bytearray. Now all these functions emit a warning since non-string paths are deprecated on Windows. It looks to me that the support of non-bytes paths was added by accident.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26800>
_______________________________________

From report at bugs.python.org  Sun Apr 24 14:41:28 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 24 Apr 2016 18:41:28 +0000
Subject: [issue23277] Cleanup unused and duplicate imports in tests
In-Reply-To: <1421716663.28.0.404138725628.issue23277@psf.upfronthosting.co.za>
Message-ID: <20160424184125.4122.85704.08E5E028@psf.io>


Roundup Robot added the comment:

New changeset fa44d1bc9b68 by Serhiy Storchaka in branch 'default':
Issue #23277: Remove unused imports in tests.
https://hg.python.org/cpython/rev/fa44d1bc9b68

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23277>
_______________________________________

From report at bugs.python.org  Sun Apr 24 14:43:56 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 24 Apr 2016 18:43:56 +0000
Subject: [issue23277] Cleanup unused and duplicate imports in tests
In-Reply-To: <1421716663.28.0.404138725628.issue23277@psf.upfronthosting.co.za>
Message-ID: <1461523436.11.0.703327863126.issue23277@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks Berker.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23277>
_______________________________________

From report at bugs.python.org  Sun Apr 24 15:04:14 2016
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 24 Apr 2016 19:04:14 +0000
Subject: [issue26839] python always calls getrandom() at start,
 causing long hang after boot
Message-ID: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za>


New submission from Matthias Klose:

[forwarded from https://bugs.debian.org/822431]

This regression / change of behaviour was seen between 20160330 and 20160417 on the 3.5 branch. The only check-in which could affect this is the fix for issue #26735.

3.5.1-11 = 20160330
3.5.1-12 = 20160417

Martin writes:
"""
I just debugged the adt-virt-qemu failure with python 3.5.1-11 and
tracked it down to python3.5 hanging for a long time when it gets
called before the kernel initializes its RNG (which can take a minute
in VMs which have low entropy sources).

With 3.5.1-10:

  $ strace -e getrandom python3 -c 'True'
  +++ exited with 0 +++

With -11:
  $ strace -e getrandom python3 -c 'True'
  getrandom("\300\0209\26&v\232\264\325\217\322\303:]\30\212Q\314\244\257t%\206\"", 24, 0) = 24
  +++ exited with 0 +++

When you do this with -11 right after booting a VM, the getrandom()
can block for a long time, until the kernel initializes its random
pool:

   11:21:36.118034 getrandom("/V#\200^O*HD+D_\32\345\223M\205a\336/\36x\335\246", 24, 0) = 24
   11:21:57.939999 ioctl(0, TCGETS, 0x7ffde1d152a0) = -1 ENOTTY (Inappropriate ioctl for device)

   [    1.549882] [TTM] Initializing DMA pool allocator
   [   39.586483] random: nonblocking pool is initialized

(Note the time stamps in the strace in the first paragraph)

This is really unfriendly -- it essentially means that you stop being
able to use python3 early in the boot process or even early after
booting. It would be better to initialize that random stuff lazily,
until/if things actually need it.

In the diff between -10 and -11 I do seem some getrandom() fixes to
supply the correct buffer size (but that should be irrelevant as in
-10 getrandom() wasn't called in the first place), and a new call
which should apply to Solaris only (#ifdef sun), so it's not entirely
clear where that comes from or how to work around it.

It's very likely that this is the same cause as for #821877, but the
description of that is both completely different and also very vague,
so I file this separately for now.
"""

----------
components: Interpreter Core
messages: 264121
nosy: doko, haypo
priority: normal
severity: normal
status: open
title: python always calls getrandom() at start, causing long hang after boot
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

From report at bugs.python.org  Sun Apr 24 15:06:20 2016
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 24 Apr 2016 19:06:20 +0000
Subject: [issue26839] python always calls getrandom() at start,
 causing long hang after boot
In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za>
Message-ID: <1461524780.5.0.349856347555.issue26839@psf.upfronthosting.co.za>


Matthias Klose added the comment:

other issues fixed between these dates:

    - Issue #26659: Make the builtin slice type support cycle collection.
    - Issue #26718: super.__init__ no longer leaks memory if called multiple
      times.  NOTE: A direct call of super.__init__ is not endorsed!
    - Issue #25339: PYTHONIOENCODING now has priority over locale in setting
      the error handler for stdin and stdout.
    - Issue #26717: Stop encoding Latin-1-ized WSGI paths with UTF-8.
    - Issue #26735: Fix :func:`os.urandom` on Solaris 11.3 and newer when
      reading more than 1,024 bytes: call ``getrandom()`` multiple times with
      a limit of 1024 bytes per call.
    - Issue #16329: Add .webm to mimetypes.types_map.
    - Issue #13952: Add .csv to mimetypes.types_map.
    - Issue #26709: Fixed Y2038 problem in loading binary PLists.
    - Issue #23735: Handle terminal resizing with Readline 6.3+ by installing
      our own SIGWINCH handler.
    - Issue #26586: In http.server, respond with "413 Request header fields too
      large" if there are too many header fields to parse, rather than killing
      the connection and raising an unhandled exception.
    - Issue #22854: Change BufferedReader.writable() and
      BufferedWriter.readable() to always return False.
    - Issue #6953: Rework the Readline module documentation to group related
      functions together, and add more details such as what underlying Readline
      functions and variables are accessed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

From report at bugs.python.org  Sun Apr 24 15:20:08 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 24 Apr 2016 19:20:08 +0000
Subject: [issue26840] Hidden test in test_heapq
Message-ID: <1461525608.59.0.682456524569.issue26840@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There are two methods test_get_only in TestErrorHandling in test_heapq. The latter hides the former.

There is only one test_get_only in 2.7.

----------
assignee: rhettinger
components: Tests
messages: 264123
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Hidden test in test_heapq
type: behavior
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26840>
_______________________________________

From report at bugs.python.org  Sun Apr 24 15:30:43 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 24 Apr 2016 19:30:43 +0000
Subject: [issue26800] Don't accept bytearray as filenames part 2
In-Reply-To: <1461015295.39.0.246147143774.issue26800@psf.upfronthosting.co.za>
Message-ID: <1461526243.35.0.305938533284.issue26800@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm really sceptical that anyone really use bytearray for filenames in Python. I'm quite sure that most functions fail with bytearray. Do you have an example of application using bytearray? What's the point of using bytearray? To limit memory copy and optimize the memory usage?

The two most common functions for filenames are os.path.join() and open(). I just tried:

>>> os.path.join(bytearray(b"a"), b"b")
Traceback (most recent call last):
  ...
TypeError: startswith first arg must be bytes or a tuple of bytes, not str

>>> open(bytearray(b"/etc/issue"))
Traceback (most recent call last):
  ...
TypeError: invalid file: bytearray(b'/etc/issue')

Hum, so bytearray are not accepted for open() nor os.path.join(), right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26800>
_______________________________________

From report at bugs.python.org  Sun Apr 24 15:35:29 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 24 Apr 2016 19:35:29 +0000
Subject: [issue26822] itemgetter/attrgetter/methodcaller objects ignore
 keyword arguments
In-Reply-To: <1461266621.67.0.0664681491354.issue26822@psf.upfronthosting.co.za>
Message-ID: <1461526529.41.0.944451025342.issue26822@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

In general there should be an early out test for keywords==NULL before calling the comparatively high overhead function _PyArg_NoKeywords.  

That function adds overhead everywhere it is used and provides zero benefit to correct programs in order to provide earlier detection of a very rare class of errors.

Some care needs to be taken before slapping _PyArg_NoKeywords onto every function in the core that doesn't use keyword arguments.

----------
nosy: +rhettinger
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26822>
_______________________________________

From report at bugs.python.org  Sun Apr 24 15:37:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 24 Apr 2016 19:37:03 +0000
Subject: [issue26839] python always calls getrandom() at start,
 causing long hang after boot
In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za>
Message-ID: <1461526623.68.0.323010815969.issue26839@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Python 3 uses os.urandom() at startup to randomize the hash function. os.urandom() now uses the new Linux getrandom() function which blocks until the Linux kernel is feeded with enough entropy. It's a deliberate choice.

The workaround is simple: set the PYTHONHASHSEED environment variable to use a fixed seed. For example, PYTHONHASHSEED=0 disables hash randomization.

If you use virtualization and Linux is not feeded with enough entropy, you have security issues.

> I just debugged the adt-virt-qemu failure (...)

If you use qemu, you can use virt-rng to provide good entropy to the VM from the host kernel.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

From report at bugs.python.org  Sun Apr 24 16:24:42 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 24 Apr 2016 20:24:42 +0000
Subject: [issue26841] Hidden test in ctypes tests
Message-ID: <1461529482.09.0.936239527723.issue26841@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There are two methods named "test_errors" in FunctionTestCase in Lib/ctypes/test/test_functions.py. The latter hides the former.

----------
components: Tests
messages: 264127
nosy: amaury.forgeotdarc, belopolsky, meador.inge, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Hidden test in ctypes tests
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26841>
_______________________________________

From report at bugs.python.org  Sun Apr 24 16:26:42 2016
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Sun, 24 Apr 2016 20:26:42 +0000
Subject: [issue26698] Tk DPI awareness
In-Reply-To: <1459911228.34.0.00983454800259.issue26698@psf.upfronthosting.co.za>
Message-ID: <1461529602.09.0.581415021535.issue26698@psf.upfronthosting.co.za>


Westley Mart?nez added the comment:

IDLE 3.5.1 on Windows 10

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26698>
_______________________________________

From report at bugs.python.org  Sun Apr 24 16:31:24 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 24 Apr 2016 20:31:24 +0000
Subject: [issue26840] Hidden test in test_heapq
In-Reply-To: <1461525608.59.0.682456524569.issue26840@psf.upfronthosting.co.za>
Message-ID: <1461529884.39.0.0256973798561.issue26840@psf.upfronthosting.co.za>


Berker Peksag added the comment:

This is a duplicate of issue 19119.

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> duplicate test name in Lib/test/test_heapq.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26840>
_______________________________________

From report at bugs.python.org  Sun Apr 24 16:33:44 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 24 Apr 2016 20:33:44 +0000
Subject: [issue26249] Change PyMem_Malloc to use pymalloc allocator
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <20160424203331.13955.42726.79DAB394@psf.io>


Roundup Robot added the comment:

New changeset 7acad5d8f80e by Victor Stinner in branch 'default':
Issue #26249: Mention PyMem_Malloc() change in What's New in Python 3.6 in the
https://hg.python.org/cpython/rev/7acad5d8f80e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26249>
_______________________________________

From report at bugs.python.org  Sun Apr 24 16:34:16 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 24 Apr 2016 20:34:16 +0000
Subject: [issue26841] Hidden test in ctypes tests
In-Reply-To: <1461529482.09.0.936239527723.issue26841@psf.upfronthosting.co.za>
Message-ID: <1461530056.89.0.992540061053.issue26841@psf.upfronthosting.co.za>


Berker Peksag added the comment:

This is a duplicate of issue 19113.

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> duplicate test names in Lib/ctypes/test/test_functions.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26841>
_______________________________________

From report at bugs.python.org  Sun Apr 24 16:35:26 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 24 Apr 2016 20:35:26 +0000
Subject: [issue26249] Change PyMem_Malloc to use pymalloc allocator
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <1461530126.18.0.724316758226.issue26249@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I documented the change, buildbots are happy, I close the issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26249>
_______________________________________

From report at bugs.python.org  Sun Apr 24 17:35:16 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 24 Apr 2016 21:35:16 +0000
Subject: [issue26822] itemgetter/attrgetter/methodcaller objects ignore
 keyword arguments
In-Reply-To: <1461266621.67.0.0664681491354.issue26822@psf.upfronthosting.co.za>
Message-ID: <1461533716.01.0.255106798455.issue26822@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch that adds fast checks before calling _PyArg_NoKeywords().

Other option is redefine _PyArg_NoKeywords as a macro:

#define _PyArg_NoKeywords(name, kw)  ((kw) != NULL && _PyArg_NoKeywords((name), (kw)))

This will affect all usages of _PyArg_NoKeywords.

----------
Added file: http://bugs.python.org/file42583/operator_getters_kwargs_speedup.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26822>
_______________________________________

From report at bugs.python.org  Sun Apr 24 18:37:06 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 24 Apr 2016 22:37:06 +0000
Subject: [issue12305] Building PEPs doesn't work on Python 3
In-Reply-To: <1307665935.0.0.179187869363.issue12305@psf.upfronthosting.co.za>
Message-ID: <1461537426.52.0.773514496195.issue12305@psf.upfronthosting.co.za>


Berker Peksag added the comment:

peps repo is now Python 3 compatible. Related commits:

* https://github.com/python/peps/commit/88f9f6da5d51a36d0f6a1bb833a6e8c85763c7d2
* https://github.com/python/peps/commit/3e5cad857053e0c15b2621dae728f32b4099c1a5

----------
nosy: +berker.peksag
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12305>
_______________________________________

From report at bugs.python.org  Sun Apr 24 19:27:22 2016
From: report at bugs.python.org (Edward Segall)
Date: Sun, 24 Apr 2016 23:27:22 +0000
Subject: [issue26842] Python Tutorial 4.7.1: Need to explain default parameter
 lifetime
Message-ID: <1461540442.59.0.34324123093.issue26842@psf.upfronthosting.co.za>


New submission from Edward Segall:

I am using the tutorial to learn Python. I know many other languages, and I've taught programming language theory, but even so I found the warning in Section 4.7.1 about Default Argument Values to be confusing. After I spent some effort investigating what actually happens, I realized that the warning is incomplete. 

I'll suggest a fix below, after explaining what concerns me. 

Here is the warning in question:

-----------------------------------------------------------------
Important warning: The default value is evaluated only once. This makes a difference when the default is a mutable object such as a list, dictionary, or instances of most classes. ...

def f(a, L=[]):
    L.append(a)
    return L

print(f(1))
print(f(2))
print(f(3))

This will print

[1]
[1, 2]
[1, 2, 3]
-----------------------------------------------------------------

It's clear from this example that values are carried from one function invocation to another. That's pretty unusual behavior for a "traditional" function, but it's certainly not unheard of -- in C/C++/Java, you can preserve state across invocations by declaring that a local variable has static lifetime. When using this capability, though, it's essential to understand exactly what's happening -- or at least well enough to anticipate its behavior under a range of conditions. I don't believe the warning and example are sufficient to convey such an understanding. 

After playing with it for a while, I've concluded the following: "regular" local variables have the usual behavior (called "automatic" lifetime in C/C++ jargon), as do the function's formal parameters, EXCEPT when a default value is defined. Each default value is stored in a location that has static lifetime, and THAT is the reason it matters that (per the warning) the expression defining the default value is evaluated only once. 

This is very unfamiliar behavior -- I don't think I have used another modern language with this feature. So I think it's important that the explanation be very clear. 

I would like to suggest revising the warning and example to something more like the following: 

-----------------------------------------------------------------
Important warning: When you define a function with a default argument value, the expression defining the default value is evaluated only once, but the resultant value persists as long as the function is defined. If this value is a mutable object such as a list, dictionary, or instance of most classes, it is possible to change that object after the function is defined, and if you do that, the new (mutated) value will subsequently be used as the default value.  

For example, the following function accepts two arguments:

def f(a, L=[]):
    L.append(a)
    return L

This function is defined with a default value for its second formal parameter, called L. The expression that defines the default value denotes an empty list. When the function is defined, this expression is evaluated once. The resultant list is saved as the default value for L. 

Each time the function is called, it appends the first argument to the second one by invoking the second argument's append method. 

If we call the function with two arguments, the default value is not used. Instead, the list that is passed in as the second argument is modified. However, if we call the function with one argument, the default value is modified. 

Consider the following sequence of calls. First, we define a list and pass it in each time as the second argument. This list accumulates the first arguments, as follows: 


myList=[]
print(f(0, myList))
print(f(1, myList))

This will print: 

[0]
[0, 1]

As you can see, myList is being used to accumulate the values passed in to the first as the first argument.
 
If we then use the default value by passing in only one argument, as follows:

print(f(2))
print(f(3))

we will see: 

[2]
[2, 3]

Here, the two invocations appended values to to the default list. 

Let's continue, this time going back to myList:

print(f(4,myList))

Now the result will be:

[0, 1, 4]

because myList still contains the earlier values.

The default value still has its earlier values too, as we can see here:

print(f(5))

[2, 3, 5]

To summarize, there are two distinct cases: 

1) When the function is invoked with an argument list that includes a value for L, that L (the one being passed in) is changed by the function. 

2) When the function is invoked with an argument list that does not include a value for L, the default value for L is changed, and that change persists through future invocations. 
-----------------------------------------------------------------

I hope this is useful. I realize it is much longer than the original. I had hoped to make it shorter, but when I did I found I was glossing over important details.

----------
assignee: docs at python
components: Documentation
messages: 264135
nosy: docs at python, esegall
priority: normal
severity: normal
status: open
title: Python Tutorial 4.7.1: Need to explain default parameter lifetime
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26842>
_______________________________________

From report at bugs.python.org  Sun Apr 24 20:31:18 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 25 Apr 2016 00:31:18 +0000
Subject: [issue26800] Don't accept bytearray as filenames part 2
In-Reply-To: <1461526243.35.0.305938533284.issue26800@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJ=+kG=2L7egHjBa3We2cDByxk3Ss8iabQxVdj9-doWCA@mail.gmail.com>


Guido van Rossum added the comment:

OK, it isn't worth fighting for. I will update PEP 484. It seems mypy
doesn't support the special treatment bytearray anyway.

For posterity, the reason I thought that bytearray should be accepted is
not that bytearray is better in any way, just that sometimes you might read
a filename off a bytearray that you read off a file or a socket. But it's
clearly not a strong use case (or we had gotten complaints long ago) so
I'll let it go. Sorry!! Thanks for the feedback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26800>
_______________________________________

From report at bugs.python.org  Sun Apr 24 20:44:58 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 25 Apr 2016 00:44:58 +0000
Subject: [issue26837] assertSequenceEqual() raises BytesWarning when format
 message
In-Reply-To: <1461511946.3.0.425674817359.issue26837@psf.upfronthosting.co.za>
Message-ID: <1461545098.0.0.423884524319.issue26837@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think the change is good in spirit, especially using repr() and limiting the size. See the review for a couple problems.

----------
nosy: +martin.panter
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26837>
_______________________________________

From report at bugs.python.org  Sun Apr 24 20:53:05 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 25 Apr 2016 00:53:05 +0000
Subject: [issue26800] Don't accept bytearray as filenames part 2
In-Reply-To: <CAP7+vJJ=+kG=2L7egHjBa3We2cDByxk3Ss8iabQxVdj9-doWCA@mail.gmail.com>
Message-ID: <CAP7+vJKgWAe6QHWPZG3dcJMWqo-W8iBOmmQ_pmBA7x8=qL7YwQ@mail.gmail.com>


Guido van Rossum added the comment:

Sigh, I was wrong, not only does mypy promote bytearray to bytes, it
actually depends on this in its own code. Not for filenames, but for a
regex match. It reads the source into a bytearray, and then passes that to
something that uses regex matches (which *do* support bytearrays, and
rightly so). If I remove the bytearray promotion I run into some type
errors, and if I fix those (without copying data) I run into more type
errors. I guess we could fix it by carefully marking up everything that
takes bytearrays in the stubs, but it's surely inconvenient. So maybe I'll
leave this in mypy for now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26800>
_______________________________________

From report at bugs.python.org  Sun Apr 24 20:55:16 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Apr 2016 00:55:16 +0000
Subject: [issue26800] Don't accept bytearray as filenames part 2
In-Reply-To: <1461015295.39.0.246147143774.issue26800@psf.upfronthosting.co.za>
Message-ID: <20160425005513.335.21584.E3EB5D83@psf.io>


Roundup Robot added the comment:

New changeset 3fb0f9a0b195 by Guido van Rossum in branch 'default':
Rip out the promotion from bytearray/memoryview to bytes. See http://bugs.python.org/issue26800.
https://hg.python.org/peps/rev/3fb0f9a0b195

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26800>
_______________________________________

From report at bugs.python.org  Sun Apr 24 20:57:52 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 25 Apr 2016 00:57:52 +0000
Subject: [issue26804] Prioritize lowercase proxy variables in urllib.request
In-Reply-To: <1461053909.86.0.0123928931795.issue26804@psf.upfronthosting.co.za>
Message-ID: <1461545872.46.0.699559771603.issue26804@psf.upfronthosting.co.za>


Martin Panter added the comment:

Yes that was my rambling way of saying that I had checked to see if they were in the right place, and reporting that it was all okay :)

New patch seems okay to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26804>
_______________________________________

From report at bugs.python.org  Sun Apr 24 21:09:18 2016
From: report at bugs.python.org (Kylie McClain)
Date: Mon, 25 Apr 2016 01:09:18 +0000
Subject: [issue21622] ctypes.util incorrectly fails for libraries without
 DT_SONAME
In-Reply-To: <1401593302.24.0.994822187168.issue21622@psf.upfronthosting.co.za>
Message-ID: <1461546558.55.0.607070368971.issue21622@psf.upfronthosting.co.za>


Kylie McClain added the comment:

This is still a problem on musl distributions as of 2.7.11. Are there any plans to fix this?

Patch used by Alpine Linux:
http://git.alpinelinux.org/cgit/aports/tree/main/python/musl-find_library.patch

----------
nosy: +Kylie McClain

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21622>
_______________________________________

From report at bugs.python.org  Sun Apr 24 21:24:08 2016
From: report at bugs.python.org (Eric Hanchrow)
Date: Mon, 25 Apr 2016 01:24:08 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1461547448.59.0.36895457788.issue15873@psf.upfronthosting.co.za>


Changes by Eric Hanchrow <eric.hanchrow at gmail.com>:


----------
nosy: +Eric.Hanchrow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Sun Apr 24 21:41:20 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 25 Apr 2016 01:41:20 +0000
Subject: [issue24114] ctypes.utils uninitialized variable 'paths'
In-Reply-To: <1430578995.23.0.112303250331.issue24114@psf.upfronthosting.co.za>
Message-ID: <1461548480.25.0.0706326298161.issue24114@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
stage: patch review -> needs patch
title: ctypes.utils uninitialized variable 'path' -> ctypes.utils uninitialized variable 'paths'
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24114>
_______________________________________

From report at bugs.python.org  Sun Apr 24 21:46:39 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 25 Apr 2016 01:46:39 +0000
Subject: [issue6338] Error message displayed on stderr when no C compiler is
 present with ctypes
In-Reply-To: <1245877709.89.0.124582375066.issue6338@psf.upfronthosting.co.za>
Message-ID: <1461548799.07.0.00323274952715.issue6338@psf.upfronthosting.co.za>


Martin Panter added the comment:

It would be good to close the file when it?s no longer needed. Also, if this bug is relevant to Python 3, I would use open() rather than file().

----------
nosy: +martin.panter
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6338>
_______________________________________

From report at bugs.python.org  Sun Apr 24 21:53:50 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 25 Apr 2016 01:53:50 +0000
Subject: [issue18502] CDLL does not use same paths as util.find_library
In-Reply-To: <1374185482.63.0.0818947870098.issue18502@psf.upfronthosting.co.za>
Message-ID: <1461549230.75.0.0908995596349.issue18502@psf.upfronthosting.co.za>


Martin Panter added the comment:

Documenting this quirk seems reasonable to me if you want to suggest a patch (and we don?t agree to fix it).

See Issue 21042 for returning full paths on Linux. We tried to make this change, but it wasn?t easy to do it consistently for arbitrary ABIs, so I backed it out.

See Issue 9998 discussing changing find_library() to emulate a run-time linker, rather than a compile-time linker.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18502>
_______________________________________

From report at bugs.python.org  Sun Apr 24 21:55:11 2016
From: report at bugs.python.org (Steven Adams)
Date: Mon, 25 Apr 2016 01:55:11 +0000
Subject: [issue26793] uuid causing thread issues when forking using os.fork
 py3.4+
In-Reply-To: <1460955119.44.0.370193254434.issue26793@psf.upfronthosting.co.za>
Message-ID: <1461549311.8.0.143607180671.issue26793@psf.upfronthosting.co.za>


Steven Adams added the comment:

anyone got any other thoughts on this??

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26793>
_______________________________________

From report at bugs.python.org  Sun Apr 24 21:58:44 2016
From: report at bugs.python.org (Joshua Landau)
Date: Mon, 25 Apr 2016 01:58:44 +0000
Subject: [issue26843] tokenize does not include Other_ID_Start or
 Other_ID_Continue in identifier
Message-ID: <1461549524.26.0.280315753344.issue26843@psf.upfronthosting.co.za>


New submission from Joshua Landau:

This is effectively a continuation of https://bugs.python.org/issue9712.

The line in Lib/tokenize.py

    Name = r'\w+'

must be changed to a regular expression that accepts Other_ID_Start at the start and Other_ID_Continue elsewhere. Hence tokenize does not accept '??'.


See the reference here:

    https://docs.python.org/3.5/reference/lexical_analysis.html#identifiers

I'm unsure whether unicode normalization (aka the `xid` properties) needs to be dealt with too.


Credit to toriningen from http://stackoverflow.com/a/29586366/1763356.

----------
components: Library (Lib)
messages: 264145
nosy: Joshua.Landau
priority: normal
severity: normal
status: open
title: tokenize does not include Other_ID_Start or Other_ID_Continue in identifier
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26843>
_______________________________________

From report at bugs.python.org  Sun Apr 24 22:39:00 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 25 Apr 2016 02:39:00 +0000
Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux
In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za>
Message-ID: <1461551940.0.0.550850020793.issue9998@psf.upfronthosting.co.za>


Martin Panter added the comment:

I also found Issue 18502 essentially about the same incompatibility between CDLL() and find_library().

The problem I see with using find_library() to blindly load a library is that you could be loading an incompatible version (wrong soname). That is why I asked Pau why they couldn?t give the proper library name to CDLL().

I noticed that Python?s own ?uuid? module calls CDLL(find_library("uuid")); see <https://hg.python.org/cpython/annotate/v3.5.1/Lib/uuid.py#l459>. On my Linux computer, the full library name is libuuid.so.1, and according to online man pages, this is also the case on Free BSD. So I wonder if the ?uuid? module should call CDLL("libuuid.so.1") directly. If somebody invented a new incompatible version libuuid.so.2, Python?s uuid module might crash, or become subtly broken, but programs that linked directly to libuuid.so.1 would continue to work.

Does anyone have any valid use cases where they want to use a shared library on LD_LIBRARY_PATH or similar, but cannot use CDLL() or LoadLibrary() directly? If people really want a way to load a library given its compile-time name, maybe changing find_library() is a valid way forward. But to me the use case does not seem robust or worth blessing in Python?s standard library.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9998>
_______________________________________

From report at bugs.python.org  Sun Apr 24 22:46:47 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 25 Apr 2016 02:46:47 +0000
Subject: [issue19317] ctypes.util.find_library should examine binary's RPATH
 on Solaris
In-Reply-To: <1382283098.83.0.173984225129.issue19317@psf.upfronthosting.co.za>
Message-ID: <1461552407.74.0.890422729284.issue19317@psf.upfronthosting.co.za>


Martin Panter added the comment:

find_library() is documented as emulating the build-time linker, and I suspect the RPATH of the Python executable is not relevant at build time. See also Issue 9998 and Issue 18502.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19317>
_______________________________________

From report at bugs.python.org  Sun Apr 24 23:20:15 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 25 Apr 2016 03:20:15 +0000
Subject: [issue21622] ctypes.util incorrectly fails for libraries without
 DT_SONAME
In-Reply-To: <1401593302.24.0.994822187168.issue21622@psf.upfronthosting.co.za>
Message-ID: <1461554415.97.0.0574013143241.issue21622@psf.upfronthosting.co.za>


Martin Panter added the comment:

On Linux, the find_library() function is documented to return ?the filename of the library file?, but in reality it seems it return the soname, and therefore breaks if there is no soname. I do not know why we extract the soname, but it has been that way at least since ctypes was added to Python 2.5.

What do you intend to do with the result of find_library()? See also Issue 9998, especially about searching LD_LIBRARY_PATH. I am struggling to see robust use cases for find_library().

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21622>
_______________________________________

From report at bugs.python.org  Sun Apr 24 23:26:52 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 25 Apr 2016 03:26:52 +0000
Subject: [issue21826] Performance issue (+fix) AIX ctypes.util with no
 /sbin/ldconfig present
In-Reply-To: <1403452871.25.0.30621640858.issue21826@psf.upfronthosting.co.za>
Message-ID: <1461554812.64.0.214915395452.issue21826@psf.upfronthosting.co.za>


Martin Panter added the comment:

See also Issue 26439 about find_library() AIX support

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21826>
_______________________________________

From report at bugs.python.org  Sun Apr 24 23:28:51 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 25 Apr 2016 03:28:51 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1461554931.4.0.113230431599.issue26439@psf.upfronthosting.co.za>


Martin Panter added the comment:

Maybe Issue 21826 is relevant (slowdown on AIX caused by missing ldconfig)

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Sun Apr 24 23:51:23 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 25 Apr 2016 03:51:23 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1461556283.98.0.268202156341.issue11063@psf.upfronthosting.co.za>


Martin Panter added the comment:

One thing I am wondering about is why we have to use find_library() at all. Wouldn?t it be more robust, and more efficient, to call CDLL() directly? We just have to know the exactly library version we are expecting. On Linux, the full soname is libuuid.so.1. It seems on OS X it is called libc.dylib (but it would be good for someone else to confirm).

# The uuid_generate_* routines are provided by libuuid on at least
# Linux and FreeBSD, and provided by libc on Mac OS X.
if sys.platform == "darwin":
    libname = "libc.dylib"
else:
    libname = "libuuid.so.1"
_ctypes_lib = ctypes.CDLL(libname)

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11063>
_______________________________________

From report at bugs.python.org  Sun Apr 24 23:54:14 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 25 Apr 2016 03:54:14 +0000
Subject: [issue23961] IDLE autocomplete window does not automatically close
 when selection is made
In-Reply-To: <1429060935.51.0.684469355013.issue23961@psf.upfronthosting.co.za>
Message-ID: <1461556454.3.0.777348947875.issue23961@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage:  -> resolved
status: open -> closed
superseder:  -> IDLE code completion window can hang or misbehave with mouse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23961>
_______________________________________

From report at bugs.python.org  Mon Apr 25 00:14:27 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 25 Apr 2016 04:14:27 +0000
Subject: [issue24331] *** Error in `/usr/bin/python': double free or
 corruption (!prev): 0x0000000000f5c760 *** when cloning hg repository into
 directory on cifs
In-Reply-To: <1432992886.73.0.102368057265.issue24331@psf.upfronthosting.co.za>
Message-ID: <1461557667.88.0.780738359073.issue24331@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Agreed, this is unlikely an issue with Python. Please report it to Mercurial developers.

----------
nosy: +berker.peksag
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24331>
_______________________________________

From report at bugs.python.org  Mon Apr 25 00:19:28 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 25 Apr 2016 04:19:28 +0000
Subject: [issue24114] ctypes.utils uninitialized variable 'paths'
In-Reply-To: <1430578995.23.0.112303250331.issue24114@psf.upfronthosting.co.za>
Message-ID: <1461557968.61.0.89385259941.issue24114@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +easy
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24114>
_______________________________________

From report at bugs.python.org  Mon Apr 25 01:24:44 2016
From: report at bugs.python.org (paul j3)
Date: Mon, 25 Apr 2016 05:24:44 +0000
Subject: [issue20430] Make argparse.SUPPRESS work as an argument "dest"
In-Reply-To: <1390963954.16.0.426686215118.issue20430@psf.upfronthosting.co.za>
Message-ID: <1461561884.71.0.635491907194.issue20430@psf.upfronthosting.co.za>


paul j3 added the comment:

I just found a case where `dest` is `SUPPRESS` - the default subparsers setup.

      _SubParsersAction(option_strings=[], dest='==SUPPRESS==', nargs='A...', ...

If I make this Action 'required' (in the current distribution 'subparsers' are not required - there's a bug/issue for that)

     parser._actions[1].required=True

and call the parser without the required subparser argument I should get an error message.  In earlier versions this would have been a non specific,  `error: too few arguments', but the new one tries to name the missing argument, e.g.

    program: error: the following arguments are required: choice

But with SUPPRESS I get a further error as _parse_known_args tries to format this error message:

C:\Users\paul\Miniconda3\lib\argparse.py in _parse_known_args(self, arg_strings, namespace)
   1991         if required_actions:
   1992             self.error(_('the following arguments are required: %s') %
-> 1993                        ', '.join(required_actions))

TypeError: sequence item 0: expected str instance, NoneType found

(This error may have been reported elsewhere.  This issue is the first one I found that deals with `dest=argparse.SUPPRESS`.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20430>
_______________________________________

From report at bugs.python.org  Mon Apr 25 02:00:21 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Apr 2016 06:00:21 +0000
Subject: [issue26837] assertSequenceEqual() raises BytesWarning when format
 message
In-Reply-To: <1461511946.3.0.425674817359.issue26837@psf.upfronthosting.co.za>
Message-ID: <20160425060011.63430.82103.0DFCD906@psf.io>


Roundup Robot added the comment:

New changeset ae5cc8ab664a by Serhiy Storchaka in branch '3.5':
Issue #26837: assertSequenceEqual() now correctly outputs non-stringified
https://hg.python.org/cpython/rev/ae5cc8ab664a

New changeset d0d541c2afb7 by Serhiy Storchaka in branch '2.7':
Issue #26837: assertSequenceEqual() now correctly outputs non-stringified
https://hg.python.org/cpython/rev/d0d541c2afb7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26837>
_______________________________________

From report at bugs.python.org  Mon Apr 25 02:01:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 Apr 2016 06:01:04 +0000
Subject: [issue26837] assertSequenceEqual() raises BytesWarning when format
 message
In-Reply-To: <1461511946.3.0.425674817359.issue26837@psf.upfronthosting.co.za>
Message-ID: <1461564064.53.0.913108564009.issue26837@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your helpful review Martin!

----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26837>
_______________________________________

From report at bugs.python.org  Mon Apr 25 02:05:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 Apr 2016 06:05:00 +0000
Subject: [issue26843] tokenize does not include Other_ID_Start or
 Other_ID_Continue in identifier
In-Reply-To: <1461549524.26.0.280315753344.issue26843@psf.upfronthosting.co.za>
Message-ID: <1461564300.11.0.323227306971.issue26843@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is a duplicate of issue24194. Yes, there is no progress still.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> tokenize yield an ERRORTOKEN if an identifier uses Other_ID_Start or Other_ID_Continue

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26843>
_______________________________________

From report at bugs.python.org  Mon Apr 25 02:05:43 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 Apr 2016 06:05:43 +0000
Subject: [issue24194] tokenize yield an ERRORTOKEN if an identifier uses
 Other_ID_Start or Other_ID_Continue
In-Reply-To: <1431608427.75.0.966529056278.issue24194@psf.upfronthosting.co.za>
Message-ID: <1461564343.2.0.716005602316.issue24194@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage:  -> needs patch
versions: +Python 3.5, Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24194>
_______________________________________

From report at bugs.python.org  Mon Apr 25 02:08:17 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 Apr 2016 06:08:17 +0000
Subject: [issue24194] tokenize yield an ERRORTOKEN if an identifier uses
 Other_ID_Start or Other_ID_Continue
In-Reply-To: <1431608427.75.0.966529056278.issue24194@psf.upfronthosting.co.za>
Message-ID: <1461564497.11.0.5975076883.issue24194@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
dependencies: +Request for property support in Python re lib, python lib re uses obsolete sense of \w in full violation of UTS#18 RL1.2a

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24194>
_______________________________________

From report at bugs.python.org  Mon Apr 25 02:09:06 2016
From: report at bugs.python.org (Lev Maximov)
Date: Mon, 25 Apr 2016 06:09:06 +0000
Subject: [issue26844] Wrong error message during import
Message-ID: <1461564546.15.0.190869698481.issue26844@psf.upfronthosting.co.za>


New submission from Lev Maximov:

Error message was supposedly copy-pasted without change.
Makes it pretty unintuinive to debug.
Fix attached.

----------
components: Library (Lib)
files: error.diff
keywords: patch
messages: 264157
nosy: Lev Maximov
priority: normal
severity: normal
status: open
title: Wrong error message during import
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/file42584/error.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26844>
_______________________________________

From report at bugs.python.org  Mon Apr 25 02:15:09 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 25 Apr 2016 06:15:09 +0000
Subject: [issue26844] Wrong error message during import
In-Reply-To: <1461564546.15.0.190869698481.issue26844@psf.upfronthosting.co.za>
Message-ID: <1461564909.2.0.807774065488.issue26844@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +brett.cannon
priority: normal -> low
stage:  -> patch review
versions:  -Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26844>
_______________________________________

From report at bugs.python.org  Mon Apr 25 02:21:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 Apr 2016 06:21:35 +0000
Subject: [issue26844] Wrong error message during import
In-Reply-To: <1461564546.15.0.190869698481.issue26844@psf.upfronthosting.co.za>
Message-ID: <1461565295.84.0.246461818534.issue26844@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

But while we are here, it would be nice to replace type(path) with type(path).__name__ (and the same for type(name)).

----------
nosy: +eric.snow, ncoghlan, serhiy.storchaka
stage: patch review -> commit review
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26844>
_______________________________________

From report at bugs.python.org  Mon Apr 25 02:36:56 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 25 Apr 2016 06:36:56 +0000
Subject: [issue23662] Cookie.domain is undocumented
In-Reply-To: <1426345280.31.0.365548742215.issue23662@psf.upfronthosting.co.za>
Message-ID: <1461566216.84.0.0387356802784.issue23662@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.6 -Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23662>
_______________________________________

From report at bugs.python.org  Mon Apr 25 03:59:27 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 25 Apr 2016 07:59:27 +0000
Subject: [issue17905] Add check for locale.h
In-Reply-To: <1367676553.24.0.0475219885835.issue17905@psf.upfronthosting.co.za>
Message-ID: <1461571167.47.0.323762912755.issue17905@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Android API level 21 has a full fledged locale.h now.
There is still no langinfo.h, this issue is a duplicate of issue #22747.

----------
nosy: +xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17905>
_______________________________________

From report at bugs.python.org  Mon Apr 25 04:03:06 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 25 Apr 2016 08:03:06 +0000
Subject: [issue22747] Interpreter fails in initialize on systems where
 HAVE_LANGINFO_H is undefined
In-Reply-To: <1414445408.19.0.175857050886.issue22747@psf.upfronthosting.co.za>
Message-ID: <1461571386.2.0.595483616095.issue22747@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Android default system encoding is UTF-8 as specified at http://developer.android.com/reference/java/nio/charset/Charset.html

<quote>The platform's default charset is UTF-8. (This is in contrast to some older implementations, where the default charset depended on the user's locale.) </quote>

> If the platform doesn't provide anything, we can maybe adopt the same
> approach than Mac OS X: force the encoding to UTF-8 and just don't use
> the C library.

The attached patch does the same thing as proposed by Victor but emphasizes that Android does not HAVE_LANGINFO_H and does not have CODESET.  And the fact that HAVE_LANGINFO_H and CODESET are not defined causes other problems (maybe as well in Mac OS X). In that case, PyCursesWindow_New() in _cursesmodule.c falls back nicely to "utf-8", but _Py_device_encoding() in fileutils.c instead does a Py_RETURN_NONE. It seems that this impacts _io_TextIOWrapper___init___impl() in textio.c and os_device_encoding_impl() in posixmodule.c. And indeed, os.device_encoding(0) returns None on android.

----------
nosy: +xdegaye
Added file: http://bugs.python.org/file42585/locale.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22747>
_______________________________________

From report at bugs.python.org  Mon Apr 25 04:03:59 2016
From: report at bugs.python.org (Joshua Landau)
Date: Mon, 25 Apr 2016 08:03:59 +0000
Subject: [issue26843] tokenize does not include Other_ID_Start or
 Other_ID_Continue in identifier
In-Reply-To: <1461549524.26.0.280315753344.issue26843@psf.upfronthosting.co.za>
Message-ID: <1461571439.63.0.712180408664.issue26843@psf.upfronthosting.co.za>


Joshua Landau added the comment:

Sorry, I'd stumbled on my old comment on the closed issue and completely forgot about the *last* time I did the same thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26843>
_______________________________________

From report at bugs.python.org  Mon Apr 25 04:07:53 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 25 Apr 2016 08:07:53 +0000
Subject: [issue20305] Android's incomplete locale.h implementation prevents
 cross-compilation
In-Reply-To: <1390155202.76.0.360148898057.issue20305@psf.upfronthosting.co.za>
Message-ID: <1461571673.64.0.0969964859725.issue20305@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

This error:
    _curses.error: setupterm: could not find terminfo database

does not occur for me after removing the '--disable-database --disable-home-terminfo' options from the configure options used to cross-compile ncurses, and after setting the TERMINFO environment variable to a location where the the compiled description of the vt100 terminal is set. See https://bitbucket.org/xdegaye/pyona.

Also, with API level 21 (Android 5.0), the build of python3 with the official android toolchains (that is, without resorting to external libraries for wide character support) runs correctly and the python test suite is run with few errors, so IMHO this issue may be closed.

----------
nosy: +xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20305>
_______________________________________

From report at bugs.python.org  Mon Apr 25 04:24:50 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 25 Apr 2016 08:24:50 +0000
Subject: [issue26842] Python Tutorial 4.7.1: Need to explain default parameter
 lifetime
In-Reply-To: <1461540442.59.0.34324123093.issue26842@psf.upfronthosting.co.za>
Message-ID: <1461572690.17.0.444168828407.issue26842@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> I hope this is useful. I realize it is much longer than the original.

There lies the difficultly.  The purpose of the tutorial is to quickly introduce the language, not to take someone deeply down a rabbit hole.  The docs tend to be worded in an affirmative manner showing cases of the language being used properly, giving a brief warning where necessary.  Further explorations should be left as FAQs.  

I think we could add a FAQ link or somesuch to the existing warning but the main flow shouldn't be interrupted (many on the topics in the tutorial could warrant entire blog posts and scores of StackOverflow entries, but the tutorial itself aspires to be a "short and sweet" quick tour around the language.  

The utility and approachability of the tutorial would be undermined by overexpanding each new topic.  This is especially important in the early sections of the tutorial (i.e. section 4).  

Also, I don't really like the provided explanation, "there are two cases ...".  The actual execution model has one case (default arguments are evaluated once when the function is defined) and there are many ways to use it.

Lastly, this is only one facet of parameter specification and parameter passing.  Other facets include, variable length argument lists, keyword-only arguments, annotations, etc.   Any expanded coverage should occur later in the tutorial and cover all the facets collectively.

----------
nosy: +rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26842>
_______________________________________

From report at bugs.python.org  Mon Apr 25 04:30:41 2016
From: report at bugs.python.org (Pau Tallada)
Date: Mon, 25 Apr 2016 08:30:41 +0000
Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux
In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za>
Message-ID: <1461573041.26.0.707906127506.issue9998@psf.upfronthosting.co.za>


Pau Tallada added the comment:

> Pau: What is wrong with the more direct CDLL("libspatialindex_c.so") proposal that bypasses find_library()?

I don't know much about library loading, but from what I understand at https://github.com/Toblerity/rtree/issues/56 , if they hardcode "libspatialindex_c.so" in CDLL call, then it breaks in OSX, because its uses .dylib extension. And they don't want to reimplement find_library to choose the right extension for each platform.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9998>
_______________________________________

From report at bugs.python.org  Mon Apr 25 04:41:22 2016
From: report at bugs.python.org (Hans-Peter Jansen)
Date: Mon, 25 Apr 2016 08:41:22 +0000
Subject: [issue26804] Prioritize lowercase proxy variables in urllib.request
In-Reply-To: <1461053909.86.0.0123928931795.issue26804@psf.upfronthosting.co.za>
Message-ID: <1461573682.02.0.102687459783.issue26804@psf.upfronthosting.co.za>


Hans-Peter Jansen added the comment:

v7:
 - reorder test code in order to improve edibility

----------
Added file: http://bugs.python.org/file42586/python-urllib-prefer-lowercase-proxies-v7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26804>
_______________________________________

From report at bugs.python.org  Mon Apr 25 05:44:22 2016
From: report at bugs.python.org (Marcos Dione)
Date: Mon, 25 Apr 2016 09:44:22 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module and use
 it to improve shutils.copy()
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1461577462.96.0.292131992216.issue26826@psf.upfronthosting.co.za>


Marcos Dione added the comment:

Then I don't know. My only worry is whether having the method local to os would allow shutils.copy() to use it or not.

I will start by looking at other similar functions there to see to do it. urandom() looks like a good starting point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Mon Apr 25 06:35:36 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Apr 2016 10:35:36 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module and use
 it to improve shutils.copy()
In-Reply-To: <1461577462.96.0.292131992216.issue26826@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYHytMOLfc8cHP8McH+9EceCVkNAuKrE_sVqpOKY_fypA@mail.gmail.com>


STINNER Victor added the comment:

If we add a new private function to the os module (ex:
os._copy_file_range), it can be used in shutil if available. But it
would be a temporary solution until we declare the API stable. Maybe
it's ok to add the API as public today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Mon Apr 25 06:44:37 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 25 Apr 2016 10:44:37 +0000
Subject: [issue9456] Apparent memory leak in PC/bdist_wininst/install.c
In-Reply-To: <1280781943.93.0.297912103498.issue9456@psf.upfronthosting.co.za>
Message-ID: <1461581077.93.0.282050888194.issue9456@psf.upfronthosting.co.za>


Berker Peksag added the comment:

install_c.diff looks good to me. Attaching a fresh version of it. There is a comment in PC/bdist_wininst/install.c saying

    IMPORTANT NOTE: IF THIS FILE IS CHANGED, PCBUILD\BDIST_WININST.VCXPROJ MUST BE REBUILT AS WELL.

I don't have Windows so I can't build VS project files myself. I'm adding Steve and Zachary to review/commit the patch (if they have time to take a look at it).

----------
nosy: +berker.peksag, steve.dower, zach.ware
stage:  -> patch review
type:  -> behavior
versions: +Python 3.6 -Python 3.4
Added file: http://bugs.python.org/file42587/issue9456.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9456>
_______________________________________

From report at bugs.python.org  Mon Apr 25 07:20:31 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Mon, 25 Apr 2016 11:20:31 +0000
Subject: [issue26039] More flexibility in zipfile write interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1461583231.33.0.31785233517.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

It wasn't as bad as I thought (hopefully that doesn't mean I've missed something). zipfile-open-w6.patch allows interleaved reads and writes so long as the underlying file object is seekable.

You still can't have multiple write handles open (it wouldn't know where to start the second file), or read & write handles on a non-seekable stream (I don't think a non-seekable read-write file ever makes sense, except perhaps for a pty, which is really two separate streams on one file descriptor).

Tests are passing again.

----------
Added file: http://bugs.python.org/file42588/zipfile-open-w6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Mon Apr 25 07:28:00 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 25 Apr 2016 11:28:00 +0000
Subject: [issue9456] Apparent memory leak in PC/bdist_wininst/install.c
In-Reply-To: <1280781943.93.0.297912103498.issue9456@psf.upfronthosting.co.za>
Message-ID: <1461583680.46.0.0531393811717.issue9456@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9456>
_______________________________________

From report at bugs.python.org  Mon Apr 25 07:32:25 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Apr 2016 11:32:25 +0000
Subject: [issue23662] Cookie.domain is undocumented
In-Reply-To: <1426345280.31.0.365548742215.issue23662@psf.upfronthosting.co.za>
Message-ID: <20160425113216.24440.33452.4C633716@psf.io>


Roundup Robot added the comment:

New changeset 1fdaa71d47f5 by Berker Peksag in branch '3.5':
Issue #23662: Document default value of RFC 2109 attributes
https://hg.python.org/cpython/rev/1fdaa71d47f5

New changeset b3ad9c002bb8 by Berker Peksag in branch 'default':
Issue #23662: Document default value of RFC 2109 attributes
https://hg.python.org/cpython/rev/b3ad9c002bb8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23662>
_______________________________________

From report at bugs.python.org  Mon Apr 25 07:35:20 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 25 Apr 2016 11:35:20 +0000
Subject: [issue23662] Cookie.domain is undocumented
In-Reply-To: <1426345280.31.0.365548742215.issue23662@psf.upfronthosting.co.za>
Message-ID: <1461584120.13.0.711330772702.issue23662@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Actually, it's already documented at https://docs.python.org/3.5/library/http.cookies.html#http.cookies.Morsel. I just added a note about the default value of domain.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23662>
_______________________________________

From report at bugs.python.org  Mon Apr 25 08:01:01 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 25 Apr 2016 12:01:01 +0000
Subject: [issue7504] Same name cookies
In-Reply-To: <1260798869.28.0.314761148717.issue7504@psf.upfronthosting.co.za>
Message-ID: <1461585661.18.0.853430539382.issue7504@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Improper handling of duplicate cookies

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7504>
_______________________________________

From report at bugs.python.org  Mon Apr 25 08:04:56 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 25 Apr 2016 12:04:56 +0000
Subject: [issue991266] Cookie.py does not correctly quote Morsels
Message-ID: <1461585896.96.0.670108748379.issue991266@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Here is a patch for Python 3.

----------
nosy: +berker.peksag
versions: +Python 3.5, Python 3.6 -Python 3.1, Python 3.2
Added file: http://bugs.python.org/file42589/issue991266.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue991266>
_______________________________________

From report at bugs.python.org  Mon Apr 25 08:08:35 2016
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 25 Apr 2016 12:08:35 +0000
Subject: [issue26739] idle: Errno 10035 a non-blocking socket operation could
 not be completed immediately
In-Reply-To: <1460409859.89.0.789703447955.issue26739@psf.upfronthosting.co.za>
Message-ID: <1461586115.54.0.00812267217862.issue26739@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

I think that the select.select calls there are a red herring, since I see no evidence that the rpc socket is ever put in non-blocking mode.
But the line
self.rpcclt.listening_sock.settimeout(10)
indicates that the socket is in timeout mode, and so, the error could be expected if it weren't for the backported fix for issue #9090

I'll have another look at that code and see if thera are any loopholes.

Also, Micahel could try commenting out this line in 
C:\Python27\Lib\idlelib\PyShell.py:
 self.rpcclt.listening_sock.settimeout(10)

and see if the problem goes away.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26739>
_______________________________________

From report at bugs.python.org  Mon Apr 25 09:27:34 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 Apr 2016 13:27:34 +0000
Subject: [issue26249] Change PyMem_Malloc to use pymalloc allocator
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <1461590854.38.0.859765372127.issue26249@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

68b2a43d8653 introduced memory leak.

$ ./python -m test.regrtest -uall -R : test_format
Run tests sequentially
0:00:00 [1/1] test_format
beginning 9 repetitions
123456789
.........
test_format leaked [6, 7, 7, 7] memory blocks, sum=27
1 test failed:
    test_format
Total duration: 0:00:01

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26249>
_______________________________________

From report at bugs.python.org  Mon Apr 25 09:56:21 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 25 Apr 2016 13:56:21 +0000
Subject: [issue26804] Prioritize lowercase proxy variables in urllib.request
In-Reply-To: <1461053909.86.0.0123928931795.issue26804@psf.upfronthosting.co.za>
Message-ID: <1461592581.46.0.460048884742.issue26804@psf.upfronthosting.co.za>


Martin Panter added the comment:

V7 looks good to me

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26804>
_______________________________________

From report at bugs.python.org  Mon Apr 25 10:35:26 2016
From: report at bugs.python.org (Eric Snow)
Date: Mon, 25 Apr 2016 14:35:26 +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: <1461594926.53.0.235857316459.issue23496@psf.upfronthosting.co.za>


Eric Snow added the comment:

FYI: https://mail.python.org/pipermail/python-dev/2016-April/144320.html

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Mon Apr 25 10:52:16 2016
From: report at bugs.python.org (Yolanda)
Date: Mon, 25 Apr 2016 14:52:16 +0000
Subject: [issue26807] mock_open()().readline() fails at EOF
In-Reply-To: <1461140283.7.0.219960203136.issue26807@psf.upfronthosting.co.za>
Message-ID: <1461595936.84.0.920210951296.issue26807@psf.upfronthosting.co.za>


Yolanda added the comment:

diff --git a/Lib/unittest/test/testmock/testwith.py b/Lib/unittest/test/testmock/testwith.py
index a7bee73..efe6391 100644
--- a/Lib/unittest/test/testmock/testwith.py
+++ b/Lib/unittest/test/testmock/testwith.py
@@ -297,5 +297,16 @@ class TestMockOpen(unittest.TestCase):
         self.assertEqual(handle.readline(), 'bar')
 
 
+    def test_readlines_after_eof(self):
+        # Check that readlines does not fail after the end of file
+        mock = mock_open(read_data='foo')
+        with patch('%s.open' % __name__, mock, create=True):
+            h = open('bar')
+            h.read()
+            h.read()
+            data = h.readlines()
+            self.assertEqual(data, [])
+
+
 if __name__ == '__main__':
     unittest.main()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26807>
_______________________________________

From report at bugs.python.org  Mon Apr 25 11:16:37 2016
From: report at bugs.python.org (Wenzel Jakob)
Date: Mon, 25 Apr 2016 15:16:37 +0000
Subject: [issue26154] Add private _PyThreadState_UncheckedGet() to get the
 current thread state
In-Reply-To: <1453206633.27.0.0623775421981.issue26154@psf.upfronthosting.co.za>
Message-ID: <1461597397.24.0.767932061156.issue26154@psf.upfronthosting.co.za>


Wenzel Jakob added the comment:

I've also run into this regression. FWIW this is what I've ended up using to work around it (it's a mess, but what are we to do..)

#if PY_VERSION_HEX >= 0x03050000 && PY_VERSION_HEX < 0x03050200
extern "C" {
    /* Manually import _PyThreadState_Current symbol */
    struct _Py_atomic_address { void *value; };
    PyAPI_DATA(_Py_atomic_address) _PyThreadState_Current;
};
#endif

PyThreadState *get_thread_state_unchecked() {
#if   PY_VERSION_HEX < 0x03000000
    return _PyThreadState_Current;
#elif PY_VERSION_HEX < 0x03050000
    return (PyThreadState*) _Py_atomic_load_relaxed(&_PyThreadState_Current);
#elif PY_VERSION_HEX < 0x03050200
    return (PyThreadState*) _PyThreadState_Current.value;
#else
    return _PyThreadState_UncheckedGet();
#endif
}

----------
nosy: +wenzel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26154>
_______________________________________

From report at bugs.python.org  Mon Apr 25 11:18:51 2016
From: report at bugs.python.org (Joseph Hackman)
Date: Mon, 25 Apr 2016 15:18:51 +0000
Subject: [issue25788] fileinput.hook_encoded has no way to pass arguments to
 codecs
In-Reply-To: <1449160890.79.0.711012524776.issue25788@psf.upfronthosting.co.za>
Message-ID: <1461597531.77.0.486535267208.issue25788@psf.upfronthosting.co.za>


Joseph Hackman added the comment:

Ping.

Just wondering if anyone on the nosy list would be willing to help review my patch. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25788>
_______________________________________

From report at bugs.python.org  Mon Apr 25 11:35:44 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Apr 2016 15:35:44 +0000
Subject: [issue26804] Prioritize lowercase proxy variables in urllib.request
In-Reply-To: <1461053909.86.0.0123928931795.issue26804@psf.upfronthosting.co.za>
Message-ID: <20160425153450.51707.68232.8B1A8C34@psf.io>


Roundup Robot added the comment:

New changeset 49b975122022 by Senthil Kumaran in branch '3.5':
Issue #26804: urllib.request will prefer lower_case proxy environment variables
https://hg.python.org/cpython/rev/49b975122022

New changeset 316593f5bf73 by Senthil Kumaran in branch 'default':
merge 3.5
https://hg.python.org/cpython/rev/316593f5bf73

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26804>
_______________________________________

From report at bugs.python.org  Mon Apr 25 11:42:43 2016
From: report at bugs.python.org (Robert Collins)
Date: Mon, 25 Apr 2016 15:42:43 +0000
Subject: [issue26807] mock_open()().readline() fails at EOF
In-Reply-To: <1461140283.7.0.219960203136.issue26807@psf.upfronthosting.co.za>
Message-ID: <1461598963.38.0.258648874632.issue26807@psf.upfronthosting.co.za>


Robert Collins added the comment:

Thanks Yolanda. I've touched up the test a little and run a full test run (make test) - sadly it fails: there is an explicit test that StopIteration gets raised if you set it as a side effect.


======================================================================
FAIL: test_mock_open_after_eof (unittest.test.testmock.testmock.MockTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/robertc/work/cpython-3.5.hg/Lib/unittest/test/testmock/test                                      mock.py", line 1428, in test_mock_open_after_eof
    self.assertEqual('', h.readline())
AssertionError: '' != None

======================================================================
FAIL: test_side_effect_iterator (unittest.test.testmock.testmock.MockTest                                      )
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/robertc/work/cpython-3.5.hg/Lib/unittest/test/testmock/test                                      mock.py", line 980, in test_side_effect_iterator
    self.assertRaises(StopIteration, mock)
AssertionError: StopIteration not raised by <Mock id='140302027307384'>

======================================================================
FAIL: test_side_effect_setting_iterator (unittest.test.testmock.testmock.                                      MockTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/robertc/work/cpython-3.5.hg/Lib/unittest/test/testmock/test                                      mock.py", line 1015, in test_side_effect_setting_iterator
    self.assertRaises(StopIteration, mock)
AssertionError: StopIteration not raised by <Mock id='140302027307720'>

----------------------------------------------------------------------
Ran 705 tests in 1.251s

FAILED (failures=3, skipped=3)

Of those, I think the first failure is a bug in the patch; the second and third are genuine failures - you'll need to make your change in mock_open itself, not in 'mock'.

I've attached an updated patch which has ACKS, NEWS filled out and tweaked your test to be more comprehensive.

----------
keywords: +patch
Added file: http://bugs.python.org/file42590/issue26807.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26807>
_______________________________________

From report at bugs.python.org  Mon Apr 25 11:52:08 2016
From: report at bugs.python.org (Yolanda)
Date: Mon, 25 Apr 2016 15:52:08 +0000
Subject: [issue26807] mock_open()().readline() fails at EOF
In-Reply-To: <1461140283.7.0.219960203136.issue26807@psf.upfronthosting.co.za>
Message-ID: <1461599528.9.0.402167145136.issue26807@psf.upfronthosting.co.za>


Yolanda added the comment:

So... the failures are because i'm capturing the StopIteration exception in that case. then it's normal that it's not raised. How should you solve that problem instead?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26807>
_______________________________________

From report at bugs.python.org  Mon Apr 25 12:03:20 2016
From: report at bugs.python.org (Robert Collins)
Date: Mon, 25 Apr 2016 16:03:20 +0000
Subject: [issue26807] mock_open()().readline() fails at EOF
In-Reply-To: <1461140283.7.0.219960203136.issue26807@psf.upfronthosting.co.za>
Message-ID: <1461600200.07.0.284585415648.issue26807@psf.upfronthosting.co.za>


Robert Collins added the comment:

You're changing _mock_call but readline is actually implemented in _readline_side_effect - just changing that should be all thats needed (to deal with StopIteration). You will however need to fixup the return values since the test I added is a bit wider than just the single defect you uncovered.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26807>
_______________________________________

From report at bugs.python.org  Mon Apr 25 12:17:34 2016
From: report at bugs.python.org (cowlicks)
Date: Mon, 25 Apr 2016 16:17:34 +0000
Subject: [issue19251] bitwise ops for bytes of equal length
In-Reply-To: <1381694847.24.0.709324715816.issue19251@psf.upfronthosting.co.za>
Message-ID: <1461601054.83.0.464424357477.issue19251@psf.upfronthosting.co.za>


cowlicks added the comment:

To reiterate, this issue would make more readable, secure, and speed up a lot of code.

The concerns about this being a numpy-like vector operation are confusing to me. The current implementation is already vector-like, but lacks size checking. Isn't "int ^ int" really just the xor of two arbitrarily long arrays of binary data? At least with "bytes ^ bytes" we can enforce the arrays be the same size.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19251>
_______________________________________

From report at bugs.python.org  Mon Apr 25 12:18:03 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Apr 2016 16:18:03 +0000
Subject: [issue26804] Prioritize lowercase proxy variables in urllib.request
In-Reply-To: <1461053909.86.0.0123928931795.issue26804@psf.upfronthosting.co.za>
Message-ID: <20160425161759.4124.41650.9E529527@psf.io>


Roundup Robot added the comment:

New changeset c502deb19cb0 by Senthil Kumaran in branch '2.7':
backport fix for Issue #26804.
https://hg.python.org/cpython/rev/c502deb19cb0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26804>
_______________________________________

From report at bugs.python.org  Mon Apr 25 12:18:48 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 25 Apr 2016 16:18:48 +0000
Subject: [issue26804] Prioritize lowercase proxy variables in urllib.request
In-Reply-To: <1461053909.86.0.0123928931795.issue26804@psf.upfronthosting.co.za>
Message-ID: <1461601128.86.0.458743143603.issue26804@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

This is fixed in all versions of Python.

Thank you for your contribution, Hans-Peter Jansen.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26804>
_______________________________________

From report at bugs.python.org  Mon Apr 25 12:24:12 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Apr 2016 16:24:12 +0000
Subject: [issue19251] bitwise ops for bytes of equal length
In-Reply-To: <1381694847.24.0.709324715816.issue19251@psf.upfronthosting.co.za>
Message-ID: <1461601452.99.0.283258201549.issue19251@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I like to add the bitwise protocol between byte objects of equal length

Would it make sense to add such operators in a new module like the existing (but deprecated) audioop module?

If yes, maybe we should start with a module on PyPI. Is there a volunteer to try this option?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19251>
_______________________________________

From report at bugs.python.org  Mon Apr 25 12:27:38 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 25 Apr 2016 16:27:38 +0000
Subject: [issue19251] bitwise ops for bytes of equal length
In-Reply-To: <1461601054.83.0.464424357477.issue19251@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLvfvwtcn7YzkVgf+HVjOprmiRj3KupATsfzQ2mFj5-0g@mail.gmail.com>


Guido van Rossum added the comment:

Can you point to some examples of existing code that would become more
readable and faster when this feature exists? Separately, how is it more
secure?

On Mon, Apr 25, 2016 at 9:17 AM, cowlicks <report at bugs.python.org> wrote:

>
> cowlicks added the comment:
>
> To reiterate, this issue would make more readable, secure, and speed up a
> lot of code.
>
> The concerns about this being a numpy-like vector operation are confusing
> to me. The current implementation is already vector-like, but lacks size
> checking. Isn't "int ^ int" really just the xor of two arbitrarily long
> arrays of binary data? At least with "bytes ^ bytes" we can enforce the
> arrays be the same size.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue19251>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19251>
_______________________________________

From report at bugs.python.org  Mon Apr 25 12:50:49 2016
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 25 Apr 2016 16:50:49 +0000
Subject: [issue26844] Wrong error message during import
In-Reply-To: <1461564546.15.0.190869698481.issue26844@psf.upfronthosting.co.za>
Message-ID: <1461603049.58.0.302930450867.issue26844@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/issue26844>
_______________________________________

From report at bugs.python.org  Mon Apr 25 13:08:47 2016
From: report at bugs.python.org (Edward Segall)
Date: Mon, 25 Apr 2016 17:08:47 +0000
Subject: [issue26842] Python Tutorial 4.7.1: Need to explain default parameter
 lifetime
In-Reply-To: <1461540442.59.0.34324123093.issue26842@psf.upfronthosting.co.za>
Message-ID: <1461604127.51.0.101130929166.issue26842@psf.upfronthosting.co.za>


Edward Segall added the comment:

I agree with most of your points: A tutorial should be brief and should not go down rabbit holes. Expanded discussion of default parameter behavior would probably fit better with the other facets of parameter speceification and parameter passing, perhaps as a FAQ. 

But I also believe a change to the current presentation is needed. Perhaps it would be best to introduce default arguments using simple numerical types, and refer to a separate explanation (perhaps as a FAQ) of the complexities associated with using mutable objects as defaults. 

> Also, I don't really like the provided explanation, "there are two cases ...".  The actual execution model has one case (default arguments are evaluated once when the function is defined) and there are many ways to use it.

The distinction between the two cases lies in storage of the result, not in argument evaluation. In the non-default case, the result is stored in a caller-provided object, while in the default case, the result is stored in a callee-provided object. This results in different behaviors (as the example makes clear); hence the two cases are not the same. 

This distinction is important to new users because it's necessary to think of them differently, and because (to me, at least) one of them is very non-intuitive. In both cases, the change made to the object is a side effect of the function. In the non-default case, this side effect is directly visible to the caller, but in the default case, it is only indirectly visible. 

Details like this are probably obvious to people who are very familiar with both call by object reference and to Python's persistent lifetime of default argument objects, but I don't think that group fits the target audience for a tutorial.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26842>
_______________________________________

From report at bugs.python.org  Mon Apr 25 13:29:41 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 25 Apr 2016 17:29:41 +0000
Subject: [issue19251] bitwise ops for bytes of equal length
In-Reply-To: <1381694847.24.0.709324715816.issue19251@psf.upfronthosting.co.za>
Message-ID: <1461605381.45.0.976384880505.issue19251@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

I have wanted bytes/bytearray bit operations (be sure to include the in place operators for bytearray) when using micropython where it is normal to be operating on binary data.

that said, i'd need someone from micropython to chime in as to if they can magically detect
 # Equivalent of:  c = b ^ a
 c = bytes(x ^ y for x, y in zip(a, b))
and make it run fast.

what is a similar expression for an in place bytearray modification?
 # Equivalent of:  a ^= b
 assert len(a) == len(b)
 for i, b_i in enumerate(b): a[i] ^= b_i  ?

Why both of the above are slow is obvious: tons of work looping within python itself, creating and destroying small integers and/or tuples the entire time instead of deferring to the optimal loop in C.

Neither of the above "look as nice" as a simple operator would.
But they are at least both understandable and frankly about the same as what you would naively write in C for the task.

Security claims?  Nonsense. This has nothing to do with security.  It is *fundamentally impossible* to write constant time side channel attack resistant algorithms in a high level garbage collected language. Do not attempt it.  Leave that stuff to assembler or _very_ carefully crafted C/C++ that the compiler cannot undo constant time enforcing tricks in.  Where it belongs.  Python will never make such guarantees.

NumPy?  No.  That is a huge bloated dependency.  It is not relevant to this as we are not doing scientific computing.  It is not available everywhere.

The int.from_bytes(...) variant optimizations?  Those are hacks that might be useful to people in CPython today, but they are much less readable.  Do not write that in polite code, hide it behind a function with a comment explaining why it's so ugly to anyone who dares look inside please.

So as much as I'd love this feature to exist on bytes & bytearray, it is not a big deal that it does not.

Starting with a PyPI module for fast bit operations on bytes & bytearray objects makes more sense (include both pure python and a C extension implementation).  Use of that will give an idea of how often anyone actually wants to do this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19251>
_______________________________________

From report at bugs.python.org  Mon Apr 25 13:41:09 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 25 Apr 2016 17:41:09 +0000
Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux
In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za>
Message-ID: <1461606069.33.0.736944727017.issue9998@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

> Does anyone have any valid use cases where they want to use a shared library on LD_LIBRARY_PATH or similar

I presume that would include this issue's creator and other people who have commented here about what they see as a drawback in find_library's current behaviour.

Pau Tallada's point about wanting to use a cross-platform invocation also seems reasonable. Remember, if you know the exact library you want to use, you don't *need* find_library: and this issue is about making find_library useful in a wider set of cases than it currently is.

> The problem I see with using find_library() to blindly load a library

Nobody is saying that the result of find_library() has to be used to blindly load a library. The point you make about the code in the uuid module is orthogonal to the proposal in this issue - even the behaviour of find_library never changed, that code could break for the reasons you give. For that, it's not unreasonable to raise a separate issue about possible fragility of the code in uuid.

I asked a question which I think is relevant to this enhancement request - "is emulating a build-time linker the most useful thing? In the context of Python binding to external libraries, why is build-time linking behaviour better than run-time linking behaviour?"

Do you have an answer to that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9998>
_______________________________________

From report at bugs.python.org  Mon Apr 25 14:00:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 Apr 2016 18:00:46 +0000
Subject: [issue19251] bitwise ops for bytes of equal length
In-Reply-To: <1381694847.24.0.709324715816.issue19251@psf.upfronthosting.co.za>
Message-ID: <1461607246.49.0.364462435646.issue19251@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> If yes, maybe we should start with a module on PyPI. Is there a volunteer to try this option?

bitsets ? ordered subsets over a predefined domain
bitarray ? efficient boolean array implemented as C extension
bitstring ? pure-Python bit string based on bytearray
BitVector ? pure-Python bit array based on unsigned short array
Bitsets ? Cython interface to fast bitsets in Sage
bitfield ? Cython positive integer sets
intbitset ? integer bit sets as C extension

Is it enough? Ah, and NumPy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19251>
_______________________________________

From report at bugs.python.org  Mon Apr 25 15:05:34 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 Apr 2016 19:05:34 +0000
Subject: [issue25788] fileinput.hook_encoded has no way to pass arguments to
 codecs
In-Reply-To: <1449160890.79.0.711012524776.issue25788@psf.upfronthosting.co.za>
Message-ID: <1461611134.15.0.298571393931.issue25788@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added comments on Rietveld (follow the "review" link beside the patch link).

----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25788>
_______________________________________

From report at bugs.python.org  Mon Apr 25 15:09:35 2016
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 25 Apr 2016 19:09:35 +0000
Subject: [issue20305] Android's incomplete locale.h implementation prevents
 cross-compilation
In-Reply-To: <1390155202.76.0.360148898057.issue20305@psf.upfronthosting.co.za>
Message-ID: <1461611375.59.0.0863065585745.issue20305@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Thank you, closing this.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20305>
_______________________________________

From report at bugs.python.org  Mon Apr 25 15:17:11 2016
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 25 Apr 2016 19:17:11 +0000
Subject: [issue17905] Add check for locale.h
In-Reply-To: <1367676553.24.0.0475219885835.issue17905@psf.upfronthosting.co.za>
Message-ID: <1461611831.35.0.402548539314.issue17905@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Okay, closing as a duplicate (the second patch here that checks for
locale.h seems too broad to me since it's a standard header).

----------
nosy: +skrah
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Interpreter fails in initialize on systems where HAVE_LANGINFO_H is undefined
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17905>
_______________________________________

From report at bugs.python.org  Mon Apr 25 15:39:24 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Apr 2016 19:39:24 +0000
Subject: [issue17905] Add check for locale.h
In-Reply-To: <1367676553.24.0.0475219885835.issue17905@psf.upfronthosting.co.za>
Message-ID: <20160425193908.111110.454.D5314612@psf.io>


Roundup Robot added the comment:

New changeset cc501d439239 by Stefan Krah in branch 'default':
Issue #17905: Do not guard locale include with HAVE_LANGINFO_H.
https://hg.python.org/cpython/rev/cc501d439239

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17905>
_______________________________________

From report at bugs.python.org  Mon Apr 25 15:43:12 2016
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 25 Apr 2016 19:43:12 +0000
Subject: [issue17905] Add check for locale.h
In-Reply-To: <1367676553.24.0.0475219885835.issue17905@psf.upfronthosting.co.za>
Message-ID: <1461613392.17.0.413437549251.issue17905@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I think all locale includes are unguarded now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17905>
_______________________________________

From report at bugs.python.org  Mon Apr 25 15:56:07 2016
From: report at bugs.python.org (ProgVal)
Date: Mon, 25 Apr 2016 19:56:07 +0000
Subject: [issue26845] Misleading variable name in exception handling
Message-ID: <1461614167.42.0.470146541912.issue26845@psf.upfronthosting.co.za>


New submission from ProgVal:

In Python/errors.c, PyErr_Restore is defined this way:

void
PyErr_Restore(PyObject *type, PyObject *value, PyObject *traceback)


In Python/ceval.c, in the END_FINALLY case, it is called like this:

PyErr_Restore(status, exc, tb);


I believe ?exc? should be renamed to ?val?.


Indeed, END_FINALLY pops values from the stack like this:

PyObject *status = POP();
// ...
else if (PyExceptionClass_Check(status)) {
     PyObject *exc = POP();
     PyObject *tb = POP();
     PyErr_Restore(status, exc, tb);


And, they are pushed like this, in fast_block_end:

PUSH(tb);
PUSH(val);
PUSH(exc);

----------
components: Interpreter Core
messages: 264198
nosy: Valentin.Lorentz
priority: normal
severity: normal
status: open
title: Misleading variable name in exception handling
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26845>
_______________________________________

From report at bugs.python.org  Mon Apr 25 16:03:07 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 25 Apr 2016 20:03:07 +0000
Subject: [issue26833] returning ctypes._SimpleCData objects from callbacks
In-Reply-To: <1461400325.28.0.01385438687.issue26833@psf.upfronthosting.co.za>
Message-ID: <1461614587.49.0.578095336283.issue26833@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
components: +ctypes
nosy: +amaury.forgeotdarc, belopolsky, meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26833>
_______________________________________

From report at bugs.python.org  Mon Apr 25 16:47:32 2016
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 25 Apr 2016 20:47:32 +0000
Subject: [issue26846] Workaround for non-standard stdlib.h on Android
Message-ID: <1461617252.68.0.745100271283.issue26846@psf.upfronthosting.co.za>


New submission from Stefan Krah:

Android's stdlib.h pollutes the namespace by including a memory.h header.

----------
assignee: skrah
components: Build
messages: 264199
nosy: skrah, xdegaye
priority: normal
severity: normal
status: open
title: Workaround for non-standard stdlib.h on Android
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26846>
_______________________________________

From report at bugs.python.org  Mon Apr 25 16:49:49 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Apr 2016 20:49:49 +0000
Subject: [issue26846] Workaround for non-standard stdlib.h on Android
In-Reply-To: <1461617252.68.0.745100271283.issue26846@psf.upfronthosting.co.za>
Message-ID: <20160425204931.41395.70945.1233FEB9@psf.io>


Roundup Robot added the comment:

New changeset fae01d14dd4e by Stefan Krah in branch 'default':
Issue #26846: Workaround for non-standard stdlib.h on Android.
https://hg.python.org/cpython/rev/fae01d14dd4e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26846>
_______________________________________

From report at bugs.python.org  Mon Apr 25 16:57:03 2016
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 25 Apr 2016 20:57:03 +0000
Subject: [issue26846] Workaround for non-standard stdlib.h on Android
In-Reply-To: <1461617252.68.0.745100271283.issue26846@psf.upfronthosting.co.za>
Message-ID: <1461617823.67.0.304633021837.issue26846@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan at bytereef.org>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26846>
_______________________________________

From report at bugs.python.org  Mon Apr 25 17:19:06 2016
From: report at bugs.python.org (Martin Dengler)
Date: Mon, 25 Apr 2016 21:19:06 +0000
Subject: [issue9400] multiprocessing.pool.AsyncResult.get() messes up
 exceptions
In-Reply-To: <1280333027.17.0.112361474517.issue9400@psf.upfronthosting.co.za>
Message-ID: <1461619146.63.0.684249975884.issue9400@psf.upfronthosting.co.za>


Changes by Martin Dengler <martin at martindengler.com>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9400>
_______________________________________

From report at bugs.python.org  Mon Apr 25 19:10:39 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Apr 2016 23:10:39 +0000
Subject: [issue20306] Lack of pw_gecos field in Android's struct passwd causes
 cross-compilation for the pwd module to fail
In-Reply-To: <1390155821.88.0.335321844624.issue20306@psf.upfronthosting.co.za>
Message-ID: <20160425231036.30179.30836.5003A09A@psf.io>


Roundup Robot added the comment:

New changeset 0d74d4937ab9 by Stefan Krah in branch 'default':
Issue #20306: The pw_gecos and pw_passwd fields are not required by POSIX.
https://hg.python.org/cpython/rev/0d74d4937ab9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20306>
_______________________________________

From report at bugs.python.org  Mon Apr 25 19:57:11 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Apr 2016 23:57:11 +0000
Subject: [issue22747] Interpreter fails in initialize on systems where
 HAVE_LANGINFO_H is undefined
In-Reply-To: <1414445408.19.0.175857050886.issue22747@psf.upfronthosting.co.za>
Message-ID: <20160425235705.71149.98953.25A35419@psf.io>


Roundup Robot added the comment:

New changeset ad6be34ce8c9 by Stefan Krah in branch 'default':
Issue #22747: Workaround for systems without langinfo.h.
https://hg.python.org/cpython/rev/ad6be34ce8c9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22747>
_______________________________________

From report at bugs.python.org  Mon Apr 25 20:00:36 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Apr 2016 00:00:36 +0000
Subject: [issue22747] Interpreter fails in initialize on systems where
 HAVE_LANGINFO_H is undefined
In-Reply-To: <1414445408.19.0.175857050886.issue22747@psf.upfronthosting.co.za>
Message-ID: <1461628836.0.0.0827754067819.issue22747@psf.upfronthosting.co.za>


Stefan Krah added the comment:

We don't support Android officially yet, but I think until #8610
is resolved something must be done here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22747>
_______________________________________

From report at bugs.python.org  Mon Apr 25 20:04:14 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Apr 2016 00:04:14 +0000
Subject: [issue20306] Lack of pw_gecos field in Android's struct passwd causes
 cross-compilation for the pwd module to fail
In-Reply-To: <1390155821.88.0.335321844624.issue20306@psf.upfronthosting.co.za>
Message-ID: <1461629054.77.0.658498670112.issue20306@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan at bytereef.org>:


----------
assignee:  -> skrah
components: +Build -Cross-Build
nosy: +skrah
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.6 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20306>
_______________________________________

From report at bugs.python.org  Mon Apr 25 21:53:35 2016
From: report at bugs.python.org (Anthony Sottile)
Date: Tue, 26 Apr 2016 01:53:35 +0000
Subject: [issue16662] load_tests not invoked in package/__init__.py
In-Reply-To: <1355217291.85.0.41912767842.issue16662@psf.upfronthosting.co.za>
Message-ID: <1461635615.03.0.305445742232.issue16662@psf.upfronthosting.co.za>


Anthony Sottile added the comment:

I have a hunch that this fix here may be causing this: https://github.com/spotify/dh-virtualenv/issues/148

Minimally:

echo 'from setuptools import setup; setup(name="demo")' > setup.py
echo 'import pytest' > tests/__init__.py

$ python setup.py test
running test
running egg_info
writing dependency_links to demo.egg-info/dependency_links.txt
writing demo.egg-info/PKG-INFO
writing top-level names to demo.egg-info/top_level.txt
reading manifest file 'demo.egg-info/SOURCES.txt'
writing manifest file 'demo.egg-info/SOURCES.txt'
running build_ext

----------------------------------------------------------------------
Ran 0 tests in 0.000s

OK


$ python3.5 setup.py test
running test
running egg_info
writing demo.egg-info/PKG-INFO
writing dependency_links to demo.egg-info/dependency_links.txt
writing top-level names to demo.egg-info/top_level.txt
reading manifest file 'demo.egg-info/SOURCES.txt'
writing manifest file 'demo.egg-info/SOURCES.txt'
running build_ext
tests (unittest.loader._FailedTest) ... ERROR

======================================================================
ERROR: tests (unittest.loader._FailedTest)
----------------------------------------------------------------------
ImportError: Failed to import test module: tests
Traceback (most recent call last):
  File "/usr/lib/python3.5/unittest/loader.py", line 462, in _find_test_path
    package = self._get_module_from_name(name)
  File "/usr/lib/python3.5/unittest/loader.py", line 369, in _get_module_from_name
    __import__(name)
  File "/tmp/foo/tests/__init__.py", line 1, in <module>
    import pytest
ImportError: No module named 'pytest'


----------------------------------------------------------------------
Ran 1 test in 0.000s

FAILED (errors=1)

----------
nosy: +Anthony Sottile

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16662>
_______________________________________

From report at bugs.python.org  Mon Apr 25 22:29:45 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 26 Apr 2016 02:29:45 +0000
Subject: [issue26039] More flexibility in zipfile write interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1461637785.66.0.922809287657.issue26039@psf.upfronthosting.co.za>


Martin Panter added the comment:

I understand Python?s zipfile module does not allow reading unless seek() is supported (this was one of ?????s complaints). So it is irrelevant whether we are writing.

I left a few comments, but it sounds like it is valid read and write at the same time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Mon Apr 25 23:15:40 2016
From: report at bugs.python.org (Luke)
Date: Tue, 26 Apr 2016 03:15:40 +0000
Subject: [issue26847] filter docs unclear wording
Message-ID: <1461640540.65.0.428299683802.issue26847@psf.upfronthosting.co.za>


New submission from Luke:

The current docs for both filter and itertools.filterfalse use the following wording (emphasis added):

all elements that are false are removed
returns the items that are false
This could be confusing for a new Python programmer, because the actual behaviour is that elements are equality-compared, not identity-compared.

Suggested wording: "are equal to False"

https://docs.python.org/3.5/library/functions.html#filter
https://docs.python.org/3.5/library/itertools.html#itertools.filterfalse

----------
assignee: docs at python
components: Documentation
messages: 264206
nosy: docs at python, unfamiliarplace
priority: normal
severity: normal
status: open
title: filter docs unclear wording
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26847>
_______________________________________

From report at bugs.python.org  Tue Apr 26 00:01:43 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 26 Apr 2016 04:01:43 +0000
Subject: [issue26847] filter docs unclear wording
In-Reply-To: <1461640540.65.0.428299683802.issue26847@psf.upfronthosting.co.za>
Message-ID: <1461643303.82.0.971813643764.issue26847@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

"are equal to False" would be wrong though. Any "falsy" value is preserved by filterfalse, and removed by filter. They need not be equal to False (the bool singleton); empty containers (e.g. (), [], {}, "") are all considered false, and behave as such, despite not being equal to False.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26847>
_______________________________________

From report at bugs.python.org  Tue Apr 26 00:02:24 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 26 Apr 2016 04:02:24 +0000
Subject: [issue26847] filter docs unclear wording
In-Reply-To: <1461640540.65.0.428299683802.issue26847@psf.upfronthosting.co.za>
Message-ID: <1461643344.18.0.507761925377.issue26847@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

That's why lower case "false" is used, not "False"; the former is the loose definition, the latter is the strict singleton.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26847>
_______________________________________

From report at bugs.python.org  Tue Apr 26 00:22:02 2016
From: report at bugs.python.org (Luke)
Date: Tue, 26 Apr 2016 04:22:02 +0000
Subject: [issue26847] filter docs unclear wording
In-Reply-To: <1461640540.65.0.428299683802.issue26847@psf.upfronthosting.co.za>
Message-ID: <1461644522.81.0.575078374949.issue26847@psf.upfronthosting.co.za>


Luke added the comment:

josh, we're saying the same thing but misunderstanding each other. :)

I realize that they can be empty containers, etc., and that's why I think "equal to False" is appropriate -- because those things *are* equal to False:

>>> [] == False
True
>>> 0 == False
True
etc.

However, they are not identical to False:

>>> [] is False
False
>>> 0 is False
False

And that's why I think the wording "are false" is potentially misleading.

Perhaps there's a better wording than "equal to False" (compares equivalently to False? or simply: are falsey? :p), but anyhow, we're identifying the same behaviour here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26847>
_______________________________________

From report at bugs.python.org  Tue Apr 26 00:24:42 2016
From: report at bugs.python.org (Luiz Poleto)
Date: Tue, 26 Apr 2016 04:24:42 +0000
Subject: [issue22234] urllib.parse.urlparse accepts any falsy value as an url
In-Reply-To: <1408538391.97.0.53072227801.issue22234@psf.upfronthosting.co.za>
Message-ID: <1461644682.64.0.375144823019.issue22234@psf.upfronthosting.co.za>


Luiz Poleto added the comment:

As discussed on the Mentors list, the attached patch (issue22234_36.patch) includes the deprecation warning (and related test) on the urlparse function.

----------
keywords: +patch
versions: +Python 3.6 -Python 3.4
Added file: http://bugs.python.org/file42591/issue22234_36.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22234>
_______________________________________

From report at bugs.python.org  Tue Apr 26 00:27:05 2016
From: report at bugs.python.org (Luiz Poleto)
Date: Tue, 26 Apr 2016 04:27:05 +0000
Subject: [issue22234] urllib.parse.urlparse accepts any falsy value as an url
In-Reply-To: <1408538391.97.0.53072227801.issue22234@psf.upfronthosting.co.za>
Message-ID: <1461644825.2.0.0524988850943.issue22234@psf.upfronthosting.co.za>


Luiz Poleto added the comment:

As discussed on the Mentors list, the attached patch (issue22234_37.patch) changes the urlparse function to handle non-str and non-bytes arguments and adds a new test case for it.

----------
Added file: http://bugs.python.org/file42592/issue22234_37.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22234>
_______________________________________

From report at bugs.python.org  Tue Apr 26 00:40:34 2016
From: report at bugs.python.org (Jack O'Connor)
Date: Tue, 26 Apr 2016 04:40:34 +0000
Subject: [issue26848] asyncio.subprocess's communicate() method mishandles
 empty input bytes
Message-ID: <1461645634.01.0.295749785908.issue26848@psf.upfronthosting.co.za>


New submission from Jack O'Connor:

Setting stdin=PIPE and then calling communicate(b"") should close the child's stdin immediately, similar to stdin=DEVNULL. Instead, communicate() treats b"" like None and leaves the child's stdin open, which makes the child hang forever if it tries to read anything.

I have a PR open with a fix and a test: https://github.com/python/cpython/pull/33

----------
components: asyncio
messages: 264212
nosy: gvanrossum, haypo, oconnor663, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.subprocess's communicate() method mishandles empty input bytes
type: behavior
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26848>
_______________________________________

From report at bugs.python.org  Tue Apr 26 00:59:55 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 26 Apr 2016 04:59:55 +0000
Subject: [issue26848] asyncio.subprocess's communicate() method mishandles
 empty input bytes
In-Reply-To: <1461645634.01.0.295749785908.issue26848@psf.upfronthosting.co.za>
Message-ID: <1461646795.69.0.0805038472739.issue26848@psf.upfronthosting.co.za>


Berker Peksag added the comment:

python/cpython is a semi-official read-only mirror of hg.python.org/cpython. We haven't switched to GitHub yet. You may want to open a pull request to https://github.com/python/asyncio See https://github.com/python/asyncio/wiki/Contributing for details.

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26848>
_______________________________________

From report at bugs.python.org  Tue Apr 26 01:24:35 2016
From: report at bugs.python.org (Jack O'Connor)
Date: Tue, 26 Apr 2016 05:24:35 +0000
Subject: [issue26848] asyncio.subprocess's communicate() method mishandles
 empty input bytes
In-Reply-To: <1461645634.01.0.295749785908.issue26848@psf.upfronthosting.co.za>
Message-ID: <1461648275.31.0.877716441952.issue26848@psf.upfronthosting.co.za>


Jack O'Connor added the comment:

Thanks for the heads up, Berker, I've re-submitted the PR as https://github.com/python/asyncio/pull/335.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26848>
_______________________________________

From report at bugs.python.org  Tue Apr 26 01:25:15 2016
From: report at bugs.python.org (Jack O'Connor)
Date: Tue, 26 Apr 2016 05:25:15 +0000
Subject: [issue26848] asyncio.subprocess's communicate() method mishandles
 empty input bytes
In-Reply-To: <1461645634.01.0.295749785908.issue26848@psf.upfronthosting.co.za>
Message-ID: <1461648315.57.0.326458433842.issue26848@psf.upfronthosting.co.za>


Jack O'Connor added the comment:

Related: The asyncio communicate() method differs from standard subprocess in how it treats input bytes when stdin is (probably mistakenly) not set to PIPE. Like this:

    proc = await create_subprocess_shell("sleep 5")
    await proc.communicate(b"foo")  # Oops, I forgot stdin=PIPE above!

The standard, non-async version of this example, communicate would ignore the input bytes entirely. But here in the asyncio version, communicate will try to write those bytes to stdin, which is None, and the result is an AttributeError.

Since the user probably only hits this case by mistake, I think raising an exception is preferable. But it would be nice to raise an exception that explicitly said "you've forgotten stdin=PIPE" instead of the unhelpful "'NoneType' object has no attribute 'write'". Maybe it would be worth cleaning this up while we're here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26848>
_______________________________________

From report at bugs.python.org  Tue Apr 26 01:44:46 2016
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 26 Apr 2016 05:44:46 +0000
Subject: [issue26847] filter docs unclear wording
In-Reply-To: <1461640540.65.0.428299683802.issue26847@psf.upfronthosting.co.za>
Message-ID: <1461649486.44.0.626465176902.issue26847@psf.upfronthosting.co.za>


Georg Brandl added the comment:

You didn't test your examples:

>>> [] == False
False

False is not equal to the "empty value" of any other type than other numeric types.  (This is mostly because of how booleans were originally introduced to Python.)

"is false", on the other hand, is the conventional shorthand for `bool(x) == False`.

----------
nosy: +georg.brandl
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26847>
_______________________________________

From report at bugs.python.org  Tue Apr 26 01:55:15 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Apr 2016 05:55:15 +0000
Subject: [issue22234] urllib.parse.urlparse accepts any falsy value as an url
In-Reply-To: <1408538391.97.0.53072227801.issue22234@psf.upfronthosting.co.za>
Message-ID: <1461650115.29.0.695097803179.issue22234@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

`x != ''` emits BytesWarning if x is bytes. 'encode' attribute is not needed for URL parsing. any() is slower that a `for` loop.

I would suggest to look at efficient os.path implementations.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22234>
_______________________________________

From report at bugs.python.org  Tue Apr 26 02:12:53 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Apr 2016 06:12:53 +0000
Subject: [issue26634] recursive_repr forgets to override __qualname__ of
 wrapper
In-Reply-To: <1458792576.69.0.965727650976.issue26634@psf.upfronthosting.co.za>
Message-ID: <1461651173.15.0.724923088973.issue26634@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: rhettinger -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26634>
_______________________________________

From report at bugs.python.org  Tue Apr 26 02:13:37 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Apr 2016 06:13:37 +0000
Subject: [issue26809] `string` exposes ChainMap from `collections`
In-Reply-To: <1461152182.96.0.373784885739.issue26809@psf.upfronthosting.co.za>
Message-ID: <1461651217.19.0.186959556857.issue26809@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: rhettinger -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26809>
_______________________________________

From report at bugs.python.org  Tue Apr 26 02:14:15 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Apr 2016 06:14:15 +0000
Subject: [issue25243] decouple string-to-boolean logic from
 ConfigParser.getboolean and offer as separate function
In-Reply-To: <1443307220.16.0.776749230814.issue25243@psf.upfronthosting.co.za>
Message-ID: <1461651255.09.0.0956149011067.issue25243@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25243>
_______________________________________

From report at bugs.python.org  Tue Apr 26 02:15:01 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Apr 2016 06:15:01 +0000
Subject: [issue26512] Vocabulary: Using "integral" in library/stdtypes.html
In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>
Message-ID: <1461651301.98.0.951696343287.issue26512@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: rhettinger -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26512>
_______________________________________

From report at bugs.python.org  Tue Apr 26 02:31:37 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Apr 2016 06:31:37 +0000
Subject: [issue26634] recursive_repr forgets to override __qualname__ of
 wrapper
In-Reply-To: <1458792576.69.0.965727650976.issue26634@psf.upfronthosting.co.za>
Message-ID: <20160426063134.13089.72213.F409C296@psf.io>


Roundup Robot added the comment:

New changeset 1f0369547b0e by Serhiy Storchaka in branch '3.5':
Issue #26634: recursive_repr() now sets __qualname__ of wrapper.
https://hg.python.org/cpython/rev/1f0369547b0e

New changeset fb70ea8b7b2d by Serhiy Storchaka in branch 'default':
Issue #26634: recursive_repr() now sets __qualname__ of wrapper.
https://hg.python.org/cpython/rev/fb70ea8b7b2d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26634>
_______________________________________

From report at bugs.python.org  Tue Apr 26 02:32:05 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Apr 2016 06:32:05 +0000
Subject: [issue26634] recursive_repr forgets to override __qualname__ of
 wrapper
In-Reply-To: <1458792576.69.0.965727650976.issue26634@psf.upfronthosting.co.za>
Message-ID: <1461652325.48.0.0722749713139.issue26634@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26634>
_______________________________________

From report at bugs.python.org  Tue Apr 26 02:39:02 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 26 Apr 2016 06:39:02 +0000
Subject: [issue22234] urllib.parse.urlparse accepts any falsy value as an url
In-Reply-To: <1408538391.97.0.53072227801.issue22234@psf.upfronthosting.co.za>
Message-ID: <1461652742.61.0.787686488276.issue22234@psf.upfronthosting.co.za>


Martin Panter added the comment:

Luiz: Your _36 patch looks like it adds an unconditional warning whenever urlparse() is called, but I would have expected it to depend on the type of the ?url? parameter.

There are related functions that seem to accept false values like None in Python 3, but not in Python 2. Perhaps they should also be considered with any changes:

urlsplit(None)
parse_qs(None)
parse_qsl(None)
urldefrag(None)

Also, I wonder if we should continue to accept bytearray as well as bytes. Bytearray has a decode() method.

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22234>
_______________________________________

From report at bugs.python.org  Tue Apr 26 02:47:00 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Apr 2016 06:47:00 +0000
Subject: [issue24685] collections.OrderedDict collaborative subclassing
In-Reply-To: <1437584641.0.0.00317519120009.issue24685@psf.upfronthosting.co.za>
Message-ID: <1461653220.84.0.936054852918.issue24685@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Sorry Eric, I'm going to mark this as rejected.  IMO this amounts to twisting the implementation into knots without any real payoff.  I'm glad you enjoyed my Pycon talk and were inspired by it.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24685>
_______________________________________

From report at bugs.python.org  Tue Apr 26 02:55:06 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Apr 2016 06:55:06 +0000
Subject: [issue25823] Speed-up oparg decoding on little-endian machines
In-Reply-To: <1449567251.61.0.853791637694.issue25823@psf.upfronthosting.co.za>
Message-ID: <1461653706.19.0.278032298247.issue25823@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I there are no objections I'm inclined to push the patch in hope that this will make the Wordcode patch (issue26647) simpler and more efficient (yes, this will add more work for Demur for synchronization).

----------
nosy: +Demur Rumed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25823>
_______________________________________

From report at bugs.python.org  Tue Apr 26 03:10:08 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Apr 2016 07:10:08 +0000
Subject: [issue16394] Reducing tee() memory footprint
In-Reply-To: <1351955719.4.0.453680036148.issue16394@psf.upfronthosting.co.za>
Message-ID: <20160426071005.13103.6510.E9221192@psf.io>


Roundup Robot added the comment:

New changeset f09306f9fa6f by Raymond Hettinger in branch 'default':
Issue #16394:  Note the tee() pure python equivalent is only a rough approximation.
https://hg.python.org/cpython/rev/f09306f9fa6f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16394>
_______________________________________

From report at bugs.python.org  Tue Apr 26 03:11:17 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Apr 2016 07:11:17 +0000
Subject: [issue16394] Reducing tee() memory footprint
In-Reply-To: <1351955719.4.0.453680036148.issue16394@psf.upfronthosting.co.za>
Message-ID: <1461654677.77.0.331330341293.issue16394@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/issue16394>
_______________________________________

From report at bugs.python.org  Tue Apr 26 03:15:49 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Apr 2016 07:15:49 +0000
Subject: [issue23275] Can assign [] = (), but not () = []
In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za>
Message-ID: <1461654949.16.0.0759224877128.issue23275@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Martin, do you want to take it from here?

----------
assignee: rhettinger -> martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23275>
_______________________________________

From report at bugs.python.org  Tue Apr 26 03:37:22 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Apr 2016 07:37:22 +0000
Subject: [issue26842] Python Tutorial 4.7.1: Need to explain default parameter
 lifetime
In-Reply-To: <1461540442.59.0.34324123093.issue26842@psf.upfronthosting.co.za>
Message-ID: <1461656242.92.0.226127923921.issue26842@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Sorry but I'm going to reject this one.  I tried out the text on a Python class that I'm currently teaching and the learners found the text to be clear enough (though some were jarred by the choice of *L* as the variable name) and they all got the essential points (the default variable is evaluated once and what they should do if you don't want the default value to be shared between subsequent calls).

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26842>
_______________________________________

From report at bugs.python.org  Tue Apr 26 03:38:26 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 26 Apr 2016 07:38:26 +0000
Subject: [issue26512] Vocabulary: Using "integral" in library/stdtypes.html
In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>
Message-ID: <1461656306.39.0.469449051179.issue26512@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a v3 patch for Python 3, addressing everyone?s comments:

Fix the leftover table markup
Link math.trunc(x) etc syntax to the main documentation
Hide numbers module prefix from Integral class name
Change ?integral float? ? ~numbers.Integral
Add emphasis for *n* parameter
Change int ? Integral in doc strings

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file42593/stdtypes-integral.v3.py3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26512>
_______________________________________

From report at bugs.python.org  Tue Apr 26 03:38:58 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 26 Apr 2016 07:38:58 +0000
Subject: [issue26512] Vocabulary: Using "integral" in library/stdtypes.html
In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>
Message-ID: <1461656338.17.0.367707828908.issue26512@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


Removed file: http://bugs.python.org/file42593/stdtypes-integral.v3.py3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26512>
_______________________________________

From report at bugs.python.org  Tue Apr 26 03:39:20 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 26 Apr 2016 07:39:20 +0000
Subject: [issue26512] Vocabulary: Using "integral" in library/stdtypes.html
In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>
Message-ID: <1461656360.14.0.815964791664.issue26512@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


Added file: http://bugs.python.org/file42594/stdtypes-integral.v3.py3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26512>
_______________________________________

From report at bugs.python.org  Tue Apr 26 03:40:11 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 26 Apr 2016 07:40:11 +0000
Subject: [issue23275] Can assign [] = (), but not () = []
In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za>
Message-ID: <1461656411.1.0.0331125598176.issue23275@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I missed Martin's comment about the documentation. I will update my patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23275>
_______________________________________

From report at bugs.python.org  Tue Apr 26 03:50:41 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Apr 2016 07:50:41 +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: <1461657041.64.0.697800492294.issue25420@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

FWIW, the random.patch from matejcik makes me uncomfortable.  It feels like a hack that obscures the code, would confound linters and type checkers, and would create more problems than it would solve.

----------
assignee: rhettinger -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25420>
_______________________________________

From report at bugs.python.org  Tue Apr 26 03:51:47 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 26 Apr 2016 07:51:47 +0000
Subject: [issue26846] Workaround for non-standard stdlib.h on Android
In-Reply-To: <1461617252.68.0.745100271283.issue26846@psf.upfronthosting.co.za>
Message-ID: <1461657107.53.0.825118980554.issue26846@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Thanks.
Cross-compilation for android is fine now.
Tested with a run of test_decimal on android emulator.
Maybe issue #26723 can be closed now as well ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26846>
_______________________________________

From report at bugs.python.org  Tue Apr 26 03:55:47 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 26 Apr 2016 07:55:47 +0000
Subject: [issue20306] Lack of pw_gecos field in Android's struct passwd causes
 cross-compilation for the pwd module to fail
In-Reply-To: <1390155821.88.0.335321844624.issue20306@psf.upfronthosting.co.za>
Message-ID: <1461657347.32.0.372825156952.issue20306@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

With changeset 0d74d4937ab9, test_pwd fails on android API level 21 at test_values with:
  Traceback (most recent call last):
    File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_pwd.py", line 27, in test_values
      self.assertIsInstance(e.pw_passwd, str)
  AssertionError: None is not an instance of <class 'str'>

On android API 21 HAVE_STRUCT_PASSWD_PW_PASSWD is defined but p->pw_passwd is set to NULL.

----------
nosy: +xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20306>
_______________________________________

From report at bugs.python.org  Tue Apr 26 03:59:24 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Apr 2016 07:59:24 +0000
Subject: [issue23986] Inaccuracy about "in" keyword for list and tuple
In-Reply-To: <1429255378.08.0.140067438597.issue23986@psf.upfronthosting.co.za>
Message-ID: <20160426075921.13107.99784.5C1FD5D0@psf.io>


Roundup Robot added the comment:

New changeset aba647a34ed4 by Raymond Hettinger in branch '2.7':
Issue #23986:  Note that the in-operator for lists and tuples check identity before equality.
https://hg.python.org/cpython/rev/aba647a34ed4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23986>
_______________________________________

From report at bugs.python.org  Tue Apr 26 04:00:09 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Apr 2016 08:00:09 +0000
Subject: [issue16927] Separate built-in types from functions and group similar
 functions in functions.rst
In-Reply-To: <1357883404.71.0.215467038207.issue16927@psf.upfronthosting.co.za>
Message-ID: <1461657609.19.0.0408337133421.issue16927@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: rhettinger -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16927>
_______________________________________

From report at bugs.python.org  Tue Apr 26 04:00:31 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Apr 2016 08:00:31 +0000
Subject: [issue23986] Inaccuracy about "in" keyword for list and tuple
In-Reply-To: <1429255378.08.0.140067438597.issue23986@psf.upfronthosting.co.za>
Message-ID: <1461657631.25.0.750241851095.issue23986@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/issue23986>
_______________________________________

From report at bugs.python.org  Tue Apr 26 04:09:48 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Apr 2016 08:09:48 +0000
Subject: [issue24715] Sorting HOW TO: bad example for reverse sort stability
In-Reply-To: <1437817871.39.0.0442628081402.issue24715@psf.upfronthosting.co.za>
Message-ID: <20160426080937.122104.30523.AC2AA1BC@psf.io>


Roundup Robot added the comment:

New changeset ba87f7f246e0 by Raymond Hettinger in branch '2.7':
Issue #24715: Improve sort stability example
https://hg.python.org/cpython/rev/ba87f7f246e0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24715>
_______________________________________

From report at bugs.python.org  Tue Apr 26 04:11:35 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Apr 2016 08:11:35 +0000
Subject: [issue24715] Sorting HOW TO: bad example for reverse sort stability
In-Reply-To: <1437817871.39.0.0442628081402.issue24715@psf.upfronthosting.co.za>
Message-ID: <20160426081134.27739.76276.87980355@psf.io>


Roundup Robot added the comment:

New changeset ae1e55102449 by Raymond Hettinger in branch '3.5':
Issue #24715: Improve sort stability example
https://hg.python.org/cpython/rev/ae1e55102449

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24715>
_______________________________________

From report at bugs.python.org  Tue Apr 26 04:11:50 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Apr 2016 08:11:50 +0000
Subject: [issue24715] Sorting HOW TO: bad example for reverse sort stability
In-Reply-To: <1437817871.39.0.0442628081402.issue24715@psf.upfronthosting.co.za>
Message-ID: <1461658310.34.0.902446356992.issue24715@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/issue24715>
_______________________________________

From report at bugs.python.org  Tue Apr 26 04:14:22 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Apr 2016 08:14:22 +0000
Subject: [issue24434] ItemsView.__contains__ does not mimic dict_items
In-Reply-To: <1434050451.28.0.415875303865.issue24434@psf.upfronthosting.co.za>
Message-ID: <1461658462.97.0.221746246457.issue24434@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: rhettinger -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24434>
_______________________________________

From report at bugs.python.org  Tue Apr 26 04:18:17 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Apr 2016 08:18:17 +0000
Subject: [issue26822] itemgetter/attrgetter/methodcaller objects ignore
 keyword arguments
In-Reply-To: <1461266621.67.0.0664681491354.issue26822@psf.upfronthosting.co.za>
Message-ID: <1461658697.24.0.0696253122145.issue26822@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The patch looks good and is ready to apply.  The macro also is a fine idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26822>
_______________________________________

From report at bugs.python.org  Tue Apr 26 04:21:59 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 26 Apr 2016 08:21:59 +0000
Subject: [issue26512] Vocabulary: Using "integral" in library/stdtypes.html
In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>
Message-ID: <1461658919.3.0.394551032458.issue26512@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is the Python 2 version. The difference is that floor() and ceil() return an ?integer as a float?, and I didn?t touch the doc strings.

----------
Added file: http://bugs.python.org/file42595/stdtypes-integral.v3.py2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26512>
_______________________________________

From report at bugs.python.org  Tue Apr 26 04:22:04 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Apr 2016 08:22:04 +0000
Subject: [issue24296] Queue documentation note needed
In-Reply-To: <1432729321.3.0.0746320695027.issue24296@psf.upfronthosting.co.za>
Message-ID: <1461658924.76.0.624181352761.issue24296@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/issue24296>
_______________________________________

From report at bugs.python.org  Tue Apr 26 04:24:10 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Apr 2016 08:24:10 +0000
Subject: [issue26020] set_display evaluation order doesn't match documented
 behaviour
In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za>
Message-ID: <1461659050.46.0.620620857296.issue26020@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/issue26020>
_______________________________________

From report at bugs.python.org  Tue Apr 26 04:30:06 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Apr 2016 08:30:06 +0000
Subject: [issue25981] Intern namedtuple field names
In-Reply-To: <1451505939.05.0.983054710729.issue25981@psf.upfronthosting.co.za>
Message-ID: <1461659406.94.0.276793688614.issue25981@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> I think it would be better to change the compiler to always 
> intern short string literals. And patching namedtuple will 
> be not needed.

Can we close this entry?   If you do patch the compiler, a separate tracker item can be opened.

----------
assignee: rhettinger -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25981>
_______________________________________

From report at bugs.python.org  Tue Apr 26 04:39:11 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Apr 2016 08:39:11 +0000
Subject: [issue20663] Introduce exception argument to iter
In-Reply-To: <1392659027.56.0.320916972318.issue20663@psf.upfronthosting.co.za>
Message-ID: <1461659951.56.0.950914082244.issue20663@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I really don't think this is worth it.  In my programming career, I may have had an occasion to use this only once every few years.

----------
assignee: rhettinger -> 
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20663>
_______________________________________

From report at bugs.python.org  Tue Apr 26 04:49:27 2016
From: report at bugs.python.org (Yolanda)
Date: Tue, 26 Apr 2016 08:49:27 +0000
Subject: [issue26807] mock_open()().readline() fails at EOF
In-Reply-To: <1461140283.7.0.219960203136.issue26807@psf.upfronthosting.co.za>
Message-ID: <1461660567.69.0.551287131777.issue26807@psf.upfronthosting.co.za>


Yolanda added the comment:

I tried patching the readline_side_effect call. But i cannot trap StopIteration there, and i don't see any clear way to detect that the generator has reached its end at that level.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26807>
_______________________________________

From report at bugs.python.org  Tue Apr 26 04:51:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Apr 2016 08:51:12 +0000
Subject: [issue25981] Intern namedtuple field names
In-Reply-To: <1451505939.05.0.983054710729.issue25981@psf.upfronthosting.co.za>
Message-ID: <1461660672.74.0.167458789745.issue25981@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I already opened separate issue26148. Since I sure this is the correct way, I'm closing this issue. I'll reopen it in case of issue26148 will be rejected.

----------
superseder:  -> String literals are not interned if in a tuple

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25981>
_______________________________________

From report at bugs.python.org  Tue Apr 26 04:51:57 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Apr 2016 08:51:57 +0000
Subject: [issue25981] Intern namedtuple field names
In-Reply-To: <1451505939.05.0.983054710729.issue25981@psf.upfronthosting.co.za>
Message-ID: <1461660717.57.0.145164685521.issue25981@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25981>
_______________________________________

From report at bugs.python.org  Tue Apr 26 05:12:10 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Apr 2016 09:12:10 +0000
Subject: [issue26723] Add an option to skip _decimal module
In-Reply-To: <1460227200.51.0.75268683171.issue26723@psf.upfronthosting.co.za>
Message-ID: <1461661930.78.0.348853946839.issue26723@psf.upfronthosting.co.za>


Stefan Krah added the comment:

After #26846 _decimal builds on Android.

----------
resolution: rejected -> fixed
superseder:  -> Workaround for non-standard stdlib.h on Android

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26723>
_______________________________________

From report at bugs.python.org  Tue Apr 26 05:14:22 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Apr 2016 09:14:22 +0000
Subject: [issue26846] Workaround for non-standard stdlib.h on Android
In-Reply-To: <1461657107.53.0.825118980554.issue26846@psf.upfronthosting.co.za>
Message-ID: <20160426091410.GA4729@bytereef.org>


Stefan Krah added the comment:

> Maybe issue #26723 can be closed now as well ?

I think it was already closed, but I added a link to this issue now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26846>
_______________________________________

From report at bugs.python.org  Tue Apr 26 05:24:50 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 26 Apr 2016 09:24:50 +0000
Subject: [issue26849] android does not support versioning in SONAME
Message-ID: <1461662690.12.0.966004358302.issue26849@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

When python is cross-compiled for android with --enable-shared, the following error occurs:

# python -c "import socket"
Fatal Python error: PyThreadState_Get: no current thread

This also occurs when importing subprocess, asyncore or asyncio but not when importing posix (not a shared library).  This is fixed by building python without soname versioning, although I have no idea why a problem with the android loader would cause this error.
Patch attached.

Some references to the android loader and soname versioning:
    https://code.google.com/p/android/issues/detail?id=55868
    https://groups.google.com/forum/#!msg/android-ndk/_UhNpRJlA1k/hbryqzEgN94J

----------
components: Cross-Build
files: soname_versioning.patch
keywords: patch
messages: 264241
nosy: Alex.Willmer, xdegaye
priority: normal
severity: normal
status: open
title: android does not support versioning in SONAME
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file42596/soname_versioning.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26849>
_______________________________________

From report at bugs.python.org  Tue Apr 26 05:29:53 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2016 09:29:53 +0000
Subject: [issue26512] Vocabulary: Using "integral" in library/stdtypes.html
In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>
Message-ID: <1461662993.41.0.0413096777942.issue26512@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/issue26512>
_______________________________________

From report at bugs.python.org  Tue Apr 26 05:30:16 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Tue, 26 Apr 2016 09:30:16 +0000
Subject: [issue26039] More flexibility in zipfile write interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1461663016.4.0.30265198759.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

zipfile-open-w7 adds a test that Martin requested

----------
Added file: http://bugs.python.org/file42597/zipfile-open-w7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Tue Apr 26 05:43:35 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Apr 2016 09:43:35 +0000
Subject: [issue20306] Lack of pw_gecos field in Android's struct passwd causes
 cross-compilation for the pwd module to fail
In-Reply-To: <1390155821.88.0.335321844624.issue20306@psf.upfronthosting.co.za>
Message-ID: <20160426094332.27745.35887.505532EC@psf.io>


Roundup Robot added the comment:

New changeset f0f519aca558 by Stefan Krah in branch 'default':
Issue #20306:  Android is the only system that returns NULL for the pw_passwd
https://hg.python.org/cpython/rev/f0f519aca558

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20306>
_______________________________________

From report at bugs.python.org  Tue Apr 26 05:50:07 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Apr 2016 09:50:07 +0000
Subject: [issue20306] Lack of pw_gecos field in Android's struct passwd causes
 cross-compilation for the pwd module to fail
In-Reply-To: <1390155821.88.0.335321844624.issue20306@psf.upfronthosting.co.za>
Message-ID: <1461664207.0.0.202608932506.issue20306@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Okay, for the record: I think that returning "None" would probably be
more correct than the empty string, but I don't think users actually
care to the point that they will introduce a case split in their
applications.

Realistically, probably no one cares about pw_passwd at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20306>
_______________________________________

From report at bugs.python.org  Tue Apr 26 06:36:42 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Apr 2016 10:36:42 +0000
Subject: [issue26249] Change PyMem_Malloc to use pymalloc allocator
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <20160426103636.102818.69530.689273F3@psf.io>


Roundup Robot added the comment:

New changeset 090502a0c69c by Victor Stinner in branch 'default':
Issue #25349, #26249: Fix memleak in formatfloat()
https://hg.python.org/cpython/rev/090502a0c69c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26249>
_______________________________________

From report at bugs.python.org  Tue Apr 26 06:36:43 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Apr 2016 10:36:43 +0000
Subject: [issue25349] Use _PyBytesWriter for bytes%args
In-Reply-To: <1444351825.62.0.273684816362.issue25349@psf.upfronthosting.co.za>
Message-ID: <20160426103635.102818.25524.296F7E83@psf.io>


Roundup Robot added the comment:

New changeset 090502a0c69c by Victor Stinner in branch 'default':
Issue #25349, #26249: Fix memleak in formatfloat()
https://hg.python.org/cpython/rev/090502a0c69c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25349>
_______________________________________

From report at bugs.python.org  Tue Apr 26 06:43:24 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 26 Apr 2016 10:43:24 +0000
Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux
In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za>
Message-ID: <1461667404.31.0.691073001991.issue9998@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks Pau, for some reason I didn?t pick up the dylib OS X problem last time I looked at that link. This is a quick summary of the library names searched on different platforms:

Windows: {name} and {name}.dll, via %PATH%
OS X: lib{name}.dylib, {name}.dylib and {name}.framework/{name}, via dyld_find()
BSD: lib{name}.* via ldconfig (choose highest ABI version) and cc
Solaris: lib{name}.so via crle, and lib{name}.* via cc
Gnu: lib{name}.* via ldconfig and cc

Already, these cases seem to be half emulating the run-time linker and half the build-time linker. I don?t have a good answer about which is ?better? (it would depend on the use case). But since we already have a mix, maybe changing towards run-time would not be such a problem as I first thought.

A half-cooked idea of mine is a simpler function that just accounts for common library naming conventions on various platforms, but does not extract sonames or spawn compilers. I think this could work with what seems to be a common use case of passing the result directly to CDLL(), which will do the real search. For the Windows and OS X cases, a loop might be required to attempt CDLL() with the different possibilities.

But I agree this is straying from the topic of this bug report. Perhaps I should accept that people want to find libraries by just the build-time name, but that are accessible at runtime.

More related reports about find_library() vs CDLL():
Issue 19317: Search Python?s RPATH
Issue 21622: Work without DT_SONAME

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9998>
_______________________________________

From report at bugs.python.org  Tue Apr 26 07:01:08 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Tue, 26 Apr 2016 11:01:08 +0000
Subject: [issue26039] More flexibility in zipfile write interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1461668468.7.0.506161488325.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

zipfile-open-w8 removes the concurrent read-write check for non-seekable files. As Martin points out, reading currently requires seeking, and a streaming read API would look very different from the current API.

----------
Added file: http://bugs.python.org/file42598/zipfile-open-w8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Tue Apr 26 07:23:17 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 26 Apr 2016 11:23:17 +0000
Subject: [issue23275] Can assign [] = (), but not () = []
In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za>
Message-ID: <1461669797.57.0.0578378981772.issue23275@psf.upfronthosting.co.za>


Martin Panter added the comment:

Okay I?ll let Berker update his patch, but I?m happy to try my hand at updating the documentation if needed.

I reviewed the current patch. I can?t say whether the ast.c change is good or not. But IMO the test would be better off in somewhere like /Lib/test/test_unpack.py. It is only a superficial relationship with tuples because the syntax looks the same. Also may be worth testing that [] = [] etc work as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23275>
_______________________________________

From report at bugs.python.org  Tue Apr 26 07:35:23 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2016 11:35:23 +0000
Subject: [issue26850] PyMem_RawMalloc(): update also sys.getallocatedblocks()
 in debug mode
Message-ID: <1461670523.49.0.555580906198.issue26850@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I modified PyMem_Malloc() to use the pymalloc allocator in the issue #26249. This change helped to find a memory leak in test_format that I introduced in Python 3.6:
http://bugs.python.org/issue26249#msg264174

This memory leak gave me an idea: PyMem_RawMalloc() should also update sys.getallocatedblocks() (number of currently allocated blocks). It would help to find memory leaks using "python -m test -R 3:3" in extension modules using PyMem_RawMalloc() (and not PyMem_Malloc() or PyObject_Malloc()).

Attached patch uses an atomic variable _Py_AllocatedBlocks, but only in debug mode. I chose to only change the variable in debug mode to:

* not impact performances
* I don't know if atomic variables are well supported (especially the "var++" operation)
* I don't know yet the impact of this change (how sys.getallocatedblocks() is used).

(The patch would be simpler if the release mode would also be impacted.)

The patch changes _PyObject_Alloc() and _PyObject_Free() in debug mode to only account allocations directly made by pymalloc, to let PyMem_RawMalloc() and PyMem_RawFree() update the _Py_AllocatedBlocks variable. In release mode, _PyObject_Alloc() and _PyObject_Free() are responsible to update the _Py_AllocatedBlocks variable for allocations delegated to PyMem_RawMalloc() and PyMem_RawFree().

----------
files: pymem_rawmalloc_blocks.patch
keywords: patch
messages: 264250
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: PyMem_RawMalloc(): update also sys.getallocatedblocks() in debug mode
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42599/pymem_rawmalloc_blocks.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26850>
_______________________________________

From report at bugs.python.org  Tue Apr 26 07:35:59 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2016 11:35:59 +0000
Subject: [issue26249] Change PyMem_Malloc to use pymalloc allocator
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <1461670559.22.0.940275280705.issue26249@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> 68b2a43d8653 introduced memory leak.

I was very surprised to see a regression in test_format since I didn't change any change related to bytes, bytearray or str formatting in this issue.

In fact, it's much better than that! With PyMem_Malloc() using pymalloc, we benefit for free of the cheap "_Py_AllocatedBlocks" memory leak detector. I introduced the memory leak in the issue #25349 when I optimimzed bytes%args and bytearray%args using the new _PyBytesWriter API.

This memory leak gave me an idea, I opened the issue #26850: "PyMem_RawMalloc(): update also sys.getallocatedblocks() in debug mode".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26249>
_______________________________________

From report at bugs.python.org  Tue Apr 26 07:37:12 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2016 11:37:12 +0000
Subject: [issue26249] Change PyMem_Malloc to use pymalloc allocator
In-Reply-To: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>
Message-ID: <1461670632.58.0.0242995289666.issue26249@psf.upfronthosting.co.za>


STINNER Victor added the comment:

There are no more know bugs related to this change, I close the issue. Thanks for the test_format report Serhiy, I missed it.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26249>
_______________________________________

From report at bugs.python.org  Tue Apr 26 07:39:16 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2016 11:39:16 +0000
Subject: [issue16662] load_tests not invoked in package/__init__.py
In-Reply-To: <1355217291.85.0.41912767842.issue16662@psf.upfronthosting.co.za>
Message-ID: <1461670756.68.0.0827526332366.issue16662@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> ImportError: No module named 'pytest'

It looks like you must install pytest dependency. If you consider that it's really a bug in Python, please open an issue: this issue is now closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16662>
_______________________________________

From report at bugs.python.org  Tue Apr 26 07:42:11 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2016 11:42:11 +0000
Subject: [issue25823] Speed-up oparg decoding on little-endian machines
In-Reply-To: <1449567251.61.0.853791637694.issue25823@psf.upfronthosting.co.za>
Message-ID: <1461670931.94.0.407258218033.issue25823@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I dislike the usage of union to use fetch 16-bit but only in little endian. I would prefer to modify the PyCodeObject to ensure that co_code is aligned to 16-bit and use an uint16_t* pointer in ceval.c. It would be simpler no? In the worst case, we should overallocate 1 null byte in PyCodeObject to align bytecode to 16-bit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25823>
_______________________________________

From report at bugs.python.org  Tue Apr 26 07:44:19 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2016 11:44:19 +0000
Subject: [issue25823] Speed-up oparg decoding on little-endian machines
In-Reply-To: <1449567251.61.0.853791637694.issue25823@psf.upfronthosting.co.za>
Message-ID: <1461671059.7.0.768252440256.issue25823@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"I there are no objections I'm inclined to push the patch in hope that this will make the Wordcode patch (issue26647) simpler and more efficient (yes, this will add more work for Demur for synchronization)."

I would prefer to be kind with Demur and wait until his patch is merged (to not introduce conflicts). Wordcode change is quite big, whereas this one is short. Raymond already approved his patch on the python-dev mailing list, I waiting for the feedback of Yury and Serhiy until Sunday to push the wordcode change.

IMHO it will be simpler to optimize the (oparg, opvalue) fetch in ceval.c after wordcode will be merged.

What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25823>
_______________________________________

From report at bugs.python.org  Tue Apr 26 07:45:19 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2016 11:45:19 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1461671119.94.0.253529833924.issue26647@psf.upfronthosting.co.za>


STINNER Victor added the comment:

@Serhiy and Yury: I'm waiting for your review on this change. I would like to push the wordcode change, I propose to push it sunday. Tell me if you need more time to review it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Tue Apr 26 07:46:53 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2016 11:46: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: <1461671213.9.0.593746193591.issue25420@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The issue is more general than just "import random", Python reads entropy at startup to initialize a random seed for its randomized hash function: see the issue #26839.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25420>
_______________________________________

From report at bugs.python.org  Tue Apr 26 07:47:19 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2016 11:47:19 +0000
Subject: [issue26839] python always calls getrandom() at start,
 causing long hang after boot
In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za>
Message-ID: <1461671239.49.0.437711244489.issue26839@psf.upfronthosting.co.za>


STINNER Victor added the comment:

See also the issue #25420 which is similar but specific to "import random".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

From report at bugs.python.org  Tue Apr 26 07:48:55 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Apr 2016 11:48:55 +0000
Subject: [issue20598] argparse docs: '7'.split() is confusing magic
In-Reply-To: <1392132505.16.0.864715722344.issue20598@psf.upfronthosting.co.za>
Message-ID: <20160426114848.102814.72058.B5771199@psf.io>


Roundup Robot added the comment:

New changeset 44f888e47ab0 by Martin Panter in branch '2.7':
Issue #20598: Replace trivial split() calls with lists in argparse docs
https://hg.python.org/cpython/rev/44f888e47ab0

New changeset 49561532504c by Martin Panter in branch '3.5':
Issue #20598: Replace trivial split() calls with lists in argparse docs
https://hg.python.org/cpython/rev/49561532504c

New changeset 14cb17682831 by Martin Panter in branch 'default':
Issue #20598: Merge argparse docs from 3.5
https://hg.python.org/cpython/rev/14cb17682831

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20598>
_______________________________________

From report at bugs.python.org  Tue Apr 26 07:49:07 2016
From: report at bugs.python.org (jan matejek)
Date: Tue, 26 Apr 2016 11:49:07 +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: <1461671347.61.0.296821907589.issue25420@psf.upfronthosting.co.za>


jan matejek added the comment:

unlike #26839, however, there is no workaround for "import random".
so i maintain that this issue is in fact very specific to the random module

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25420>
_______________________________________

From report at bugs.python.org  Tue Apr 26 07:50:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Apr 2016 11:50:10 +0000
Subject: [issue22234] urllib.parse.urlparse accepts any falsy value as an url
In-Reply-To: <1408538391.97.0.53072227801.issue22234@psf.upfronthosting.co.za>
Message-ID: <1461671410.05.0.102476320354.issue22234@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch that deprecates empty non-str and non-decodable arguments for urlparse, urlsplit, urlunparse, urlunsplit, urldefrag, and parse_qsl.

----------
Added file: http://bugs.python.org/file42600/urlparse_empty_bad_arg_deprecation.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22234>
_______________________________________

From report at bugs.python.org  Tue Apr 26 08:05:37 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 26 Apr 2016 12:05:37 +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: <1461672337.2.0.467152288807.issue25420@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

I still believe the underlying system API use should be fixed rather than all the different instances where it gets used.

getrandom() should not block. If it does on a platform, that's a bug on that platform and Python should revert to the alternative of using /dev/urandom directly (or whatever other source of randomness is available).

Disabling hash randomization is not a good workaround for the issue, since it will definitely pop up in other areas as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25420>
_______________________________________

From report at bugs.python.org  Tue Apr 26 08:10:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Apr 2016 12:10:10 +0000
Subject: [issue25823] Speed-up oparg decoding on little-endian machines
In-Reply-To: <1449567251.61.0.853791637694.issue25823@psf.upfronthosting.co.za>
Message-ID: <1461672610.55.0.839511801293.issue25823@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I agree that implementing fast fetch 16-bit is simpler with wordcodes.

----------
dependencies: +ceval: use Wordcode, 16-bit bytecode

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25823>
_______________________________________

From report at bugs.python.org  Tue Apr 26 08:11:44 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2016 12:11:44 +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: <1461672704.9.0.271774957708.issue25420@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> so i maintain that this issue is in fact very specific to the random module

I think that you misunderstood the issue. I'm now closing it as a duplicate of the issue #26839.

--

Marc-Andre Lemburg: Please continue the discussion on the issue #26839. I copied your latest message.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> python always calls getrandom() at start, causing long hang after boot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25420>
_______________________________________

From report at bugs.python.org  Tue Apr 26 08:11:47 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2016 12:11:47 +0000
Subject: [issue26839] python always calls getrandom() at start,
 causing long hang after boot
In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za>
Message-ID: <1461672707.84.0.385834237351.issue26839@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The issue #25420 has been closed as a duplicate of this issue.

Copy of the latest message:

msg264262 - (view) 	Author: Marc-Andre Lemburg (lemburg) * (Python committer) 	Date: 2016-04-26 12:05

I still believe the underlying system API use should be fixed rather than all the different instances where it gets used.

getrandom() should not block. If it does on a platform, that's a bug on that platform and Python should revert to the alternative of using /dev/urandom directly (or whatever other source of randomness is available).

Disabling hash randomization is not a good workaround for the issue, since it will definitely pop up in other areas as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

From report at bugs.python.org  Tue Apr 26 08:12:26 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2016 12:12:26 +0000
Subject: [issue26839] python always calls getrandom() at start,
 causing long hang after boot
In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za>
Message-ID: <1461672746.65.0.402174113511.issue26839@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +lemburg, matejcik, mmarkk, rhettinger, thomas-petazzoni

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

From report at bugs.python.org  Tue Apr 26 08:20:11 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 26 Apr 2016 12:20:11 +0000
Subject: [issue26851] android compilation and link flags
Message-ID: <1461673211.54.0.945034926098.issue26851@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

The attached patch:

  * Sets the recommended android compilation flags, see: http://developer.android.com/ndk/guides/standalone_toolchain.html#abi.  Note that the android toolchains already set the -fpic flag, as shown with:

    arm-linux-androideabi-gcc -v -S main.c 2>&1 | grep main.c

  * Sets the Position independent executables (PIE) flag which is mandatory starting at API level 21 and supported starting with API level 16.

----------
components: Cross-Build
files: build-flags.patch
keywords: patch
messages: 264266
nosy: Alex.Willmer, xdegaye
priority: normal
severity: normal
status: open
title: android compilation and link flags
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42601/build-flags.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26851>
_______________________________________

From report at bugs.python.org  Tue Apr 26 08:22:23 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Apr 2016 12:22:23 +0000
Subject: [issue26839] python always calls getrandom() at start,
 causing long hang after boot
In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za>
Message-ID: <1461673343.09.0.548770509332.issue26839@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Hmm. Why does os.urandom(), which should explicitly not block, use a blocking getrandom() function?

This is quite unexpected on Linux.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

From report at bugs.python.org  Tue Apr 26 08:23:32 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2016 12:23:32 +0000
Subject: [issue26850] PyMem_RawMalloc(): update also sys.getallocatedblocks()
 in debug mode
In-Reply-To: <1461670523.49.0.555580906198.issue26850@psf.upfronthosting.co.za>
Message-ID: <1461673412.21.0.521887908035.issue26850@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The expected side effect of this change is that hunting memory leaks in regrtest (python -m test) may get more noise.

I ran the Python test suite using "./python -m test -R 3:3": test_nntplib, test_tools and test_unittest failed.

Run alone, test_tools still fails:
-------------
$ ./python -m test -R 3:3 test_tools
0:00:00 [1/1] test_tools
beginning 6 repetitions
123456
......
test_tools leaked [0, 5, 20] references, sum=25
test_tools leaked [0, 1, 4] memory blocks, sum=5
test_tools took 44 sec
1 test failed:
    test_tools
Total duration: 0:00:45
-------------

But if I run test_tools one more time, it doesn't fail anymore...

Example of two sequential runs using two processes:
-------------
$ ./python -m test -R 3:3 test_tools
Run tests sequentially
0:00:00 [1/1] test_tools
beginning 6 repetitions
123456
......
test_tools took 44 sec
1 test OK.
Total duration: 0:00:44

$ ./python -m test -R 3:3 test_tools
Run tests sequentially
0:00:00 [1/1] test_tools
beginning 6 repetitions
123456
......
test_tools leaked [2, 0, 10] references, sum=12
test_tools leaked [0, 0, 3] memory blocks, sum=3
test_tools took 43 sec
1 test failed:
    test_tools
Total duration: 0:00:44
-------------

test_nntplib doesn't fail anymore when run alone.

Oh, and test_unittest failure doesn't seem related to my change: "./python -m test -R 3:3 test_unittest" already fails without my change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26850>
_______________________________________

From report at bugs.python.org  Tue Apr 26 08:30:05 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Apr 2016 12:30:05 +0000
Subject: [issue22234] urllib.parse.urlparse accepts any falsy value as an url
In-Reply-To: <1408538391.97.0.53072227801.issue22234@psf.upfronthosting.co.za>
Message-ID: <1461673805.51.0.547389416575.issue22234@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

And here is simpler patch that just disallows bad arguments without deprecation.

----------
Added file: http://bugs.python.org/file42602/urlparse_empty_bad_arg_disallow.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22234>
_______________________________________

From report at bugs.python.org  Tue Apr 26 08:35:11 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Apr 2016 12:35:11 +0000
Subject: [issue26839] python always calls getrandom() at start,
 causing long hang after boot
In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za>
Message-ID: <1461674111.18.0.325768167093.issue26839@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Wow, it's by design:

" os.urandom(n)

    Return a string of n random bytes suitable for cryptographic use."


``man urandom'':

"A read from the /dev/urandom device will not block waiting for more entropy.  As a result,  if  there  is
       not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a crypto-
       graphic attack on the algorithms used by the driver."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

From report at bugs.python.org  Tue Apr 26 08:37:32 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2016 12:37:32 +0000
Subject: [issue26839] python always calls getrandom() at start,
 causing long hang after boot
In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za>
Message-ID: <1461674252.49.0.0576278962581.issue26839@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"Hmm. Why does os.urandom(), which should explicitly not block, use a blocking getrandom() function? This is quite unexpected on Linux."

I modified os.getrandom() in the issue #22181 to use the new getrandom() syscall of Linux 3.17. The syscall blocks until the Linux kernel entropy pool is *initialized* with enough entropy. In a healthy system, it must never occur.

To be clear: you get read 10 MB (or 1 GB or more) of random data using os.urandom() even if the entropy pool is empty. You can test:

* In a terminal 1, run "dd if=/dev/random of=random" to ensure that the entropy pool is empty
* In a terminal 2, run "while true; do cat /proc/sys/kernel/random/entropy_avail; sleep 1; done" to see that entropy pool is empty (or very low, like less 100 bytes)
* In a terminal 3, get a lot of random data using os.urandom(): ./python -c 'import os; x=os.urandom(1024*1024*10)'

=> it works, you *can* get 10 MB of random data even if the kernel entropy pool is empty.

Reminder: getrandom() is used to avoid a file descriptor which caused various issues (see issue #22181 for more information).

Ok, now this issue. The lack of entropy is a known problem in virtual machine. It's common that SSH, HTTPS, or other operations block because because of the lack of entropy. On bare metal, the Linux entropy pool is feeded by physical events like interruptions, keyboard strokes, mouse moves, etc. On a virtual machine, there is *no* source of entropy.

The problem is not only known but also solved, at least for qemu: you must attach a virtio-rng device to your virtual machine. See for example https://fedoraproject.org/wiki/Features/Virtio_RNG The VM can now reads fresh and good quality entropy from the host.

To come back to Python: getrandom() syscall only blocks until the entropy pool is *initialized* with enough entropy.

The getrandom() syscall has a GRND_NONBLOCK to fail with EAGAIN if reading from /dev/random (not /dev/urandom) would block because the entropy pool has not enough entropy:
http://man7.org/linux/man-pages/man2/getrandom.2.html

IMHO it's a deliberate choice to block in getrandom() when reading /dev/urandom while the entropy pool is not initialized with enough entropy yet.

Ok, now the question is: should python do nothing to support VM badly configured (with no real source of entropy)?

It looks like the obvious change is to not use getrandom() but revert code to use a file descriptor and read from /dev/urandom. We will get bad entropy, but Python will be able to start.

I am not excited by this idea. The os.urandom() private file descriptor caused other kinds of issues and bad quality entropy is also an issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

From report at bugs.python.org  Tue Apr 26 08:38:40 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2016 12:38:40 +0000
Subject: [issue26839] Python 3.5 running in a virtual machine blocks at
 startup or on importing the random module
In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za>
Message-ID: <1461674320.54.0.247388134728.issue26839@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: python always calls getrandom() at start, causing long hang after boot -> Python 3.5 running in a virtual machine blocks at startup or on importing the random module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

From report at bugs.python.org  Tue Apr 26 08:40:18 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2016 12:40:18 +0000
Subject: [issue26839] Python 3.5 running in a virtual machine with Linux
 kernel 3.17+ can block at startup or on importing the random module
In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za>
Message-ID: <1461674418.88.0.329530745074.issue26839@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: Python 3.5 running in a virtual machine blocks at startup or on importing the random module -> Python 3.5 running in a virtual machine with Linux kernel 3.17+ can block at startup or on importing the random module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

From report at bugs.python.org  Tue Apr 26 08:40:38 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2016 12:40:38 +0000
Subject: [issue26839] Python 3.5 running in a virtual machine with Linux
 kernel 3.17+ can block at startup or on importing the random module on
 getrandom()
In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za>
Message-ID: <1461674438.57.0.674394227255.issue26839@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: Python 3.5 running in a virtual machine with Linux kernel 3.17+ can block at startup or on importing the random module -> Python 3.5 running in a virtual machine with Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

From report at bugs.python.org  Tue Apr 26 08:43:31 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 26 Apr 2016 12:43:31 +0000
Subject: [issue26852] add a COMPILEALL_FLAGS Makefile variable
Message-ID: <1461674611.23.0.732409522866.issue26852@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Add a COMPILEALL_FLAGS Makefile variable to allow setting this flag to have legacy locations for byte-code files and save space on mobile devices.

Patch attached.
The '-E' python command line option added to $(PYTHON_FOR_BUILD) in the patch is fixing a problem that should actually be entered in another issue.  When cross-compiling, the PYTHON_FOR_BUILD command sets PYTHONPATH to the location of the cross-compiled shared libraries of the extension modules.  So the compilation of modules that import extension modules fail without '-E'.

----------
components: Cross-Build
files: compileall-flags.patch
keywords: patch
messages: 264272
nosy: Alex.Willmer, xdegaye
priority: normal
severity: normal
status: open
title: add a COMPILEALL_FLAGS Makefile variable
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42603/compileall-flags.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26852>
_______________________________________

From report at bugs.python.org  Tue Apr 26 08:44:11 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 26 Apr 2016 12:44:11 +0000
Subject: [issue20598] argparse docs: '7'.split() is confusing magic
In-Reply-To: <1392132505.16.0.864715722344.issue20598@psf.upfronthosting.co.za>
Message-ID: <1461674651.97.0.521002618315.issue20598@psf.upfronthosting.co.za>


Martin Panter added the comment:

I committed my simpler patch. I hope that is okay :)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20598>
_______________________________________

From report at bugs.python.org  Tue Apr 26 08:57:17 2016
From: report at bugs.python.org (Anish Shah)
Date: Tue, 26 Apr 2016 12:57:17 +0000
Subject: [issue22234] urllib.parse.urlparse accepts any falsy value as an url
In-Reply-To: <1408538391.97.0.53072227801.issue22234@psf.upfronthosting.co.za>
Message-ID: <1461675437.46.0.768509623948.issue22234@psf.upfronthosting.co.za>


Changes by Anish Shah <shah.anish07 at gmail.com>:


----------
nosy:  -anish.shah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22234>
_______________________________________

From report at bugs.python.org  Tue Apr 26 09:01:37 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 26 Apr 2016 13:01:37 +0000
Subject: [issue26853] missing symbols in curses and readline modules on android
Message-ID: <1461675697.75.0.0916516767531.issue26853@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

The android loader complains when shared libraries are not linked against their needed libraries (see also issue #21668).  When ncurses is cross-compiled as a shared library, the curses and readline modules must be linked with libtinfow.so.

The attached patch is a quick hack: setup.py spawns readelf to get the list of needed libraries, but this fails as the readelf path name is wrong (it is not the absolute path) and so cannot be used as is for a correct patch.

----------
components: Cross-Build
files: curses_readline.patch
keywords: patch
messages: 264274
nosy: Alex.Willmer, xdegaye
priority: normal
severity: normal
status: open
title: missing symbols in curses and readline modules on android
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file42604/curses_readline.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26853>
_______________________________________

From report at bugs.python.org  Tue Apr 26 09:06:41 2016
From: report at bugs.python.org (Luke)
Date: Tue, 26 Apr 2016 13:06:41 +0000
Subject: [issue26847] filter docs unclear wording
In-Reply-To: <1461640540.65.0.428299683802.issue26847@psf.upfronthosting.co.za>
Message-ID: <1461676001.96.0.536468219812.issue26847@psf.upfronthosting.co.za>


Luke added the comment:

For shame! ... I deserved that callout. :S

My examples should have included the cast to bool, which is indeed not the same as the values' being "equal to False" in themselves...

I didn't realize that "is false" was conventional shorthand for that cast and comparison. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26847>
_______________________________________

From report at bugs.python.org  Tue Apr 26 09:07:45 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 26 Apr 2016 13:07:45 +0000
Subject: [issue26854] missing header on android for the ossaudiodev module
Message-ID: <1461676065.72.0.0543666103766.issue26854@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

On linux /usr/include/sys/soundcard.h includes /usr/include/linux/soundcard.h while on android (also a linux) there is only /usr/include/linux/soundcard.h

Patch attached.

----------
components: Cross-Build
files: ossaudiodev.patch
keywords: patch
messages: 264276
nosy: Alex.Willmer, xdegaye
priority: normal
severity: normal
status: open
title: missing header on android for the ossaudiodev module
type: compile error
versions: Python 3.6
Added file: http://bugs.python.org/file42605/ossaudiodev.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26854>
_______________________________________

From report at bugs.python.org  Tue Apr 26 09:18:31 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 26 Apr 2016 13:18:31 +0000
Subject: [issue26855] add platform.android_ver() for android
Message-ID: <1461676711.89.0.563475479331.issue26855@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

The attached patch misses a test case.

Also how can we be sure that the '/system/build.prop' file may be guaranteed to exist on all android devices ?
It is difficult to get a reliable information on the android infrastructure when the information does not relate to the java libraries.

----------
components: Cross-Build
files: platform.patch
keywords: patch
messages: 264277
nosy: Alex.Willmer, xdegaye
priority: normal
severity: normal
status: open
title: add platform.android_ver() for android
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42606/platform.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26855>
_______________________________________

From report at bugs.python.org  Tue Apr 26 09:23:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Apr 2016 13:23:00 +0000
Subject: [issue22234] urllib.parse.urlparse accepts any falsy value as an url
In-Reply-To: <1408538391.97.0.53072227801.issue22234@psf.upfronthosting.co.za>
Message-ID: <1461676980.07.0.779266321036.issue22234@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch addresses Martin's comment.

----------
Added file: http://bugs.python.org/file42607/urlparse_empty_bad_arg_deprecation2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22234>
_______________________________________

From report at bugs.python.org  Tue Apr 26 09:29:05 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 26 Apr 2016 13:29:05 +0000
Subject: [issue26856] android does not have pwd.getpwall()
Message-ID: <1461677345.21.0.582848799296.issue26856@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

User ids on android are the ids of the applications and they are used to enforce the applications access rights.  See the 'User IDs and File Access' section at http://developer.android.com/guide/topics/security/permissions.html.

Most integers are existing user ids on android. This may explain why getpwall() is missing.
Patch attached.

----------
components: Library (Lib)
files: pwd.patch
keywords: patch
messages: 264279
nosy: xdegaye
priority: normal
severity: normal
status: open
title: android does not have pwd.getpwall()
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file42608/pwd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26856>
_______________________________________

From report at bugs.python.org  Tue Apr 26 09:33:19 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 26 Apr 2016 13:33:19 +0000
Subject: [issue26857] gethostbyname_r() is broken on android
Message-ID: <1461677599.23.0.153884294057.issue26857@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

HAVE_GETHOSTBYNAME_R is defined on android API 21, but importing the _socket module fails with:

    ImportError: dlopen failed: cannot locate symbol "gethostbyaddr_r" referenced by "_socket.cpython-36m-i386-linux-gnu.so"

Patch attached.
The patch does not take into account the fact that this may be fixed in future versions of android.

----------
components: Cross-Build
files: socketmodule.patch
keywords: patch
messages: 264280
nosy: Alex.Willmer, xdegaye
priority: normal
severity: normal
status: open
title: gethostbyname_r() is broken on android
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file42609/socketmodule.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26857>
_______________________________________

From report at bugs.python.org  Tue Apr 26 09:37:22 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 26 Apr 2016 13:37:22 +0000
Subject: [issue26858] setting SO_REUSEPORT fails on android
Message-ID: <1461677842.81.0.574068471289.issue26858@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Android defines SO_REUSEPORT on android API 21 but setting this option in the asyncio tests raises OSError: [Errno 92] Protocol not available.

The attached patch assumes there is a platform.android_ver() function to detect that this is the android platform.  The patch does not take into account the fact that this may be fixed in future versions of android.

----------
components: Cross-Build
files: test.asyncio.patch
keywords: patch
messages: 264281
nosy: Alex.Willmer, xdegaye
priority: normal
severity: normal
status: open
title: setting SO_REUSEPORT fails on android
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file42610/test.asyncio.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26858>
_______________________________________

From report at bugs.python.org  Tue Apr 26 09:40:10 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2016 13:40:10 +0000
Subject: [issue20598] argparse docs: '7'.split() is confusing magic
In-Reply-To: <1461674651.97.0.521002618315.issue20598@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbo29EXF3gSAJj062S3SV4SXnWFN2aoVSjhCeZarV-hcw@mail.gmail.com>


STINNER Victor added the comment:

Thanks. The doc looks better like that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20598>
_______________________________________

From report at bugs.python.org  Tue Apr 26 09:42:17 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 26 Apr 2016 13:42:17 +0000
Subject: [issue26859] unittest fails with "Start directory is not importable"
Message-ID: <1461678137.48.0.743276761028.issue26859@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

unittest fails to load tests when the tests are in a package that has an __init__.pyc file and no __init__.py file.

Patch attached.

----------
components: Library (Lib)
files: unittest.patch
keywords: patch
messages: 264283
nosy: xdegaye
priority: normal
severity: normal
status: open
title: unittest fails with "Start directory is not importable"
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file42611/unittest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26859>
_______________________________________

From report at bugs.python.org  Tue Apr 26 09:44:11 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Apr 2016 13:44:11 +0000
Subject: [issue26839] Python 3.5 running in a virtual machine with Linux
 kernel 3.17+ can block at startup or on importing the random module on
 getrandom()
In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za>
Message-ID: <1461678251.07.0.576206887236.issue26839@psf.upfronthosting.co.za>


Stefan Krah added the comment:

It is clear how /dev/urandom works. I just think that securing enough
entropy on startup should be done by the init scripts (if systemd still
allows that :) and not by an application.

[Unless the application is gpg or similar.]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

From report at bugs.python.org  Tue Apr 26 09:45:06 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Tue, 26 Apr 2016 13:45:06 +0000
Subject: [issue26860] os.walk and os.fwalk yield namedtuple instead of tuple
Message-ID: <1461678306.82.0.694875654943.issue26860@psf.upfronthosting.co.za>


New submission from Aviv Palivoda:

I am suggesting that os.walk and os.fwalk will yield a namedtuple instead of the regular tuple they currently yield.
The use case for this change can be seen in the next example:

def walk_wrapper(walk_it):
    for dir_entry in walk_it:
        if dir_entry[0] == "aaa":
           yield dir_entry

Because walk_it can be either os.walk or os.fwalk I need to access dir_entry via index.

My change will allow me to change this function to:

def walk_wrapper(walk_it):
    for dir_entry in walk_it:
        if dir_entry.dirpath == "aaa":
           yield dir_entry

Witch is more clear and readable.

----------
components: Library (Lib)
files: os-walk-result-namedtuple.patch
keywords: patch
messages: 264285
nosy: loewis, palaviv
priority: normal
severity: normal
status: open
title: os.walk and os.fwalk yield namedtuple instead of tuple
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42612/os-walk-result-namedtuple.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26860>
_______________________________________

From report at bugs.python.org  Tue Apr 26 09:47:15 2016
From: report at bugs.python.org (Vukasin Felbab)
Date: Tue, 26 Apr 2016 13:47:15 +0000
Subject: [issue26861] shutil.copyfile() doesn't close the opened files
Message-ID: <1461678435.64.0.223785102956.issue26861@psf.upfronthosting.co.za>


New submission from Vukasin Felbab:

shutil.copyfile() doesn't close the opened files, so it is vulnerable to IO Error 24: too many files open

actually, the src and dst files should be closed after copy

----------
components: IO
messages: 264286
nosy: vocdetnojz
priority: normal
severity: normal
status: open
title: shutil.copyfile() doesn't close the opened files
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26861>
_______________________________________

From report at bugs.python.org  Tue Apr 26 09:49:48 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 26 Apr 2016 13:49:48 +0000
Subject: [issue26862] SYS_getdents64 does not need to be defined on android
 API 21
Message-ID: <1461678588.46.0.828463582716.issue26862@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Revert the changeset commited at issue #20307 as the compilation does not fail anymore on android API level 21.

Patch attached.

----------
components: Cross-Build
files: posixmodule.patch
keywords: patch
messages: 264287
nosy: Alex.Willmer, xdegaye
priority: normal
severity: normal
status: open
title: SYS_getdents64 does not need to be defined on android API 21
type: compile error
versions: Python 3.6
Added file: http://bugs.python.org/file42613/posixmodule.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26862>
_______________________________________

From report at bugs.python.org  Tue Apr 26 09:53:40 2016
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 26 Apr 2016 13:53:40 +0000
Subject: [issue26860] os.walk and os.fwalk yield namedtuple instead of tuple
In-Reply-To: <1461678306.82.0.694875654943.issue26860@psf.upfronthosting.co.za>
Message-ID: <1461678820.41.0.388240309859.issue26860@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/issue26860>
_______________________________________

From report at bugs.python.org  Tue Apr 26 09:58:00 2016
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 26 Apr 2016 13:58:00 +0000
Subject: [issue26860] os.walk and os.fwalk yield namedtuple instead of tuple
In-Reply-To: <1461678306.82.0.694875654943.issue26860@psf.upfronthosting.co.za>
Message-ID: <1461679080.6.0.864981891508.issue26860@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Quick review of patch looks good.  I'll try to look it over more closely later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26860>
_______________________________________

From report at bugs.python.org  Tue Apr 26 10:03:45 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 26 Apr 2016 14:03:45 +0000
Subject: [issue20598] argparse docs: '7'.split() is confusing magic
In-Reply-To: <1392132505.16.0.864715722344.issue20598@psf.upfronthosting.co.za>
Message-ID: <1461679425.57.0.463357255533.issue20598@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage: patch review -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20598>
_______________________________________

From report at bugs.python.org  Tue Apr 26 10:05:20 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 26 Apr 2016 14:05:20 +0000
Subject: [issue26862] SYS_getdents64 does not need to be defined on android
 API 21
In-Reply-To: <1461678588.46.0.828463582716.issue26862@psf.upfronthosting.co.za>
Message-ID: <1461679520.86.0.0582198346718.issue26862@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26862>
_______________________________________

From report at bugs.python.org  Tue Apr 26 10:14:14 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2016 14:14:14 +0000
Subject: [issue26839] Python 3.5 running in a virtual machine with Linux
 kernel 3.17+ can block at startup or on importing the random module on
 getrandom()
In-Reply-To: <1461678251.07.0.576206887236.issue26839@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbqWEv2-4RtPxV6b7-Go7ZLj-onBWSjg1JXksE9_219AQ@mail.gmail.com>


STINNER Victor added the comment:

Since many years, Linux systems store entropy on disk to quickly feed the
entropy pool at startup.

It doesn't create magically entropy on VM where you start with zero entropy
at the first boot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

From report at bugs.python.org  Tue Apr 26 10:20:52 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Apr 2016 14:20:52 +0000
Subject: [issue26857] gethostbyname_r() is broken on android
In-Reply-To: <1461677599.23.0.153884294057.issue26857@psf.upfronthosting.co.za>
Message-ID: <20160426142040.12708.33291.2EDFC6C2@psf.io>


Roundup Robot added the comment:

New changeset eb19ad1918cd by Stefan Krah in branch 'default':
Issue #26857: Workaround for missing symbol "gethostbyaddr_r" on Android.
https://hg.python.org/cpython/rev/eb19ad1918cd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26857>
_______________________________________

From report at bugs.python.org  Tue Apr 26 10:24:20 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 26 Apr 2016 14:24:20 +0000
Subject: [issue26863] android lacks some declarations for the posix module
Message-ID: <1461680660.31.0.0876884221413.issue26863@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

'AT_EACCESS' is not declared although HAVE_FACCESSAT is defined
'I_PUSH' is not declared

Patch attached.
The patch does not take into account the fact that this may be fixed in future versions of android.

----------
components: Cross-Build
files: posixmodule.patch
keywords: patch
messages: 264291
nosy: Alex.Willmer, xdegaye
priority: normal
severity: normal
status: open
title: android lacks some declarations for the posix module
type: compile error
versions: Python 3.6
Added file: http://bugs.python.org/file42614/posixmodule.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26863>
_______________________________________

From report at bugs.python.org  Tue Apr 26 10:31:57 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Apr 2016 14:31:57 +0000
Subject: [issue26839] Python 3.5 running in a virtual machine with Linux
 kernel 3.17+ can block at startup or on importing the random module on
 getrandom()
In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za>
Message-ID: <1461681117.45.0.865846714081.issue26839@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I did not claim that it magically creates entropy. -- Many VMs are throwaway test beds. It would be annoying to setup some entropy
gathering mechanism just so that Python starts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

From report at bugs.python.org  Tue Apr 26 10:32:40 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 26 Apr 2016 14:32:40 +0000
Subject: [issue26863] android lacks some declarations for the posix module
In-Reply-To: <1461680660.31.0.0876884221413.issue26863@psf.upfronthosting.co.za>
Message-ID: <1461681160.87.0.74397773033.issue26863@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Fixing a comment in previous patch.

----------
Added file: http://bugs.python.org/file42615/posixmodule.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26863>
_______________________________________

From report at bugs.python.org  Tue Apr 26 10:33:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Apr 2016 14:33:48 +0000
Subject: [issue26861] shutil.copyfile() doesn't close the opened files
In-Reply-To: <1461678435.64.0.223785102956.issue26861@psf.upfronthosting.co.za>
Message-ID: <1461681228.9.0.745488922746.issue26861@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you provide an example?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26861>
_______________________________________

From report at bugs.python.org  Tue Apr 26 10:35:50 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Apr 2016 14:35:50 +0000
Subject: [issue26846] Workaround for non-standard stdlib.h on Android
In-Reply-To: <1461617252.68.0.745100271283.issue26846@psf.upfronthosting.co.za>
Message-ID: <20160426143517.102814.73188.DE61311B@psf.io>


Roundup Robot added the comment:

New changeset 287996ff241f by Stefan Krah in branch 'default':
Issue #26846: Post commit cleanup.
https://hg.python.org/cpython/rev/287996ff241f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26846>
_______________________________________

From report at bugs.python.org  Tue Apr 26 10:37:00 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Apr 2016 14:37:00 +0000
Subject: [issue26857] gethostbyname_r() is broken on android
In-Reply-To: <1461677599.23.0.153884294057.issue26857@psf.upfronthosting.co.za>
Message-ID: <1461681420.31.0.283217643489.issue26857@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Thanks, fixed.

----------
assignee:  -> skrah
nosy: +skrah
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26857>
_______________________________________

From report at bugs.python.org  Tue Apr 26 10:43:47 2016
From: report at bugs.python.org (Daniel Morrison)
Date: Tue, 26 Apr 2016 14:43:47 +0000
Subject: [issue26864] urllib.request no_proxy check differs from curl
Message-ID: <1461681827.76.0.743158989172.issue26864@psf.upfronthosting.co.za>


New submission from Daniel Morrison:

The no_proxy environment variable works in python as a case
sensitive suffix check.

Curl handles this variable as a case insensitive hostname check.

Case sensitivity appears to be in conflict with the DNS Case
Insensitivity RFC (https://tools.ietf.org/html/rfc4343).

While the suffix check is documented
(https://docs.python.org/3/library/urllib.request.html), this
seems to be problematic and inconsistent with other tools on the
system.

I believe the ideal solution would be to have proxy_bypass be a
method of ProxyHandler so that it can be overridden without
dependence on undocumented methods. This would also allow
for the requested behavior to be added without breaking backwards
compatibility.

----------
components: Library (Lib)
messages: 264297
nosy: Daniel Morrison
priority: normal
severity: normal
status: open
title: urllib.request no_proxy check differs from curl
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/issue26864>
_______________________________________

From report at bugs.python.org  Tue Apr 26 10:49:38 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Apr 2016 14:49:38 +0000
Subject: [issue26854] missing header on android for the ossaudiodev module
In-Reply-To: <1461676065.72.0.0543666103766.issue26854@psf.upfronthosting.co.za>
Message-ID: <20160426144905.40046.38779.78008AB4@psf.io>


Roundup Robot added the comment:

New changeset d943e6f7c9f3 by Stefan Krah in branch 'default':
Issue #26854: Android has a different include path for soundcard.h.
https://hg.python.org/cpython/rev/d943e6f7c9f3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26854>
_______________________________________

From report at bugs.python.org  Tue Apr 26 10:52:12 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Apr 2016 14:52:12 +0000
Subject: [issue26854] missing header on android for the ossaudiodev module
In-Reply-To: <1461676065.72.0.0543666103766.issue26854@psf.upfronthosting.co.za>
Message-ID: <1461682332.66.0.609573128073.issue26854@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Thanks!

----------
assignee:  -> skrah
nosy: +skrah
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26854>
_______________________________________

From report at bugs.python.org  Tue Apr 26 11:04:50 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Apr 2016 15:04:50 +0000
Subject: [issue26863] android lacks some declarations for the posix module
In-Reply-To: <1461680660.31.0.0876884221413.issue26863@psf.upfronthosting.co.za>
Message-ID: <20160426150432.1514.32374.9EF13DE0@psf.io>


Roundup Robot added the comment:

New changeset f4c6dab59cd8 by Stefan Krah in branch 'default':
Issue #26863: HAVE_FACCESSAT should (currently) not be defined on Android.
https://hg.python.org/cpython/rev/f4c6dab59cd8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26863>
_______________________________________

From report at bugs.python.org  Tue Apr 26 11:06:13 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Apr 2016 15:06:13 +0000
Subject: [issue26863] android lacks some declarations for the posix module
In-Reply-To: <1461680660.31.0.0876884221413.issue26863@psf.upfronthosting.co.za>
Message-ID: <1461683173.2.0.245817713072.issue26863@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Thanks again!

----------
assignee:  -> skrah
nosy: +skrah
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26863>
_______________________________________

From report at bugs.python.org  Tue Apr 26 11:09:17 2016
From: report at bugs.python.org (Marcos Dione)
Date: Tue, 26 Apr 2016 15:09:17 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module and use
 it to improve shutils.copy()
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1461683357.44.0.272275015741.issue26826@psf.upfronthosting.co.za>


Marcos Dione added the comment:

Ok, I have a preliminary version of the patch. It has several parts:

* Adding the functionality to the os module, with docstring.
* Make shutil.copyfileobj() to use it if available.
* Modify the docs (this has to be done by hand, right?).
* Modify NEWS and ACKS.

Several points:

* For the time being, flags must be 0, so I was not sure whether put the argument or not. Just in case, I put it.

* I'm not sure how to test for availability, so configure defines HAVE_COPY_FILE_RANGE.

* No tests yet.

Talking about tests, I tried copying a 325MiB on an SSD, f2fs. Here are the times:

Old user space copy:

$ time ./python -m timeit -n 10 -s 'import shutil' 'a = open ("a.mp4", "rb"); b = open ("b.mp4", "wb+"); shutil.copyfileobj (a, b, 16*1024*1024)'
10 loops, best of 3: 259 msec per loop
real    0m7.915s
user    0m0.104s
sys     0m7.792s


New copy_file_range:

$ time ./python -m timeit -n 10 -s 'import shutil' 'a = open ("a.mp4", "rb"); b = open ("b.mp4", "wb+"); shutil.copyfileobj (a, b, 16*1024*1024)'
10 loops, best of 3: 193 msec per loop
real    0m5.926s
user    0m0.080s
sys     0m5.836s

Some 20% improvement, but notice that the buffer size is 1024 times Python's default size (16MiB vs. 16KiB).

One difference that I notice in semantics is that if the file is not open in binary form, but the file is binary, you get no UnicodeDecodeError (because the data never reaches userspace).

Let me know what you think.

----------
keywords: +patch
Added file: http://bugs.python.org/file42616/copy_file_range.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Tue Apr 26 11:11:14 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 26 Apr 2016 15:11:14 +0000
Subject: [issue26839] Python 3.5 running in a virtual machine with Linux
 kernel 3.17+ can block at startup or on importing the random module on
 getrandom()
In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za>
Message-ID: <1461683474.82.0.840363872775.issue26839@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

As mentioned on the other issue #25420, this is a regression and a change in documented behavior of os.urandom(), which is expected to be non-blocking, regardless of whether entropy is available or not.

The fix should be easy (from reading the man page http://man7.org/linux/man-pages/man2/getrandom.2.html): set the GRND_NONBLOCK flag on getrandom(); then, if the function returns -1 and sets EAGAIN, fallback to reading from /dev/urandom directly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

From report at bugs.python.org  Tue Apr 26 11:11:35 2016
From: report at bugs.python.org (Marcos Dione)
Date: Tue, 26 Apr 2016 15:11:35 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module and use
 it to improve shutils.copy()
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1461683495.39.0.797032632723.issue26826@psf.upfronthosting.co.za>


Marcos Dione added the comment:

Version without the NEWS and ACKS change.

----------
Added file: http://bugs.python.org/file42617/copy_file_range.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Tue Apr 26 11:11:50 2016
From: report at bugs.python.org (Marcos Dione)
Date: Tue, 26 Apr 2016 15:11:50 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module and use
 it to improve shutils.copy()
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1461683510.7.0.0791325503943.issue26826@psf.upfronthosting.co.za>


Changes by Marcos Dione <mdione at grulic.org.ar>:


Removed file: http://bugs.python.org/file42616/copy_file_range.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Tue Apr 26 11:12:02 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Apr 2016 15:12:02 +0000
Subject: [issue26862] SYS_getdents64 does not need to be defined on android
 API 21
In-Reply-To: <1461678588.46.0.828463582716.issue26862@psf.upfronthosting.co.za>
Message-ID: <1461683522.29.0.387095412962.issue26862@psf.upfronthosting.co.za>


Stefan Krah added the comment:

@shiz: Can we settle on API level 21 or is there any reason to leave this in?

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26862>
_______________________________________

From report at bugs.python.org  Tue Apr 26 11:22:02 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 26 Apr 2016 15:22:02 +0000
Subject: [issue26849] android does not support versioning in SONAME
In-Reply-To: <1461662690.12.0.966004358302.issue26849@psf.upfronthosting.co.za>
Message-ID: <1461684122.73.0.469930420428.issue26849@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Attached are the logcat traces of the abort.

This links helps in reading Android avc messages: http://www.all-things-android.com/content/debugging-se-android-avc-messages

----------
Added file: http://bugs.python.org/file42618/logcat.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26849>
_______________________________________

From report at bugs.python.org  Tue Apr 26 11:26:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Apr 2016 15:26:58 +0000
Subject: [issue26020] set_display evaluation order doesn't match documented
 behaviour
In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za>
Message-ID: <1461684418.12.0.798284505875.issue26020@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
components: +Interpreter Core -Documentation
nosy: +serhiy.storchaka
stage: patch review -> commit review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26020>
_______________________________________

From report at bugs.python.org  Tue Apr 26 11:30:26 2016
From: report at bugs.python.org (Neil Girdhar)
Date: Tue, 26 Apr 2016 15:30:26 +0000
Subject: [issue26020] set_display evaluation order doesn't match documented
 behaviour
In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za>
Message-ID: <1461684626.92.0.571517259737.issue26020@psf.upfronthosting.co.za>


Neil Girdhar added the comment:

Please don't forget to fix BUILD_SET_UNPACK to match.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26020>
_______________________________________

From report at bugs.python.org  Tue Apr 26 11:32:21 2016
From: report at bugs.python.org (Neil Girdhar)
Date: Tue, 26 Apr 2016 15:32:21 +0000
Subject: [issue26020] set_display evaluation order doesn't match documented
 behaviour
In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za>
Message-ID: <1461684741.85.0.906176844514.issue26020@psf.upfronthosting.co.za>


Neil Girdhar added the comment:

Also, please add the following test: "{*{True, 1}}"

Should be True.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26020>
_______________________________________

From report at bugs.python.org  Tue Apr 26 11:36:52 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 26 Apr 2016 15:36:52 +0000
Subject: [issue26865] toward the support of the android platform
Message-ID: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

This issue lists issues that may have to be fixed in the perspective of a future support of the android platform.

build
    issue #26849: android does not support versioning in SONAME
    issue #26851: android compilation and link flags
    issue #26852: add a COMPILEALL_FLAGS Makefile variable

curses, readline
    issue #26853: missing symbols in curses and readline modules on android

ossaudiodev
    issue #26854: missing header on android for the ossaudiodev module

platform
    issue #16353: add function to os module for getting path to default shell
    issue #26855: add platform.android_ver() for android

pwd
    issue #26856: android does not have pwd.getpwall()

socketmodule
    issue #26857: gethostbyname_r() is broken on android

asyncio tests
    issue #26858: setting SO_REUSEPORT fails on android

unittest
    issue #26859: unittest fails with "Start directory is not importable"

posixmodule
    issue #26862: SYS_getdents64 does not need to be defined on android API 21
    issue #26863: android lacks some declaration for the posix module

----------
components: Cross-Build
messages: 264310
nosy: Alex.Willmer, xdegaye
priority: normal
severity: normal
status: open
title: toward the support of the android platform
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26865>
_______________________________________

From report at bugs.python.org  Tue Apr 26 11:41:10 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 26 Apr 2016 15:41:10 +0000
Subject: [issue26864] urllib.request no_proxy check differs from curl
In-Reply-To: <1461681827.76.0.743158989172.issue26864@psf.upfronthosting.co.za>
Message-ID: <1461685270.52.0.37127486693.issue26864@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

No, urllib.request does not handle the no_proxy environment in case-sensitive way. It first checks if any environment_variable.lower() ends with "_proxy", and then checks if there is any environment_variable ends with "_proxy". So it works as a case insensitive check, but the lowercase one will override others, e.g, no_proxy overrides no_PROXY. But the document is misleading, it should be clarified.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, martin.panter, xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26864>
_______________________________________

From report at bugs.python.org  Tue Apr 26 11:54:52 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Apr 2016 15:54:52 +0000
Subject: [issue26020] set_display evaluation order doesn't match documented
 behaviour
In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za>
Message-ID: <1461686092.42.0.614096598464.issue26020@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Please don't forget to fix BUILD_SET_UNPACK to match.

Isn't it already correct?

> Also, please add the following test: "{*{True, 1}}"

Did you meant "{*{True}, *{1}}"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26020>
_______________________________________

From report at bugs.python.org  Tue Apr 26 11:55:08 2016
From: report at bugs.python.org (Daniel Morrison)
Date: Tue, 26 Apr 2016 15:55:08 +0000
Subject: [issue26864] urllib.request no_proxy check differs from curl
In-Reply-To: <1461681827.76.0.743158989172.issue26864@psf.upfronthosting.co.za>
Message-ID: <1461686108.65.0.576943769263.issue26864@psf.upfronthosting.co.za>


Daniel Morrison added the comment:

I believe there was a misunderstanding.

While the environment variable name is handled in a case
insensitive way, the contents of the environment variable is not.

Please see some examples below:

    >>> os.environ['no_proxy'] = 'example.com'
    >>> urllib.request.proxy_bypass('EXAMPLE.com')
    0
    >>> urllib.request.proxy_bypass('example.com')
    1

Also to clarify the meaning of suffix check:

    >>> os.environ['no_proxy'] = 'example.com'
    >>> urllib.request.proxy_bypass('myexample.com')
    1

My apologies for my lack of clarity.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26864>
_______________________________________

From report at bugs.python.org  Tue Apr 26 11:58:48 2016
From: report at bugs.python.org (Neil Girdhar)
Date: Tue, 26 Apr 2016 15:58:48 +0000
Subject: [issue26020] set_display evaluation order doesn't match documented
 behaviour
In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za>
Message-ID: <1461686328.76.0.747789572679.issue26020@psf.upfronthosting.co.za>


Neil Girdhar added the comment:

Ah, sorry, I somehow went cross-eyed.  Not sure offhand which test would test the BUILD_TUPLE_UNPACK, but I think you're right Serhiy.  Could just add both?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26020>
_______________________________________

From report at bugs.python.org  Tue Apr 26 12:00:10 2016
From: report at bugs.python.org (Roman Evstifeev)
Date: Tue, 26 Apr 2016 16:00:10 +0000
Subject: [issue26865] toward the support of the android platform
In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za>
Message-ID: <1461686410.77.0.64731515365.issue26865@psf.upfronthosting.co.za>


Changes by Roman Evstifeev <someuniquename at gmail.com>:


----------
nosy: +Roman.Evstifeev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26865>
_______________________________________

From report at bugs.python.org  Tue Apr 26 12:00:31 2016
From: report at bugs.python.org (Roman Evstifeev)
Date: Tue, 26 Apr 2016 16:00:31 +0000
Subject: [issue26856] android does not have pwd.getpwall()
In-Reply-To: <1461677345.21.0.582848799296.issue26856@psf.upfronthosting.co.za>
Message-ID: <1461686431.63.0.851559079761.issue26856@psf.upfronthosting.co.za>


Changes by Roman Evstifeev <someuniquename at gmail.com>:


----------
nosy: +Roman.Evstifeev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26856>
_______________________________________

From report at bugs.python.org  Tue Apr 26 12:00:35 2016
From: report at bugs.python.org (Roman Evstifeev)
Date: Tue, 26 Apr 2016 16:00:35 +0000
Subject: [issue26858] setting SO_REUSEPORT fails on android
In-Reply-To: <1461677842.81.0.574068471289.issue26858@psf.upfronthosting.co.za>
Message-ID: <1461686435.51.0.196915465906.issue26858@psf.upfronthosting.co.za>


Changes by Roman Evstifeev <someuniquename at gmail.com>:


----------
nosy: +Roman.Evstifeev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26858>
_______________________________________

From report at bugs.python.org  Tue Apr 26 12:00:38 2016
From: report at bugs.python.org (Roman Evstifeev)
Date: Tue, 26 Apr 2016 16:00:38 +0000
Subject: [issue26859] unittest fails with "Start directory is not importable"
In-Reply-To: <1461678137.48.0.743276761028.issue26859@psf.upfronthosting.co.za>
Message-ID: <1461686438.56.0.886537041397.issue26859@psf.upfronthosting.co.za>


Changes by Roman Evstifeev <someuniquename at gmail.com>:


----------
nosy: +Roman.Evstifeev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26859>
_______________________________________

From report at bugs.python.org  Tue Apr 26 12:01:58 2016
From: report at bugs.python.org (Tom Middleton)
Date: Tue, 26 Apr 2016 16:01:58 +0000
Subject: [issue26866] Inconsistent environment in Windows using "Open With"
Message-ID: <1461686518.69.0.791676363676.issue26866@psf.upfronthosting.co.za>


New submission from Tom Middleton:

I have found that the execution of python scripts is inconsistent from the following methods:
>From Explorer:

1) Right-Click->Open with->python.exe
2) Right-Click->Open (assuming python.exe being the "default" application)
3) Right-Click->Open with->"Choose default program..."->python.exe
4) Double-Click the script
from the command prompt:
4) python <scriptname>
5) <scriptname>

Of those listed, #1 opens the script with the CWD as c:\Windows\System32\
The remainder open the script with the CWD (as from os.getcwd()) as the current directory of the executed script.

The issue arose when attempting to open a file in the same directory as the script. The issue of how to access a file in the same directory as the script isn't the point of this issue however it is that it is inconsistent across methods that would seem to be identical to the user.

A use case for Open with->python.exe is if say you want your default behavior to be open with an IDE.

The following other issues I found may be relevant.

#22121
#25450

Some digging found this registry entry which may be relevant.
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.py

----------
components: Installation, Windows
messages: 264315
nosy: busfault, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Inconsistent environment in Windows using "Open With"
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26866>
_______________________________________

From report at bugs.python.org  Tue Apr 26 12:02:57 2016
From: report at bugs.python.org (Roman Evstifeev)
Date: Tue, 26 Apr 2016 16:02:57 +0000
Subject: [issue26862] SYS_getdents64 does not need to be defined on android
 API 21
In-Reply-To: <1461678588.46.0.828463582716.issue26862@psf.upfronthosting.co.za>
Message-ID: <1461686577.57.0.0066037754229.issue26862@psf.upfronthosting.co.za>


Changes by Roman Evstifeev <someuniquename at gmail.com>:


----------
nosy: +Roman.Evstifeev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26862>
_______________________________________

From report at bugs.python.org  Tue Apr 26 12:04:41 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 26 Apr 2016 16:04:41 +0000
Subject: [issue26865] Meta-issue: support of the android platform
In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za>
Message-ID: <1461686681.16.0.927358852311.issue26865@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
dependencies: +SYS_getdents64 does not need to be defined on android API 21, add a COMPILEALL_FLAGS Makefile variable, add function to os module for getting path to default shell, add platform.android_ver() for android, android compilation and link flags, android does not have pwd.getpwall(), android does not support versioning in SONAME, android lacks some declarations for the posix module, gethostbyname_r() is broken on android, missing header on android for the ossaudiodev module, missing symbols in curses and readline modules on android, setting SO_REUSEPORT fails on android, unittest fails with "Start directory is not importable"
title: toward the support of the android platform -> Meta-issue: support of the android platform

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26865>
_______________________________________

From report at bugs.python.org  Tue Apr 26 12:06:14 2016
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 26 Apr 2016 16:06:14 +0000
Subject: [issue26865] Meta-issue: support of the android platform
In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za>
Message-ID: <1461686774.2.0.22354525941.issue26865@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/issue26865>
_______________________________________

From report at bugs.python.org  Tue Apr 26 12:24:27 2016
From: report at bugs.python.org (Roman Evstifeev)
Date: Tue, 26 Apr 2016 16:24:27 +0000
Subject: [issue26849] android does not support versioning in SONAME
In-Reply-To: <1461662690.12.0.966004358302.issue26849@psf.upfronthosting.co.za>
Message-ID: <1461687867.15.0.672621852364.issue26849@psf.upfronthosting.co.za>


Changes by Roman Evstifeev <someuniquename at gmail.com>:


----------
nosy: +Roman.Evstifeev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26849>
_______________________________________

From report at bugs.python.org  Tue Apr 26 12:25:28 2016
From: report at bugs.python.org (Eric Snow)
Date: Tue, 26 Apr 2016 16:25:28 +0000
Subject: [issue26865] Meta-issue: support of the android platform
In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za>
Message-ID: <1461687928.34.0.738263777862.issue26865@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/issue26865>
_______________________________________

From report at bugs.python.org  Tue Apr 26 12:26:40 2016
From: report at bugs.python.org (Roman Evstifeev)
Date: Tue, 26 Apr 2016 16:26:40 +0000
Subject: [issue26853] missing symbols in curses and readline modules on android
In-Reply-To: <1461675697.75.0.0916516767531.issue26853@psf.upfronthosting.co.za>
Message-ID: <1461688000.46.0.300302948728.issue26853@psf.upfronthosting.co.za>


Changes by Roman Evstifeev <someuniquename at gmail.com>:


----------
nosy: +Roman.Evstifeev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26853>
_______________________________________

From report at bugs.python.org  Tue Apr 26 12:27:29 2016
From: report at bugs.python.org (Roman Evstifeev)
Date: Tue, 26 Apr 2016 16:27:29 +0000
Subject: [issue26855] add platform.android_ver() for android
In-Reply-To: <1461676711.89.0.563475479331.issue26855@psf.upfronthosting.co.za>
Message-ID: <1461688049.09.0.901378028684.issue26855@psf.upfronthosting.co.za>


Changes by Roman Evstifeev <someuniquename at gmail.com>:


----------
nosy: +Roman.Evstifeev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26855>
_______________________________________

From report at bugs.python.org  Tue Apr 26 12:46:25 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Tue, 26 Apr 2016 16:46:25 +0000
Subject: [issue26854] missing header on android for the ossaudiodev module
In-Reply-To: <1461676065.72.0.0543666103766.issue26854@psf.upfronthosting.co.za>
Message-ID: <1461689185.51.0.875561244397.issue26854@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Maybe checking sys/soundcard.h and linux/soundcard.h in configure.ac is better?

[1] https://github.com/yan12125/python3-android/blob/cpython-hg/mk/python/soundcard-h-path.patch

----------
nosy: +Chi Hsuan Yen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26854>
_______________________________________

From report at bugs.python.org  Tue Apr 26 12:49:20 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Tue, 26 Apr 2016 16:49:20 +0000
Subject: [issue26855] add platform.android_ver() for android
In-Reply-To: <1461676711.89.0.563475479331.issue26855@psf.upfronthosting.co.za>
Message-ID: <1461689360.69.0.816450433719.issue26855@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

> Also how can we be sure that the '/system/build.prop' file may be guaranteed to exist on all android devices ?

This path is hard-coded in BioniC [1]. Though I can't find a document/relevant source codes to guarantee 'ro.build.version.release' and 'ro.build.version.sdk' is always in /system/build.prop

And the format of build.prop is not exactly INI. It supports 'import' clauses. See [2] and load_properties() function in [3]

Other options include calling `getprop` via subprocess or using C level function __system_property_get(). The first approach should always work. It's just somewhat tricky on Android 4.1 [4]. For the second option, a bad news is that it's a private API and was just removed from the latest NDK. Chromium has a workaround for that [5] and CPython may use similar approaches.

[1] https://android.googlesource.com/platform/bionic/+/master/libc/include/sys/_system_properties.h
[2] http://forum.xda-developers.com/android/general/explanation-build-prop-values-t3069341
[3] https://android.googlesource.com/platform/system/core/+/master/init/property_service.cpp
[4] https://github.com/rave-engine/python3-android/pull/10#issuecomment-159151445
[5] https://groups.google.com/a/chromium.org/forum/#!topic/chromium-reviews/keQP6L9aVyU

----------
nosy: +Chi Hsuan Yen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26855>
_______________________________________

From report at bugs.python.org  Tue Apr 26 12:50:02 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Tue, 26 Apr 2016 16:50:02 +0000
Subject: [issue26865] Meta-issue: support of the android platform
In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za>
Message-ID: <1461689402.42.0.36057588178.issue26865@psf.upfronthosting.co.za>


Changes by Chi Hsuan Yen <yan12125 at gmail.com>:


----------
nosy: +Chi Hsuan Yen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26865>
_______________________________________

From report at bugs.python.org  Tue Apr 26 12:59:06 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 26 Apr 2016 16:59:06 +0000
Subject: [issue26864] urllib.request no_proxy check differs from curl
In-Reply-To: <1461681827.76.0.743158989172.issue26864@psf.upfronthosting.co.za>
Message-ID: <1461689946.68.0.774476890329.issue26864@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Ohh, it's my fault to misunderstand. I think your thinking is reasonable. Curl handles the suffix check insensitively.

----------
components: +Library (Lib) -Documentation
nosy:  -docs at python
type: enhancement -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26864>
_______________________________________

From report at bugs.python.org  Tue Apr 26 13:08:42 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Tue, 26 Apr 2016 17:08:42 +0000
Subject: [issue26853] missing symbols in curses and readline modules on android
In-Reply-To: <1461675697.75.0.0916516767531.issue26853@psf.upfronthosting.co.za>
Message-ID: <1461690522.87.0.368703894211.issue26853@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Things may be different if ncurses is built with --without-termlib or --enable-widec is not specified. I wasn't hit by this bug as my ncurses is built with --without-termlib.

----------
nosy: +Chi Hsuan Yen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26853>
_______________________________________

From report at bugs.python.org  Tue Apr 26 13:13:30 2016
From: report at bugs.python.org (Marcos Dione)
Date: Tue, 26 Apr 2016 17:13:30 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module and use
 it to improve shutils.copy()
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1461690810.27.0.369666755974.issue26826@psf.upfronthosting.co.za>


Marcos Dione added the comment:

Hmm, I just noticed that it doesn't fallback to normal copy if the arguments are not valid (EBADF, EXDEV). Back to the drawing board...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Tue Apr 26 13:55:40 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Apr 2016 17:55:40 +0000
Subject: [issue26854] missing header on android for the ossaudiodev module
In-Reply-To: <1461676065.72.0.0543666103766.issue26854@psf.upfronthosting.co.za>
Message-ID: <1461693340.53.0.189015265283.issue26854@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Since Android is the only known system with an odd include path, I
prefer the short patch. In general, let's try to keep patches as
short as possible (which Xavier is already doing).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26854>
_______________________________________

From report at bugs.python.org  Tue Apr 26 14:16:54 2016
From: report at bugs.python.org (Marcos Dione)
Date: Tue, 26 Apr 2016 18:16:54 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module and use
 it to improve shutils.copy()
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1461694614.97.0.567209624893.issue26826@psf.upfronthosting.co.za>


Marcos Dione added the comment:

New version. Factoring the old method in a nested function also paves the way to implement https://bugs.python.org/issue25156 .

----------
Added file: http://bugs.python.org/file42619/copy_file_range.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Tue Apr 26 14:17:06 2016
From: report at bugs.python.org (Marcos Dione)
Date: Tue, 26 Apr 2016 18:17:06 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module and use
 it to improve shutils.copy()
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1461694626.61.0.229771508023.issue26826@psf.upfronthosting.co.za>


Changes by Marcos Dione <mdione at grulic.org.ar>:


Removed file: http://bugs.python.org/file42617/copy_file_range.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Tue Apr 26 14:18:51 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Apr 2016 18:18:51 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module and use
 it to improve shutils.copy()
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1461694731.98.0.485698335418.issue26826@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy:  -pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Tue Apr 26 14:35:04 2016
From: report at bugs.python.org (cowlicks)
Date: Tue, 26 Apr 2016 18:35:04 +0000
Subject: [issue19251] bitwise ops for bytes of equal length
In-Reply-To: <1381694847.24.0.709324715816.issue19251@psf.upfronthosting.co.za>
Message-ID: <1461695704.5.0.395120188604.issue19251@psf.upfronthosting.co.za>


cowlicks added the comment:

@gvanrossum in this previous comment https://bugs.python.org/issue19251?@ok_message=msg%20264184%20created%0Aissue%2019251%20message_count%2C%20messages%20edited%20ok&@template=item#msg257964

I pointed out code from the wild which would be more readable, and posted preliminary benchmarks. But there is a typo, I should have written:

def __mix_single_column(self, a):
    t = len(a) * bytes([reduce(xor, a)])
    a ^= t ^ xtime(a ^ (a[1:] + a[0:1]))


As @gregory.p.smith points out, my claim about security isn't very clear. This would be "more secure" for two reasons. Code would be easier to read and therefore verify, but this is the same as readability. The other reason, doing some binary bitwise op on two bytes objects enforces that the objects be the same length, so unexpected bugs in these code samples would be avoided.

bytes(x ^ y for x, y in zip(a, b))

(int.from_bytes(a, 'big') ^ int.from_bytes(b, 'big')).to_bytes(len(a), 'big')

# XOR each byte of the roundKey with the state table
def addRoundKey(state, roundKey):
    for i in range(len(state)):
        state[i] = state[i] ^ roundKey[i]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19251>
_______________________________________

From report at bugs.python.org  Tue Apr 26 14:39:13 2016
From: report at bugs.python.org (cowlicks)
Date: Tue, 26 Apr 2016 18:39:13 +0000
Subject: [issue19251] bitwise ops for bytes of equal length
In-Reply-To: <1381694847.24.0.709324715816.issue19251@psf.upfronthosting.co.za>
Message-ID: <1461695953.3.0.787842542085.issue19251@psf.upfronthosting.co.za>


cowlicks added the comment:

I'll look through the list @serhiy.storchaka posted and make sure this still seems sane to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19251>
_______________________________________

From report at bugs.python.org  Tue Apr 26 15:25:58 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Apr 2016 19:25:58 +0000
Subject: [issue19251] bitwise ops for bytes of equal length
In-Reply-To: <1461607246.49.0.364462435646.issue19251@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwb+OuKTnpxxLtTU2k2-SL8KjD2XvrKwJSMoOezpRkW0XA@mail.gmail.com>


STINNER Victor added the comment:

>> If yes, maybe we should start with a module on PyPI. Is there a volunteer to try this option?
>
> bitsets ? ordered subsets over a predefined domain

This is an array of *bits*, not an array of bytes (or integers).

> bitarray ? efficient boolean array implemented as C extension

This one is also an array of *bits*, but I see .frombytes() and
.tobytes() methods.

> bitstring ? pure-Python bit string based on bytearray

Array of *bits*. I don't see how to use an array of integers (or a
byte string) with it.

> BitVector ? pure-Python bit array based on unsigned short array
> Bitsets ? Cython interface to fast bitsets in Sage
> bitfield ? Cython positive integer sets
> intbitset ? integer bit sets as C extension

I'm too lazy to check these ones.

I didn't check these modules support operations like x^y.

> Is it enough? Ah, and NumPy.

I'm quite sure that NumPy supports operations like x^y ;-) And NumPy
supports a wide choices of arrays.

Victor

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19251>
_______________________________________

From report at bugs.python.org  Tue Apr 26 16:21:22 2016
From: report at bugs.python.org (Daniel Stokes)
Date: Tue, 26 Apr 2016 20:21:22 +0000
Subject: [issue26536] Add the SIO_LOOPBACK_FAST_PATH option to socket.ioctl
In-Reply-To: <1457666128.63.0.278319184112.issue26536@psf.upfronthosting.co.za>
Message-ID: <1461702082.12.0.998469106022.issue26536@psf.upfronthosting.co.za>


Daniel Stokes added the comment:

The "Lifecycle of a Patch" document recommends pinging an issue after a month of no review. I do not see any special ping option, so I am assuming that means to post a comment.

To help with code review I tried to keep this change very similar to a previous similar change: http://bugs.python.org/issue6971

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26536>
_______________________________________

From report at bugs.python.org  Tue Apr 26 17:03:37 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Apr 2016 21:03:37 +0000
Subject: [issue26853] missing symbols in curses and readline modules on android
In-Reply-To: <1461675697.75.0.0916516767531.issue26853@psf.upfronthosting.co.za>
Message-ID: <1461704617.55.0.175947075623.issue26853@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Do you need libtinfow? It seems that it's not supported in setup.py,
and getting even libtinfo support into some Linux distributions took
quite a while.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26853>
_______________________________________

From report at bugs.python.org  Tue Apr 26 17:03:47 2016
From: report at bugs.python.org (=?utf-8?q?Tin_Tvrtkovi=C4=87?=)
Date: Tue, 26 Apr 2016 21:03:47 +0000
Subject: [issue26664] find a bug in activate.fish of venv of cpython3.6
In-Reply-To: <1459255585.37.0.253753371111.issue26664@psf.upfronthosting.co.za>
Message-ID: <1461704627.1.0.574741582938.issue26664@psf.upfronthosting.co.za>


Tin Tvrtkovi? added the comment:

I'm getting this exact issue on Python 3.5 (xenial system installation).

All my existing venvs (from before my upgrade to xenial) work. Here's the diff:


> diff .venv/bin/activate.fish ../wrapt/.venv/bin/activate.fish 
35c35
< set -gx VIRTUAL_ENV "/home/tin/pg/hypothesis/.venv"
---
> set -gx VIRTUAL_ENV "/home/tin/pg/wrapt/.venv"
58,59c58,59
<         if test -n "$(.venv) "
<             printf "%s%s%s" "$(.venv) " (set_color normal) (_old_fish_prompt)
---
>         if test -n "(.venv) "
>             printf "%s%s%s" "(.venv) " (set_color normal) (_old_fish_prompt)

The added dollar signs are the issue. Removing them fixes the problem.

For the record:

> fish --version
fish, version 2.2.0

And here's the actual error message, the same as in the png:

> . .venv/bin/activate.fish 
$(...) is not supported. In fish, please use '(.venv)'.
.venv/bin/activate.fish (line 58):         if test -n "$(.venv) "
                                                       ^
from sourcing file .venv/bin/activate.fish
	called on line 151 of file /usr/share/fish/config.fish

in function ?.?
	called on standard input

source: Error while reading file ?.venv/bin/activate.fish?

----------
nosy: +tinchester

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26664>
_______________________________________

From report at bugs.python.org  Tue Apr 26 17:05:17 2016
From: report at bugs.python.org (=?utf-8?q?Tin_Tvrtkovi=C4=87?=)
Date: Tue, 26 Apr 2016 21:05:17 +0000
Subject: [issue26664] find a bug in activate.fish of venv of cpython3.6
In-Reply-To: <1459255585.37.0.253753371111.issue26664@psf.upfronthosting.co.za>
Message-ID: <1461704717.88.0.988370341173.issue26664@psf.upfronthosting.co.za>


Changes by Tin Tvrtkovi? <tinchester at gmail.com>:


----------
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26664>
_______________________________________

From report at bugs.python.org  Tue Apr 26 17:06:24 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Apr 2016 21:06:24 +0000
Subject: [issue26853] missing symbols in curses and readline modules on android
In-Reply-To: <1461675697.75.0.0916516767531.issue26853@psf.upfronthosting.co.za>
Message-ID: <1461704784.35.0.289134429868.issue26853@psf.upfronthosting.co.za>


Stefan Krah added the comment:

IOW, on Linux tinfo should work fine in combination with ncursesw.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26853>
_______________________________________

From report at bugs.python.org  Tue Apr 26 17:07:26 2016
From: report at bugs.python.org (=?utf-8?q?Tin_Tvrtkovi=C4=87?=)
Date: Tue, 26 Apr 2016 21:07:26 +0000
Subject: [issue26664] find a bug in activate.fish of venv of cpython3.6
In-Reply-To: <1459255585.37.0.253753371111.issue26664@psf.upfronthosting.co.za>
Message-ID: <1461704846.39.0.766557285903.issue26664@psf.upfronthosting.co.za>


Tin Tvrtkovi? added the comment:

Also I will add I've been using fish for a long time and have never been affected by #26348.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26664>
_______________________________________

From report at bugs.python.org  Tue Apr 26 17:23:58 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 26 Apr 2016 21:23:58 +0000
Subject: [issue26862] SYS_getdents64 does not need to be defined on android
 API 21
In-Reply-To: <1461678588.46.0.828463582716.issue26862@psf.upfronthosting.co.za>
Message-ID: <1461705838.36.0.75383680849.issue26862@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

I have no problem just removing the #ifdef as Android API 21 is now old enough (Lollipop / 5.0) that anyone building Python 3.6 for use on Android is probably fine with it.

If there is a #define that can be used to test the android api level at compile time, adding that to the #if is another approach and would keep people who are trying to run something on an older version happy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26862>
_______________________________________

From report at bugs.python.org  Tue Apr 26 18:19:42 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Apr 2016 22:19:42 +0000
Subject: [issue16255] subrocess.Popen needs /bin/sh but Android only has
 /system/bin/sh
In-Reply-To: <1350421202.49.0.905467284446.issue16255@psf.upfronthosting.co.za>
Message-ID: <1461709182.28.0.0421590561229.issue16255@psf.upfronthosting.co.za>


Stefan Krah added the comment:

It seems that Android is the only known platform that deviates from
/bin/sh. So perhaps we should simply set a variable to either
/bin/sh or /system/bin/sh rather than waiting for #16353 to settle.

----------
nosy: +skrah
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16255>
_______________________________________

From report at bugs.python.org  Tue Apr 26 18:45:36 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 26 Apr 2016 22:45:36 +0000
Subject: [issue26866] Inconsistent environment in Windows using "Open With"
In-Reply-To: <1461686518.69.0.791676363676.issue26866@psf.upfronthosting.co.za>
Message-ID: <1461710736.46.0.464983005609.issue26866@psf.upfronthosting.co.za>


Steve Dower added the comment:

I don't think there's actually a way to fix this - the current working directory is inherited from the current process in the "Open with" case (FWIW, #3 also produces the same result as #1).

I suspect it would need a fix in Windows, which is highly unlikely, or potentially a fix in the launcher to change the current working directory? The latter sounds like a bad idea, but I could be wrong.

In any case, won't be fixed for 2.7, only 3.6 and potentially 3.5.

----------
versions: +Python 3.5, Python 3.6 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26866>
_______________________________________

From report at bugs.python.org  Tue Apr 26 20:29:48 2016
From: report at bugs.python.org (Joseph Hackman)
Date: Wed, 27 Apr 2016 00:29:48 +0000
Subject: [issue25788] fileinput.hook_encoded has no way to pass arguments to
 codecs
In-Reply-To: <1449160890.79.0.711012524776.issue25788@psf.upfronthosting.co.za>
Message-ID: <1461716988.52.0.78963038968.issue25788@psf.upfronthosting.co.za>


Joseph Hackman added the comment:

Uploading a new patch to address the issues in previous patch.

----------
Added file: http://bugs.python.org/file42620/issue25788-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25788>
_______________________________________

From report at bugs.python.org  Tue Apr 26 20:53:22 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 27 Apr 2016 00:53:22 +0000
Subject: [issue26536] Add the SIO_LOOPBACK_FAST_PATH option to socket.ioctl
In-Reply-To: <1457666128.63.0.278319184112.issue26536@psf.upfronthosting.co.za>
Message-ID: <1461718402.08.0.828800599492.issue26536@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for pinging, Daniel. I'm not a Windows user so I can't test the patch, but I left some review comments on Rietveld: http://bugs.python.org/review/26536/

----------
components: +Extension Modules -IO, Windows
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26536>
_______________________________________

From report at bugs.python.org  Tue Apr 26 20:53:50 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 27 Apr 2016 00:53:50 +0000
Subject: [issue26536] Add the SIO_LOOPBACK_FAST_PATH option to socket.ioctl
In-Reply-To: <1457666128.63.0.278319184112.issue26536@psf.upfronthosting.co.za>
Message-ID: <1461718430.8.0.296044571861.issue26536@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
components: +Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26536>
_______________________________________

From report at bugs.python.org  Tue Apr 26 21:02:06 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 27 Apr 2016 01:02:06 +0000
Subject: [issue24933] socket.recv(size, MSG_TRUNC) returns more than size bytes
In-Reply-To: <1440502095.54.0.909214947799.issue24933@psf.upfronthosting.co.za>
Message-ID: <1461718926.07.0.258076320493.issue24933@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
stage:  -> needs patch
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24933>
_______________________________________

From report at bugs.python.org  Tue Apr 26 21:20:58 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 27 Apr 2016 01:20:58 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module and use
 it to improve shutils.copy()
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1461720058.81.0.806711018131.issue26826@psf.upfronthosting.co.za>


Martin Panter added the comment:

Yes, the RST documentation has to be done by hand. It usually has more detail than the doc strings.

I didn?t see any changes to the configure script in your patches. Did you make that change to define HAVE_COPY_FILE_RANGE yet?

In /Modules/posixmodule.c (all three of your patches have an indented diff header, so the review doesn?t pick it up):

+#ifdef HAVE_COPY_FILE_RANGE
+/* The name says posix but currently it's Linux only */

What name are you referring to? The file posixmodule? I think the file name is a bit misleading; according to the comment at the top, it is also used on Windows.

+return (!async_err) ? posix_error() : NULL;

This would make more sense with the logic swapped around: async_err? NULL : posix_error()

Regarding copyfileobj(), I think we should continue to support file objects that do not directly wrap FileIO (includes your Unicode transcoding case). See the points given in Issue 25063. Perhaps we could keep the new version as a high-level copy_file_range() wrapper, but retain brute_force_copy() under the original copyfileobj() name. A bit like the socket.sendfile() method vs os.sendfile().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Tue Apr 26 21:43:48 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 27 Apr 2016 01:43:48 +0000
Subject: [issue25452] Add __bool__() method to subprocess.CompletedProcess
In-Reply-To: <1445424658.54.0.134413313052.issue25452@psf.upfronthosting.co.za>
Message-ID: <1461721428.7.0.264179025012.issue25452@psf.upfronthosting.co.za>


Berker Peksag added the comment:

The idea sounds good to me.

----------
nosy: +berker.peksag
stage:  -> needs patch
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25452>
_______________________________________

From report at bugs.python.org  Tue Apr 26 21:53:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 27 Apr 2016 01:53:35 +0000
Subject: [issue26859] unittest fails with "Start directory is not importable"
In-Reply-To: <1461678137.48.0.743276761028.issue26859@psf.upfronthosting.co.za>
Message-ID: <1461722015.86.0.150077598209.issue26859@psf.upfronthosting.co.za>


Martin Panter added the comment:

Is this the same bug as Issue 26481? I.e. is it the unittest dicovery mode that is affected? Maybe close the other bug as a duplicate, since Xavier has provided a patch here.

----------
components: +Tests
nosy: +martin.panter
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26859>
_______________________________________

From report at bugs.python.org  Tue Apr 26 22:23:03 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 27 Apr 2016 02:23:03 +0000
Subject: [issue26864] urllib.request no_proxy check differs from curl
In-Reply-To: <1461681827.76.0.743158989172.issue26864@psf.upfronthosting.co.za>
Message-ID: <1461723783.6.0.343886905715.issue26864@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I write a patch to fix this.

It seems on Windows and MacOS the behaviour is right. On MacOS it leaves the matching to fnmatch. On Windows it uses case insensitive regular matching.

----------
keywords: +patch
Added file: http://bugs.python.org/file42621/issue26864.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26864>
_______________________________________

From report at bugs.python.org  Tue Apr 26 22:36:58 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 27 Apr 2016 02:36:58 +0000
Subject: [issue24147] Dialect class defaults are not documented.
In-Reply-To: <1431133519.25.0.806037285537.issue24147@psf.upfronthosting.co.za>
Message-ID: <1461724618.24.0.543471711808.issue24147@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/issue24147>
_______________________________________

From report at bugs.python.org  Tue Apr 26 23:02:59 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 27 Apr 2016 03:02:59 +0000
Subject: [issue26864] urllib.request no_proxy check differs from curl
In-Reply-To: <1461681827.76.0.743158989172.issue26864@psf.upfronthosting.co.za>
Message-ID: <1461726179.7.0.357927102868.issue26864@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

The code has changed recently. I update the patch to reveal the change.

----------
Added file: http://bugs.python.org/file42622/issue26864_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26864>
_______________________________________

From report at bugs.python.org  Tue Apr 26 23:09:59 2016
From: report at bugs.python.org (Tom Middleton)
Date: Wed, 27 Apr 2016 03:09:59 +0000
Subject: [issue26866] Inconsistent environment in Windows using "Open With"
In-Reply-To: <1461686518.69.0.791676363676.issue26866@psf.upfronthosting.co.za>
Message-ID: <1461726599.97.0.330831630652.issue26866@psf.upfronthosting.co.za>


Tom Middleton added the comment:

That is interesting, in my use #3 seems to work. I am not certain if it matters whether the default application is already selected as python.exe or not.
FWIW I'm on Windows 7 64 bit using 2.7.11 release install.

**Full Disclosure** I did muck in the registry to get command line arguments to work correctly.(adding the %* to python.exe commands ala #7936) though that shouldn't have any affect on this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26866>
_______________________________________

From report at bugs.python.org  Tue Apr 26 23:34:14 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 27 Apr 2016 03:34:14 +0000
Subject: [issue26867] test_ssl test_options fails on ubuntu 16.04
Message-ID: <1461728054.24.0.63704060185.issue26867@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title: test_ssl test_options fails on ubuntu 16.04

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26867>
_______________________________________

From report at bugs.python.org  Tue Apr 26 23:37:18 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 27 Apr 2016 03:37:18 +0000
Subject: [issue26867] test_ssl test_options fails on ubuntu 16.04
Message-ID: <1461728238.71.0.110276038105.issue26867@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

test_options in test_ssl fails on Ubuntu 16.04. I don't know this is due to the newest ubuntu or a recent code change. But I checkout revision 90000 and then rebuild and test, test_option still fails.

The traceback is:

FAIL: test_options (test.test_ssl.ContextTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/angwer/cpython/Lib/test/test_ssl.py", line 847, in test_options
    self.assertEqual(0, ctx.options)
AssertionError: 0 != 33554432

----------
components: +Library (Lib)
nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26867>
_______________________________________

From report at bugs.python.org  Tue Apr 26 23:38:19 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 27 Apr 2016 03:38:19 +0000
Subject: [issue24933] socket.recv(size, MSG_TRUNC) returns more than size bytes
In-Reply-To: <1440502095.54.0.909214947799.issue24933@psf.upfronthosting.co.za>
Message-ID: <1461728299.94.0.12703526832.issue24933@psf.upfronthosting.co.za>


Martin Panter added the comment:

As far as I know, passing MSG_TRUNC into recv() is Linux-specific. I guess the ?right? portable way to get a message size is to know it in advance, or guess and expand the buffer if MSG_PEEK cannot return the whole message.

Andrey: I don?t think we are accessing _unallocated_ memory (which could crash Python). If you look at _PyBytes_Resize(), I think it correctly allocates the memory, and just leaves it uninitialized.

Some options:

* Document that arbitrary flags like Linux?s MSG_TRUNC not supported
* Limit the returned buffer to the original buffer size
* Raise an exception or warning if recv() returns more than the original buffer size
* Reject unsupported flags like MSG_TRUNC
* Initialize the expanded buffer with zeros

----------
components: +Extension Modules -Library (Lib)
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24933>
_______________________________________

From report at bugs.python.org  Tue Apr 26 23:50:06 2016
From: report at bugs.python.org (Luiz Poleto)
Date: Wed, 27 Apr 2016 03:50:06 +0000
Subject: [issue22234] urllib.parse.urlparse accepts any falsy value as an url
In-Reply-To: <1408538391.97.0.53072227801.issue22234@psf.upfronthosting.co.za>
Message-ID: <1461729006.11.0.902534229982.issue22234@psf.upfronthosting.co.za>


Luiz Poleto added the comment:

I am seeing some results when running urlparse with patch urlparse_empty_bad_arg_deprecation2.patch applied:

>>> urllib.parse.urlparse({})
__main__:1: DeprecationWarning: Use of {} is deprecated
__main__:1: DeprecationWarning: Use of '' is deprecated
ParseResultBytes(scheme=b'', netloc=b'', path=b'', params=b'', query=b'', fragment=b'')

>>> urllib.parse.urlparse('', b'')
__main__:1: DeprecationWarning: Use of b'' is deprecated
/home/poleto/SCMws/python/latest/cpython/Lib/urllib/parse.py:378: DeprecationWarning: Use of b'' is deprecated
  splitresult = urlsplit(url, scheme, allow_fragments)
ParseResult(scheme=b'', netloc='', path='', params='', query='', fragment='')
Will bytes be deprecated if used as a default_schema?

>>> urllib.parse.urlparse(b'', '')
ParseResultBytes(scheme=b'', netloc=b'', path=b'', params=b'', query=b'', fragment=b'')
Shouldn't it complain that the types are different? In fact it does, if you don't provide empty strings:

>>> urllib.parse.urlparse(b'www.python.org', 'http')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "(...)/cpython/Lib/urllib/parse.py", line 377, in urlparse
    url, scheme, _coerce_result = _coerce_args(url, scheme)
  File "(...)/cpython/Lib/urllib/parse.py", line 120, in _coerce_args
    raise TypeError("Cannot mix str and non-str arguments")
TypeError: Cannot mix str and non-str arguments

>>> urllib.parse.urlparse({'a' : 1})
__main__:1: DeprecationWarning: Use of '' is deprecated
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "(...)/cpython/Lib/urllib/parse.py", line 377, in urlparse
    url, scheme, _coerce_result = _coerce_args(url, scheme)
  File "(...)/cpython/Lib/urllib/parse.py", line 128, in _coerce_args
    return _decode_args(args) + (_encode_result,)
  File "(...)/cpython/Lib/urllib/parse.py", line 98, in _decode_args
    return tuple(x.decode(encoding, errors) if x else '' for x in args)
  File "(...)/cpython/Lib/urllib/parse.py", line 98, in <genexpr>
    return tuple(x.decode(encoding, errors) if x else '' for x in args)
AttributeError: 'dict' object has no attribute 'decode'

>>> urllib.parse.urlparse(['a', 'b', 'c'])
__main__:1: DeprecationWarning: Use of [] is deprecated
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "(...)/cpython/Lib/urllib/parse.py", line 377, in urlparse
    url, scheme, _coerce_result = _coerce_args(url, scheme)
  File "(...)/cpython/Lib/urllib/parse.py", line 128, in _coerce_args
    return _decode_args(args) + (_encode_result,)
  File "(...)/cpython/Lib/urllib/parse.py", line 98, in _decode_args
    return tuple(x.decode(encoding, errors) if x else '' for x in args)
  File "(...)/cpython/Lib/urllib/parse.py", line 98, in <genexpr>
    return tuple(x.decode(encoding, errors) if x else '' for x in args)
AttributeError: 'list' object has no attribute 'decode'

I thought about writing test cases but I wasn't a 100% sure if the above is working as expected so I thought I should ask first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22234>
_______________________________________

From report at bugs.python.org  Tue Apr 26 23:53:48 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 27 Apr 2016 03:53:48 +0000
Subject: [issue26864] urllib.request no_proxy check differs from curl
In-Reply-To: <1461681827.76.0.743158989172.issue26864@psf.upfronthosting.co.za>
Message-ID: <1461729228.88.0.691068646098.issue26864@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think this patch looks okay. It fixes the case insensitivity problem, but there is also the string suffix problem (see the myexample.com demo). I think it is reasonable for example.com to match my.example.com, but not myexample.com.

----------
stage:  -> patch review
versions:  -Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26864>
_______________________________________

From report at bugs.python.org  Tue Apr 26 23:59:23 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 27 Apr 2016 03:59:23 +0000
Subject: [issue22234] urllib.parse.urlparse accepts any falsy value as an url
In-Reply-To: <1408538391.97.0.53072227801.issue22234@psf.upfronthosting.co.za>
Message-ID: <1461729563.47.0.560231867641.issue22234@psf.upfronthosting.co.za>


Martin Panter added the comment:

Regarding urlparse(b'', ''). Currently the second parameter is ?scheme?, which is documented as being an empty text string by default. If we deprecate this, we should update the documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22234>
_______________________________________

From report at bugs.python.org  Wed Apr 27 00:00:07 2016
From: report at bugs.python.org (Luiz Poleto)
Date: Wed, 27 Apr 2016 04:00:07 +0000
Subject: [issue22234] urllib.parse.urlparse accepts any falsy value as an url
In-Reply-To: <1408538391.97.0.53072227801.issue22234@psf.upfronthosting.co.za>
Message-ID: <1461729607.17.0.841965001791.issue22234@psf.upfronthosting.co.za>


Luiz Poleto added the comment:

As for urlparse_empty_bad_arg_disallow.patch, I didn't go too deep into testing it but I found that calling urlparse with different non-str args are producing different results:

urlparse({})
TypeError: unhashable type: 'slice'

urlparse([])
AttributeError: 'list' object has no attribute 'decode'

urlparse(())
AttributeError: 'tuple' object has no attribute 'decode'

I thought they should all raise a TypeError but again, I am not sure it is working as expected by the patch's author.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22234>
_______________________________________

From report at bugs.python.org  Wed Apr 27 00:08:47 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 27 Apr 2016 04:08:47 +0000
Subject: [issue26864] urllib.request no_proxy check differs from curl
In-Reply-To: <1461681827.76.0.743158989172.issue26864@psf.upfronthosting.co.za>
Message-ID: <1461730127.65.0.462496555632.issue26864@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Yes, you are right. I don't notice that. I will try to fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26864>
_______________________________________

From report at bugs.python.org  Wed Apr 27 01:14:25 2016
From: report at bugs.python.org (Richard PALO)
Date: Wed, 27 Apr 2016 05:14:25 +0000
Subject: [issue19317] ctypes.util.find_library should examine binary's RPATH
 on Solaris
In-Reply-To: <1382283098.83.0.173984225129.issue19317@psf.upfronthosting.co.za>
Message-ID: <1461734065.4.0.520238204938.issue19317@psf.upfronthosting.co.za>


Richard PALO added the comment:

There *is* a feature with linking called $ORIGIN.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19317>
_______________________________________

From report at bugs.python.org  Wed Apr 27 01:36:44 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 27 Apr 2016 05:36:44 +0000
Subject: [issue26868] Incorrect check for return value of PyModule_AddObject
 in _csv.c
Message-ID: <1461735404.8.0.653639688918.issue26868@psf.upfronthosting.co.za>


New submission from Berker Peksag:

This is probably harmless, but Modules/_csv.c has the following code:

    Py_INCREF(&Dialect_Type);
    if (PyModule_AddObject(module, "Dialect", (PyObject *)&Dialect_Type))
        return NULL;

However, PyModule_AddObject returns only -1 and 0. It also doesn't decref Dialect_Type if it returns -1 so I guess more correct code should be:

    Py_INCREF(&Dialect_Type);
    if (PyModule_AddObject(module, "Dialect", (PyObject *)&Dialect_Type) == -1) {
        Py_DECREF(&Dialect_Type);
        return NULL;
    }

The same pattern can be found in a few more modules.

----------
components: Extension Modules
files: csv.diff
keywords: patch
messages: 264350
nosy: berker.peksag
priority: low
severity: normal
stage: patch review
status: open
title: Incorrect check for return value of PyModule_AddObject in _csv.c
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42623/csv.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26868>
_______________________________________

From report at bugs.python.org  Wed Apr 27 01:55:31 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Apr 2016 05:55:31 +0000
Subject: [issue25788] fileinput.hook_encoded has no way to pass arguments to
 codecs
In-Reply-To: <1449160890.79.0.711012524776.issue25788@psf.upfronthosting.co.za>
Message-ID: <1461736531.56.0.357904336364.issue25788@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, I forget. Needed updates of the documentation (including the "versionchanged" directive). And would be nice if you add corresponding entities in Doc/whatsnew/3.6.rst, Misc/NEWS and Misc/ACKS. The rest of the patch LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25788>
_______________________________________

From report at bugs.python.org  Wed Apr 27 01:57:58 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Apr 2016 05:57:58 +0000
Subject: [issue26672] regrtest missing in the module name
In-Reply-To: <1459336751.45.0.914074281653.issue26672@psf.upfronthosting.co.za>
Message-ID: <20160427055754.12160.27455.3E95B921@psf.io>


Roundup Robot added the comment:

New changeset 2ef61a4747eb by Berker Peksag in branch '2.7':
Issue #26672: Fix regrtest example in test.rst
https://hg.python.org/cpython/rev/2ef61a4747eb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26672>
_______________________________________

From report at bugs.python.org  Wed Apr 27 01:58:37 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 27 Apr 2016 05:58:37 +0000
Subject: [issue26672] regrtest missing in the module name
In-Reply-To: <1459336751.45.0.914074281653.issue26672@psf.upfronthosting.co.za>
Message-ID: <1461736717.65.0.787984646525.issue26672@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Good catch, thanks for the report!

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type: enhancement -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26672>
_______________________________________

From report at bugs.python.org  Wed Apr 27 02:14:28 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 27 Apr 2016 06:14:28 +0000
Subject: [issue26864] urllib.request no_proxy check differs from curl
In-Reply-To: <1461681827.76.0.743158989172.issue26864@psf.upfronthosting.co.za>
Message-ID: <1461737668.08.0.567171654159.issue26864@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I update the patch to use regular expression to handle both case and suffix. This regular expression has the function of curl's check_noproxy. And I think a separate test case is better here.

----------
Added file: http://bugs.python.org/file42624/issue26864_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26864>
_______________________________________

From report at bugs.python.org  Wed Apr 27 02:15:40 2016
From: report at bugs.python.org (Richard PALO)
Date: Wed, 27 Apr 2016 06:15:40 +0000
Subject: [issue19317] ctypes.util.find_library should examine binary's RPATH
 on Solaris
In-Reply-To: <1382283098.83.0.173984225129.issue19317@psf.upfronthosting.co.za>
Message-ID: <1461737740.57.0.211790533333.issue19317@psf.upfronthosting.co.za>


Richard PALO added the comment:

oups... I meant to add the comment about $ORIGIN (not really useful here) but also the fact that the binary python is built with the dependencies found via the library path (-L, for example) and the eventual run-paths (-R or -runpath) when not in the system paths.

As indicated by automatthias@, package managers such as pkgsrc, CSW, *ports and the like have their $PREFIX off of the system main path..  usually in /usr/pkg, /usr/local, /opt/local or something like that
(for unices and linux sort of systems, anyway).

My pkgsrc python2.7 binary has the following runpath:
```
richard at omnis:/home/richard$ dump -Lpv /opt/local/bin/python2.7 |grep RPATH
[12]	RPATH           /opt/pbulk32/gcc49/i486-sun-solaris2.11/lib/.:/opt/pbulk32/gcc49/lib/.:/opt/local/lib
```

What is being requested greatly simplifies things, and can probably be generalised to other ELF based systems too.

BTW I came across the issue as well with py-magic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19317>
_______________________________________

From report at bugs.python.org  Wed Apr 27 02:22:13 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 27 Apr 2016 06:22:13 +0000
Subject: [issue26864] urllib.request no_proxy check differs from curl
In-Reply-To: <1461681827.76.0.743158989172.issue26864@psf.upfronthosting.co.za>
Message-ID: <1461738133.51.0.0736974341172.issue26864@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Update to improve the test case.

----------
Added file: http://bugs.python.org/file42625/issue26864_v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26864>
_______________________________________

From report at bugs.python.org  Wed Apr 27 02:39:03 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 27 Apr 2016 06:39:03 +0000
Subject: [issue22234] urllib.parse.urlparse accepts any falsy value as an url
In-Reply-To: <1408538391.97.0.53072227801.issue22234@psf.upfronthosting.co.za>
Message-ID: <1461739143.58.0.255315785312.issue22234@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Serhiy:

I left review comments on the patch too. 
I agree to "tightening" of the input arg type in these urlparse functions. 

Before we for the next version, I think, it will be helpful to enumerate the behavior for wrong arg types for these functions that you would like to see.

1. Invalid formats like {}, [], None could just be TypeError.

2. The mix of bytes and str should be deprecated and we could give the suggestion for the encouraged single type in the deprecation warning.

3. Any thing else w.r.t to special rules for various parts of url.

In general, if we are going with the deprecation cycle, we would as well go with deciding on what to allow and present it in a simple way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22234>
_______________________________________

From report at bugs.python.org  Wed Apr 27 03:19:34 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Apr 2016 07:19:34 +0000
Subject: [issue26868] Incorrect check for return value of PyModule_AddObject
 in _csv.c
In-Reply-To: <1461735404.8.0.653639688918.issue26868@psf.upfronthosting.co.za>
Message-ID: <1461741574.68.0.341336061054.issue26868@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Testing returned value of PyModule_AddObject() is correct. This is a matter of style what to use: `if (...)`, `if (... == -1)` or `if (... < 0)`.

But the problem with a leak is more general. I have opened a discussion on Python-Dev: http://comments.gmane.org/gmane.comp.python.devel/157545 .

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26868>
_______________________________________

From report at bugs.python.org  Wed Apr 27 03:47:47 2016
From: report at bugs.python.org (Thomas Guettler)
Date: Wed, 27 Apr 2016 07:47:47 +0000
Subject: [issue26869] unittest longMessage docs
Message-ID: <1461743267.94.0.620093650485.issue26869@psf.upfronthosting.co.za>


New submission from Thomas Guettler:

The first message of the longMessage docs is confusing:

https://docs.python.org/3/library/unittest.html#unittest.TestCase.longMessage

> If set to True then ....

This reads between the lines, that the default is False.

But that was long ago in Python2. In Python3 the default is True (which I prefer to the old default).

I think the docs should be like.

And the term "normal message" is not defined. For new comers the "normal message" is what I get if you don't change the default, not the behaviour of the Python2 version :-)

I think "normal message" should be replaced with "short message" or "diff message" .. I am unsure.

What do you think?

----------
assignee: docs at python
components: Documentation
messages: 264359
nosy: docs at python, guettli
priority: normal
severity: normal
status: open
title: unittest longMessage docs
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26869>
_______________________________________

From report at bugs.python.org  Wed Apr 27 03:52:14 2016
From: report at bugs.python.org (Tyler Crompton)
Date: Wed, 27 Apr 2016 07:52:14 +0000
Subject: [issue26870] Unexpected call to readline's add_history in
 call_readline
Message-ID: <1461743534.82.0.668302064476.issue26870@psf.upfronthosting.co.za>


New submission from Tyler Crompton:

I was implementing a REPL using the readline module and noticed that there are extraneous calls to readline's add_history function in call_readline[1]. This was a problem because there were some lines, that, based on their compositions, I might not want in the history. Figuring out why I was getting two entries for every 

The function call has been around ever since Python started supporting GNU Readline (first appeared in Python 1.4 or so, I believe)[2]. This behavior doesn't seem to be documented anywhere.

I can't seem to find any code that depends on a line that is read in by call_readline to be added to the history. I guess the user might rely on the interactive interpreter to use the history feature. Beyond that, I can't think of any critical purpose for it.

There are four potential workarounds:

1. Don't use the input function. Unfortunately, this is a non-solution as it prevents one from using Readline/libedit for input operations.
2. Don't use Readline/libedit. For the same reasons, this isn't a good solution.
3. Evaluate get_current_history_length() and store its result. Evaluate input(). Evaluate get_current_history_length() again. If the length changed, execute readline.remove_history_item(readline.get_current_history_length() - 1). Note that one can't assume that the length will change after a call to input, because blank lines aren't added to the history. This isn't an ideal solution for obvious reasons. It's a bit convoluted.
4. Use some clever combination of readline.get_line_buffer, tty.setcbreak, termios.tcgetattr, termios.tcsetattr, msvcrt.getwche, and try-except-finally blocks. Besides the obvious complexities in this solution, this isn't particularly platform-independent.

I think that it's fair to say that none of the above options are desirable. So let's discuss potential solutions.

1. Remove this feature from call_readline. Not only will this cause a regression in the interactive interpreter, many people rely on this behavior when using the readline module.
2. Dynamically swap histories (or readline configurations in general) between readline-capable calls to input and prompts in the interactive interpreter. This would surely be too fragile and add unnecessary overhead.
3. Document this behavior and leave the code alone. I wouldn't say that this is a solution, but it would at least help other developers that would fall in the same trap that I did.
4. Add a keyword argument to input to instruct call_readline to not add the line to the history. Personally, this seems a bit dirty.
5. Add a readline function in the readline module that doesn't rely on call_readline. Admittedly, the implementation would have to look eerily similar to call_readline, so perhaps there could be a flag on call_readline. However, that would require touching a few files that don't seem to be particularly related. But a new function might be confusing since call_readline sounds like a name that you'd give such a function.

I think that the last option would be a pretty clean change that would cause the least number of issues (if any) for existing code bases. Regardless of the implementation details, I think that this would be the best route?to add a Python function called readline to the readline module. I would imagine that this would be an easy change/addition.

I'm attaching a sample script that demonstrates the described issue.

[1]: https://github.com/python/cpython/blob/fa3fc6d78ee0ce899c9c828e796b66114400fbf0/Modules/readline.c#L1283
[2]: https://github.com/python/cpython/commit/e59c3ba80888034ef0e4341567702cd91e7ef70d

----------
components: Library (Lib)
files: readline_history.py
messages: 264360
nosy: Tyler Crompton
priority: normal
severity: normal
status: open
title: Unexpected call to readline's add_history in call_readline
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/file42626/readline_history.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26870>
_______________________________________

From report at bugs.python.org  Wed Apr 27 04:13:14 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 27 Apr 2016 08:13:14 +0000
Subject: [issue26859] unittest fails with "Start directory is not importable"
In-Reply-To: <1461678137.48.0.743276761028.issue26859@psf.upfronthosting.co.za>
Message-ID: <1461744794.46.0.430028764536.issue26859@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

It seems to be the same bug.

Source-less distributions are useful on mobile devices where space is sparse.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26859>
_______________________________________

From report at bugs.python.org  Wed Apr 27 04:14:06 2016
From: report at bugs.python.org (Tyler Crompton)
Date: Wed, 27 Apr 2016 08:14:06 +0000
Subject: [issue26870] Unexpected call to readline's add_history in
 call_readline
In-Reply-To: <1461743534.82.0.668302064476.issue26870@psf.upfronthosting.co.za>
Message-ID: <1461744846.55.0.309609976534.issue26870@psf.upfronthosting.co.za>


Changes by Tyler Crompton <tyler at tylercrompton.com>:


----------
nosy: +twouters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26870>
_______________________________________

From report at bugs.python.org  Wed Apr 27 04:41:06 2016
From: report at bugs.python.org (Marcos Dione)
Date: Wed, 27 Apr 2016 08:41:06 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module and use
 it to improve shutils.copy()
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1461746466.29.0.983613166696.issue26826@psf.upfronthosting.co.za>


Marcos Dione added the comment:

> I didn?t see any changes to the configure script in your patches. Did you make that change to define HAVE_COPY_FILE_RANGE yet?

I'm not really sure how to make the test for configure.ac. Other functions are checked differently (availability of header files), but in this case it would need a compile test. I will have to investigate further.

> In /Modules/posixmodule.c (all three of your patches have an indented diff header, so the review doesn?t pick it up):

indented diff header?

> +#ifdef HAVE_COPY_FILE_RANGE
> +/* The name says posix but currently it's Linux only */
> 
> What name are you referring to?

Posix, The function is not Posix at all. I can remove that comment.

> +return (!async_err) ? posix_error() : NULL;
> 
> This would make more sense with the logic swapped around: async_err? NULL : posix_error()

I have to be honest, I just copied it from posix_sendfile(), but I agree.

I'll answer the last paragraph when I finished understanding it, but I think you mean things like zipFile.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Wed Apr 27 04:46:50 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 27 Apr 2016 08:46:50 +0000
Subject: [issue26481] unittest discovery process not working without .py
 source files
In-Reply-To: <1457111372.53.0.54879325378.issue26481@psf.upfronthosting.co.za>
Message-ID: <1461746810.93.0.750509878115.issue26481@psf.upfronthosting.co.za>


Martin Panter added the comment:

Please see Issue 26859; I think it is describing the same problem, and a fix is proposed (although no regression test)

----------
nosy: +martin.panter
resolution:  -> duplicate
status: open -> closed
superseder:  -> unittest fails with "Start directory is not importable"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26481>
_______________________________________

From report at bugs.python.org  Wed Apr 27 05:09:28 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 27 Apr 2016 09:09:28 +0000
Subject: [issue26864] urllib.request no_proxy check differs from curl
In-Reply-To: <1461681827.76.0.743158989172.issue26864@psf.upfronthosting.co.za>
Message-ID: <1461748168.06.0.988896559014.issue26864@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Thanks for your comment martin. Using re.escape is really a good advise.

----------
Added file: http://bugs.python.org/file42627/issue26864_v5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26864>
_______________________________________

From report at bugs.python.org  Wed Apr 27 05:16:15 2016
From: report at bugs.python.org (Marcos Dione)
Date: Wed, 27 Apr 2016 09:16:15 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module and use
 it to improve shutils.copy()
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1461748575.3.0.315723468444.issue26826@psf.upfronthosting.co.za>


Marcos Dione added the comment:

Updated the patch withe most of Martin Panter's and all vadium's comments.

----------
Added file: http://bugs.python.org/file42628/copy_file_range.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Wed Apr 27 05:47:09 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 27 Apr 2016 09:47:09 +0000
Subject: [issue26862] SYS_getdents64 does not need to be defined on android
 API 21
In-Reply-To: <1461678588.46.0.828463582716.issue26862@psf.upfronthosting.co.za>
Message-ID: <1461750429.03.0.0812758118507.issue26862@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

New patch taking into account Gregory's comments.
API level 19 is the last to have a sys/linux-syscalls.h header.
All levels have a android/api-level.h header that define __ANDROID_API__.
There is no API level 20, and SYS_getdents64 is defined at API level 21.

----------
Added file: http://bugs.python.org/file42629/posixmodule.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26862>
_______________________________________

From report at bugs.python.org  Wed Apr 27 05:52:43 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 27 Apr 2016 09:52:43 +0000
Subject: [issue26868] Incorrect check for return value of PyModule_AddObject
 in _csv.c
In-Reply-To: <1461735404.8.0.653639688918.issue26868@psf.upfronthosting.co.za>
Message-ID: <1461750763.21.0.340834439975.issue26868@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the write-up, Serhiy.

It looks like "... == -1" is more popular in the codebase (for  PyModule_AddObject, "... < 0" is the most popular style).

Here is a patch to document the current behavior of PyModule_AddObject.

----------
Added file: http://bugs.python.org/file42630/addobject_doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26868>
_______________________________________

From report at bugs.python.org  Wed Apr 27 05:55:50 2016
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 27 Apr 2016 09:55:50 +0000
Subject: [issue26866] Inconsistent environment in Windows using "Open With"
In-Reply-To: <1461686518.69.0.791676363676.issue26866@psf.upfronthosting.co.za>
Message-ID: <1461750950.6.0.314131338872.issue26866@psf.upfronthosting.co.za>


Eryk Sun added the comment:

Generally the directory that an application needs for its configuration files and data is either the script directory or an %AppData% or %LocalAppData% subdirectory. If the initial working directory matters for some reason (e.g. for writing output files), the parent process either changes to the desired directory beforehand or passes the working directory as a parameter to the CreateProcess or ShellExecuteEx API. It wouldn't make sense for Python to set the working directory to the script directory, because a standard user probably can't even modify that directory. 

> From Explorer:

When running a file, Explorer usually creates the child process with the initial working directory set to that of the target file. However, for "open with" it uses its own working directory, "%SystemRoot%\System32". Actually, the "open with" dialog (not the menu) that lets you select and run an application isn't even Explorer. It's openwith.exe. At least it is in Windows 10 and, IIRC, back to Windows 7.

A workaround is to create a "Run" command in "HKCU\SOFTWARE\Classes\SystemFileAssociations\.py". See the following page for more information about application registration:

https://msdn.microsoft.com/en-us/library/ee872121

For example, the follow .reg file defines a command to run a script using the py.exe launcher. It also adds an "Edit" command that uses DDE to open a script in Visual Studio 2015. 

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Classes\SystemFileAssociations\.py]

[HKEY_CURRENT_USER\SOFTWARE\Classes\SystemFileAssociations\.py\shell]
@="Run"

[HKEY_CURRENT_USER\SOFTWARE\Classes\SystemFileAssociations\.py\shell\Edit]

[HKEY_CURRENT_USER\SOFTWARE\Classes\SystemFileAssociations\.py\shell\Edit\command]
@="\"C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\Common7\\IDE\\devenv.exe\" /dde"

[HKEY_CURRENT_USER\SOFTWARE\Classes\SystemFileAssociations\.py\shell\Edit\ddeexec]
@="Open(\"%1\")"

[HKEY_CURRENT_USER\SOFTWARE\Classes\SystemFileAssociations\.py\shell\Edit\ddeexec\application]
@="VisualStudio.14.0"

[HKEY_CURRENT_USER\SOFTWARE\Classes\SystemFileAssociations\.py\shell\Edit\ddeexec\topic]
@="system"

[HKEY_CURRENT_USER\SOFTWARE\Classes\SystemFileAssociations\.py\shell\Run]

[HKEY_CURRENT_USER\SOFTWARE\Classes\SystemFileAssociations\.py\shell\Run\command]
@="\"C:\\Windows\\py.exe\" \"%1\" %*"

These commands are associated directly with the .py file extension, so they'll always be available, even if no ProgID (e.g. Python.File) is associated with .py scripts. However, the shell will prefer a selected ProgID's "Run" or "Edit" commands, if they exist.

FYI, Explorer's "FileExts\.py" key caches the OpenWithProgids, OpenWithList, and the selected UserChoice for .py files. It shouldn't be modified programmatically, and there's actually a deny ACE on the UserChoice subkey to prevent setting values. One thing you can do, if necessary, is delete the entire key to recompute the file association from the HKCR settings.

If you're manually testing changes by directly modifying the registry (such as deleting the above key), you can call the shell's SHChangeNotify function to refresh file associations, which avoids having to log off and back on. For example:

    import ctypes
    shell32 = ctypes.WinDLL('shell32')

    SHCNE_ASSOCCHANGED = 0x08000000
    shell32.SHChangeNotify.restype = None
    
    shell32.SHChangeNotify(SHCNE_ASSOCCHANGED, 0, 0, 0)

> from the command prompt:

cmd spawns a process using its current working directory (displayed in the prompt, or returned by "cd" without an argument). This is not necessarily the directory of the target file. You can use the /d option of the start command to override this with a specific working directory. For example:

    start "title" /d "C:\Temp" "C:\Temp\somescript.py"

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26866>
_______________________________________

From report at bugs.python.org  Wed Apr 27 05:59:46 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 27 Apr 2016 09:59:46 +0000
Subject: [issue26855] add platform.android_ver() for android
In-Reply-To: <1461676711.89.0.563475479331.issue26855@psf.upfronthosting.co.za>
Message-ID: <1461751186.62.0.469429182854.issue26855@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The android/api-level.h header exists at all the android API levels and define __ANDROID_API__ as, for example at level 21:

    #define __ANDROID_API__ 21

So it is possible to get the sdk version from here, and maybe forget about the release version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26855>
_______________________________________

From report at bugs.python.org  Wed Apr 27 06:02:19 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 27 Apr 2016 10:02:19 +0000
Subject: [issue26870] Unexpected call to readline's add_history in
 call_readline
In-Reply-To: <1461743534.82.0.668302064476.issue26870@psf.upfronthosting.co.za>
Message-ID: <1461751339.63.0.597743314473.issue26870@psf.upfronthosting.co.za>


Martin Panter added the comment:

Solution 3 (documentation) can easily be done for existing versions of Python. Any other fix I think would have to be done in the next Python version (3.6).

By solution 2 (dynamically swap histories), do you mean add an API to save and load the entire history list somewhere, like read/write_history_file(), but maybe to a Python list instead?

A variation on solution 4 came to my mind: Add a global variable or function to the readline module to enable or disable automatic history addition. Or maybe a callback that is run after a line is entered, with it set to the current implementation by default.

If I understand solution 5 (new version of call_readline), that also seems reasonable. I guess you mean to add a new function to replace the Python call to input()? A minor downside would be that the caller has to do extra work if it wants to use input() when the Readline library is unavailable.

----------
components: +Extension Modules -Library (Lib)
nosy: +martin.panter
versions:  -Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26870>
_______________________________________

From report at bugs.python.org  Wed Apr 27 06:32:22 2016
From: report at bugs.python.org (Roman Evstifeev)
Date: Wed, 27 Apr 2016 10:32:22 +0000
Subject: [issue22747] Interpreter fails in initialize on systems where
 HAVE_LANGINFO_H is undefined
In-Reply-To: <1414445408.19.0.175857050886.issue22747@psf.upfronthosting.co.za>
Message-ID: <1461753142.63.0.105566613726.issue22747@psf.upfronthosting.co.za>


Changes by Roman Evstifeev <someuniquename at gmail.com>:


----------
nosy: +Roman.Evstifeev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22747>
_______________________________________

From report at bugs.python.org  Wed Apr 27 06:33:32 2016
From: report at bugs.python.org (Roman Evstifeev)
Date: Wed, 27 Apr 2016 10:33:32 +0000
Subject: [issue17905] Add check for locale.h
In-Reply-To: <1367676553.24.0.0475219885835.issue17905@psf.upfronthosting.co.za>
Message-ID: <1461753212.3.0.953997391594.issue17905@psf.upfronthosting.co.za>


Changes by Roman Evstifeev <someuniquename at gmail.com>:


----------
nosy: +Roman.Evstifeev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17905>
_______________________________________

From report at bugs.python.org  Wed Apr 27 06:37:46 2016
From: report at bugs.python.org (Roman Evstifeev)
Date: Wed, 27 Apr 2016 10:37:46 +0000
Subject: [issue16255] subrocess.Popen needs /bin/sh but Android only has
 /system/bin/sh
In-Reply-To: <1350421202.49.0.905467284446.issue16255@psf.upfronthosting.co.za>
Message-ID: <1461753466.78.0.967733473486.issue16255@psf.upfronthosting.co.za>


Changes by Roman Evstifeev <someuniquename at gmail.com>:


----------
nosy: +Roman.Evstifeev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16255>
_______________________________________

From report at bugs.python.org  Wed Apr 27 06:39:10 2016
From: report at bugs.python.org (Roman Evstifeev)
Date: Wed, 27 Apr 2016 10:39:10 +0000
Subject: [issue16353] add function to os module for getting path to default
 shell
In-Reply-To: <1351473560.4.0.147895276383.issue16353@psf.upfronthosting.co.za>
Message-ID: <1461753550.3.0.957673112734.issue16353@psf.upfronthosting.co.za>


Changes by Roman Evstifeev <someuniquename at gmail.com>:


----------
nosy: +Roman.Evstifeev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16353>
_______________________________________

From report at bugs.python.org  Wed Apr 27 06:39:40 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 27 Apr 2016 10:39:40 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module and use
 it to improve shutils.copy()
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1461753580.1.0.915085069042.issue26826@psf.upfronthosting.co.za>


Martin Panter added the comment:

FYI Martin Panter and vadmium are both me :)

I?m not a big fan or expert on configure.ac and Autoconf, but I guess in this case it is the simplest solution. Maybe look at some of the existing AC_CHECK_DECL and AC_COMPILE_IFELSE invocations. I guess you need to see if __NR_copy_file_range is available.

In the earlier patches, there were four space characters at the start of the file. In the 2016-04-27 09:16 patch, there is a completely empty line (after +#endif /* HAVE_COPY_FILE_RANGE */), which may also be interfering.

FWIW, I don?t think you have to have the posix_ prefix on your function if you don?t want it. It is a static function, so the naming is fairly unrestricted.

About changing copyfileobj(), here are some test cases which may help explain the compatibility problems:

# Transcoding a file to a different character encoding
with open("input.txt", "rt", encoding="latin-1") as input, \
        open("utf8.txt", "wt", encoding="utf-8") as output:
    shutil.copyfileobj(input, output)

# Input is a BufferedReader and may hold extra buffered data
with open("data", "rb") as input, open("output", "wb") as output:
    header = input.read(100)  # Actually reads more bytes from OS
    process_header(header)
    copyfileobj(input, output)  # Copy starting from offset 100

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Wed Apr 27 06:53:17 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 27 Apr 2016 10:53:17 +0000
Subject: [issue26864] urllib.request no_proxy check differs from curl
In-Reply-To: <1461681827.76.0.743158989172.issue26864@psf.upfronthosting.co.za>
Message-ID: <1461754397.43.0.598918468529.issue26864@psf.upfronthosting.co.za>


Martin Panter added the comment:

This version looks okay to me, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26864>
_______________________________________

From report at bugs.python.org  Wed Apr 27 07:30:49 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Wed, 27 Apr 2016 11:30:49 +0000
Subject: [issue26855] add platform.android_ver() for android
In-Reply-To: <1461676711.89.0.563475479331.issue26855@psf.upfronthosting.co.za>
Message-ID: <1461756649.25.0.96292340984.issue26855@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Isn't this macro used in compile time? I thought android_ver() aims to check runtime versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26855>
_______________________________________

From report at bugs.python.org  Wed Apr 27 07:58:30 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 27 Apr 2016 11:58:30 +0000
Subject: [issue26855] add platform.android_ver() for android
In-Reply-To: <1461676711.89.0.563475479331.issue26855@psf.upfronthosting.co.za>
Message-ID: <1461758310.52.0.901907715717.issue26855@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

If the file is guaranteed to exist on most modern Android platforms, this sounds like a good approach.

Perhaps you could add support to fallback to running getprop instead, if the file doesn't exist or cannot be parsed ?!

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26855>
_______________________________________

From report at bugs.python.org  Wed Apr 27 08:05:49 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Apr 2016 12:05:49 +0000
Subject: [issue26868] Incorrect check for return value of PyModule_AddObject
 in _csv.c
In-Reply-To: <1461735404.8.0.653639688918.issue26868@psf.upfronthosting.co.za>
Message-ID: <1461758749.31.0.472270350562.issue26868@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added comments on Rietveld.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26868>
_______________________________________

From report at bugs.python.org  Wed Apr 27 08:07:10 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 27 Apr 2016 12:07:10 +0000
Subject: [issue26855] add platform.android_ver() for android
In-Reply-To: <1461676711.89.0.563475479331.issue26855@psf.upfronthosting.co.za>
Message-ID: <1461758830.71.0.271299485075.issue26855@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

Some screenshots showing different file contents:

 * http://www1-lw.xda-cdn.com/files/2013/12/tweak-your-samsung-galaxy-s3s-performance-with-these-build-prop-android-hacks.w654.jpg
 * http://media.apcmag.com/wp-content/uploads/sites/20/2014/04/buildprop-text-file.jpg
 * http://i.imgur.com/hZXQaX9.png

I think exposing `codename` and `incremental` may also make sense to get a complete picture.

`ro.product` also has a lot of useful entries which could be used for some of the other platform APIs such as uname().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26855>
_______________________________________

From report at bugs.python.org  Wed Apr 27 09:15:37 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Wed, 27 Apr 2016 13:15:37 +0000
Subject: [issue26855] add platform.android_ver() for android
In-Reply-To: <1461676711.89.0.563475479331.issue26855@psf.upfronthosting.co.za>
Message-ID: <1461762937.52.0.696320328108.issue26855@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

I have a WIP patch. [1] It's based on Shiz's patch [2].

[1] https://github.com/yan12125/python3-android/blob/cpython-hg/mk/python/android-misc.patch
[2] https://github.com/rave-engine/python3-android/blob/9bb6420317922c07df405315eea040f9301f7eca/mk/python/3.4.3/python-3.4.3-android-misc.patch

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26855>
_______________________________________

From report at bugs.python.org  Wed Apr 27 09:34:58 2016
From: report at bugs.python.org (Tyler Crompton)
Date: Wed, 27 Apr 2016 13:34:58 +0000
Subject: [issue26870] Unexpected call to readline's add_history in
 call_readline
In-Reply-To: <1461743534.82.0.668302064476.issue26870@psf.upfronthosting.co.za>
Message-ID: <1461764098.36.0.836881108624.issue26870@psf.upfronthosting.co.za>


Tyler Crompton added the comment:

I agree about the documentation. It would only take a few minutes to do.

In regard to your inquiry about the second solution, more or less, yes. I left that one a bit ambiguous since there are many ways to skin that cat. But in retrospect, I probably shouldn't have included that potential solution since it'd be a bit goofy and wouldn't necessarily be much different (in terms of code conciseness) than the third workaround that I mentioned.

As for your suggestion about the fourth solution, I like that idea. I feel that it's actually more similar to the fifth solution than the fourth, but I feel that we're getting close to coming up with something that should be easy and effective.

Lastly, in regard to the fifth solution, yes. But I see what you're saying about the downside. Yeah, that would be rather annoying. For a moment, I thought that it could fall back to standard IO in the absence of Readline/libedit, but that would be a bit misleading for a function in the readline module. Besides, input already does that anyway.

I would imagine that in the vast majority of cases of using such a new function, the developer would fallback to input, because they'd likely prioritize getting the content from the user over ensuring Readline/libedit functionality. Since we already have a function that automatically does that, I think your suggestion to add a function to the readline module to enable/disable automatic history addition would be ideal. I'd be reluctant to use a global Python variable since it would be out of uniform with the rest of the members (i.e., functions) of the module.

I like the idea of adding a set_auto_history(flag=True|False) or something to that effect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26870>
_______________________________________

From report at bugs.python.org  Wed Apr 27 12:10:24 2016
From: report at bugs.python.org (Joseph Hackman)
Date: Wed, 27 Apr 2016 16:10:24 +0000
Subject: [issue25788] fileinput.hook_encoded has no way to pass arguments to
 codecs
In-Reply-To: <1449160890.79.0.711012524776.issue25788@psf.upfronthosting.co.za>
Message-ID: <1461773424.48.0.942276276595.issue25788@psf.upfronthosting.co.za>


Joseph Hackman added the comment:

Updated documentation in fileinput.rst, Doc/whatsnew/3.6.rst, Misc/NEWS and Misc/ACKS.

Thank you so much Serhiy for taking the time to review!

----------
Added file: http://bugs.python.org/file42631/issue25788-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25788>
_______________________________________

From report at bugs.python.org  Wed Apr 27 12:20:38 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 27 Apr 2016 16:20:38 +0000
Subject: [issue26866] Inconsistent environment in Windows using "Open With"
In-Reply-To: <1461686518.69.0.791676363676.issue26866@psf.upfronthosting.co.za>
Message-ID: <1461774038.39.0.00518801129933.issue26866@psf.upfronthosting.co.za>


Steve Dower added the comment:

Wouldn't be surprised to see differences between Win7 and Win10 - the "current working directory" concept has essentially been deprecated in Windows for a while (at least through the GUI).

Registering a system file association is something we could do for the launcher, but that'd be about it. I'm not sure it'd gain that much. Would be very interesting to collect data on who double clicks .py files vs. running them from another program or a console.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26866>
_______________________________________

From report at bugs.python.org  Wed Apr 27 13:17:27 2016
From: report at bugs.python.org (Tom Middleton)
Date: Wed, 27 Apr 2016 17:17:27 +0000
Subject: [issue26866] Inconsistent environment in Windows using "Open With"
In-Reply-To: <1461686518.69.0.791676363676.issue26866@psf.upfronthosting.co.za>
Message-ID: <1461777447.66.0.837896919007.issue26866@psf.upfronthosting.co.za>


Tom Middleton added the comment:

I agree with your assessment Steve. I don't see there being a good fix to this. I also think it would be a bad idea to have the launcher change the current working directory.
Example:
c:\foo\> python d:\scripts\bar.py myfile
(where myfile is in c:\foo\)

A kludge work around in a script is something like this:
import os

if __name__ == "__main__":
    os.chdir(os.path.dirname(__file__))


I also don't think it makes sense to counteract what seems to be a Windows issue in python (or the launcher of which I am less familiar with). I was hoping it was going to be a simple registry setting or something like that which could be handled in the install process.


Eryk, you are correct, it was poor coding that led to the issue. I don't think I was clear in my initial post that I realize that opening a file and assuming the directory of the script is the cwd is not good practice. I was commenting that it is inconsistent between launching methods. I was launching a script that was attempting to write a log file using the logging module with a relative path filename. It was a gotcha because it worked fine on my desktop and it wasn't working when a colleague ran it from "Open with". I've since improved my methodology so the issue is moot for that regard.
However, it is still interesting that there is an inconsistency in Windows in those methods of execution. FWIW I also tested it out with perl and as I expected, got the same results of working directories.

Also please note that I am working in Python 2.7, there is no py launcher as there is in 3. I am not certain what inconsistencies may occur between calling py.exe v. python.exe.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26866>
_______________________________________

From report at bugs.python.org  Wed Apr 27 13:35:15 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 27 Apr 2016 17:35:15 +0000
Subject: [issue26869] unittest longMessage docs
In-Reply-To: <1461743267.94.0.620093650485.issue26869@psf.upfronthosting.co.za>
Message-ID: <1461778515.48.0.691545531762.issue26869@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Replace existing description with

"This class attribute determines what happens when a custom failure message is passed as the msg argument to an assertXYY call that fails.  If True, the default, the custom message is appended to the end of the standard failure message.  If False, the custom message replaces the standard message.

The standard failure message for each *assert method* contains useful information about the objects involved.  For example the message from assertEqual shows the repr of the two unequal objects.  It is usually easier to augment rather than replace this message

The class setting can be overridden in individual test methods by assigning an instance attribute, self.longMessage, to True or False before calling the assert methods.

New in version 3.1."

----------
nosy: +terry.reedy
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26869>
_______________________________________

From report at bugs.python.org  Wed Apr 27 13:44:18 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 27 Apr 2016 17:44:18 +0000
Subject: [issue26664] find a bug in activate.fish of venv of cpython3.6
In-Reply-To: <1459255585.37.0.253753371111.issue26664@psf.upfronthosting.co.za>
Message-ID: <1461779058.25.0.775090935465.issue26664@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

The patch introduced by issue26348 should be reverted. The __VENV_PROMPT__ is meant to be a placeholder. For example, when you create a virtual environment named venv-test, the __VENV_PROPMT__ will be replace by (venv-test). If the patch is applied, it will be $(venv-test), treated as an expression and then cause a failure.

----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26664>
_______________________________________

From report at bugs.python.org  Wed Apr 27 13:52:52 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Apr 2016 17:52:52 +0000
Subject: [issue26871] Change weird behavior of PyModule_AddObject()
Message-ID: <1461779571.56.0.960686965696.issue26871@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

PyModule_AddObject() has weird and counterintuitive behavior. It steals a reference only on success. The caller is responsible to decref it on error. This behavior was not documented and inconsistent with the behavior of other functions stealing a reference (PyList_SetItem() and PyTuple_SetItem()). Seems most developers don't use this function correctly, since only in few places in the stdlib a reference is decrefed explicitly after PyModule_AddObject() failure.

This weird behavior was first reported in issue1782, and changing it was proposed. Related bugs in PyModule_AddIntConstant() and PyModule_AddStringConstant() were fixed, but the behavior of PyModule_AddObject() was not changed and not documented.

This issue is opened for gradual changing the behavior of PyModule_AddObject(). Proposed patch introduces new macros PY_MODULE_ADDOBJECT_CLEAN that controls the behavior of PyModule_AddObject() as PY_SSIZE_T_CLEAN controls the behavior of PyArg_Parse* functions. If the macro is defined before including "Python.h", PyModule_AddObject() steals a reference unconditionally.  Otherwise it steals a reference only on success, and the caller is responsible for decref'ing it on error (current behavior). This needs minimal changes to source code if PyModule_AddObject() was used incorrectly (i.e. as documented), and keep the code that explicitly decref a reference after PyModule_AddObject() working correctly.

Use of PyModule_AddObject() without defining PY_MODULE_ADDOBJECT_CLEAN is declared deprecated (or we can defer this to 3.7). In the distant future (after dropping the support of 2.7) the old behavior will be dropped.

See also a discussion on Python-Dev: http://comments.gmane.org/gmane.comp.python.devel/157545 .

----------
components: Extension Modules, Interpreter Core
files: pymodule_addobject.patch
keywords: patch
messages: 264384
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Change weird behavior of PyModule_AddObject()
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42632/pymodule_addobject.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26871>
_______________________________________

From report at bugs.python.org  Wed Apr 27 13:53:07 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 27 Apr 2016 17:53:07 +0000
Subject: [issue26348] activate.fish sets VENV prompt incorrectly
In-Reply-To: <1455282539.52.0.733684318611.issue26348@psf.upfronthosting.co.za>
Message-ID: <1461779587.18.0.565506394706.issue26348@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

The original behaviour is right. __VENV_PROMPT__ is meant to be a placeholder, not a variable interpreted by shell. I think this patch should be reverted. Related issue is #26664.

----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26348>
_______________________________________

From report at bugs.python.org  Wed Apr 27 14:02:02 2016
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 27 Apr 2016 18:02:02 +0000
Subject: [issue26871] Change weird behavior of PyModule_AddObject()
In-Reply-To: <1461779571.56.0.960686965696.issue26871@psf.upfronthosting.co.za>
Message-ID: <1461780122.43.0.720531824819.issue26871@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I think the current behavior is good for error handling by goto,
which is common for module initialization.

Please don't change this.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26871>
_______________________________________

From report at bugs.python.org  Wed Apr 27 14:07:34 2016
From: report at bugs.python.org (Joshua Bronson)
Date: Wed, 27 Apr 2016 18:07:34 +0000
Subject: [issue25243] decouple string-to-boolean logic from
 ConfigParser.getboolean and offer as separate function
In-Reply-To: <1443307220.16.0.776749230814.issue25243@psf.upfronthosting.co.za>
Message-ID: <1461780454.44.0.19512638954.issue25243@psf.upfronthosting.co.za>


Joshua Bronson added the comment:

Hi Raymond, I'm a bit confused by your comment. The patch I attached to my previous message adds the static method `bool.parse_config_str`. So there's no need to `import configparser` to use this, and "from" is no longer included in the proposed method name. Could you please take a look at my previous message, if you missed it, and reopen this if appropriate?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25243>
_______________________________________

From report at bugs.python.org  Wed Apr 27 14:09:03 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Apr 2016 18:09:03 +0000
Subject: [issue26868] Incorrect check for return value of PyModule_AddObject
 in _csv.c
In-Reply-To: <1461735404.8.0.653639688918.issue26868@psf.upfronthosting.co.za>
Message-ID: <1461780543.87.0.322323601746.issue26868@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

As for Modules/_csv.c, I think it is better to change the behavior of PyModule_AddObject() (issue26871). This will fix similar issues in all modules.

----------
dependencies: +Change weird behavior of PyModule_AddObject()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26868>
_______________________________________

From report at bugs.python.org  Wed Apr 27 14:10:54 2016
From: report at bugs.python.org (Joshua Bronson)
Date: Wed, 27 Apr 2016 18:10:54 +0000
Subject: [issue25243] decouple string-to-boolean logic from
 ConfigParser.getboolean and offer as separate function
In-Reply-To: <1443307220.16.0.776749230814.issue25243@psf.upfronthosting.co.za>
Message-ID: <1461780654.1.0.669367840467.issue25243@psf.upfronthosting.co.za>


Joshua Bronson added the comment:

Actually, looks like the version of the patch I attached did use the name `bool.from_config_str`, sorry about that -- I'll attach a new patch renaming this to `bool.parse_config_str` if there is interest in further consideration.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25243>
_______________________________________

From report at bugs.python.org  Wed Apr 27 14:13:15 2016
From: report at bugs.python.org (Joshua Bronson)
Date: Wed, 27 Apr 2016 18:13:15 +0000
Subject: [issue25243] decouple string-to-boolean logic from
 ConfigParser.getboolean and offer as separate function
In-Reply-To: <1443307220.16.0.776749230814.issue25243@psf.upfronthosting.co.za>
Message-ID: <1461780795.48.0.902337979798.issue25243@psf.upfronthosting.co.za>


Joshua Bronson added the comment:

Though come to think of it, the issue you raised with using "from" in the method name wouldn't apply here, since the static method is on the bool class, and the method does return bool.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25243>
_______________________________________

From report at bugs.python.org  Wed Apr 27 14:32:17 2016
From: report at bugs.python.org (Michael Felt)
Date: Wed, 27 Apr 2016 18:32:17 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1461781937.57.0.211973619728.issue26439@psf.upfronthosting.co.za>


Michael Felt added the comment:

These are very different issues. However, this patch may resolve both!

ldconfig (-p if I recall) lists where (shared) libraries have been installed (imho, this is a GNU tool approach) - whereas AIX would use dump -H to find library paths embedded in a program and/or shared library.

Until this patch, to use shared libraries on AIX the members of an archive needed to be extracted from the .a archive, and for 64-bit members, a separate directory (e.g. /usr/lib64) is needed. With this patch find_library() (actually cdll.LoadLibrary() can load members from either both .so and .a libraries, as is normal for AIX.

So, in a way, this would also solve https://bugs.python.org/issue21826 as ldconfig is no longer needed (nor called) on AIX.

p.s. As it is well longer than a month - I would appreciate that someone actually look at the patch and tell me how it can be improved! :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Wed Apr 27 14:47:29 2016
From: report at bugs.python.org (David Edelsohn)
Date: Wed, 27 Apr 2016 18:47:29 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1461782849.04.0.00948831114829.issue26439@psf.upfronthosting.co.za>


David Edelsohn added the comment:

The most recent patch seems to follow AIX semantics correctly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Wed Apr 27 15:07:31 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Apr 2016 19:07:31 +0000
Subject: [issue26871] Change weird behavior of PyModule_AddObject()
In-Reply-To: <1461779571.56.0.960686965696.issue26871@psf.upfronthosting.co.za>
Message-ID: <1461784051.14.0.60098152504.issue26871@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Idiomatic code is

    if (PyModule_AddObject(module, "name", create_new_object()) < 0)
        goto error;

If you already have a reference and need to use it later:

    obj = create_new_object();
    ... /* use obj */
    Py_INCREF();
    if (PyModule_AddObject(module, "name", create_new_object()) < 0)
        goto error;
    ... /* use obj */
    Py_DECREF(obj);

error:
    Py_XDECREF(obj);

Many current code use above idioms, but it doesn't work as expected.

It is almost impossible to write correct code with current behavior. And _decimal.c is not an exception, it has leaks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26871>
_______________________________________

From report at bugs.python.org  Wed Apr 27 15:23:45 2016
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 27 Apr 2016 19:23:45 +0000
Subject: [issue26871] Change weird behavior of PyModule_AddObject()
In-Reply-To: <1461779571.56.0.960686965696.issue26871@psf.upfronthosting.co.za>
Message-ID: <1461785025.77.0.251068595586.issue26871@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Your definition of correctness is very odd. The "leaks" you are talking
about are single references in case of a module initialization failure,
in which case you are likely to have much bigger problems.


Please take _decimal out of this patch, it's a waste of time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26871>
_______________________________________

From report at bugs.python.org  Wed Apr 27 15:24:35 2016
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 27 Apr 2016 19:24:35 +0000
Subject: [issue26871] Change weird behavior of PyModule_AddObject()
In-Reply-To: <1461779571.56.0.960686965696.issue26871@psf.upfronthosting.co.za>
Message-ID: <1461785075.12.0.540473791887.issue26871@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/issue26871>
_______________________________________

From report at bugs.python.org  Wed Apr 27 15:42:15 2016
From: report at bugs.python.org (Dan McCombs)
Date: Wed, 27 Apr 2016 19:42:15 +0000
Subject: [issue26348] activate.fish sets VENV prompt incorrectly
In-Reply-To: <1455282539.52.0.733684318611.issue26348@psf.upfronthosting.co.za>
Message-ID: <1461786135.04.0.326282334425.issue26348@psf.upfronthosting.co.za>


Dan McCombs added the comment:

I somehow missed the comment on 2016-04-01, I apologize for being late to look at this.

Xiang is right, this patch should be reverted.

It looks like the issue reported was originally brought on by an activate.fish being used from a Python after the patch in commit 7f913c6ada03 was added, but the running version of Python did not include the patch, so that the placeholder was not being swapped out. In that case, updating the script to include $ and use the variable fixed the problem, but when the patch in 7f913c6ada03 is also included it causes the placeholder to be swapped to a name wrapped in parenthesis preceded by $ at the time the venv is created causing a syntax error in fish.

Since the patch in commit 7f913c6ada03 swaps that place holder and handles doing so in the other activate scripts as well, the patch that was part of this issue (cfc66e37eb8e) is not needed and should be reverted.

Here's the commit adding that placeholder for context:

https://hg.python.org/cpython/rev/7f913c6ada03

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26348>
_______________________________________

From report at bugs.python.org  Wed Apr 27 15:47:29 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Apr 2016 19:47:29 +0000
Subject: [issue26664] find a bug in activate.fish of venv of cpython3.6
In-Reply-To: <1459255585.37.0.253753371111.issue26664@psf.upfronthosting.co.za>
Message-ID: <1461786449.04.0.916315540575.issue26664@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/issue26664>
_______________________________________

From report at bugs.python.org  Wed Apr 27 15:50:36 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Apr 2016 19:50:36 +0000
Subject: [issue26348] activate.fish sets VENV prompt incorrectly
In-Reply-To: <1455282539.52.0.733684318611.issue26348@psf.upfronthosting.co.za>
Message-ID: <1461786636.63.0.631010173856.issue26348@psf.upfronthosting.co.za>


Brett Cannon added the comment:

So just to be clear, cfc66e37eb8e and 0f1ac94d2f98 should be reverted? No other changes?

And will this fix issue #26664 or affect it in any way?

----------
assignee:  -> brett.cannon
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26348>
_______________________________________

From report at bugs.python.org  Wed Apr 27 15:59:06 2016
From: report at bugs.python.org (Dan McCombs)
Date: Wed, 27 Apr 2016 19:59:06 +0000
Subject: [issue26348] activate.fish sets VENV prompt incorrectly
In-Reply-To: <1455282539.52.0.733684318611.issue26348@psf.upfronthosting.co.za>
Message-ID: <1461787146.98.0.413968716409.issue26348@psf.upfronthosting.co.za>


Dan McCombs added the comment:

Yes, reverting cfc66e37eb8e and 0f1ac94d2f98 should resolve #26664.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26348>
_______________________________________

From report at bugs.python.org  Wed Apr 27 16:01:45 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Apr 2016 20:01:45 +0000
Subject: [issue26348] activate.fish sets VENV prompt incorrectly
In-Reply-To: <1455282539.52.0.733684318611.issue26348@psf.upfronthosting.co.za>
Message-ID: <1461787305.69.0.575645939.issue26348@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I'll revert the two commits then and close both this and #26664 when I have a chance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26348>
_______________________________________

From report at bugs.python.org  Wed Apr 27 16:03:01 2016
From: report at bugs.python.org (Dan McCombs)
Date: Wed, 27 Apr 2016 20:03:01 +0000
Subject: [issue26348] activate.fish sets VENV prompt incorrectly
In-Reply-To: <1455282539.52.0.733684318611.issue26348@psf.upfronthosting.co.za>
Message-ID: <1461787381.5.0.933572373094.issue26348@psf.upfronthosting.co.za>


Dan McCombs added the comment:

Thanks Brett.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26348>
_______________________________________

From report at bugs.python.org  Wed Apr 27 16:14:21 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Apr 2016 20:14:21 +0000
Subject: [issue25788] fileinput.hook_encoded has no way to pass arguments to
 codecs
In-Reply-To: <1449160890.79.0.711012524776.issue25788@psf.upfronthosting.co.za>
Message-ID: <20160427201410.18223.56017.8F5A32B1@psf.io>


Roundup Robot added the comment:

New changeset 8ab8f5259f09 by Serhiy Storchaka in branch 'default':
Issue #25788: fileinput.hook_encoded() now supports an "errors" argument
https://hg.python.org/cpython/rev/8ab8f5259f09

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25788>
_______________________________________

From report at bugs.python.org  Wed Apr 27 16:16:44 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Apr 2016 20:16:44 +0000
Subject: [issue25788] fileinput.hook_encoded has no way to pass arguments to
 codecs
In-Reply-To: <1449160890.79.0.711012524776.issue25788@psf.upfronthosting.co.za>
Message-ID: <1461788204.01.0.933158010958.issue25788@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Committed with some changes. Thank you for your contribution Joseph.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25788>
_______________________________________

From report at bugs.python.org  Wed Apr 27 16:51:25 2016
From: report at bugs.python.org (sorin)
Date: Wed, 27 Apr 2016 20:51:25 +0000
Subject: [issue26872] Default ConfigParser in python is not able to load
 values habing percent in them
Message-ID: <1461790285.78.0.75016384493.issue26872@psf.upfronthosting.co.za>


New submission from sorin:

The ConfigParser issue with % (percent) is taking huge proportions because it does have serious implications downstream. One such example is the fact that in breaks virtualenv in such way the if you create a virtual env in a path that contains percent at some point you will endup with a virtualenv where you can install only about 50% of existing python packages (serious ones like numpy or pandas will fail to install or even to perform a simple python setup.py egg_info on them).

This is related to distutils which is trying to use the ConfigParser to load the python PATH (which now contains the percent). 

Switching to RawConfigParser does resolve the problem but this seems like an almost impossible attempt because the huge number of occurrences in the wild.

You will find the that only class that is able to load a value with percent inside is RawConfigParser and I don't think that this is normal.

Here is some code I created to exemplify the defective behaviour:
https://github.com/ssbarnea/test-configparser/blob/master/tests/test-configparser.py#L21

The code is executed by Travis with multiple version of python, see one result example: https://travis-ci.org/ssbarnea/test-configparser/jobs/126145032

My personal impression is that the decision to process the % (percent) and to change the behaviour between Python 2 and 3 was a very unfortunate one. Ini/Cfg file specification does not specify the percent as an escape character. Introduction of the %(VAR) feature sounds more like bug than a feature in this case.

----------
components: Distutils
messages: 264402
nosy: dstufft, eric.araujo, sorin
priority: normal
severity: normal
status: open
title: Default ConfigParser in python is not able to load values habing percent in them
type: compile error
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26872>
_______________________________________

From report at bugs.python.org  Wed Apr 27 16:55:03 2016
From: report at bugs.python.org (sorin)
Date: Wed, 27 Apr 2016 20:55:03 +0000
Subject: [issue26872] Default ConfigParser in python is not able to load
 values habing percent in them
In-Reply-To: <1461790285.78.0.75016384493.issue26872@psf.upfronthosting.co.za>
Message-ID: <1461790503.08.0.0439903560276.issue26872@psf.upfronthosting.co.za>


sorin added the comment:

Here is one example of failure caused by this https://gist.github.com/ssbarnea/b373062dd45de92735c7482b2735c5fb

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26872>
_______________________________________

From report at bugs.python.org  Wed Apr 27 18:48:25 2016
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 27 Apr 2016 22:48:25 +0000
Subject: [issue26871] Change weird behavior of PyModule_AddObject()
In-Reply-To: <1461779571.56.0.960686965696.issue26871@psf.upfronthosting.co.za>
Message-ID: <1461797305.8.0.0366988035454.issue26871@psf.upfronthosting.co.za>


Stefan Krah added the comment:

It seems that the patch also introduces a segfault if PyLong_FromSsize_t() returns NULL.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26871>
_______________________________________

From report at bugs.python.org  Wed Apr 27 19:34:30 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 27 Apr 2016 23:34:30 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1461800070.79.0.380143526076.issue26439@psf.upfronthosting.co.za>


Martin Panter added the comment:

I notice the patch is against Python 2, and uses Python 2 specific syntax. I am unsure if this kind of change is acceptable for 2.7, or if it would have to only go into 3.6. Hopefully this version of the patch will notify the review system that it is against Python 2.

----------
stage:  -> patch review
Added file: http://bugs.python.org/file42633/python.Lib.ctypes.160309.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Wed Apr 27 19:34:53 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 27 Apr 2016 23:34:53 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1461800093.01.0.24222027982.issue26439@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


Removed file: http://bugs.python.org/file42633/python.Lib.ctypes.160309.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Wed Apr 27 19:35:49 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 27 Apr 2016 23:35:49 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1461800149.93.0.704857414956.issue26439@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


Added file: http://bugs.python.org/file42634/python.Lib.ctypes.160317.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Wed Apr 27 21:46:42 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 Apr 2016 01:46:42 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1461808002.75.0.502746095646.issue26439@psf.upfronthosting.co.za>


Martin Panter added the comment:

I don?t know anything about AIX specific stuff, but I left some general comments in the code review.

Is there any chance that AIX people would be relying on the current behaviour that I understand uses _findSoname_ldconfig() and _findLib_gcc()?

Is this new functionality covered by the test suite? E.g. in /Lib/ctypes/test/test_find.py, there are tests that call find_library() for GL, GLU, and gle. Are those libraries common on AIX?

As discussed in Issue 9998, it seems a lot of people use find_library() to help convert a build-time library name to a run-time shared library name that can be passed to CDLL() or LoadLibrary(). E.g. on Linux:

>>> find_library("python2.7")  # As used in cc . . . -lpython2.7
'libpython2.7.so.1.0'
>>> cdll.LoadLibrary("libpython2.7.so.1.0")
<CDLL 'libpython2.7.so.1.0', handle 7f58e7495000 at 7f58e573ac90>

Does your patch support this kind of use case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Wed Apr 27 21:49:22 2016
From: report at bugs.python.org (Nathan Williams)
Date: Thu, 28 Apr 2016 01:49:22 +0000
Subject: [issue26873] xmlrpclib raises when trying to convert an int to string
 when unicode is available
Message-ID: <1461808162.86.0.277160090083.issue26873@psf.upfronthosting.co.za>


New submission from Nathan Williams:

I am using xmlrpclib against an internal xmlrpc server.
One of the responses returns integer values, and it raises an exception in "_stringify"

The code for _stringify is (xmlrpclib.py:180 in python2.7):

if unicode:
    def _stringify(string):
        # convert to 7-bit ascii if possible
        try:
            return string.encode("ascii")
        except UnicodeError:
            return string
else:
    def _stringify(string):
        return string


So when "unicode" is available, .encode is called on the parameter (which are the returned objects from the server) which fails for ints.

Without the unicode path it works fine, proven with the following monkey-patch:
xmlrpclib._stringify = lambda s: s

I am using the above patch as a workaround, but a fix to the library should be straightforward, simply checking for AttributeError in the except clause would solve it while retaining the existing functionality.


The traceback:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/xmlrpclib.py", line 1199, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib/python2.6/xmlrpclib.py", line 1489, in __request
    verbose=self.__verbose
  File "/usr/lib/python2.6/xmlrpclib.py", line 1253, in request
    return self._parse_response(h.getfile(), sock)
  File "/usr/lib/python2.6/xmlrpclib.py", line 1387, in _parse_response
    p.feed(response)
  File "/usr/lib/python2.6/xmlrpclib.py", line 601, in feed
    self._parser.Parse(data, 0)
  File "/usr/lib/python2.6/xmlrpclib.py", line 868, in end
    return f(self, join(self._data, ""))
  File "/usr/lib/python2.6/xmlrpclib.py", line 935, in end_struct
    dict[_stringify(items[i])] = items[i+1]
  File "/usr/lib/python2.6/xmlrpclib.py", line 176, in _stringify
    return string.encode("ascii")
AttributeError: 'int' object has no attribute 'encode'

----------
components: Library (Lib)
messages: 264407
nosy: Nathan Williams
priority: normal
severity: normal
status: open
title: xmlrpclib raises when trying to convert an int to string when unicode is available
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26873>
_______________________________________

From report at bugs.python.org  Thu Apr 28 00:10:22 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 28 Apr 2016 04:10:22 +0000
Subject: [issue20447] doctest.debug_script: insecure use of /tmp
In-Reply-To: <1391090625.54.0.961890812263.issue20447@psf.upfronthosting.co.za>
Message-ID: <1461816622.25.0.492390149588.issue20447@psf.upfronthosting.co.za>


Berker Peksag added the comment:

3.1 is now EOL: https://docs.python.org/devguide/index.html#status-of-python-branches

----------
nosy: +berker.peksag
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20447>
_______________________________________

From report at bugs.python.org  Thu Apr 28 00:36:10 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 28 Apr 2016 04:36:10 +0000
Subject: [issue20453] json.load() error message changed in 3.4
In-Reply-To: <1391162931.99.0.108127691347.issue20453@psf.upfronthosting.co.za>
Message-ID: <1461818170.0.0.755762187459.issue20453@psf.upfronthosting.co.za>


Berker Peksag added the comment:

3.4 is in security-fix-only mode and 3.5+ has better error messages thanks to JSONDecodeError (07af9847dbec). Closing this as 'out of date'.

----------
nosy: +berker.peksag
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20453>
_______________________________________

From report at bugs.python.org  Thu Apr 28 00:36:54 2016
From: report at bugs.python.org (Luiz Poleto)
Date: Thu, 28 Apr 2016 04:36:54 +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: <1461818214.34.0.761660337546.issue25461@psf.upfronthosting.co.za>


Luiz Poleto added the comment:

The change to os.rst is already committed so I modified the patch to remove it and keep only the change to os.py, which looks good and ready to be committed.

----------
Added file: http://bugs.python.org/file42635/issue25461.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25461>
_______________________________________

From report at bugs.python.org  Thu Apr 28 00:39:11 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Apr 2016 04:39:11 +0000
Subject: [issue26873] xmlrpclib raises when trying to convert an int to string
 when unicode is available
In-Reply-To: <1461808162.86.0.277160090083.issue26873@psf.upfronthosting.co.za>
Message-ID: <1461818351.44.0.139137372014.issue26873@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you provide a response of your server (pass verbose=True to ServerProxy)?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26873>
_______________________________________

From report at bugs.python.org  Thu Apr 28 00:44:10 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 28 Apr 2016 04:44:10 +0000
Subject: [issue1145257] shutil.copystat() may fail...
Message-ID: <1461818650.48.0.39508630857.issue1145257@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution: accepted -> out of date
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1145257>
_______________________________________

From report at bugs.python.org  Thu Apr 28 00:44:47 2016
From: report at bugs.python.org (Richard PALO)
Date: Thu, 28 Apr 2016 04:44:47 +0000
Subject: [issue19317] ctypes.util.find_library should examine binary's RPATH
 on Solaris
In-Reply-To: <1382283098.83.0.173984225129.issue19317@psf.upfronthosting.co.za>
Message-ID: <1461818687.45.0.832784843345.issue19317@psf.upfronthosting.co.za>


Richard PALO added the comment:

An example:

richard at omnis:/home/richard$ python2.7
Python 2.7.11 (default, Apr 27 2016, 04:35:25) 
[GCC 4.9.3] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import *
>>> from ctypes.util import find_library
>>> find_library('magic')
>>> cdll.LoadLibrary('libmagic.so')
<CDLL 'libmagic.so', handle fe240840 at fe7879ac>

Finally, as you can see above, LoadLibrary() works fine to load '/opt/local/libmagic.so' because of the runpath in the python binary, but find_library() does not because the runpath is ignored.

This should probably be considered as 'unexpected' behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19317>
_______________________________________

From report at bugs.python.org  Thu Apr 28 00:47:16 2016
From: report at bugs.python.org (Richard PALO)
Date: Thu, 28 Apr 2016 04:47:16 +0000
Subject: [issue19317] ctypes.util.find_library should examine binary's RPATH
 on Solaris
In-Reply-To: <1382283098.83.0.173984225129.issue19317@psf.upfronthosting.co.za>
Message-ID: <1461818836.26.0.251099483004.issue19317@psf.upfronthosting.co.za>


Richard PALO added the comment:

[fingers not yet warmed up] that is '/opt/local/lib/libmagic.so'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19317>
_______________________________________

From report at bugs.python.org  Thu Apr 28 01:13:46 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 28 Apr 2016 05:13:46 +0000
Subject: [issue26867] test_ssl test_options fails on ubuntu 16.04
In-Reply-To: <1461728238.71.0.110276038105.issue26867@psf.upfronthosting.co.za>
Message-ID: <1461820426.65.0.0466455910575.issue26867@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

After some test, I think the reason causing this error is due to SSL_CTX_clear_options. 

With OPENSSL_VERSION_NUMBER 268443775, SSL_CTX_clear_options(self->ctx, 2248147967) returns 33554432, where SSL_CTX_get_options returns 2248147967. From the manpage of SSL_CTX_clear_options, it seems it should return 0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26867>
_______________________________________

From report at bugs.python.org  Thu Apr 28 01:17:11 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 28 Apr 2016 05:17:11 +0000
Subject: [issue18551] child_exec() doesn't check return value of fcntl()
In-Reply-To: <1374695138.31.0.553729401393.issue18551@psf.upfronthosting.co.za>
Message-ID: <1461820631.71.0.803085218397.issue18551@psf.upfronthosting.co.za>


Berker Peksag added the comment:

There is one fcntl call in Modules/_posixsubprocess.c now and its return value is checked

    local_max_fd = fcntl(0, F_MAXFD);
    if (local_max_fd >= 0)

Closing this as 'out of date'.

----------
nosy: +berker.peksag
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18551>
_______________________________________

From report at bugs.python.org  Thu Apr 28 01:51:10 2016
From: report at bugs.python.org (Nathan Williams)
Date: Thu, 28 Apr 2016 05:51:10 +0000
Subject: [issue26873] xmlrpclib raises when trying to convert an int to string
 when unicode is available
In-Reply-To: <1461808162.86.0.277160090083.issue26873@psf.upfronthosting.co.za>
Message-ID: <1461822670.24.0.32939609969.issue26873@psf.upfronthosting.co.za>


Nathan Williams added the comment:

I have attached the response.
As it is coming from our UMS, I had to redact a few values, but that shouldn't matter.

For reference, they were the host name of my email address, and the hashes of passwords etc.
Our UMS is a bit too chatty!

----------
Added file: http://bugs.python.org/file42636/pybug.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26873>
_______________________________________

From report at bugs.python.org  Thu Apr 28 01:59:26 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 28 Apr 2016 05:59:26 +0000
Subject: [issue26867] test_ssl test_options fails on ubuntu 16.04
In-Reply-To: <1461728238.71.0.110276038105.issue26867@psf.upfronthosting.co.za>
Message-ID: <1461823166.81.0.681038613192.issue26867@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

>From the source code (get from apt-get source) of openssl-1.0.2g, I find

SSL_CTX_clear_options(ctx, op):
  op &= ~SSL_OP_NO_SSLv3
  return (ctx->options &= ~op)
SSL_CTX_set_options(ctx, op):
  op |= SSL_OP_NO_SSLv3
  return (ctx->options |= op)

which differs from the official code repos:

SSL_CTX_clear_options(ctx, op):
  return (ctx->options &= ~op)
SSL_CTX_set_options(ctx, op):
  return (ctx->options |= op)

This difference is introduced by debian-specific patch:

     case SSL_CTRL_OPTIONS:
+        larg|=SSL_OP_NO_SSLv3;
         return (ctx->options |= larg);
     case SSL_CTRL_CLEAR_OPTIONS:
+        larg&=~SSL_OP_NO_SSLv3;
         return (ctx->options &= ~larg);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26867>
_______________________________________

From report at bugs.python.org  Thu Apr 28 02:42:47 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 28 Apr 2016 06:42:47 +0000
Subject: [issue26860] os.walk and os.fwalk yield namedtuple instead of tuple
In-Reply-To: <1461678306.82.0.694875654943.issue26860@psf.upfronthosting.co.za>
Message-ID: <1461825767.87.0.446892580426.issue26860@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Classes are normally named with CamelCase.  Also, "walk_result" or "WalkResult" seems like an odd name that doesn't really fit.   DirEntry or DirInfo is a better match (see the OP's example, "for dir_entry in walk_it: ...")

The "versionchanged" should be a "versionadded".

The docs should use "named tuple" instead of "namedtuple".  The former is the generic term used in the glossary to describe the instances.  The latter is the factory function that creates a new tuple subclass.

The attribute descriptions for the docs are pretty good.  They should also be applied as actual docstrings in the code as well.

The docs and code for fwalk() needs to be harmonized with walk() so the the tuple fields use the same names:  change (root, dirs, files) to (dirpath, dirnames, filenames).

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26860>
_______________________________________

From report at bugs.python.org  Thu Apr 28 02:43:36 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 Apr 2016 06:43:36 +0000
Subject: [issue19317] ctypes.util.find_library should examine binary's RPATH
 on Solaris
In-Reply-To: <1382283098.83.0.173984225129.issue19317@psf.upfronthosting.co.za>
Message-ID: <1461825816.93.0.652872207551.issue19317@psf.upfronthosting.co.za>


Martin Panter added the comment:

I am realizing that many people like to use find_library() as a way of converting a portable name like ?magic? (from building with -lmagic) into a platform-specific name (libmagic.so.1, libmagic.dylib, magic.dll, etc), and then pass this to LoadLibrary() or equivalent. So searching Python?s runpath would probably be valid for that use case.

IMO the extra searching is inefficient, and not robust if there is more than one version of the library. Personally I would be more interested in adding an alternative function, maybe make_library_name("magic", "1") -> "libmagic.so.1", or cdll.LoadLibraryByPortableName("magic", "1").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19317>
_______________________________________

From report at bugs.python.org  Thu Apr 28 03:08:02 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Apr 2016 07:08:02 +0000
Subject: [issue26873] xmlrpclib raises when trying to convert an int to string
 when unicode is available
In-Reply-To: <1461808162.86.0.277160090083.issue26873@psf.upfronthosting.co.za>
Message-ID: <1461827282.45.0.348807391777.issue26873@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you. Your server produces a response containing nonstandard type tag "ex:nil" [1].

    <member><name>authority</name><value>ROLE_USER</value></member>
    <member><name>fromDate</name><value><ex:nil/></value></member>
    <member><name>userId</name><value><i4>15</i4></value></member>

xmlrpclib is unable to handle this tag, and error handling is poor. xmlrpclib can handle only standard types and "nil" [2].

What is worse, xmlrpclib silently ignores unsupported tag and interprets following name "userId" as a value of the name "fromDate", and following userId's value 15 as next name and so forth. Your workaround doesn't help since the result is totally broken. You get values as keys and keys as values.

What can we do with this issue?

1. Add better handling of unsupported tags. There is a bug, xmlrpc should detect this case and fail instead of producing unreliable result. This is applicable to 2.7.

2. Add support of some Apache extension tags. This is new feature and can be added in 3.6 only. Not all extension tags can be supported, "ex:serializable" is Java specific. This is separate issue.

Martin, do you agree?

[1] http://ws.apache.org/xmlrpc/types.html
[2] http://web.archive.org/web/20130120074804/http://ontosys.com/xml-rpc/extensions.php

----------
assignee:  -> serhiy.storchaka
nosy: +loewis
stage:  -> needs patch
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26873>
_______________________________________

From report at bugs.python.org  Thu Apr 28 04:00:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Apr 2016 08:00:48 +0000
Subject: [issue26860] os.walk and os.fwalk yield namedtuple instead of tuple
In-Reply-To: <1461678306.82.0.694875654943.issue26860@psf.upfronthosting.co.za>
Message-ID: <1461830448.06.0.724020923241.issue26860@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Sorry, but I disagree with Raymond in many points.

> Classes are normally named with CamelCase.  Also, "walk_result" or "WalkResult" seems like an odd name that doesn't really fit.   DirEntry or DirInfo is a better match (see the OP's example, "for dir_entry in walk_it: ...")

See "stat_result", "statvfs_result", "waitid_result", "uname_result", and "times_result". DirEntry is already used in the os module. And if accept this feature, needed separate types for walk() and fwalk() results.

> The "versionchanged" should be a "versionadded".

os.walk() is not new. Just it's result is changed. Class "walk_result" can be tagged with "versionadded", but I'm not sure there is a need to document it separately. The documentation of the os module already too large. "uname_result" and "times_result" are not documented.

> The docs and code for fwalk() needs to be harmonized with walk() so the the tuple fields use the same names:  change (root, dirs, files) to (dirpath, dirnames, filenames).

(root, dirs, files) is shorter than (dirpath, dirnames, filenames) and these names were used with os.walk() and os.fwalk() for years.

I general, I have doubts about this feature.

1. There is little backward incompatibility. At least pickle is not backward compatible, and I guess other serialization methods.

2. os.walk() and os.fwalk() are purposed to be used in for loop with immediate unpacking result tuple:

    for root, dirs, files in os.walk(...):
        ...

Adding named tuple doesn't add any benefit for common case.

In OP case, you can either use fwalk-based implementation of walk (issue15200):

    def fwalk_as_walk(*args, **kwargs):
        for x in os.fwalk(*args, **kwargs):
            yield x[:-1]

or just ignore the rest of tuple items:

    for root, *_ in walk_it:
        ...

3. Using namedtuple is slower and consumes more memory than using tuple. Even for FS-related operation like os.walk() this can matter. A lot of code is optimized for exact tuples, with namedtuple this optimization is lost.

4. New names (dirpath, dirnames, filenames) are questionable. Why not use undersores (dir_names)? "dir" in dirpath refers to the current proceeded directory, but "dir" in dirnames refers to it's subdirectories. Currently you are free to use short names (root, dirs, files) from examples or what you prefer, but with namedtuple you are sticked with standard names forever. There are no names that satisfy everybody.

5. Third-party walk-like iterators generate tuples, so you can't use attribute access in too general code.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26860>
_______________________________________

From report at bugs.python.org  Thu Apr 28 04:01:03 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 28 Apr 2016 08:01:03 +0000
Subject: [issue26853] missing symbols in curses and readline modules on android
In-Reply-To: <1461675697.75.0.0916516767531.issue26853@psf.upfronthosting.co.za>
Message-ID: <1461830463.52.0.598185969658.issue26853@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Thanks Chi Hsuan Yen and Stefan. Indeed the --with-termlib configure option documentation states: "When building the ncurses library, organize this as two parts:  the curses library (libncurses) and the low-level terminfo library (libtinfo)". Using --without-termlib prevents that split.

My previous comment about readelf is wrong, the gcc cross-compiler is in the $PATH directory search path, as well as readelf.

Closing this issue as not a bug.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26853>
_______________________________________

From report at bugs.python.org  Thu Apr 28 04:04:55 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Apr 2016 08:04:55 +0000
Subject: [issue26871] Change weird behavior of PyModule_AddObject()
In-Reply-To: <1461779571.56.0.960686965696.issue26871@psf.upfronthosting.co.za>
Message-ID: <1461830695.44.0.689724804829.issue26871@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> It seems that the patch also introduces a segfault if PyLong_FromSsize_t() returns NULL.

Good catch Stefan! Py_XDECREF ahould be used instead of Py_DECREF in _PyModule_AddObject().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26871>
_______________________________________

From report at bugs.python.org  Thu Apr 28 05:20:06 2016
From: report at bugs.python.org (Thomas Guettler)
Date: Thu, 28 Apr 2016 09:20:06 +0000
Subject: [issue26869] unittest longMessage docs
In-Reply-To: <1461743267.94.0.620093650485.issue26869@psf.upfronthosting.co.za>
Message-ID: <1461835206.18.0.408362693717.issue26869@psf.upfronthosting.co.za>


Thomas Guettler added the comment:

Thank you for understanding my concern.



> The standard failure message for each *assert method* contains useful  
> information about the objects involved.  For example the message from 
> assertEqual shows the repr of the two unequal objects.  It is usually 
> easier to augment rather than replace this message

I think above is not needed.


> The class setting can be overridden in individual test methods by 
> assigning an instance attribute, self.longMessage, to True or False 
> before calling the assert methods.

I would add "the default value of the class gets reset before each test call". That is more explicit (I hope my text is what happens behind the scene)

Again, thank you, that you care.

Regards,
  Thomas G?ttler

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26869>
_______________________________________

From report at bugs.python.org  Thu Apr 28 05:25:33 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 28 Apr 2016 09:25:33 +0000
Subject: [issue24114] ctypes.utils uninitialized variable 'paths'
In-Reply-To: <1430578995.23.0.112303250331.issue24114@psf.upfronthosting.co.za>
Message-ID: <1461835533.27.0.235741252078.issue24114@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Simply add one line to make the function theoretically more robust.

----------
nosy: +xiang.zhang
Added file: http://bugs.python.org/file42637/issue24114.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24114>
_______________________________________

From report at bugs.python.org  Thu Apr 28 05:54:07 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 28 Apr 2016 09:54:07 +0000
Subject: [issue26358] mmap.mmap.__iter__ is broken (yields bytes instead of
 ints)
In-Reply-To: <1455421066.19.0.307034706486.issue26358@psf.upfronthosting.co.za>
Message-ID: <1461837247.34.0.159934451481.issue26358@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26358>
_______________________________________

From report at bugs.python.org  Thu Apr 28 05:54:15 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 28 Apr 2016 09:54:15 +0000
Subject: [issue24434] ItemsView.__contains__ does not mimic dict_items
In-Reply-To: <1434050451.28.0.415875303865.issue24434@psf.upfronthosting.co.za>
Message-ID: <1461837255.63.0.890524588883.issue24434@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24434>
_______________________________________

From report at bugs.python.org  Thu Apr 28 06:15:37 2016
From: report at bugs.python.org (Kees Bos)
Date: Thu, 28 Apr 2016 10:15:37 +0000
Subject: [issue24114] ctypes.utils uninitialized variable 'paths'
In-Reply-To: <1430578995.23.0.112303250331.issue24114@psf.upfronthosting.co.za>
Message-ID: <1461838537.22.0.7383752204.issue24114@psf.upfronthosting.co.za>


Kees Bos added the comment:

It's not entirely theoretical to me. I inherited some solaris boxes that cannot be properly maintained anymore and that have a clre program that dumps core. Hence no valid output and running into uninitialized 'paths'. The patch from Xiang Zhang will fix that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24114>
_______________________________________

From report at bugs.python.org  Thu Apr 28 07:02:54 2016
From: report at bugs.python.org (Antti Haapala)
Date: Thu, 28 Apr 2016 11:02:54 +0000
Subject: [issue22234] urllib.parse.urlparse accepts any falsy value as an url
In-Reply-To: <1408538391.97.0.53072227801.issue22234@psf.upfronthosting.co.za>
Message-ID: <1461841374.67.0.247530851738.issue22234@psf.upfronthosting.co.za>


Antti Haapala added the comment:

I do not believe there is code that would depend on `urlparse(urlstring={})` *not* throwing an error, since `{}` obviously is neither a URL, nor a string.

Further down the documentation explicitly states that

> The URL parsing functions were originally designed to operate on 
> character strings only. In practice, it is useful to be able to 
> manipulate properly quoted and encoded URLs as sequences of ASCII 
> bytes. Accordingly, the URL parsing functions in this module all 
> operate on bytes and bytearray objects in addition to str objects.

As the documentation does not state that it should work on any other objects, there shouldn't be any code that should be deprecated. Furthermore even in 3.5, the `bool(datetime.time(0, 0)) == False` was removed without any deprecation cycle, despite it having been a documented feature for more than a decade (unlike this one).

And IMHO not giving an object of expected type should result in a TypeError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22234>
_______________________________________

From report at bugs.python.org  Thu Apr 28 08:28:19 2016
From: report at bugs.python.org (Meador Inge)
Date: Thu, 28 Apr 2016 12:28:19 +0000
Subject: [issue24114] ctypes.utils uninitialized variable 'paths'
In-Reply-To: <1430578995.23.0.112303250331.issue24114@psf.upfronthosting.co.za>
Message-ID: <1461846499.42.0.921057672706.issue24114@psf.upfronthosting.co.za>


Meador Inge added the comment:

Xiang's patch LGTM.  Given that Kees has verified it, I will apply today.

----------
assignee:  -> meador.inge
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24114>
_______________________________________

From report at bugs.python.org  Thu Apr 28 09:11:47 2016
From: report at bugs.python.org (Marcos Dione)
Date: Thu, 28 Apr 2016 13:11:47 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module and use
 it to improve shutils.copy()
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1461849107.0.0.137361214121.issue26826@psf.upfronthosting.co.za>


Marcos Dione added the comment:

> About changing copyfileobj(), here are some test cases which may help explain the compatibility problems:

I see, I was expecting something like that after reading https://bugs.python.org/issue25063 's conclusions. I removed that part.

> Perhaps we could keep the new version as a high-level copy_file_range() wrapper, but retain brute_force_copy() under the original copyfileobj() name. A bit like the socket.sendfile() method vs os.sendfile().

You mean having always a copy_file_range() method that in the worst case would fallback to copyfileobj()? I'm considering using it to optimize copyfile() (and indirectly copy() and copy2()) instead. 

And sorry for the patch wrong format.

----------
Added file: http://bugs.python.org/file42638/copy_file_range.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Thu Apr 28 10:10:47 2016
From: report at bugs.python.org (Marcos Dione)
Date: Thu, 28 Apr 2016 14:10:47 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module.
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1461852647.53.0.111080787939.issue26826@psf.upfronthosting.co.za>


Marcos Dione added the comment:

I'll do the copyfile() part once I'm convinced it doesn't break anything else.

----------
title: Expose new copy_file_range() syscal in os module and use it to improve shutils.copy() -> Expose new copy_file_range() syscal in os module.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Thu Apr 28 10:31:57 2016
From: report at bugs.python.org (Robert Collins)
Date: Thu, 28 Apr 2016 14:31:57 +0000
Subject: [issue26859] unittest fails with "Start directory is not importable"
In-Reply-To: <1461678137.48.0.743276761028.issue26859@psf.upfronthosting.co.za>
Message-ID: <1461853917.65.0.0503238857954.issue26859@psf.upfronthosting.co.za>


Robert Collins added the comment:

Could you please add a test case.

----------
nosy: +rbcollins
stage: patch review -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26859>
_______________________________________

From report at bugs.python.org  Thu Apr 28 11:19:45 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Apr 2016 15:19:45 +0000
Subject: [issue26871] Change weird behavior of PyModule_AddObject()
In-Reply-To: <1461779571.56.0.960686965696.issue26871@psf.upfronthosting.co.za>
Message-ID: <1461856785.26.0.483300274662.issue26871@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Removed changes in _decimal.c and deprecation. Used Py_XDECREF in _PyModule_AddObject().

----------
Added file: http://bugs.python.org/file42639/pymodule_addobject_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26871>
_______________________________________

From report at bugs.python.org  Thu Apr 28 11:26:33 2016
From: report at bugs.python.org (Marcos Dione)
Date: Thu, 28 Apr 2016 15:26:33 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module.
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1461857193.12.0.566592040343.issue26826@psf.upfronthosting.co.za>


Marcos Dione added the comment:

I managed to modify the congigure.ac file so it includes the proper test. after I run autoconf it generated the proper configure script, but I also needed to run autoheaders (both run by make autoconf). This last command modified a generated file that's in the repo, so I'm adding its diff too, but I'm not sure if that's ok.

----------
Added file: http://bugs.python.org/file42640/copy_file_range.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Thu Apr 28 11:31:14 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 28 Apr 2016 15:31:14 +0000
Subject: [issue26868] Document PyModule_AddObject's behavior on error
In-Reply-To: <1461735404.8.0.653639688918.issue26868@psf.upfronthosting.co.za>
Message-ID: <1461857474.96.0.140607526229.issue26868@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
title: Incorrect check for return value of PyModule_AddObject in _csv.c -> Document PyModule_AddObject's behavior on error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26868>
_______________________________________

From report at bugs.python.org  Thu Apr 28 12:08:50 2016
From: report at bugs.python.org (mbarao)
Date: Thu, 28 Apr 2016 16:08:50 +0000
Subject: [issue26874] Docstring error in divmod function
Message-ID: <1461859730.5.0.461826994455.issue26874@psf.upfronthosting.co.za>


New submission from mbarao:

The documentation of the divmod function says that a tuple ((x-x%y)/y, x%y) is returned, but this is not correct anymore for python3.
I think it should be ((x-x%y)//y, x%y) where an integer division is used.

----------
assignee: docs at python
components: Documentation
messages: 264434
nosy: docs at python, mbarao
priority: normal
severity: normal
status: open
title: Docstring error in divmod function
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26874>
_______________________________________

From report at bugs.python.org  Thu Apr 28 12:31:46 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Thu, 28 Apr 2016 16:31:46 +0000
Subject: [issue26874] Docstring error in divmod function
In-Reply-To: <1461859730.5.0.461826994455.issue26874@psf.upfronthosting.co.za>
Message-ID: <1461861106.38.0.024756295167.issue26874@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

The documentation looks fine to me. Are you seeing any other place that I'm missing?

https://docs.python.org/3/library/functions.html#divmod

----------
nosy: +ebarry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26874>
_______________________________________

From report at bugs.python.org  Thu Apr 28 12:50:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Apr 2016 16:50:22 +0000
Subject: [issue26873] xmlrpclib raises when trying to convert an int to string
 when unicode is available
In-Reply-To: <1461808162.86.0.277160090083.issue26873@psf.upfronthosting.co.za>
Message-ID: <1461862222.01.0.732917903153.issue26873@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Minimal reproducer:

>>> xmlrpclib.loads('<params><param><value><struct><member><name>a</name><value><ex:nil/></value></member><member><name>b</name><value><ex:nil/></value></member></struct></value></param></params>')
(({'a': 'b'},), None)

The workaround for your particular case, Nathan:

    xmlrpclib.Unmarshaller.dispatch['ex:nil'] = xmlrpclib.Unmarshaller.dispatch['nil']

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26873>
_______________________________________

From report at bugs.python.org  Thu Apr 28 12:56:43 2016
From: report at bugs.python.org (mbarao)
Date: Thu, 28 Apr 2016 16:56:43 +0000
Subject: [issue26874] Docstring error in divmod function
In-Reply-To: <1461859730.5.0.461826994455.issue26874@psf.upfronthosting.co.za>
Message-ID: <1461862603.77.0.422286926602.issue26874@psf.upfronthosting.co.za>


mbarao added the comment:

See divmod.__doc__

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26874>
_______________________________________

From report at bugs.python.org  Thu Apr 28 13:37:13 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 28 Apr 2016 17:37:13 +0000
Subject: [issue26875] mmap doc gives wrong code example
Message-ID: <1461865033.17.0.77697230941.issue26875@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

The code given in mmap doc

import mmap

with mmap.mmap(-1, 13) as mm:
    mm.write("Hello world!")

should be

mm.write(b"Hello world!")

The *b* is left out and then causes exception.

----------
assignee: docs at python
components: Documentation
files: mmap_doc.patch
keywords: patch
messages: 264438
nosy: docs at python, xiang.zhang
priority: normal
severity: normal
status: open
title: mmap doc gives wrong code example
Added file: http://bugs.python.org/file42641/mmap_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26875>
_______________________________________

From report at bugs.python.org  Thu Apr 28 14:01:37 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Apr 2016 18:01:37 +0000
Subject: [issue26874] Docstring error in divmod function
In-Reply-To: <1461859730.5.0.461826994455.issue26874@psf.upfronthosting.co.za>
Message-ID: <1461866497.2.0.314067910108.issue26874@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +eric.smith, lemburg, mark.dickinson, stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26874>
_______________________________________

From report at bugs.python.org  Thu Apr 28 14:05:20 2016
From: report at bugs.python.org (Rohit Jamuar)
Date: Thu, 28 Apr 2016 18:05:20 +0000
Subject: [issue26876] Extend MSVCCompiler class to respect environment
 variables
Message-ID: <1461866719.82.0.2605655084.issue26876@psf.upfronthosting.co.za>


New submission from Rohit Jamuar:

The UnixCompiler class respects flags (CC, LD, AR, CFLAGS and LDFLAGS) set to the environment, whereas MSVCCompiler class does not. This change allows building CPython and any module that invokes distutils to utilize flags and executables that have been set to the environment. Inclusion of this change would ensure MSVCCompiler's behavior to be same as that of UnixCompiler and would also allow using a different set of compiler / linker / archiver, on Windows, without having the necessity for implementing separate compiler classes - using environment variables it should be possible to use a separate set of build executables - for example icl, clang, etc.

----------
components: Distutils
files: msvc_respect_env_flags.patch
keywords: patch
messages: 264439
nosy: dstufft, eric.araujo, r.david.murray, rohitjamuar, zach.ware
priority: normal
severity: normal
status: open
title: Extend MSVCCompiler class to respect environment variables
type: enhancement
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file42642/msvc_respect_env_flags.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26876>
_______________________________________

From report at bugs.python.org  Thu Apr 28 15:10:40 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 28 Apr 2016 19:10:40 +0000
Subject: [issue26874] Docstring error in divmod function
In-Reply-To: <1461859730.5.0.461826994455.issue26874@psf.upfronthosting.co.za>
Message-ID: <1461870640.55.0.0273510348993.issue26874@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> I think it should be ((x-x%y)//y, x%y) where an integer division is used.

How about simply (x//y, x%y)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26874>
_______________________________________

From report at bugs.python.org  Thu Apr 28 15:26:39 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Apr 2016 19:26:39 +0000
Subject: [issue26874] Docstring error in divmod function
In-Reply-To: <1461859730.5.0.461826994455.issue26874@psf.upfronthosting.co.za>
Message-ID: <20160428192556.35283.66504.EEACDF45@psf.io>


Roundup Robot added the comment:

New changeset fb49082a75d1 by Zachary Ware in branch '2.7':
Issue #26874: Make divmod docstring and full doc match
https://hg.python.org/cpython/rev/fb49082a75d1

New changeset ef193be5c3cd by Zachary Ware in branch '3.5':
Issue #26874: Fix divmod docstring
https://hg.python.org/cpython/rev/ef193be5c3cd

New changeset 28c89ebd6e5a by Zachary Ware in branch 'default':
Closes #26874: Merge with 3.5
https://hg.python.org/cpython/rev/28c89ebd6e5a

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26874>
_______________________________________

From report at bugs.python.org  Thu Apr 28 15:28:45 2016
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 28 Apr 2016 19:28:45 +0000
Subject: [issue26874] Docstring error in divmod function
In-Reply-To: <1461859730.5.0.461826994455.issue26874@psf.upfronthosting.co.za>
Message-ID: <1461871725.2.0.229596921831.issue26874@psf.upfronthosting.co.za>


Zachary Ware added the comment:

If only I had reloaded the page before pushing...

Btw, this was first reported in issue1209411, but only the docs were changed, not the docstring.

----------
nosy: +zach.ware
resolution: fixed -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26874>
_______________________________________

From report at bugs.python.org  Thu Apr 28 15:40:47 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Apr 2016 19:40:47 +0000
Subject: [issue26874] Docstring error in divmod function
In-Reply-To: <1461859730.5.0.461826994455.issue26874@psf.upfronthosting.co.za>
Message-ID: <20160428194036.18199.94644.D0CDA0DD@psf.io>


Roundup Robot added the comment:

New changeset 5a578ec4b3b3 by Zachary Ware in branch '2.7':
Issue #26874: Simplify the divmod docstring.
https://hg.python.org/cpython/rev/5a578ec4b3b3

New changeset 3edf8aa1ed97 by Zachary Ware in branch '3.5':
Issue #26874: Simplify the divmod docstring
https://hg.python.org/cpython/rev/3edf8aa1ed97

New changeset c6e285789963 by Zachary Ware in branch 'default':
Closes #26874: Merge with 3.5
https://hg.python.org/cpython/rev/c6e285789963

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26874>
_______________________________________

From report at bugs.python.org  Thu Apr 28 15:46:45 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Apr 2016 19:46:45 +0000
Subject: [issue26873] xmlrpclib raises when trying to convert an int to string
 when unicode is available
In-Reply-To: <1461808162.86.0.277160090083.issue26873@psf.upfronthosting.co.za>
Message-ID: <1461872805.42.0.849589001785.issue26873@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Proposed patch makes xmlrpc unmarshaller to be more strong and raise ValueError instead of returning incorrect value when encounters with unsupported value type. The unmarshaller still skips unknown tags silently if they are occurred outside of the "value" element.

----------
keywords: +patch
stage: needs patch -> patch review
versions: +Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42643/xmlrpc_unsupported.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26873>
_______________________________________

From report at bugs.python.org  Thu Apr 28 15:48:00 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Apr 2016 19:48:00 +0000
Subject: [issue26875] mmap doc gives wrong code example
In-Reply-To: <1461865033.17.0.77697230941.issue26875@psf.upfronthosting.co.za>
Message-ID: <20160428194757.13860.23379.5F653F32@psf.io>


Roundup Robot added the comment:

New changeset 5c8e1b98dc3f by Zachary Ware in branch '3.5':
Issue #26875: Fix mmap example
https://hg.python.org/cpython/rev/5c8e1b98dc3f

New changeset aaf2ad84ae1c by Zachary Ware in branch 'default':
Closes #26875: Merge with 3.5
https://hg.python.org/cpython/rev/aaf2ad84ae1c

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26875>
_______________________________________

From report at bugs.python.org  Thu Apr 28 15:48:43 2016
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 28 Apr 2016 19:48:43 +0000
Subject: [issue26875] mmap doc gives wrong code example
In-Reply-To: <1461865033.17.0.77697230941.issue26875@psf.upfronthosting.co.za>
Message-ID: <1461872923.16.0.496214651116.issue26875@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thanks for the report and patch!

----------
nosy: +zach.ware
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26875>
_______________________________________

From report at bugs.python.org  Thu Apr 28 15:52:26 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Apr 2016 19:52:26 +0000
Subject: [issue22477] GCD in Fractions
In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za>
Message-ID: <1461873146.52.0.35681138477.issue22477@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Is there something to do with this issue?

----------
nosy: +serhiy.storchaka
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22477>
_______________________________________

From report at bugs.python.org  Thu Apr 28 16:25:25 2016
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 28 Apr 2016 20:25:25 +0000
Subject: [issue26876] Extend MSVCCompiler class to respect environment
 variables
In-Reply-To: <1461866719.82.0.2605655084.issue26876@psf.upfronthosting.co.za>
Message-ID: <1461875125.17.0.898985861889.issue26876@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I can't seem to get the patch to apply, could you please regenerate it against a fresh checkout of https://hg.python.org/cpython#default (or 'master' of github.com/python/cpython)?

This looks fairly straightforward, but I'm far from an expert on distutils :).  I can see issues arising from attempts to use a compiler/linker/etc. that doesn't recognize options that we assume are going to cl/link/etc., but I'm not sure how big a deal that is: I'd be inclined to say that if you're trying to tell distutils where cl is, don't get mad when what you told it doesn't work.

Also, I don't think Lib/distutils/msvccompiler.py is used anymore, but rather Lib/distutils/_msvccompiler.py in 3.5+.

I'm generally in favor of this, but would feel much better about it with buy-in from Steve.

There has also been mention of creating a new ICCCompiler class, but I'm not sure whether that has gotten anywhere.

----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26876>
_______________________________________

From report at bugs.python.org  Thu Apr 28 16:26:00 2016
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 28 Apr 2016 20:26:00 +0000
Subject: [issue26876] Extend MSVCCompiler class to respect environment
 variables
In-Reply-To: <1461866719.82.0.2605655084.issue26876@psf.upfronthosting.co.za>
Message-ID: <1461875160.64.0.424208931.issue26876@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: +christopher.hogan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26876>
_______________________________________

From report at bugs.python.org  Thu Apr 28 16:55:25 2016
From: report at bugs.python.org (Steve Dower)
Date: Thu, 28 Apr 2016 20:55:25 +0000
Subject: [issue26876] Extend MSVCCompiler class to respect environment
 variables
In-Reply-To: <1461866719.82.0.2605655084.issue26876@psf.upfronthosting.co.za>
Message-ID: <1461876925.47.0.0269800625783.issue26876@psf.upfronthosting.co.za>


Steve Dower added the comment:

I'm neutral about applying it to 2.7, though I can see the value in doing so.

For 3.5 it definitely has to modify _msvccompiler - the other two modules are just left behind to distract people apparently :) (but actually in case someone accidentally(?) too a direct dependency on an undocumented class).

One thing I'd like to see is an environment variable to switch it on - probably DISTUTILS_USE_SDK is fine for this. In the default case, we know exactly where we are looking for the tools, and so we know what they are called. If you're intending to override this completely, you probably need to override everything, and DISTUTILS_USE_SDK is the flag for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26876>
_______________________________________

From report at bugs.python.org  Thu Apr 28 17:44:42 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Thu, 28 Apr 2016 21:44:42 +0000
Subject: [issue26877] tarfile use wrong code when read from fileobj
Message-ID: <1461879882.57.0.719679075431.issue26877@psf.upfronthosting.co.za>


New submission from ???? ?????????:

tarfile.py: _FileInFile():

(near line 687)

b = self.fileobj.read(length)
if len(b) != length:
    raise ReadError("unexpected end of data")

every read() API does not guarantee that it will read `length` bytes. So, if fileobj reads less than requestedm that is not an error (!)

In my case it was a pipe...

----------
components: Library (Lib)
messages: 264450
nosy: mmarkk
priority: normal
severity: normal
status: open
title: tarfile use wrong code when read from fileobj
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26877>
_______________________________________

From report at bugs.python.org  Thu Apr 28 17:56:45 2016
From: report at bugs.python.org (Michael Felt)
Date: Thu, 28 Apr 2016 21:56:45 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1461880605.42.0.911536132019.issue26439@psf.upfronthosting.co.za>


Michael Felt added the comment:

I have not looked specifically, at least not that I remember, for differences in util/ctypes in python2 and python3. Will do so tomorrow.

I did just look briefly at the library, rather archive, built by default as libpython2.7.a - it is static members only, i.e., my build using xlc (i.e., not using gcc) does not build a shared object, so cdll.LoadLibrary and/or find_library will not find anything for python2.7.. Neither will m, or libm, on a default AIX system (with no other gcc based packages installed - these also install a gnu rte where the utilities and libs you mention might include.

The few python packages I have found, packaged by others, tend to reload everything yet again, not depending on anything that may already be there. And to use shared libraries they are extracting the members from the .a archives into two directories - when they support both 32 and 64-bit targets.

My intent is to examine the program to discover where libraries should be and find the member name that is most likely. Also, if LIBPATH is defined, those directories are searched first for a match.

In short, the key difference is to look at the program (probably python) for the blibpath string in the application as well as python (from memory, sys.* calls) to build a list of directories to search.

findLibrary('foo') first finds libfoo.a, then looks in libfoo.a for shr*.o members, libfoo.so, libfoo.so.X and/or libfoo.so.X.Y, etc..

I need to check that findLibrary('foo.so') continues to work. At one time it did, just have not looked at this for several weeks and I forget if it still works. That is what I shall make sure stays in the "testing" part of the patch.

Michael

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Thu Apr 28 18:18:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Apr 2016 22:18:33 +0000
Subject: [issue26877] tarfile use wrong code when read from fileobj
In-Reply-To: <1461879882.57.0.719679075431.issue26877@psf.upfronthosting.co.za>
Message-ID: <1461881913.47.0.990803158463.issue26877@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26877>
_______________________________________

From report at bugs.python.org  Thu Apr 28 18:25:26 2016
From: report at bugs.python.org (DqASe)
Date: Thu, 28 Apr 2016 22:25:26 +0000
Subject: [issue26878] Allow doctest to deep copy globals
Message-ID: <1461882326.3.0.694986363749.issue26878@psf.upfronthosting.co.za>


New submission from DqASe:

Currently doctest makes shallow copies of the environment or globs argument.  This is somewhat un-symmetrical: on the one hand, a test cannot see variables created by another, but on the other, it can alter mutable objects.  This is inconvenient e.g. when documenting several methods that change an object (say, obj.append() , then obj.insert() - one would hope that the results are independent on the order tests are executed ).

An option to make deep copies of the variables in the context, instead of shallow ones, would in my opinion solve the issue cleanly.

----------
components: Library (Lib)
messages: 264452
nosy: DqASe
priority: normal
severity: normal
status: open
title: Allow doctest to deep copy globals
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26878>
_______________________________________

From report at bugs.python.org  Thu Apr 28 18:29:03 2016
From: report at bugs.python.org (DqASe)
Date: Thu, 28 Apr 2016 22:29:03 +0000
Subject: [issue26878] Allow doctest to deep copy globals
In-Reply-To: <1461882326.3.0.694986363749.issue26878@psf.upfronthosting.co.za>
Message-ID: <1461882543.21.0.572637164449.issue26878@psf.upfronthosting.co.za>


Changes by DqASe <DqASe at mailinator.com>:


----------
components: +Tests -Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26878>
_______________________________________

From report at bugs.python.org  Thu Apr 28 18:41:40 2016
From: report at bugs.python.org (DqASe)
Date: Thu, 28 Apr 2016 22:41:40 +0000
Subject: [issue26878] Allow doctest to deep copy globals
In-Reply-To: <1461882326.3.0.694986363749.issue26878@psf.upfronthosting.co.za>
Message-ID: <1461883300.71.0.433107620116.issue26878@psf.upfronthosting.co.za>


DqASe added the comment:

Alternatively, add an option like deepglobs={...} . The dictionary argument would be deep-copied at each test and added to the environment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26878>
_______________________________________

From report at bugs.python.org  Thu Apr 28 18:59:59 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Thu, 28 Apr 2016 22:59:59 +0000
Subject: [issue26877] tarfile use wrong code when read from fileobj
In-Reply-To: <1461879882.57.0.719679075431.issue26877@psf.upfronthosting.co.za>
Message-ID: <1461884399.52.0.853398868948.issue26877@psf.upfronthosting.co.za>


???? ????????? added the comment:

The same in tarfile.copyfileobj()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26877>
_______________________________________

From report at bugs.python.org  Thu Apr 28 19:39:25 2016
From: report at bugs.python.org (Rogi)
Date: Thu, 28 Apr 2016 23:39:25 +0000
Subject: [issue26879] new message
Message-ID: <00004ebffd0d$54a76e66$dd6b35d1$@linuxmail.org>


New submission from Rogi:

Hello!

You have a new message, please read <http://www.gazzaz.com.sa/territory.php?v>

rogi at linuxmail.org

----------
messages: 264455
nosy: Rogi
priority: normal
severity: normal
status: open
title: new message

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26879>
_______________________________________

From report at bugs.python.org  Thu Apr 28 19:44:52 2016
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 28 Apr 2016 23:44:52 +0000
Subject: [issue26879] new message
In-Reply-To: <00004ebffd0d$54a76e66$dd6b35d1$@linuxmail.org>
Message-ID: <1461887092.89.0.210398781118.issue26879@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26879>
_______________________________________

From report at bugs.python.org  Thu Apr 28 19:51:45 2016
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 28 Apr 2016 23:51:45 +0000
Subject: [issue26879] Spam
In-Reply-To: <00004ebffd0d$54a76e66$dd6b35d1$@linuxmail.org>
Message-ID: <1461887505.59.0.223014863383.issue26879@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy:  -Rogi
title: new message -> Spam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26879>
_______________________________________

From report at bugs.python.org  Thu Apr 28 19:51:55 2016
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 28 Apr 2016 23:51:55 +0000
Subject: [issue26879] Spam
Message-ID: <1461887515.9.0.247797491645.issue26879@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
Removed message: http://bugs.python.org/msg264455

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26879>
_______________________________________

From report at bugs.python.org  Thu Apr 28 20:46:42 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 29 Apr 2016 00:46:42 +0000
Subject: [issue26878] Allow doctest to deep copy globals
In-Reply-To: <1461882326.3.0.694986363749.issue26878@psf.upfronthosting.co.za>
Message-ID: <1461890802.49.0.00878667406183.issue26878@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

I'm afraid I can't quite see what the problem is. If you're passing your own globs argument, can't you deepcopy it yourself? 

Could you show a minimal, short example demonstrating the issue please?

----------
nosy: +steven.daprano
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26878>
_______________________________________

From report at bugs.python.org  Thu Apr 28 21:43:07 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 29 Apr 2016 01:43:07 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module.
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1461894187.06.0.907553969728.issue26826@psf.upfronthosting.co.za>


Martin Panter added the comment:

Yes, having a high-level version of copy_file_range() that falls back to copyfileobj() should be okay. I?m not sure if it should be a public API of shutil, or just an internal detail.

I am wondering if it would be nice to rearrange the os.copy_file_range() signature and make more parameters optional, or is that getting too high level?

copy_file_range(in, out, count, offset_in=None, offset_out=None, flags=0)

copy_file_range(f1, f2, size)  # Try to copy a whole file
copy_file_range(f1, f2, 30, 100, 200)  # Try 30 bytes at given offsets

Also left some more review comments. Also, we should eventually add test case(s) for the new functionality, and an entry to Doc/whatsnew/3.6.rst.

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Thu Apr 28 22:22:19 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 29 Apr 2016 02:22:19 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1461896539.64.0.204300144689.issue26439@psf.upfronthosting.co.za>


Martin Panter added the comment:

The obvious (but easy to fix) problem I forsee with Python 3 is the print() calls. If you use print("") and print(arg), that will work with both 2 and 3. There may be more complications with bytes vs text stdout if we change the os.popen() calls to use subprocess.Popen.

I didn?t mean to use libpython2.7 specifically. Substitute any shared library that is widely available across platforms; maybe ?crypto? is a better example. CDLL(find_library("crypto")) loads "libcrypto.so.1.0.0" on my Linux computer. It looks like you got the equivalent working for AIX; I was just checking.

FWIW it looks like your parsing of sys.executable to find library search paths is similar to searching the runpath (or RPATH) on ELF files, as proposed in Issue 19317. And it seems AIX?s LIBPATH environment variable is similar to LD_LIBRARY_PATH on Linux, proposed to be searched in Issue 9998. Also, I understand the equivalent OS X environment variables DYLD_(FALLBACK)_LIBRARY_PATH are already used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Fri Apr 29 00:28:32 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 29 Apr 2016 04:28:32 +0000
Subject: [issue23453] Clarify bytes vs text with non-seeking tarfile stream
In-Reply-To: <1423739998.49.0.706967373594.issue23453@psf.upfronthosting.co.za>
Message-ID: <1461904112.82.0.793841250329.issue23453@psf.upfronthosting.co.za>


Martin Panter added the comment:

Looks like the _Stream docstring needs a similar fix regarding stdin and stdout. Also, it wouldn?t hurt to specify that the read() and write() methods should work with bytes, not text.

----------
title: Opening a stream with tarfile.open() triggers a TypeError: can't concat bytes to str error -> Clarify bytes vs text with non-seeking tarfile stream
versions: +Python 3.5, Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23453>
_______________________________________

From report at bugs.python.org  Fri Apr 29 00:53:15 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 29 Apr 2016 04:53:15 +0000
Subject: [issue10436] tarfile.extractfile in "r|" stream mode fails with
 filenames or members from getmembers()
In-Reply-To: <1289931464.79.0.618120236196.issue10436@psf.upfronthosting.co.za>
Message-ID: <1461905595.86.0.859600494704.issue10436@psf.upfronthosting.co.za>


Martin Panter added the comment:

David, if you are still interested, I think specific suggestions or patches would be welcome (even if Lars assigned this to himself five years ago). I also like the idea of separate low-level and random access layers (I also thought of this).

One other problem with the documentation of this mode is it points to the Examples section, but it is not obvious why. The only example specific to non-seeking mode was removed in r63411, apparently because it was obsolete:

The _only_ way to extract an uncompressed tar stream from ?sys.stdin?:

tar = tarfile.open(mode="r|", fileobj=sys.stdin)
for tarinfo in tar:
    tar.extract(tarinfo)

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10436>
_______________________________________

From report at bugs.python.org  Fri Apr 29 01:52:12 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 29 Apr 2016 05:52:12 +0000
Subject: [issue26358] mmap.mmap.__iter__ is broken (yields bytes instead of
 ints)
In-Reply-To: <1455421066.19.0.307034706486.issue26358@psf.upfronthosting.co.za>
Message-ID: <1461909132.5.0.785927219547.issue26358@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I tried to write a patch to make mmap behave like bytearray more. Making iteration returns int is easy. But I am trapped in the contains operation. To support operation like b'aa' in b'aabbcc', we have to do a str in str search. I don't find any portable way except writing my own. bytes and bytearray use stringlib_find, but that is not reachable in a c module. Any advice?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26358>
_______________________________________

From report at bugs.python.org  Fri Apr 29 02:00:18 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 29 Apr 2016 06:00:18 +0000
Subject: [issue26358] mmap.mmap.__iter__ is broken (yields bytes instead of
 ints)
In-Reply-To: <1455421066.19.0.307034706486.issue26358@psf.upfronthosting.co.za>
Message-ID: <1461909618.01.0.395353969236.issue26358@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for taking a look at this, Xiang.

Like I said in msg263470, making the in operator work with mmap objects is out of scope for this issue and it should be handled in a separate issue (I already have a WIP patch, but please feel free to work on it).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26358>
_______________________________________

From report at bugs.python.org  Fri Apr 29 02:07:20 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 29 Apr 2016 06:07:20 +0000
Subject: [issue26358] mmap.mmap.__iter__ is broken (yields bytes instead of
 ints)
In-Reply-To: <1455421066.19.0.307034706486.issue26358@psf.upfronthosting.co.za>
Message-ID: <1461910040.85.0.299073173355.issue26358@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Ho, I'm really curious to see the resolution. ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26358>
_______________________________________

From report at bugs.python.org  Fri Apr 29 02:08:29 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 29 Apr 2016 06:08:29 +0000
Subject: [issue26358] mmap.mmap.__iter__ is broken (yields bytes instead of
 ints)
In-Reply-To: <1455421066.19.0.307034706486.issue26358@psf.upfronthosting.co.za>
Message-ID: <1461910109.16.0.0252421494852.issue26358@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Making iteration returns int is backward incompatible change. I afraid it is too later to do this. We lost a chance at a time of Python 3.0.

We need separate mmap class that behave more like bytes/bytearray/memoryview/sequence of 8-bit integers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26358>
_______________________________________

From report at bugs.python.org  Fri Apr 29 02:13:03 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Apr 2016 06:13:03 +0000
Subject: [issue26822] itemgetter/attrgetter/methodcaller objects ignore
 keyword arguments
In-Reply-To: <1461266621.67.0.0664681491354.issue26822@psf.upfronthosting.co.za>
Message-ID: <20160429061259.1536.13847.251681F7@psf.io>


Roundup Robot added the comment:

New changeset 54663cbd0de1 by Serhiy Storchaka in branch '3.5':
Issue #26822: Decreased an overhead of using _PyArg_NoKeywords() in calls of
https://hg.python.org/cpython/rev/54663cbd0de1

New changeset 22caee20223e by Serhiy Storchaka in branch 'default':
Issue #26822: Decreased an overhead of using _PyArg_NoKeywords() in calls of
https://hg.python.org/cpython/rev/22caee20223e

New changeset d738f268a013 by Serhiy Storchaka in branch '2.7':
Issue #26822: Decreased an overhead of using _PyArg_NoKeywords() in calls of
https://hg.python.org/cpython/rev/d738f268a013

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26822>
_______________________________________

From report at bugs.python.org  Fri Apr 29 02:22:05 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 29 Apr 2016 06:22:05 +0000
Subject: [issue26822] itemgetter/attrgetter/methodcaller objects ignore
 keyword arguments
In-Reply-To: <1461266621.67.0.0664681491354.issue26822@psf.upfronthosting.co.za>
Message-ID: <1461910925.18.0.142683144702.issue26822@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Upon closer inspection, redefine _PyArg_NoKeywords as a macro turned out to be not such a good idea. Other use of _PyArg_NoKeywords are in __new__ and __init__ methods. Create these objects in most cases (except may be slice) is performance critical operation than calling itemgetter, attrgetter or methodcaller object. It is better to add this microoptimization on cases (set and frozenset already have it).

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26822>
_______________________________________

From report at bugs.python.org  Fri Apr 29 02:29:20 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 29 Apr 2016 06:29:20 +0000
Subject: [issue26880] Remove redundant checks from set.__init__
Message-ID: <1461911360.58.0.917817733289.issue26880@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

set.__init__ have checks PyAnySet_Check(self) and PySet_Check(self). They are redundant since set.__init__ can't be called for non-set.

>>> set.__init__(frozenset(), ())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: descriptor '__init__' requires a 'set' object but received a 'frozenset'

Do I miss something?

----------
assignee: rhettinger
components: Interpreter Core
files: set_init.patch
keywords: patch
messages: 264467
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Remove redundant checks from set.__init__
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file42644/set_init.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26880>
_______________________________________

From report at bugs.python.org  Fri Apr 29 02:50:49 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Apr 2016 06:50:49 +0000
Subject: [issue26881] modulefinder should reuse the dis module
Message-ID: <1461912649.38.0.754834410981.issue26881@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The scan_opcodes_25() method of the modulefinder module implements a disassembler of Python bytecode. The implementation is incomplete, it doesn't support EXTENDED_ARG. I suggest to drop the disassembler and reuse the dis module.

See also the issue #26647 "Wordcode" changes the bytecode.

----------
messages: 264468
nosy: Demur Rumed, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: modulefinder should reuse the dis module
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26881>
_______________________________________

From report at bugs.python.org  Fri Apr 29 02:52:13 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 29 Apr 2016 06:52:13 +0000
Subject: [issue26877] tarfile use wrong code when read from fileobj
In-Reply-To: <1461879882.57.0.719679075431.issue26877@psf.upfronthosting.co.za>
Message-ID: <1461912733.65.0.185824906238.issue26877@psf.upfronthosting.co.za>


Martin Panter added the comment:

Can you give a demonstration script? I don?t see how this could be triggered. If you use a tarfile mode like "r|", it internally uses a _Stream object which has a loop to do exact reads: <https://hg.python.org/cpython/annotate/v3.5.1/Lib/tarfile.py#l567>.

----------
nosy: +martin.panter
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26877>
_______________________________________

From report at bugs.python.org  Fri Apr 29 02:54:57 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Apr 2016 06:54:57 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1461912897.75.0.80949765613.issue26647@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Demur: Serhiy and me reviewed your change wpy6.patch. Can you modify your change? If not, I can do it ;-) It's up to you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Fri Apr 29 03:43:34 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 29 Apr 2016 07:43:34 +0000
Subject: [issue26881] modulefinder should reuse the dis module
In-Reply-To: <1461912649.38.0.754834410981.issue26881@psf.upfronthosting.co.za>
Message-ID: <1461915814.85.0.908135338594.issue26881@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Proposed patch adds private helper function dis._unpack_args() that unpacks long arguments. This function is now reused in two places in dis and in modulefinder.

----------
components: +Library (Lib)
keywords: +patch
stage:  -> patch review
type:  -> behavior
Added file: http://bugs.python.org/file42645/dis_unpack_args.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26881>
_______________________________________

From report at bugs.python.org  Fri Apr 29 03:51:34 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 29 Apr 2016 07:51:34 +0000
Subject: [issue26859] unittest fails with "Start directory is not importable"
In-Reply-To: <1461678137.48.0.743276761028.issue26859@psf.upfronthosting.co.za>
Message-ID: <1461916294.7.0.903699509863.issue26859@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Here is the patch with a test case.
I have checked that the new test case fails with 'Start directory is not importable"' when loader.py is not patched.

----------
Added file: http://bugs.python.org/file42646/unittest_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26859>
_______________________________________

From report at bugs.python.org  Fri Apr 29 04:04:31 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 29 Apr 2016 08:04:31 +0000
Subject: [issue26358] mmap.mmap.__iter__ is broken (yields bytes instead of
 ints)
In-Reply-To: <1455421066.19.0.307034706486.issue26358@psf.upfronthosting.co.za>
Message-ID: <1461917071.75.0.338269612581.issue26358@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Although Serhiy thinks we need a separate class for this but I still want to upload my patch first. Maybe some of it can be helpful later, or garbage.

I add a mmap_contains to fix the in operator's behaviour (I don't find the separate issue). I use the simplest search method which is O(m*n). Previously I thought it is not acceptable but I find out that mmap_gfind goes this way too.

By the way, only operations related to mmap_item are affected, which I can see is iteration and in (search does not need to iterate since there is find method), indexing is not affected. So maybe this does not break the backward compatibility that hard.

Hope no disturb.

----------
keywords: +patch
Added file: http://bugs.python.org/file42647/mmap_bytearray_like.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26358>
_______________________________________

From report at bugs.python.org  Fri Apr 29 04:11:10 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 29 Apr 2016 08:11:10 +0000
Subject: [issue26880] Remove redundant checks from set.__init__
In-Reply-To: <1461911360.58.0.917817733289.issue26880@psf.upfronthosting.co.za>
Message-ID: <1461917470.35.0.551498594714.issue26880@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

LGTM

----------
assignee: rhettinger -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26880>
_______________________________________

From report at bugs.python.org  Fri Apr 29 04:12:01 2016
From: report at bugs.python.org (=?utf-8?b?0JDQu9C10LrRgdCw0L3QtNGAINCS0LjQvdC+0LPRgNCw0LTQvtCy?=)
Date: Fri, 29 Apr 2016 08:12:01 +0000
Subject: [issue26882] The Python process stops responding immediately after
 starting
Message-ID: <1461917521.83.0.656374171868.issue26882@psf.upfronthosting.co.za>


New submission from ????????? ??????????:

I start in Windows 7 virtual machine the Python x86 subprocess from another console application with commandline: 
c:\python35\python.exe -c print('hello')

Immediately after the startup process stops responding and hanging forever.

If you run it with the parameter -version python shows the version information to the console normally.

----------
components: Interpreter Core
files: python.dmp
messages: 264475
nosy: ????????? ??????????
priority: normal
severity: normal
status: open
title: The Python process stops responding immediately after starting
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file42648/python.dmp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26882>
_______________________________________

From report at bugs.python.org  Fri Apr 29 04:25:24 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 29 Apr 2016 08:25:24 +0000
Subject: [issue22477] GCD in Fractions
In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za>
Message-ID: <1461918324.59.0.728306410823.issue22477@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

As far as I know, we're all done here.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22477>
_______________________________________

From report at bugs.python.org  Fri Apr 29 04:25:30 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 29 Apr 2016 08:25:30 +0000
Subject: [issue22477] GCD in Fractions
In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za>
Message-ID: <1461918330.39.0.029005801576.issue22477@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22477>
_______________________________________

From report at bugs.python.org  Fri Apr 29 04:25:47 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 29 Apr 2016 08:25:47 +0000
Subject: [issue22477] GCD in Fractions
In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za>
Message-ID: <1461918347.3.0.297614667999.issue22477@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> fixed
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22477>
_______________________________________

From report at bugs.python.org  Fri Apr 29 04:32:22 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Apr 2016 08:32:22 +0000
Subject: [issue26880] Remove redundant checks from set.__init__
In-Reply-To: <1461911360.58.0.917817733289.issue26880@psf.upfronthosting.co.za>
Message-ID: <20160429083216.12144.45418.0B872388@psf.io>


Roundup Robot added the comment:

New changeset ed6345cb08ab by Serhiy Storchaka in branch 'default':
Issue #26880: Removed redundant checks in set.__init__.
https://hg.python.org/cpython/rev/ed6345cb08ab

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26880>
_______________________________________

From report at bugs.python.org  Fri Apr 29 04:32:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 29 Apr 2016 08:32:40 +0000
Subject: [issue26880] Remove redundant checks from set.__init__
In-Reply-To: <1461911360.58.0.917817733289.issue26880@psf.upfronthosting.co.za>
Message-ID: <1461918760.79.0.474666789785.issue26880@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/issue26880>
_______________________________________

From report at bugs.python.org  Fri Apr 29 04:42:25 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Fri, 29 Apr 2016 08:42:25 +0000
Subject: [issue26860] os.walk and os.fwalk yield namedtuple instead of tuple
In-Reply-To: <1461678306.82.0.694875654943.issue26860@psf.upfronthosting.co.za>
Message-ID: <1461919345.89.0.202442163284.issue26860@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

In regard to Raymond`s points I agree with Serhiy`s comments.

As for Serhiy`s doubts:

> 3. Using namedtuple is slower and consumes more memory than using tuple. Even for FS-related operation like os.walk() this can matter. A lot of code is optimized for exact tuples, with namedtuple this optimization is lost.

I did some testing on my own PC:
./python -m timeit -s "from os import walk"  "for x in walk('Lib'): pass"

Regular tuple: 7.53 msec
Named tuple: 7.66 msec

> 4. New names (dirpath, dirnames, filenames) are questionable. Why not use undersores (dir_names)? "dir" in dirpath refers to the current proceeded directory, but "dir" in dirnames refers to it's subdirectories. Currently you are free to use short names (root, dirs, files) from examples or what you prefer, but with namedtuple you are sticked with standard names forever. There are no names that satisfy everybody.

I agree that there will be no names that will satisfy everybody but I think the names that are currently in the documentation are the most trivial choice.

As for points 1,2,5 this feature doesn`t break any of the old walk API.

One more point I would like input on is the testing. I can remove the walk method from the WalkTests, FwalkTests classes and use the new named tuple attributes in the tests. Do you think its better or should we keep the tests with the old API (access using indexes)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26860>
_______________________________________

From report at bugs.python.org  Fri Apr 29 05:15:57 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 29 Apr 2016 09:15:57 +0000
Subject: [issue26877] tarfile use wrong code when read from fileobj
In-Reply-To: <1461879882.57.0.719679075431.issue26877@psf.upfronthosting.co.za>
Message-ID: <1461921357.82.0.388469596865.issue26877@psf.upfronthosting.co.za>


???? ????????? added the comment:

well, I don't use "r|" (but will, thanks for suggestion)

In any case, assuming that read() returns exact length is wrong. There is .readexactly() (f.e. in asyncio I mean). Or, one should use simple loop to call .read() multiple times.

Reading from plain file does not guarantee, that read() syscall will return requested count of bytes even when these bytes are available.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26877>
_______________________________________

From report at bugs.python.org  Fri Apr 29 05:54:24 2016
From: report at bugs.python.org (Stefan Forstenlechner)
Date: Fri, 29 Apr 2016 09:54:24 +0000
Subject: [issue26883] input() call blocks multiprocessing
Message-ID: <1461923664.77.0.748212868392.issue26883@psf.upfronthosting.co.za>


New submission from Stefan Forstenlechner:

If input is called right away after applying a single job to multiprocessing.Pool or submitting concurrent.futures.ProcessPoolExecutor then the processes are not started. If multiple jobs are submitted everything works fine.

This only seems to be a problem on Windows (probably only 10) and python version 3.x

See my stackoverflow question: http://stackoverflow.com/questions/36919678/python-multiprocessing-pool-does-not-start-right-away

----------
components: Windows
messages: 264480
nosy: Stefan Forstenlechner, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: input() call blocks multiprocessing
type: behavior
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26883>
_______________________________________

From report at bugs.python.org  Fri Apr 29 06:08:05 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 29 Apr 2016 10:08:05 +0000
Subject: [issue26877] tarfile use wrong code when read from fileobj
In-Reply-To: <1461879882.57.0.719679075431.issue26877@psf.upfronthosting.co.za>
Message-ID: <1461924485.13.0.563621837277.issue26877@psf.upfronthosting.co.za>


Martin Panter added the comment:

On the other hand, you cannot use a pipe with mode="r" because that mode does seeking; that is why I asked for more details on what you are doing:

$ cat | python3 -c 'import tarfile, sys; tarfile.open(fileobj=sys.stdin.buffer, mode="r")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.5/tarfile.py", line 1580, in open
    return func(name, filemode, fileobj, **kwargs)
  File "/usr/lib/python3.5/tarfile.py", line 1610, in taropen
    return cls(name, mode, fileobj, **kwargs)
  File "/usr/lib/python3.5/tarfile.py", line 1467, in __init__
    self.offset = self.fileobj.tell()
OSError: [Errno 29] Illegal seek

Python 3 has the io.RawIOBase class which models the low level read() system call and does partial reads, and the io.BufferedIOBase class whose read() method guarantees an exact read. You can often wrap a raw object with BufferedReader to easily convert to the buffered kind.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26877>
_______________________________________

From report at bugs.python.org  Fri Apr 29 06:09:46 2016
From: report at bugs.python.org (DqASe)
Date: Fri, 29 Apr 2016 10:09:46 +0000
Subject: [issue26878] Allow doctest to deep copy globals
In-Reply-To: <1461882326.3.0.694986363749.issue26878@psf.upfronthosting.co.za>
Message-ID: <1461924586.32.0.0506461504844.issue26878@psf.upfronthosting.co.za>


DqASe added the comment:

I'd like each test to see the same environment (including variables contents). Deepcopying extraglobs argument at call time is not sufficient because it is only done once, not before each test.

----------
Added file: http://bugs.python.org/file42649/x.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26878>
_______________________________________

From report at bugs.python.org  Fri Apr 29 06:26:45 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 29 Apr 2016 10:26:45 +0000
Subject: [issue9321] CGIHTTPServer cleanup htbin
In-Reply-To: <1279701482.44.0.871660375803.issue9321@psf.upfronthosting.co.za>
Message-ID: <1461925605.61.0.211028222081.issue9321@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I agree with David and ?ric. There is no point to remove/deprecate it. I'd prefer to fix bugs in CGIHTTPRequestHandler (and in other CGI related stuff in stdlib) instead of introducing new incompatibilities at this point.

----------
nosy: +berker.peksag
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9321>
_______________________________________

From report at bugs.python.org  Fri Apr 29 06:32:11 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 29 Apr 2016 10:32:11 +0000
Subject: [issue26884] cross-compilation of extension module links to the wrong
 python library
Message-ID: <1461925930.98.0.579147295527.issue26884@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

configure of the cross compilation is run with '--enable-shared --with-pydebug'.

The cross-compilation fails attempting to link the extension module objects with a non existing libpython3.6m instead of libpython3.6dm, when the native python that is used to run setup.py had not been configured with --with-pydebug.

The attached patch fixes this problem.

----------
components: Cross-Build
files: build.patch
keywords: patch
messages: 264484
nosy: Alex.Willmer, xdegaye
priority: normal
severity: normal
status: open
title: cross-compilation of extension module links to the wrong python library
type: compile error
versions: Python 3.6
Added file: http://bugs.python.org/file42650/build.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26884>
_______________________________________

From report at bugs.python.org  Fri Apr 29 06:36:06 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 29 Apr 2016 10:36:06 +0000
Subject: [issue26865] Meta-issue: support of the android platform
In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za>
Message-ID: <1461926166.42.0.568493054436.issue26865@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

build
    issue #26884: cross-compilation of extension module links to the wrong python library

This should be added to the meta-issue dependencies, I guess.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26865>
_______________________________________

From report at bugs.python.org  Fri Apr 29 06:40:56 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 29 Apr 2016 10:40:56 +0000
Subject: [issue10850] inconsistent behavior concerning
 multiprocessing.manager.BaseManager._Server
In-Reply-To: <1294360374.53.0.588595674921.issue10850@psf.upfronthosting.co.za>
Message-ID: <1461926456.78.0.865562548928.issue10850@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +easy
nosy: +berker.peksag, davin
stage:  -> needs patch
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10850>
_______________________________________

From report at bugs.python.org  Fri Apr 29 06:43:38 2016
From: report at bugs.python.org (Ma Lin)
Date: Fri, 29 Apr 2016 10:43:38 +0000
Subject: [issue26882] The Python process stops responding immediately after
 starting
In-Reply-To: <1461917521.83.0.656374171868.issue26882@psf.upfronthosting.co.za>
Message-ID: <1461926618.35.0.795158622146.issue26882@psf.upfronthosting.co.za>


Ma Lin added the comment:

Hang everytime?
When it hangs, try to press ENTER of keyboard on the console window, does it work?
If it works, see issue26744: print() function hangs on MS-Windows 10

----------
nosy: +Ma Lin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26882>
_______________________________________

From report at bugs.python.org  Fri Apr 29 06:45:20 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 29 Apr 2016 10:45:20 +0000
Subject: [issue24434] ItemsView.__contains__ does not mimic dict_items
In-Reply-To: <1434050451.28.0.415875303865.issue24434@psf.upfronthosting.co.za>
Message-ID: <1461926720.02.0.690441890918.issue24434@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Caleb's resolution looks good, just like the C version does, at least seems correct.

Serhiy, the corner case is interesting. math.nan == math.nan should return false so I think (1, math.nan) in ItemsView({1: math.nan} is a right behaviour. But the C version, which calls PyObject_RichCompareBool and then do a pointer check first seems having some problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24434>
_______________________________________

From report at bugs.python.org  Fri Apr 29 06:53:26 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 29 Apr 2016 10:53:26 +0000
Subject: [issue8491] Need readline command and keybinding information
In-Reply-To: <1271879913.89.0.268262009322.issue8491@psf.upfronthosting.co.za>
Message-ID: <1461927206.59.0.188399663171.issue8491@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +easy
nosy: +martin.panter
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.5, Python 3.6 -Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8491>
_______________________________________

From report at bugs.python.org  Fri Apr 29 07:12:06 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 29 Apr 2016 11:12:06 +0000
Subject: [issue26878] Allow doctest to deep copy globals
In-Reply-To: <1461924586.32.0.0506461504844.issue26878@psf.upfronthosting.co.za>
Message-ID: <20160429111143.GW13497@ando.pearwood.info>


Steven D'Aprano added the comment:

On Fri, Apr 29, 2016 at 10:09:46AM +0000, DqASe wrote:
> Added file: http://bugs.python.org/file42649/x.py

Ah, I see! That makes sense now. Thanks.

Why don't you just set the initial state of the lists in the doctests? 
That makes much better documentation. Imagine a more complex example 
where the function name means nothing to you and the topic is 
unfamiliar:

    >>> piyo(mylist, hogera=12, fuga=7)
    >>> mylist
    [0, 2, 4, 6, 14, 16]

But if I show the initial state of the list, not only is the meaning 
more obvious (which makes it better documentation and a better test), 
but your problem goes away:

    >>> mylist = [0, 2, 4, 6, 8, 10, 12, 14, 16]
    >>> piyo(mylist, hogera=12, fuga=7)
    >>> mylist
    [0, 2, 4, 6, 14, 16]

I fear that this suggested feature will encourage poor doctests that 
rely on global state rather than local state.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26878>
_______________________________________

From report at bugs.python.org  Fri Apr 29 07:12:27 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 29 Apr 2016 11:12:27 +0000
Subject: [issue26865] Meta-issue: support of the android platform
In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za>
Message-ID: <1461928347.83.0.844667235589.issue26865@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
dependencies: +cross-compilation of extension module links to the wrong python library

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26865>
_______________________________________

From report at bugs.python.org  Fri Apr 29 07:41:47 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Apr 2016 11:41:47 +0000
Subject: [issue26322] Missing docs for typing.Set
In-Reply-To: <1455050900.92.0.506743123977.issue26322@psf.upfronthosting.co.za>
Message-ID: <20160429114143.13924.8582.BE448266@psf.io>


Roundup Robot added the comment:

New changeset 6cd8cd14f648 by Berker Peksag in branch '3.5':
Issue #26322: Document typing.Set, patch by Joseph Moran
https://hg.python.org/cpython/rev/6cd8cd14f648

New changeset d263dcfd9bb6 by Berker Peksag in branch 'default':
Issue #26322: Document typing.Set, patch by Joseph Moran
https://hg.python.org/cpython/rev/d263dcfd9bb6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26322>
_______________________________________

From report at bugs.python.org  Fri Apr 29 07:42:18 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 29 Apr 2016 11:42:18 +0000
Subject: [issue26322] Missing docs for typing.Set
In-Reply-To: <1455050900.92.0.506743123977.issue26322@psf.upfronthosting.co.za>
Message-ID: <1461930138.45.0.814429189545.issue26322@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks, Joseph!

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26322>
_______________________________________

From report at bugs.python.org  Fri Apr 29 08:01:29 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Apr 2016 12:01:29 +0000
Subject: [issue26822] itemgetter/attrgetter/methodcaller objects ignore
 keyword arguments
In-Reply-To: <1461266621.67.0.0664681491354.issue26822@psf.upfronthosting.co.za>
Message-ID: <1461931289.84.0.02881742504.issue26822@psf.upfronthosting.co.za>


STINNER Victor added the comment:

-    if (!_PyArg_NoKeywords("itemgetter", kw))
+    if (kw != NULL && !_PyArg_NoKeywords("itemgetter", kw))

Can't we use a macro to implement this micro-optimization, instead of modifying each call to _PyArg_NoKeywords?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26822>
_______________________________________

From report at bugs.python.org  Fri Apr 29 08:18:39 2016
From: report at bugs.python.org (DqASe)
Date: Fri, 29 Apr 2016 12:18:39 +0000
Subject: [issue26878] Allow doctest to deep copy globals
In-Reply-To: <1461882326.3.0.694986363749.issue26878@psf.upfronthosting.co.za>
Message-ID: <1461932319.85.0.109655757342.issue26878@psf.upfronthosting.co.za>


DqASe added the comment:

I see your point. I thought it can still be useful in these scenarios:

1. when doc/testing tens of methods of a specific class. Instantiation of the class is repetitive (DRY principle).
2. Instantiation can be expensive (e.g. from network)
3. To behave less-surprisingly (why can't I re-use objects created in an earlier test, but I can re-use the internal state of mutable ones?)
4. An aspiration for tests to be forcibly sandboxed from the execution environment (that would require deep copies by default).
5. Relying on an always-equal global state is better (IMHO) than relying on a *mutable* global state, after all.

But I understand it's debatable. Thanks anyways.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26878>
_______________________________________

From report at bugs.python.org  Fri Apr 29 08:24:45 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 29 Apr 2016 12:24:45 +0000
Subject: [issue20247] Condition._is_owned is wrong
In-Reply-To: <1389660921.49.0.651163897864.issue20247@psf.upfronthosting.co.za>
Message-ID: <1461932685.11.0.564107704784.issue20247@psf.upfronthosting.co.za>


Berker Peksag added the comment:

issue 25516 is a duplicate, but I'm going to close this one since issue 25516 has a patch.

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> threading.Condition._is_owned() is wrong when using threading.Lock

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20247>
_______________________________________

From report at bugs.python.org  Fri Apr 29 08:29:06 2016
From: report at bugs.python.org (Marcos Dione)
Date: Fri, 29 Apr 2016 12:29:06 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module.
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1461932946.17.0.0765667972098.issue26826@psf.upfronthosting.co.za>


Marcos Dione added the comment:

> Yes, having a high-level version of copy_file_range() that falls back to copyfileobj() should be okay.

I'm not sure about this. For the moment c_f_o() is available only if the syscall is there.


> I am wondering if it would be nice to rearrange the os.copy_file_range() signature and make more parameters optional, [...]
> 
> copy_file_range(in, out, count, offset_in=None, offset_out=None, flags=0)

I agree with this, most of the time you will want to just advance both offsets, and providing None all the time can be tiring.

I fixed this, modified a little the doc, but now I'll read about integer types and sizes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Fri Apr 29 08:48:47 2016
From: report at bugs.python.org (Demur Rumed)
Date: Fri, 29 Apr 2016 12:48:47 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1461934127.61.0.762467148405.issue26647@psf.upfronthosting.co.za>


Demur Rumed added the comment:

I should be able to submit a wpy7.patch this evening, though I was never able to generate a patch in the format you prefer. Should I fall back to piping git diff? At this point it may be better if you take in the last suggestions as I'd probably end up removing TARGET_WITH_IMPL & then there'd be debate about that being unnecessary

To be clear: I'll upload a wpy7.patch this evening, & you can decide whether to create your own patch from wpy6 or wpy7 or accept wpy7. In the meantime if you just update wpy6 then all well. Sorry for not being very straight forward

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Fri Apr 29 09:06:42 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Apr 2016 13:06:42 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1461934127.61.0.762467148405.issue26647@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYKb5LUWCTGsj2YkBfCt6k2YB7M3fOW_7Pg4+GfyJEHPw@mail.gmail.com>


STINNER Victor added the comment:

To create a patch accepted by Rietveld, you should clone the Mercurial
repository, apply your patch, and then regenerate the diff using
Mercurial:

Something like:

$ cd python_hg_clone
$ patch -p1 < ../git_patch.patch
$ hg diff > hg_diff.patch

To clone: hg clone https://hg.python.org/cpython/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Fri Apr 29 09:48:23 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Apr 2016 13:48:23 +0000
Subject: [issue24902] http.server: on startup, show host/port as URL
In-Reply-To: <1440074614.12.0.491243146535.issue24902@psf.upfronthosting.co.za>
Message-ID: <20160429134812.34473.49262.A6C14F9B@psf.io>


Roundup Robot added the comment:

New changeset 3be61137280a by Berker Peksag in branch 'default':
Issue #24902: Print server URL on http.server startup
https://hg.python.org/cpython/rev/3be61137280a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24902>
_______________________________________

From report at bugs.python.org  Fri Apr 29 09:51:04 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 29 Apr 2016 13:51:04 +0000
Subject: [issue24902] http.server: on startup, show host/port as URL
In-Reply-To: <1440074614.12.0.491243146535.issue24902@psf.upfronthosting.co.za>
Message-ID: <1461937864.9.0.504178593817.issue24902@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I replaced %-string with str.format(). Thanks!

Note: Please sign the PSF contributor agreement at https://www.python.org/psf/contrib/contrib-form/

----------
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/issue24902>
_______________________________________

From report at bugs.python.org  Fri Apr 29 10:11:55 2016
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 29 Apr 2016 14:11:55 +0000
Subject: [issue26882] The Python process stops responding immediately after
 starting
In-Reply-To: <1461917521.83.0.656374171868.issue26882@psf.upfronthosting.co.za>
Message-ID: <1461939115.45.0.0225333678599.issue26882@psf.upfronthosting.co.za>


Eryk Sun added the comment:

python.dmp is from Windows 8.1 (NT 6.3):

    0:000> ?? @$peb->OSMajorVersion; ?? @$peb->OSMinorVersion
    unsigned long 6
    unsigned long 3

with the following command line and working directory:

    0:000> ?? @$peb->ProcessParameters->CommandLine
    struct _UNICODE_STRING
     ""C:\Python35\python.exe" -c print('hello')"
       +0x000 Length           : 0x54
       +0x002 MaximumLength    : 0x56
       +0x004 Buffer           : 0x01100a9e  ""C:\Python35\python.exe" -c print('hello')"

    0:000> ?? @$peb->ProcessParameters->CurrentDirectory
    struct _CURDIR
       +0x000 DosPath          : _UNICODE_STRING "C:\TestPlatform\integrationTests\"
       +0x008 Handle           : 0x00000024 Void

The STARTUPINFO dwFlags is set to STARTF_USESTDHANDLES (0x100), so the standard handles are from the STARTUPINFO hStdInput, hStdOutput, and hStdError:

    0:000> ?? @$peb->ProcessParameters->WindowFlags
    unsigned long 0x100

Standard input appears to be a console handle (starting in Windows 8 console handles are kernel handles, so we can inspect them in the debugger):

    0:000> ?? @$peb->ProcessParameters->StandardInput
    void * 0x00000018
    0:000> !handle 18 3
    Handle 00000018
      Type          File
      Attributes    0
      GrantedAccess 0x12019f:
             ReadControl,Synch
             Read/List,Write/Add,Append/SubDir/CreatePipe,ReadEA,WriteEA,ReadAttr,WriteAttr
      HandleCount   4
      PointerCount  131064

It looks like a console handle because it's open with both read and write access, which is required for the console API (e.g. ReadConsoleInput and WriteConsoleInput). 

Standard output appears to be a pipe or file, opened with only write access:

    0:000> ?? @$peb->ProcessParameters->StandardOutput
    void * 0x000011d4
    0:000> !handle 11d4 3
    Handle 000011d4
      Type          File
      Attributes    0
      GrantedAccess 0x120196:
             ReadControl,Synch
             Write/Add,Append/SubDir/CreatePipe,WriteEA,ReadAttr,WriteAttr
      HandleCount   2
      PointerCount  65536

The process is blocked on the NtQueryInformationFile [1] system call in the process of creating Python's sys.std* file objects.

    0:000> k
    ChildEBP RetAddr
    0109f354 74afa9a4 ntdll!NtQueryInformationFile+0xc
    0109f3ac 73e11b15 KERNELBASE!SetFilePointerEx+0x9c
    ...
    0109f450 73fe051e ucrtbase!_lseeki64+0x19
    ...
    0109f48c 740421e3 python35!_io_FileIO_tell+0x2d
    ...
    0109f508 73fe4948 python35!_buffered_raw_tell+0x20
    ...
    0109f53c 74053dc0 python35!_io_BufferedReader___init__+0x3f
    ...
    0109f648 740420ff python35!_io_open+0x90
    ...
    0109f710 740c37b4 python35!create_stdio+0xac
    0109f748 740c2871 python35!initstdio+0x264
    0109f760 73faf203 python35!_Py_InitializeEx_Private+0x351
    ...
    0109f808 1c7c11df python35!Py_Main+0x713

Specifically it's querying StandardInput (handle 0x18) for FilePositionInformation (0xe), which is stored in an 8-byte FILE_POSITION_INFORMATION struct (i.e. the size of a LARGE_INTEGER for the current position):

    0:000> dd @esp l6
    0109f358  74afa9a4 00000018 0109f37c 0109f388
    0109f368  00000008 0000000e

This is querying the value of the file pointer to initialize sys.stdin.buffer. 

Microsoft has been busy rolling out major updates to the console subsystem over the past few years. It could be a bug in the condrv.sys console device driver, which is new in Windows 8. It's hard to say what's going on without attaching a kernel debugger to inspect the problem.

Switching to a device driver required reimplementing the console API -- e.g. everything that used to get routed to LPC interprocess calls to conhost.exe now goes through I/O system calls. Specifically, console handles prior to Windows 8 were flagged by setting the lower 2 bits (e.g. 3, 7, 11, etc) to route calls to LPC-based functions where possible (e.g. ReadFile -> ReadConsoleA) or immediately fail. Most if not all of that specialized code is gone in Windows 8+. WinAPI calls with console handles now take the regular path to call NT I/O system calls such as NtReadFile, NtDeviceIoControlFile, and NtQueryInformationFile.

For example, in Windows 7 calling SetFilePointerEx to get or set the non-existent file pointer of a console handle fails immediately with STATUS_INVALID_HANDLE. This can be ignored harmlessly. But in the new console, we can do something silly like this (tested in Windows 10):

    >>> sys.stdin.seek(50)
    50
    >>> sys.stdin.tell()
    50

    >>> kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)
    >>> h = kernel32.GetStdHandle(-10)
    >>> pos = ctypes.c_longlong()
    >>> kernel32.SetFilePointerEx(h, 0, ctypes.byref(pos), 1)
    1
    >>> pos.value
    50

(On a tangent, the new implementation also breaks Ctrl+C handling. It no longer sets ERROR_OPERATION_ABORTED when interrupting a ReadFile console read. This breaks Python's REPL and input function.)

[1]: https://msdn.microsoft.com/en-us/library/ff567052

----------
components: +Windows
nosy: +eryksun, paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26882>
_______________________________________

From report at bugs.python.org  Fri Apr 29 10:26:05 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Apr 2016 14:26:05 +0000
Subject: [issue25551] Event's test_reset_internal_locks too fragile
In-Reply-To: <1446677150.66.0.649715763686.issue25551@psf.upfronthosting.co.za>
Message-ID: <20160429142553.100776.96267.0CC5BA1A@psf.io>


Roundup Robot added the comment:

New changeset 110dfb244b27 by Berker Peksag in branch '3.5':
Issue #25551: Test condition behavior instead of its internals
https://hg.python.org/cpython/rev/110dfb244b27

New changeset 9694185cdd9f by Berker Peksag in branch 'default':
Issue #25551: Test condition behavior instead of its internals
https://hg.python.org/cpython/rev/9694185cdd9f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25551>
_______________________________________

From report at bugs.python.org  Fri Apr 29 10:26:53 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 29 Apr 2016 14:26:53 +0000
Subject: [issue25551] Event's test_reset_internal_locks too fragile
In-Reply-To: <1446677150.66.0.649715763686.issue25551@psf.upfronthosting.co.za>
Message-ID: <1461940013.18.0.651234268763.issue25551@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Nir!

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25551>
_______________________________________

From report at bugs.python.org  Fri Apr 29 10:34:15 2016
From: report at bugs.python.org (Marcos Dione)
Date: Fri, 29 Apr 2016 14:34:15 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module.
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1461940455.78.0.951389803366.issue26826@psf.upfronthosting.co.za>


Marcos Dione added the comment:

I fixed most of the type problems, except that I'm not sure how to convert to size_t. Someone suggested to convert with 'n', then check if it's negative and correct. I'll ask the mailing list for better suggestions.

I also noted that running 'hg diff' shows the modifications to 'configure', which I didn't include. This leads me to doubt whether including the modification to 'pyconfig.h' is ok, given that it's generated by 'autoheader'.

----------
Added file: http://bugs.python.org/file42651/copy_file_range.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Fri Apr 29 10:45:22 2016
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 29 Apr 2016 14:45:22 +0000
Subject: [issue26860] os.walk and os.fwalk yield namedtuple instead of tuple
In-Reply-To: <1461678306.82.0.694875654943.issue26860@psf.upfronthosting.co.za>
Message-ID: <1461941122.67.0.64246140321.issue26860@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I'm not clear on what you asking, but regardless we should have both the old (by-index) tests and new by-attribute tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26860>
_______________________________________

From report at bugs.python.org  Fri Apr 29 11:33:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 29 Apr 2016 15:33:04 +0000
Subject: [issue26885] Add parsing support for more types in xmlrpc
Message-ID: <1461943983.79.0.576979457392.issue26885@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Apache XML-RPC server supports additional data types (http://ws.apache.org/xmlrpc/types.html). Proposed patch adds support of parsing some of these types: "ex:nil", "ex:i1", "ex:i2", "ex:i8", "ex:biginteger", "ex:float", "ex:bigdecimal". "nil" and "i8" without a prefix was already supported, but the support of "i8" was not documented.

The support of "ex:dateTime" can be added after resolving issue15873.

----------
components: Library (Lib)
files: xmlrpc_extensions.patch
keywords: patch
messages: 264504
nosy: loewis, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add parsing support for more types in xmlrpc
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42652/xmlrpc_extensions.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26885>
_______________________________________

From report at bugs.python.org  Fri Apr 29 11:33:20 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 29 Apr 2016 15:33:20 +0000
Subject: [issue26885] Add parsing support for more types in xmlrpc
In-Reply-To: <1461943983.79.0.576979457392.issue26885@psf.upfronthosting.co.za>
Message-ID: <1461944000.69.0.115274154248.issue26885@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
dependencies: +xmlrpclib raises when trying to convert an int to string when unicode is available

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26885>
_______________________________________

From report at bugs.python.org  Fri Apr 29 11:34:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 29 Apr 2016 15:34:39 +0000
Subject: [issue26873] xmlrpclib raises when trying to convert an int to string
 when unicode is available
In-Reply-To: <1461808162.86.0.277160090083.issue26873@psf.upfronthosting.co.za>
Message-ID: <1461944079.3.0.558000949139.issue26873@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Opened issue26885 for adding support of "ex:nil" and other types.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26873>
_______________________________________

From report at bugs.python.org  Fri Apr 29 12:09:11 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 29 Apr 2016 16:09:11 +0000
Subject: [issue26860] os.walk and os.fwalk yield namedtuple instead of tuple
In-Reply-To: <1461678306.82.0.694875654943.issue26860@psf.upfronthosting.co.za>
Message-ID: <1461946151.36.0.680964037768.issue26860@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

https://www.python.org/dev/peps/pep-0008/#class-names -- "Class names should normally use the CapWords convention."

Examples:
---------
crypt.py
6:from collections import namedtuple as _namedtuple
13:class _Method(_namedtuple('_Method', 'name ident salt_chars total_size')):

difflib.py
34:from collections import namedtuple as _namedtuple
36:Match = _namedtuple('Match', 'a b size')

dis.py
163:_Instruction = collections.namedtuple("_Instruction",
280:    Generates a sequence of Instruction namedtuples giving the details of each

doctest.py
107:from collections import namedtuple
109:TestResults = namedtuple('TestResults', 'failed attempted')

functools.py
21:from collections import namedtuple
345:_CacheInfo = namedtuple("CacheInfo", ["hits", "misses", "maxsize", "currsize"])

inspect.py
51:from collections import namedtuple, OrderedDict
323:Attribute = namedtuple('Attribute', 'name kind defining_class object')
968:Arguments = namedtuple('Arguments', 'args, varargs, varkw')
1008:ArgSpec = namedtuple('ArgSpec', 'args varargs keywords defaults')
1032:FullArgSpec = namedtuple('FullArgSpec',
1124:ArgInfo = namedtuple('ArgInfo', 'args varargs keywords locals')
1317:ClosureVars = namedtuple('ClosureVars', 'nonlocals globals builtins unbound')
1372:Traceback = namedtuple('Traceback', 'filename lineno function code_context index')
1412:FrameInfo = namedtuple('FrameInfo', ('frame',) + Traceback._fields)

nntplib.py
159:GroupInfo = collections.namedtuple('GroupInfo',
162:ArticleInfo = collections.namedtuple('ArticleInfo',

No doubt, there are exceptions to the rule in the standard library which is less consistent than we might like:  "stat_result".  That said, stat_result is a structseq and many C type names are old or violate the rules (list vs List, etc).   New named tuples should follow PEP 8 can use CapWords convention unless there is a strong reason not to in a particular case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26860>
_______________________________________

From report at bugs.python.org  Fri Apr 29 12:26:58 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Fri, 29 Apr 2016 16:26:58 +0000
Subject: [issue26860] os.walk and os.fwalk yield namedtuple instead of tuple
In-Reply-To: <1461678306.82.0.694875654943.issue26860@psf.upfronthosting.co.za>
Message-ID: <1461947218.2.0.683510401252.issue26860@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

Thanks for the response Ethan I think that I will leave the tests as they are in the current patch.

> No doubt, there are exceptions to the rule in the standard library which is less consistent than we might like:  "stat_result".  That said, stat_result is a structseq and many C type names are old or violate the rules (list vs List, etc).   New named tuples should follow PEP 8 can use CapWords convention unless there is a strong reason not to in a particular case.

I actually thought we should keep on consistency with other "result" like objects. I can see your point about new named tuples that should follow PEP 8 and DirEntry is an example of new "result" class that follow PEP8.
What names do you suggest? Maybe DirInfo and FDirInfo?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26860>
_______________________________________

From report at bugs.python.org  Fri Apr 29 12:29:35 2016
From: report at bugs.python.org (Peter L)
Date: Fri, 29 Apr 2016 16:29:35 +0000
Subject: [issue26886] Cross-compiling python:3.5.x fails with "Parser/pgen:
 Parser/pgen: cannot execute binary file"
Message-ID: <1461947375.28.0.628311795437.issue26886@psf.upfronthosting.co.za>


New submission from Peter L:

Cross-compiling python-3.5.x fails with "Parser/pgen: Parser/pgen: cannot execute binary file" (CBUILD="x86_64-pc-linux-gnu" and CHOST="armv7a-hardfloat-linux-gnueabi").

python-3.5.x requires "pgen" and "_freeze_importlib" to be compiled and executed at build time. Otherwise, it fails with "Parser/pgen: Parser/pgen: cannot execute binary file".

----------
components: Cross-Build
messages: 264508
nosy: Alex.Willmer, Peter L2
priority: normal
severity: normal
status: open
title: Cross-compiling python:3.5.x  fails with "Parser/pgen: Parser/pgen: cannot execute binary file"
type: compile error
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26886>
_______________________________________

From report at bugs.python.org  Fri Apr 29 12:33:41 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 29 Apr 2016 16:33:41 +0000
Subject: [issue13436] compile() doesn't work on ImportFrom with level=None
In-Reply-To: <1321747479.31.0.688458511993.issue13436@psf.upfronthosting.co.za>
Message-ID: <1461947621.71.0.94027901318.issue13436@psf.upfronthosting.co.za>


Berker Peksag added the comment:

level=None is now allowed: https://hg.python.org/cpython/file/default/Python/Python-ast.c#l5224 (see line 5224 to 5232) I converted the example in msg147972 to a Python script. test_bad_integer is still useful as it uses the required 'lineno' field. I will also commit issue13436.py as a test case.

----------
nosy: +berker.peksag
Added file: http://bugs.python.org/file42653/issue13436.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13436>
_______________________________________

From report at bugs.python.org  Fri Apr 29 12:34:40 2016
From: report at bugs.python.org (Peter L)
Date: Fri, 29 Apr 2016 16:34:40 +0000
Subject: [issue26886] Cross-compiling python:3.5.x fails with "Parser/pgen:
 Parser/pgen: cannot execute binary file"
In-Reply-To: <1461947375.28.0.628311795437.issue26886@psf.upfronthosting.co.za>
Message-ID: <1461947680.56.0.94535906101.issue26886@psf.upfronthosting.co.za>


Peter L added the comment:

Originally posted:
https://bugs.gentoo.org/show_bug.cgi?id=581304

----------
keywords: +patch
Added file: http://bugs.python.org/file42654/python-3.5-crosscompile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26886>
_______________________________________

From report at bugs.python.org  Fri Apr 29 12:50:07 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Apr 2016 16:50:07 +0000
Subject: [issue13436] compile() doesn't work on ImportFrom with level=None
In-Reply-To: <1321747479.31.0.688458511993.issue13436@psf.upfronthosting.co.za>
Message-ID: <20160429165002.26877.45557.163E2183@psf.io>


Roundup Robot added the comment:

New changeset 59638baee25e by Berker Peksag in branch 'default':
Issue #13436: Add a test to make sure that ast.ImportFrom(level=None) works
https://hg.python.org/cpython/rev/59638baee25e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13436>
_______________________________________

From report at bugs.python.org  Fri Apr 29 12:50:20 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 29 Apr 2016 16:50:20 +0000
Subject: [issue13436] compile() doesn't work on ImportFrom with level=None
In-Reply-To: <1321747479.31.0.688458511993.issue13436@psf.upfronthosting.co.za>
Message-ID: <1461948620.74.0.320384198496.issue13436@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13436>
_______________________________________

From report at bugs.python.org  Fri Apr 29 13:04:44 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 29 Apr 2016 17:04:44 +0000
Subject: =?utf-8?q?=5Bissue18956=5D_Document_useful_functions_in_=E2=80=98pydoc?=
 =?utf-8?q?=E2=80=99_module?=
In-Reply-To: <1378532336.08.0.216765249116.issue18956@psf.upfronthosting.co.za>
Message-ID: <1461949484.54.0.707392167211.issue18956@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Make generally useful pydoc functions public

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18956>
_______________________________________

From report at bugs.python.org  Fri Apr 29 14:07:20 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Fri, 29 Apr 2016 18:07:20 +0000
Subject: [issue26886] Cross-compiling python:3.5.x fails with "Parser/pgen:
 Parser/pgen: cannot execute binary file"
In-Reply-To: <1461947375.28.0.628311795437.issue26886@psf.upfronthosting.co.za>
Message-ID: <1461953240.33.0.986140992374.issue26886@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

You may need this patch: https://hg.python.org/cpython/rev/0f7a299c6d50

----------
nosy: +Chi Hsuan Yen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26886>
_______________________________________

From report at bugs.python.org  Fri Apr 29 14:10:47 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 Apr 2016 18:10:47 +0000
Subject: [issue26830] Refactor Tools/scripts/google.py
In-Reply-To: <1461346654.96.0.919095766119.issue26830@psf.upfronthosting.co.za>
Message-ID: <1461953447.18.0.416625426635.issue26830@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Demos should demonstrate proper modern code.  1. Contain decent docstrings.  2. Dependency on sys.argv, derived from a command line, should be in the 'if __name__' clause triggered when the module *is* invoked from command line. Especially in simple cases like this, it should be possible to import the module and call main(args) without involving sys.argv.  See review.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26830>
_______________________________________

From report at bugs.python.org  Fri Apr 29 15:03:05 2016
From: report at bugs.python.org (Michael Felt)
Date: Fri, 29 Apr 2016 19:03:05 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1461880605.42.0.911536132019.issue26439@psf.upfronthosting.co.za>
Message-ID: <5ca37e59-f30d-6db0-bbc1-708e4f3064e7@gmail.com>


Michael Felt added the comment:

On 4/28/2016 11:56 PM, Michael Felt wrote:
> Michael Felt added the comment:
>
> I have not looked specifically, at least not that I remember, for differences in util/ctypes in python2 and python3. Will do so tomorrow.
>
> I did just look briefly at the library, rather archive, built by default as libpython2.7.a - it is static members only, i.e., my build using xlc (i.e., not using gcc) does not build a shared object, so cdll.LoadLibrary and/or find_library will not find anything for python2.7.. Neither will m, or libm, on a default AIX system (with no other gcc based packages installed - these also install a gnu rte where the utilities and libs you mention might include.
>
> The few python packages I have found, packaged by others, tend to reload everything yet again, not depending on anything that may already be there. And to use shared libraries they are extracting the members from the .a archives into two directories - when they support both 32 and 64-bit targets.
>
> My intent is to examine the program to discover where libraries should be and find the member name that is most likely. Also, if LIBPATH is defined, those directories are searched first for a match.
>
> In short, the key difference is to look at the program (probably python) for the blibpath string in the application as well as python (from memory, sys.* calls) to build a list of directories to search.
>
> findLibrary('foo') first finds libfoo.a, then looks in libfoo.a for shr*.o members, libfoo.so, libfoo.so.X and/or libfoo.so.X.Y, etc..
>
> I need to check that findLibrary('foo.so') continues to work. At one time it did, just have not looked at this for several weeks and I forget if it still works. That is what I shall make sure stays in the "testing" part of the patch.
>
> Michael
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue26439>
> _______________________________________

I am reworking the logic - as many use cdll.LoadLibrary without ever 
calling find_library, and then __init__.py breaks.

More asap.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Fri Apr 29 15:13:39 2016
From: report at bugs.python.org (Peter L)
Date: Fri, 29 Apr 2016 19:13:39 +0000
Subject: [issue26886] Cross-compiling python:3.5.x fails with "Parser/pgen:
 Parser/pgen: cannot execute binary file"
In-Reply-To: <1461947375.28.0.628311795437.issue26886@psf.upfronthosting.co.za>
Message-ID: <1461957219.32.0.242743439715.issue26886@psf.upfronthosting.co.za>


Peter L added the comment:

Hmmm.  Solves half the problem. Still fails when trying to run "_freeze_importlib".

This works though:
https://hg.python.org/cpython/rev/66e40df31fac

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26886>
_______________________________________

From report at bugs.python.org  Fri Apr 29 15:24:17 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 Apr 2016 19:24:17 +0000
Subject: [issue26832] ProactorEventLoop doesn't support stdin/stdout nor files
 with connect_read_pipe/connect_write_pipe
In-Reply-To: <1461383150.45.0.258316694453.issue26832@psf.upfronthosting.co.za>
Message-ID: <1461957857.99.0.981359329694.issue26832@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The surprise to me, being on Windows, is that the pipe connection methods sometimes work with non-pipes.  The limitations of Windows event loops are given in https://docs.python.org/3/library/asyncio-eventloops.html#windows.  The pipe connection functions are discussed in https://docs.python.org/3/library/asyncio-eventloop.html#connect-pipes.  Both say that the methods do not work with Windows' SelectorEventLoop.

My understanding is that this is because Windows' select() call does not work with pipes -- meaning honest-to-goodness OS pipes.  So I understood "*pipe* is file-like object." more as a un-surprising statement of fact than as a permissive "'pipe' can be any file-like object and not necessarily a pipe".

If 'pipe' were intended to mean 'file-like', then why use 'pipe'?  But I can see how a current unix user would understand that sentence the other way.  Perhaps the sentence should read "For SelectorEventLoops (not on Windows), *pipe* can also be any file-like object with the appropriate methods." -- assuming that this is true on all non-Windows systems.

Isn't there some other way to asynchronously read/file files, as opposed to sockets and pipes, on Windows?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26832>
_______________________________________

From report at bugs.python.org  Fri Apr 29 15:30:20 2016
From: report at bugs.python.org (Peter L)
Date: Fri, 29 Apr 2016 19:30:20 +0000
Subject: [issue26886] Cross-compiling python:3.5.x fails with "Parser/pgen:
 Parser/pgen: cannot execute binary file"
In-Reply-To: <1461947375.28.0.628311795437.issue26886@psf.upfronthosting.co.za>
Message-ID: <1461958220.34.0.889973612732.issue26886@psf.upfronthosting.co.za>


Peter L added the comment:

Gonna close it since it seems to be related to

http://bugs.python.org/issue22359

and solved with

https://hg.python.org/cpython/rev/66e40df31fac

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26886>
_______________________________________

From report at bugs.python.org  Fri Apr 29 16:35:56 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Apr 2016 20:35:56 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461962156.77.0.0233744921336.issue26814@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Results of the CPython benchmark suite. Reference = default branch at rev 496e094f4734, patched: fastcall fork at rev 2b4b7def2949.

I got many issues to get a reliable benchmark output:

* https://mail.python.org/pipermail/speed/2016-April/000329.html
* https://mail.python.org/pipermail/speed/2016-April/000341.html

The benchmark was run with CPU isolation. Both binaries were compiled with PGO+LTO.

Report on Linux smithers 4.4.4-301.fc23.x86_64 #1 SMP Fri Mar 4 17:42:42 UTC 2016 x86_64 x86_64
Total CPU cores: 8

### call_method_slots ###
Min: 0.289704 -> 0.269634: 1.07x faster
Avg: 0.290149 -> 0.275953: 1.05x faster
Significant (t=162.17)
Stddev: 0.00019 -> 0.00150: 8.1176x larger

### call_method_unknown ###
Min: 0.275295 -> 0.302810: 1.10x slower
Avg: 0.280201 -> 0.309166: 1.10x slower
Significant (t=-200.65)
Stddev: 0.00161 -> 0.00191: 1.1909x larger

### call_simple ###
Min: 0.202163 -> 0.207939: 1.03x slower
Avg: 0.202332 -> 0.208662: 1.03x slower
Significant (t=-636.09)
Stddev: 0.00008 -> 0.00015: 2.0130x larger

### chameleon_v2 ###
Min: 4.349474 -> 3.901936: 1.11x faster
Avg: 4.377664 -> 3.942932: 1.11x faster
Significant (t=62.39)
Stddev: 0.01403 -> 0.06826: 4.8635x larger

### django_v3 ###
Min: 0.484456 -> 0.462013: 1.05x faster
Avg: 0.489186 -> 0.465189: 1.05x faster
Significant (t=53.10)
Stddev: 0.00415 -> 0.00180: 2.3096x smaller

### etree_generate ###
Min: 0.193538 -> 0.182069: 1.06x faster
Avg: 0.196306 -> 0.184403: 1.06x faster
Significant (t=65.94)
Stddev: 0.00140 -> 0.00115: 1.2181x smaller

### etree_iterparse ###
Min: 0.189955 -> 0.177583: 1.07x faster
Avg: 0.195268 -> 0.183411: 1.06x faster
Significant (t=27.04)
Stddev: 0.00316 -> 0.00304: 1.0386x smaller

### etree_process ###
Min: 0.166556 -> 0.158617: 1.05x faster
Avg: 0.168822 -> 0.160672: 1.05x faster
Significant (t=43.33)
Stddev: 0.00125 -> 0.00140: 1.1205x larger

### fannkuch ###
Min: 0.859842 -> 0.878412: 1.02x slower
Avg: 0.865138 -> 0.889188: 1.03x slower
Significant (t=-14.97)
Stddev: 0.00718 -> 0.01436: 2.0000x larger

### float ###
Min: 0.222095 -> 0.214706: 1.03x faster
Avg: 0.226273 -> 0.218210: 1.04x faster
Significant (t=21.61)
Stddev: 0.00307 -> 0.00212: 1.4469x smaller

### hexiom2 ###
Min: 100.489630 -> 94.765364: 1.06x faster
Avg: 101.204871 -> 94.885605: 1.07x faster
Significant (t=77.45)
Stddev: 0.25310 -> 0.05016: 5.0454x smaller

### meteor_contest ###
Min: 0.181076 -> 0.176904: 1.02x faster
Avg: 0.181759 -> 0.177783: 1.02x faster
Significant (t=43.68)
Stddev: 0.00061 -> 0.00067: 1.1041x larger

### nbody ###
Min: 0.208752 -> 0.217011: 1.04x slower
Avg: 0.211552 -> 0.219621: 1.04x slower
Significant (t=-69.45)
Stddev: 0.00080 -> 0.00084: 1.0526x larger

### pathlib ###
Min: 0.077121 -> 0.070698: 1.09x faster
Avg: 0.078310 -> 0.071958: 1.09x faster
Significant (t=133.39)
Stddev: 0.00069 -> 0.00081: 1.1735x larger

### pickle_dict ###
Min: 0.530379 -> 0.514363: 1.03x faster
Avg: 0.531325 -> 0.515902: 1.03x faster
Significant (t=154.33)
Stddev: 0.00086 -> 0.00050: 1.7213x smaller

### pickle_list ###
Min: 0.253445 -> 0.263959: 1.04x slower
Avg: 0.255362 -> 0.267402: 1.05x slower
Significant (t=-95.47)
Stddev: 0.00075 -> 0.00101: 1.3447x larger

### raytrace ###
Min: 1.071042 -> 1.030849: 1.04x faster
Avg: 1.076629 -> 1.109029: 1.03x slower
Significant (t=-3.93)
Stddev: 0.00199 -> 0.08246: 41.4609x larger

### regex_compile ###
Min: 0.286053 -> 0.273454: 1.05x faster
Avg: 0.287171 -> 0.274422: 1.05x faster
Significant (t=153.16)
Stddev: 0.00067 -> 0.00050: 1.3452x smaller

### regex_effbot ###
Min: 0.044186 -> 0.048192: 1.09x slower
Avg: 0.044336 -> 0.048513: 1.09x slower
Significant (t=-172.41)
Stddev: 0.00020 -> 0.00014: 1.4671x smaller

### richards ###
Min: 0.137456 -> 0.135029: 1.02x faster
Avg: 0.138993 -> 0.136028: 1.02x faster
Significant (t=20.35)
Stddev: 0.00116 -> 0.00088: 1.3247x smaller

### silent_logging ###
Min: 0.060288 -> 0.056344: 1.07x faster
Avg: 0.060380 -> 0.056518: 1.07x faster
Significant (t=310.27)
Stddev: 0.00011 -> 0.00005: 2.1029x smaller

### telco ###
Min: 0.010735 -> 0.010441: 1.03x faster
Avg: 0.010849 -> 0.010557: 1.03x faster
Significant (t=34.04)
Stddev: 0.00007 -> 0.00005: 1.3325x smaller

### unpickle_list ###
Min: 0.290750 -> 0.297958: 1.02x slower
Avg: 0.292741 -> 0.299419: 1.02x slower
Significant (t=-41.62)
Stddev: 0.00133 -> 0.00090: 1.4852x smaller

The following not significant results are hidden, use -v to show them:
2to3, call_method, chaos, etree_parse, fastpickle, fastunpickle, formatted_logging, go, json_dump_v2, json_load, mako_v2, normal_startup, nqueens, pidigits, regex_v8, simple_logging, spectral_norm, startup_nosite, tornado_http, unpack_sequence.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Fri Apr 29 16:37:52 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Apr 2016 20:37:52 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461962272.49.0.392099517427.issue26814@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Results of the CPython benchmark suite. Reference = default branch at rev 496e094f4734, patched: fastcall fork at rev 2b4b7def2949.

Oh, I forgot to mention that I modified perf.py to run each benchmark using 10 fresh processes to test multiple random seeds for the randomized hash function, instead of testing a fixed seed (PYTHONHASHSEED=1). This change should reduce the noise in the benchmark results.

I ran the benchmark suite using --rigorous.

I will open a new issue later for my perf.py change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Fri Apr 29 16:43:13 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 29 Apr 2016 20:43:13 +0000
Subject: [issue10850] inconsistent behavior concerning
 multiprocessing.manager.BaseManager._Server
In-Reply-To: <1294360374.53.0.588595674921.issue10850@psf.upfronthosting.co.za>
Message-ID: <1461962593.61.0.699162186894.issue10850@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10850>
_______________________________________

From report at bugs.python.org  Fri Apr 29 16:56:45 2016
From: report at bugs.python.org (Ron Barak)
Date: Fri, 29 Apr 2016 20:56:45 +0000
Subject: [issue26887] Erratum in
 https://docs.python.org/2.6/library/multiprocessing.html
Message-ID: <1461963405.27.0.843692247406.issue26887@psf.upfronthosting.co.za>


New submission from Ron Barak:

Erratum in https://docs.python.org/2.6/library/multiprocessing.html:

The chunksize argument is the same as the one used by the map() method. For very long iterables using a large value for chunksize can make >>>make<<< the job complete much faster than using the default value of 1.

----------
messages: 264520
nosy: ronbarak
priority: normal
severity: normal
status: open
title: Erratum in https://docs.python.org/2.6/library/multiprocessing.html
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26887>
_______________________________________

From report at bugs.python.org  Fri Apr 29 17:02:59 2016
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 29 Apr 2016 21:02:59 +0000
Subject: [issue26887] Erratum in
 https://docs.python.org/2.6/library/multiprocessing.html
In-Reply-To: <1461963405.27.0.843692247406.issue26887@psf.upfronthosting.co.za>
Message-ID: <1461963779.71.0.419062361555.issue26887@psf.upfronthosting.co.za>


Zachary Ware added the comment:

The documentation for 2.6 is no longer maintained (and neither is 2.6 itself, so we highly recommend upgrading to at least 2.7 if at all possible), and this has already been fixed in 2.7.

Thanks for the report anyway!

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26887>
_______________________________________

From report at bugs.python.org  Fri Apr 29 17:14:58 2016
From: report at bugs.python.org (Aleksander Gajewski)
Date: Fri, 29 Apr 2016 21:14:58 +0000
Subject: [issue26888] Multiple memory leaks after raw Py_Initialize and
 Py_Finalize.
Message-ID: <1461964498.64.0.249239175864.issue26888@psf.upfronthosting.co.za>


New submission from Aleksander Gajewski:

There are a lot of memory leaks detected by AddressSanitzer (used with gcc-6.1). The sample program with its cmakelists and output can be found in the attachment. Exact list of memory leaks is placed in log_3_python_test.txt. I am using Python3.5.1 compile from sources (placed in /opt/python).

----------
components: Library (Lib)
files: python_leak.tar
messages: 264522
nosy: Aleksander Gajewski
priority: normal
severity: normal
status: open
title: Multiple memory leaks after raw Py_Initialize and Py_Finalize.
type: resource usage
versions: Python 3.5
Added file: http://bugs.python.org/file42655/python_leak.tar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26888>
_______________________________________

From report at bugs.python.org  Fri Apr 29 17:26:47 2016
From: report at bugs.python.org (Steve Dower)
Date: Fri, 29 Apr 2016 21:26:47 +0000
Subject: [issue26832] ProactorEventLoop doesn't support stdin/stdout nor files
 with connect_read_pipe/connect_write_pipe
In-Reply-To: <1461383150.45.0.258316694453.issue26832@psf.upfronthosting.co.za>
Message-ID: <1461965207.03.0.630519738356.issue26832@psf.upfronthosting.co.za>


Steve Dower added the comment:

Pipes and file handles are equivalent in Windows, but socket handles are their own namespace and have their own functions. Some Python code will switch between them automatically to make socket functions work with file descriptors, but generally I'd expect stream pipes (as opposed to, IIRC, datagram pipes) to be compatible with files but not sockets.

Not entirely sure how that plays into this issue, but it's a bit more background.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26832>
_______________________________________

From report at bugs.python.org  Fri Apr 29 17:39:16 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 29 Apr 2016 21:39:16 +0000
Subject: [issue26889] Improve Doc/library/xmlrpc.client.rst
Message-ID: <1461965955.82.0.756722302068.issue26889@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch makes minor improvements of Doc/library/xmlrpc.client.rst.

----------
components: Extension Modules
files: docs_xmlrpc_client.patch
keywords: patch
messages: 264524
nosy: effbot, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Improve Doc/library/xmlrpc.client.rst
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42656/docs_xmlrpc_client.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26889>
_______________________________________

From report at bugs.python.org  Fri Apr 29 17:39:27 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 29 Apr 2016 21:39:27 +0000
Subject: [issue26889] Improve Doc/library/xmlrpc.client.rst
In-Reply-To: <1461965955.82.0.756722302068.issue26889@psf.upfronthosting.co.za>
Message-ID: <1461965967.24.0.696913553882.issue26889@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation -Extension Modules
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26889>
_______________________________________

From report at bugs.python.org  Fri Apr 29 17:43:53 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 29 Apr 2016 21:43:53 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461966233.19.0.719274481062.issue26814@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you repeat benchmarks on different computer? Better with different CPU or compiler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Fri Apr 29 17:55:12 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Apr 2016 21:55:12 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461966912.97.0.308575242022.issue26814@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Could you repeat benchmarks on different computer? Better with different CPU or compiler.

Sorry, I don't really have the bandwith to repeat the benchmarks. PGO+LTO compilation is slow and running the benchmark suite in rigorous mode is very slow.

What do you expect from running the benchmark on a different computer?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Fri Apr 29 18:13:24 2016
From: report at bugs.python.org (Francisco Couzo)
Date: Fri, 29 Apr 2016 22:13:24 +0000
Subject: [issue26830] Refactor Tools/scripts/google.py
In-Reply-To: <1461346654.96.0.919095766119.issue26830@psf.upfronthosting.co.za>
Message-ID: <1461968004.14.0.699716598218.issue26830@psf.upfronthosting.co.za>


Francisco Couzo added the comment:

Here's the patch with the modifications from the review.

----------
Added file: http://bugs.python.org/file42657/scripts_google_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26830>
_______________________________________

From report at bugs.python.org  Fri Apr 29 18:14:43 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 29 Apr 2016 22:14:43 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1461968083.31.0.37041759762.issue26219@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Victor brought this patch to my attention as the motivation for PEP 509. Unfortunately the patch doesn't apply cleanly and I don't have time to try and piece together all the different parts. From the description on python-dev you linked to there are actually a few different patches that all work together and result in a significant speedup. Is there any chance that you could get all this up to date so it applies cleanly to the CPython 3.6 repo (the hg version!), and report some realistic benchmarks? The speedups reported sound great, but I worry that there's a catch (e.g. memory cost that doesn't become apparent until you have a large program, or minimal speedup on realistic code). This is currently holding up approval of PEP 509.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26219>
_______________________________________

From report at bugs.python.org  Fri Apr 29 18:16:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 29 Apr 2016 22:16:35 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461968195.7.0.527634436941.issue26814@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Results look as a noise. Some tests become slower, others become faster. If results on different machine will show the same sets of slowing down and speeding up tests, this likely is not a noise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Fri Apr 29 18:23:44 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Apr 2016 22:23:44 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1461968624.51.0.772422434082.issue26814@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Results look as a noise.

As I wrote, it's really hard to get a reliable benchmark result. I did my best.

See also discussions about the CPython benchmark suite on the speed list:
https://mail.python.org/pipermail/speed/

I'm not sure that you will get less noise on other computers. IMHO many benchmarks are simply "broken" (not reliable).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Fri Apr 29 18:27:31 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 29 Apr 2016 22:27:31 +0000
Subject: [issue26822] itemgetter/attrgetter/methodcaller objects ignore
 keyword arguments
In-Reply-To: <1461266621.67.0.0664681491354.issue26822@psf.upfronthosting.co.za>
Message-ID: <1461968851.39.0.922368648911.issue26822@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Can't we use a macro to implement this micro-optimization, instead of modifying each call to _PyArg_NoKeywords?

I proposed this idea above. But then I have found that 1) most usages of _PyArg_NoKeywords are not in performance critical code and 2) my attempt caused a crash. Thus I have committed simpler patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26822>
_______________________________________

From report at bugs.python.org  Fri Apr 29 18:43:57 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 29 Apr 2016 22:43:57 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1461969837.55.0.78610359087.issue26219@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Hi Guido, I'll try to update the patch soon.

> but I worry that there's a catch (e.g. memory cost that doesn't become apparent until you have a large program, or minimal speedup on realistic code).

Here's an excerpt from my email [1] to Python-dev on memory footprint:

To measure the max/average memory impact, I tuned my code to optimize 
*every* code object on *first* run.  Then I ran the entire Python test 
suite.  Python test suite + standard library both contain around 72395 
code objects, which required 20Mb of memory for caches.  The test 
process consumed around 400Mb of memory.  Thus, the absolute worst case 
scenario, the overhead is about 5%.

[1] https://mail.python.org/pipermail/python-dev/2016-February/143025.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26219>
_______________________________________

From report at bugs.python.org  Fri Apr 29 18:51:19 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 29 Apr 2016 22:51:19 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1461969837.55.0.78610359087.issue26219@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLYCGfJAtkLh7RQrNJcKVnBQ-H0TN3mmimuUxjc=0OVuA@mail.gmail.com>


Guido van Rossum added the comment:

Thanks, that's a cool stat. Please do update the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26219>
_______________________________________

From report at bugs.python.org  Fri Apr 29 19:06:31 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 29 Apr 2016 23:06:31 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1461971191.89.0.425500439667.issue26219@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Alright, attaching a rebased patch (opcache3.patch).

Some caveats:

1. The patch embeds a fairly outdated PEP 509 implementation.

2. A PoC implementation of LOAD_METHOD opcode that should be really cleaned-up (and some parts of it rewritten).

3. I was going to spend more time on ceval.c code to make it lighter, and, perhaps, break large chunks of code into small functions.

All in all, this patch can be used for benchmarking, but it's not yet ready for a thorough code review.

Last thing, if you flip OPCODE_CACHE_STATS to 1 in ceval.c, python will print debug stats on opcode cache.

----------
Added file: http://bugs.python.org/file42658/opcache3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26219>
_______________________________________

From report at bugs.python.org  Fri Apr 29 19:07:08 2016
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 29 Apr 2016 23:07:08 +0000
Subject: [issue26871] Change weird behavior of PyModule_AddObject()
In-Reply-To: <1461779571.56.0.960686965696.issue26871@psf.upfronthosting.co.za>
Message-ID: <1461971228.07.0.989052386195.issue26871@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Serhiy, I'm sorry that I overreacted here. You're doing great work for
Python -- we just happen to disagree on this one particular issue.

I think there were some proponents on python-dev, perhaps they'll show
up and discuss the details.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26871>
_______________________________________

From report at bugs.python.org  Fri Apr 29 19:10:33 2016
From: report at bugs.python.org (Demur Rumed)
Date: Fri, 29 Apr 2016 23:10:33 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1461971433.74.0.127014830466.issue26647@psf.upfronthosting.co.za>


Demur Rumed added the comment:

Plain git diff formatted patch. I installed mercurial but then `hg clone https://hg.python.org/cpython` failed twice over weird protocol errors (2nd one had to do with negative length) so I gave up

----------
Added file: http://bugs.python.org/file42659/wpy7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Fri Apr 29 19:43:13 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 29 Apr 2016 23:43:13 +0000
Subject: [issue26826] Expose new copy_file_range() syscal in os module.
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1461973393.7.0.126092677308.issue26826@psf.upfronthosting.co.za>


Martin Panter added the comment:

For the generated files, it doesn?t matter much either way for review (I can just ignore them). As long as the eventual committer remembers to regenerate them. (Personally I?d prefer not to keep these files in the respository, but that?s a different can of worms :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Fri Apr 29 23:33:07 2016
From: report at bugs.python.org (Sebastien Bourdeauducq)
Date: Sat, 30 Apr 2016 03:33:07 +0000
Subject: [issue26890] inspect.getsource gets source copy on disk even when
 module has not been reloaded
Message-ID: <1461987187.54.0.900828586529.issue26890@psf.upfronthosting.co.za>


New submission from Sebastien Bourdeauducq:

The fix of https://bugs.python.org/issue1218234 is a bit zealous. If the module has not been reloaded, e.g. calling a function will execute code older than what inspect.getsource returns.

----------
components: Library (Lib)
messages: 264538
nosy: sebastien.bourdeauducq
priority: normal
severity: normal
status: open
title: inspect.getsource gets source copy on disk even when module has not been reloaded
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26890>
_______________________________________

From report at bugs.python.org  Fri Apr 29 23:45:04 2016
From: report at bugs.python.org (Sebastien Bourdeauducq)
Date: Sat, 30 Apr 2016 03:45:04 +0000
Subject: [issue26890] inspect.getsource gets source copy on disk even when
 module has not been reloaded
In-Reply-To: <1461987187.54.0.900828586529.issue26890@psf.upfronthosting.co.za>
Message-ID: <1461987904.22.0.890368495919.issue26890@psf.upfronthosting.co.za>


Sebastien Bourdeauducq added the comment:

And since the import statement does not touch linecache, there are many other cases where inspect.getsource and objects can be out of sync.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26890>
_______________________________________

From report at bugs.python.org  Fri Apr 29 23:46:30 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Apr 2016 03:46:30 +0000
Subject: [issue26864] urllib.request no_proxy check differs from curl
In-Reply-To: <1461681827.76.0.743158989172.issue26864@psf.upfronthosting.co.za>
Message-ID: <20160430034625.34495.94599.11B704B2@psf.io>


Roundup Robot added the comment:

New changeset ca882ee68d46 by Martin Panter in branch '3.5':
Issue #26864: Fix case insensitivity and suffix comparison with no_proxy
https://hg.python.org/cpython/rev/ca882ee68d46

New changeset 1ceb91974dc4 by Martin Panter in branch 'default':
Issue #26864: Merge no_proxy fixes from 3.5
https://hg.python.org/cpython/rev/1ceb91974dc4

New changeset a1aad42f1195 by Martin Panter in branch '2.7':
Issue #26864: Fix case insensitivity and suffix comparison with no_proxy
https://hg.python.org/cpython/rev/a1aad42f1195

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26864>
_______________________________________

From report at bugs.python.org  Sat Apr 30 00:36:38 2016
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 30 Apr 2016 04:36:38 +0000
Subject: [issue26891] CPython doesn't work when you disable refcounting
Message-ID: <1461990997.54.0.540088358275.issue26891@psf.upfronthosting.co.za>


New submission from Larry Hastings:

So here's a strange one.

I want to do some mysterious experiments with CPython.  So I disabled refcount changes in CPython.

I changed Py_INCR and Py_DECR so they expand to nothing.  I had to change some other macros to match (SETREF, XSETREF, and the Py_RETURN_* ones) to fix some compiler errors and warnings.  Also, to prevent the str object from making in-place edits, I changed _Py_NewReference so that the initial reference count for all objects is 2.

CPython builds, then gets to the "generate-posix-vars" step and fails with this output:

./python -E -S -m sysconfig --generate-posix-vars ;\
if test $? -ne 0 ; then \
        echo "generate-posix-vars failed" ; \
        rm -f ./pybuilddir.txt ; \
        exit 1 ; \
fi
Fatal Python error: Py_Initialize: Unable to get the locale encoding
Traceback (most recent call last):
  File "<frozen importlib._bootstrap_external>", line 1078, in _path_importer_cache
KeyError: '/usr/local/lib/python36.zip'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<frozen importlib._bootstrap>", line 979, in _find_and_load
  File "<frozen importlib._bootstrap>", line 964, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 903, in _find_spec
  File "<frozen importlib._bootstrap_external>", line 1137, in find_spec
  File "<frozen importlib._bootstrap_external>", line 1108, in _get_spec
  File "<frozen importlib._bootstrap_external>", line 1080, in _path_importer_cache
  File "<frozen importlib._bootstrap_external>", line 1056, in _path_hooks
  File "<frozen importlib._bootstrap_external>", line 1302, in path_hook_for_FileFinder
  File "<frozen importlib._bootstrap_external>", line 96, in _path_isdir
  File "<frozen importlib._bootstrap_external>", line 81, in _path_is_mode_type
  File "<frozen importlib._bootstrap_external>", line 75, in _path_stat
AttributeError: module 'posix' has no attribute 'stat'
Aborted (core dumped)
generate-posix-vars failed
Makefile:598: recipe for target 'pybuilddir.txt' failed
make: *** [pybuilddir.txt] Error 1

I'm stumped.  Why should CPython be dependent on reference counts actually changing?  I figured I'd just leak memory like crazy, not change behavior.

Attached is my patch against current trunk (1ceb91974dc4) in case you want to try it yourself.  Testing was done on Ubuntu 15.10 64-bit, gcc 5.2.1.

----------
components: Interpreter Core
files: larry.turn.off.refcounts.1.diff.txt
messages: 264541
nosy: brett.cannon, larry
priority: low
severity: normal
stage: needs patch
status: open
title: CPython doesn't work when you disable refcounting
type: behavior
Added file: http://bugs.python.org/file42660/larry.turn.off.refcounts.1.diff.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26891>
_______________________________________

From report at bugs.python.org  Sat Apr 30 00:36:50 2016
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 30 Apr 2016 04:36:50 +0000
Subject: [issue26891] CPython doesn't work when you disable refcounting
In-Reply-To: <1461990997.54.0.540088358275.issue26891@psf.upfronthosting.co.za>
Message-ID: <1461991010.06.0.287789397797.issue26891@psf.upfronthosting.co.za>


Changes by Larry Hastings <larry at hastings.org>:


----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26891>
_______________________________________

From report at bugs.python.org  Sat Apr 30 01:06:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Apr 2016 05:06:30 +0000
Subject: [issue26891] CPython doesn't work when you disable refcounting
In-Reply-To: <1461990997.54.0.540088358275.issue26891@psf.upfronthosting.co.za>
Message-ID: <1461992790.56.0.572579544569.issue26891@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is other code that sets refcount.

Include/object.h:764:    Py_REFCNT(op) = 1)
Objects/moduleobject.c:38:        Py_REFCNT(def) = 1;
Objects/longobject.c:5450:            Py_REFCNT(op) = refcnt + 1;
Objects/unicodeobject.c:1762:        Py_REFCNT(unicode) = 3;
Objects/unicodeobject.c:15044:    Py_REFCNT(s) -= 2;
Objects/unicodeobject.c:15103:            Py_REFCNT(s) += 1;
Objects/unicodeobject.c:15107:            Py_REFCNT(s) += 2;

I would suggest to set initial refcount to 1000000000, define Py_REFCNT(s) as returning constant 1000000000, and fix subsequent compiler errors.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26891>
_______________________________________

From report at bugs.python.org  Sat Apr 30 01:22:59 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Apr 2016 05:22:59 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1461993779.89.0.628091139976.issue26647@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file42661/wpy7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Sat Apr 30 02:24:23 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 30 Apr 2016 06:24:23 +0000
Subject: [issue24434] ItemsView.__contains__ does not mimic dict_items
In-Reply-To: <1434050451.28.0.415875303865.issue24434@psf.upfronthosting.co.za>
Message-ID: <1461997463.4.0.166045210997.issue24434@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

After reading issue4296, I agree with Serhiy's point on the second issue. Right now, (1, math.nan) in ItemsView({1: math.nan}) returns false which seems not acceptable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24434>
_______________________________________

From report at bugs.python.org  Sat Apr 30 04:04:36 2016
From: report at bugs.python.org (Michael Felt)
Date: Sat, 30 Apr 2016 08:04:36 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1462003476.91.0.65856036906.issue26439@psf.upfronthosting.co.za>


Michael Felt added the comment:

Question - before I submit a patch.

A. Is there a PEP I should read re: ctypes/util and/or ctypes/cdll?

B. I show two different behaviors of responding - My question is, what does the community think should be the response? My preference is to bring the request back to it's stub - (strip lib from the beginning, and .so* or .a from the suffix, so that it is in it's -lFOO form - as if being offered to a linker (with -lFOO, we do not use -lFOO.so.6 (e.g., for libc.so.6).
I have seen a lot of variance in how cdll is used (in only two python based projects I am currently interested in porting). Calls are frequently made using some variation including .so somewhere in the name and/or code is basing decesions based on a the number (###) returned by find_library (e.g., libFOO.so.###, and ### MUST be one of a list - and is rejected if not a match (even if newer)). I would think if there is a version dependancy this should be a call to the library loaded rather than an external string.
In any case, - for one example - as libc.so.* will never exist, by default, on AIX, for ease of use I believe that translating libFOO.* to FOO and then doing the 'find' comes closest to what was intended (long long ago) - again, is there a PEP with guidance on this AND my preference, for AIX, is to look in .a archives first for a .so member, and then look for an AIX legacy member (shr.*.o) and then look for an external .so.* file.

With my current working version - this is the output of the test in util.py:

root at x064:[/data/prj/aixtools/python/python-2.7.11.3/Lib/ctypes]../../python ./util.py
libm.a
libc.a
libbz2.a
<CDLL 'None', handle b at 700000000216630>
<CDLL 'libcrypt.a(shr_64.o)', handle c at 700000000216630>
libcrypt.a

Additional Tests for AIX
call find_library("foo")
c:  libc.a
c.a:  None
c.so:  None
libc:  libc.a
libc.a:  libc.a
libc.so.6:  libc.a
crypt:  libcrypt.a
crypto:  libcrypto.a
crypto.so:  None
libcrypto.so:  libcrypto.a

call cdll.LoadLibrary("foo")
m:  <CDLL 'None', handle d at 700000000216860>
libm.so:  <CDLL 'None', handle e at 700000000216860>
c:  <CDLL 'libc.a(shr_64.o)', handle f at 700000000216860>
c.a:  <CDLL 'libc.a(shr_64.o)', handle 10 at 700000000216860>
libc.a:  <CDLL 'libc.a(shr_64.o)', handle 11 at 700000000216860>
libc.so.6:  <CDLL 'libc.a(shr_64.o)', handle 12 at 700000000216860>
libc.so.9:  <CDLL 'libc.a(shr_64.o)', handle 13 at 700000000216860>
bz2:  <CDLL 'libbz2.a(libbz2.so.1)', handle 14 at 700000000216860>
libbz2:  <CDLL 'libbz2.a(libbz2.so.1)', handle 15 at 700000000216860>
crypt:  <CDLL 'libcrypt.a(shr_64.o)', handle 16 at 700000000216860>
crypto:  <CDLL 'libcrypto.a(libcrypto64.so)', handle 17 at 700000000216860>
crypto.so:  <CDLL 'libcrypto.a(libcrypto64.so)', handle 18 at 700000000216860>
libcrypto.so:  <CDLL 'libcrypto.a(libcrypto64.so)', handle 19 at 700000000216860>
iconv:  <CDLL 'libiconv.a(libiconv.so.2)', handle 1a at 700000000216860>
intl:  <CDLL 'libintl.a(libintl.so.1)', handle 1b at 700000000216860>

The test looks like:
################################################################
# test code

def test():
    from ctypes import cdll
    if os.name == "nt":
        print cdll.msvcrt
        print cdll.load("msvcrt")
        print find_library("msvcrt")

    if os.name == "posix":
        # find and load_version
        print find_library("m")
        print find_library("c")
        print find_library("bz2")

        # getattr
##        print cdll.m
##        print cdll.bz2

        # load
        if sys.platform == "darwin":
            print cdll.LoadLibrary("libm.dylib")
            print cdll.LoadLibrary("libcrypto.dylib")
            print cdll.LoadLibrary("libSystem.dylib")
            print cdll.LoadLibrary("System.framework/System")
        else:
            print cdll.LoadLibrary("libm.so")
            print cdll.LoadLibrary("libcrypt.so")
            print find_library("crypt")

        if sys.platform.startswith("aix"):
            print "\nAdditional Tests for AIX"
            print "call find_library(\"foo\")"
            print "c: ", find_library("c")
            print "c.a: ", find_library("c.a")
            print "c.so: ", find_library("c.so")
            print "libc: ", find_library("libc")
            print "libc.a: ", find_library("libc.a")
            print "libc.so.6: ", find_library("libc.so.6")
            print "crypt: ", find_library("crypt")
            print "crypto: ", find_library("crypto")
            print "crypto.so: ", find_library("crypto.so")
            print "libcrypto.so: ", find_library("libcrypto.so")
###
            print "\ncall cdll.LoadLibrary(\"foo\")"
            print "m: ", cdll.LoadLibrary("m")
            print "libm.so: ", cdll.LoadLibrary("libm.so")
            print "c: ", cdll.LoadLibrary("c")
            print "c.a: ", cdll.LoadLibrary("c.a")
            print "libc.a: ", cdll.LoadLibrary("libc.a")
            print "libc.so.6: ", cdll.LoadLibrary("libc.so.6")
            print "libc.so.9: ", cdll.LoadLibrary("libc.so.9")
            print "bz2: ", cdll.LoadLibrary("bz2")
            print "libbz2: ", cdll.LoadLibrary("libbz2")
            print "crypt: ", cdll.LoadLibrary("crypt")
            print "crypto: ", cdll.LoadLibrary("crypto")
            print "crypto.so: ", cdll.LoadLibrary("crypto.so")
            print "libcrypto.so: ", cdll.LoadLibrary("libcrypto.so")
            print "iconv: ", cdll.LoadLibrary("iconv")
            print "intl: ", cdll.LoadLibrary("intl")

if __name__ == "__main__":
    test()

Thank you for your considered comments. My goal is ease of use for (porting) existing projects to AIX, i.e., ideally without code change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Sat Apr 30 04:17:14 2016
From: report at bugs.python.org (Yolanda)
Date: Sat, 30 Apr 2016 08:17:14 +0000
Subject: [issue26807] mock_open()().readline() fails at EOF
In-Reply-To: <1461140283.7.0.219960203136.issue26807@psf.upfronthosting.co.za>
Message-ID: <1462004234.72.0.579452614018.issue26807@psf.upfronthosting.co.za>


Yolanda added the comment:

How about...

@@ -2339,9 +2339,12 @@ def mock_open(mock=None, read_data=''):
         if handle.readline.return_value is not None:
             while True:
                 yield handle.readline.return_value
-        for line in _state[0]:
-            yield line
 
+        try:
+            while True:
+                yield next(_state[0])
+        except StopIteration:
+            yield ''

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26807>
_______________________________________

From report at bugs.python.org  Sat Apr 30 05:47:55 2016
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 30 Apr 2016 09:47:55 +0000
Subject: [issue26891] CPython doesn't work when you disable refcounting
In-Reply-To: <1461990997.54.0.540088358275.issue26891@psf.upfronthosting.co.za>
Message-ID: <1462009675.17.0.935897603514.issue26891@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I did as you suggested.  I also discovered that _Py_NewReference is usually a macro, and I'd only fixed the version in Objects/object.c (the one not being used).  When I fixed both those things, and switched the makefile so it uses a different Python interpreter in the build itself, it builds successfully.  The interpreter doesn't run though.

The next problem: there are a couple of spots where code asserts the refcount of an object must == 1.  This is so they can modify the object in-place.  This is usually a sanity-check, so I assume the code knows what it's doing, so I removed the refcount assertion.  I did this two or three times: set, unicode, and (maybe) bytes.

Now it's segfaulting in lookdict_unicode_nodummy().  mp->ma_keys looks like garbage, the keys it refers to are invalid addresses.  I'd be very happy to post my patch if someone else wanted to try debugging it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26891>
_______________________________________

From report at bugs.python.org  Sat Apr 30 06:04:43 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Sat, 30 Apr 2016 10:04:43 +0000
Subject: [issue26892] debuglevel not honored in urllib
Message-ID: <1462010683.91.0.12780176416.issue26892@psf.upfronthosting.co.za>


New submission from Chi Hsuan Yen:

The following test program:

import sys
try:
    import urllib.request as urllib_request
except:
    import urllib2 as urllib_request

print(sys.version)

handler = urllib_request.HTTPSHandler(debuglevel=1)
opener = urllib_request.build_opener(handler)
print(opener.open('https://httpbin.org/user-agent').read().decode('utf-8'))

Works as expected in Python 2:
$ python2 test_urllib_debuglevel.py
2.7.11 (default, Mar 31 2016, 06:18:34) 
[GCC 5.3.0]
send: 'GET /user-agent HTTP/1.1\r\nAccept-Encoding: identity\r\nHost: httpbin.org\r\nConnection: close\r\nUser-Agent: Python-urllib/2.7\r\n\r\n'
reply: 'HTTP/1.1 200 OK\r\n'
header: Server: nginx
header: Date: Sat, 30 Apr 2016 10:02:32 GMT
header: Content-Type: application/json
header: Content-Length: 40
header: Connection: close
header: Access-Control-Allow-Origin: *
header: Access-Control-Allow-Credentials: true
{
  "user-agent": "Python-urllib/2.7"
}

But the verbose output is unavailable in Python 3.x:
$ ./python test_urllib_debuglevel.py
3.6.0a0 (default:1ceb91974dc4, Apr 30 2016, 17:44:57) 
[GCC 5.3.0]
{
  "user-agent": "Python-urllib/3.6"
}

Patch attached.

----------
components: Library (Lib)
files: urllib_debuglevel.patch
keywords: patch
messages: 264547
nosy: Chi Hsuan Yen
priority: normal
severity: normal
status: open
title: debuglevel not honored in urllib
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file42662/urllib_debuglevel.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26892>
_______________________________________

From report at bugs.python.org  Sat Apr 30 06:35:10 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 30 Apr 2016 10:35:10 +0000
Subject: [issue9303] Migrate sqlite3 module to _v2 API to enhance performance
In-Reply-To: <1279541286.68.0.824716490463.issue9303@psf.upfronthosting.co.za>
Message-ID: <1462012510.24.0.0214058276341.issue9303@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

I made a new patch to fix this issue. I left a fallback to the old API as Jim suggested. In addition to the changes in Robin`s patch I changed sqlite3_close to sqlite3_close_v2 if available.

This solves issue 26187 as well.

----------
nosy: +palaviv
Added file: http://bugs.python.org/file42663/9303.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9303>
_______________________________________

From report at bugs.python.org  Sat Apr 30 06:37:45 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 30 Apr 2016 10:37:45 +0000
Subject: [issue26187] sqlite3 trace callback prints duplicate line
In-Reply-To: <1453577672.38.0.77226221379.issue26187@psf.upfronthosting.co.za>
Message-ID: <1462012665.5.0.536878688883.issue26187@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

This issue will be resolved when we change the sqlite3_prepare to sqlite3_prepare_v2. So there should be a dependency on issue 9303.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26187>
_______________________________________

From report at bugs.python.org  Sat Apr 30 06:40:18 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Apr 2016 10:40:18 +0000
Subject: [issue26891] CPython doesn't work when you disable refcounting
In-Reply-To: <1461990997.54.0.540088358275.issue26891@psf.upfronthosting.co.za>
Message-ID: <1462012818.04.0.675162059187.issue26891@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Just now I'm reading the code of the peephole optimizer, and it contains such assertion since it modifies the lnotab bytes array in-place. May be there are other similar cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26891>
_______________________________________

From report at bugs.python.org  Sat Apr 30 06:46:37 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 30 Apr 2016 10:46:37 +0000
Subject: [issue24887] Sqlite3 has no option to provide open flags
In-Reply-To: <1439898126.92.0.460778309784.issue24887@psf.upfronthosting.co.za>
Message-ID: <1462013197.92.0.420402843082.issue24887@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

IMO this issue can be closed as the URI filename interface can be used instead of the flags. The URI interface parameters can override the flags given as specified in:
https://www.sqlite.org/c3ref/open.html

----------
nosy: +palaviv

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24887>
_______________________________________

From report at bugs.python.org  Sat Apr 30 07:52:45 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 30 Apr 2016 11:52:45 +0000
Subject: [issue23960] PyErr_SetImportError doesn't clean up on some errors
In-Reply-To: <1429053168.87.0.990858167954.issue23960@psf.upfronthosting.co.za>
Message-ID: <1462017165.6.0.603151872171.issue23960@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch. I left review comments on Rietveld (click to the review link above).

----------
nosy: +berker.peksag
stage:  -> patch review
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23960>
_______________________________________

From report at bugs.python.org  Sat Apr 30 08:29:52 2016
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 30 Apr 2016 12:29:52 +0000
Subject: [issue26891] CPython doesn't work when you disable refcounting
In-Reply-To: <1461990997.54.0.540088358275.issue26891@psf.upfronthosting.co.za>
Message-ID: <1462019392.26.0.588475309596.issue26891@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Here is my theory: if the code asserts that it's true, and the code normally runs fine, then it's normally true, and therefore I can remove the assertion and the code will run correctly.  I haven't hit that assertion in the peephole optimizer.  But I have assertions turned off.

The checks in unicode / set / bytes (maybe) were not regulated by _NDEBUG, they were unconditional "if (refcnt != 1) BadInternalCall();" code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26891>
_______________________________________

From report at bugs.python.org  Sat Apr 30 08:35:26 2016
From: report at bugs.python.org (Julien Enche)
Date: Sat, 30 Apr 2016 12:35:26 +0000
Subject: [issue26893] ValueError exception raised when using IntEnum with an
 attribute called "name" and @unique decorator
Message-ID: <1462019726.06.0.0957572026567.issue26893@psf.upfronthosting.co.za>


New submission from Julien Enche:

The linked file fails with the following error :
ValueError: duplicate values found in <enum 'User'>: id -> User.name, name -> User.name

This exception was not raised with Python 3.4.

----------
files: enumtest.py
messages: 264554
nosy: Julien Enche
priority: normal
severity: normal
status: open
title: ValueError exception raised when using IntEnum with an attribute called "name" and @unique decorator
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file42664/enumtest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26893>
_______________________________________

From report at bugs.python.org  Sat Apr 30 08:47:56 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 30 Apr 2016 12:47:56 +0000
Subject: [issue26864] urllib.request no_proxy check differs from curl
In-Reply-To: <1461681827.76.0.743158989172.issue26864@psf.upfronthosting.co.za>
Message-ID: <1462020476.89.0.519480115199.issue26864@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26864>
_______________________________________

From report at bugs.python.org  Sat Apr 30 09:20:42 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Apr 2016 13:20:42 +0000
Subject: [issue26893] ValueError exception raised when using IntEnum with an
 attribute called "name" and @unique decorator
In-Reply-To: <1462019726.06.0.0957572026567.issue26893@psf.upfronthosting.co.za>
Message-ID: <1462022442.9.0.101877311291.issue26893@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
components: +Library (Lib)
nosy: +barry, eli.bendersky, ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26893>
_______________________________________

From report at bugs.python.org  Sat Apr 30 09:33:25 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 30 Apr 2016 13:33:25 +0000
Subject: [issue26893] ValueError exception raised when using IntEnum with an
 attribute called "name" and @unique decorator
In-Reply-To: <1462019726.06.0.0957572026567.issue26893@psf.upfronthosting.co.za>
Message-ID: <1462023205.62.0.818994144234.issue26893@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Looks like 2545bfe0d273 (issue 23486) is the culprit.

----------
keywords: +3.5regression
nosy: +berker.peksag
stage:  -> needs patch
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26893>
_______________________________________

From report at bugs.python.org  Sat Apr 30 09:35:53 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Apr 2016 13:35:53 +0000
Subject: [issue23960] PyErr_SetImportError doesn't clean up on some errors
In-Reply-To: <1429053168.87.0.990858167954.issue23960@psf.upfronthosting.co.za>
Message-ID: <1462023353.79.0.104432481218.issue23960@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
nosy: +serhiy.storchaka
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23960>
_______________________________________

From report at bugs.python.org  Sat Apr 30 10:33:42 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 30 Apr 2016 14:33:42 +0000
Subject: [issue26892] debuglevel not honored in urllib
In-Reply-To: <1462010683.91.0.12780176416.issue26892@psf.upfronthosting.co.za>
Message-ID: <1462026822.64.0.918505075245.issue26892@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Hi Chi Hsuan,

The patch looks good to me. Additional tests for the coverage of this will be helpful too. Thanks!

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26892>
_______________________________________

From report at bugs.python.org  Sat Apr 30 10:36:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Apr 2016 14:36:00 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1462026960.19.0.604188087959.issue26647@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I found bugs in peephole.c. I have published my comments on Rietveld, but reviewing peephole.c is still not finished.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Sat Apr 30 10:45:07 2016
From: report at bugs.python.org (Memeplex)
Date: Sat, 30 Apr 2016 14:45:07 +0000
Subject: [issue26894] Readline not aborting line edition on sigint
Message-ID: <1462027506.98.0.545203031593.issue26894@psf.upfronthosting.co.za>


New submission from Memeplex:

Maybe this is just a bug in ipython but as it's closely related to http://bugs.python.org/issue23735 I'm reporting it here too, just in case.

-- My original report to bug-readline:

using readline with ipython 4.1.2 and the TkAgg (or GTK3Agg)
backend for matplotlib, I observed the following behavior:

1) open ipython in pylab mode (ipython --pylab or use the %pylab magic once inside the repl).

2) Type something.

3) Press Ctrl-C: line edition is not aborted as expected.

-- And this was Chet answer:

This is probably the result of the same signal handling issues as with
SIGWINCH that we discussed a little more than a year ago. Readline
catches the signal, sets a flag, and, when it's safe, resends it to the
calling application. It expects that if the calling application catches
SIGINT, it will take care of cleaning up the readline state. Sometimes
applications don't want to kill the current line on SIGINT.
Notice it doesn't happen with the Qt5Agg backend.

----------
components: Extension Modules
messages: 264559
nosy: memeplex
priority: normal
severity: normal
status: open
title: Readline not aborting line edition on sigint
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26894>
_______________________________________

From report at bugs.python.org  Sat Apr 30 10:58:54 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 30 Apr 2016 14:58:54 +0000
Subject: [issue14882] Link/Compile Error on Sun Sparc Solaris10 with
 gcc3.4.3----python2.6.8
In-Reply-To: <1337679105.42.0.19403489432.issue14882@psf.upfronthosting.co.za>
Message-ID: <1462028334.68.0.18532862135.issue14882@psf.upfronthosting.co.za>


Berker Peksag added the comment:

> From some website, I was told that this is caused by a fault of Solaris's gcc.

Closing as 'not a bug' since this isn't an issue with Python. Also, 2.6 is now EOL.

----------
nosy: +berker.peksag
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14882>
_______________________________________

From report at bugs.python.org  Sat Apr 30 11:02:11 2016
From: report at bugs.python.org (Simmo Saan)
Date: Sat, 30 Apr 2016 15:02:11 +0000
Subject: [issue26895] regex matching on bytes considers zero byte as end
Message-ID: <1462028531.93.0.527876280571.issue26895@psf.upfronthosting.co.za>


New submission from Simmo Saan:

Regex functions on bytes consider zero byte as end and stop matching at that point. This is completely nonsensical since python has no problems working with zero bytes otherwise.

For example:
  Matches as expected: re.match(b'a', b'abc')
  Does not match unexpectedly: re.match(b'a', b'\x00abc')

----------
components: Regular Expressions
messages: 264561
nosy: Simmo Saan, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: regex matching on bytes considers zero byte as end
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26895>
_______________________________________

From report at bugs.python.org  Sat Apr 30 11:04:41 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 30 Apr 2016 15:04:41 +0000
Subject: [issue23897] Update Python 3 extension module porting guide
In-Reply-To: <1428588935.72.0.479238222018.issue23897@psf.upfronthosting.co.za>
Message-ID: <1462028681.92.0.751417603937.issue23897@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
components: +Documentation
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23897>
_______________________________________

From report at bugs.python.org  Sat Apr 30 11:23:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Apr 2016 15:23:39 +0000
Subject: [issue26895] regex matching on bytes considers zero byte as end
In-Reply-To: <1462028531.93.0.527876280571.issue26895@psf.upfronthosting.co.za>
Message-ID: <1462029819.67.0.59183028942.issue26895@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is no bug.

The pattern b'a' matches bytes that starts with byte 97 (ord(b'a')), but b'\x00abc' starts with byte 0.

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26895>
_______________________________________

From report at bugs.python.org  Sat Apr 30 11:36:40 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Apr 2016 15:36:40 +0000
Subject: [issue21746] urlparse.BaseResult no longer exists
In-Reply-To: <1402650592.68.0.838750531809.issue21746@psf.upfronthosting.co.za>
Message-ID: <20160430153637.17957.20765.E9CF166B@psf.io>


Roundup Robot added the comment:

New changeset 6d49a7330c99 by Berker Peksag in branch '2.7':
Issue #21746: Remove BaseResult reference from urlparse documentation
https://hg.python.org/cpython/rev/6d49a7330c99

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21746>
_______________________________________

From report at bugs.python.org  Sat Apr 30 11:37:55 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 30 Apr 2016 15:37:55 +0000
Subject: [issue21746] urlparse.BaseResult no longer exists
In-Reply-To: <1402650592.68.0.838750531809.issue21746@psf.upfronthosting.co.za>
Message-ID: <1462030675.66.0.975988926141.issue21746@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Matthew. Python 3 documentation has already been updated.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21746>
_______________________________________

From report at bugs.python.org  Sat Apr 30 11:38:11 2016
From: report at bugs.python.org (Tim Peters)
Date: Sat, 30 Apr 2016 15:38:11 +0000
Subject: [issue26895] regex matching on bytes considers zero byte as end
In-Reply-To: <1462028531.93.0.527876280571.issue26895@psf.upfronthosting.co.za>
Message-ID: <1462030691.42.0.229427597162.issue26895@psf.upfronthosting.co.za>


Tim Peters added the comment:

Do note that `.match()` is constrained to match starting at the first byte.  `.search()` is not (it can start matching at any position), and your example works fine if `.search()` is used instead.

This is all expected, and intended, and documented.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26895>
_______________________________________

From report at bugs.python.org  Sat Apr 30 12:07:32 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Apr 2016 16:07:32 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1462032452.34.0.211599652048.issue26647@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
dependencies: +modulefinder should reuse the dis module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Sat Apr 30 12:08:16 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 30 Apr 2016 16:08:16 +0000
Subject: [issue26893] ValueError exception raised when using IntEnum with an
 attribute called "name" and @unique decorator
In-Reply-To: <1462019726.06.0.0957572026567.issue26893@psf.upfronthosting.co.za>
Message-ID: <1462032496.81.0.572375833118.issue26893@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26893>
_______________________________________

From report at bugs.python.org  Sat Apr 30 12:46:02 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Sat, 30 Apr 2016 16:46:02 +0000
Subject: [issue26892] debuglevel not honored in urllib
In-Reply-To: <1462010683.91.0.12780176416.issue26892@psf.upfronthosting.co.za>
Message-ID: <1462034762.21.0.5917742923.issue26892@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Patch for the test.

----------
Added file: http://bugs.python.org/file42665/urllib_debuglevel_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26892>
_______________________________________

From report at bugs.python.org  Sat Apr 30 13:21:03 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Apr 2016 17:21:03 +0000
Subject: [issue26711] Fix comparison of plistlib.Data
In-Reply-To: <1460059602.28.0.307914137302.issue26711@psf.upfronthosting.co.za>
Message-ID: <1462036863.31.0.975370017812.issue26711@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ronald, my second patch uses "==" instead of __eq__. Is it good to you?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26711>
_______________________________________

From report at bugs.python.org  Sat Apr 30 13:42:50 2016
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 30 Apr 2016 17:42:50 +0000
Subject: [issue26893] ValueError exception raised when using IntEnum with an
 attribute called "name" and @unique decorator
In-Reply-To: <1462019726.06.0.0957572026567.issue26893@psf.upfronthosting.co.za>
Message-ID: <1462038170.32.0.124905968609.issue26893@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Thanks for catching that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26893>
_______________________________________

From report at bugs.python.org  Sat Apr 30 13:57:02 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sat, 30 Apr 2016 17:57:02 +0000
Subject: [issue26877] tarfile use wrong code when read from fileobj
In-Reply-To: <1461879882.57.0.719679075431.issue26877@psf.upfronthosting.co.za>
Message-ID: <1462039022.69.0.509909190499.issue26877@psf.upfronthosting.co.za>


???? ????????? added the comment:

Well, there are  more than one workarounds for that.

man read:
===============
If a read() is interrupted by a signal after it has successfully read some data, it shall return the number of bytes read.
=====================

So, this is a way how to make "exploit" for this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26877>
_______________________________________

From report at bugs.python.org  Sat Apr 30 14:11:53 2016
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sat, 30 Apr 2016 18:11:53 +0000
Subject: [issue26877] tarfile use wrong code when read from fileobj
In-Reply-To: <1461879882.57.0.719679075431.issue26877@psf.upfronthosting.co.za>
Message-ID: <1462039913.06.0.945809934886.issue26877@psf.upfronthosting.co.za>


Lars Gust?bel added the comment:

Please give us some example test code that shows us what goes wrong exactly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26877>
_______________________________________

From report at bugs.python.org  Sat Apr 30 14:39:35 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 30 Apr 2016 18:39:35 +0000
Subject: [issue1944] Document PyUnicode_* API
In-Reply-To: <1201415203.65.0.272410099804.issue1944@psf.upfronthosting.co.za>
Message-ID: <1462041575.98.0.249774534991.issue1944@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Remaining undocumented functions:

>From this issue:

PyUnicode_RSplit
PyUnicode_Partition
PyUnicode_RPartition

>From issue 10435:

PyUnicode_IsIdentifier
PyUnicode_Append
PyUnicode_AppendAndDel
PyUnicode_GetDefaultEncoding
PyUnicode_FromOrdinal
PyUnicode_Resize
PyUnicode_GetMax
PyUnicode_InternImmortal
PyUnicode_CHECK_INTERNED

>From issue 18688:

Py_UNICODE_REPLACEMENT_CHARACTER
PyUnicodeIter_Type
PyUnicode_AsDecodedObject
PyUnicode_AsDecodedUnicode
PyUnicode_AsEncodedObject
PyUnicode_AsEncodedUnicode
PyUnicode_BuildEncodingMap

----------
keywords:  -easy
nosy: +berker.peksag
stage:  -> needs patch
title: Documentation for PyUnicode_AsString (et al.) missing. -> Document PyUnicode_* API
versions: +Python 3.5, Python 3.6 -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1944>
_______________________________________

From report at bugs.python.org  Sat Apr 30 14:40:02 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 30 Apr 2016 18:40:02 +0000
Subject: [issue18688] Document undocumented Unicode object API
In-Reply-To: <1375989166.23.0.200448183394.issue18688@psf.upfronthosting.co.za>
Message-ID: <1462041602.78.0.744901102573.issue18688@psf.upfronthosting.co.za>


Berker Peksag added the comment:

This is a duplicate of issue 1944.

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18688>
_______________________________________

From report at bugs.python.org  Sat Apr 30 14:40:27 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 30 Apr 2016 18:40:27 +0000
Subject: [issue10435] Document unicode C-API in reST
In-Reply-To: <1289924206.67.0.561264270455.issue10435@psf.upfronthosting.co.za>
Message-ID: <1462041627.44.0.338615762458.issue10435@psf.upfronthosting.co.za>


Berker Peksag added the comment:

This is a duplicate of issue 1944.

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Document PyUnicode_* API

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10435>
_______________________________________

From report at bugs.python.org  Sat Apr 30 14:41:21 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 30 Apr 2016 18:41:21 +0000
Subject: [issue18688] Document undocumented Unicode object API
In-Reply-To: <1375989166.23.0.200448183394.issue18688@psf.upfronthosting.co.za>
Message-ID: <1462041681.71.0.905578525421.issue18688@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
superseder:  -> Document PyUnicode_* API

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18688>
_______________________________________

From report at bugs.python.org  Sat Apr 30 14:49:16 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Apr 2016 18:49:16 +0000
Subject: [issue26822] itemgetter/attrgetter/methodcaller objects ignore
 keyword arguments
In-Reply-To: <1461266621.67.0.0664681491354.issue26822@psf.upfronthosting.co.za>
Message-ID: <1462042156.15.0.210946824917.issue26822@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> 2) my attempt caused a crash.

I found an error in my attempt. Here is a patch that correctly define macros for _PyArg_NoKeywords and _PyArg_NoPositional micro-optimization.

I don't know wherever it is worth to push it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26822>
_______________________________________

From report at bugs.python.org  Sat Apr 30 15:38:01 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Apr 2016 19:38:01 +0000
Subject: [issue1944] Document PyUnicode_* API
In-Reply-To: <1201415203.65.0.272410099804.issue1944@psf.upfronthosting.co.za>
Message-ID: <1462045081.39.0.300027405538.issue1944@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

PyUnicode_DecodeCodePageStateful

Following functions likely should be wrapped with "#ifndef Py_LIMITED_API":

_PyUnicode_ClearStaticStrings
_PyUnicode_EQ
_PyUnicode_FromId

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1944>
_______________________________________

From report at bugs.python.org  Sat Apr 30 16:01:37 2016
From: report at bugs.python.org (Oren Milman)
Date: Sat, 30 Apr 2016 20:01:37 +0000
Subject: [issue26896] mix-up with the terms 'importer', 'finder',
 'loader' in the import system and related code
Message-ID: <1462046496.61.0.778323150916.issue26896@psf.upfronthosting.co.za>


New submission from Oren Milman:

the proposed changes:
1. it seems there is some mix-up with the terms 'importer' and 'finder' (and rarely also 'loader') in the import system and in related code (I guess most of it is just relics from the time before PEP 302).
The rational is simply https://docs.python.org/3/glossary.html#term-importer, which means (as I understand it) that the only place where 'importer' is appropriate is where the described object is guaranteed to be both a finder and loader object (i.e. currently only any of the following: BuiltinImporter, FrozenImporter, ZipImporter, mock_modules, mock_spec, TestingImporter).

Note: At first I pondered about also changing local variable names and even the name of a static C function, so I posted a question to the core-mentorship mailing list, and ultimately accepted (of course) the answer - https://mail.python.org/mailman/private/core-mentorship/2016-April/003541.html - fix only docs.

these proposed changes are in the following files:
    - Python/import.c (also changed the line saying that get_path_importer returning None tells the caller it should fall back to the built-in import mechanism, as it is no longer true, according to https://docs.python.org/3/reference/import.html#path-entry-finders. As I understand it, the last is indeed the right one)
    - Doc/c-api/import.rst (also changed the parallel doc of the aforementioned comment in Python/import.c)
    - Lib/pkgutil.py
    - Doc/Library/pkgutil.rst
    - Lib/runpy.py (also changed the function comment of _get_module_details, which specified wrong return values)
    - Lib/test/test_pkgutil.py
    

2. While scanning every CPython file that contains the string 'importer', Anaconda (a Sublime Package for Python) found two local variable assignments which were never used. I commented both out (and added a comment stating why). I would be happy to change those two tiny fixes if needed. 

these proposed changes are in the following files:
    - Lib/test/test_importlib/import_/test_meta_path.py
    - Lib/test/test_importlib/util.py


diff:
The patches diff is attached.


tests:
I built the changed *.rst files, and they looked fine.

I played a little with the interpreter, and everything worked as usual.
In addition, I run 'python -m test' (on my 64-bit Windows 10) before and after applying the patch, and got quite the same output.
the outputs of both runs are attached.

----------
components: Library (Lib)
files: issue.diff
keywords: patch
messages: 264576
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: mix-up with the terms 'importer', 'finder', 'loader' in the import system and related code
versions: Python 3.6
Added file: http://bugs.python.org/file42666/issue.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26896>
_______________________________________

From report at bugs.python.org  Sat Apr 30 16:07:21 2016
From: report at bugs.python.org (Oren Milman)
Date: Sat, 30 Apr 2016 20:07:21 +0000
Subject: [issue26896] mix-up with the terms 'importer', 'finder',
 'loader' in the import system and related code
In-Reply-To: <1462046496.61.0.778323150916.issue26896@psf.upfronthosting.co.za>
Message-ID: <1462046841.63.0.186700534965.issue26896@psf.upfronthosting.co.za>


Changes by Oren Milman <orenmn at gmail.com>:


Added file: http://bugs.python.org/file42667/CPythonTestOutput.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26896>
_______________________________________

From report at bugs.python.org  Sat Apr 30 16:08:38 2016
From: report at bugs.python.org (Oren Milman)
Date: Sat, 30 Apr 2016 20:08:38 +0000
Subject: [issue26896] mix-up with the terms 'importer', 'finder',
 'loader' in the import system and related code
In-Reply-To: <1462046496.61.0.778323150916.issue26896@psf.upfronthosting.co.za>
Message-ID: <1462046918.6.0.145298584962.issue26896@psf.upfronthosting.co.za>


Changes by Oren Milman <orenmn at gmail.com>:


Added file: http://bugs.python.org/file42668/patchedCPythonTestOutput.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26896>
_______________________________________

From report at bugs.python.org  Sat Apr 30 21:41:06 2016
From: report at bugs.python.org (Torsten Bronger)
Date: Sun, 01 May 2016 01:41:06 +0000
Subject: [issue22005] datetime.__setstate__ fails decoding python2 pickle
In-Reply-To: <1405687792.76.0.689943587668.issue22005@psf.upfronthosting.co.za>
Message-ID: <1462066866.12.0.248816360017.issue22005@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/issue22005>
_______________________________________

From report at bugs.python.org  Sat Apr 30 23:29:19 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 May 2016 03:29:19 +0000
Subject: [issue24114] ctypes.utils uninitialized variable 'paths'
In-Reply-To: <1430578995.23.0.112303250331.issue24114@psf.upfronthosting.co.za>
Message-ID: <20160501032912.34481.16417.1E3E0439@psf.io>


Roundup Robot added the comment:

New changeset 57bf7a40925f by Meador Inge in branch '2.7':
Issue #24114: Fix an uninitialized variable in `ctypes.util`.
https://hg.python.org/cpython/rev/57bf7a40925f

New changeset db5baad7ad69 by Meador Inge in branch '3.5':
Issue #24114: Fix an uninitialized variable in `ctypes.util`.
https://hg.python.org/cpython/rev/db5baad7ad69

New changeset 5b5fbce1db9c by Meador Inge in branch 'default':
Issue #24114: Fix an uninitialized variable in `ctypes.util`.
https://hg.python.org/cpython/rev/5b5fbce1db9c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24114>
_______________________________________

From report at bugs.python.org  Sat Apr 30 23:32:51 2016
From: report at bugs.python.org (Meador Inge)
Date: Sun, 01 May 2016 03:32:51 +0000
Subject: [issue24114] ctypes.utils uninitialized variable 'paths'
In-Reply-To: <1430578995.23.0.112303250331.issue24114@psf.upfronthosting.co.za>
Message-ID: <1462073571.28.0.480731385769.issue24114@psf.upfronthosting.co.za>


Meador Inge added the comment:

Fixed.

Thank y'all for the patch and help with testing.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24114>
_______________________________________